Operations Design

SCOR Model

The SCOR model is a reference for supply chain performance across plan, source, make, deliver, return, and enable.

The questionWhere is this supply chain losing performance, and which processes should we redesign first?

Supply Chain Operations Reference model. The current edition is called the SCOR Digital Standard (SCOR DS).

Model · Supply Chain Council, now ASCM, 1996

Plan Balance demand and supply
Source Procure and receive goods
Make Create the product or service
Deliver Fulfill customer orders
Return Reverse flow from the customer
Enable Govern the supply chain as a whole

Simplified list of the six process families in older SCOR editions. The current edition uses different names.

When to use it

A supply chain function cannot agree on process names or boundaries, and every project starts by redrawing the same map.
You need a structured baseline of supply chain performance before deciding which processes to redesign.
Two supply chains, from a merger or from two business units, have to be compared process by process.
The client wants performance measured with standard definitions so that results can be compared with other companies, where data exist.

When to avoid it

The problem sits in one link, such as a late supplier or a single warehouse. A SIPOC or a root-cause method gets there faster.
The question is how to buy a category or how to treat a supplier. The Kraljic matrix is the more direct tool for that.
The client has not decided what the supply chain is supposed to compete on. SCOR describes and measures operations and does not choose the strategy for you.
The team is likely to copy the standard's process list and practice library as a target design. The model is descriptive, and its detail was not written for your business.

Overview

SCOR is a reference model for describing a supply chain in a shared vocabulary: standard process names, defined performance measures, and a library of practices. It supports the choice of which parts of a supply chain to measure and which to redesign, and it gives two sites, or two companies, a common basis for comparing themselves.

It is descriptive, not prescriptive. The process list tells you what a supply chain usually does, not what yours should look like. The content belongs to ASCM and has changed form over time, from six processes in older editions to a seven-part structure in the current Digital Standard, so say which edition you are using.

The process families

Plan

Balancing requirements against available resources to produce a plan for the supply chain, including the plans for the processes below. This is where demand and supply are reconciled, so late or competing forecasts show up here.

Source

Procuring, ordering, scheduling, receiving, and transferring goods and services. This is the process that sits next to a category strategy such as the Kraljic matrix.

Transform

Scheduling and creating products and services, including production, assembly, and repair and overhaul. It is the successor to Make in older editions, widened so that it fits service providers as well as manufacturers.

Order

Handling the customer's purchase, including pricing, payment terms, and order status. Older editions had this inside Deliver.

Fulfill

Executing customer orders, including scheduling delivery, picking, packing, shipping, installing, and invoicing. Together with Order, it replaces the older Deliver.

Return

The reverse flow of goods and services from the customer, to diagnose the condition, decide entitlement, and send the item back into the supply chain. It is often the least developed process in a client's map.

Orchestrate

Connecting and governing the supply chain as a whole, including business rules, performance management, data and technology, network design, contracts, risk, and compliance. It roughly corresponds to Enable in older editions, and in the current model it sits above the other processes.

What it is not

A prescriptive template. SCOR describes what supply chains usually do, and it does not require every process or practice to be carried out. Teams adapt or skip lower-level processes.
A set of departments. The processes cut across org charts, so map by process and not by function.
A model of the company. It is applied to one supply chain at a time, defined by a product and customer combination, and a company with several product lines has several.

The steps

Define the supply chain in scope

Choose a product family and a customer segment, not the whole company. If the client sells several product lines, expect several supply chains and pick the one that matters most.
Map it at the top levels

Draw the top-level processes and the second-level configuration, such as make to stock or build to order. Stop before the third level unless a specific problem needs it. What comes out is one map that people from different functions accept.
Agree and measure a few metrics

Select a handful of measures covering reliability, responsiveness, cost, and assets, and write down the exact definition of each. Measure them for the chain in scope. Do not adopt the whole metric library.
Compare against targets or peers

Compare the results with the client's own targets or with peer data. The model does not hold benchmark data for every kind of supply chain, so check that a comparable set exists before you promise a comparison.
Choose what to redesign

Rank the gaps by effect on customers and on cost, and pick the processes to redesign. Decompose below the third level yourself, because that detail is company-specific. What comes out is a short list with owners.

In practice

Two distribution networks, one from each side of an acquisition, give different answers to the question of what the order cycle time is. One counts from receipt of the customer's order. The other counts from credit approval. The consultant picks a single product family sold to a single customer segment and calls that the supply chain in scope, then maps both networks in the model's top-level processes and notes each one's configuration. One network holds finished stock. The other builds to order.

Next the team agrees on definitions for a handful of top-level measures: perfect order fulfillment, order cycle time, and the cost to serve. With the same definitions applied, the gap is no longer a dispute about arithmetic. The second network's order process includes a manual credit hold that adds days, and the first network's return flow has no owner. Those two processes go on the redesign list.

What you leave with

A statement of the supply chain in scope, defined by product family and customer segment.
A process map at the top levels, with each configuration noted.
Written definitions and a baseline for a small set of performance measures.
A ranked list of gaps against targets or comparable peers.
A short list of processes to redesign, each with an owner.

Failure points

Mapping everything

The team draws third-level maps for every process because the standard makes it easy. Months pass, and the processes behind the real problem get the same attention as the rest.

Edition mismatch

The client's team uses the older six-process names and the consultant uses the current ones. Make, deliver, and enable do not match transform, order, fulfill, and orchestrate one for one, and meetings get stuck on vocabulary. Say which edition you use at the start.

Benchmarking without a comparable peer set

The client is compared with companies that have different products, channels, or configurations, or no data exist for its kind of chain. The gap looks informative and is not.

Reference treated as the design

The practice library is read as a list of things to do. Teams adopt practices that suit other companies and neglect the problem in front of them.

Processes assigned to functions

Plan goes to the planning team, source to purchasing, and so on, and the handoffs between them, where cycle time and errors build up, belong to no one. The map is accurate and nobody is accountable for how the process runs end to end.

The failures above are usually Leverage & IP: it was used once, and nothing was left that makes the next engagement easier.

Origin

SCOR was developed in 1996 by the consulting firm PRTM and the research firm AMR Research, and the Supply Chain Council endorsed it as a cross-industry standard for describing and measuring supply chains. The Council later became part of APICS, which is now ASCM, the Association for Supply Chain Management. ASCM owns the model today.

Editions through 12.0 used six processes: plan, source, make, deliver, return, and enable. The SCOR Digital Standard, released in 2019 and updated in 2022, restructured them into orchestrate at the top level, then plan, order, source, transform, fulfill, and return. The detailed content, including the metric and practice libraries, is ASCM's, and this note describes it only at a high level. ASCM states that the Digital Standard is open access under a Creative Commons attribution, non-commercial, no-derivatives license. Read the terms before you put any of it in a client deliverable.