Gemba Coach by Michael Ballé

How Can One Be A Better Sensei?

Thu, 02 Sep 2010 04:00:00 GMT

Dear Gemba Coach,

Our operations VP is disappointed with our lean program. Despite his close personal involvement with the program, it is not delivering the level of results he expects. How can he be a better sensei? Is this even the right question to ask? Both of your recent books stress the importance of the sensei role. What advice should I share with my VP so that he can support greater results from our lean work?

The role of sensei (an experienced coach or mentor) in lean programs is indeed problematic, and probably the greatest bottleneck to the widespread diffusion of “real” lean. True senseis are rare, expensive, and uniquely difficult to work with. They often work with senior managers who doubt their value, since these executives believe they’ve got enough brains in-house to run the lean program. They are often considered too expensive, intrusive, or unnecessary by companies convinced that they are indeed lean.

So why is it that I have yet to come across a convincing lean transformation that occurred without a sensei’s help? And believe me, I’m looking. If somehow we could circumvent the high barrier to entry the “sensei” represents, we could greatly accelerate the speed of lean diffusion. It’s just that in my experience, while many companies show some improvement with their lean programs, they fail to distinguish themselves dramatically from their competitors. The dramatic results are to be found in the few instances where the management team has worked with an experienced sensei. Here you will often see a specific – and highly recognizable – blend of radical results obtained through small-step kaizen improvement. We’re talking 15% productivity improvement, 50% defects reduction and 25% stock reduction per year (after two or three years, the gap with competitors really shows). Any given company may not achieve all three aces, but certainly at least one, and sometimes all three.

(These significant results are obtained by radical changes in the process as well, usually visualized by a working pull system and a low-level focus on problem awareness and problem solving.)

So what is it that the sensei actually do? Their power has nothing to do with day-to-day coaching, or a great formal Playbook that he teaches individuals to follow. Recently I visited an automotive parts plant that I’ve known for years. The plant has reduced their in-process WIP to about .7 days, which is good. They had switched off the computer tracking as a way to manage their internal flow even better, as it forced their supervisors to work exclusively with kanban cards. A recently-hired value-stream manager was struggling with the absence of scheduling software. “Guys, what’s the parallel system?” he asked his workers. “I’ve worked in automotive before: no one ever really follows the cards. There has to be a scheduling software somewhere: you can tell me, I’m your new boss.” It took some time for him to accept that there really was no phantom system—that the continuous WIP improvement was due to maintaining the tension on the kanban cards; and pulling some out regularly (which, of course, created many headaches in machine availability and changeovers and so on).

This new manager was just as surprised when he asked to see the manual, and was told that there wasn’t one. “But you had a consultant help you with implementing this pull system,” he asked, “surely he left you some slides?” It wasn’t like that, he was told. The consultant visited once every couple of months and discussed what we were doing with your predecessor. Mostly he pointed out areas where we were not following up on our own ideas and then argued about the one or two big things we should work on for the next step. There never was a manual, because we did all the work ourselves, explained his colleagues. It sort of came together over time. We used to have four days of work in process inventory when we started, but we took it out step by step.

Learning by Doing

This response didn’t help much the new value-stream manager – who, by the way, continued to struggle for a while before figuring out that working at further reducing the WIP was the best way to get “into” the pull system and learn – but it describes fairly well the sensei’s role. Lean’s learning approach is learning by doing, not learning by design. Rather than have several presentations about the ins and outs of a pull system and then try to implement the perfect system all at once, lean learning will occur by working out one problem after another according to a regiment devised by, you’ve guessed it, the sensei. A sensei is a coach who has the experience of taking people through the implementation journey and who can (1) demonstrate current problems and (2) explain what the next step should be (in Mike Rother’s “kata” terms: the next target condition).

Why can’t people figure it out by themselves just by reading the books or using a consultant who will “implement” the tool for them? The trick is to realize that not only does the sensei control the direction of implementation (making sure the lean tool is working as it should on the gemba), but also the rhythm of learning.

