|
|
My organization is evaluating the use of computer simulation to support our Lean efforts. In addition to reviewing various programs, we are wondering who should be using the program. For example, is there one person whose full time responsibility is to create computer simulations? Are there multiple users of the software?
If we do decide that computer simulation is the "what", does anybody recommendations for the "who"? Does anybody have any lessons learned about who the right person/people are? Is there a specific background that this person should have (ie math / engineering)?
Any insights would be greatly appreciated.
|
|
|
Danielle,
We're twelve years into our lean journey and hardly use and computer simulations anymore. (We used to.) The reason we got away from them is exactly what our Japanese Senseis told us at the beginning. The only person who really learns anything in one of these is the person who writes the simulation. The people who really need to learn are those that operate and manage the processes. They'll learn much more by going to Gemba. If you really think you need a simulation, create a simple tabletop one with stuff you have laying around. Just like they say in the commercial, the results are priceless.
Tom
|
|
|
You want to evaluate the use of computer simulation to support your lean efforts.
For what purpose? Is this to simulate process flow? If so, I wouldn't do it, because someone sitting in a room playing with software is no way to get the people involved in the process to learn and interact. That is accomplished with Value Stream Mapping, and walking the Gemba.
|
|
|
Computer-based simulation modeling was a big part of job for several years, and it has a lot of value. But I'm in total agreement with Tom. The most important part of the simulation experience is the experiential component, and the ability to "move material" and work the "schedule" on the tabletop and see how the system will behave is very powerful for participants, particularly those who will be doing the job (e.g., operators, planners, etc.). Tabletop simulations are especially useful for developing pull systems.
|
|
|
I have to agree with everything that's been said so far to some extent. Yes, simulation is no substitute for going to the Gemba. Yes, tabletop models can bee useful for gaining process insight and playing what if. Where I find computer-based simulation to be indispensable is in situations where uncertainty plays an important role. Uncertainties such as customer demand patterns, absenteeism, machine availability, delay frequency and duration, etc. These are very hard to accurately fold into process improvement efforts without some sort of simulation engine. And since it is hard we tend to minimize the effect in our thinking to the point where we don't even recognize that uncertainties exist. However, in my experience profound process improvements are often found in managing those uncertainties.
Getting accurate data to load into the simulation models is usually very hard. It takes a lot of creativity and discipline, and the effort is a particularly hard sell the first time around. Estimates don't work. Some dismiss it by saying, "Oh, that's not Lean; that's Six Sigma stuff." Others are turned off by the math involved. However, the results are worth the effort. The most striking example I can think of is a case where Lean tools by themselves had us poised to solve the wrong problem, or at least not the problem with the most leverage. By developing a simulation model of the process the team was able to not only re-focus on the high leverage issues, but also to prioritize the proposed countermeasures based on what-if analysis and projected benefit return on investment for those countermeasures that required investment. Lastly, the team was able to try different combinations of countermeasures and develop an implementation strategy prior to piloting. The ability to test fly an implementation strategy prior to taking on passengers (e.g. their co-workers) gave the team more confidence that the improvements were really going to work.
Are the models perfect; in other words, do they predict the future? Absolutely not. But assuming they've been validated prior to use, they are indicative. I recognize the debates on whether everyone should do simulations versus technical specialists, and also whether simulation is necessary on every project. My attitude towards the first debate is that the people who do simulations should be the people who want to do simulations. It's a skill that can be learned if a person is curious/interested. The packages available today make setting up models quite easy, especially if you are already versed in process mapping. If a person's idea of Lean is process improvement without data, then simulation is definitely "not-Lean." But if you're OK with a blurred edge between Lean and Six Sigma, or whatever else you want to call data-based process improvement, then simulation deserves a place in your bag of tricks (with all due respect to Sensei's).
Lastly, simulation is not necessary or even smart on every project. I think one always has to be cognizant of the cost of what we do in proportion to the benefits that might be gained and when. Gathering the necessary data may take months depending on the tempo of the underlying process. Many people may need to be involved in gathering the data at the source. These things, not the cost of the software and running it, are the predominant costs associated with simulation. Nonetheless, there definitely are projects where the cost of being wrong, even incrementally wrong, are enormous. Simulation has a place.
|
>
Community >
Forums
Send to a Friend
