Die erste Welle des Business Process Reengineering scheiterte aus einem ehrlichen Grund: Die Technologie jener Zeit konnte nicht liefern, was die Theorie versprach. 1993 konnte ein Unternehmen einen Prozess auf einem Whiteboard neu zeichnen, doch die darunterliegenden Systeme waren starr, batchgebunden und schwer zu integrieren, sodass die Neugestaltung entweder an der Grenze des Großrechners ins Stocken geriet oder zu einer Kostensenkungsübung im Gewand der Transformationssprache verkam. Die Idee war stichhaltig und das Werkzeug war es nicht, und beide wurden gemeinsam in Erinnerung behalten.

Diese Beschränkung hat sich weitgehend aufgelöst. Programmierschnittstellen sind heute eine Standarderwartung statt eines maßgeschneiderten Projekts. Event Streaming, Cloud-Datenplattformen und Orchestrierungs-Engines machen es machbar, einen Prozess zu komponieren, der über mehrere Systeme of Record hinweg läuft, ohne Daten von Hand zwischen ihnen zu transportieren. Was einst eine heldenhafte Integration war, ist heute gewöhnliches Engineering. Die Folge ist, dass die Reengineering-Frage, lange aufgeschoben, weil sie zu teuer zu beantworten war, wieder handhabbar geworden ist, und sie kehrt in den meisten Organisationen unter anderen Namen zurück: Order-to-Cash-Neugestaltung, Customer Onboarding, Lieferresilienz, Beschleunigung des Finanzabschlusses.

Die Versuchung, die Reengineering-Frage aufzuschieben, ist verständlich und nicht mehr sicher. Jahrelang war es der rationale Weg, zu warten, weil die Integrationskosten jeder ernsthaften Neugestaltung den Nutzen überstiegen, und die Unternehmen häuften Behelfslösungen an, in der zuversichtlichen Erwartung, dass sie mit dem nächsten Systemupgrade gelöst würden. Das geschah selten. Jedes Upgrade bewahrte die alte Prozessform, weil die Migration der Form billiger war als ihre Infragestellung, und das zufällige Design verhärtete sich zu scheinbarer Dauerhaftigkeit. Was sich geändert hat, ist, dass Wettbewerber, die die Frage stellen, nun auf die Antwort reagieren können, und ein Prozess, der doppelt so lange dauert oder doppelt so viel kostet, wird nicht mehr dadurch verdeckt, dass alle anderen gleich langsam sind.

Es gibt einen zweiten Grund, warum die Frage jetzt zählt. Drei Jahrzehnte der Einführung von Unternehmenssoftware haben die meisten Großunternehmen mit einem CRM zurückgelassen, das den Kunden abbildet, einem ERP, das die Transaktion und das Finanzwesen abbildet, und einer Supply-Chain-Suite, die Material und Kapazität abbildet, jeweils von einer anderen Funktion zu einer anderen Zeit nach einer anderen Logik konfiguriert. Die Prozesse, die tatsächlich Wert schaffen, einen Auftrag entgegenzunehmen und zu erfüllen, einen Kunden zu gewinnen und zu bedienen, das Angebot gegen die reale Nachfrage zu planen, laufen quer durch alle drei. Die Organisation ist nach Funktion gegliedert; die Arbeit ist nach Fluss gegliedert; und die Lücke zwischen beiden ist der Ort, an dem sich Kosten, Verzögerung und Fehler sammeln. Reengineering ist die Disziplin, diese Lücke bewusst zu schließen, statt sie mit Tabellenkalkulationen und gutem Willen zu überkleben.

