A common topic of discussion in many companies is how to document and share what has been learned as they improve their processes.
The most common approach is some kind of database (either online or on paper) that documents the various “best practices” solutions to various problems.
They might, for example, show the before and after of the development of a work cell, how their visual controls are set up, or a particularly clever tool or gadget they developed.
Perhaps not so surprisingly, these bits of information turn out to be far less useful than people think they should be.
Why is that?
Let’s back up a bit and look at a larger scale.
Toyota, and other companies that are doing these things well, have all been pretty open about letting people come on and see what they are doing.
Other companies seeking to benchmark these companies then want to find one that faces similar types of problems, say “low-mix / high-volume production” or similar process flows.
Our community has developed a sense of what a “lean system” looks like. We express it in terms of the solutions to problems that have been developed.
Work cells.
Kanban.
Clever tools or gadgets.
But we also (hopefully) know that seeing examples of these things with the intent of copying them doesn’t really help that much.
Oh, they can be copied… but the track record for sustaining is pretty poor.
Nope, we know (again, hopefully) that it is not about the solutions, but about the process of solving the problem. In other words, it is the method used to develop the solutions that is important to grasp. Seeing the solutions after the fact actually gives very little insight into how to develop the skills required to do it yourself, or sustain it yourself.
OK, back to the original topic.
IF we know that copying another company’s solutions doesn’t work very well, and that we need to instead get a grasp of the thinking process that resulted in those solutions, then what should we be sharing internally, and how should we be sharing it?
The classic way to share is with a single page that says “Before Kaizen” on one side, and “After Kaizen” on the other. There might be a space for “problem” but when it is filled in, the words are usually pretty superficial. 85% of the space is devoted to a couple of pictures.
Even if it does state the problem clearly, it still doesn’t get into the process used to solve the problem.
Nor does it get into what was learned about the process of solving problems.
Now… before you leap in and say “Sure, that is what an A3 is for!” I will agree with you. Except that unless an A3 is written with that specific purpose in mind, most of the ones I have seen tend to do little better than the Before-and-After pages. Or they are so full of charts and graphs that they are really impossible to follow.
In other words, they are too complicated to convey the message, because the intended message wasn’t clear when they were developed..
It really comes down to intent.
If you are trying to share, be crystal clear on what you are sharing. What are you trying to communicate?
I believe it would be far more valuable to depict where your problem-solving process was faulty, what mistakes you made, where you went back and corrected yourself, and what you want to pass along about problem solving.
That would be a far more useful for the next person to come along.
Mark,
I always say that I’ve learned more from my failures than from my successes. After all, I always go in with a plan to succeed. So if doing that plan led to success, although I achieved my goals, I didn’t learn much. If however doing the plan led to a different result than expected, the door to learning magically opened. Of course the door to success sometimes slammed in my face at the same time. So I’d agree with you that simply sharing success stories doesn’t allow much learning for others.
On the other hand, at least part of the reason most of us share our successes is to give our teams a bit of a pat on the back. Everyone loves to see their name in lights – or print. So we use what we call “Impact Statements” which are one page (front only) “press release style” documents that are available on the company intranet. They define the (then) current situation and problems, what the team did to address them and the results they achieved. And as you stated, there’s lots of room for pictures of smiling faces or clever solutions. Do they work? Well, on the PR side, I’d say they do. As for the learning side, not so much.
So would I like to start sharing my failures so others could actually learn more? That depends how close to Performance Appraisal time it is and how much my boss values failures and learnings.
Tom
This isn’t about sharing “failures” or “successes.”
It is about sharing what you learned and how you learned it – the process of solving the problem vs. simply the results.
The only “failure” I can think of is a gap condition where there weren’t any problems to solve.
Mark,
I absolutely agree that we should be sharing what we learned to get our results.
Unfortunately most folks just want to share the results – which has very little to do with the learning required to get those results. So it’s the age old focus on results vs. process again!
Tom
At the same time, those same people are continually asking how they can do a better job sharing “best practices” across the organization.
So are their managers.
The “sharing” process is generally structured in some way.
By slightly altering the process, and our definition of “results” a big change is possible.
I completely agree with everything you say with a “but” at the end. My hesitation is a question because I don’t know the answer. No one ever understands solutions to the problems unless they develop them themselves. So no solution ever sustains unless it is developed by the owners of the process. From personal observation, I would call these two rules hard and fast principles. They don’t vary.
BUT…When do you standardize the solutions? For me the sharing of solutions has two purposes:
1) Develop organizational learning. Ensure that everyone is learning what one group learned. This is where I completely agree with you. Copying the solution does not teach anyone anything and the copy is usually more wasteful than it is useful. Copying the approach to solving the problem and learning based upon that will always result in a more robust and sustaining system.
2) Sharing also ensures some level of standardization throughout an organization. This is where I will deviate from you a little bit. At some point and at some level, there is real value in using somewhat standardized systems from one work area to the next. Using standard approaches to problem solving should come to somewhat similar solutions but small differences in the solutions can often lead to struggles in sustainment in the future as well.
I have an example where we had a strong push a few years ago to eliminate all internal scheduling and go solely to pull systems throughout an entire value stream. We did value stream maps of the whole process and then determined that we need 5 seperate pull systems to connect suppliers and customers throughout the value stream. We decided to use your approach to solving these 5 distinct problems (how to signal supply needs to your customer). Each connection got a team together and in a couple days the team developed solutions to the problem. Then when the next team started we gave it free rain to develop its own solution but we gave it direction in the approach learned from the previous team.
Three of the connections developed very similar solutions. The other two developed very different solutions but I think all three types of connections were very good solutions to the problems at hand. They worked for them at the time. I honestly thought that these systems would sustain because of the ownership developed in the area. Fast forward a year and a half. 1 1/2 years of organizational shifts mean that most of the connections don’t have the same owners. In fact some of the owners have moved from an area that had a different type of connection. They have a lot less respect for the system controlling the area than the system they created at their old spot. Universally, the systems deteriorate.
So my question after all that typing is this; Would it have been better for the organization to at some point say, “Okay, good job with all of these systems but we are going to this (pick one).”???
There is a balance here. I think that sharing of solutions has an important role. Organizations need standardization to ensure sustainment in volatile workforces. My personal approach is to give groups huge blank canvases to solve the problem (with a standard science based approach) at first, then start standardizing the systems after owners have an understanding of their processes.
If you go too far to the left and give every group complete carte blanche to create you will struggle with sustainment for one reason. If you go too far to the right and “share” solutions (that really turn into a standard that someone is going to be held accountable too…) then you will struggle with sustainment for another reason…