It’s not about supply chain visibility. It’s about Response Management.

JohnWesterveld

I came across the article “Five ‘I’s’ of supply chain visibility” recently and while I agree with the idea,  I don’t think it goes far enough.  According to the author, the five I’s are Interception (listen for events), Interpretation (identify the impact),  Investigation( assess information), Integration (must kick off workflows in other applications), Implementation (must seamlessly layer on top of other applications).  The focus on the article is that visibility is required so that you can know an event has happened.   I completely agree that with the article that visibility is important.   Supply chain visibility is critical in fact.   However, visibility is NOT enough.

Let’s look at an example.

Let’s say that a large shipment of long lead items is found to be defective.   A visibility system would potentially alert you that this event has happened and might even tell you the next higher assemblies that are impacted by these parts. But typically, a supply chain visibility system would stop there.   It’s kind of like the check engine light on your dashboard.   It tells you something bad has happened – and that you are probably going to be spending some money, but it doesn’t give you enough information to resolve the problem.   To solve the problem you need to go to the shop.  In supply chain, you need to go to the ERP system.

So what do we REALLY need.  Well, yes, we need a system that provides supply chain visibility across the entire supply chain, and yes, that system needs to alert us when something has happened, so let’s start with that.

We need;

  • Visibility- We need to be able to see across the supply chain.   We need to be able to integrate data from multiple disparate systems inside and outside the corporate boundaries.
  • Alerting – We need to be able to trigger an alert when some event that we care about has happened. The system, however, should not just dumbly report that some parts are scrapped, but instead should report that event only if it matters.  To do this, we need Analytics – which brings me to my next point.
  • Analytics – If you are to truly understand the impact an event will have, you need to be able to replicate the analytics that exist in your ERP system and your demand management system inside the tool.   Why?  Let’s say that the order we scrapped above is pegged to forecasted demand several periods out.   And let’s say that there is enough time to generate an order and replenish the inventory before these scrapped parts are actually needed.  The event is not really important.  It doesn’t impact customer orders, it’s just an inconvenience in that you need to send the bad parts back and get good parts.  Let’s say now that the next order for a different part is pegged to a customer order worth several million dollars that is now going to be late.  This is an event that we need to deal with NOW.
  • Active Spreadsheets – People are used to working in Microsoft Excel.  It’s a natural feeling environment for analyzing information.  Now, imagine if you could enter a change into this spreadsheet and see results appear in seconds – not just a simple calculation, but instead, actually see the results of full ERP analytics.
  • Collaboration – Often, the person alerted to a potential problem, is not authorized or able to simulate all possible resolutions.   For example, you wouldn’t expect a buyer to change the master schedule, nor would you expect a master scheduler to change a purchase order.    For this reason, you need a tool that allows you to identify the people impacted by the change and collaborate with them to resolve the problem.
  • Simulation – The author  talked about the need for simulation.  In my opinion, this is critical to responding to an event.  We need to try out different alternatives (splitting orders, expediting, finding alternate sources, etc) which can only be effectively done in a simulation environment. We need to be able to share these simulations with others to get their input.  Further,  we need to be able to compare these different simulations side by side.  Something is clearly required that clearly shows which potential solutions  best meets the corporate goals and objectives – this brings us to scorecards
  • Scorecards – Let’s say that for my scrapped part example, I have three different solutions that could potentially resolve the problem.  I can see that for each of the solutions, the customer orders that were late are now on-time.  Great!  Except, one solution used a much more expensive replacement part, another solution expedited a shipment that increased transportation cost, and the third solution borrowed parts from other orders.   How do I see the impact of these three choices?  Which should I choose?  A multi-scenario scorecard would take these three solutions and compare them side by side measuring the impact of the potential resolution on key corporate metrics.  In this example, the first two metrics would result in an increase in cost of goods sold and a corresponding decrease in margin.  The third solution would show as a decrease in on-time delivery and potentially a decrease in revenue for the quarter.  These results, compared against a given target and appropriately weighted would provide an overall score for each solution that the analyst could then use to decide which scenario is best to use.

Now, THIS is a tool that could drive the 21st century supply chain. With a tool like this, it’s no longer just about supply chain visibility, it’s about being able to respond to events when they occur. It’s about Response Management.

JohnWesterveld

John Westerveld part of the Global Alliances team for Kinaxis. He joined Kinaxis over 17 years ago bringing with him 16 years of manufacturing experience, including 10 years in the information technology field. While at Kinaxis, John has held several roles including Product Management, Technical Sales support and Product Marketing.

More blog posts by John Westerveld

Leave a Reply