By and large, we all feel that we like learning and are eager to do so on the job. But what we mostly have in mind is learning (1) what we think we should learn and (2) at our own pace. What this means, in our culture, is learning more about what we already know to fill in the gaps and get into more detail, and take the time to read and discuss and debate and think before we actually commit to action. Working with a sensei is very destabilizing on both accounts because first, he or she will push you to learn new things (that you haven’t done before at all), which is kinda scary, and worse, will push you to do it at his or her own rhythm – not yours. The deal is “do and then think”, rather than “think, and then do.” This sounds at odds with the notion that the Japanese culture is about “aim, aim, aim and then fire” rather than our tendency to shoot from the hip, but the misunderstanding comes from the fact that “aim” in lean often means “try” in a kaizen situation, before you commit. Learning will occur from reflecting on the kaizen experiments and getting it right until we go for the large-scale radical change.

On the gemba, it’s not an easy proposition. Most people resist the sensei’s comments and indications for a number of reasons ranging from distrust (what does this guy know of our daily work?) to fear (if I start doubling the number of changeovers, I’ll never hit my production numbers) or straightforward annoyance (who does this guy think he is to show me up like this on my own turf? And if he knows the answer why doesn’t he just spit it out?). The point is that most of these emotional reactions to the sensei’s challenge are just that – resistance to having to learn at an imposed pace, rather than at our leisure. Consequently, these reactions are also understandable and totally okay (it’s a free world) as long as they don’t hold back the learning process. You don’t have to like your sensei – just get cracking and do the kaizen.

Any business is an interconnected system: that is an inescapable truth of wholesale improvement. In order to get budget-level sales, cash, cost and capex results one can’t focus only on piecemeal issues – fixing one leg of the table won’t help much is all the other three are not rebalanced as well. Obtaining sustainable business results of the order we discussed simply can’t be achieved by just fixing a few local issues in operations. Experience shows that eliminating a “bottleneck” only means creating another one. It’s the balloon syndrome: squeeze at one end and it will bulge on the other.

Sustaining Improvements

The sensei will help you to construct an approach that encompasses the full company or business unit. For instance, the pull system we were discussing is a particular case of a more general approach. In order to deliver to customers and obtain cash results, the value stream needed an improvement process – not a way to make it work, but a process to drive the improvement on the delivery and cash dimensions. The pull system they built under the guidance of the sensei is this mechanism. The game is not about replacing the MRP with kanban cards, it’s having a system that will lead to improvements sustainably. And indeed, by working with the pull system (first building it and then running it), the value stream manager (should he want to) could identify at every visit one specific area for improvement which would deliver on-time delivery and reduce inventory.

At the plant level, the sensei and the plant manager spelled out a “north star”, a list of dimensions which needed to be improved day in, day out, in order not only to deliver results right now, but also to ensure the future existence of the plant, and its flourishing. These dimensions ranged from the obvious operational issues of safety, quality and lead-time, to cooperation with engineering, machine maintenance, developing technical expertise in specific areas, growing people, working with suppliers and so on.

On each of these dimensions, the sensei helped the plant manager to set in place an improvement process (for instance, what would be the improvement process for better working with engineers? In this specific case, the first step was creating full-size cardboard cutout cells of new projects to collaborate before the machines were finalized). And within each improvement process, the discussion at every visit was about which necessary improvement came out of the process and whether this improvement would deliver results both right now and for the future.

In the end, the resulting lean program had nothing in common with the frequent “apply the roadmap” approach. It could be summarized on a couple of A4 sheets in four columns: Area for improvement – improvement process – specific improvement topic – did it work or not?

The fun part is the sensei really doesn’t know what shape these improvement processes will take – it completely depends of the organization and the personalities involved – just as the sensei won’t have specific ideas about what to improve in each case. The lean program’s fundamental aim is to develop local leadership in improvement so the specific form it will take is unique, a blend of lean principles, the people in the bus and the contextual spot the company finds itself in. The only thing we do know is that if people work hard, they will deliver an order of magnitude in results. It might sound like religion, but that is what tends to happen.

