Pain and Gain of Integrated EDI Part Three: Other Industry Gains

The Gain of Integrated EDI

Electronic data interchange (EDI) has earned the reputation of a complex, rigid, and expensive means of document and data exchange among trading partners. However, transportation, finance, insurance and other industries have heavily leveraged EDI and proprietary communications to conduct business. Also, major manufacturers, such as automotive original equipment manufacturers (OEM) and consumer product goods (CPG) companies have embraced EDI and mandated that their suppliers do the same.

Consequently, many small and medium companies are under pressure to deploy the same EDI system as a major customer, and are making it a basic cost of doing business with the market leaders. An example of this widespread trend of larger companies giving ultimatums of "my way, or highway" is Owens Corning. It has mandated that several hundred of its suppliers implement Internet EDI or face a $50 (USD) charge for each paper invoice submitted. Other large corporations, such as Wal-Mart, Home Depot, Target, etc. in finding Internet-based EDI to be productive and cost-effective, have mandated it to their suppliers.

This is Part Three of a three-part note.

Part One detailed the pain of integrated EDI.

Part Two discussed the gains of the automotive supplier industry.

The EDI-XML Debate

For some enterprises, there are still barriers to using EDI, or at least some compelling reasons for them to embrace extensible markup language (XML) to exchange vital documents such as purchase orders, delivery notices, and invoices instead. In theory, XML shows many advantages, since unlike EDI, it was specifically designed to transfer data on the Internet. Also, while organizations in an EDI network have to set up direct, "point-to-point" connections between each participating system, XML's "extensibility" supposedly means that participating companies using an agreed upon data format for transactions can freely exchange data. In short, XML has initially not only promised to ease the technical pain of integrating the flow of data between systems, applications, and people, but it can reduce cost through faster transactions throughput, improved trading partners' data quality, the elimination of manual processes, and so forth.

Nevertheless, while at the surface there are few economic or strategic reasons for organizations to persist with EDI, many seem reluctant to adopt XML. In fact, there is only negligible growth in the number of organizations replacing their EDI-based systems with XML. The key reason being that the percentage of organizations using XML has not yet reached the "critical mass" of double digits in the of overall business-to-business (B2B) data flow. However, the number of large and medium organizations using EDI is estimated between 250,000 and 350,000 worldwide.

Additionally, XML is not without its challenges. For one, XML standards are still relatively immature and unstable, lacking a lot of development and industry expertise behind them. Consequently, it is curious that the perceived value and adoption of XML is higher within the hi-tech, chemical, and retail and consumer sectors where there are mature industry initiatives and standards like RosettaNet, CIDX, UCCNet, AS2. Moreover, XML has a larger footprint than EDI, which means it requires more bandwidth. For companies that handle large volumes of transactions a day, that extra bandwidth can quickly become quite expensive.

For the time being, businesses that have invested significant resources in EDI use it for B2B communications, and many see EDI as the best choice for secure, reliable transactions because it is a mature, standardized, and trusted medium. The leading EDI standards, such as the X12 and EDIFACT, continue to meet the ever-evolving needs of more than a dozen industries. Contrast this to the ongoing evolution of the myriad of industry-specific extensions (dialects) to the XML standard—many of which are non-interoperable and still work-in-progress. Inevitably, XML traffic will exceed EDI X12 protocol traffic, but it will not necessarily be a replacement. While X12 is still the dominant format for things like purchase orders and invoices, X12 documents are not widely used for newer things like collaborative forecasting and planning. Because of this absence, users may be motivated to exchange these data in XML.

What has emerged instead is a type of XMLEDI hybrid, leveraging the benefits of both interchange systems and satisfying the demands of large and small companies in a trading network. Many customers want to leverage XML with their existing EDI systems, making interaction between the two technologies seamless. This relies on enterprise application integration (EAI) platforms from the likes of Sterling Commerce and GXS. Additionally, it is only logical that these EDI value-added networks (VAN) and other providers of service integration will reinvigorate their business value proposition by adding applications to their "plumbing" portfolios and offer more of an application-like, vertical solutions approach to meet the integration requirements of the trading community. To that end, the Sterling Integrator product supports EDI and XML natively, allowing users to maintain their investment in EDI while progressing to key XML-based technologies.