Die Grunderkenntnis des Reengineering, und weiterhin diejenige, die am meisten leistet, ist, dass ein Unternehmen wahrheitsgetreuer durch seine Prozesse beschrieben wird als durch sein Organigramm. Ein funktionszentriertes Unternehmen optimiert jede Abteilung an ihren eigenen Zielen: Der Vertrieb maximiert die Abschlüsse, der Betrieb minimiert die Stückkosten, das Finanzwesen schützt das Umlaufvermögen. Jedes ist für sich rational, und die Summe ist oft im Ganzen schlecht, weil die Übergaben zwischen den Funktionen, dort, wo der Kunde tatsächlich wartet, niemandem gehören. Ein prozesszentriertes Unternehmen kehrt dies um. Es benennt die durchgängigen Flüsse, die zählen, gibt jedem einen Verantwortlichen mit echter Befugnis über die funktionalen Grenzen hinweg und misst den Fluss als Ganzes: Durchlaufzeit, First-Pass-Yield, Cost-to-Serve, Cash Conversion.

Daraus folgt eine harte Vorfrage, auf deren Beantwortung wir bestehen, bevor irgendeine Neugestaltung beginnt: reengineern oder schrittweise verbessern? Die beiden sind nicht austauschbar, und ihre Verwechslung ist in beide Richtungen teuer. Schrittweise Verbesserung ist die richtige Wahl, wenn ein Prozess grundlegend gesund und lediglich mit Verschwendung überkrustet ist; hier zahlen sich die Werkzeuge von Lean und kontinuierlicher Verbesserung schnell und sicher aus. Reengineering ist nur dann gerechtfertigt, wenn der Prozess Annahmen verkörpert, die nicht mehr gelten, wenn die Abfolge der Schritte aufgrund einer Beschränkung existiert, die inzwischen verschwunden ist, oder wenn das gewünschte Ergebnis durch keinerlei Feinabstimmung des bestehenden Designs erreichbar ist. Der Test, den wir anlegen, ist unverblümt. Wenn Sie nicht bei diesem Prozess hätten ankommen können, indem Sie von einem leeren Blatt aus für das heutige Ergebnis entworfen hätten, ist er ein Kandidat für die Neugestaltung. Wenn Sie es gekonnt hätten, ist er ein Kandidat für die Verbesserung.

Das dritte Prinzip lautet, dass ein Prozess, der CRM, SCM und ERP umspannt, nicht in einem von ihnen allein neu gestaltet werden kann. Der Kundenstamm, der Produktstamm, die Preislogik und der Auftragsstatus sind gemeinsame Fakten, die redundant und oft inkonsistent in allen drei Systemen leben. Eine echte Neugestaltung muss entscheiden, wo jeder Fakt erzeugt wird, wie er sich fortpflanzt, und welchem System vertraut wird, wenn sie sich widersprechen. Deshalb behandeln wir Daten und Integration nicht als nachgelagerte Umsetzungsfrage, sondern als die Substanz des Designs selbst. Das Prozessmodell und das Datenmodell sind zwei Sichten auf dieselbe Sache, und ein Reengineering-Vorhaben, das schöne Prozessdiagramme hervorbringt und die Datenverantwortung ungeklärt lässt, hat in Wahrheit nichts reengineert.

Ein viertes Prinzip untermauert die anderen drei: Prozess, System und Organisation sind nicht drei Dinge, die aufeinander abzustimmen sind, sondern eine Sache, aus drei Blickwinkeln betrachtet. Wenn sie als getrennte Arbeitsstränge mit getrennter Steuerung behandelt werden, optimiert jeder für seinen eigenen Abschluss, und sie treffen beim Go-live in wechselseitigem Widerspruch aufeinander. Das System erzwingt einen Fluss, für dessen Ausführung die Organisation nicht besetzt ist, gegen Daten, die der Prozess als sauber angenommen hatte. Sie als eine einzige Entscheidung zu entwerfen, ist intellektuell anspruchsvoller und in der Praxis weit günstiger, weil die Widersprüche auf dem Papier gefunden werden statt in der Produktion.

Das Feld bewegt sich, und nicht immer in die Richtung, für die die Anbieter werben. Ein paar Muster verdienen eine klare Benennung, weil sie verändern, wie eine Neugestaltung anzugehen ist.