I believe you’ve got to be a genius to learn math out of a textbook. We didn’t like it, but most of us learned math with a teacher who got us through the curriculum. Top athletes don’t require less coaching, but more to keep on the top of their game. Similarly, I’m certain it is possible to learn lean on one’s own through trial and error, but without a firm guiding hand, this is likely to take a while, with not much to show for it in the end. Learning IS hard, and it cannot be delegated. To sum up, the sensei’s role is to:

1) start from the gemba.

2) highlight problems and show the right direction.

3) maintain a rhythm of learning.

4) build up the improvement process, and show good judgment on improvement ideas.

The next question tends to be: “okay, where do I find a sensei?” And to this question as well there is no easy answer. But indeed, this is the first step on the path of “real lean”, the path that leads to radical transformation and spectacular result. And the only answer I know to this question is that finding one’s sensei is the first challenging task in the lean journey.

How Do I Clarify Lean Roles and Responsibilities?

Sun, 22 Aug 2010 04:00:00 GMT

Dear Gemba Coach,

Can you provide some guidance on splitting roles and responsibilities amongst the various hands-on leaders of the lean implementation (lean support group, operations managers, team leaders) in order to get the best mix of engagement and proper process?

Hmmm … this is a very interesting and very politically sensitive question - because of the senior commitment to one approach or another, a decision that is usually made before realizing the ins and outs of either approach (how do you get out of the signed deal with the consultant to run X number of kaizen events?). More than ever, the real underlying debate here is: what are we trying to achieve? To try and answer, I’ll oversimplify two extreme positions, and then we can look for compromises in the space in-between.

Most people will agree that better processes deliver better performance. Short of inventing ab nihilo a newer better process (which many IT vendors suggest), the lean approach is to eliminate waste from existing processes and in doing so improve them, which will improve performance. So far, so good, right? Common sense says that if we take waste out of the process, it will perform better, and so deliver better results. The obvious way to do so is to create a team of lean experts well versed in the lean tools, to line up every business process and to give the lean team the goal of hitting these processes one after the other until the entire business has been “leaned.” By now, experience has repeatedly shown that this lean team runs into trouble both with management and frontline staff, so it’s necessary to give them support.

Show Me the Money

In solving the problem of process performance this way, we generally end up with a lean support group which tackles shop-floor projects “championed” by a senior or middle-manager to deliver spot savings. It is expected that the accumulation of such savings will boost the bottom line. In this approach, most projects are successful and, in the first two years, the support group is highly motivated, well thought of, and learns a lot. As time goes by, two typical issues surface: (1) the lean “savings” can’t be found in the accounts at bottom-line level and (2) many of the process improvements have turned out to be unsustainable. At this stage, the organization typically casts around for solutions with, on the one hand, the senior lean leaders asking “sustainability” questions, and the lean experts finding out that after two years in a “lean” job, it’s hard to go back to the management line.

From very early on, the senseis have been telling us that lean is not about applying the tools to every process but developing the kaizen mindset in every employee. How would that impact the bottom-line? With this angle of view, people make processes, not the other way around (which does not invalidate that the process drives the behavior). The reasoning is the following: more competent people come up with smarter processes, which delivers superior results. In this perspective, waste elimination is the basic training tool to teach employees to better care for their customers, do their job more precisely and understand more deeply the underlying principles of their work.

Boss and Sensei

In the “JOB = WORK + KAIZEN” attitude, the line manager is directly responsible for kaizen. His or her mission is to develop his or her staff, and to do so by getting them to do kaizen and lean their own processes. In the purest form, there is no need for any lean support group as lean is what management does. When Art Smalley recalls his time at Toyota’s Kamigo plant, he describes being taught TPS by the engine shop’s manager Toomo “Tom” Harada – who has the dual role of boss and sensei. Harada himself was a young engineer at the Kamigo plant when it was still run by Taiichi Ohno, its founding plant manager.

Now, few western managers would be up to both manage and teach kaizen to their staff, as few would have been trained that way by their own manager. In practice, when Toyota started transplanting plants out of its home base, the company developed a “coordinator” role. Every mid-level manager (starting with supervisors upwards) was doubled by someone from the mother plant in Japan whose role was to teach kaizen to the western manager – and to coordinate with Toyota City. Most transplants have a “shadow organization” of coordinators to train line managers to their kaizen role. This is not a permanent role – engineers from Toyota in Japan are given this three-year appointment to develop them and give them overseas experience. Any manager in a Toyota transplant would expect to deal with several coordinators during his or her time in the job.