Going a Step Further?

Still, this readable data is only partly good for enterprise resource planning (ERP) and back-office systems, since the real action is in merging data with information already being processed within the ERP system. The challenge is to make sense of the constant flood of information arriving daily as EDI messages. In high volume environments, this can consist of hundreds of records affecting the releases and forecasts of hundreds of parts. It is infeasible to manually re-enter this data. Therefore an additional interface must be developed and tested. Yet, unlike an interface that updates and synchronizes inventory levels or product quality information (if one is talking about interfacing ERP systems with WMS or quality management systems), the EDI interface typically involves the extensive use of business rules and logic. These are established between every customer and supplier rather than to only statically mapped data. That is to say, the highly personal nature of the data means that no two interfaces are exactly alike, thus further complicates matters.

Ultimately, these imply an extensive use of resources on both sides of the table. The enterprise software vendor supplying the interface must write and test custom code, and the user (such as an automotive supplier or customer) must test and re-test thoroughly until the interface is working consistently. However, with an intrinsic EDI system within the ERP product, third party software costs are virtually non-existent. Moreover, the time it takes to build the custom interface is drastically reduced, since the interface work is built from within the ERP system and the knowledge of data structures and business logic is inherent.

To that end, Microsoft will provide built-in support for various EDI standards and data transports. In addition to working with Inovis, it will develop EDI and other areas of connectivity extension and enhancement with the help of Covast and vSync. Covast's EDI Accelerator for BizTalk automatically renders an XML representation of the EDI format and vSync markets EDI for MBS Great Plains. It allows users to send and receive EDI documents from within the ERP package's Sales Order and Purchase Order modules.

However, over the last ten years, another MBS' EDI partner, eBridge, has also established partnerships with many other leading mid-market ERP and accounting software vendors, such as ACCPAC, Best Software, Epicor Software, Exact Software, Intuit, Open Systems, and Softline, which together with ACCPAC, was recently acquired by Sage Group, the parent of Microsoft Business Solutions' (MBS) archrival Best Software (see Will Sage Group Cement Its SME Leadership with ACCPAC and Softline Acquisitions?). eBridge provides tools that allow mid-market ERP and accounting packages to accommodate bi-directional data exchanges within an EDI (ANSI X12 and EDIFACT for international deployments) or XML framework. Products include the flagship eBridge EDI, Mapper (for reformatting e-business documents), ASN, CRM Integration, and the eBridge Software Development Kit. Epicor also partnered with ACOM, whose EZConnect engine also allows trading partners to exchange documents in compliance with EDI, XML, and other structured data formats.

IQMS Offers Integrated EDI

It is amazing that the small ERP vendor IQMS has a native IQ EDI module that supports ANSI X12, EDIFACT, and Odette file formats. Given the importance of emerging technologies, IQ EDI is also XML-enabled and supports FTP transmission and receipt of files. The system generates and processes virtually all commonly required transaction sets. For inbound transactions, it supports remittance advice (820); planning/release schedule (830); purchase orders (850); change orders (860); shipping schedule (862); order status report (870); receiving advice (861); functional acknowledgement (997); cash application (824); and text message (864) when it comes to X12 format, and DELFOR (a delivery schedule message from a buyer to a supplier about product requirements) and DELJIT (delivery just-in-time message which relays the precise delivery sequence of a JIT schedule) EDIFACT transactions. On the outbound transactions side, it supports invoicing (810); planning/release schedule (830); shipments (ASN) (856); order acknowledgement (855); vendor shipping schedule (865); and functional acknowledgement (997) for X12 and DESADV (dispatch advice message) for EDIFACT—a message specifying details for goods dispatched or ready for dispatch under agreed conditions.

