“When you have a hammer,” so the saying goes, “everything looks like a nail.” The implication, of course, is that when you have a good problem-solving technique, you tend to look at every problem and see examples of problems that would benefit from the use of your technique. By extension, this saying suggests that people with hammers often try to use them when they are completely inappropriate.
In the case of Supply Chain, one of the more interesting hammers is SCOR—Supply Chain Operations Reference—a cross-industry standard for supply chain metrics, practices, and process descriptions, which are linked, for use, with a strong BPR methodology. SCOR is industry-neutral to a degree, meaning that it looks at order management in computer manufacturing, for example, basically the same way that it looks at order management for garments or chemicals.
Interestingly, the hammer has worked very well across many industries. But it hasn’t worked in all industries.
SCOR is not quite the right hammer for the service-related industries.
“Manufacturing,” as opposed to “service delivery,” is not very natural. When we’ve considered using SCOR in these areas, we ended up renaming certain processes (but not renumbering them) to be more of a “natural fit” to what we were investigating. We resculpted the hammer to be a finer instrument in solving different kinds of problems by altering the activity naming/description of SCOR.
But then we went all the way. When we considered different problems not in the traditional Supply Chain arena, such as sales or product design, we found that we could conceive of those problems types of supply-chains and then use SCOR to accelerate the business process re-engineering. “Customer Chain,” for example, was the process of “manufacturing customers” based on “input leads” and “product catalogues.” “Design” was the process of “manufacturing bills of material” out of “supplier data” and “marketing demands.” The hammer was not” SCOR by itself, but rather the _structure_ of SCOR was the great hammer for organizing an approach to different business domains. You could use SCOR metrics to a degree, even some best practices, if you just rethought any business activity in terms of input/change/output.
At HP then, we divided up the enterprise work world into eight domains. Four were operational (Sales, Supply-Chain, Product Design, Marketing), and four were “enablers” (“HR,” “Finance,” “IT,” and “Management”). Each of these broke down into architectural structures that looked like SCOR, but kept process descriptions specific to the domain. Instead of SCOR level-1 “plan, source, make, deliver” we would have, for example “plan, relate, sell, contract” in sales. At level- 2, we looked at SCOR and followed the pattern again: Build-to-stock, build-toorder, engineer-to-order was about looking at the unit of activity (order) from a stock perspective—Configure and freely engineer it. So, for sales, we would look at “channel sales” (stock), “grouped sales” (call center, internet), and “custom sales” (field sales teams). And so on at level 3.
We then, in turn, were able to standardize team skill sets, using this view.
Certain people in the team, early on, would become skilled at re-engineering processes in one domain, say Supply Chain. Once they had mastered one domain, it was very simple for them to work with multiple-domain processes together. A supply-chain engineer turned out to be a quick study for sales process redesign. Then, lastly, once they were good at re-engineering multiple domains, we found that they were pretty good at modifying domain descriptions to fit into entirely new categories. Going back, for example, to services, these engineers could quickly adapt a domain framework (SCOR) to describe services delivery while using standardized metrics, and so forth. “Services,” certain public sector activities (Education, Government), and, by redefining toolkits flexibly, other specialized tasks were more easily approached by experts.
How well did this “one size fits all” approach work? In two programs inside HP where we looked at IT processes that did not seem a “natural fit” to SCOR, we adapted the framework (naming, not structure) to make it more appropriate, and then used it for re-engineering. “Path to Production” in IT corresponds to the manufacturing delivery process, and we could adapt many best practices from classical manufacturing to improve IT stability and performance for the installation of finished software. Likewise, using specially tailored versions of our 4-framework model, we described certain IT major process areas, like “Desktop Management,” and after going through a global re-engineering of desktop deployment within HP, we used supply-chain, sales, and design best practices to articulate a new global framework for delivery, saving millions of dollars in cost, improving asset utilization multifold, and reducing delivery cycle type by half or more.
Industry analysts are currently investigating “Kaizan IT” and “IT Supply Chain,” as well as techniques such as those we pioneered by adapting SCOR frameworks to domains where they are not natural fits, by modifying the nomenclature, but not the structure.
What’s the takeaway? First, learn SCOR thoroughly. Build a team around that as a tool, gain facility in using it in different business situations. Once you have mastered re-engineering using the framework-based approach, you can then quickly pick up alternative frameworks for different domains (sales, design) and begin to amplify the scope of your team’s re-engineering activities across the enterprise within your company. Finally, when they understand how to use the frameworks in multiple situations together, look at creating custom frameworks for the most unfamiliar areas—service delivery, project management, and so forth. The core knowledge and technique amplifies greatly the skill sets in unrelated areas.
It is not that “everything is a nail” once you use the SCOR “hammer,” – but, rather, that when you understand how to solve a problem with tools, and also begin to be quick about understanding how to use tools for new problems, your toolkit gets bigger, and you can look at tools for areas you never even considered.
You become the process problem solver and tool creator at the same time.