Toyota also created a specialist “lean” group (the Operations Management Consulting Division – OMDD in Europe and TSSC in the US) in the sixties to help suppliers get started with kaizen. This group has evolved in various ways since then, and they would be considered to be the paratroopers of lean – if you need a shock treatment to get going with kaizen, these experts will coach you through projects to teach you the ropes of TPS. Now that does sound like a Lean Support Group, but the underlying thinking is very different. The idea is not to generate results, but to teach. One of my senseis who works for an automotive supplier has been coached continuously for twenty years by OMCD experts, and in some cases doing projects in plants which did not even deliver parts to Toyota.

The point is that between the two extreme positions of on one hand (i) managers manage and lean specialists come in at shop floor level to lean the waste out of their processes (so they can go on managing) and (ii) there is no lean support group because to it managing means improving and it’s managers main job is to teach kaizen to their teams (which is where the team leader comes in as the lead operators to maintain standards and facilitate kaizen), every company, starting where it does, has to find a working organizational design to get moving.

What I’ve learned from studying many lean programs and how Toyota goes about it with suppliers is that the key person to develop lean is the plant manager (or the corresponding unit manager in service operations). Consequently, I frame the question you’re asking in terms of: how can I best develop plant managers. In practice, we often end up with a variety of mechanisms:

1. Senior management visits with a sensei to challenge the plant manager and define areas to work on and overall objectives

2. Personal coaching of the plant manager by an internal lean expert to help him or her understand the details of the tools and their applications in specific shop floor situations

3. A full-time lean specialist working for the plant manager, coached by the corporate lean expert, to train supervisors to run their own kaizen workshops

4. A community of practice of plant managers to support yokoten within the company (both sharing and competing to obtain results).

Plan for Every Manager

There are no cookie-cutter organizational solutions and every company has to reach the proper balance between staff and line roles. For what it’s worth, my take is that the operations manager, plant manager, supervisor, team leader line bear the entire responsibility for getting results by running operations day to day AND doing kaizen. Now, this is a rather tall order, and they often need support. I believe the form this support takes should be ad hoc: whether an internal specialist group, external consultants, trainers, access to a sensei. Most organizations I see run into trouble when they devise a one-size-fits all program irrespective of the training needs of each individual manager.

I don’t know how to answer the question other than by suggesting to try and develop a “plan for every manager” and think on a case by case basis of what kind of support they would need to develop lean thinking. In many cases, the organizations would be very reticent to a tailored approach to lean learning (and would need to control the process tighter), but starting from the learning needs of managers is the best way I can think of to design support roles and responsibilities which will truly engage the line management in their kaizen roles.

Standardized Work in Business Processes

Wed, 11 Aug 2010 04:00:00 GMT

Dear Gemba Coach,

How about standardized work in a business process environment? For example, in a procurement process or supply chain processes? There are not many books/articles on standardized work in a transactional environment. Please help to shed some light on how we should approach standardized work in business processes.

Let’s take a step back here: why would you want to apply standardized work in transactional environments in the first place? As you may know if you’ve followed this column, I’m a great believer in the lean tools, and don’t subscribe to the tool vs. philosophy dichotomy – on the contrary, I firmly believe the tools and principles must be aligned to deliver the hoped-for results.

Lean tools are countermeasures to specific problems. More specifically, lean tools are countermeasures to people who are running a process and not understanding some specific problem in the way they operate this process. A lean tool is above all a standard analysis method enabling people to look at a typical problem. For instance, SMED is about separating internal from external work in changeover in order to make operators see the muda in the way they carry out changeovers. Five S is a tool to visualize zone control in order to make operators realize the muda that is caused by not keeping the right things at the right place, and so on.

