Category Archives: Supply Chain Projects

Blink Analysis

Some time ago I reviewed a fairly large SCM program which covered an entire line of business in multiple geographies, many activities, and substantial depth of process capture. The intent of the program was to standardize processes to a single blueprint across the company, which they had made fairly dramatic progress on in a short amount of time (as usual: with frameworks including SCOR). Continue reading

The Great Convergence

I spoke at a conference last November in San Diego, about different supply chain management techniques and how the “compete” with each other. What impressed me at the conference was that after years of discussion around Six-Sigma, SCOR, LEAN and other approaches, people are now completely accepting true ‘convergence’ and ‘condensation’ around supply chain process work, and understanding the proper place of different methodologies within overall change management. Continue reading

Just Doing It

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

Time for Change

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

The Design Phase

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

If I Had a Hammer

“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

Keep On Keeping On

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

Why Do You Model?

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