EDI & ERP

EDI Impact on ERP System Implementation

ERP systems are designed to be a ‘total solution’ to enterprise resource planning across multiple business units with each component having an impact on every other component. The components are typically grouped into ‘subsets’ that direct their functionality at different business operations:

Finance & Accounting

Supply

Manufacturing

Warehouse & Distribution

Marketing & Sales

Planning & Analysis

Each of these basic business components has direct impact on each other component. The ERP system attempts to balance the impact and make information transfer more efficient and standardized. This is designed to reduce the ‘foreign’ system interfaces; but never entirely eliminates them! No system yet conceived will meet any corporations ‘total’ system requirements. In every case, there are ‘auxiliary’ and other support systems that will have to be interfaced to the ERP system. Furthermore, many companies cannot live with the delivered functionality of the ERP system that was chosen and decide to ‘modify’ it to meet on-going business requirements.

For these reasons and just plane ‘good business’ it is extremely critical to plan these deployments, considering the different impacts on each business unit. In the past with multiple vendor-supplied systems, the interfaces were known, controlled and understood by the indigenous staff. Now with ERP systems, these interfaces are imbedded in the system and no longer completely understood by the company technicians or applications support groups. (Frequently, they are not even understood by the ERP systems group who deliver the product)

Because the ERP systems component interfaces are imbedded and controlled by ‘setup tables’ or other control systems which are defined during the installation process, when the system is configured the ‘setup’ process selects different program components to ‘load’ as part of the installed ERP system base. These selected components will determine the inventory method and how it is valued, counted, warehoused; how accounting entries are posted and at what level of detail (defined by the Chart of Accounts). Component selections will determine the manufacturing process control, warehouse management and distribution control processes to be utilized. All these business unit control systems will be linked by imbedded system processes necessary to control the vast array of components encompassed by the ERP system.

It is for this reason that the planning process is so critical. Every business unit in the company will be directly affected by the operation of the ERP system. Subsequent changes in any business unit function or process can and will affect every other component.

If for example, a company chooses to implement EDI or other electronic communication transaction system at a later date, many of the operational components of the system will be impacted. If in the future, instead of hard copy purchase orders, the company decides to utilize a fax based system, the simple concept of ‘send method’ for the purchase order comes into play. Based on the original configuration, if this was not planned, the component required to format a fax instead of print the purchase order may not have been installed. This becomes more complex if electronic data interchange (EDI) is chosen at a later date. A whole set of tables, files and parameters come into play that may not have been configured during the initial installation of the ERP system.

Not only may the purchase order process be impacted, but the purchase order response cycle, change management, backorder system, manufacturing, lead time, distribution and accounting discount management systems will come into play. This does not even consider the legal impact of the company and its business partners agreeing to accept a facsimile instead of hard copy; an electronic transaction instead of a fax.

When the electronic business application comes into play, whole new sets of components are added. Instead of ‘data entry’ processing the purchase order or invoice, now it is electronically entering the system. The oversight that many companies relay on, the clerical purchase order desk or invoice-processing desk, are no longer a part of the transaction process. The manual correction prior to data entry that the clerical staff ‘always’ did is no longer present. The simple change of ‘e’ to ‘ea’ for order quantity in ‘eaches’ that the data entry clerk automatically made, is no longer ‘automatic’ but must be planned/programmed to be handle.

This has a ‘ripple’ effect across each and every business unit. Activities that used to be ‘handled’ by indigenous staff now must be ‘handled’ and processed by the ERP system interfaces. Now the people that used to perform the mundane task of ‘paper handling’ can be better utilized as ‘error handlers’; tackling the inbound/outbound transaction flow that falls outside the capability of the ERP system to process.

ERP transaction interfaces (IDOC’s for SAP, F47-files for JD Edwards, EDI Gateway for Oracle, etc.) are designed to process these electronic transactions into and out of the ERP application system business unit modules. These transactions have both accounting and financial impact as well as operational impact on the day-to-day operation of the business. They have ‘ripple effects’ across business units. Without the proper planning and understanding of these ‘gateway’ interface operations, companies may fail to plan for the impact that electronic transaction processing through an ERP system will have. Attempting to implement an electronic transaction interface (weather it’s EDI, MQ-Series, MS-MQ, Internet access, or another mode), after the ERP system has been fully implemented may be extremely costly. Many of the required components may not have been installed during the ‘configuration process’ if certain electronic interface options (such as EDI) were not selected during the initial criteria and business rules selection process. Retrofitting these components over existing operational ERP system components may be difficult. More so if any customization was done to ANY business unit module; due to the inter-linkage ‘ripple’ effect of how the ERP system processes transactions.

In addition to this 'ripple' effect, many of these transaction interfaces in today's ERP systems do not have sufficient data elements to contain and manage many of the new data requirements present in today's electronic business and EDI transactions. Current sophisticated shipping and transport systems require complex dating and specific packaging instructions. In addition, with many 'drop shipment' orders, third party shipping addresses and instructions often are not captured in the basic ERP system data base structure. Further complicating the situation is RFID (Radio Frequency Identification) tagging and specifications will soon become a standard practice in most industry segments (wholesale, retail and government). This will add identification tagging components to many shipping transactions that are not currently supported within the most common data base structures of today's ERP systems. It is therefore necessary to implement auxiliary data structures that will support and maintain these additional data components of today's business transactions. The data flow methodology encompassed by EBFM (Electronic Business Flow Management) design provides the data analysis and structure to support these and forthcoming data requirements.

In the end, it is always better to plan than to spend. Careful consideration of the ERP system’s impact on on-going business operations must take priority over the ‘need to implement’. At the same time, it is paramount that companies don’t ‘plan’ instead of ‘do’. There is a critical balance that is often gained by the old KISS principle. The more complex the operation, the more detailed the planning. The simpler the process, the easier to implement.

Evaluation of business rules is necessary prior to any ERP system implementation. The concept of an Enterprise Resource Planning system is after all based upon the concept that the business has adopted a common set of business rules that have been (or are to be) applied across all affected business units of the organization.

Experience Counts!

“You can't keep one disease and heal two others - when the body heals it heals everything.”