As far as I understand, standardized work was developed to help workers find assembly patterns with the least waste and overburden so that the target cycle time can be achieved consistently through the shift. At the gemba, when you watch how operators put products together, very often you’ll see they know what to do (insert these three bolts here, here, and here) but their practice varies on the how – they don’t make the same moves from one part to the next, which leads to quality issues. Also, if the work hasn’t been well designed, operators will tire during the shift and risk professional illnesses as well as not reach the target. As a countermeasure to such issues, Toyota developed the “standardized work” tool to analyze motion, find the best method, and train operators to follow it. Standardized work is clearly a tool for continuous improvement (as opposed to work standards which describe the basic process – the what).

Transactional operations hardly fit in that pattern: few business processes are so rigorously defined that what lean guys call “pre-requisites” would apply. For standardized work, this would be a repetitive cyclical work within a 10-minute cycle, with a stable process and low equipment downtime. Transactional processes often involve interactions between people, and if there’s one thing people hate is being treated as a number: the robocaller, the inflexible administrative staff, the salesperson who refuses to understand your problem and so on.

However, we should be careful because the temptation to “script” is always strong: this is the Taylorist answer to transactional operations. The experts define the perfect interaction and the human operator lends his or her voice to say it out loud, or fill in the right spots on the computer system. However, business interactions are, well, transactions and scripting high variability situations often (1) fail to resolve the problem and (2) angers or frustrates the other party. Positive relationships are an essential part of good outcomes, as they lead to quicker and better problem solving. “Standardizing” such operations prematurely can easily lead to fixing the wrong problem, and be endlessly disappointed by the outcomes.

What is the Problem?

So, before we start thinking: hey, this is a great tool in assembly processes: where else can we apply it – let’s take the question the right way around and try to clarify what exactly are the problems we’re trying to solve?

My experience with business processes is that the “normal” case is usually pretty easy to handle. But then the difficult cases are many, and they all come in differently. It’s like opening a window: 90% of the time, it’s a no brainer, but then when you hit a snag, it can be a real challenge (or am I the only one to struggle with the new window handles that open sideways, upwards, downwards and, well, never just open?). For instance, back at the gemba, I’ve recently been shown an application of “standardized work” (or so they told me) to a banking back office process. The lean specialists had looked at all the possible cases in one simple operation, and written standards, which had then been computerized with rolling menus to be sure that the operator followed the right sequence in the right circumstances. As a result, an operation that took routinely 10 to 20 seconds now took a minute and a half: in 90% of the cases, the operation was really simple and the operators did it perfectly well by hand. In the remaining 10% there were difficulties, and yes, checklists would be useful – but setting the “standard” to engulf all cases simply slowed down the process tremendously (and annoyed the operators). If the only tool you know is a hammer you tend to treat everything as a nail.

Business processes tend to be fluid and interactive – they have only one way of going right (hopefully what happens most of the time) and a zillion ways of going awry. However, because of the very fluidity of the process, most operators know how to deal with the normal situation but are often unprepared to deal when things are off. More to the point, they find it hard to recognize when they are an abnormal situation until it’s reached crisis point, management has to get involved, tempers are high, and everyone loses points.

The aim of a lean tool here would be for a team of operators to learn to (1) analyze their own work and (2) recognize the muda they create by some of their reactions so that (3) they find better ways of handling this.

Firstly, let’s start with outcomes: what constitutes “good work” as opposed to “bad work.” In effect, we need to help them analyze their own work and see the consequences of their own actions. In a procurement office, suggesting that procurement operators are responsible for getting correct parts to the assembly station as opposed to blindly following the IT system (and so managing parts lead time rather than inventory level) usually triggers many adverse reactions – the operators feel powerless to do anything else than what they currently do, and generally have no visibility on the impact of their decisions.

Secondly, we need to help them distinguish normal conditions from problem situations, and help them with basic problem solving skills to work with third parties. In any interaction, the deal and the relationship are equally important outcomes, and basic negotiation skills are essential to help operators resolve issues amicably with their vis-à-vis.

Key Operations

In tackling a business process, I would first get the operators to draw out the chain of agents in the process leading to the customer. In the procurement chain, for instance, we would have the supplier’s producer, the supplier’s planner, the procurement agent, the logistics contractor, the goods-inwards logistics material handler, the operator and so on. Plus we would have supplier sales and our purchasing department involved somehow. Next, we would try to map what each of these departments would consider a good outcome, from their window, and compare it to what kind of outcomes we would need to deliver right first time to our customers.