Further, due to the inherent integration with the rest of the vendor's EnterpriseIQ ERP suite, outbound transactions are sent directly from the system. It also includes template-mapping tools and eliminates the need for third-party translators, which are a default for a vast majority of ERP systems that require third-party EDI solutions. When it comes to industry savvy, the system is based on the Automotive Industry Action Group (AIAG) supply chain business practices and a number of flexibility business rules generate exceptions. For example, it can flag and report dramatic quantity changes in EDI transactions or identify the maximum increase or decrease allowed based on a selected day range and allowed percentage change (user defined limits). Logically, orders complying with the rules are passed through to the sales module, while the orders that do not comply are flagged.

Finally, the rules can be set up either for each EDI transaction code number or each customer. IQ EDI is an integrated component within EntepriseEQ, supporting the capability to translate files that are downloaded directly from a web site or through the traditional EDI mailbox setup with a VAN provider. However one should note that IQMS does not provide communication nor maintains the mailbox, and requires a third-party communications system (i.e., VAN) to perform this service.

EnterpriseIQ also offers a number of useful utilities, such as the IQAlert notification system, with many nifty business activity monitoring (BAM) features (see Business Activity Monitoring— Watching the Store for You). For example, the appropriate persons are alerted about low inventory levels, missed shipments, late or pending purchase order receipts or other burning issues. It can also schedule unsupervised tasks like running a material requirements planning (MRP) engine, EDI processing, or creating database backups late at night.

User Recommendations

Small and medium, discrete repetitive manufacturing and distribution businesses with demand-driven supply chain management concerns, unsophisticated B2B integration practices, and a need to flexibly connect with trading partners should evaluate the functionality of these products and how value can be added to existing applications.

As usual, users should employ a critical approach when evaluating products, and require company representatives to demonstrate specific technological and germane functional capabilities. Compliance with the common industry standards such as Ford MS-9000, AIAG, Manufacturing Assembly Pilot (MAP), or International Automotive Sector Group (IASG) QS-9000 should be probed. Whether the system supports the practices and dictated standards by the "big-brother" trading partners (such as GM, Ford, Honda, etc.) should also be determined.

Lower tier automotive suppliers in need of a plant-focused ERP system and the need to quickly and affordably get on their e-business feet will likely benefit from evaluating IQMS, Infor Automotive, and similar products. Additionally, the likes of Infor Automotive should be evaluated to raise the bar for other vendors when demonstrating their EDI, ANX, release accounting, just-in-sequence (JIS), repetitive purchasing, integrated barcode printing, lean manufacturing, and other e-business processes pertinent to the automotive industry. Sharp industry focus and domain expertise, product interconnectivity, and quick and inexpensive e-commerce enablement have been the bargaining chips of IQMS, QAD, and Infor's in the game against its peers.

Companies that are dependent on EDI for transaction routing should look hard at these products as a pathway into the XML century. What should be most important is how smoothly the translation service can be integrated with other systems. Therefore, size and technical strength are not as important as is users' experience with the same systems.

Given that XML and EDI will be used concurrently for some time in the future, companies should think carefully about how to leverage the mix to minimize the risk of both systems doing the same work. To that end, one should thoroughly consider the number of transactions the company will transmit on a daily basis, and whether that transaction volume will change over time. Further, every interested enterprise should ascertain whether it has the staffing available to commit certain full-time resources to EDI or XML. Additionally, while the solution's compatibility with the current operating environment is mission critical, the number of trading partners is also crucial. Any EDI/XML solution should be checked to see if it has ever worked with any trading partners. The price structure for adding a new trading partner must also be considered.

Prospective customers should ask all competing vendors to produce the total cost of ownership (TCO) and return on investment (ROI) rationale for a particular deployment. Customers should clarify whether they are purchasing all of the software they need to meet their EDI/XML requirements now, and what the costs for implementation, training, support, and upgrades will be now and in the future. For example, will trading partner updates be readily available for download, or must the customer wait for EDI/XML maps to be changed?