Email a copy of 'Standard Work Is Like Food – Taste before Seasoning' to a friend
Loading ...
E-Mail 'Standard Work Is Like Food – Taste before Seasoning' To A Friend
Loading ... Loading ...Subscribe to Gemba Tales™
Subscribe via RSS (What is RSS?)
Or by emailWe never spam. Period.
Ask a question here via email if you'd rather not post it publicly.Kaizen Event Fieldbook
Gemba Tales™
is sponsored by
Mark R. Hamel's
Shingo Award-winning
Kaizen Event Fieldbook
• BUY FROM SME
• BUY FROM AMAZON
"A critical distinction from other texts on the market, the Fieldbook links the technical aspects of kaizen to lean philosophy. Kaizen is the game changer in any lean transformation, and this is the game book." -Bruce Hamilton, President, Greater Boston Manufacturing PartnershipConnect With Me
#1 by Mike Krebs on January 15th, 2012
Quote
Mark,
This is a very timely post for me considering our company is deploying standard beyond the pilot site. You can only catch so much during the net change event – as you state the chances of it being perfect are nada.
Concurrent with deployment – as more minds review and follow the SW – it becomes clear that it can be improved almost out of the gate. If we wait too long to integrate the improvements, teams lose the “buy-in” if they have to suffer through something wasteful but unchangeable. So, allowing for some “early” improvements can aid in the adoption.
To pick a time frame like 30 or 90 days, or number of cycles seems arbitrary. Improvements should begin to be made once the teams understand the SW and begin to see the waste.
Eager to here your thoughts.
#2 by markrhamel on January 15th, 2012
Quote
Hi Mike,
Thanks for the very thoughtful comment!
I wouldn’t be so bold as to select an arbitrary time frame either. But, I think a relatively brief and temporary “lock down” on standard work – perhaps a week or more makes sense. One very key point you make is that the teams need to “understand” the standard work. Understanding can only come to fruition through practice. Of course, practice will help identify waste and other opportunities. You are spot on regarding how an extensive lock down will frustrate stakeholders and their engagement around kaizen.
It’s a delicate balance!
Best regards,
Mark
#3 by David Kinne on January 16th, 2012
Quote
Is it about ‘timeframe’? Is it about ‘cycle rate’ (number of uses of the standard or product/service related to the standard work0? Is it about a ‘measure’ of the standard? Something rings true to a measure more than a timeframe. Just as standard work is a means to structure activity to a agreed standard the ability to change the standard work should probably have a standard applied as well. I’d vote for some measure of performance (if able to) over a flat timeframe. Or even cycles of use or cycles of product/service provided? If the standard work is truly developed within the context of the team then, wouldn’t the team be the final review to determine if a change were needed? Guess I have more questions than answers…….
Thanks for the challenging thoughts.
#4 by markrhamel on January 16th, 2012
Quote
Hi David,
Thanks for the comment. Excellent point(s)!
Yes, cycles of new standard work rather than time frame, itself may make a heck of a lot more sense. Depending upon the value stream and the specific processes, cycle times could be seconds, minutes, hours, or even days. The team(s) that have adopted the “new,” previously developed standard work from the pilot line, need to experience, unless there are some glaring deficiencies, some cycles before “seasoning” the standard work.
Best regards,
Mark
#5 by Andrew Bishop on January 16th, 2012
Quote
Stories about Thomas Edison abound in my former home, Fort Myers, FL, where the great inventor is something of a patron saint (he had his “Winter Laboratory” there – shared grounds with Henry Ford & Firestone!). In one story, he famously declined to hire an interviewing engineer who salted before tasting at mealtime. I guess he figured, like you, that it was a general rule and, if broken at the table, might be broken at work as well!
#6 by markrhamel on January 16th, 2012
Quote
Hi Andrew,
Thanks for the comments.
Now there’s something to add to the interview selection criteria! Thanks for sharing.
Best regards,
Mark
#7 by John Huner on January 22nd, 2012
Quote
I don’t see any need for a timeframe, myself. The key is to make sure any improvement is documented.
Any actual change should really be PDSA (so tested and proven). I don’t mind using judgement to make a change to the standard and then test it when that makes sense – it does in some cases.
As long as you update the standards and validate they work that is the key to me. Not the time-frame. If an organization found it was inefficient to have too many changes then it can make sense to impose restrictions. That is a system specific constraint though, I believe. To a significant extent those early in lean will have constraints that make fast changes seem impossible (similar to ideas of fast turnover, more many years ago – now many people realize how possible such things are).
Pingback: Management Improvement Blog Carnival #155 » Curious Cat Management Improvement Blog
#8 by markrhamel on January 22nd, 2012
Quote
Hi John,
Thanks for the comment. You make a number of excellent points!
My purpose for referencing a time-frame is primarily within the context of deploying standard work across a number of (near) identical lines and/or sites that have little or no prior experience with standard work. In such instance the standard work is typically developed at the pilot site/line. The inexperienced recipients of the new standard work very often have an immediate reaction that the standard work needs to be “improved.” This is induced largely by the change and the feeling that their freedom to do their work as they desire (non-standard) is being infringed. The point is that they need to live with the new standard work for a bit to adequately understand it and “check” or “study” it before making changes.
Thanks,
Mark
Pingback: MindEdge Monthly: noteworthy Quality news…February 2012 « Quality At Work
#9 by Wesley Connell on February 1st, 2012
Quote
I might be outside the normal line of thinking, but I don’t see any problem with allowing the new line to “season” the standard work very early, almost immediately, in the process.
During a implementation workshop, the standard work from the pilot line is distributed and run through with the affected workers. The data from the pilot line on cycle times are made available. Before the conclusion of the workshop, we allow for any improvements to be made to the standard work, but they need to be agreed upon by all members of the new cell and documented.
This starts the PDCA cycle. The rule is that the new standard work will be evaluated against the pilot. Best standard work wins. This has done well for us to engage employees and make the improvement process their own.
Its not that they are seasoning the food that they are being served, its more akin to a chef making the recipe their own by adding their own unique seasoning.
#10 by markrhamel on February 1st, 2012
Quote
Hi Wesley,
Thanks for the comment. Some excellent points.
What I was referring to was standard work that had been developed, often started within a kaizen event, but then continually PDCA’d for a number of weeks within the pilot line/cell/team. The pilot process is important from a technical prove-out perspective and to shake out any initial human resource issues. Here, the presumption is that there are similar, if not identical lines, within the same or other locations.
Once that post-pilot “checkpoint” has been cleared, we often proceed to another line, where we can see the technical scalability dynamics as well the impact on HR stuff (may have gone from the handpicked folks in the pilot to a team that may be more representative of the general population). Certainly, when the move proceeds to other sites, we can start experiencing the impact of different cultures as well, etc.
The point that I was attempting to get at is when moving from the pilot to one or more “initial deployment” lines, the recipients should just use the new standard work for a period of time before introducing changes. This is especially important, if the new standard work is moving to an area that is very immature from a lean perspective – often never having any real standard work. If we don’t lock down the standard work for a period, the immediate reaction from the next line is something along, “this stinks, let’s change it.”
Now, it does make sense before the deployment to the next line to conduct what I call a “net change” review within which we review the value stream to see if there are any heretofore unidentified differences between the pilot and the next line (systems, equipment, staffing ratios, etc.). If there are substantial differences, then the standard work should often be adjusted before introducing it to the new line.
There’s more to say, but I hope this makes sense.
BTW, go Bantams! Nice to hear from a Trinity grad.
Best regards,
Mark
Trinity ‘85
BS Math (not a good one)
Varsity Baseball, captain
AXP