My Supplier Said to Me: Let’s Start That Batch Over

On the twelfth (work) day of Christmas my supplier said to me ‘Sorry about that. I’ll go find out what happened, but in the meantime, let’s just start that batch over.’ 

Yesterday, we wrote of the story that is all too common. A supplier screwed up (pun intended), and they’re hoping that you won’t hold it against them. What you do at this point is really up to you depending on the needs of your business. 

Whether the batch is scrapped and the cost of covering it becomes a football that is being tossed back and forth until an agreement is reached, or the supplier does the right thing and just eats the cost without much fuss, it doesn’t really matter. Let’s talk about the conversation to resolve the root of the problem. 

An RCCA is a Root Cause and Corrective Action discussion. It’s a broad term used to describe a conversation– not just a transaction or blurb, but a complete conversation between two parties – between company and supplier. Its purpose is to do collaborative investigation research to determine the root cause and formulate a plan to prevent it in the future, and it is not supported by EDI.

Though unsupported, it’s an incredibly important part of an overall continuous improvement strategy where issues are analyzed, and process improvement is made based on analytical results. So, RCCA is much more than a blamestorming session, RCCA is a cooperative conversation between company and supplier in order to resolve a problem.

RCCA involves containment of the issue in both the company and supplier environments so that the scope of the issue is controlled, the impact is limited, and the costs are managed. Utilizing RCCA brings about long-term quality improvements and is a critical element of b2b collaboration. 

Once again, we see where EDI, though it has stood the test of time, is limited in its capacity to meet some of the needs of modern business communications. How do you handle RCCA communications? Phone? Email? Webex? Something else? Let us hear your thoughts, we would love to know what works for you when EDI doesn’t…

My Supplier Said to Me: Just Use Different Screws

On the eleventh (work) day of Christmas my supplier said to me ‘are you sure you can’t just use new screws that fit the thread in the parts we already sent?’ 

Specification issues arise in all sorts of shapes and sizes. Some are big issues and make you pause to ask how it’s possible that the batch was shipped. Other issues are so small it’s impressive that they were ever discovered. 

An incorrect thread cut into a screw hole is one of those things that is almost never discovered until the part that it lives in is installed. After the manufacturing tech encounters the issue on the assembly line, an inventory check is commissioned which reveals that the entire batch has screw holes that are out of specification. 

Clearly, this is a quality issue. So, what now? You can send an angry email, an RMA, or a Supplier Corrective Action Request, or you can buy different screws that resolve the problem without stirring the pot. If you opt for the last option, who is going to pay for the new screws and how is that going to ensure that this issue doesn’t come up again? The answer, of course, depends on how tightly you want to abide by your parts diagram and whether or not your process allows for part substitutions.

This issue, so small as screw threads, has now caused a ripple effect and is now impacting other parts as well as costing hundreds of dollars in parts and time to make up for the mistake. Even if it’s just a different screw, the problem resolution must be documented and handled appropriately so that when someone needs a replacement part, they can find the correct one. 

Even for something that appears so insignificant, you may need to execute a part purge and at the very least an RCCA discussion with your supplier, which is now completely outside the realm of EDI. How do you handle your RCCA communications? 

My Supplier Said to Me: New Specifications?

On the tenth (work) day of Christmas my supplier said to me “oh… well, uh, when were those specifications issued?” 

Changing specifications are just a fact of life in the world of manufacturing. In the software world we used to say, ‘requirements are like water; they are not firm unless frozen.’ Screw holes are moved, bolt patterns change, and weight is reduced. This is part and parcel of manufacturing. If your supplier makes and delivers batches of the same part throughout the year it is almost guaranteed that at some point that they will have to deal with a specification change. 

How you communicate that change matters almost as much as the change itself. To keep up with the fast pace of change in today’s business world, we must transform the way we think about supplier communications. No longer is it about just managing suppliers. The goal here is collaboration, not just obedience.

