If you answered in the affirmative, then please proceed to question number two: Are you mother and father, brother and sister?
I know you've been busy growing the business. But it's time to upgrade the AOL company email address and swap the EDI software in the cash for clunkers deals that EDI service companies offer. Generally, EDI software customers are the most appreciative EDI SaaS customers since they understand, rather than someone new in the business needing service. Let me give you one simple example.
The EDI ANSI X12 860 -- Purchase Order Change document, version 50...who_cares -- it's always different. An EDI Coordinator smiles every time they here those numbers; 8-6-0. It could be a mini-series but it definitely is job security. Because not only is the document syntactically different per customer, the meaning and business rules behind it are different as well. It may generate additional documents, need changes to existing ERP data, and create challenges when coming to invoice creation. Whooo, how long and how much will the quote on getting and maintaining this with several customers cost?
I attended the VCF (Vendor Compliance Federation) West Conference this past week in sunny Scottsdale. On stage were a few major retailers, a distributor, a manufacturer, and business leader from the GS1 association talking about their supplier's challenges with handling the eight sixty. Just in this small group there are several differences on how the document is used:
DSW, retailer: An 860 can mean one of two things -- "replace all with..." or "these are the only changes."
AAFES, retailer: only means "these are the changes to the original order." And AAFES changes the original purchase order 18% of the time according to Brenda Barnett, EDI Compliance Lead.
Genesco, retailer and distributor: also uses the documents when changing out SKUs.
Bugaboo, manufacturer, mentioned, Bed Bath & Beyond division Buy Buy Baby: only uses the 860 to cancel the order then sends another newly changed 850 purchase order.
Further challenges include just understanding the metadata behind the elements in the document. A common misunderstanding is "does that number apply to the original or is it to be replaced?" Data quality is sometimes a culprit and then there is timing of receipt of not meeting a "cancel by" date. Most companies running older ERPs cannot even handle the changes without custom programming and they may never make it a priority to get it done.
Where is the logic in having a full time staff resource fighting the battle individually when the battle has already been won at the EDI service level for thousands of other suppliers to AAFES, Bed Bath & Beyond, DSW, Genesco, and others? This is one example.
B2B EDI is best served on the SaaS server level. Another interesting data point was brought up at the VCF conference by Scott Koegler, editor of the eC-BP.org (eCommerce best practices). Scott performed a recent survey of his readers and found that (I lost the exact numbers -- Scott help me out here) basically EDI user-customers give a short leash and have higher expectations of SaaS EDI provider than EDI user-customer who have their own internal EDI software and staff. Then, in the same survey, EDI user-customers using their own software and resources had higher downtime and longer implementation times.
More to come as I tour the Southern States in the month of December.
- Rob Guerriere, EVP, DataTrans Solutions