Business Process Reengineering: Was es ist und wann es wirklich sinnvoll ist

Business Process Reengineering ist einer dieser Begriffe, die auf nahezu alles angewendet werden und dadurch fast nichts mehr bedeuten. Teams verwenden ihn für alles – von der Optimierung eines Genehmigungs-Workflows bis zum Austausch eines kompletten Betriebsmodells. Diese Lücke zwischen Begriff und Realität ist der Punkt, an dem die meisten BPR-Projekte abstürzen, bevor die Neugestaltung überhaupt beginnt.

Also: Was es tatsächlich bedeutet, wann es sinnvoll ist und warum die Misserfolgsquote beschämend vorhersehbar ist.

Was Teams erst spät lernen

• BPR bedeutet die radikale Neugestaltung von Kernprozessen – keine inkrementellen Korrekturen mit größer klingenden Worten.
• Setzen Sie es ein, wenn die Optimierung des aktuellen Prozesses die Leistungslücke wiederholt nicht schließen kann.
• Die meisten BPR-Initiativen scheitern vor der Neugestaltungsphase, nicht währenddessen – Probleme mit Umfang und Sponsoring bringen sie zuerst zu Fall.
• BPR ist kein Projekt mit Enddatum; Organisationen, die es so behandeln, fallen meist innerhalb von zwei Jahren in alte Muster zurück.

Was Business Process Reengineering tatsächlich bedeutet

Definieren wir zunächst klar, was ein Geschäftsprozess ist.

Business Process Reengineering ist die radikale Neugestaltung von Geschäftsprozessen, um drastische Verbesserungen bei Leistung, Kosten, Geschwindigkeit, Qualität und Service zu erzielen. Keine geringfügigen Fortschritte. Nicht die Verkürzung der Durchlaufzeit um 10 %. Das Ziel ist eine Größenordnungsänderung darin, wie zentrale Arbeit erledigt wird.

Das GAO formulierte es so: BPR beginnt auf einem leeren Blatt. Sie optimieren nicht das Bestehende. Sie fragen, wie der Prozess aussehen sollte, wenn Sie ihn heute von Grund auf neu aufbauen würden – mit den Ergebnissen, die Sie tatsächlich benötigen. Die Perspektive von IBM ergänzt die End-to-End-Dimension: Prozess-Reengineering ist eine Managementdisziplin, die die Grenzen der aktuellen Arbeit hinterfragt, nicht nur die Effizienz einzelner Schritte innerhalb dieser Grenzen.

Was die Neugestaltung von Geschäftsprozessen nicht ist: Sie ist keine kontinuierliche Verbesserung, kein Kaizen und nicht das, was passiert, wenn Sie einem bestehenden Workflow ein neues Tool hinzufügen und es Transformation nennen. Prozessverbesserung arbeitet innerhalb des aktuellen Designs. Was als Business Process Reengineering bezeichnet wird, stellt das Design selbst infrage.

Diese Unterscheidung klingt akademisch, bis Sie zwei Monate in einem Neugestaltungsprojekt sind und feststellen, dass Sie die ganze Zeit einen Prozess optimiert haben, der gar nicht existieren sollte.

Harvard Business Review gab BPR erstmals eine formale Identität in Michael Hammers Artikel von 1990, der argumentierte, dass die meisten Effizienzmaßnahmen die falsche Maschinerie polierten. Die Idee verbreitete sich schnell. Die Umsetzung war deutlich chaotischer.

Business Process Reengineering vs. Business Process Improvement

Die Verwirrung zwischen BPR und BPI (Business Process Improvement) richtet echten Schaden an – Teams definieren Projekte falsch, besetzen sie falsch und messen Erfolg an den falschen Maßstäben. Hier ist der Vergleich ohne Füllmaterial:

Business Process Improvement konzentriert sich darauf, den aktuellen Prozess besser zu machen. BPR fragt, ob der aktuelle Prozess in seiner jetzigen Form überhaupt existieren sollte. Das ist die Trennlinie.

Reengineering mit Werkzeugen zur Prozessverbesserung – Lean, Six Sigma, Workflow-Mapping – ist möglich, doch diese Werkzeuge werden dabei in einem grundlegend anderen Modus eingesetzt. Sie optimieren nicht; Sie gestalten auf Basis dokumentierter Erkenntnisse darüber neu, was nicht funktioniert.

