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:
- Which process and what it’s supposed to achieve
- Sequence of steps to achieve a good outcome
- Key points at each step to get it right
- 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:
- Frequent problems
- How to spot them early
- 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.
