How Can Our Back Office Sustain Lean?
How Can Our Back Office Sustain Lean?
Dear Gemba Coach,
The improvement program at the back office of the bank at which I am a lean facilitator is slipping. For the past several years, we have improved operations by visualizing daily performance, conducting daily briefs and teaching team leaders to solve problems. We have progressed visibly in quality and productivity. Recently however I am finding our lean progress harder to sustain. Teams that were doing great slip back and we seem to have to constantly regain lost ground. Is there a way to make lean more sustainable?
There is, and it involves the question of whether you are pulling—but let’s spend a moment framing this challenge.
Sustainability is and will always be an issue in lean because of the human factor. We not constructing a mechanical organization that runs like Charlie Chaplin’s clockwork factory (and God help us if we were!); rather, we’re coaching a football team. And as any fan knows, a team’s performance is, by nature, hard to sustain over time, because it depends on the players, the coach, and the circumstances. The same types of challenges apply at the Gemba.
Our lean lenses can help us analyze this challenge with more rigor. Basically, we can identify three specific workplace diseases that produce waste and which eventually arrest lean progress. They are:
- No confirmation: a failure to understand clearly the purpose of the job you’re asked to do. People need to be able to confirm bad from good (as opposed to blindly follow procedures) and to have some autonomy to make smart calls in different conditions.
- Overburden: are you certain that workers are in good working conditions without having to deal with any unreasonable barriers such as too much work, too many interruptions, hard to handle software, unclear processes, arbitrary managers and so on?
- Unlevelness: every day chaos as work is done in fits and starts, long batches and last minute panics, too many procedural changes, and all the various forms of instability that stop one from getting a grip and thinking clearly.
The lean approach towards this is not to create the perfect process, but to strive constantly to improve the conditions of the working process. This is an important distinction. Performance is not delivered by designing and then tightly controlling the perfect organization (sorry to pop your Taylorist balloon), but by generating positive dynamics through engaging in daily problem solving. People will naturally function better as a team even individually when they are in the habit of working together to solve problems. Solving problems together stirs a pioneer spirit in even the most administrative back office where the main task is data copy, as well as the craftsman’s interest for the job, no matter how narrow and repetitive. The point is that people will be interested in what they do – whatever it is – if you keep them interested.
And there’s the rub: how can we develop the kaizen spirit in a sustainable, generative, continuous way? How can we keep back office teams solving problems together day in day out, when they’re sitting in a basement doing apparently pointless repetitive jobs, such as checking credit applications or routine IT maintenance tasks? Experience shows there are three key ingredients to keep the PDCA wheel turning:
- The manager’s attitude: time and time again we see that managers who are engaged with their workers produce greater lean success. If the frontline manager is genuinely interested in improving performance BY working with her teams to solve local problems and to involve every brain in the room in finding local knacks to make work easier, then people will continue to engage in problem solving and progress as a team. I’ve been visiting some companies for half a dozen years, and the lean teams that sustain success are always proud to show me how they’ve changed this or that to continue to improve their performance. And it comes down largely to whether the manager “gets it” or not.
- Improvements must benefit the team: in some cases, I’ve met with managers who do “get it”, but have failed to get their departments to accept that change is a normal part of the job. These guys work very hard at problem-solving, but experience recurring slip-backs and need to be re-motivated again regularly. At first, I believed naively there was some fault in them, that they lacked some kind of leadership trait I could not see. But then I realized it doesn’t have to do much with them as managers, but with their higher ups. In some organizations, workers are moved around all the time and/or the pressure for productivity is relentless. As a result, whatever improvement made on a local station won’t benefit the person who had the idea because either this worker is pulled somewhere else or management will take all the benefit and never give anything back.
- The team must also trust its own ability to solve problems. Some well-meaning managers solve all the “small issues” in order to focus the team on the large problems. This seldom ends well, as all the people learn from this is reliance on the manager. Motivation stems from success. In order to keep motivated, teams must regularly experience successes on their own terms. As a manager this means cherry picking problems so that they are both challenging (a bit) and solvable.
Unfortunately, many frontline bosses consider that their job is to tell people what to do when—and when. They use this limited power to (deliberately or not) reward the people they like with “plum” jobs and punish those they don’t with the nasty work no one likes. The problem is that nobody who works for these bosses cares about kaizen because it doesn’t change the fundamental unfairness of work.
Enter the pull system. Let’s go to a glamorous back office where people are supposed to check movie and TV production projects for approval for grants from a large foundation. At the Gemba, the work isn’t so glitzy: a team of people work in crowded offices making sure the administrative part of the folder is correct before passing it on to the decision makers. They are organized by “specialties” and are asked to track their response time. Since work comes in irregularly, when response time of one person increases beyond the three-week target, the head of the office is supposed to go and help this worker solve problems. This often comes down to giving that extra file to someone else. Some times it’s the last in the queue, some other times it’s the tricky case that we’d all like to get rid of. There is nothing particularly bad in the way this office works, nor anything especially surprising. There are files stacked all over the place, and frequent people dramas and breakdowns, which is surprising because the department head is a caring gentle soul who genuinely tries to help his staff.
One day, the department head switches to pull. He creates bins with three vertical slots and a central waiting queue. The idea is that files are opened by his assistant and put in the central stack, and from then on into one of the checker’s “three slot” bin when there is an empty slot. At first, they all argue against this because they are so specialized no one could possibly do each other’s job. So they have a working session to isolate the really specialized cases, but they quickly agree that it could be interesting to look at other files as well. In two weeks time, the inventory is down to zero (which is problematic because it shows there is one head too many) and the extra time is used to focus on many improvement projects that had been put on the side-burner for lack of time.
What happened? Pull system magic. The pull system takes away from the manager the decision of what to do, so that he or she can focus on how to do it.
In a back office situation, the pull system also evens out the workload between employees, which, it turns out, is a huge benefit to them. Evening out the workloads liberates time to solve problems, problems that are now highlighted by the pull system (when someone’s bin gets clogged up). People now see that solving problems will help them improve their performance, not some abstract group performance (careful there: we don’t measure individual performance, only team, but now every person can see their contribution to the team).
One further overburden issue is that, fairly often, the best worker gets the hardest cases – and so is “punished” in terms of performance for her competence. The pull system will highlight this and help people deal with the situation better.
Finally, the pull system creates a working environment with strong incentives for the manager to keep solving problems – if he or she doesn’t the situation will quickly revert to what it was before and every one will notice.
The earliest paper I’ve found on lean is a 1977 piece by Sugimori et al called Toyota production system and Kanban system materialization of just-in-time and respect for human system. Quite a mouthful, but there you have it: JIT and respect go hand in hand. Over the years, I’ve found that a pull system tends to be the best (or least worst) answer to the sustainability question. And even so it doesn’t sustain itself by itself, since someone has to ratchet up the level of Just in time to lower the water in the lake, make the rocks appear and keep people interested in solving problems.
I haven’t come across one situation yet where pull is natural. Every one has their reasons to explain (honestly) that pull won’t work in their special case. With back-office work, I’ve found that visualizing a central queue of files and dispatching regularly to individual queues is a good place to start, but you’ll probably have to make your one up as you go. My father’s sensei’s advice was: “don’t interpret just-in-time at your convenience.” Start from there, and see where it gets you – my bet is that any pull system will make kaizen more sustainable than none.
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?