Having clarified this chain, I would then focus on the key operations leading to a successful outcome – when all goes well so to speak. For these operations I would start discussing work standards (not standardized work): how to stabilize the process of doing certain repetitive tasks to lead to positive outcomes:

1. Which process and what it’s supposed to achieve

2. Sequence of steps to achieve a good outcome

3. Key points at each step to get it right

4. Lists of materials, information or equipment needed to perform

From working on these work standards on key parts of the process, the team can identify basic problems, as in, frequent issues that make the standard inoperable. The goal is to help operators see they are no longer in standard conditions and special care needs to apply. We’ll end up with a checklist of:

1. Frequent problems

2. How to spot them early

3. How to react when this occurs (not problem solving, but next step)

Having clarified common problems in the process, the team can then work on checklists to help operators solve the problem. These very different from “standardized work” inasmuch as problems rarely can be solved with a set sequence of steps in a given time. These are lists of various typical aspects of the problem to check before escalading it to the next level of management. Such checklists are maintained continuously as experienced operators share how they solve such and such problems.

Having done this basic work, we can ask ourselves: how could we improve things so that the problem does not appear – and start the kaizen process. A good book to read on these topics is Steven Spear’s remarkable The High-Velocity Edge [The High Velocity Edge]

To my mind, attempting to apply “standardized work” to business processes is a slippery road. The temptation will be to prescribe greater rigidity in work patterns dealing with fluid and flexible situations. At the end of that road, you find the call center operator chained to his or her phone with a set script or the automated robot caller who drives you crazy.

I’d choose a different route: making sure the business outcomes are properly defined at each point of the chain in the business process. Before we “solve” problems in the value-stream map, let’s make sure these are the right problems. Standards can be very useful there to describe what is a quality interaction, and to explain what is important to succeed at every step, in order to achieve the proper objectives.

The many “standards” tools in lean are about having a discussion with operators to find the most muda-free way of doing a repetitive job. It’s one of the tools that is the easiest to misinterpret as a Taylorist way of getting operators to apply the “one best way” devised by central experts. In business processes, before we even get to discuss standards, it’s well worth working with the team to clarify their understanding of the work they do (in particular, I always find that discussions about what is a good outcome are valuable), what waste is generated by mishandling some specific situations, and what local tricks can we devise to (1) spot that something is going wrong and (2) react immediately to avoid escalation. Working continuously on these ideas will first lead to checklists, and, maybe, if the situation is frequent enough, to standards that will then be taught upfront to the next generation of workers (when this happens, you do that…). But let’s keep in mind that the value of the tools is in teaching people to understand better their own work (and thus improve their performance), not apply blindly the “one best way” someone else has devised for them.

Standardized Work in Machine-Intensive Processes

Wed, 04 Aug 2010 04:00:00 GMT

Dear Gemba Coach,

Most lean literature and case studies to date focus on assembly type manufacturing which utilizes very people-intensive operations. This is not the case in the machine-intensive process industries and therefore has major implications on the format of standardized work. Can you shed some light on what standardized work should look like in the process industries?

Thank you for this question, which provides an opportunity to investigate the point of a lean tool. Many people use magical thinking when adopting tools—assuming that by simply applying them, the process will improve and so will performance. Five S is typically prone to such hopes—and disappointments. Hopeful improvers see endless cycles of 5S drives fail to generate any radical change in either process or performance, because the tool has not been applied for the right reasons.

The crucial lean principle to keep in mind is that lean tools were invented to help people analyze their own work patterns and see the muda they themselves generate in their own processes, so that they can look for better ways to get the job done. “Standardized work” (a set sequence of steps to do within a target cycle time), for example, is a great tool to help assembly operators see that they rarely perform the same tasks the same way, see that this involves a lot of walking, fumbling and creates defectives as well as safety risks, and learn a better way. Consequently, you are right to question whether this applies to machine shops or flow processes. The fundamental question is: which aspect of the work do we want to focus on?

