When Your EDI Expert Walks Out the Door - What Stays Behind?

The day your EDI developer leaves is the day you realize that all of your EDI mapping knowledge left with them. Often the sole domain of a single person, EDI mapping can easily disappear out from under you, leaving you in a bind.

What Is Actually in an EDI Map?

Even though the mapping may look technical and possibly confusing, the reality is that it includes deeply integrated business rules that translate and map your partner's business logic onto yours. Different trading partners have their own quirks or tendencies, and the EDI mapper distills all of these into a single map per document that allows data to flow seamlessly in and out of your system. Not to mention the crisis band-aid solutions that quietly became permanent.

Why EDI Documentation Rarely Exists

Often the mapping is built on the fly and with deadlines in mind. The rules are tweaked and adjusted as testing progresses. When the final product is complete, the mapper will usually think that if changes are needed later, they will be the ones to make them. Since they built the map, that won't be a problem. Most mapping tools are built for speed and functionality, not for explaining the logic behind the decisions.

The Turnover Trouble

When the lead resource is no longer with the organization, that is when teams discover how complex it is for someone else to reverse engineer a map, figure out the nuanced logic, and adjust one piece without the entire house of cards coming down. Even though the map may work seamlessly, adding an extra segment or requirement can throw a wrench into the whole setup. One new requirement could cause the entire map to be redone if it is not properly understood by the new EDI analyst.

What a Better Scenario Looks Like

Several practices can make maps easier to understand, simpler to change, and more future-proof:

• Standard naming conventions - Having a documented standard for how rules are named - whether related to the source data, the destination data, or something else - makes it easier to locate the exact place changes need to be made.
• Clear rules - Inline commenting and rule documentation allow the next person to understand the logic and make adjustments quickly.
• Trading partner specs and rules - Keeping the original trading partner specifications and documentation organized helps explain what the partner required and what the expectations were when the map was originally created.
• Version management and test change logs - When a change is made to the map, documenting why it was made and confirming the testing performed helps the next person responsible understand the map's current state.

Take it from someone who has had to decipher a lot of EDI maps, and has probably left a few in their wake for others to decipher. A small investment of time up front to improve clarity pays dividends when maps suddenly get handed off and require an urgent update.

Think of your EDI maps less as technical files and more as a record of your business relationships - one that only has value if someone besides the original author can read it.