ec-bp Bloggers |
Sep 14
2008
|
Is EDI Owned by IT or the Business?Posted by Ken Kinlock in management   |
|
The recent post by Tracy Loetz: "Technical or Business?" and the post
by Mike Kelly on "Maximum Overdrive" were great and are serving to set
the stage for me to talk about my favorite hot button: WHO OWNS EDI IN
A COMPANY.
We have three choices:
(CHOICE 1) assign EDI to the business function that receives the most benefit.
This makes sense since they will probably end up paying for the EDI function even if we pick choices 2 or 3.
(CHOICE 2) assign EDI to the Information Systems function (or whatever their current buzzword is this year: IT, MIS). Well, EDI seems a little technical on the surface so let's just put it with other technical groups.
(CHOICE 3) assign EDI to a neutral third party. I'll suggest Finance only because I have been there and done it.
Like Tracy, I too was a member of a team that not only did the EDI maps, interface programs, and support; but attended business meetings to understand how each group operated, so we could communicate with the World. Better than being part of a huge all-day IT meeting on how to make everybody's job description look alike.
Recruiters present an unusual problem filling EDI jobs. If the hiring manager is in an IT function, the recruiter is too used to "more traditional" MIS jobs and most cannot ask the right questions to get the right people. Instead, they resort to enumerating candidate software and document experience (does an 856 rank as highly as a 997?). But if the hiring manager is in a business function, the recruiter does better because today's EDI software does not require a "techie".
Mike's story reminds me of an encounter with the MIS VP (yup, he owned EDI and paid my fees). He could NO WAY understand why a pilot trading partner could not just generate an ASN for us so we would not fall behind our development schedule. The VP of Supply Chain understood easily: "You guys are asking the supplier to send a document for something he is not shipping till next week. Just so you can make a tick mark on your progress chart."
In today's environment, the link between technical and business knowledge is stronger than ever. EDI has moved past the world of COBOL and JCL (thank goodness! I could never get past the "Identification Division" in COBOL).
Time to get EDI out of monstrous MIS empires and join with the organizations we serve. Yes, we can even split the EDI "department" and abolish a mini empire. How about "Buy-Side EDI" and "Sell-Side EDI"?
We have three choices:
(CHOICE 1) assign EDI to the business function that receives the most benefit.
This makes sense since they will probably end up paying for the EDI function even if we pick choices 2 or 3.
(CHOICE 2) assign EDI to the Information Systems function (or whatever their current buzzword is this year: IT, MIS). Well, EDI seems a little technical on the surface so let's just put it with other technical groups.
(CHOICE 3) assign EDI to a neutral third party. I'll suggest Finance only because I have been there and done it.
Like Tracy, I too was a member of a team that not only did the EDI maps, interface programs, and support; but attended business meetings to understand how each group operated, so we could communicate with the World. Better than being part of a huge all-day IT meeting on how to make everybody's job description look alike.
Recruiters present an unusual problem filling EDI jobs. If the hiring manager is in an IT function, the recruiter is too used to "more traditional" MIS jobs and most cannot ask the right questions to get the right people. Instead, they resort to enumerating candidate software and document experience (does an 856 rank as highly as a 997?). But if the hiring manager is in a business function, the recruiter does better because today's EDI software does not require a "techie".
Mike's story reminds me of an encounter with the MIS VP (yup, he owned EDI and paid my fees). He could NO WAY understand why a pilot trading partner could not just generate an ASN for us so we would not fall behind our development schedule. The VP of Supply Chain understood easily: "You guys are asking the supplier to send a document for something he is not shipping till next week. Just so you can make a tick mark on your progress chart."
In today's environment, the link between technical and business knowledge is stronger than ever. EDI has moved past the world of COBOL and JCL (thank goodness! I could never get past the "Identification Division" in COBOL).
Time to get EDI out of monstrous MIS empires and join with the organizations we serve. Yes, we can even split the EDI "department" and abolish a mini empire. How about "Buy-Side EDI" and "Sell-Side EDI"?
Set as favorite
Bookmark
Email This
Hits: 1302
Trackback(0)
TrackBack URI for this entryComments (1)
Subscribe to this comment's feed
Sales Compliance Manager
written by Julie Traverso, November 11, 2008
written by Julie Traverso, November 11, 2008
Thank you for your post. I am the non-tech/business funtion role that oversees EDI in our company, stemming from a reorganization a couple of years ago that lead us to ask ourselves these very same questions. Since EDI is really just a communication tool and even a value added service for our customers, the process fell onto the Sales Operations team to understand and oversee, working with our 3rd party ERP and EDI provider. And yes, I gather and read those vendor compliance guides too. We are the first point of contact for our new and existing trading partners, working with our IT, finance, customer service, and fulfillment teams. It works...and we have very few chargebacks to prove it!
report abuse
vote down
vote up
Votes: +0
Write comment