The Core of Standardized Work

Before we get to the nitty-gritty of the tools, let’s go back to the gemba. I recently visited an industrial tannery where raw hides are processed on a conveyor through chemical baths, and then dried in large oven-type equipment. Or, a few years back, I worked with a manufacturer of industrial carpets: huge rolls of materials go through a number of processes in large equipment that fills up entire halls. Where are the operators in such settings? Some operators work at set stations in the process, typically to move materials from one step to the next. For instance, the hides will be taken off the conveyor to be taken to the ovens. This could be automated, but in some cases the flexibility necessary for the operation requires human labor. Operators can also be found doing specific operations such as tool changeovers or material supply. In a machine shop, for instance, an operator’s main job is to bring the part to the machine, insert it and then set the proper tool for machining. This would be true also of the large flow-processing operations such as the carpet making I mentioned. Finally, human operators are also found running the entire process – most commonly within a central control room where the computer system keeps track of all the equipment, and from there, human operators go and perform a number of checks on the machines themselves.

The core idea of standardized work is to determine the most efficient (as in: “muda-free”) work sequence and to repeat it exactly in the same way so that operators avoid unnecessary motion and wasted effort. Standardized work guarantees quality and precision, saves time, maintains safety and prevents equipment damage. But what about when there is no sequence, because a few operators are called to and fro to deal with materials and equipment, but without any apparent cycle to their work?

Standardized work is primarily there to show the operator a muda-free way of working: by referring to the operations standard sheet and the standardized work sheet, operators can find out what they do wrong and correct it, or what they do better, and improve the standard. Secondly, standardized work is essential in helping operators cope with change: change in the mix of products with tool change-over, change in the volume, with more or less people in the shop (and integrating part time colleagues, for instance), change of production with new product introduction and so on. Without standardized work, each of these changes becomes a huge headache that the shop will naturally try to avoid or resist. Standardized work is an essential aspect of flexibility.

Where are the main examples of muda in a machine intensive process shop? By standing in the Ohno circle in any machine shop or process shop we can see muda:

A few operators are isolated at workstations doing either checking or moving components from one process to the next. With all the focus on the machinery, these workstations have rarely been looked at in detail, and are in dire need of being improved.
Most machining or process shops require moving materials and parts to and from the equipment – often in large crates or rolls, and through haphazard routes. Such movement is unavoidable, but essentially muda, and can often be organized as a regular cycle and regular routes.
The periodic jobs which need doing on the machines such as changeovers, basic maintenance, or material supply are themselves muda-prone, as its felt that every time is different and there is no standard way to perform the job. Certainly, any SMED workshop in a machine shop will reveal exactly how unorganized and difficult most tool changeovers really are.
The control part of the process is also rife with muda, as operators move to and fro in large halls to check this or that according to what appears on the computers screen, often after the fact and when they deal with a lot of defectives or rework. Having operators spend their time “babysitting” the equipment is an obvious form of muda in most process industries I’ve seen.
Last – but not least – defectives are often considered as “normal” in process industries: every time tools are changed in a machine shop, or material is changed in a process shop, some parts and some product is considered defective for “setting” purposes. In machine shops, typically, the first part of a batch will be thrown away as part of the setting process. If one reduces the batches to only a few parts at a time to follow real demand, this procedure becomes unbearably wasteful.

#1 Form of Muda

Before we go to the tool itself, we must ask ourselves what can we do to reduce muda in a machine-intensive process shop.

The number one form of muda in a machine shop occurs, not surprisingly, when machines go wrong: either they produce defects, or they break down. To avoid this, labor is utilized to “patrol” the shop and make sure the product is good and that machines run. Most of these activities are either too early (you check but there’s nothing wrong) or too late (something went wrong, and you only find out when you come to check). In effect, the way to fight this source of waste is to be able to spot real-time where you need to be when. The main tool for improving machine-intensive processes is andon, before standardized work.

