A beginner’s guide to ERP integration

Integration is an important concept related to any ERP system.  We all have legacy systems that work well and we want to continue using them. Many of us want to use a particular system because it is best of breed or otherwise fits well within our needs.  ERP needs to communicate with these other systems and integration is the word we use to describe that communication.

Definitions

The word integration comes from the Latin: “integrare” or to make whole.  More recently we define integrate as meaning to put together parts and to combine them into a whole.  

Communicate is a verb meaning both to send a message on a subject and then to receive the same message with the expressed meaning intact.  We all played the simple children’s game where a moderator whispered a message to one kid who whispered to a second kid. When the last kid in the line repeated the message they heard it rarely is the same as the original message.  The final received message can be humorously much different. Related to business communications, we cannot afford any loss of communication. We cannot afford any loss of integrity.

ERP integration

Businesses today have many different systems all operating at once. We have software to run our online virtual storefront.  We want to accept orders and payments using the storefront system and then manage and fulfill those orders using our ERP. If the volume of orders is very low, someone can print a report from the storefront system of orders received recently and then type those orders into the ERP system.

Check out our ERP comparison to find out what popular ERP systems can offer your business

We might have a very sophisticated system for product management.  It includes specific chemical formulations and tightly managed temperature and pressure measurements leading to products that match what we advertise and what customers want to order.  How do we integrate that product management system with our ERP and its production order scheduling and order bills of material?

Integration requirements can be external as well.  Our customer wants to send a high volume of orders and expects such quick turnaround we need to automatically integrate those customer orders with our internal ERP order fulfillment systems.

Point to point integration

If we read any of the literature on integration, we see references to point to point integration as the most simple model.  There would be a single sent message from one system that we use as a single received message read into another system. Our storefront to ERP example above seems to fit that definition.  Or, does it?

Before we can create a sales order in ERP, we must have a valid customer record.  That order from the storefront system can be for a new customer. Once we create a new customer record and then create a new sales order in our ERP, we run into another potential problem.  The product listed and sold was a model XYZ. We already defined the same product in ERP as a model 123. We have sold model 123s for years to other customers before we ever began using the storefront system.  We want to keep this integration simple so we create a two-column table we can use to match products from the storefront system to the same product in ERP.

We recorded a payment from the storefront customer and we still have not recorded that payment in the accounting module of our ERP.  We now must create a customer payment record that we can post as a bank deposit.

Integration management gets more complicated even in our simple case.  We must match the shipping method requested and possible create new records in our ship via a table.  The customer’s address can be to a new sales tax district and we have to update our sales tax jurisdiction tables.  The customer’s requested shipping date cannot be met. ERP develops a new shipping date but how do we pass that information back to the storefront system so we can inform our customer?

Point to point implies a single transmission point to a single reception point.  Even using our simple example, we see there are multiple reception points within ERP and, since we must transmit from ERP to the storefront, we have additional transmission channels.  There is a mathematical formula to calculate the number of channels we must develop integrations to manage but we can easily see there few truly simple integrations.

Custom integrations

Many businesses that wanted to integrate software with their ERP software have moved to some kind of custom integration.  As we read, simple is not so simple. Most ERP systems include a library of pre-defined connections that allow customized programming to connect to the ERP while keeping all the validation and other rules intact.  Using these connections, a developer is essentially mirroring a keyboard input through their programming.

A set of custom programs can accomplish our entire set of integrations linking our web storefront to ERP.  We have a test for a new customer ID and, conditionally, the creation of the new customer record. We get the new sales order.  We use a matrix to translate from one version of product identification to the version used in ERP. In addition, we can link backward from ERP to the storefront to update the shipping date from ERP notifying the customer when to expect his order to be delivered.

EDI

Electronic data interchange is another type of integration.  Some of the earliest businesses to use EDI were automobile manufacturers that wanted suppliers to deliver component products to a specific point along an assembly line at the precise time that component would be required.  EDI documents include purchase orders and changes to those orders. Almost any type of business document is included in the EDI set so that businesses can communicate electronically with speed and accuracy without any human requirements involved to slow the processes.  A purchase order from a customer business is translated almost instantly into a sales order in the supplier business’ ERP system. That system then can send an ASN or advance shipping notice to the customer’s ERP informing them their order is on the way.

EDI is well proven and can be used within a business as an integration link between systems as well.  The sending system sends an EDI message to the receiving system, which receives and processes that message accurately.  EDI might not be the newest technology but it can serve well.

Application program interfaces

Most systems today, including ERPs, include a library of APIs (application program interfaces).  These are clearly defined rules for communication with the system. The API will include data structures, specifications for routines, and other components necessary to communicate with that system.  Programmers can match the API from our ERP system with an API from the other system we want to integrate with ERP and the desired communications are made possible and enhanced. We still have a custom integration but now the development of that integration is much more simple and we have confidence that we will follow the rules included with both systems.

Enterprise system bus

ESB or (enterprise service bus) is a relatively new category of software.  A business can employ an ESB along with ERP and other software the business needs.  The ESB functions as a communications medium and “listens” for messages sent by one of the systems.  The ESB then “translates” that message into whatever language the intended receiving system requires so that the receiving system can “hear” to the message and understand its meaning.  An ESB can route messages between various services. It will resolve any contention among those services related to particular messages. The ESB can handle data transformation, error and exception controls, queuing and sequencing, and enforce proper quality of messaging between systems.  

Check out our complete ERP features guide to get a comprehensive look at all the features you can include in your ERP requirements

With an ESB, we set configurations rather than coding integrations.  The ESB also can set up a single point of failure bringing down all systems.  ESBs are also quite complex and require a high degree of maintenance to keep the configurations operating at an optimal level.

At this time, most ESB software is expensive and used primarily by large businesses with a high volume of communication to be integrated.  Smaller and mid-sized businesses might not have the resources required to employ an ESB.

Conclusion

Our ERP systems today are like Swiss army knives with many valuable tools we can use as needed.  All of though use many systems in addition to our ERP. Some of those are legacy systems that still provide value we require with no simple path to replacement available to us.  Some of us employ systems that are best of breed or they just work well enough the cost of switching to another system is not a cost we care to spend. Some of us use systems that are not available in any ERP.  All require integration of these systems with our ERP and often the non-ERP systems also need to be integrated.  

What we are looking for is a single “whole” system we can use across all of our functions by all of our users.  Until that “whole” system exists, we need integration to make our systems complete. Integration is not a simple process and even the most apparently simple requirements quickly become complex.  The tools available for integration improve. Developers of ERP and the other systems we want to integrate have improved in their employment of APIs to help us integrate. Software today can all employ web services, XML, and JSON that a developer can use to make integration easier to develop and more robust to use.