Prozessinnovation liegt näher am BPR-Ende dieser Tabelle. Geschäftstransformation ist der organisatorische Rahmen, in dem BPR stattfindet. Geschäftsprozesse zu nutzen, um bedeutende Veränderungen zu erreichen, ist das Ziel von BPR; Geschäftsprozesse für geringfügige Verbesserungen zu nutzen, ist das Ziel von BPI.

Ein Team, das zwischen beiden wählt, trifft keine taktische Entscheidung. Es beurteilt strukturell, wie kaputt die Sache tatsächlich ist.

Ziele von Business Process Reengineering und seine Auslöser

Das Ziel von Business Process Reengineering ist eine drastische Verbesserung in vier Dimensionen: Kostenreduktion, Verkürzung der Durchlaufzeit, Qualitätssteigerung und bessere Servicebereitstellung. IBM und Bain formulieren dies durchgehend gleich – BPR beseitigt Redundanzen, reduziert unnötige Übergaben, standardisiert Arbeit, die nicht variieren muss, und automatisiert Schritte, die keine menschliche Entscheidung erfordern sollten.

Das sind die Ergebnisse. Was löst die Entscheidung aus, diese durch Neugestaltung statt durch Optimierung anzustreben?

Drei organisatorische Signale führen Teams in Richtung BPR:

Defekte funktionsübergreifende Übergaben, die Verzögerungen, Fehler und Lücken bei der Verantwortlichkeit verursachen und die durch Prozessoptimierung nicht behoben werden konnten. Wenn Arbeit zwischen Teams verschwindet und niemand für die Lücke verantwortlich ist, ist das Problem strukturell.

Nicht wettbewerbsfähige Durchlaufzeiten, die bestehen, weil der Prozess für Einschränkungen entwickelt wurde, die nicht mehr existieren – Altsysteme, papierbasierte Genehmigungen, isolierte Daten. Der Prozess läuft genau wie vorgesehen. Das Design ist das Problem.

Grundlegende strukturelle Altlasten, bei denen der Prozess so oft repariert wurde, dass die Workarounds selbst zum Prozess geworden sind. Niemand weiß mehr, was überhaupt beabsichtigt ist. Optimierung fügt nur eine weitere Schicht Klebeband hinzu.

Wenn die Geschäftsprozesse einer Organisation dauerhaft nicht mit ihren Geschäftszielen übereinstimmen – wenn die tatsächlich ausgeführte Arbeit Ergebnisse erzeugt, die die Geschäftsstrategie nicht tolerieren kann –, ist BPR die rationale Antwort. Nicht weil es angenehm ist, sondern weil der Versuch, einen strukturell falschen Prozess zu optimieren, teuer erkaufte Geduld ist.

Die geschäftlichen Ergebnisse, auf die BPR abzielt, sind nicht abstrakt. Sie zeigen sich als messbare Veränderungen: pro Tag bearbeitete Bestellungen, Zeit vom Lead bis zum Abschluss, Kosten pro Transaktion, Fehlerrate pro 1.000 Einheiten. Wenn Sie diese vor Beginn der Neugestaltung nicht benennen können, sind Sie noch nicht bereit für BPR.

Wenn der aktuelle Prozess das Problem ist, nicht die Ausführung

Auf dieses Signal achte ich immer wieder: Ein Team führt Quartal für Quartal Verbesserungszyklen für denselben Prozess durch, und die Kennzahlen bewegen sich, schließen die Lücke aber nie. Die bestehenden Prozesse werden korrekt ausgeführt. Die Ausführung ist nicht das Problem.

IBM formuliert das klar. End-to-End-Optimierung stößt an eine Grenze, wenn das Prozessdesign selbst die Einschränkung darstellt. Sie können Lean-Sprints für einen Workflow mit vielen Übergaben unbegrenzt durchführen und haben anschließend immer noch einen Workflow mit vielen Übergaben. Sie haben die Übergaben nur etwas schneller gemacht. Prozess-Reengineering ist besonders dann wirksam, wenn unnötige Schritte, redundante Genehmigungen und strukturelle Engpässe im Design verankert sind – nicht in der Ausführung.

Die aktuelle Geschäftsentscheidung, die Sie an diesem Punkt tatsächlich treffen: Ist die Leistungslücke ein Disziplinproblem oder ein Architekturproblem? Wenn dieselben Schritte unabhängig davon, wer sie ausführt, immer wieder denselben Fehlermodus erzeugen, dann ist es Architektur. Die Optimierung des aktuellen Prozesses bringt abnehmende Erträge. Das ist kein Versagen des Verbesserungsteams. Es ist ein Signal, dass die Diskussion weiter vorn ansetzen muss.

