Estimated reading time: 3 minutes, 45 seconds

Keep the Change

coins 

 

When a partner asks you to accept his PO Change (860), what are the options if that document is not part of your program? Well, you can:

      
  • Tell him ‘no’ and recommend calling in PO changes to your customer service desk, or
  • Tell him “yes’ and figure out how to automate or manually process the 860, or
  • Tell him there’s a lot of development required that will take considerable time and hope he forgets about it.

With the first alternative, you run the risk of the customer focusing on the word ‘no’ and holding that against you as a supplier. Otherwise, it’s a perfectly reasonable approach and one we used successfully on many projects. The second is what the customer wants to hear, but puts some pressure on you to make the outcome work on your end. We used it when we had to and opted for manual processing. The third may buy you some time, but customers rarely forget a commitment. I can’t ever recall going in this direction, but I bet it’s been tried before.

Obviously, you want to support your partners, and changing a PO is a fairly normal part of the business process. However, electronically modifying a ‘live’ business transaction can be a tricky proposition. Lots of moving parts are involved. Here are a few things to consider.

  • The message. You need to make sure you completely understand the nature of how changes are communicated in the document, the meaning of codes, etc. If you’re attempting to automate the process, it’s obviously critical. Even if you expect to handle the change manually by converting the 860 to a human-readable email or other document, you’ll still need to be able to communicate exactly what needs to be done.
  • Your ERP’s capabilities. To automate the processing of the document, you’ll need to work closely with your ERP team to see whether it’s doable in the destination system. You must investigate how the application file is constructed for changes, what the allowable timing is relative to the processing stage of the original PO within the order flow, and what happens if a change is put through that can’t be applied to the original. This is a very challenging part of the analysis.
  • The EDI document flow. Does the customer expect an acknowledgment back of some sort? If so, do you have the capability to create it either automatically or manually to meet his requirements?
  • Your business model. If your customer is ordering direct materials with a fairly long lead time, then it’s possible the PO Change won’t cause you any heartburn from a timing standpoint. But if you process electronic orders quickly and ship them immediately, then the timing of subsequent changes will be problematic. Additionally, if you dropship from other suppliers and therefore kick off additional transactions from the original purchase order, you’ll also have challenges.

I wish I could tell you we had fully automated the 860, but we didn’t even come close. We took a shot at it when we established our program at another company division back in 2000. However, we had major issues with the 860 relative to our business model, which not only depended on quick shipping of product but also had a high percentage of dropshipped items.

We later experienced similar issues with our corporate program when we took the initial steps to evaluate the automation of the PO Change. We were a victim of our own success: by processing, shipping, and dropshipping so quickly, we were unable to provide the automation on the 860 we enjoyed almost everywhere else. A bit disappointing, but it’s generally understandable to our customers. Our default approach when asked to support the 860 was to gently persuade the customer to contact our customer service center for changes, but if they must send the 860 we’ll accept it and direct the contents via email to that same service center.

The PO Change is a transaction that’s been difficult for us, but I can see where it’s perfectly logical for some companies to expect. Unless it’s high volume, though, it wouldn’t seem to require full automation. In fact, it’s almost something you would want a human to view and interpret before taking action. Although the vast majority of people in our profession consider themselves highly supportive of fully automating every possible transaction, this is one where human intervention may be desirable. What are your thoughts?

Enhanced by Zemanta
Read 4096 times
Rate this item
(0 votes)

Visit other PMG Sites: