Recently we were running a segment of our design workshops for generating and managing Supply Chain Center of Excellence (COE) organizations for a large European company, and in defining their standard COE processes, we discussed with one sub-team what were their deployment strategies for projects. I was met with a kind of blank look, “deployment strategy?” Continue reading
As a trainer and advocate of standard process languages and standards for metrics I frequently talk to companies that don’t do classic manufacturing; services providers like banks, insurance companies, software companies, etc. Their observation is that they like the value of the standard reference models (SCOR¹, CCOR and DCOR) but they are too manufacturing oriented: “We buy and sell DIY hardware and tools, we don’t make them” and “we provide banking services, we don’t make or ship money”. The question I would like to address here is whether standard reference models can be deployed in non-manufacturing companies.
It was Abraham Maslow who said that when you have a hammer, you treat everything like a nail. My hammer is the SCOR language which I normally use to describe supply chain processes. With this hammer in hand I find that many processes appear to be some form of supply chain process. An organization or function performs supply chain processes if it delivers some type of goods or services. The problem I found is that the language may not match. Let’s take IT as an example. Continue reading
Syndrome 1: You’ve developed a beautiful supply chain process model, metrics model, with depth and subtlety that allows you to probe with anything from automated software, to six-sigma statistics, is easy-to-explain to executives and has that rare power to illuminate business rather than merely describe. You team performs analysis, and begins redesigning processes to be more efficient and effective, and… when you work with process owners, they look at the starting process and ask the hated question “What’s this? I don’t recognize this…”. Continue reading
In a recent article, “The Design phase”, I discussed the concept of designing the change from the current way the process operates to the improved way with very few constraints. Does this mean that you can do without rigorous deployment planning? No, but you need to separate the discussions: First focus on what needs to be done. What type of changes need to be made, what type of skills do I need on my projects to make those changes, and what changes are dependent on each other: understand the possibilities. The final phase of a supply chain improvement project is to get ready for launching these projects you defined in the Design phase. You are about to deploy your change programs. You just need to make sure to get them prioritized and funded. This article addresses this final stage before you deploy your changes: the Deployment Planning. In Deployment Planning I will introduce constraints on the time, budget, and other key areas of the overall plan.
Why is it important to first focus on the requirements in the Design phase before incorporating the constraints in the Deployment Planning phase? Because, constraints can cloud the discussions of what needs to be changed. Continue reading
Recently somebody asked me what some of the key reasons of failure are for new teams adopting Business Process Management or SCOR. The number one risk is obvious: lack of sponsorship. A close second however is the inability to prove the value (of the team). One of the biggest start-up problems is the focus on getting a project started – get busy. That’s really when the clock starts ticking for proving your value (Now the company is actually spending money on your great idea). Many (start-up) teams have problems getting beyond the analysis phase of a project.
Recently somebody asked me what some of the key reasons of failure are for new teams adopting Business Process Management or SCOR. The number one risk is obvious: lack of sponsorship. A close second however is the inability to prove the value (of the team). One of the biggest start-up problems is the focus on getting a project started – get busy. That’s really when the clock starts ticking for proving your value (Now the company is actually spending money on your great idea). Many (start-up) teams have problems getting beyond the analysis phase of a project. They do everything right: scope out the project properly, capture process and metrics data and perform the analysis to root cause the problem. But then they stall. They present their findings and solutions to sponsors and stakeholders and feel they have solved the problem. Next project, please. Continue reading
“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. Continue reading
Someone told me a bad joke this morning “How is Winnie the Pooh like Jack the Ripper”… They both share the same middle name. In Six-Sigma “DMAIC” or “DMADV”, there are five distinct phases of work, in what my company uses there is “SCADD”, or five distinct phases of work, in SCOR there are five distinct phases, in many methodologies there are 4, 5, 6 phases of work… and they all somewhat share the same ‘middle’ name, or analysis. I’ve written before here about not getting locked in ‘analysis paralysis’ by focusing on designing an analysis plan to answer a question, usually a question about what is a root-cause issue in business performance which doesn’t meet a requirement. However, finding a root-cause issue is not the same as solving the problem, and that’s the focus of my interest today. Continue reading
The first question most executives ask when I explain how we organize an improvement project is along the lines of “can we skip the process modeling?” They either believe all the processes have already been modeled or they know their employees are saturated from all the modeling or other consulting efforts. The reality is that I rarely find off the shelf materials (process and metrics models) that I can use without significant rework. In this article I want to make a case to model less, not more. Let’s start with why you model.
Modeling for the purpose of modeling. Companies exploring process optimization tend to start with a company-wide modeling exercise. “You can’t fix, what you don’t understand, so let’s document all processes in the company”. Over time this becomes a burden to the modelers and the business. Processes change constantly, therefore the documentation ages quickly. This repository requires a large group of modelers to create and maintain. A typical characteristic of this type of modeling exercise is the process fatigue described in the introduction. Continue reading