Warum die Geschäftsstrategie vor der Neugestaltung stehen muss

Der GAO-Leitfaden zu BPR ist eindeutig: Eine Business-Process-Reengineering-Initiative ohne definierte Ziele und Leistungsbaselines ist keine BPR-Initiative. Sie ist eine kostspielige Aktivität mit unklaren Ergebnissen.

Das ist keine optionale Vorbereitung. Strategie zuerst verhindert Scheitern. Teams, die ein BPR-Projekt beginnen, ohne die Frage zu beantworten: „Welches konkrete Leistungsergebnis verfolgen wir, und woran erkennen wir, dass wir es erreicht haben?“, stellen oft viel zu spät fest, dass sie eine umfassende Neugestaltung des falschen Geschäftsbereichs vorgenommen haben – oder den richtigen Bereich auf das falsche Ziel ausgerichtet haben.

Das Geschäftsumfeld verändert, wie Erfolg aussieht. Ein staatlicher Prozess, der für einen Betrieb mit 50 Mitarbeitenden angemessen war, kann für einen Betrieb mit 500 Mitarbeitenden völlig falsch sein. Definierte Ziele erzwingen diese Diskussion frühzeitig. Ohne sie wird die Neugestaltungsphase zu einer langen Debatte darüber, was der Prozess eigentlich leisten sollte, während die Projektuhr weiterläuft.

Schritte des Business Process Reengineering

Die Schritte von BPR folgen in jeder fundierten Behandlung des Themas einer konsistenten Abfolge. Hier ist die Reihenfolge mit ehrlichen Hinweisen darauf, wo Dinge scheitern.

• Ziele definieren und Leistungsbaselines festlegen

Der BPR-Prozess beginnt damit, was „besser“ in messbaren Begriffen tatsächlich bedeutet – Kosten pro Einheit, Durchlaufzeit, Fehlerrate, Durchsatz. Ohne Baselines wird die Neugestaltung nach Meinungen statt nach Fakten beurteilt. Hier sind die meisten Teams bereits in Schwierigkeiten: Sie möchten direkt zur Prozessneugestaltung springen, bevor der Ansatz zur Prozessverbesserung in Daten verankert wurde.

• Den aktuellen Prozess ehrlich abbilden

Prozessanalyse bedeutet in dieser Phase, zu dokumentieren, was tatsächlich passiert, nicht was laut Handbuch passiert. Ich sehe immer wieder dieses Muster: Der dokumentierte Prozess und der reale Prozess weichen in funktionsübergreifenden Workflows um 30–50 % voneinander ab, weil die dokumentierte Version die Absicht widerspiegelt und die reale Version zeigt, was Menschen tun, um mit den Einschränkungen des Systems zurechtzukommen. Nutzen Sie Process-Mining-Tools, wo Datenspuren vorhanden sind – ERP-Logs, Ticketsysteme, CRM-Zeitstempel –, um den tatsächlichen Prozess sichtbar zu machen, ohne auf Selbstauskünfte von Personen angewiesen zu sein, die dem Prozess zu nah stehen.

• Annahmen hinterfragen und das ideale Prozessmodell entwickeln

Prozess-Reengineering konzentriert sich auf die Neugestaltung von einem leeren Blatt aus, nicht auf Basis der aktuellen Abbildung. Jeder Schritt im bestehenden Arbeitsprozess sollte hinterfragt werden: Existiert dieser Schritt, weil er notwendig ist, oder weil ihn niemand entfernt hat? Tools zur Prozesssimulation helfen hier – Sie können den neu gestalteten Prozess modellieren, bevor Sie sich auf die Umsetzung festlegen. Nur so lassen sich Designfehler erkennen, die erst sichtbar würden, wenn der neue Prozess live ist. Der Fehlermodus in dieser Phase besteht darin, innerhalb der alten Einschränkungen neu zu gestalten. Teams reden sich zurück in das aktuelle Design, weil „das System X nicht kann“ oder „das Team nicht bereit für Y ist“. Das sind Umsetzungsbeschränkungen. Es sind keine Einschränkungen des Prozessdesigns.

• Den neu gestalteten Prozess implementieren