When there is a change in specification, proactive communication is critical. Communicating ahead of time gives your suppliers plenty of notice to make changes between production runs. This cuts down on waste and stress for everyone involved. 

Collaborating with suppliers to work for the greater good of all instead of just tolerating each other helps to develop strong relationships with your suppliers. The long-term benefits of these relationships are increases in quality, efficiency, and customer service, and who doesn’t like better customer service? 

The reality is that to be successful, your suppliers need information from you. When they are successful you are successful

But what about when non-EDI trading partners need to receive updated specifications? What about when a supplier communication needs to include documents that don’t exist in classical B2B EDI? One of the main barriers to achieving true b2b collaboration is that without B2B eCommerce infrastructure, important supplier communications are easily lost. ‘When did you issue those new specifications?’ the supplier asks. ‘Well before you started the current batch. We can’t accept these’ you respond. Now begins the reject process…

My Supplier Said to Me: Just in Time Delivery?

On the ninth (work) day of Christmas my supplier said to me “We are working on it, but when do you REALLY need that Just in Time delivery?”

The answer to the question in the title is, of course, Just in Time. Inventory management is critical for modern supply chains. The longer that parts inventory is held by your company, the more money it costs. If parts deliveries are early then inventories can pile up, and the cost of maintaining that inventory stock increases with it. Conversely, if those deliveries are late then you could have to halt production. 

Either of those situations are bad news for a manufacturing company, and if the supplier has to ask when the Just in Time delivery is, that’s a bad sign. 

Maintaining inventory is a delicate balance. The general rule of them is that the less inventory you’re keeping in stock the better. 

Learning to recognize the signs of potential issues and correcting them leads to fewer early or late deliveries resulting in lower costs and more consistent forecasting. Supplier communications are key. Don’t just send an email assuming that it was received, and everything is moving according to schedule. You need structured, process oriented b2b communications if you want to operate with efficiency and effectiveness. 

Let’s look at the example of charge backs and penalties for deliveries made outside of the Just in Time delivery window. Chargebacks can occur for a variety of reasons, but they’re particularly common for just in time delivery infractions. In fact, the number one cause of a chargeback is not receiving an ASN on time. This is a huge reason to make sure that your suppliers are electronically enabled. 

This brings us back around to the first post in this series. When your suppliers aren’t compliant with your standards it is really difficult for you to enforce just in time delivery standards because you have no way to verify that mission critical business documents are being sent and received on time. 

How are you enforcing your Just in Time Delivery standards with your non-EDI suppliers? 

My Supplier Said to Me: Uh, We Just Finished That Batch

On the seventh (work) day of Christmas my supplier said to me “We just finished that batch. I’ll have to start a new one to make that change.”

You just want to issue a quick change-order, but you’re too late. Just as they receive the notification, they have just finished the batch of your parts. Well. Now what? They want to start a new batch. Who will pay for the scrap from the first batch? 

Communication with your suppliers is critical for maintaining a fast and efficient supply chain. 

If the supplier was given advance notice via an EDI 860 transaction set that a new specification was on its way, then the whole situation might have been avoided. Normally, the supplier is only responsible for making parts that are compliant with the specifications they receive at the time of the order. This means that the lack of structured supplier communication has resulted in you as the customer covering the cost of a new batch or trying to find a work around that allows you to use the newly out of spec parts. 

If new specifications are received after production begins, then the cost of halting production and retooling is owned by the purchaser of the parts who sends the new specifications. There is no ethical dilemma here. It is the right thing to do. It still costs money, and that comes out of your company’s profitability. 

So, what is at the root of this problem? I’m glad you asked.

Emails are lost and phone calls are missed. People are busy. When schedules do not line up and supplier communication is not standardized, production can continue for days before your change-order is received. 

What’s the bottom line? You need your suppliers to be tightly integrated so that you have both process and visibility in your communications in order to make these incidents much less common. 

How do you manage change-orders with non-EDI suppliers? 

%d bloggers like this: