TGI - ERP Software Solution

Main Menu

Posts Tagged ‘ERP software evaluation’

Successful ERP Implementation Starts with Successful ERP Software Evaluation

Friday, March 25th, 2011 by admin

Implementing an ERP software system represents both a significant technological and cultural change for any manufacturing or distribution organization. An ERP system changes the very nature of individuals’ jobs, roles, and responsibilities within the company. Unfortunately, the ERP industry is wrought with failed implementations or terrible stories of companies not being able to take orders, receive product, or ship orders to customers upon go-live.

Generally speaking, implementations fail for two reasons. First, the manufacturing or distribution organization’s internal ERP implementation project team was simply not committed to executing the necessary tasks to complete the software implementation in a timely fashion. Similarly, the ERP vendor was not able to deliver what it promised during the sales process or was not equally committed to completing the implementation successfully.

Secondly, and perhaps more commonly, ERP implementations fail because the organization did not select the right ERP solution and vendor in the first place. Successful ERP implementation projects do not begin with signing contracts and paying a software vendor money for software licenses; rather, successful ERP implementation projects begin with a well-structured, quantitative ERP software evaluation process that looks in-depth at each ERP system’s complete set of functional capabilities and how such functionality translates to tangible benefits and potential ROI for the manufacturer or distributor. To a degree, “selecting” an ERP system is different than “buying” an ERP system.

At TGI, we encourage each of our potential new business prospects to evaluate TGI and Enterprise 21 ERP through a thorough, quantitative ERP selection process, and we offer free ERP software selection tools to assist in this process. Depending on the nature of the industry the prospect is in, the prospect’s software requirements across various business departments and units (accounting, order entry, inventory and warehousing, purchasing, manufacturing, etc.) expected software implementation time frame, budget constraints, and countless other factors, we are often times a great fit for the prospect. Other times, however, we may not have the most viable solution for a particular business. The point is that through a thorough ERP software evaluation process, strengths and weaknesses of each software vendor and solution can be identified, allowing organizations to select the best possible ERP solution for their respective businesses while simultaneously providing a stepping stone for organizations to complete their ERP implementation projects successfully.


Buying a fully-integrated ERP software suite vs. a best-of-breed solution approach

Friday, December 25th, 2009 by admin

This article will explore the relative advantages of acquiring and implementing a fully-integrated ERP software system rather than buying application software based on a best-of-breed solution approach.

A typical manufacturing or distribution enterprise will need the following types of functionality:

  • Financial management and reporting;
  • Inventory management, purchasing, and order management;
  • E-commerce;
  • Customer relationship management;
  • Manufacturing planning and execution;
  • Warehouse management;
  • Forecasting and planning; and
  • Decision support and business intelligence.

While one could buy subsets of the above list from separate vendors, here are some of the disadvantages to buying this functionality based on a best-of-breed approach:

  • Separate systems with separate infrastructure – separate database instances potentially requiring separate servers.
  • Different look and feel for various applications – users would have to learn different sets of commands and menu structures for different applications.
  • Sharing of data across separate systems – passing of data would generally be done via a batch process.
  • Timeliness of data across the enterprise – even if the data were shared perfectly across the separate systems, there would be time delays between the time data is initially present in one system and when it becomes visible in the other system.
  • Single version of the truth for the entire business – when data is not fully in-sync, there can be differences of opinion as to whose data is correct (i.e., what were the monthly sales figures for customers in a given category or geographical region?).
  • Everyone in the organization works from the same set of information – provides visibility to data from across the organization to make well-informed decisions that impact customers and the organization as a whole.
  • “Least common denominator” for functionality – often an overlooked point in discussion of this topic. There can be some enhanced functionality in one of the functional areas that is the reason the business decided to buy that specific best-of-breed solution in the first place; however, the functionality and data needed from other functional application areas to support and enable that functionality may not be present or easy to access in those other modules, making the new functionality impossible to use.

The following describes the spectrum of integration methods for enterprise-class application software:

  • Fully-integrated system – designed and built from the ground up as an integrated whole all by the same software development organization and team.
  • Separate systems that are owned by the same software vendor – software vendors may have acquired separate systems and developed integration points between these solutions.  In general there would be separate development teams for the various solutions within the given software development organization. The development teams’ primary focus would be on functionality and ease of use enhancements within their specific product lines, not the integration points between various solutions.  There could be a third, totally separate development team for an integration solution from the software vendor.
  • Systems from different organizations that work together – similar to systems that are owned by the same software vendor above, except in this case the separate development organizations focusing on the separate solutions are not owned by the same parent organization.  As you might imagine, this further complicates matters.  One solution provider may elect to change their complete database schema from one software release to another thus disabling any existing integration points. This approach also poses problems for the upgrade process, software vendor roles and responsibilities, and paying maintenance fees to multiple software vendors year after year.
  • One-off integrations by systems integrators – in this case, a systems integrator who is implementing one or more of the software solutions for a given customer may have developed an integration point between two solutions.  In this case, the systems integrator is the only one concerned with the integration – not the development organizations who own the separate software solutions.  This is the most precarious situation of all of the non-fully integrated solutions scenarios.

Core advantages of fully-integrated systems:

  • Data is timely and accurate across the entire enterprise with single points of data entry.
  • Training of personnel in one functional area can translate into other functional areas because the usability aspects of the system as well as core functions (creating new items, querying for data, etc.) will be the same across all areas of the application suite.
  • Single version of the truth – by having one centralized system, data will be the same for the entire enterprise.
  • Integration between functional areas will be the strongest and will be in the best position to enable a company to implement version upgrades as they become available without risking invalidating an integration point between two separate systems.
  • Should be able to take advantage of all functionality in the system without concern about running up against a “least common denominator” situation where functionality in one area of the system may be unusable because corresponding functionality and data may not exist in other functional areas of the business system.

It has been my experience over the years that most organizations who have adopted a best-of-breed approach have not done so based on a strategic decision; rather, they have had a core set of functionality they have decided is the starting point for ERP selection and implementation purposes of a new system.  Rather than focusing on a superset of functionality they will likely ultimately need over time, they may have made a decision to go with an ERP software package that fit the core subset of capabilities very nicely at a price point that was substantially lower than fully-integrated solutions with broader capabilities.

Over time, however, the business outgrows the functionality originally selected and implemented and is now forced to make a decision of whether it wants to keep its existing software and add a bolt-on solution to what it already has or start over and go with a broader, fully-integrated ERP solution.

Organizations are strongly encouraged to step back and ask themselves where they are going strategically and what complete set of functionality they will ultimately need over time so they can buy a fully-integrated software suite that provides this complete set of functionality even if they don’t take advantage of all of its capabilities day one.