Während des gesamten Prozesses benötigt jeder Schritt des neu gestalteten Prozesses einen Verantwortlichen, einen Zeitplan und einen Rückfallpfad. Der Fehlermodus besteht hier darin, die Implementierung als IT-Projekt zu behandeln, obwohl sie eine organisatorische Veränderung ist. Der reengineerte Prozess kann auf dem Papier richtig aussehen und dennoch scheitern, weil die Personen, die ihn ausführen müssen, nicht an seiner Gestaltung beteiligt waren. Damit kommen Sie zum unten beschriebenen Sponsoring-Problem.

• Messen, validieren und iterieren

Prozessdesign ist mit dem Go-live nicht abgeschlossen. Messen Sie den neu gestalteten Prozess gegen die im ersten Schritt definierten Baselines. Vergleichen Sie Vorher und Nachher. Kennzeichnen Sie Abweichungen, die nicht modelliert wurden. Die OECD-Forschung zu KI-gestützter Produktivität – die in Volkswirtschaften mit hoher KI-Akzeptanz 0,4–1,3 Prozentpunkte jährliches TFP-Wachstum prognostiziert – unterstreicht, warum diese Messphase heute wichtiger ist als vor fünfzehn Jahren: KI-gestützte Neugestaltung bringt neue Fehlermodi mit sich, die in früheren BPR-Wellen nicht vorhanden waren, und Sie werden nicht wissen, was kaputtgegangen ist, wenn Sie nicht gemessen haben, womit Sie begonnen haben.

📊 In der Praxis:
Der GAO-Leitfaden ist eindeutig: BPR erfordert definierte Prozessverantwortliche, messbare Leistungsbaselines und klare Verantwortlichkeit, bevor die Neugestaltung beginnt. In der Praxis würde ich ergänzen: Wenn Sie nicht eine Person benennen können, die für die Leistung des aktuellen Prozesses verantwortlich ist – nicht das Team, nicht die Abteilung, eine Person –, wird die Neugestaltungsphase bei Fragen der Ownership ins Stocken geraten, die bereits in Woche eins hätten geklärt werden müssen. Die meisten BPR-Projekte sind schon vor der ersten Whiteboard-Session in Schwierigkeiten.

Beispiele für Business Process Reengineering in der Praxis

Beispiele für Business Process Reengineering lassen sich anhand von Kategorien leichter erkennen als anhand von Unternehmensnamen. Die meisten Organisationen, die es durchlaufen haben, veröffentlichen keine detaillierten Berichte. Die Muster bei den Anwendungsfällen sind jedoch konsistent genug, dass es nützlich ist, sie zu erkennen.

Betrieb und Finanzen: Durchlaufzeiten und manuelle Übergaben reduzieren

Dies ist der häufigste BPR-Anwendungsfall. Ein Betriebs- oder Finanzteam hat einen Prozess – Rechnungsfreigabe, Weiterleitung von Bestellungen, Debitorenbuchhaltung, Bestandsabgleich –, der mehrere Personen, Systeme und Genehmigungsstufen durchläuft. Die Durchlaufzeit beträgt Wochen, obwohl sie Tage betragen sollte. Fehler vervielfachen sich bei jeder Übergabe. Niemand hat einen vollständigen Überblick.

Wenn diese Teams BPR implementieren, umfasst die Neugestaltung typischerweise die Beseitigung unnötiger Schritte – Genehmigungen, die bestehen, weil sie niemand hinterfragt hat –, die Standardisierung der Dateneingabe, damit nachgelagerte Systeme sie ohne menschliches Eingreifen verarbeiten können, sowie die Einführung von Geschäftsprozessautomatisierung für Schritte, die kein Urteilsvermögen erfordern. Bains Grundsatz, vor der Automatisierung zu standardisieren, gilt hier besonders – wenn Sie einen schlecht gestalteten Prozess automatisieren, erhalten Sie Fehler im großen Maßstab statt Fehler in menschlicher Geschwindigkeit.

Eine Reengineering-Initiative in diesem Kontext könnte einen 14-tägigen Kreditorenprozess auf drei Tage verkürzen, indem vier unnötige Genehmigungsstufen entfernt, drei Datensysteme in einem Workflow zusammengeführt und der manuelle Abgleich beseitigt werden, der nur existierte, weil die Systeme nicht miteinander kommunizierten. Der Business Case der Organisation ist nicht theoretisch. Er zeigt sich im Cashflow-Timing.

Kundengerichtete und öffentliche BPR-Anwendungsfälle

