1) Unrealistic implementation timelines.
Unless you are implementing a transaction set with a sister division of an existing customer, proper testing can take a couple of weeks. Analyzing the customer’s requirements and evaluating your company’s ability to meet those requirements are just the start and does not need to be rushed. Even when that is done, system configuration on your end as well as your VAN needs to occur, and translation maps need to be created to handle the documents. Just getting set up to receive the tests can take a week.
2) Inadequate testing requirements.
It always makes me nervous when a testing partner only asks for a 997 to complete testing. There are just too many scenarios that could occur on the inbound and outbound documents not to at least run one order completely through the process to ensure all pieces are in order. Another example of this is customer’s putting canned test data on a web portal. Not using actual SKU’s or shipping locations, limits both sides to adequately test the process, and usually results in only testing the EDI person’s ability to manipulate data.
3) Business misunderstanding of data flow.
In our current business environment, instant message delivery is an expectation. Instant messaging and email have made that level of communication commonplace, but it is important to understand that EDI may not be as instant. While direct AS2 connection between the two parties can go a long way in speeding up delivery, when a VAN interconnect is used there could be delays of 30 minutes or more depending on all the number of interconnects the document needs to travel through. I always like to use the hour buffer to set proper expectations.
4) Customer’s who take liberties with EDI standards.
Recently I was presented with a customer’s EDI specification that totally ignored ANSI X12 guidelines. Instead of using the N4 segment to relay city, state, and zip code information, they insisted this information was going to be sent in the N3 segment with the different elements separated by commas. These kinds of liberties put the receiving party behind the eight ball to meet their customer’s needs. Not only do they now have to go through the normal testing process, it is likely that they will also need to install custom code in their translator, maps, ERP, or all of the above. Since telling the new customer that they are violating EDI standards may be a difficult conversation, proper time and resource considerations needs to be taken into account.
5) Special Characters.
Last but not least (and the most common cause of me having a headache) is the infamous special character. EDI makes use of characters such as <, >, *,|, and ; (to name a few) as indicators that there will be a new field, or new data set coming up. Since characters can be used as segment separators and terminators, having one randomly show up in a free form message field or product description will invariably cause document level exceptions that will halt the transmission of the document. While it is nigh impossible to account for all of the characters, it is advisable to work with your product management team to set item descriptor standards which limit or eliminates the use of those characters. Even if your EDI team puts measures in place to handle an asterisk in the EDI, your trading partner may not have done the same and the document will then fail on their end.
While it is true that every part of business faces its’ own unique set of challenges, understanding of these, proper communication, and planning can be a great benefit to your overall EDI program.