Composability statt Monolith. Die Annahme, dass eine einzige ERP-Suite den größten Teil des Prozesses besitzen sollte, weicht einer Architektur spezialisierter Systeme, die durch Integration verbunden sind. Die Kundeninteraktionsschicht, die Planungs-Engine, der finanzielle Kern und die Fulfilment-Systeme sind zunehmend voneinander getrennt, nach ihren jeweiligen Vorzügen ausgewählt und zu einem Fluss zusammengesetzt. Das ist befreiend für das Prozessdesign, weil Sie nicht mehr an die Meinung eines einzigen Anbieters gebunden sind, wie Order-to-Cash funktionieren sollte, doch es verlagert die Schwierigkeit in die Integrations- und Governance-Schicht, die nun die Kohärenz trägt, die früher der Monolith bereitstellte.

Process Mining als Evidenz. Über den größten Teil seiner Geschichte begann Reengineering mit Workshops, in denen Menschen beschrieben, wie sie glaubten, dass der Prozess funktionierte, was verlässlich eine Fiktion war. Process Mining rekonstruiert den tatsächlichen Prozess aus den Event-Logs, die die Systeme ohnehin ausgeben, und zeigt jede Variante, jede Nacharbeitsschleife und jede Umgehung so, wie sie wirklich auftritt. Wir betrachten es inzwischen als nahezu fahrlässig, eine Neugestaltung ohne diese Evidenz zu beginnen. Sie ersetzt Meinung durch eine gemessene Ausgangslinie und liefert später das Instrument, das Ihnen sagt, ob sich die Neugestaltung in der Produktion wie beabsichtigt verhält.

Cloud-ERP und die Zwei-Ebenen-Realität. Der Wechsel zu Cloud-ERP wird oft als Gelegenheit verkauft, zu Standardprozessen zurückzukehren und Jahre der Anpassung aufzugeben, und für wirklich gängige Arbeit ist das ein guter Rat. Doch derselbe Schritt verhärtet sich häufig zu einer Zwei-Ebenen-Landschaft, einem standardisierten Kern, umgeben von den spezialisierten Systemen, die die tatsächliche Unverwechselbarkeit eines Unternehmens tragen. Die Designfrage lautet daher nicht, ob anzupassen ist, sondern wo die Unverwechselbarkeit rechtmäßig lebt, indem man den Kern nah am Standard hält, während man dem Rand erlaubt, abzuweichen, und die beiden bewusst statt zufällig integriert.

Automatisierung wandert von der Aufgabe zum Prozess. Die erste Generation der Automatisierung, insbesondere Robotic Process Automation, ahmte meist einen Menschen nach, der sich durch Bildschirme klickt, was den bestehenden Prozess verfestigte, statt ihn neu zu gestalten. Das nützlichere Muster besteht heute darin, den neu gestalteten Fluss auf der Ebene des Prozesses zu automatisieren, mit Orchestrierung und nativer Integration, und die bildschirmnahe Automatisierung für die echten Ränder vorzuhalten, an denen keine Schnittstelle existiert. Einen schlechten Prozess zu automatisieren, lässt Sie ihn nur schneller ausführen.

Ein neu gestalteter Prozess ist nur so gut wie die Architektur, die ihn trägt. Mehrere Designprinzipien trennen Neugestaltungen, die halten, von denen, die still zum Alten zurückkehren.

Eine einzige Quelle der Wahrheit je Fakt, nicht je System. Der Instinkt, ein System zum Herrn über alles zu erklären, ist ebenso falsch wie gar keinen Herrn zu haben. Die Disziplin ist feiner: Benennen Sie für jede bedeutsame Entität und jedes Attribut genau ein System, das es erzeugt, und lassen Sie die übrigen es abonnieren. Das CRM mag die Kundenbeziehung besitzen, während das ERP das rechtliche Konto und die Kreditposition besitzt; worauf es ankommt, ist, dass die Verantwortung ausdrücklich, vereinbart und durchgesetzt ist, sodass der Abgleich aufhört, ein monatliches Ritual zu sein.

Integration als Vertrag, nicht als Verbindung. Punkt-zu-Punkt-Schnittstellen, in Eile gebaut, werden zum brüchigsten Teil der Systemlandschaft, weil jede Annahmen kodiert, die niemand aufgeschrieben hat. Wir gestalten Integration als versionierte Verträge mit definierten Events, Payloads und Semantiken, vermittelt über eine Schicht, die Veränderung auf beiden Seiten absorbieren kann. Das Ziel ist, dass ein System hinter seinem Vertrag ersetzt werden kann, ohne dass jeder Nachbar es wissen muss.

Den Prozess beobachtbar gestalten. Ein Prozess, der im Flug nicht gemessen werden kann, kann nicht gesteuert werden, und die meisten können es nicht. Wir bauen den neu gestalteten Fluss so, dass sein Zustand, seine Zeiten und seine Ausnahmen von Konstruktion an als Events ausgegeben werden und dasselbe Process Mining speisen, das die Ausgangslinie ermittelt hat. Beobachtbarkeit ist keine nachträglich hinzugefügte Instrumentierung; sie ist eine eingebaute Eigenschaft, und sie ist es, die dem Prozess erlaubt, sich nach Projektende weiter zu verbessern.

Für Umkehrbarkeit entwerfen. Eine Neugestaltung, die nur vorwärtsgehen kann, ist eine Neugestaltung, gegen die Widerstand entstehen wird, weil die Kosten eines Irrtums katastrophal sind. Wir bauen die Migration so, dass jedes Inkrement angehalten, parallel zum Bestand betrieben und rückgängig gemacht werden kann, wenn die Evidenz es verlangt. Das ist keine Zaghaftigkeit; es ist das, was Kühnheit bezahlbar macht. Wenn eine Änderung günstig umkehrbar ist, wird eine Organisation Änderungen versuchen, die sie unter einem Alles-oder-nichts-Umstieg niemals riskieren würde, und es sind genau diese Versuche, die sich zu echter Transformation summieren.

Für die Ausnahme entwerfen, nicht für den Idealfall. Die meisten Neugestaltungen werden für die Transaktion gezeichnet, die sich brav verhält, und die meisten Kosten liegen in jenen, die es nicht tun: die Teillieferung, die strittige Rechnung, der Kunde, der zweimal unter leicht abweichenden Namen existiert. Ein Prozess, der seine Ausnahmen an eine Tabellenkalkulation und eine willige Person leitet, ist nicht entworfen worden; er ist halb entworfen und im Rest dem menschlichen guten Willen überlassen worden. Wir modellieren die Ausnahmepfade ausdrücklich, entscheiden, welche häufig genug sind, um einen erstklassigen Weg durch das System zu verdienen, und welche wirklich selten genug sind, um sie durchdachter manueller Arbeit zu übergeben, und wir machen diese Unterscheidung zu einer bewussten Wahl statt zu einem Zufall dessen, was die Software gerade unterstützte. Das wahre Maß einer Neugestaltung ist, wie sie sich an ihrem schlimmsten Dienstag verhält, nicht an ihrem besten.

Die Weisen, auf die diese Programme scheitern, sind konsistent genug, um katalogisiert zu werden, und die meisten sind Versagen des Urteilsvermögens statt der Technologie.

Big-Bang-Ablösung des ERP. Der teuerste Einzelfehler ist, das ERP abzulösen und die Prozesse in einem einzigen gleichzeitigen Umstieg über das gesamte Unternehmen hinweg neu zu gestalten. Die Theorie lautet, dass ein sauberer Schnitt die Kosten des Betriebs zweier Welten vermeidet; die Praxis ist, dass sich das Risiko potenziert, weil jedes Problem auf einmal auftaucht, ohne Möglichkeit, die Ursache zu isolieren, und das Unternehmen die Fähigkeit zum Rückfall verliert. Wir bevorzugen eine Neugestaltung, die nach Prozess und nach Domäne geliefert wird, wobei der neue Fluss auf einem begrenzten Umfang bewiesen wird, bevor er ausgeweitet wird. Eine gestufte Migration ist langsamer und weit wahrscheinlicher am Ziel anzukommen.