How can the machines spot something is going wrong and how can they call your attention to it? Jidoka is often seen as the hidden part of the lean iceberg – an engineering technology Toyota has developed to make its machines “autonomous” in the sense of having some judgment over whether they were making parts to specification or working correctly. Think, for instance, of installing captors behind cutting tools to make sure the tolerance are held and to stop the machine if they’re not. Andon (the call mechanism) is essential to waste reduction in a machine shop or a flow process because it takes away the “random walk” of operators checking on the machines. The equipment no longer needs a babysitter – it will call for help when needed. In this manner one can dramatically reduce the resources needed to ensure things run, and invest more in maintenance activities and problem solving to keep the equipment at its nominal value.

The second common form of waste found in machine intensive environments occurs when operators carry out technical tasks such as changing tools or maintenance. Standing in the Ohno circle during these activities it becomes painfully obvious that much of the time is spend going back and forward looking for tools, parts, second-guessing, correcting previous work and so on. Operations standards (the bedrock behind standardized work) are an essential tool to help people minimize muda in these operations. By (1) listing clearly the steps of, says, the maintenance, (2) highlighting the critical point at each step and (3) explaining why this is a critical point, one has a tool both to help operators learn how to do this better, but also to kaizen their own work by analyzing the specific reasons they do not follow the standard at any given time.

Thirdly, a lot of waste occurs as operators shuttle materials from and to the machines. These trips are mostly organized “on demand” and often suffer from conflicting priorities and many mishaps. On this kind of waste, standardized work (a stable sequence of steps) can be very to help operators better organize their delivery and pick-up routes.

I have discussed this question with Art Smalley (author of Creating Level Pull and co-author of Understanding A3 Thinking), who is currently writing a book on standardized work with Mr. Isao Kato the original creator of the modern day standardized work course in Toyota, and his take from his experience in Toyota’s machine shop is that:

“The question is sort of tough to answer and the devil is in the details ... the 100% strict truth is that Toyota does not use pure standardized work in engine or transmission machining lines. The reason is that the work pattern is not cyclical. Instead the operator walk pattern to different stations is dictated by the andon signal. It tells them to go and change cutting tools, conduct quality checks, and find out why machines have stopped, etc. So in the purest sense it is not governed by the three elements of takt time, work sequence, and standard work in process (SWIP). That is mainly for man machine combination that have repetitive work that is the same cycle after cycle.

“In machining we use operator instruction sheets that for all intents and purposes look the same to the untrained eye. They still contain columns on the left for Main Work Elements of the job and a column for Key Points for each step of the job. There will be a picture or diagram to the right and the usual information at the top. If you look closely however the elemental times don't exist and there is no indication for Standard Work in Process (SWIP). In machining we use lots of operation instruction sheets for tool changes, quality checks, gauging of parts, and various tasks such as machine start up, shut down, or some cases involving troubleshooting.”

Andon Challenge

To answer your question, the “standardized work” tool was created to help assembly operators find the best muda-free way of assembling parts. In describing the sequence of steps to achieve in a takt, standardized work is a great tool to learn the proper sequence, and then spot problems in the way we currently do things (if we can’t get the job done with the target cycle time, if we don’t do the operations in the correct sequence, etc.); which then highlights the opportunities for kaizen. In a machine shop or process flow environment, the issues are different, and the first question to solve is how to direct the attention of operators in large, complex and demanding areas. Before addressing standardized work questions, make sure you’ve done enough work on the andon mechanisms. Modifying machines so that they recognize the problems they create is never easy and often a worthwhile challenge.

Secondly, when operators do intervene on the equipment – how do we make sure they do it right? Such activities are usually different from walking around a workstation to use equipment in sequence, but certainly a step-by-step approach can help tremendously, as well as a focus on explicit “pay attention” points at each step (which can often differ from machine to machine”. In this case, operations standard would be the more relevant tool.

In specific cases – the change-over is now down to a few minutes, or there is a materials pick up and delivery route – the standardized work sheet in its classic form of showing the operators’ steps from one station to the next can be helpful to find more detailed waste and work on it. But it wouldn’t be where I’d intuitively start. I’d first make sure operators can tell by themselves when to be where, to do what, and how to go about it to do a good job of it. The key to tools is that they should help the people doing the work better understand how they do their job, and see what kinds of muda they are generating in the process. Different situations do call for different tools.