Coincidently my experience this week ties in nicely to the last post.
I have a couple of teams working to develop pull systems through their respective work areas.
The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.
An alternative approach is to have a small group of experts design the system.
Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.
What I am watching this week is more organic.
First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.
The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.
They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.
Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.
Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.
They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.
They are figuring out how to make it more robust, without making it cumbersome or too complicated.
They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.
The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.
What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.
This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.
It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.
Oh – and I’m really glad this process works because that saves me from having to know the answers.
Mark,
Great story! I’m a true believer in the power of cheap, simple, ugly – but realistic – table top simulations designed and run by the folks who are going to run the real system. The big things they do – if facilitated properly – are to develop a team to work as a team and most importantly, to learn by doing. And the great part about the learning here is that nobody gets hurt and no processes or customers are impacted. In short, there’s simply no better way to run PDCA cycles.
On the other hand, many people will argue that computer simulations are “more accurate” in these situations. I really get angry when I hear that kind of stuff. First, you need to bring a “simulation expert” in to build and run the thing. Second, you need to teach him or her all about your process and hope they get it right. Finally, you get to sit there and watch the cute icons move magically around the screen. What’s missing? Any learning by anybody other than the expert. And you always run the risk of computers just making the world’s most accurate errors. Words fail me on these.
Tom