Das bestehende Durcheinander automatisieren. Ein Programm, das den aktuellen Prozess abbildet, ihn getreu automatisiert und das Ergebnis Transformation nennt, hat sehr viel ausgegeben, um schneller in die falsche Richtung zu gehen. Automatisierung sollte auf die Neugestaltung folgen, sie niemals ersetzen.

Das Diagramm reengineern, nicht die Organisation. Eine Neugestaltung, die das System und den Prozess ändert, aber die Anreize, Rollen und Berichtslinien unangetastet lässt, wird von den Menschen, denen sie Unbequemlichkeiten bereitet, still rückgängig gemacht. Wenn der Prozess nun funktionsübergreifend ist, aber die Boni funktional bleiben, gewinnen die funktionalen Ziele. Prozessverantwortung ohne Befugnis ist Dekoration.

Aufgeschobene Datenschuld. Teams verschieben die Stammdaten- und Qualitätsarbeit routinemäßig als unglamourös und beabsichtigen, sich ihr später zu widmen. Später trifft der neu gestaltete Prozess, der saubere und konsistente Daten annahm, auf die reale Sache und gerät ins Stocken. Datenqualität ist keine Aufräumaufgabe neben dem Projekt; sie ist eine Voraussetzung dafür, dass der Prozess überhaupt funktioniert. Beraterisch geführtes Design ohne Operateure im Raum verschärft dies: Eine ausschließlich von Spezialisten gezeichnete Neugestaltung wird das stillschweigende Wissen der Menschen verfehlen, die die Arbeit ausführen, den Grund, warum ein Schritt, der überflüssig aussieht, in Wahrheit tragend ist, die Ausnahme, die wöchentlich vorkommt und nie dokumentiert wurde. Wenn diese Operateure dem neuen Prozess erstmals in der Schulung begegnen, entdecken sie seine Lücken, und ihr Vertrauen, einmal verloren, ist teuer zurückzugewinnen.

Umfang nach System statt nach Ergebnis. Programme, die als ERP-Projekt oder CRM-Projekt beauftragt sind, erben die Grenzen der Software statt der Grenzen der Arbeit, und die systemübergreifenden Flüsse, die genau dort liegen, wo der Wert sitzt, fallen in die Lücken zwischen den Strängen. Der Auftrag sollte ein Ergebnis und einen Fluss benennen und die Systeme darin fallen lassen.

Wir beginnen beim Fluss und beim Ergebnis, nicht beim System. Bevor wir irgendeine Änderung vorschlagen, legen wir fest, was der durchgängige Prozess erreichen soll, in Begriffen, die das Unternehmen wiedererkennt, Durchlaufzeit, Cost-to-Serve, Cash Conversion, Kundenaufwand, und wir messen den Ist-Zustand daran anhand der Event-Daten, die die Systeme bereits vorhalten, statt anhand der Geschichte, die die Menschen in Workshops erzählen. Diese gemessene Ausgangslinie entscheidet den ersten Streit, ob der Prozess Reengineering oder Verbesserung verdient, auf Grundlage von Evidenz statt Begeisterung.

Wo eine Neugestaltung gerechtfertigt ist, entwerfen wir den Prozess, das Datenmodell und die Integration gemeinsam und behandeln sie als drei Sichten auf eine Entscheidung statt als drei aufeinanderfolgende Projekte. Wir klären die Verantwortung für jeden geteilten Fakt über CRM, SCM und ERP hinweg ausdrücklich, definieren die Integration als versionierte Verträge und machen die Orchestrierung des Flusses zu einem prüfbaren Artefakt statt zu Logik, die über die Konfiguration verstreut ist. Der neu gestaltete Prozess wird so gebaut, dass er seinen eigenen Zustand ausgibt, damit er in der Produktion gegen dieselbe Ausgangslinie gemessen werden kann, die ihn gerechtfertigt hat.

