Archive for the ‘Software Evaluation’ Category

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 software (CRM);
• Manufacturing Management Software;
• a warehouse management system (WMS);
• Forecasting and planning;
• and Business intelligence (BI).

Disadvantages of a Best-of-breed Approach

While one could buy subsets of the above list from separate vendors, there are some 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 through a batch process, an API integration, or manual data import / export between the various systems. Particularly with API integrations, updates and upgrades in one system need to be tested in conjunction with the operation of another system to ensure no integration points become inoperable as part of the upgrade.
• 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 of discussion on 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.
• Finger pointing among software vendors. Any time two systems become integrated with one another, the customer risks being placed in the middle of the two vendors in the event that the integration is not working properly or data becomes lost or invalid when being passed from one system to another. This can ultimately lead to the customer not being able to utilize the two systems to their fullest potential and leads to all parties becoming frustrated with one another.

ERP Integration Methods

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

• Fully-integrated ERP 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 ERP 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.

Advantages of a fully-integrated ERP solution

• 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.