When it comes to EDI integration here are five common mistakes we have seen over the years. I am sure there are others but these are ones we see regularly.
1. Assume the EDI implementation guide is always 100% accurate. It’s amazing the number of people who believe that what is in the EDI implementation guide is gospel. The reality is that it is only in the very largest of companies, with a dedicated EDI group, that guides are kept 100% current. It’s when we see the EDI and actually start testing with real data or are in production that the fun begins.
2. Assume that because you have tested with an outside third party that you are 100% setup and ready to go. Third party testing has become a huge industry because in the early days of EDI it was all about syntax. Today it’s all about data. A good EDI translator should have no issues generating syntactically correct EDI. Its poor data that will kill you each and every time. Unfortunately third party testers don’t test with real data they test for syntax and that’s a mistake.
3. Trying to develop your own translator. I could write volumes on this. We see this all the time. A company has an in-house IT resource who looks at the implementation guide and says hey I can program an interface for this transaction or these transactions. The reality is that every implementation is different and by the time the in-house IT resource has finished the company ends up with a far more costly solution made up of cobbled together code, more than likely undocumented and difficult to maintain when something changes. Heaven forbid that resource ever leaves the company or is let go. It’s far cheaper to buy a good software platform than it is to build your own.
4. I am technical I can do it all myself! This is one we see regularly. EDI and data integration is not rocket science I acknowledge that. But would you try and be your own gas furnace technician, or do your own eye surgery? We would all answer no and find an expert. So why is EDI integration different? Does it not make sense to hire an integration expert, get it done right or at the very least get the system and the data flow laid down correctly? In the long run its cheaper, less time consuming and you get a better system.
5. Finally the one I like the best. The battle between the purists and the pragmatists. This week, on one of the LinkedIn EDI groups, there has been a raging debate over whether the translator should do any sort of data manipulation or whether all logic should be in the ERP system or whether it should outside of both. The reality is that there is no ERP system that is perfect and in most data import and export has been an after thought. There are exceptions of course. What can be done in the ERP system should be done there and what cannot be done in the ERP should be done in the translator. To say categorically that it should be in one or the other is a mistake. Be flexible I think its a better approach.