Wir liefern nach Domäne und nach Fluss, niemals per Big-Bang-Umstieg. Ein begrenzter Ausschnitt des neu gestalteten Prozesses wird in der Produktion an realen Transaktionen bewiesen, bevor er ausgeweitet wird, sodass das Risiko isoliert bleibt und das Unternehmen die Fähigkeit zum Rückfall behält. Durchgehend behandeln wir den organisatorischen Wandel, die Verantwortung, die Anreize, die Rollen, als Teil des Engineerings statt als nachträglichen Gedanken, weil ein Prozess, für dessen Ausführung die Organisation nicht eingerichtet ist, nicht überleben wird. Unser Ziel ist eine Neugestaltung, die sich nach unserem Weggang weiter verbessert, weil die Instrumente zu ihrer Steuerung von Anfang an eingebaut wurden.

Wir sind offen, was das Tempo betrifft. Eine Neugestaltung, die drei Systeme of Record umspannt, kann ehrlicherweise nicht in einem Quartal abgeschlossen werden, und jeder Vorschlag, der es verspricht, verkauft einen Umstieg statt einer Neugestaltung. Wir sequenzieren die Arbeit so, dass jede Domäne für sich eine messbare Verbesserung erbringt, was das Vertrauen und die Aufmerksamkeit für die nächste verdient, statt das Unternehmen zu bitten, durch ein mehrjähriges Programm für einen einzigen fernen Lohn den Atem anzuhalten. Diese Sequenzierung diszipliniert auch das Design selbst: Ein Fluss, der verpflichtet ist, seinen Wert auf einem begrenzten Ausschnitt zu beweisen, kann sich nicht hinter dem Versprechen verstecken, dass am Ende alles zusammenpassen wird. Wenn ein Ausschnitt das Ergebnis nicht verbessert, das zu verbessern er beauftragt war, entdecken wir es weit lieber an einer Domäne als an allen dreien zugleich.

Was unsere Arbeit im Prozess-Reengineering auszeichnet, ist, dass wir uns weigern, CRM, Supply Chain und ERP als getrennte Territorien mit getrennten Neugestaltungen zu behandeln. Wir halten den durchgängigen Fluss, die Daten, die durch ihn laufen, und die Organisation, die ihn betreibt, in einer einzigen Sicht, und wir klären die harten Fragen der Verantwortung und Integration als Designentscheidungen, statt sie auf die Umsetzung zu verschieben. Das ist ein schwierigeres Gespräch zu beginnen und ein weit dauerhafteres Ergebnis abzuschließen.

Es gibt auch eine praktische Folge, die verändert, was die Arbeit annehmen darf. Wenn ein Engagement eine Fähigkeit erfordert, die noch nicht existiert, muss es nicht auf einen Beschaffungszyklus oder die Roadmap eines Anbieters warten. Die Nashua 360 Enterprise Platform ist darauf ausgelegt, nahezu jede Funktion im Tempo aufzunehmen, durch extreme Vibe Coding: Was benötigt wird, wird in einfacher Sprache beschrieben und rasch generiert, doch stets innerhalb fester Architekturprinzipien und unter strenger Qualitätssicherung, sodass Geschwindigkeit niemals auf Kosten von Kohärenz, Sicherheit oder Kontrolle geht. Die Wirkung ist strategisch statt bloß bequem. Sie verschiebt die Make-or-Buy-Grenze, hält Optionalität günstig und lässt die Architektur der Strategie folgen, statt dass sich die Strategie dem beugt, was gerade zufällig im Regal stand.

Der Lohn für diese Disziplin ist eine Reihe von Kernprozessen, die tun, was das Unternehmen tatsächlich braucht, gemessen an Ergebnissen, die ihm wichtig sind, getragen von einer Architektur, die sich ändern kann, ohne zu brechen, und betrieben von einer Organisation, die eingerichtet ist, sie auszuführen. Das ist es, was Reengineering immer liefern sollte, und mit dem heutigen Werkzeug kann es das endlich.