Why does every EDI department experience Forensic EDI?

First off, we need to define Forensic EDI.

Forensic EDI is having to reinvent the wheel when the completed wheel is in front of you, operational, and to take this analogy too far, does not have a flat.

So Forensic EDI is having to redefine a process in your system because there is no documentation telling you how it works, why it works, who asked for it, and a number of other possible reasons. Suffice to say, if you have a person on your team who contacts a trading partner, spend days...weeks....maybe months creating elaborate inbound and/or outbound processes that work perfectly; then they leave the company abruptly and someone else is handed the project to attempt to understand it to add a new trading partner or entity but there is ZERO documentation and that person is in longer available to ask questions of - then you have experienced Forensic EDI.

I cannot tell you how to perform the analysis, or how to understand your system, but I can tell you how to avoid it. One simple truth, one simple word. "DOCUMENTATION"

Microsoft Word in this instance is your BFF. As you develop, test, rework, test, and finally get it to do what you need for it to do, you can avoid Forensic EDI in the future by simply putting pen to paper, or in this case fingers to keyboard. Screenshots are worth reams of paper and drawing little arrows to the items in the screenshots with a text box explaining what the reader is looking at is like gold-pressed latinum (a reference for the other Star Trek fans out there).

Lastly, once the documentation is created, have a fast meeting with your team and explain it. Nothing worse than learning the documentation makes no sense. Rewrite it if needed, but put the documentation into a public, or at minimum a shared drive where your other team members have access to it.

EDI is not a secret code. EDI is not something you keep to yourself because if no one else knows what I know, I can never be laid-off. That is a false idea at the highest level. I have worked with people like that in the past at many previous companies. They were let go, I showed up and had to do deep research to try to understand what they did. Some actually created an easy-to-understand system, while others created a convoluted series of alias' that seemed to lead nowhere, so a support person would need to contact them in order to correct an error.

Personally, I like this aspect of EDI. I enjoy creating the documentation of a system that I have no idea about. Once I am finished creating, I pass it on to someone in the department to ensure that it not only makes sense as written, but it also makes sense as related to the connections, network, and systems.

I am a huge fan of making certain each and every person I am working with knows what I know. I had a saying that I like which I heard from a former EXCELLENT manager I had, (hi Hank), we used to say:

Document it, I may get hit by a bus and you may need to know it!