To prevent BPM failure, focus on process design and quality

Editor's Note: In this Q & A, Peter Schooff speaks with consultant Thomas Olbrich about process design and process quality. Olbrich is founder of the Taraneon Group, a process consulting and testing company based in Germany. He's also been a professor, a management consultant and the head of the global workflow-consulting division of a leading BPM provider, as well as the co-founder of several global BPM communities.

PS: Could you talk about the importance of quality management during process design?

TO: It's extremely important for a number of reasons. Remember that with process design, we're trying to either create an improvement to an existing process or we're attempting to design a new solution for a new challenge. So when we look back at how a process has come into the sea of operations, it always begins with a design.

Now, this sounds very simple, but it brings with it the danger that any errors and weaknesses you have in the original process design will be carried over into the following stages, like the IT implementation, the organizational implementation, or—worst of all—into process operations themselves.

The difficulty is that process design works under a different set of assumptions than the process operations parts. It's much more static; the project is isolated; you have different influences. That makes it very difficult to design something that will also perform not only under the project criteria, but also under the operational criteria.

We've also seen in a number of studies that only 18% of reengineering projects actually fulfill their intended objectives. When you look at root causes of these numbers, you will, of course, find reasons such as bad project management, wrong decisions by management and several others.

But the main causes of process failure can actually be traced back to the design phase. That involves errors that force IT to develop some sort of workarounds that may work technically, but don't serve the process objectives. Or it involves something like lack of acceptance by the process users, or simply the fact that process design failed to take into account the dynamics of day-to-day operations.

Quality management really involves the task of providing realistic criteria [early in the project lifecycle]. If we do that, any design errors we can get rid of prior to implementation will help reduce cost and improve the uptake by the organization.

PS: An ounce of prevention is worth a pound of cure, I imagine. So what, then, are some of the key methods then for achieving process quality?

TO: Maybe we can turn that question around a bit and look at the symptoms of missing process quality first.

Let's start with process failures. The first type involves a process that actually works fine and even delivers the intended results and performance —until something unexpected happened in the process environment, such as a noticeable increase in the number of orders or the number of customer inquiries. Then we start to see the process quality degrading, beginning very slowly, sometimes even unnoticeably, on a downward spiral until the process itself ceases to function.

[Another aspect of such failures involves the lack of] flexibility and agility in a situation or environment where the process may work, but doesn't really take into account the dynamics of the customer environment or the employee behavior or the system behavior. Another example—something we've seen a number of times—is where people have successfully completed projects, but the project results—meaning the process—doesn't make the leap into the operation. One reason for that: The process looks fine on paper, but doesn't stand the test of reality, and management refuses to actually put in to operation.

The second category of process problems is probably the most common as well as the most misunderstood and most underrated: process acceptance. Even if you have a process that works, that doesn't mean that employees and customers will accept it. We've all heard employees say [about a new process], "Well, it's different than what we had before, but it's not really better. Why did you put all the money and effort into changing what we had?"

So the very real question on process quality in this case is not "Does the process work?" but "Does it work how we wanted it to work?" Or, from an employee's point of view: "Do I want to work like that in the future?" What we see time and again is that, on paper, these new processes are probably deployed—but, at the same time, shadow processes come into existence. That's when the employees actually work in a completely different way to that demanded by the official process.

What's remarkable here is that nobody really seems to notice, or want to notice, until you do a process audit. We recently had a case at a major European financial institution in which 90% of the official processes had nothing to do with how people actually worked. Those shadow processes actually did the work because people were more comfortable with them. So validation and acceptance of processes plays an important part in process quality management.

A third category involves errors and weaknesses in process logic. The question here is: "Does the process work at all?" Now, without wanting to sound too cynical, my impression is that, over the years, process quality management has been reduced to [this question]: "Does the process model look nice and good?" If it does, many people automatically assume that it will be just as nice and good once you breathe the reality of operations into it.

