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: Here’s the list of SCOR metrics; let’s review which aspects you want to measure. The ‘argument’ that they are the industry standard quickly kills those two birds with one stone; What metric and How is it defined.
Once I started using SCOR on my projects I realized the true value of the standard definitions for process. In many projects, where two teams need to come to an integrated solution or extract a single process out of two ‘this-is-how-we-always-did-it’ processes, a lot of resistance seems to exist about the what and how. Experience learns this is partially caused by the lack of understanding of what it is people do, we have all been trained to think in organization units rather then processes. The label of an organization may or may not be representative for what it is the organization does. (I started my carrier in a group called short-term-planning, a group of supply-shortage fire-fighters, we did everything possible and impossible to support customer orders, but none of it I would classify as planning). Just imagine the potential differences between two organizations with the same name in different companies (like in a merger or acquisition situation).
At the time the Supply Chain Council’s training materials stated that a SCOR project would take between 12 and 18 months. This was a big turn-off for us. We already knew how to do a multi-year project (just continue business as usual). It would also be a hard sell to our management: “If we train everybody now, we will see the results in 12-18 months”. This, plus the knowledge that the attention span of management for ’strategic’ projects was about 3-6 months, did not really seem like something we would invest in.
To fast forward through 5 years following the training; I started using SCOR on projects I worked on, then got to train a couple of people in using SCOR, later formed a group of SCOR project managers and soon realized we were fine-tuning the way we did projects. Methods and templates were modified and frameworks for other business domains – such as product design and sales operations – were created.
My advice for those starting to develop supply chain management processes is to select an existing reference framework that contains process and metrics pre-populated. Start with measuring the high-level metrics and describe your company’s, function’s or organization’s level-1/level-2 processes. But, don’t take my work for it, talk to other practitioners or a coach on how to make supply chain management a competency for your company.
2014 Update: Reviewing this post 8 years later the main points are still valid, but the leaders have moved from managing projects to managing supply chains. Frameworks like SCOR remain key ingredients but standard processes are now known to align supply chain strategies, networks, processes and resources.