Team Building with the SCOR (Supply-Chain Operations Reference) Model
The Supply-Chain Operations Reference-model (SCOR) helps companies understand the supply chain work that needs to be done and how to measure the output of that work. Less well known, however, are the benefits SCOR can deliver in terms of fostering true supply chain team building. Here's a look at how this process framework can help organizations knock down the functional fences and get everyone moving forward in a productive and collaborative manner.
By Joe Francis -- Supply Chain Management Review, 3/1/2007
Companies typically realize six major benefits from successfully using the Supply-Chain Operations Reference-model (SCOR). SCOR helps them manage the business by providing detailed visibility into how work actually gets done. The model also helps companies compete more effectively through its system of metrics that are objectively linked to business processes. SCOR's end-to-end supply chain focus also points companies toward real process improvements, as opposed to just moving bottlenecks from one place to another. Next, the use of SCOR metrics and attributes usually improves cost and cycle time and reliability. Finally, the SCOR Roadmaps help streamline and accelerate business change by mapping out the process improvement cycle.
That's five benefits. The sixth benefit—and focus of this article—is that SCOR promotes team building. The first five benefits combine to create a clear understanding of the big supply chain picture. With that knowledge, individuals in the supply chain organization can better understand their commitments and relationships as well as the consequences of their activities and decisions on others. They also have a more transparent view of the end-to-end supply chain operation. With all of this, they begin to think of themselves more as team players than as narrow functional specialists.
The Supply-Chain Operations Reference-model is a process framework that allows for rapid and reliable end-to-end descriptions of work, material, and information flows in supply chains. In a real sense, it's a supply chain dictionary. SCOR includes definitions for standard supply chain metrics (for example, perfect order fulfillment), definitions for specific activities (receiving, verifying material, trailer loading, and so forth), standard activity “inputs and outputs,” collections of best practices linked to processes, and a methodology for characterizing and improving supply chains.
The nonprofit Supply-Chain Council maintains SCOR as an open standard for its members. It provides training in the SCOR framework and methodology as well in special-purpose usage, such as linking SCOR and Six Sigma. The Council has chapters in Japan, China, the United States, Europe, South Africa, Latin America, Brazil, Southeast Asia, and Australia/New Zealand. The SCOR standard is also supported by software companies like SAP, TIBCO, and Xelocity. (For more on SCOR and the Council, see www.supply-chain.org.)
So how does all the SCOR team magic come about? What follows are three real-world examples showing how SCOR (1) helped make supply chain teams out of competitors during a merger, (2) helped create global supply chain teams to redesign and improve complex planning processes, and (3) helped the supply chain and design organizations gel as a team. A key to success in each case was that the supply chain professionals involved were able to move away from a functional, geographic, or business unit orientation to embrace broader supply chain processes and metric outcomes that would be shared by all. In short, they followed the SCOR principle of “no functional boundaries,” which focuses groups away from competing positions and toward shared goals and responsibilities.
Not Competitors but a Team
Compaq and Hewlett-Packard announced their merger plans on Sept. 4, 2001. Several senior managers were immediately drawn into discussions on how to execute the merger, and within a week, a management team drawn from both companies was assembled to plan the post-merger operations. I was part of that team as a supply chain manager at Compaq.
The planning sessions were “two in a box”—that is, for each management role, there would be one HP person and one Compaq person. With those guiding rules in place, the first half-dozen people were selected to begin looking at supply chain operations and technology planning.
Sharing information for planning purposes was not going to be easy. It was clear from the beginning that we were serious competitors (not complimentary players) in virtually all our products and markets. Competitors don't naturally share information—particularly on supply chains—without a struggle. We had the same supplier bases. We had very similar models (channel, build-to-order, and engineer-to-order) for execution. And we were both tough competitors. (Printers were an exception, since HP had a printer division and Compaq didn't. So to some degree the printer supply chains were exempt from the planning process at least initially.) In addition to the competitive factor, it was clear that the merger would result in the elimination of operations and people. So there was a fairly high degree of protectionism evident. Everyone was convinced that “their” organization and function should be the ones that survive.
Guided by the SCOR framework, our first step was to shift the focus from the functional organization to the “mega” processes of plan, source, make, deliver, return, and enable—the “Level 1” SCOR activities. For each of these processes, we identified people from both Compaq and HP to play a “two in a box” role. Immediately, we started seeing positive behaviors around cooperation and teaming instead of competition. The key was that we had a neutral approach. We weren't comparing one logistics group against another, or weighing the relative merits of the two procurement organizations. So it was clear that there was not going to be a “winner” from either company who would control and dominate the processes. As the planners were brought in to tackle each mega process, we could see tensions abate. SCOR's neutrality substantially reduced the resistance to sharing information and encouraged us to look at joint goals around the supply chain processes.
As the process review teams were being organized, we began to focus on criteria for planning post-merger processes. The initial instinct was to take a subjective view of supply chain performance—for example, taking the view that some supply chains had more advanced technology (say, SAP 4.6 vs. SAP 3.1) or others had better “leadership.” Again, to move away from this subjective and largely functional view, we focused on process performance within the SCOR framework. Drawing on SCOR's wide menu of metrics, the teams found it relatively easy to set the initial supply chain performance criteria. We knew, for example, that we had to reduce total supply chain management cost and cost of goods sold (COGS) by billions of dollars. We had to double supply chain asset performance. At the same time, we could not compromise order cycle time or delivery performance from current levels. It didn't matter which technology was more attractive or which supply chain supposedly had the best leadership. What did matter was hitting our cost-savings and operating target numbers with the post-merger supply chains. Everyone understood these numbers and would soon understand the processes linked to them.
With teams organized and the performance criteria set, we began capturing information on the supply chain operations of each company in every market and product line. In addition, we created a top-down model of both the current and future operations in the two companies. The process was remarkably easy to perform, with virtually no friction between “competing interests.” In other parts of the organization that were not being guided by a framework like SCOR, planning teams sometimes got bogged down in trying to compare apples-to-oranges. In some instances, teams focused solely on functions; in other cases, groups, fearing for their post-merger viability, wouldn't cooperate in data gathering. On several occasions, in fact, tensions rose to the point where team members on both sides simply walked out of a meeting.
With the supply chain team, however, things were different. By digging down and focusing on the process and end-to-end activities—and not getting distracted by turf protection battles—we had clarity of mission. And importantly, nobody felt threatened. In retrospect, it was quite remarkable.
Our efforts were far from tension free, though. The HP-Compaq merger was highly contentious from the perspective of shareholder debate, the industry analysts' views, and the widespread scrutiny of the largest IT merger in history. We went through cycles of “good week/bad week.” On a good week, when we had favorable press and saw progress being made on the business side, our supply chain teams were cheerful and highly motivated to go forward. On a bad week, when it seemed like the merger was doomed to failure and our very jobs would be in jeopardy, motivation levels were low. But even during the worst times, we all saw how much sense the merger would make because we had a clearer view of the operating processes of the two companies. We understood the efficiencies of scale possible by more effectively managing assets and inventory, by getting rid of process overlaps, and by cleaning up chronic problem areas. The end-to-end visibility afforded by SCOR helped lessen frustrations we all experienced during the “bad” weeks.
In the end, the supply chain mergers of the two companies were highly successful. We overshot our target performance goal by $1 billion. Most of the merger criteria goals were achieved within the first year. We hit the ground running on day one with detailed process-by-process change programs for moving to the new operating models, complete with fully evolved program management structures. No supply chain decisions were rescinded during the two-plus years of executing all changes. Instead, all business units that we had done the planning for achieved profitability within the first year of the merger. (In fact, the team survived to form the core of the new HP's business process management team, which provides support to process-focused initiatives primarily in supply chain.)
Breaking Down the Silos
Another organization that I worked for had been struggling for years to achieve high predictability in planning. Over a seven-year period, I was involved with multiple programs seeking to achieve a devilishly difficult goal of “95/5” (95 percent order predictability, five-day order cycle time) set by the CEO. Program after program was instituted. Each would yield a quick bounce up in order-predictability levels, only to then settle back down around 86 percent. It was a maddening and persistent problem. The downstream effects of the low reliability continued to grow over time—from having either too much or not enough inventory to constant firefighting around customer deliveries. It became clear that we needed to invest in a comprehensive effort to improve planning reliability rather than putting band-aids on the symptoms at a customer (or supplier) level.
Putting together a comprehensive planning approach was easier said than done, however. Past attempts typically had been organized around functions. Each functional organization was highly siloed and had almost no visibility to the upstream or downstream effects of their work. There was no top-level “supervisory” function for planning as a whole. Point changes would be made, for example to achieve better visibility to inventory for commodity planners or more dynamic inventory allocation for logistics planners. Yet while these may have helped inside the silo, they were actually detrimental to the execution of end-to-end supply-chain planning in some instances.
Complicating matters was a widely held view within the company that SAP's Advanced Planning and Optimization (APO) was the magic- bullet solution for all planning problems. The thinking went, if only we could get all planning processes in one system with centralized visibility of inventory and demand, everything would be great. Everyone was convinced that inventory visibility was the critical issue; the number of electronic-data-interchange (EDI) programs to provide more and more inventory visibility at every conceivable warehouse or depot was truly amazing. In the end, APO was a magic bullet, but in a way totally not expected
After considerable back-and-forth between IT and “the business,” the SCOR team was asked to help accelerate the program for developing the planning system, which was woefully behind schedule. The expectation was that we would come in and capture all the planning processes in a standard language. This standard language would then enable IT to be more effective at putting those planning processes into APO. Another phrase for this approach is “paving the cow path”; as veteran system integrators know, blindly implementing processes in an IT system can lead to problems.
Our first step was to bring together all the key managers of planning from all over the world—regional planners, commodity planners, sales planners, logistics planners—you name it. These were people who had never met each other before, or didn't even knew of each other's existence. They were people who had never before worked as a team on planning.
Second, we encouraged the managers to describe their planning processes top-down in SCOR terms of work, material, and information flow. By liberating them from their traditional functional orientation, this exercise created an amazing experience. For the first time, they could look at information that entered planning processes and could trace it all the way through to material on its way to a customer. The top-down approach forced them to understand the end-to-end picture, which heretofore had gotten lost in the weeds. Suddenly, the team understood the shared goal of 95-percent reliability and the high-level supply chain planning needed to support that performance level. They now jointly owned the context, the goal, and the outcome.
The first big shock to the system was that the organization didn't have one major planning process or even two or three. Instead, there was layer after layer of planning processes interacting in strange feedback loops or dead ends—all of which added “judgments” and other information that distorted signals and decreased reliability. Each process might have been 95-percent reliable, which the organization thought was pretty good. Yet with seven or eight layers of 5-percent failure, the error rate grows exponentially. So the system as a whole—no matter how good the components were—could only realistically achieve reliability of 60 to 80 percent.
We normally recorded the SCOR modeling and planning sessions so that we could refer back to them should questions arise about a design element or other issue. While the microphone was on during breaks, we often heard team members talking about how they finally understood how the other teams did their job, and why they themselves were doing planning.
After the first couple of days trying to make the APO system work, the team determined that they needed to step back and instead focus on solving the end-to-end problem. They determined that the question of how a process would get done should be deferred until they first identified what should get done. They agreed that they would then later meet again to flesh out the details of implementation. So more than 70 people from all over the world who had never before operated as a single team were able to see the real objectives, agree on a workable approach to getting a newly designed planning process that could meet company goals, and organize to translate the design into implementation. Talk about an effective team!
The result of this team exercise was a series of merged requirements for each planning organization that was reconciled to a single set of performance goals. The team also accomplished a six-fold reduction in planning process complexity, or layering, that immediately and dramatically improved accuracy. Importantly, this successful supply chain planning model was not created by a sponsor or stakeholder imposing a solution. Instead, it was the work of team members looking at the end-to-end supply chain with a clear goal in mind.
Taking Down the Fence
One of the most common barriers to team effectiveness is the “fence” that often exists between supply chain operations and product design. How many times have we heard about a product being designed and then “thrown over the fence” for the supply chain to manufacture and deliver. Or if there's a problem in returns, manufacturing, or packaging, the product gets “thrown back over the fence” to the design team with instructions that they “just fix it.” While there are plenty of well-integrated design and supply chain teams, the problem seems to surface more often than not.
I once observed a SCOR team that was part of a large, well-integrated initiative to solve order-cycle-time problems in a high-velocity, consumer-product supply chain. After all the top-down supply chain process reviews, metrics and performance analysis, and Six Sigma analytics that they could throw at the problem, the company was still left with below-par performance. About 50 problems, like inaccurate order information or missing product dimensional data, persisted even after the conventional corrective actions had been implemented. Many of these had to do with that “gray area” where the line between supply chain and product design can become blurred. But in this case, nobody wanted to blame the design team or the supply chain organization. Nor did they want to throw the problem over the fence. They knew that only by resolving the problem together could they make the end-to-end flow visible and identify the real solutions.
Fortunately for the product design and supply chain teams, the organization was using not only had SCOR but also a Design Chain Operations Reference-model (DCOR). This is a reference model for design processes that integrates with and compliments SCOR. The design model is managed by the Supply-Chain Council as part of more advanced tools for examining not only the supply chain but also the surrounding processes that feed into overall enterprise performance.
For this project, the program management team brought in the product design operations teams, and they began a traditional top-down review of performance requirements, processes, and major performance gaps. The aim here was not to point fingers but to identify how design intersected with supply chain at hundreds of points and where those points influenced key outcomes. It's said that 80 percent or more of supply chain costs are fixed at design time. Other metrics—like order-cycle time—are also fixed at the design stage. So if you really want to improve supply chain performance, you have to carefully examine all of your design processes.
Once the team members grasped this concept they could now quickly see where a defect in a design process might manifest itself in a work, information, or material problem. Cause-effect views were put together, and before too long design-focused individuals began to act and talk a little like supply chain managers. The supply chain folks, for their part, began to concern themselves with design integration and launch issues. The organization as a whole ceased to worry about “cross-functional” teams; now the emphasis was on being part of the customer-focused team dedicated to improving order-cycle times. And once again, in recorded workshops we heard the familiar off-line conversations about really understanding each other.
The benefits of dismantling the fence between design and supply chain were impressive. Here are a few examples:
- Because supply chain teams were involved in the phase-gate reviews on critical product data at product launch time, they ensured that no critical supply chain data was missing or incomplete.
- Because the supply chain had more accurate product-dimension information, shipments were loaded right the first time—no more wrong-size boxes requiring unloading and repacking on the trailer.
- Because the teams shared access to simple tasks (such as updating product pricing), they were able to bypass the formerly inefficient and long cycle-time update processes for key product data.
- Cross-training of design teams on supply chain processes resulted in greater responsiveness and availability of responsible parties when supply chain issues were encountered.
To ensure that these kinds of benefits are not eroded over time, the organization has kept the core design and supply chain team intact, long after the initial process problems had been solved.
The Bottom-Line Benefits
The three case examples presented here demonstrate how SCOR can greatly facilitate team building. To recap, these are among the key benefits:
- Teams work more effectively because SCOR gives them visibility into how work actually gets done—prior to the merger, in the planning processes, and in the design and supply chain operations.
- Decisions can be made based on shared enterprise-wide metrics—not on the preservation of organizations during the merger, or emphasizing one function over another in the planning process, or choosing between supply chain metrics vs. design-team metrics.
- Teams can make real supply chain improvements instead of just moving problems around. Our examples show a merger team effecting big savings in operations, a planning team turning the focus from the narrow functional approach to a top-down integrated one, and design and supply chain teams collaborating instead of throwing things “over the fence.”
- Goals can actually be met. In our examples, supply chain teams were able to achieve both cost savings and performance goals with the merger; the planning teams reduced planning cycle time and cost while improving performance by reducing complexity; and the design and supply chain teams not only improved order-cycle time but also reduced cost and improved delivery reliability.
- Finally, SCOR helps supply chain teams work more effectively by giving them a clearer understanding of the big picture. The framework helps them understand commitments and relationships as well as the consequences of activities and decisions. In addition, SCOR creates a transparent view of the end-to-end context of operations—whether it's a merger, a reorganization of processes in existing operations, or a review of processes totally outside of the supply chain.
| Author Information |
| Joe Francis is chief technology officer for the Supply-Chain Council. |
View All Blogs
