Home / Customers / Innovation / Don’t Automate, Obliterate!

Don’t Automate, Obliterate!

Our business simulation is intended to show the business impact of improving and even redesigning a rather simple business process – the effect of Business Process Re-engineering (BPR). Basic yet powerful tools come to play. Process KPIs as well as customer satisfaction and customer KPIs are a gauge for the degree of improvement. We have been running this simulation nearly a hundred times with teams from different industries. We had employees at various organisational levels. Yet, we have observed the following interesting behaviours:

BPR Simulation Key Learnings

BPR Simulation Key Learnings

  1. After experiencing the initial round of the simulation with intentionally sub-optimal process design, teams very frequently raise two requests: need more staff, need IT support.
  2. When given the chance to re-design the process, 90% of all teams tend to move their team members around to cover up process weaknesses instead of analysing and closing gaps.
  3. More often than not, teams focus on internal matters rather than customer requirements.

Our simulated process has a few intended flaws built in. The most time-consuming process step shows a backlog building up. That step can be easily improved with one very simple change that costs nothing whatsoever. This would lead to a much better flow. Additionally, this would give a reduction or even a complete removal of the backlog. However, only less than 10% of all participating teams find this “trick” without help by the facilitator. More than 50% of all teams try to add manpower to this task. Or, they opt for automating this step instead of looking closer and removing the obstacle.

There has been a significant increase in IT solutions during the business simulation since its introduction more than ten years ago. It is correct, that some tasks can run automatically just by using a hand phone. However, it does not make sense to automate a task that no one needs – after understanding how the process really works.

The sobering fact is, that teams tend to automate before understanding the process.

The sobering fact is that, teams tend to automate before understanding the process. If our business simulation findings would give any indication about real business process re-engineering (BPR) work, we would have to conclude that many IT solutions have been bought prematurely, many broken processes are still broken, just faster and many opportunities in business processes are still uncovered.

Why is this like that? It seems that IT support, an Android or iPhone App serve as silver bullets for many problems. Nowadays, Cloud-computing is the up-to-date method and can’t be wrong. Opposing against these approaches is like fighting against the time. Good old process mapping and process improvement seem like outdated approaches that belong to previous generations. Michael Hammer, the godfather of business process re-engineering, once said

Automating a mess yields an automated mess.

Simulating BPR – Conclusion

Our teams usually end their business simulation successfully. After learning and experiencing some eye-opening truth about the process, they are able to cut the lead time drastically, increase customer satisfaction to the highest level and have even fun doing so.

Only a small percentage of this improvement is due to IT support. Most of it is a result of understanding the process and optimising the flow using good old BPR tools.

2 Responses so far.

  1. UK says:

    Dear Nathan,
    it starts getting really strange when we put support processes on an app. For instance, we spend money automating feedback and complaint handling instead of putting our resources in reducing any feedback and complaint. OK, this does not apply to all organisations. But it does to banking and insurance. The best is, not getting in touch with them at all and everything runs smoothly.
    Uwe

  2. Nathan says:

    Yes, I agree. We currently have a hype towards putting everything on an app. I have seen in our organisation how people develop an app for a service that is really not necessary to be on an app. We were better off not doing it at all. As you said, developing an app is less painful than rethinking the business model and the process running it.