The demise of business processes

Why business processes lose their value in a post-industrial context and what to use instead

Uwe Friedrichsen

8 minute read

Small battered street leading to the sea

The demise of business processes

Whenever you come to a client as an IT consultant, it will not take long before someone will start talking about business processes. A typical narration is like “That’s a nice idea. But we need to make sure that everything is aligned with our business processes”. This is not limited to IT projects. If you create a new product, if you touch the organization or change anything else: it needs to be aligned with the business processes. The whole company seems to revolve around their business processes.

To be fair: business processes are so widespread for a good reason. They are a useful and well-established tool to organize the internal course of operations. But there is a catch many people do not realize.

Let us start with the good case: if you live in an industrial market context (see this post for a short introduction to industrial and post-industrial markets), where cost-efficient production and delivery is your primary driver, everything is fine: business processes are a valuable tool for organizing operations in such a setting.

The downsides of business processes

But if you live in a highly dynamic, post-industrial setting where the needs and demands of your customers are ever-changing, the focus on business processes often is counter-productive: business processes focus on the internal organization of a company. To design such a process, a relatively consistent request pattern from the market (i.e., the customers) is assumed and then the most efficient way to respond to this request pattern is described.

In a post-industrial setting this approach has two caveats:

  1. Designing and implementing a business process that responds to a given demand in the most efficient way comprise a significant fixed cost. This fixed cost leads to change inertia: if you redesign and re-implement the processes too often, the fixed costs for design and implementation will exceed the saved costs at runtime. Thus, you try to avoid regular business process redesign. Yet, request patterns change all the time in a post-industrial market due to its high dynamics. This makes the whole concept of expensive upfront design of efficient operations questionable because the underlying premise – rarely changing external request patterns – is not met anymore.
  2. Business processes focus on the internal view. Typically, the external market view is almost completely neglected in business process design. At the very beginning the external requests are analyzed once. Afterwards, they are considered fixed and all energy is focused on internal optimization. In business process design the customer is just a marginal figure.

Of course, some people will contradict: “But we do all this to deliver the best value to the customer”, they will say. Well, let us be honest: the focus of business process design is optimizing internal operations, not maximizing customer value (whatever that “value” thing means - I will come back to that question in a different post). “Customer value” is just an ostensible justification. The whole concept of business processes is about the question “how do I deliver X efficiently and repeatable”, not about “how do I create value for a customer”.

The assumption that optimizing internal delivery automatically results in customer value is a relict of industrial market thinking (again, see this post for more details). In an industrial market where demand exceeds supply by far, optimization of delivery also increases customer value. But in a post-industrial setting, customers only buy from you if you meet their needs and demands better than your competitors. Optimizing delivery does not mean at all that you satisfy your customers' needs and demands. Creating value for a customer in such a setting means a lot more than just organizing delivery.

Of course we need to deliver some value to the customer, even in industrial markets. If we would totally ignore our customers' needs, also in an industrial, high-demand setting they would not buy from us. Still, the sole focus of business process design lies on efficient organization of internal operations, not on creating customer value.

Or, as I like to put it in a bit provocative way:

As soon as companies start to focus on business processes they have lost sight of their customers.

Thus, especially in highly dynamic post-industrial markets where adapting to the ever-changing needs and demands of the customers is the key to survival, organizing the whole company around business processes quickly becomes harmful.

Employing use cases to establish customer focus

This immediately raises the question how to do better. I guess, there are probably a lot of possible answers to this question. An approach that works well for me is focusing on use cases instead of business processes. Before you start thinking about the bloated template monsters, use cases have become in the early 2000s: if I talk about use cases, I always refer to the original, very lean concept of use cases.

You can (still) find that lean definition looking at the work of Ivar Jacobson, the inventor of use cases. E.g., in Use-Case 2.0, a freely available e-book, he defines use cases like this:

Use Case: A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.

Taking this definition, we can derive the following key properties for good use cases:

  1. Focus on the perception of external users
  2. Focus on the value for external users
  3. Holistic view on the purpose of a system
  4. Very lightweight (if done right) 1

Use Cases focus holistically on customers and value while business processes focus on detailed cost-efficient internal operations

While many people limit use cases to IT system design, they actually can be applied to any kind of system, providing a lightweight way to holistically describe the purpose and value proposition of a system from its users' point of view. This means we can employ use cases also to describe the purpose and value proposition of a whole company (or parts of it).

This is exactly what we need in a post-industrial setting: use cases are a lightweight means to capture the needs and demands of our customers, i.e., what they expect from us in terms of value and interaction patterns. Note that this is very different from the focus of business processes.

You can augment a use case description with a simple interaction diagram, describing the flow of requests and answers between a customer and the company in order to deliver the promised value to the customer. I find this useful because it is very easy to create and gives you a lot of information how the value delivery feels from a customer’s point of view. 2

User interaction diagrams describe the flow of customer requests and company responses

Usually, it is very hard (or even impossible) to understand this important service quality based on business process models.

Putting it all into perspective

You may counter that it is also possible to use business processes in lightweight ways and that you remember heavyweight use case modeling from the past. Sure, that is possible. You may even put an emphasis on good customer interaction patterns in business process modeling if you want to.

The point is that usually it does not work this way. Typically, the focus of business processes on internal operations becomes independent over time. Also, optimizing for cost efficiency typically reduces the focus on reaction speed. As a consequence, time and resource consuming implementation efforts are considered fine as long as the expected cost-savings at runtime exceed the implementation costs. The resulting high fixed costs for the design and implementation of business processes in turn lead to change inertia.

Are business processes bad per se? No, they are not. If you live in an industrial setting where reaction time is of minor relevance and cost efficiency is key to success, business processes are your tool.

But if you live in a highly dynamic post-industrial market that is driven by customer needs and demands, they quickly become counter-productive. Use cases offer a better alternative in such a setting because they are focused on customers and the value they receive. And if you apply them in the intended way, they are also very lightweight, i.e., the effort to create and change use cases is small. This in turn supports short reaction times.

Business processes can also help in such a post-industrial setting. After you understood customer needs and value flow in a holistic way, e.g., employing use cases, you still need to implement your internal service delivery processes. That is where business process design can support you. You only need to keep two things in mind:

  • Whatever you are going to implement will very likely become obsolete soon. Having this in mind helps not to overdo it and avoid high fixed costs.
  • Never lose sight of your customers. Always make sure that business processes do not become an end in itself. Always remember that the actual goal is to meet your customers' needs and demands as good as possible.

  1. E.g., Use-Case 2.0 defines a set of principles that are essential to the successful application of use cases. The first principle is “Keep it simple by telling stories”. In other words: use cases should be used in a lightweight, not too formalized way to unleash their actual power. ↩︎

  2. If you think that those concepts are too simple to be useful: over time I realized that usually the opposite is true, i.e., often very simple visualizations are a lot more powerful than complex ones. Take the interaction diagrams shown here: they are dead simple. Still, you can immediately understand how good your customer interaction patterns are by looking at them. Additionally, they even help you to understand if you created the right system boundaries in your IT systems, if the user interface design supports a good customer experience, what APIs you might need to expose, and more – just using a dead simple representation, plus a healthy dose of brain power. ↩︎