To standardize or not to standardize, that is the question. While not quite Shakespearean, it is probably asked more often than "to be or not to be." Much emphasis in the lean world is placed on standardization in many forms, from standardized work to 5S. But why standardize? What do we gain?
While lean principles exist, their dogmatic application is counterproductive. Lean zealots sometimes forget this. Why do we not just say that standardization is good? Because it comes at a cost. Creating, maintaining and improving a standard requires effort. Like any cost, there should be a return on that investment, even if incalculable.
We shouldn't want to just standardize something because we think standardization is good. We want to articulate how it is good for each specific application. Here are some specific starting points for the benefits of standardization.
1. Performance gains. If one person or team can do something in 1 hour that takes everyone else 3 hours, copying that best practice across multiple resources can be a tremendous gain. If there is a best-known method that produces a clearly superior result, not standardizing is a conscious decision to accept losses. A key leadership question to those not adopting such a standard would be, "Why are you willing to accept sub-standard performance?"
2. Spotting problems. This is a specific variant of performance gains around maintaining performance. The rule applies when problems are likely to occur and the best way to spot them is to see deviations from the standard. For example, during my drive to the airport, I know how long it should take me and where I will face traffic or no traffic. If there is a deviation from that standard, it is both easy to spot and important to identify at the earliest possible time. This reason is one that could be applied to a wide range of situations, but be sure that (a) it is the best fit and (b) you achieve this level of outcome, as efforts here often fall short.
3. Don't duplicate work. Don’t reinvent the wheel. If someone creates something (a tool, training materials, etc.), then every other team creating their own version is duplicate work that can be avoided. If it takes 100 hours to develop a new training package, even if another group might do it only slightly better, it may not be worth duplicating 100 hours’ worth of work. If there is a cloud-based application that can accomplish 90% of what you want to accomplish, there is only a small gain for massive effort for that remaining 10%.
4. Shared resources. If an important and shared resource has to work with several different groups, but with each group they have to change their approach, methods, communication and so on, it is both inefficient and leads to errors. This is why every location doesn't use different security systems, or terminology, or technology. The more differences from group to group, the harder for other groups to engage them all. This may be the reason most often abused, as we can force standardization on many for the efficiency of a select few, without understanding or articulating the cost.
5. Flexible resources. If the demands on different teams vary, it can be very useful to shift resources from team to team or site to site. If the methods of each team differ, the losses from someone shifting teams and learning new methods can offset the gains of the moved resource. If there are common methods, then there are only gains when shifting resources to optimize the total output.
6. Shared learning. If two groups have a common method, then experiments and improvements can be leveraged across them. Controlled experiments can be run, abnormalities filtered out and benefits leveraged. Without a common standard, every shared learning and experiment is discounted by saying, "That doesn't apply here."
My point is, before you go through the effort of standardization, make sure you understand and articulate the benefit of investing in standardization.
