Switching ERP systems in a business is like transplanting all a person’s internal organs at once – and if you are going to take on that kind of pain, you might as well do it right. Three fundamental areas can determine success or failure of even the best managed program: where to set the functional edges; how to design the interfaces for the edges you set; and how to model your business objects in the software. In this post I’ll tackle interface design.
Types of Interfaces
There are three types of interfaces linking ERP systems with other systems:
Master Data Interfaces: Master Data includes reference information on entities like employees, vendors, customers, business units, cost centers and service lines. In general, Master Data should be created in the ERP system and passed to linked systems. Once a piece of Master Data is created, changing that information should happens infrequently (the data is non-volatile). The frequency that the information needs to be passed from the ERP to the linked system may vary from near real-time to weekly/monthly, although daily or hourly is typical. If the requirement is for real-time or near-real-time updates, then the interface should probably be a web service lookup in the other system, rather than a batch process loading reference data very frequently.
Transactional Interfaces: Transactional Data includes frequently updated or repetitively inputted information such as employee hours worked, goods purchased, work order status changes, etc. A best-of-breed system may be implemented because it handles this function better than the ERP. These transactions should start and be managed in the linked system. Only necessary information (usually financial) should be transferred back to the ERP, not every bit of detail and every status change. Researching history, making detailed adjustments should be done in the linked system if at all possible.
Status/reference Interfaces: Critical status or reference fields may need to be written back from one system to another for objects that already exist in both systems. For example, an invoice # may be a critical piece of reference information in a customer-facing work order system, even though the invoice is generated in the ERP system after the work order is finalized in the secondary system. If customer and operational requirements can be met without this type of update, such as through other reporting means, they should be. Such updates can be sporadically unreliable due to subtle differences in when objects are locked for update, purged, or other differences in the underlying data models.
Interface Principles
The following principles drive design of interfaces with an ERP.
One way: As much as possible, a type of information should flow in one direction. For example, an employee record may be created in the ERP system and should then flow to related systems. A work order may be created in a specialized system, and the necessary financial information flows to the ERP system. This insures data integrity, removes reconciliation steps from the process and ensures that the full lifecycle of a transaction does not have to be parallel in each system. It may be that information needs to be augmented in a different system, but as far as possible back and forth flows should be avoided. For example:
- An employee‘s authorization level may be maintained only in a linked Purchase Order system, even though the employee ID comes from the ERP. The authorization chain should not have to be represented in the ERP.
- A linked Asset Maintenance System may be needed to hold detail on an asset to control preventative maintenance schedules or bills of material; only the Asset ID (or even only the Property ID where the asset is located) may need to be maintained in the ERP, with the necessary financial information written back to the ERP.
Common: As much as possible, the interfaces to/from the ERP should be common among the different linked systems whenever possible. The employee download from the ERP should be a superset of all employee information sent to all the other systems. The work order upload from different work order systems to the ERP should be defined to handle information from all work order systems. This requires more effort in establishing a single, flexible design, but vastly reduces subsequent effort in maintaining and modifying the interface, or adding additional like systems, instances or versions to the fold.
Skinniest: The smallest amount of information possible should be passed between the systems. For example, work order workflow should not be modeled in both a work order system and the ERP. Detailed inventory or payroll information should only be held in the system where these transactions are processed (with the financial result written back to the ERP system). There are likely to be differences in the data model, functionality, bugs, etc. that make it impossible to keep two systems at the same level of detail without introducing a major reconciliation function which has no other value add.
Always-On: The default should be that a system instance has all interfaces on from the start. This insures that systems do not drift apart until someone decides to ‘turn on’ transactional interfaces / integrity. All interfaces should be on an automated scheduler.
Additional considerations
Timing/update issues: The simplest interfaces only update on completion in one system. Design issues may require violating this principle; for example, work orders may need to be pulled over from a linked system to the ERP prior to completion so that hours or other costs can be posted against them while they are still in process.
Scheduler: No manual intervention should be required for the interfaces to operate. Some type of scheduler should control interface runs, or the interface should be implemented with a real-time listener.
Frequency: The frequency of each interface should be no less than daily for most interfaces. Interfaces are always less work to maintain in the end if they work every time. Deciding at the outset that the frequency is at least daily forces this discipline on the design and testing of the interface.
Data Warehouses: Transactional data and reference data from all systems typically need to feed the data warehouse. The data warehouse interface is sometimes implemented separately precisely because it may have very different requirements from other interfaces. It may require far more fields of master data, for example, and require major compromises in the principle of skinniest interface above if master data interfaces are to be common.
Common interface vs Connector: Some systems may have off-the-shelf connectors available to integrate with the ERP. The benefit of using this off-the-shelf connector must be weighed against having a common interface for that data for all systems. Unless two systems come from the same vendor, I have often found limitations in fully off-the-shelf connectors limit their usefulness.