In daily operations of a business, handling change is not merely part of life, but depending on the way that entity handles those shifts in environment and customer requirements could be the driving factor behind success or failure. We have all heard some form of translation of the philosopher Heraclitus “The only constant is change.” and have learned to at least tolerate this concept in our daily personal and professional lives. With the fact that the order management process being one of the core competencies within a company, and EDI 850’s bring so much efficiency to that process, the pain of managing electronic changes to previously sent purchase orders did not lag far behind. A far more pertinent quote as it relates to the EDI purchase order/ purchase order change process was coined by Arnold Bennett when he said “Any change, even a change for the better, is always accompanied by drawbacks and discomforts. “ Enter the EDI 860.
Past experience across a good sub-section of the EDI delivery chain, the 860 has proven itself to an equal opportunity conundrum. To back up this claim, I feel the necessity here to discuss the unique issues this document poses for the sender and the receiver (as these two are inherently intertwined, as well as the third party service provider/translator.
The main issue that I have seen the 860 to cause in the customer/vendor relationship is the complexity that a change causes in the order fulfillment process. Buyers don’t simply make changes to existing purchase orders for no reason, and when they deem it is necessary to do so they expect the vendor to comply with that change. If the change is not applied, the result could be overstocks or empty shelves which neither is ever good for the relationship. In theory, this should work smoothly, but does a vendor want to post changes to an existing order carte blanche? My experience is that most vendors would respond with a resounding no.
To illustrate the problem the 860 causes for vendors, I would like to take a hypothetical order/change order through the entire process from beginning to end.
- Customer A sends Vendor Z an 850.
- Being a diligent EDI trading partner, Vendor Z has automated their order processing system and applies the order immediately upon receipt.
- Based on that order, Vendor Z begins internal plans of manufacturing, quality assurance, and shipping.
- The next week, the buyer from Customer A re-evaluates orders in process and determines that one of the items on the originating order is going to be well short of needed inventory levels and submits a purchase order change in the form of an 860.
- Vendor Z gets the change request….What to do now????
In the example above if Vendor Z has automated the 860 process, then there is a potential for that change to wreak havoc on the order fulfillment process by changing schedules and inventory allotment without intervention. Another issue that I have seen is the order under the original request has been processed and shipped before the change is received. How is this situation going to be addressed? Across many industries and ERP systems the best solution I have found is to manually process changes to existing orders. While it does deal a small blow to the automation process, manually reviewing and addressing changes is the only way to effectively manage this process.
Now that it has been determined to manually review 860’s, how is the third party service provider or mapping team going to alert the vendor of a received change? The astute EDI department will not advise the trading partner to not send the 860, but will need to work closely with the internal order processing team to determine the best method of information delivery. I have been in environments where the 860 goes nowhere and the EDI coordinator is responsible for monitoring the VAN for receipt of these documents, but the method that seems to work best is for the document to be translated to an HTML format and forwarded via email directly to the order processing team. This method keeps the translation process in place, while also eliminating the possibility of a document being looked over on the VAN’s website.
While it has been well documented that EDI is the standard for B2B automation, the 860 may be the one exception to the rule. There are simply too many variables that are in play that would drive less than optimal results on the supply chain with automatic processing. I would suggest that any change to existing purchase orders be handled with a more hand’s on approach by someone being alerted to a change request, then instead of blindly applying that change, conduct the proper analysis and communicate those findings along with proper expectations with all involved.
Last modified on Friday, 13 January 2012