Wenn kundengerichtete Teams Business Process Reengineering in Betracht ziehen, ist der Auslöser meist Servicequalität, nicht Kosten. Reaktionszeiten sind zu lang. Das Kundenerlebnis umfasst zu viele Übergaben zwischen Personen, die jeweils für einen Teil der Interaktion zuständig sind. Lösungsquoten sind niedrig, weil die Informationen zur Bearbeitung eines Anliegens in drei verschiedenen Systemen liegen.

Business Process Reengineering hilft hier, indem der Serviceprozess um das Ergebnis für den Kunden herum neu gestaltet wird, statt um die interne Struktur der Organisation. Diese Unterscheidung ist wichtig. Ein Serviceprozess, der um die Verantwortlichkeit von Abteilungen herum gestaltet ist, erzeugt immer Reibung an Abteilungsgrenzen. Ein Prozess, der um die Problemlösung für Kunden herum gestaltet ist, beseitigt diese Grenzen bereits im Design.

Für Organisationen des öffentlichen Sektors ist die Perspektive des GAO konkret: BPR bedeutet, die Erbringung öffentlicher Aufgaben um Ergebnisse für Stakeholder herum neu zu gestalten, nicht um Behördenstrukturen. Bestehende Geschäftsprozesse in Behörden spiegeln oft das Organigramm statt die Empfänger der Dienstleistung wider. BPR baut den Prozess in diesem Kontext aus Sicht von Bürgerinnen, Bürgern oder Anspruchsberechtigten neu auf, was meist ganz anders aussieht als das aktuelle Design. Geschäftsabläufe verändern sich erheblich, wenn die Ausgangsfrage lautet: „Welches Ergebnis benötigt die Person, die diese Dienstleistung erhält?“, statt: „Was übergibt jede Abteilung an die nächste?“

Vorteile von Business Process Reengineering – und was es nicht lösen kann

Die Vorteile von Business Process Reengineering sind dokumentiert und konkret: Kostenreduktion durch die Beseitigung redundanter Arbeit, Verkürzung der Durchlaufzeit durch den Abbau unnötiger Schritte und Übergaben, Qualitätsverbesserung durch Standardisierung und weniger menschliche Fehler sowie bessere operative Kontrolle, weil der neu gestaltete Prozess einfacher zu überwachen und zu steuern ist.

IBMs Argument für Geschäftsprozesse von Grund auf gilt auch hier. Wenn Sie einen Prozess neu denken, statt ihn anzupassen, ist das Verbesserungspotenzial strukturell, nicht nur geringfügig. Sie holen nicht mehr Effizienz aus demselben Design heraus. Sie ersetzen das Design. Deshalb können Leistungssteigerungen dort drastisch ausfallen, wo inkrementelle Verbesserung ein Plateau erreicht hat.

Doch BPR kann nicht alles lösen, und Teams, die es als universelle Lösung behandeln, stellen dies meist auf kostspielige Weise fest.

BPR kann keine schlechte Strategie reparieren. Eine Initiative für Geschäftsprozessmanagement, die neu gestaltet, wie ein Unternehmen ein Produkt liefert, das niemand haben möchte, ist ein sehr effizienter Weg zum selben Ergebnis. Geschäftsprozesse neu zu gestalten, um drastische Leistungsverbesserungen zu erzielen, funktioniert nur dann, wenn die verbesserte Leistung auf etwas ausgerichtet ist, das der Markt tatsächlich wertschätzt.

BPR kann kein Change Management ersetzen. Der neu gestaltete Prozess kann korrekt sein. Die Organisation muss ihn trotzdem ausführen. Mitarbeitende, die nicht an der Neugestaltung beteiligt waren und nicht verstehen, warum ihre Arbeit am Montagmorgen anders aussieht, sind ein vorhersehbarer Fehlermodus. Prozess-Reengineering ist gerade deshalb eine Managementdisziplin, weil die menschliche Seite der Umsetzung genauso wichtig ist wie die Seite des Prozessdesigns.

Und BPR endet nicht mit dem Go-live. IBM beschreibt es ausdrücklich als kontinuierliche Reise, nicht als einmaliges Projekt. Organisationen, die den Go-live-Termin als Ziellinie behandeln, stellen meist zwischen 12 und 18 Monaten später fest, dass sie wieder in Richtung der alten Muster abgedriftet sind, weil niemand die neuen überwacht hat.

