Step 4: Develop a Business-Focused EDI Solution

The results of the analysis step provides an organisation with the knowledge to develop a comprehensive specification for the EDI system. This includes:

• The volume of expected EDI traffic and the IT infrastructure needed to support it
• The capacity of internal network infrastructure to support EDI data
• The network connections needed to manage traffic with trading partners
• The programming required to ensure that internal systems comply with the data required by trading partners and with EDI standards
• The amount of customisation required to integrate internal and EDI systems

With this information, an EDI system can be designed. There are two particularly important elements to an EDI system: the EDI translator and the communications model.

The EDI Translator

Usually a package licensed from an EDI software company or EDI VAN provider, the EDI Translator’s role is to interpret the EDI information it receives from the sender and translate it into a format that the receiver can accommodate. In addition to its primary function, an EDI Translator often has several sub-systems, including the handling of the EDI envelopes, document management, audit trails, compliance checking and functional acknowledgements.

The Communications Model

One of the decisions you need to make is the type of communications you will need to connect to all your partners. There are four basic approaches: 

1. Connect directly to each one — this works well for connecting to a small number of trading partners. Your organisation is responsible for all mapping, translation, technical support and reporting. As long as everyone agrees on a single connectivity protocol, e.g. FTP over VPN, Rosetta Net, Odette FTP, AS2, a single document format and the community size remains relatively small, this approach works well. This is how EDI was handled in the early days. However, as the size of your community grows, it becomes a very complex and resource-intensive approach.
2. Use an EDI Network provider — The EDI Network provider facilitates the exchange of electronic documents via its “document mailbox” service. The sender connects to the EDI Network and sends its EDI transactions to the recipient’s mailbox. The receiver then connects to the network to receive documents in its mailbox. This approach relieves all community members of the resource-intensive responsibilities for supporting all communications issues, ensures data security and non-repudiation, while providing audit information, reporting, backup and recovery. This approach avoids many of the complexities of the direct model. Use of the EDI Network/VAN model for 100% of an EDI community was extremely popular before the rise of the commercial use of the internet and large trading networks. It remains a very popular option, but for very large communities it’s much less common to have 100% of the trading partners on the EDI network.
3. Use Direct Connects for your high-volume trading partners and use the EDI Network for the rest — This approach saves the transaction fees charged by the EDI Networks when trading with the high-volume trading partners, while relying on the EDI Network to support the high number of low-transaction volume partners. 
4. Outsource the EDI program to a Managed Services provider that connects to your entire community on your behalf — The Managed Services provider receives your business documents directly from your ERP system (SAP, Oracle, etc), assumes responsibility for all the mapping, translation, technical support, data center operations and reporting. Once documents are ready for delivery to your trading partners, the service provider delivers them either directly to the partners or via the mailbox service, depending on the individual trading partner requirements.