To achieve the utmost benefit when purchasing additional software to work with your ERP system, be sure to have a solid understanding of how your legacy system and the new package will work together.

By Ray Rebello, PE, CIRM

Interoperability addresses a range of manufacturing challenges. Possible scenarios include:

•A fabricated metals manufacturer receives an order through its ERP (enterprise resource planning) Sales Order Entry module for 200 additional units per week. The ERP system must work with an advanced planning system to see if the capacity and constrained material is available. If so, the information needs to be passed back to the ERP's material requirements planning (MRP) system to place the orders for the remaining materials.

•A consumer packaged goods manufacturer faces expensive transportation costs due to both weight and spoilage. The need is for the ERP system to work with a transportation optimization application at the time the production orders are being planned.

•An electronics manufacturer has always measured itself on the time it takes to develop a new product. However, due to increased competition, management is now measuring on time to full production. This means that manufacturing must work closely with engineering. Unfortunately, they have separate systems that do not interoperate.


Growth of "partnerships"
ERP solution vendors are becoming increasingly aware of the fact that they cannot meet all of their clients' growing lists of requirements. Therefore, they are moving to business partner relationships or alliances at a rapid rate to bridge additional supply chain functionality to the ERP backbone product.

Industry analysts have written that today's customers are looking for an "integrated solution." However, some in the analyst community predict that in a few years customers may be open to selecting "best-of-breed" applications. This means that former competitors may have to become "partners." If this occurs, the number of relationships between various software vendors will grow dramatically.

What type of vendors are partnering? Below is a partial list of the types of software you can expect ERP vendors will be looking to partners to provide:

• advanced planning systems (constraint-based and supply chain optimization)
• manufacturing execution systems (MES)
• service and warranty tracking
• visual product configurator
• sales force automation
• product data management/CAD (computer-aided design)
• hazardous materials, import/export, and other documentation

Dramatic growth of partnerships will result in a great deal of marketing hype. Many expectations will be set by the various sales forces selling their individual packages. However, customers wanting a complete solution will need to demand that interoperability be provided by the software providers. In reality, not all partnerships between the vendors will be equal, therefore all interoperability will not be the same. The question you must determine from your ERP software supplier is "what is the specific degree of interoperability between each of their partners?"


Three Types of Interoperability
To interoperate, the ERP vendor system must effectively integrate with the partner's best-of-breed system. How well it integrates will mean the success or failure of the interoperability. Three levels of integration are shown in Figure 1. As you progress through each of the levels, you will see that each new level has the potential to provide faster and more accurate interoperability. But each level has a higher development cost to achieve interoperability.

•Level 1: Interfaced Data
Interfaced data is the simplest level of interoperability. At this level there are two separate databases and two separate user interfaces. The programming requirement is to simply synchronize the databases to be sure the same information exists in both ("A" and "B" in Figure 1). For the ERP user to get an answer from the finite scheduling system, they would have to sign-on to the finite scheduling system. That system would perform all calculations using its own database. No answer is automatically returned to the ERP system.

Although this is one level of interoperability, it is not very efficient and results in errors due to outdated information or inaccurate database updates. Unfortunately, in today's ERP environment this is often sold as "integration."

•Level 2: Integrated Applications
This level of interoperability requires two separate databases, but has only one user interface. Because the databases are separate, they first need to be synchronized on a regular basis to keep the information accurate ("A" and "B" in Figure 1). The next step is the actual "calling" of the partner's application to perform the calculation ("C" in Figure 1). The finite schedule uses its own database to perform the calculations. Then the answer is returned to the ERP system for the user to review ("D" in Figure 1).

This is a very popular method of integration because of the single-user interface. The caution here is to make sure that the databases are synchronized on a regular basis.

•Level 3: Embedded Applications
Level 3 provides the best integration. At this level there is only one user interface. In addition, since there is only one database the information is always accurate.

At the embed level the user is exposed only to the ERP applications. The ERP application will call the finite scheduling program, sometimes referred to as the "engine" ("G" in Figure 1). The finite scheduler uses the ERP database to perform its calculations ("H" and "I" in Figure 1). The answer is returned to the ERP system ("J" in Figure 1), and then to the user.

The embed level is prevalent in much of the sales literature and is the one many vendors would like you to believe they have. However, to achieve this level of interoperability there is a great deal of effort required between the partners since the application code needs to be modified. This embed level of interoperability is rarely attained.


Designing Interoperability
In any case where two databases are involved, the synchronization program must be written and maintained. It is common to write a synchronization program in one of two ways: without edits or with edits. In the first, a database is updated directly without editing the data. This is easy to do, although it can be very risky.

The second common alternative used to synchronize the two databases is to write an application-specific interface program. This method creates a batch program that duplicates the functionality existing in the interactive code. This batch function accepts input from the outside application, logically edits each transaction, and updates the database if all is well. Assuming this is the best approach, one can envision the amount of work required for interface development.

Typically, in today's environment, a new application-specific interface is required for each new partner's software. As the number of business partners expands and the number of versions supported grows, the number of interfaces required will grow accordingly (see Figure 2). In fact, if the analysts' best-of-breed vision comes true, then the number of interfaces could easily get out of control.


Benefits of APIs
Instead of writing so many application-specific interfaces, a logical approach would be to develop a standard and reusable method to access the ERP application (see Figure 3). This approach is called an application program interface (API).

The API concept involves an ERP vendor creating one standard entry point for any application program and publishing the structure of the data elements (parameters) which must be passed.

The ERP vendor is responsible for writing and maintaining the piece of code which works within its system. The application-specific interfaces are eliminated and replaced with only one API. Thus, any future business partner would write to the API and significantly reduce the amount of development and maintenance.

In the manufacturing environment, the API approach is valuable. It means that a manufacturer could add new functionality to the ERP system and be confident that the software would interoperate at a low maintenance cost.

The goal of the software vendor should not be the adding of new technology and software just for the sake of change. Business software should deliver real business benefits, such as 60 percent fewer days of inventory, thus providing better cash flow.

When you consider the purchase of additional software to work with your ERP system, be sure that you have a solid understanding of how the two software packages interoperate, or you might find out that, in fact, they truly don't work together for you at all.

Copyright © 2020 by APICS — The Educational Society for Resource Management. All rights reserved.

Web Site © Copyright 2020 by Lionheart Publishing, Inc.
All rights reserved.


Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: +44 23 8110 3411 | br> E-mail:
Web: www.lionheartpub.com


Web Design by Premier Web Designs
E-mail: [email protected]