"Analysis is the difficult part of a business improvement project". "Analysts are really smart people that are hyper intelligent" and "analysis can not be trained". Those are some of the preconceptions project teams have to fear the analysis work that needs to be done on a process improvement project.
None of these are true. First of all many people confuse analysis with all those complex statistical tools that, for example, six sigma makes you believe you should apply. Many analytical techniques are not statistical and in business process improvement projects it is the group of techniques I use the least.
There is a wide variety of analytical techniques you can apply to a project. But only few are the silver bullets. Of course I could try to cut this article short by giving you the list. The problem is the silver bullet techniques are dependent on the type of improvement project. Sarbanes-Oxley for example is a type of process improvement project; focused solely on risk mitigation and putting financial controls in place. Another type of process improvement project is a lean project; focused on the reduction of waste. Waste of time, waste of space, waste of materials, etc. Each of these requires a unique set of analytical techniques. Apply the wrong technique and the outcome is different than expected. Applying 6-sigma -as in the parts per million standard deviation- in a lean project may provide interesting results but is unlikely to yield a reduction in waste of time, space or materials as six sigma is focused on reducing variance of the outcomes (i.e. improve the predictability of a process).
What we have noticed on many process improvement projects is that the analytical techniques can be classified in 3 types:
For each project you will likely apply at least one technique from every class.
Here's an example of applying all 3 in an example process improvement project. Let's assume your company is looking into reducing shrinkage. The first thing you do on such a project is develop some hypotheses where the shrinkage is taking place and design a project to collect process knowledge and process performance data to confirm or drop these hypothesis. The first step I call scoping a project, the second step is capturing the current state. The data you collected you use for determining the key shrinkage numbers by the different nodes (functions such as manufacturing, warehousing, transportation, retail store, etcetera) in your supply chain. Determine where the highest shrinkage occurs to focus your improvement efforts. For this you normally use analytical tools such as sample size, Pareto analysis, and scatter diagrams. These all fall in the performance class. You now know where to find the biggest bang for the buck.
But what is causing the shrinkage? Hopefully the process knowledge you collected in the second step can help you out. The process information you collected should have highlighted several processes that are causing shrinkage. Reviewing your processes for gross disconnects will help identifying the key issues. Expensive parts may 'walk out of the door' because there is nobody responsible for issuing these parts. Insufficient training may lead to a high damage rate to parts during the installation process. And constantly moving the product around increases the risk of damage. These are the structural analytical techniques. You now know what to solve.
How to solve these? That's where the practices can help out. Be assured that in most cases you are not the first company trying to solve the causes you found. And you may not even be the first division or business unit in your company trying to solve them. A best practices assessment in your company may help you identify workable solutions for your root causes. And as a bonus you may also find people that have experience in implementing those practices. Many companies use consulting companies for the practices. Consulting companies are exposed to many different ways different companies have implemented the same processes and they can objectively compare the effectiveness of those different versions of the same process.
That leads to an important given for any project team. You can bring any one of these types of analysis into your project at the appropriate time. When you are ready to do some serious number crunching: bring you statistical expert in. Want to know what the future direction and alternatives are for component tracking? Bring the industry guru in front of the project team for a day.
The take-aways? Apply only those tools that help you solve the problem. Applying the right analysis techniques will provide you insights in how to improve the performance. Use your resources wisely. Bring in the required analytical skills/knowledge at the right time. And finally: Don't apply statistics for the purpose of applying statistics. Analysis paralysis really exists. Apply those analytic tools that help solve the problem. Of the 40+ statistical tools in my Six Sigma pocket guide I seldom use more then 3 per project. There is simply no justification to apply all 40.
But like always, don't take my word for it; prove it to yourself in practice.
Caspar H. Hunsche is Managing Director and co-founder of Process Core Group (PCOR.com). He is the original author of the Customer-Chain and Design-Chain reference models. He is a practitioner and advocate of standards based process management.