But the fact is, that's probably the wrong approach because when we test processes in the [Tareneon] process test lab, we often find any number of design errors that actually prohibit the process from working. Those mistakes only come to light afterwards, when, for example, when you implement the process or want to put it into operations. Then, of course, you have to put an awful lot of time and money and effort into correcting those original mistakes you made in the design phase.

But one thing I should mention here is that making mistakes is not only natural, but also sometimes unavoidable. [Anyone involved with] process quality has to understand that those mistakes do get made and you have to take the appropriate measures [to deal with them]. That's what you need special process quality management for.

PS: Companies today need to be quite dynamic, which means, essentially, that processes are constantly changing. How can companies in this environment achieve process agility?

TO: This is a very important question. Everybody seems to be talking about agility, but nobody really seems to know what process agility actually means.

I think you would have to start with process information and process awareness. The questions to ask are: "Does everybody understand his or her processes? Are our process documentations up-to-date? Do we understand how our processes actually work and how they react with other processes?"

The reason I mention this in the context of agility is that we've seen that up to 40% of project time actually gets spent on the discovery phase—meaning trying to find out how we currently work. Now if you are forced to change your processes as quickly as you can, that 40% of project time spent on discovery could better be spent on process improvement or actually implementing those changes even faster.

The other thing about agility is that the most agile elements in our processes are still the employees. Our systems are usually very rigid and hard to change. It takes a lot of time; it takes a lot of expert knowledge. But our employees are very flexible.

The problem here is that we've tended to keep process workers in the dark about what their processes actually are. They know how to perform their individual tasks, but not really in which context they perform them. We recently did a survey on process awareness. Only 20% of the employees we asked were aware of the individual process responsibilities and the accountabilities.

On the other hand, we've also found that the more process-aware employees are, the more agile they've become. And once employees become more agile, process change and acceptance of process change [increase]. So I think that is a basic requirement for achieving agility.

You know, we had this expression "employee empowerment" a couple of years ago. That was one of the buzzwords; I think it's since turned into—I wouldn't call it a dirty word, but something like it. Now when you regard this [approach] as a sort of social BPM, it might actually be a golden opportunity to create process agility. Having empowered, informed, process-aware employees—that would probably be the road to take if you want to become more agile.

PS: What other big mistakes do companies make with their processes?

TO: There's one other factor that has recently come to light: the influence of the level of fluctuation in a company with regards to process accountability and process responsibility.

If you have a high level of fluctuation among process managers, nobody will really take control and ownership of a process. They'll administer a process for certain period of time and then leave to do something else—take over another process or go to another function in the company. So there's a correlation between the level of fluctuation of process managers and the quality of the processes they manage. Once we get a grip on that, one of the main factors for decreasing process quality will probably be eliminated.

This Q & A was excerpted from a more in-depth ebizQ podcast on process design and process quality. It has been edited for length, clarity and editorial style.

About the Author

Peter Schooff is a former contributing editor for ebizQ, where he also managed the ebizQ Forum for several years. Previously, Peter managed the database operations for a major cigar company, served as writer/editor of an early Internet entertainment site and developed a computer accounting system for several retail stores. Peter can be reached at

More by Peter Schooff

About ebizQ

ebizQ is the insider’s guide to next-generation business process management. We offer a growing collection of independent editorial articles on BPM trends, issues, challenges and solutions, all targeted to business and IT BPM professionals.

We cover BPM standards, governance, technology and continuous process improvement, as well as process discovery, modeling, simulation and optimization, among many other areas. We follow case management, decision management, business rules management, operational intelligence, complex event processing and other related topics. We closely track important trends such as the rise of social BPM, mobile BPM and BPM in the cloud. We also explore BPM’s use in functional areas, such as supply chain and customer management, and in key verticals, such as financial services, health care, insurance and government.

ebizQ's other BPM-oriented content includes podcasts, webcasts, webinars, white papers, a variety of expert blogs, a lively online forum and much more.