Originally posted on ec-bp.org on June 14, 2008
I’m sure all of you have heard of both the success and failure of companies outsourcing their EDI development and support to offshore IT consulting firms.
REMEDI has been involved with several customers that have decided to take this path. The plan was to have consultants from the offshore company come to the United States to get trained for 6-8 weeks, return to their country, and within a few weeks be able to take over the EDI department.
Unfortunately, they have all failed, and these were not small failures. We are talking huge companies.
It seems to me that companies have failed to understand the importance of the business knowledge that EDI resources possess. I have always said that EDI is 20% technical and 80% business. EDI is technically quite easy. It is the business knowledge of how the data is used and what the data means and the interaction with your trading partner to get the right data that is most important. How can this be trained in two months?
Sunday, November 2, 2008
EDI - Technical or Business?
Originally post on ec-bp.org on July 21, 2008
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.
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.
Subscribe to:
Posts (Atom)
