iSixSigma

Global Process? No Such Thing.

The first business process I ever put together was heavily indebted to Kevin Costner. If I build it, I figured, they will come.

And I did build it. A perfect process, polished in every detail. A global process, that everyone involved would adopt. A useful process, that would solve many disparate problems in a foul swoop. The documentation gleamed. The diagrams leapt off the page. The prose flowed like a swift mountain stream. It was a thing of beauty. Everyone was going to do everything the same way, and life would be perfect. But no one came.

In fact, my first process was a complete and utter flop. Despite being well thought out (all the right people were involved), well designed (people smarter than me worked on it), and otherwise pretty solid on paper, we ended up building a road that led precisely nowhere. Why? Because we set out to design the fabled “global process.” And it’s taken me a long time to learn why that almost never works.

The idea of global process is enchanting. Left alone, most organizations will develop several variants of even the simplest common processes. Over time, this leads to variation in output, inability to communicate between areas, and eventually a move away from the very idea of process as “a repeated set of actions.” The endpoint of this progression can be chaos, and chaos is mighty hard to manage.

Handpicked Content :   Textron CEO on Six Sigma

Faced with this possibility, global process seems like a very good idea. The higher you go in an organization, the more fervent the desire to have everyone doing things the same way. And as the experience I described above illustrates, it’s not hard to put a team together to develop a good single process that maximizes benefit to everyone involved.

But once you have that global process in hand, a thorny questions arises. What do you do with it? A good process that exists only on paper is useless. Change management and similar methodologies can help us a lot here, but whatever the new process is and whatever methodology we use to deploy it, we have teach individuals to interact with the process. And it’s generally right around this point that global anything goes out the window.

It has to. Process lives in individuals. As any line manager can tell you, even if you have only 10 individuals to worry about, you can easily spend your entire day trying to get folks to operate a simple process in a consistent manner. You might accomplish it in a technical environment through rigorous, ongoing training and techniques like poka-yoke. But in a transactional or business process environment you wouldn’t have a prayer. Now what about 100 people? Or 10,000? Or 100,000? You get the idea. Unless you intend to hover over every one of them every moment of the day, you can toss the notion of global process out the window.

Handpicked Content :   Customer Focus

I suspect the halls of most corporations are littered with the skeletons of global processes that fell prey to this failure mode. It’s incredibly common. Teams are chartered every day to design processes that never achieve the intended result, or even see the light of day. So what do we do about it? How do we get around the paradox that even global process must necessarily be customized to the environment of every single user?

For me, the answer can be summed up in a word: robustness. The best place to start is not by asking “how can we make everybody do the same thing?”, but rather by asking “how can we accommodate the differences that we know are going to exist anyway.” Or by asking “what do we absolutely have to make consistent?” rather than “what can we make consistent?” This subtle difference in thinking can have a profound effect on the outcome of process design.

Take project tracking. Most Six Sigma programs tend towards forcing all projects into a global tracking system; everyone is asked to do it the same way, with the same templates, forms, deadlines, etc. This is a logical response to the question of “what can we make consistent?” The answer is “just about everything.” But if you scratch below the surface of this supposedly global process, you’ll either find a team of people running hard (and probably failing) to try and make everyone do everything the same way every time, or a lot of practitioners simply ignoring the global process. If you don’t see one of these things, you’ll almost certainly see the other. Which is why global process usually doesn’t exist in practice, although it’s alive an well in theory.

Handpicked Content :   Six Sigma for Sports

But what if we design our system by asking a different question: what is the smallest number of things we can get away with making consistent? The answer is usually a tiny subset of the things that we could make consistent. Maybe we need a few pieces of crucial information on each project at a particular time to feed our roll-ups. Maybe we need a consistent way to view progress towards goals. As for the rest… who cares? So what if everyone does it differently? Does it really matter if a Black Belt working on widgets in Wichita uses the same PowerPoint template as a Green Belt working on new hire provisioning in New Hampshire? Does it matter if their team meetings have the same agenda? Does it matter if they follow the same roadmap? Not to me, and I suspect not to anyone. And furthermore, the chances that I can optimize the process for every environment better than the person actually doing the work are vanishingly small.

Handpicked Content :   Save $700 With iSixSigma Live Pre-Agenda Rate

