As I’ve just returned from a trip to Scotland, what topic could be timelier than international EDI? It was tough enough communicating over there with both ‘sender’ and ‘receiver’ using English (we figured that if we could identify one out of five words being spoken to us, we stood a good chance of figuring out the message. That’s generally not a good approach in business). It’s exponentially more difficult when two different languages are involved. The good news is that there are already standard ‘languages’, such as X.12, EDIFACT, and XML, that can streamline the process of document exchange between partners across the world. We didn’t do a lot of international EDI at my previous employer, but we did enough to have allowed us to identify areas of special concern when dealing with partners outside the USA. The beauty of EDI is that there’s usually a document for everything, and as long as there’s agreement on the standards, you can make some progress. That doesn’t mean it’ll be easy. As I mentioned in the past, most of our work was in connecting to customers who wanted to execute the order to pay process electronically with us. Doing that with an international customer in theory should be no different, but there are a few caveats:
- The obvious first question is whether your backend system supports international customers, or if there’s a separate system for them. In some cases, ERPs like SAP handle the entire customer population and have internal configurations to distinguish between domestic and international. In others, entirely different systems are involved.
- What transactions are under consideration? Depending on your order fulfillment process, there may be new entities like freight forwarders, 3PLs, sourcing agents, etc. that require documents you may have never mapped. Again, there’s usually a document to do everything in EDI, it just may be a matter that it’s not familiar to you, and there’s always the question as to whether your ERP system can support it with by sending, receiving, and processing the data.
- Which standard will you use? Europe is big on EDIFACT, while in the US we’re more X.12. If they go with something with which you lack experience, look upon it as an opportunity to grow your skills. EDIFACT has much in common with X.12, and a lot of mapping concepts are similar. Not only will you expand your repertoire, you’ll also give the company another capability they can use.
- Master data may be an issue. Will the customer be viewing a catalog in their own language and transmitting orders in that language? Again, the standards will be there to ensure the information flows properly, but will your systems (translator and ERP) be able to handle data with odd characters (ie. umlauts)? Will units of measure be properly handled? Addresses? Currency? We had difficulty at times with domestic partners’ UOMs, not from an EDI standpoint but from our back-end ERP. Imagine dealing with partners in a country who have a very different group of UOMs they consider to be ‘standard’.
- Business processes may be very different from what you’ve experienced with domestic partners. As I mentioned previously, there may be new parties involved in the document flow, or due to a lack of familiarity with electronic document use perhaps your partner does things on their end that may result in duplicated transactions or other issues. These situations can all be worked through, but the experience you’ve gained in working with many US-based partners may not be very helpful. You need to do a thorough job walking through the processes with your counterpart on the customer’s side
in your analysis.
- Communication may be more difficult due to a language barrier. Chances are the person you’ll be assigned to work with will be able to communicate in English, but as we’ve all experienced that won’t help much if the business contacts and other key people on their end can only speak, for example, Mandarin. Other than bulking up the testing process and running about 10 times the amount of scenarios you’d normally look at (or taking a crash Rosetta Stone course), there’s not a whole lot you can do about this one. The nailing of requirements up front is the key to a successful project, and good communication is the basis of that. If all communication is routed through a single person who is the only one that can be understood, my first three suggestions would be to test, test, test, and the next would be to make sure the business-side people are aware of the constraint and are working to find additional support.
- Obviously, data communication needs to be addressed as well, but that should be relatively straightforward. Most VANs are international, and internet-based communication is ubiquitous.
- Don’t forget the legal side. Whether or not you’re requiring TPAs for your domestic partners, check with your internal legal contact to see if there’s anything special you need to do to prepare for international EDI transaction exchange.
- Lastly, you may be able to use your company’s foray into international business to showcase your creativity. Let me give you an example. At my previous employer, a division was buying products overseas from companies that had no ability to do EDI. This division used a separate system with the ability to generate and receive EDI messages, but was forced to deal with these suppliers using faxes, phone calls, paper documents, and email. We designed and implemented a process to receive the outbound orders from the division’s system, convert them into outbound emails to the suppliers with attached PDF orders along with an embedded link that allowed them to ‘acknowledge’ receipt. The acknowledgments were returned to us and the buyers were then able to manage exceptions. This process totally streamlined what was a very labor intensive process. Later, after the suppliers moved a bit higher up the technology curve, a third-party provider was brought in to receive the orders, provide a web-form display and print capability for the suppliers, and then allow them to fill out the return documents on-line for electronic transmission to our division via EDI. Sometimes it’s more effective to think in terms of ‘process re-engineering’ rather than ‘doing EDI’.
None of the above is insurmountable. The cool thing about EDI is that it’ll work wonderfully for partners across the globe. As with everything ‘e’, the devil is in the details, and this is where the challenge lies. You need to begin on the ground floor to examine every aspect of the integration project to ensure all of the unique details of the new electronic international relationship are accommodated. I can’t emphasize enough the need to completely understand the transaction and information flow between all parties prior to creating your design. That should be the foundation of the approach that allows you to develop a solution that is much more accurate and streamlined than our experience understanding our own language being spoken in our latest European vacation adventure!
As always, any feedback or comments are appreciated. Please email me at This email address is being protected from spambots. You need JavaScript enabled to view it.
