As I was thinking of a topic for this blog, I focused on some of the things that I tend to get heated about in the EDI consulting world. That didn’t take but a few minutes…
EDI is still considered a technical process rather than a business process.
Why do I say this? The vast increase in the number EDI consulting firms, the ad content for EDI positions on Monster and DICE, and the calls our company receives.
I have been in the EDI field for 19 years and over time I have noticed the separation of EDI technical skills and EDI business skills. When I started in EDI, I was a member of a team that not only did the EDI maps, interface programs (COBOL & JCL – I’m dating myself!), and support, but we attended business meetings to understand how each group operated, so we could communicate the information via EDI. I understood how products were packaged for shipping and why they were shipped that way, I understood what products were dropped shipped and why, and I understood what we were trying to accomplish with each document.
As companies cut costs, they are looking to outsource the technical EDI work without consideration for the link between technical and business knowledge. EDI is collaborative and cannot be segregated from the business.