Armed with this realization, I figured I would work towards an 80/20 rule. That is, I’d build in robustness by leaving 80% of the process local in nature, while doing my best to maintain global consistency around the remaining 20%. In other words, for every 1 thing I was prepared to insist folks do my way, I tried to leave 4 things that they could do however they wanted. This made a tremendous difference in my day-to-day activities (wow – I have time to eat lunch again!) and an even bigger difference in the reception I got. Managing change became a whole lot easier, because the magnitude of change at the individual level was minimal. But the process still looked global from above, much more than when I was trying to make every single thing consistent. It really was paradoxical. It felt like I was doing a lot less work and catalyzing a lot less change, but the outcomes were far more successful that when I had tried to make everything global.

Handpicked Content :   “Good” Continuous Improvement Programs

Think of this as the YouTube approach. To get something on YouTube you need meet only a tiny number of consistent criteria. Your content needs to be video, and you need to be able to upload it via the YouTube interface. What device captures the video? Doesn’t matter. What kind of computer do you use? Doesn’t matter. How do you describe it? Doesn’t matter. When should you upload it? Doesn’t matter. I could go on, but you get the idea. The very little bit of global process that YouTube employs meshing with the massive amount of customization done by the user, which has the effect of democratizing the process as a whole. And paradoxically, this makes the process seem globally consistent, even though it’s almost entirely different for every single person. This is intelligent use of robustness in process design. And it works beautifully.

If those initial efforts taught me one thing, it was that I hadn’t gone far enough. I now tend towards a 90/10 rule, and I’m toying with a 95/5 rule. It works for YouTube, and it’s been working for me.

You Might Also Like

Comments 5

  1. systhinc

    An interesting approach. I have a couple of questions. What is the target vale for your key output values? What are the specification limits? How much variation will guarantee an acceptable CpK? You can figure all of this out for a transactional process. Variation in transactional processes offer two types of error: those which consume time, and those which consume (destroy) material. In both cases, you are aiming for custormer dissatisfaction.

    0
  2. systhinc

    An interesting approach. I have a couple of questions. What is the target vale for your key output values? What are the specification limits? How much variation will guarantee an acceptable CpK? You can figure all of this out for a transactional process. Variation in transactional processes offer two types of error: those which consume time, and those which consume (destroy) material. In both cases, you are aiming for custormer dissatisfaction.

    I don’t believe in "global" processes in the sense that you can get 4000 people to things exactly the same way every time. There will always be variation. The key is to determine HOW MUCH variation will guarantee custormer satisfaction every time.

    0
  3. Andrew Downard

    I agree, and I’m certainly not advocating unacceptable variation in outputs (measured however you like). But I am advocating designing processes that can accommodate variation in inputs. This idea – robust process design – is of course not new or innovative, but I find that a lot of the time it gets lost in the quest for global process, especially in the transactional/business process world.

    I find that if I start off by thinking about what DOESN’T need to be made consistent in terms of inputs, my paradigm shifts. I think about the process differently. That doesn’t remove my obligation to make sure the output is consistent – that comes from voice of the customer, and I generally don’t have the luxury of defining it. But it does keep me from devoting a lot of time and energy to enforcing standardization where it isn’t required.

    If we know Y=f(x) for a process, this discussion becomes moot. But in the beginning we usually don’t, and the appropriate work has tobe done to develop the equation. My suggestion is that we hold off on any standardization work until and unless we know the x we’re standardizing is critical. Like I said, this is not a new or innovative approach, but for whatever reason I still see a lot of people (myself included) default to standardization work long before we have a good understanding of whether it’s really necessary. And in my experience, the number of cases where it is truly necessary is much smaller that you might think.

    Andrew.

    0
  4. Kevin Johns

    I searched for ages on the web to find someone asking a question like this. I have a closely related challenge in that after years of organisational change and process re-engineering in consulting and line roles, I am starting to feel there are no such things as processes, Why did most BPR projects in the 90s fail? And why has Change Management effectively replaced pure-play process-based techniques? It’s because "process" has the people part stripped out. End-to-end process was a useful concept because it steered organisations and people away from functional silos and challenged the concept of bureaucracy, where the customer had to cross many functions to get one service. I think I’m looking for an object-oriented concept of "packages" that contain people, processes and technology but without going back to silo’d organisations. I’ve started to look at organizational routines, case-based approaches and capabilities butI don’t yet have a background in organization theory. Routines seem fuzzy and appear to have been around for a while without particularly catching on. "Capabilities" seem too big. Can anyone help?

    0
  5. Andrew Downard

    Kevin,

    I think I lack the appropriate vocabulary to appreciate your comment. Can you try and explain more fully (and at a lower level) what you are looking for? In particular, what do you mean when you say:

    "I think I’m looking for an object-oriented concept of "packages" that contain people, processes and technology but without going back to silo’d organisations.

    Andrew.

    0

Leave a Reply