A very sharp process improvement program manager — he was, admittedly, not a supply chain expert — recently asked me what seems like a simple question: “Is SCOR a noun or a verb?” Being a habitual SCOR user and proponent, I approached the answer in much the same way I would answer the question, “How do you put on your pants — right leg or left leg first?” In other words, I needed to mentally retrace some steps.
SCOR project steps
Supply chain delivery performance
Those who know me can accept the fact that my mind does, in fact, go through those mental steps — and those who've worked with me on a project know that I practice what I preach. After retracing the steps, I concluded that SCOR is a noun. I used one guideline in coming to that conclusion: improvement (savings) needed to be initiated to be considered a verb (Step 2-point 8 and Step 4-point 4). While SCOR metrics have a huge impact on identifying what to improve and estimating the impact, by themselves they will not save any money (point 2 of Steps 1 through 4).
The following is an example of a SCOR project team's journey of turning Delivery Performance data and analysis into real supply chain improvement. The team followed seven basic steps:
1. collect raw data;
There are three questions to answer in gathering raw data. First, what is the operational definition that you will use to query the data? Second, what is an appropriate sampling plan, or how much data is enough? Third, what are appropriate ways to segment the data?
The project team chose one of the literal definitions of SCOR Delivery Performance — “On Time and In Full Delivery to Customer Commit Date.” The challenge that most of the company's current delivery measures focused on line item fill rate at order shipment. Ideally, the team wanted to collect data for all sales orders in the last 12 months, but after some test queries concluded that all sales orders in January and February would be sufficient to represent known variability.
To expedite the data extraction, the team identified several different ways to segment the data (sorting and grouping): by sales order, customer number, customer ship to number, planned shipment date, actual ship date and internal shipping location (source of supply).
Descriptive statistics — characterizing the data
While we have a number for the metric, we have little understanding. There are three questions to answer in assembling descriptive statistics: First, which segments require statistics? Second, what “average” should be used? Third, what is the standard deviation (variability) of the sample?
The project team chose to apply descriptive statistics independently to each facet of the On Time and In Full segments of the measure.
In the case of On Time Delivery, the team concluded that the Mean was sufficient to represent the average and that the data was highly variable, ranging from 53 days late to 51 days early. For the In Full Delivery segment, the team concluded that the Median characterized the average better than the Mean, with this data segment ranging from 552 units short to 17 units over.
This step really initiates the “why” questioning process, and the focus changes from the entire data set to only those data points considered defective. There are two questions to answer at this step: First, what is considered a defective data point? Second, how should the defective data points be grouped and labeled to begin the problem-solving process?
The project team defined as defective any sales order that was either not on time or in full. Using the histograms for both On Time Delivery and In Full Delivery, the team was able to begin the problem-solving process.
While the histogram tells us what is defective, the pareto analysis starts to identify the “why.” There are two questions this step attempts to answer: First, what are the primary categories of defects? Second, what are the biggest problem areas?
The project team started by analyzing and sorting the On Time Delivery defects (using an affinity diagram approach). They then completed the process on the orders delivered On Time but not In Full.
The fishbone analysis focuses on generating a cause and effect summary for each bar on the pareto chart. The results will ultimately lead to the action-result step. There are two questions this step attempts to answer: First, what are the primary causes contributing to a specific defect category? Second, what are the secondary causes to a specific defect category?
The project team divided up the bars on the pareto chart and created 11 fishbone diagrams.
Each primary (and secondary) bone provided the focus for action planning and execution and ultimately performance improvement results. For example, the bone labeled Planning Master Data - Customer Lead Time Settings impacted five orders that were not delivered On Time. Resolution of this issue would have immediate positive impact on about 5% of all orders. Eliminating the Data Settings are Inaccurate bone would have immediate positive impact on 17% of the total orders.
Plan and execute improvements
This step focuses on an action plan required to eliminate the primary and secondary causes (and ultimately “kill” the whole fish). There are at least nine aspects to a good implementation plan:
The project team assembled project charter summaries for each fish (one for each bar on the pareto chart) and initiated immediate action on two. The implementation approach was based, in large part, on the complexity of the change.
The intent of this article has been to provide a summary roadmap of the basic steps of taking a metric through to implementation and results. While SCOR provides a world class cross-industry framework, it does not do the heavy-lifting analysis and problem-solving, nor does it make change happen — that part is up to you. LT
Peter Bolstorff is president and CEO of SCE Limited (www.scelimited.com), which supports “do-it-yourself” supply chain performance through education, coaching and process expertise. He is the co-author (with Logistics Today's Bob Rosenbaum) of Supply Chain Excellence: A Handbook for Dramatic Improvement Using the SCOR Model (AMACOM, 2003). As a member of the board of directors with the Supply-Chain Council, he has been involved with the development of the SCOR model since its inception. He can be reached at [email protected].