What is a map? Most would answer that it is a collection of relationships between a source document and a target document. This implies that the relationships are at the data-item level. But, isn’t it true that a map, at its essence, is a repository of business knowledge showing the relationship between business elements?
Let’s consider a small company in the United States supporting the Order-To-Cash process. As the company grows, it realizes that it will greatly benefit from the efficiencies of exchanging EDI (ANSI X12) with its trading partners to process orders, send out shipment notices and submit invoices. So, it implements EDI using X12 documents.
Then, the disruptive business event happens. The company expands their market penetration into Europe and begins trading with European partners. But, there is an immediate challenge. European companies typically do not trade using X12. The European standard is EDIFACT. The company now has to accommodate this new standard. To further complicate matters, customers in the United Kingdom want to exchange EDI using TRADACOMS and EANCOM. Finally, pushing the EDI team to the brink of desperation are the customers from Asia-Pacific (APAC) that do not use any EDI. They want to exchange flat-files, XML or even more daunting…spreadsheets.
This scenario would cause great stress in any IT group. But, let’s think about the challenge from a different perspective. Going back to the idea that our X12 maps are repositories of business knowledge, can we leverage that knowledge to help us accommodate the business needs of the company’s growth?
The answer is yes. If we could create relationships between our X12 document structures (schemas) and the new document formats, it is possible to “transform” the actual maps into new maps. This is exactly what the Migration Assistant in the EXTOL Business Integrator does. It is far easier to create relationships between two similar documents (X12 850 Purchase Order and EDIFACT ORDERS) than to create actual data maps to move data between two dissimilar data formats. If a migration tool that could accomplish schema-to-schema migration were available, the challenge shifts to become a mechanical issue and may just require minor adjustments to bring the support for new formats online. Reducing the complexity of the migration process also speeds time to market and greatly reduces risk because the company is re-using their proven business knowledge.
EDI as we know it today is very different from what it was 10 or 15 years ago, when many companies made their last EDI technology investments. Today’s businesses face a broader range of EDI requirements, including the ability to support proprietary document interchanges, near real-time transaction response, and web services.
When we talk with prospective customers about how they cope with new EDI integration requirements, the answers boil down to these five approaches: Continue reading
When you’re replacing enterprise systems…
Remember the alphabet: “EDI” comes before “ERP”
Many organizations facing enterprise-wide systems upgrades link the EDI and ERP systems selection processes, even though this approach may end up taking more calendar time and exposing the organization to greater risk. My colleague Jim O’Leary has reminded me that some organizations value the “interface compatibility” resulting from a tandem decision, and his point is valid. However, there may be other benefits to implementing EDI first, benefits that may be much greater than that of interface compatibility (which is often an ERP system issue). Continue reading
I recently sat down to interview Nahid Jilovec on the subject of her recent white paper, “Replacing Legacy EDI Systems“. In this brief (less than 15 minute) podcast, Nahid reviews the business drivers and technical advances that are motivating companies to extend or replace their aging EDI infrastructures. She also identifies the main implementation strategies available, summarizes the advantages and disadvantages of legacy replacement, and makes a strong case for strategic consideration of future business integration needs.
If you haven’t yet read Nahid’s paper, or are looking for a condensed overview of this topic that you can send to a colleague, click here to listen, or right-click on the link to download this informative interview to your MP3 player.
And if you’d like to suggest a business integration topic for a future EXTOL podcast, just reply to this post or drop us a line at firstname.lastname@example.org.
Electronic data interchange (EDI) has been around since the late 1960’s and has been adopted by thousands of organizations since that time. Many of these organizations purchased or developed their back-end software systems and communication methods with the intention of supporting EDI. Not only were the back-end systems and communication methods “EDI-centric”, but organizations also needed to purchase or develop programs to translate the EDI data to and from their applications and data. Because EDI has been around for decades and because many of these older systems were constructed for EDI, the word “legacy” tends to come up a lot when referring to EDI. In reality, EDI is a mature technology that is utilized by older systems, but it isn’t outdated. It is the hardware and software systems built around the EDI data that are becoming legacy, not EDI. In fact, thousands of organizations are currently implementing EDI for the first time. Some of these organizations may have to implement EDI because of new relationships with other organizations that mandate EDI (new trading partner relationships) or they may decide to use and implement the EDI as a canonical model for their application-to-application (A2A) initiatives as discussed in Mark Denchy’s blog, Canonical models, not just your ordinary middleman . No matter the case, EDI is a proven interchange model and not going away anytime soon.
Now that we identified the fact that EDI is still a viable option, what can we do to “modernize” it? We can do this a number of ways, from changing the back-end software and/or hardware systems to implementing tools to improve the way the data is processed. But first, let’s start by enhancing the definition of EDI. EDI can be defined as the electronic transfer of standardized structured data from one organization to another to enable business-to-business (B2B) collaboration. This definition provides more meaning than the traditional “legacy” definition, being the computer to computer exchange of structured information, that some of us are more familiar with. Continue reading