🤔 Moment.
Business Process Reengineering ist nicht abgeschlossen, wenn der neue Workflow live geht – dann beginnt die Messarbeit. Teams, die die BPR-Initiative beim Go-live abschließen, hören auf, den neuen Prozess an den Leistungsbaselines zu messen, die die Neugestaltung gerechtfertigt haben. Ohne fortlaufende Messung scheitert der neu gestaltete Prozess nicht laut. Er wird einfach still und leise zum alten Prozess mit anderen Bezeichnungen.

Warum BPR-Initiativen scheitern und was erfolgreiches Business Process Reengineering erfordert

Die Misserfolgsquote bei BPR-Initiativen ist kein Rätsel. SSRN-Forschung zu Ergebnissen von Prozess-Reengineering dokumentiert immer wieder dieselben Fehlermodi: schwaches Executive Sponsorship, unklarer Umfang, unzureichende Ressourcen und unrealistische Erwartungen. Das sind keine Ausnahmefälle. Das ist das Muster.

Erfolgreiches Business Process Reengineering setzt voraus, dass keines dieser Probleme gleichzeitig vorhanden ist, und das ist eine höhere Hürde, als die meisten Organisationen überwinden. Ich sehe dies immer wieder auf der Support-Seite: Teams, die die BPR-Implementierung als Projektmanagementproblem statt als Problem des organisatorischen Wandels behandeln, liefern oft technisch korrekte Neugestaltungen, die niemand nutzt.

Die BPR-Initiative scheitert, wenn die Personen, die für den neuen Prozess verantwortlich sind, nicht bei dessen Gestaltung geholfen haben. Sie scheitert, wenn die Führungskraft, die sie gesponsert hat, im zweiten Monat in etwas anderes hineingezogen wird. Sie scheitert, wenn der Umfang während der Neugestaltungsphase wächst, weil niemand definiert hat, was dazugehört und was nicht. Und sie scheitert, wenn der erwartete Zeitrahmen für Verbesserungen an einen Budgetzyklus statt an die tatsächliche Komplexität der Veränderung angepasst wird.

Business Process Reengineering erfolgreich zu implementieren bedeutet, diese organisatorischen Bedingungen zu schaffen, bevor die Neugestaltungsarbeit beginnt. Die Methodik ist der einfache Teil.

Die Probleme bei Umfang und Sponsoring, die BPR-Projekte scheitern lassen

Schwaches Executive Sponsorship ist die am häufigsten genannte Ursache für Misserfolge in der SSRN-Literatur, und ich würde argumentieren, dass es auch die ehrlichste ist. Eine BPR-Initiative, die von jemandem gesponsert wird, der nicht bereit ist, strukturelle Entscheidungen darüber zu treffen und durchzusetzen, wer wofür verantwortlich ist, welche Systeme sich ändern und was abgeschafft wird, gerät genau dann ins Stocken, wenn diese Entscheidungen benötigt werden.

Ein BPR-Projekt ohne klar definierte Verantwortlichkeit ist keine Neugestaltungsinitiative. Es ist eine Ausschussberatung mit Gantt-Diagrammen.

Unklarer Umfang ist der zweite Grund für Misserfolg. BPR-Projekte wachsen, weil die Probleme real und reale Probleme miteinander verbunden sind. Sie gestalten den Kreditorenprozess neu und entdecken, dass er mit der Beschaffung verbunden ist, die wiederum mit dem Lieferantenmanagement verbunden ist, das nach Ansicht einiger Beteiligter nun ebenfalls im Umfang liegen sollte, da man ohnehin schon dabei ist. Im dritten Monat versucht die BPR-Initiative dann, die gesamte Finanzfunktion mit dem ursprünglichen Budget und Zeitplan für einen Teilprozess neu zu gestalten. Das ist kein Ehrgeiz. Das ist ein Plan zum Scheitern.

Geschäftsziele klar genug zu definieren, damit Entscheidungen zum Umfang automatisch getroffen werden können, schützt dagegen. Wenn eine Veränderung dem formulierten Ziel dient, gehört sie zum Umfang. Wenn nicht, wartet sie auf die nächste Initiative.

Warum es ein Fehler ist, BPR nur als Automatisierung oder Software zu behandeln

Das sollte direkt ausgesprochen werden, weil dieses Missverständnis in der Ticket-Warteschlange häufig genug ein klares Muster bildet: Teams starten eine BPR-Initiative und meinen damit definitionsgemäß: „Wir implementieren ein neues System.“

