Blog

Standardization is not for its own sake [Lessons from the Road]

by Jamie Flinchbaugh on 01-30-17

I continue to surprise myself with the number of important topics that I have yet to write about, despite how many years I have written both blog posts and columns for first Assembly Magazine and now for several years IndustryWeek.

This month I take on the topic of standardization. The rote application of lean suggests that we standardize everything in sight. In fact, I’m just going to call all of you Alfred because it will be standard (if you ask “why Alfred?” then be prepared for the most sarcastic of responses). Standardization isn’t so inherently good that we should apply it blindly. It has benefits. In fact, it has massive benefits. But those benefits can be identified and articulated. And I attempt to provide a guide to that in my latest installment of Lessons from the Road.

In the article, I outline the following benefits of standardization:
Performance gains
Spotting problems
Don’t duplicate work
Shared resources
Flexible resources
Shared learning

As is often the case, given my constraint in space in writing a column, there are things left unsaid. I wanted to expand on one point. That is, there are often two different paths towards true standardization. The ultimate goal is both alignment and standardization in outcome / target and in methods / process. But do we go from none to all? Often we need to take steps. In taking first steps, what is more important? To standardize around a common target condition, or standardize around a method? This depends on which is more important in the near term.

If you standardize around a common target, but allow different teams / sites / individuals find their own means to get there, you may be surprised by their innovation in approaches. Yes, you will have variation in outcome, but if the target condition is clearly defined, then you can evaluate which are more successful at achieving that outcome. In “phase 2” of your grand master plan, you can then move to standardize around the methods based on which approach is most effective. This path is often effective when you are doing something entirely new and truly don’t know the best methods. img_3152

If you standardize the methods only, then you focus people on process and technique. This can sometimes feel bureaucratic and people may lose sight of the target outcome, but you’ve learned the skill of how to tear apart a process, find the best methods, and build capability around building and deploying a common method. People may deploy that method towards their own unique targets or objectives. An example here is that you standardize around how to provide employee feedback, but do not standardize what employee performance looks like and leaving that to the manager.

Some of you will say “you can’t separate method and outcome”. True, but you can absolutely determine where to start. You can’t boil the ocean, to use a cliché, so you have to focus somewhere. Where should you focus? Well, you have to be the judge. Hopefully I’ve just helped you be a better judge.

Please read the full column here.

  • Jamie, I encountered a dilemma between method and process parameters (machine parameters to produce desired outcome) and created a method with built in parameters. This way we addressed all three components. It was a lot of work but a great foundation of standardization nonetheless. The biggest challenge is making it stick and even though we engaged our production team I feel we still have cultural challenges…any advice here?? Thanks!

    Rob Gonzalez February 20, 2017 at 10:11 pm

Comments are closed.