This morning Die Welt, a German newspaper I am reading at breakfast during my visit to the SCC Europe Conference, reports that today 100 years ago Ford Motor Company implemented the assembly line for the Model T. The first assembly line was manually driven and reduced the production time from 12.5 hours to 5 hours and 50 minutes. By 1914 the fully automatic flow only required a mere 90 minutes.
The article points out that the idea for the assembly line originated from a visit to the slaughter houses of Chicago – the ‘disassembly lines’. Through trial and error the overhead trolley from the meat packers resulted in the assembly line that many/most automotive manufacturers still use today.
The Ford story is another example where a practice from one industry leads to innovation in another. History shows that radical performance improvement requires a radical change to your supply chain network and processes. At events like the European Conference presenters and attendees get to share ideas – for example with Sean Culey’s presentation about how automation, robots and big data impacted the past, today and the future.
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
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
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
After speaking at a Six Sigma conference I was asked what my definition of what supply chain management is and how it differs from Lean Six Sigma. The topic of my presentation was how to identify important change programs. I am not sure what exact wording I used but I must have first stated that I am not a Lean Six Sigma expert, only a Six Sigma customer, but my observation was that Six Sigma did not seem to use standards. My definition must have included process measurement, modeling and change planning.
For me supply chain management started 5 years ago with a request to join a group of individuals traveling to Minneapolis who were going to be trained in SCOR. The training experience was both positive and negative. The positive aspect was and remains the standard definitions for processes and metrics. As a former reporting manager I have spend many meetings explaining why we adopted a certain set of metrics and then sat through the arguments of what the definition should be according to such-and-such. Today whenever somebody asks the question how to measure an aspect of the supply chain the response is simple: Continue reading
In a previous life I was in charge of management reporting for the pan-European logistics organization for Compaq. My team was responsible for monitoring and reporting the daily, weekly, monthly and quarterly performance and progress of the operations. We provided reports on shipments-to-date, invoices send, estimated shipments for the remainder of the day, week or month, order cycle time and average shipment lead-times, and on and on. None of these metrics would keep me awake at night or would cause heavy discussion on accuracy and validity of the metric. That was reserved for one metric: “Predictability”.
Predictability was our #1 metric for customer satisfaction. It also had all the characteristics of a badly chosen metric:
- No real ownership (read: accountability)
- Nearly impossible to root-cause
- Home-grown, thus no realistic benchmarking information
- Multiple interpretations (shipped v. delivered, factory v. logistics)
- Everybody was impacted by it’s poor performance (as it was linked to profit share)
- And maybe most important: Unclear value to the customer
Recognize this type of metric? Continue reading