3 Keys to Automated Integration Without Customisation

Aug 26, 2015
Written by

microsoft logo

 

 

EDI and ERP

Technology and business process automation are increasingly becoming strategic components of success for today's digital economy.  Whether you're a manufacturer, distributor, retailer, 3PL, or in the CPG, automotive or food industries, your competitiveness is often tied to two critical business applications responsible for managing your business, ERP and EDI.  Successful implementations of these two key technologies can drive costs out of your supply chain execution and improve key metrics such as revenue per employee and cost per business transaction.

ERP systems handle finances, inventory, manufacturing and the business execution aspects of your operations. Your EDI system handles electronic interactions (transactions) with your supply chain (trading partners) including customers, suppliers, logistics organisations, banks and more.

With regard to handling the supply chain, ERP creates, receives, and manages these business transactions, while EDI transforms and communicates these transactions and instructions to and from your supply chain partners. ERP and EDI must be connected to achieve the maximum efficiencies of each. With a tightly integrated supply chain, integrated EDI will reduce labor costs and expensive errors as well.

Clearly, these two systems should be connected, but the truth is that most companies are connected poorly or not connected at all. The principal challenge in integration is that while the information these systems handle (products, prices, delivery, etc.) is the same, the ERP context and format of the data used varies greatly between systems (partners) and is very different from the data in your ERP system. This means the data must be cross-referenced, validated, and formatted precisely to create accurate business transactions in your ERP system and in the ERP systems of your partners.

The transaction integration gap is often solved by modifying the ERP to manage the transactions received and sent by EDI.  Common ERP based approaches include staging tables, and complex data "scrubbing" and formatting that can result in expensive, invasive ERP modifications Worse, such changes can inhibit updates to the ERP. These customisations are rarely well automated and require frequent manual intervention.

Integration Without Customisation

There are three main criteria for achieving automated integration between your EDI and ERP systems without ERP customisations.

  1. A strong understanding of the ERP system and the best practice approach to integration.
  2. Utilisation of a processing platform that is flexible and combines knowledge of the data in the ERP platform so data is sent accurately to the ERP and follows the end users' business requirements.
  3. Reduce user involvement with strong error trapping with alerts and automated error resolution wherever possible.

The Old Way

Historically, connecting EDI to ERP systems required the exporting of information from a translator that would reformat data received from partners into a common format that could be imported into the ERP system. The next step would be for the ERP system to do all of the "heavy lifting" - i.e. all of the error handling, data scrubbing and "cross-referencing" before attempting to create a proper transaction. Outbound transactions require even more effort from the ERP system by expecting the ERP system to understand all of the partner and transactional relationships and even provide information that is extraneous to the ERP ("turnaround data" usually received on the inbound transaction) back to the translator. This unpredictable "turnaround" data usually has no native storage area in the ERP system and requires customisation for storage so that it can be passed back to the translator at the correct moment.  Since the demands and needs of current and future partners are nearly impossible to anticipate, ongoing customisations are the norm for most ERP platforms.

Organisations that undertake ERP customisation projects for EDI integrations frequently report the same problems, which include:

  • Over budget ERP implementations.
  • Difficult and expensive ERP upgrades.
  • High ongoing cost of maintenance.
  • Transactions "falling through the cracks" due to the decoupled nature of Translators and ERP transactions. This is caused by multiple points of failure in the solution and lack of transaction lifecycle audits.
  • Unplanned disruption of ERP production environments to meet external mandates from partners.

The Solution

Full integration requires a strong and well-architected connection between the EDI and the ERP data so that the business rules and validations can be performed at the time the transaction is processed. A system that understands the unique EDI and ERP processing requirements can stand between the two processes; the ERP data and the EDI trading partners. That system must be specifically attuned to the way the ERP ‘thinks' so that it can pass information between the systems without undue burden on the ERP.  Additionally, the EDI processing platform has to understand the relationships between partners and the ERP transactions to avoid customisations.  "Turnaround" data has to be stored in a manner that is flexible and accessible to the outbound transactions.

Taking full advantage of the opportunities of advanced supply chain automation requires experts who understand both the ERP and EDI. Many EDI shops don't have experts in the ERP system that must reliably connect the EDI data nor the correct platform to make it work without ERP customisations. To be an expert in EDI to ERP integration, there must be a deep understanding of the implementation, maintenance, and lifecycle development of the ERP so that transactions are handled correctly and consistently.

Many EDI service providers offer EDI compliance, but very few make the commitment to coupling those capabilities with expert ERP integration that avoids ERP customization. Only those organisations can support such end-to-end integration in the long-term.

Written by : Glenn McPeak

SHARE ARTICLE