Das ist kein BPR. Das ist Softwareimplementierung.

IBM und Bain betonen beide ausdrücklich: Technologie ist ein Enabler im Business Process Reengineering, nicht der Gegenstand. Der neue Prozess ist der Gegenstand. Die Software, die den neuen Prozess unterstützt, ist eine nachgelagerte Entscheidung.

Wenn das Prozessdesign nicht zuerst definiert wird, definiert die Softwareimplementierung standardmäßig den Prozess – und Sie automatisieren den alten Prozess in einem neuen System. Das kostet Implementierungsbudget und erzeugt dieselben Leistungsergebnisse. Der neue Prozess sollte den Workflow bestimmen. Der Workflow sollte die Tool-Auswahl bestimmen. Diese Reihenfolge umzukehren, ist ein Fehler, der am Anfang vernünftig aussieht und sichtbar wird, wenn die erwarteten Verbesserungen ausbleiben.

Prozessdesign kommt zuerst. Die Implementierung folgt. Das ist die richtige Reihenfolge.

Modernes Business Process Reengineering: Wo BPR in einer automatisierungslastigen Umgebung passt

Eine Frage, die direkt beantwortet werden sollte: Ist modernes Business Process Reengineering noch sinnvoll, wenn Automatisierungstools überall verfügbar sind und Teams Systeme an einem Nachmittag verbinden können?

Ja. Tatsächlich macht die Verfügbarkeit von Automatisierung die BPR-Disziplin wichtiger, nicht weniger wichtig.

Hier ist Bains Argument, auf das aktuelle Umfeld angewendet: Standardisieren Sie, bevor Sie automatisieren. Wenn Automatisierungstools günstig und schnell sind, automatisieren Teams ihren aktuellen Prozess unverändert – einschließlich redundanter Genehmigungen, unnötiger Datentransformationen und Übergaben, die aus historischen Gründen bestehen und die niemand mehr erklären kann. Die Automatisierung funktioniert perfekt. Der Prozess war falsch.

BPR in einer automatisierungslastigen Umgebung ist der Schritt, der sicherstellt, dass Sie den richtigen Prozess automatisieren. Process Mining ist das moderne Werkzeug, das dies unterstützt: Es nutzt Ereignisprotokolle aus bestehenden Systemen, um den tatsächlichen Prozess sichtbar zu machen – nicht den dokumentierten, den realen –, bevor die Diskussion über die Neugestaltung beginnt. Das ist direkt relevant für das Problem, das ich immer wieder sehe: Teams versuchen, einen Prozess neu zu gestalten, den sie nie korrekt abgebildet haben, weil der reale Workflow erheblich von dem abweicht, was er nach allgemeiner Annahme sein soll.

IBM beschreibt modernes BPR als kontinuierliche Innovation, nicht als einmaliges Projekt. In der Praxis bedeutet das, Tools wie Latenode einzusetzen, um neu gestaltete Prozessmodelle vor der vollständigen Implementierung zu testen – einen neuen Workflow zwischen bestehenden Systemen zu verbinden, parallel laufen zu lassen und gegen die Baseline zu messen. Mit mehr als 5.500 Integrationen und einem vollständigen JavaScript-Node für individuelle Logik können Sie einen neu gestalteten Prozess schnell genug implementieren, um ihn zu validieren, bevor organisatorische Veränderungen im großen Maßstab erfolgen. Das ist eine grundlegend andere Fähigkeit als jene, die verfügbar war, als die ursprüngliche BPR-Literatur Anfang der 1990er Jahre entstand, und sie verändert das Risikoprofil des Ansatzes.

Die OECD-Analyse zu generativer KI und Produktivität stellt fest, dass KI schnelleres Unternehmenswachstum durch die Automatisierung von Prozessen und Abläufen unterstützen kann – dieselbe Analyse erkennt jedoch an, dass diese Unterstützung davon abhängt, dass die Prozesse überhaupt für Automatisierung geeignet sind. BPR sorgt dafür, dass sie geeignet sind. Prozessinnovation im Jahr 2026 ist noch immer zuerst ein Designproblem und erst danach ein Automatisierungsproblem.

Teams im Bereich Geschäftsabläufe, die den Neugestaltungsschritt überspringen und direkt automatisieren, wetten darauf, dass ihr aktuelles Prozessdesign korrekt ist. Meistens ist es das nicht.