Geschäftsprozessarchitektur: Was sie ist und warum Prozesslandkarten nicht ausreichen

Sie haben die Prozesslandkarten. Vielleicht sogar ziemlich viele davon. Vor zwei Jahren hat ein Teammitglied ein Swimlane-Diagramm in Lucidchart erstellt. Eine andere Abteilung pflegt eine Confluence-Seite mit Flussdiagrammen, die zuletzt aktualisiert wurden, als noch alle ins Büro gingen. Und wenn an einem Übergabepunkt zwischen Vertrieb und Finanzen etwas schiefläuft oder ein neues Automatisierungsprojekt bei der Integration mit drei unterschiedlichen Systemen scheitert, die dasselbe Konzept jeweils anders beschreiben, sagt jemand: „Wir sollten das besser dokumentieren.“

Das ist die falsche Diagnose. Die Landkarten sind nicht das Problem, und mehr Landkarten werden es nicht lösen. Was fehlt, ist die Struktur, die sie verbindet – das übergeordnete Modell, das Ihnen sagt, welche Prozesse existieren, wie sie zusammenhängen, wem sie gehören und wie sie verbessert werden. Das ist Geschäftsprozessarchitektur. Und es ist keine Dokumentation. Es ist eine Disziplin.

Die zentrale Aussage hier ist falsifizierbar: Die meisten Bemühungen zur Prozessverbesserung und Automatisierung scheitern an ihren Schnittstellen nicht, weil die einzelnen Prozesslandkarten falsch sind, sondern weil keine Architektur sie zusammenhält. Korrigieren Sie die Landkarten, ohne die Architektur aufzubauen, und Sie stehen in 18 Monaten wieder am selben Punkt.

Was die meisten Teams erst nach der zweiten gescheiterten Initiative lernen

• Geschäftsprozessarchitektur (BPA) ist ein hierarchisches Betriebsmodell, keine Sammlung von Diagrammen.
• Eine einzelne Prozesslandkarte ist keine BPA – Architektur organisiert die gesamte Hierarchie und die Governance darum herum.
• BPA benötigt Prozessverantwortliche, Kennzahlen und Change Management, um zu funktionieren; die Hierarchie allein reicht nicht aus.
• Das praktische Signal dafür, dass Sie BPA benötigen: Automatisierungsprojekte scheitern immer wieder an Integrationspunkten zwischen Abteilungen.

Was Geschäftsprozessarchitektur tatsächlich ist

Geschäftsprozessarchitektur ist ein hierarchisches Modell der Geschäftsprozesse einer Organisation, das mindestens zwei Ebenen der Prozesshierarchie abdeckt: die Ebene der End-to-End-Prozesse und die Ebene der Prozessgruppen, die diese enthalten. Das ist die Arbeitsdefinition aus Eficios Forschung zur Prozessarchitektur – und sie ist konkreter, als die meisten Teams erwarten.

Das Wort „hierarchisch“ trägt hier die entscheidende Bedeutung. Ein einzelnes Swimlane-Diagramm, das zeigt, wie ein Vertriebsmitarbeiter eine Verkaufschance durch verschiedene Phasen bewegt, ist eine Prozesslandkarte. Es dokumentiert einen Prozess. Geschäftsprozessarchitektur ist das Organisationsmodell, das diese Landkarte neben allen anderen Prozessen im Unternehmen einordnet, auf mehreren Abstraktionsebenen, und die Beziehungen zwischen ihnen definiert. Ohne die Hierarchie haben Sie keine Architektur. Sie haben ein Diagramm. Das ist nicht dasselbe.

Die Verwechslung ist nachvollziehbar. Beides umfasst Kästchen und Pfeile. Aber eine Architektur gibt jeder einzelnen Landkarte ihren Kontext – wem dieser Prozess gehört, wo er im Verhältnis zu den umliegenden Prozessen steht, was in ihn hineinfließt und was daraus hervorgeht und woran Sie erkennen, wann er geändert werden muss. Eine Prozesslandkarte liefert Ihnen all das nicht. Sie zeigt Ihnen lediglich die Schritte.

Wie sich Geschäftsprozessarchitektur von einer einzelnen Geschäftsprozesslandkarte unterscheidet

Eine Prozesslandkarte ist die Ansicht eines Prozesses. Geschäftsprozessarchitektur ist das Ordnungssystem für alle Prozesse. Die Architekturebene schafft Kontext, den einzelne Landkarten nicht selbst liefern können – und genau deshalb enden Teams, die stark in Prozessmodellierung investieren, bei Widersprüchen, die sie nicht auflösen können.

Das sehe ich in der Praxis immer wieder: Marketing erstellt eine Prozesslandkarte für die Lead-Qualifizierung. Vertrieb erstellt eine Prozesslandkarte für die Übergabe. Keines der Teams koordiniert sich auf Architekturebene, sodass Feldnamen unterschiedlich sind, der Übergabeauslöser in jedem Diagramm anders definiert wird und die Automatisierung scheitert, wenn jemand versucht, beide Bereiche zu automatisieren, weil zwei Landkarten abgeglichen werden müssen, die ohne gemeinsamen Rahmen erstellt wurden. Sie können beide Landkarten bereinigen, doch das Problem kehrt zurück, sobald jemand eine davon aktualisiert, ohne die andere anzupassen.

Prozessarchitektur im Geschäftsprozessmanagement löst dies, indem zuerst die übergeordnete Struktur etabliert wird. Die Architektur definiert Prozessgruppen wie „Lead to Cash“ oder „Kunden-Onboarding“, ordnet End-to-End-Prozesse innerhalb dieser Gruppen ein, und die einzelnen Landkarten befinden sich dann innerhalb dieser Struktur. Wenn Marketing nun seinen Teil aktualisiert, gibt es einen klaren Rahmen, der bestimmt, welche nachgelagerten Bereiche von dieser Änderung betroffen sind.

Ohne Architektur driften Prozesslandkarten auseinander. Sie widersprechen sich abteilungsübergreifend. Verantwortlichkeiten werden unklar. Und Verbesserungsbemühungen geraten ins Stocken, weil sich niemand auf den Umfang einigen kann – weil der Umfang von Anfang an nie auf Architekturebene definiert wurde.

Die Hierarchie, die Architektur zu mehr als einem Diagramm macht

Die minimal funktionsfähige Prozessarchitektur deckt zwei Ebenen ab: Prozessgruppen (Cluster verwandter Prozesse nach Geschäftsbereich oder Wertstrom) und die End-to-End-Prozesse innerhalb dieser Gruppen. Darunter befinden sich Teilprozesse, Aktivitäten und schließlich Arbeitsanweisungen – wobei nicht jede Organisation so tief gehen muss.

Was daraus eine Hierarchie statt einer flachen Liste macht, ist, dass jede Ebene Kontext von der darüberliegenden Ebene übernimmt. Ein End-to-End-Prozess für die „Rückzahlung“ ergibt nur Sinn, wenn Sie wissen, dass er innerhalb der Prozessgruppe Zahlungsdienstleistungen liegt, die wiederum Teil eines breiteren Clusters für Finanzoperationen ist. Die mBank-Fallstudie zur Verbesserung von Zahlungsprozessen zeigt genau das: Die Architekten der Bank modellierten zunächst die Architektur der Zahlungsdienstleistungen und nutzten diese Struktur dann, um den spezifischen Prozess „Rückzahlung“ zu lokalisieren und neu zu gestalten. Die Architektur machte die Verbesserungsinitiative möglich, weil sie dem Team einen Ort gab, an dem es das Problem innerhalb der breiteren Prozesslandschaft finden konnte.

Diese geschichtete Sicht unterscheidet Architektur von Dokumentation. Dokumentation hält fest, was existiert. Architektur gibt Ihnen eine kohärente Struktur, innerhalb derer alles existiert, sodass Sie immer wissen, wo Sie sich befinden.

Wo sich Business Architecture und Geschäftsprozessarchitektur überschneiden – und unterscheiden

Diese beiden Begriffe werden häufig gleichgesetzt, und die Verwechslung bringt Gespräche über den Projektumfang zu den ungünstigsten Zeitpunkten aus der Bahn.

Business Architecture ist die umfassendere Disziplin: Sie umfasst Strategie, Fähigkeiten, Wertströme und Organisationsdesign einer Organisation. Sie beantwortet Fragen wie „Welche Fähigkeiten benötigen wir, um wettbewerbsfähig zu sein?“ und „Wie schaffen unsere Wertströme Kundenergebnisse?“ Die Elemente der Business Architecture – Fähigkeiten, Wertströme, Informationsflüsse – agieren auf strategischer und organisatorischer Ebene.

Die Geschäftsprozessarchitektur ist darin eingebettet. Sie nimmt die Wertströme und Fähigkeiten, die Business Architecture definiert, und fragt: Welche tatsächlichen Prozesse liefern sie, wie sind sie organisiert, wem gehören sie und wie werden sie verbessert? Eine Business-Architecture-Praxis informiert typischerweise die oberste Ebene der Prozesshierarchie und weist BPA auf die richtigen Gruppierungen und Prioritäten hin.

Kurz gesagt: Business Architecture deckt das Warum und Was auf strategischer Ebene ab. Geschäftsprozessarchitektur deckt das Wie auf Prozessebene ab. Beide sind erforderlich. Keines ersetzt das andere.

Was eine funktionierende Geschäftsprozessarchitektur tatsächlich enthält

Die Gluu-BPA-Forschung macht dies ausdrücklich deutlich: Eine funktionierende Prozessarchitektur ist nicht nur ein Hierarchiediagramm. Sie ist ein Blueprint, der Governance-Strukturen, Prozessverantwortliche, Standards, Schnittstellendefinitionen zwischen Prozessen, Leistungskennzahlen und Tags umfasst, die Prozesse mit den von ihnen verwendeten Systemen und Daten verbinden. Die Hierarchie ist das Skelett. All dies ist der Rest des Körpers.

Die meisten Teams bauen das Skelett und hören dann auf. Das Hierarchiediagramm wird erstellt, landet in Confluence, und alle haben das Gefühl, die Arbeit sei erledigt. Sechs Monate später fragt jemand, wem der Lead-Qualifizierungsprozess gehört, und die Antwort liegt irgendwo zwischen einem Schulterzucken und drei konkurrierenden Slack-Threads. Die Architektur existiert visuell. Operativ versagt sie.

System- und Daten-Tags sind wichtiger, als die meisten Menschen erwarten. Wenn ein Prozess mit den Systemen getaggt ist, die er berührt, wissen Sie sofort, welche Automatisierungen und Tools betroffen sind, wenn sich der Prozess ändert. Ohne diese Tags beginnt jedes Automatisierungsprojekt mit einer Erkundungsphase, in der jemand fragt: „Moment, berührt dieser Prozess Salesforce oder HubSpot?“ Und die Antwort lautet: „Wir denken beides, vielleicht.“

Leistungskennzahlen sind der andere Teil, der meist übersprungen wird. Eine Architektur ohne Kennzahlen ist nur ein Wunschbild. Eine Architektur mit Kennzahlen ist ein Betriebsmodell – Sie können tatsächlich sehen, wann sich ein Prozess verschlechtert, und reagieren.

🤔 Denken Sie darüber nach:
Die meisten Teams investieren viel Zeit in Prozessmodellierung und nahezu keine Zeit in Prozessverantwortung. Das Hierarchiediagramm wird erstellt. Niemand wird für seine Pflege verantwortlich gemacht. Es werden keine Kennzahlen definiert. Wenn also ein Prozess scheitert, gibt es keinen Verantwortlichen, der ihn behebt, und keine Messgröße, die bestätigt, dass er behoben ist. Die Architektur existiert als Dokument. Sie wird nie zu einer Disziplin.

Governance, Prozessverantwortliche und die Teile, die die meisten Teams überspringen

Die BPMInstitute-Forschung zu BPA ist hier eindeutig: Effektive Prozessarchitektur erfordert Governance, Prozessverantwortliche, Change Management und Messung. Entfernen Sie eines dieser Elemente, und die Architektur verkommt zu einem statischen Artefakt.

Governance bedeutet, dass es eine definierte Entscheidungsstruktur für Prozessänderungen gibt. Wer darf einen Prozess ändern? Was löst eine Überprüfung aus? Wer löst Konflikte, wenn sich die Prozesse zweier Abteilungen widersprechen? Ohne Governance optimiert jedes Team seinen eigenen Bereich, und die Integrationspunkte zwischen Teams werden zu Niemandsland.

Prozessverantwortliche sind die konkreten Personen, die für die Prozessleistung verantwortlich sind. Nicht das Team. Nicht die Abteilung. Eine namentlich benannte Person. Das ist das Element, das ich in der Praxis am häufigsten ausgelassen sehe. Ein Prozess ohne Verantwortlichen ist ein Prozess, den niemand aktualisiert, wenn sich die Realität ändert, und den niemand korrigiert, wenn entlang dieses Prozesses etwas schiefläuft.

Change Management und Kennzahlen machen die Architektur lebendig statt archiviert. Die Prozessleistung verschlechtert sich mit der Zeit. Marktbedingungen verändern sich. Systeme werden ersetzt. Die Architektur sollte einen definierten Zyklus zur Überprüfung und Aktualisierung von Prozessen haben – und die Kennzahlen, die Ihnen sagen, wann eine Überprüfung überfällig ist.

Genau hier kommen Governance, Verantwortliche, Change Management und Messung ins Spiel. Lassen Sie sie weg, und Sie haben ein teures Diagramm.

Architektur-Frameworks und die Gestaltung von Prozessarchitekturen

Wenn Teams beginnen, Prozessarchitekturen zu gestalten, kommen am häufigsten zwei Frameworks zur Sprache, und sie lösen unterschiedliche Probleme.

Das erste liefert eine Referenztaxonomie: eine Möglichkeit zu prüfen, ob Sie die Prozesslandschaft abgedeckt haben, sowie einen Maßstab, um Ihre Struktur mit anderen Organisationen zu vergleichen. Das zweite liefert eine Designmethodik: eine Möglichkeit, strukturelle Entscheidungen darüber zu treffen, wie Sie Ihre Architektur organisieren, wenn Sie bei null anfangen. In der Regel benötigen Sie beides. Das eine sagt Ihnen, was in der Architektur enthalten sein sollte. Das andere sagt Ihnen, wie Sie sie organisieren.

BPM-Praktiker nennen durchgängig Fähigkeiten in der Prozessmodellierung und im Architekturdesign als Kernkompetenzen für 2026, gerade weil die Gestaltung einer Prozessarchitektur keine einmalige Aktivität ist. Sie erfordert fortlaufendes methodisches Denken, während sich die Organisation verändert. BPMN bleibt die Standardnotation für die Prozessmodellierung innerhalb der Architektur, doch die folgenden Frameworks liegen oberhalb dieser Ebene – sie betreffen Struktur und Klassifizierung, bevor Sie überhaupt einen Ablauf zeichnen.

APQC Process Classification Framework als Ausgangstaxonomie

Das APQC Process Classification Framework (PCF) ist eine branchenübergreifende Taxonomie, die Geschäftsprozesse in 12 Kategorien auf Unternehmensebene organisiert, von „Vision und Strategie entwickeln“ über operative Prozesse bis hin zu „Finanzressourcen verwalten“. Organisationen nutzen es als Ausgangsreferenz, wenn sie ihre eigene Prozessarchitektur aufbauen oder validieren – sie ordnen ihre bestehenden Prozesse den PCF-Kategorien zu, um Lücken, Redundanzen oder inkonsistente Benennungen zu erkennen.

Der Wert des PCF liegt im Vergleich. Da es branchenübergreifend und anbieterneutral ist, bietet es Ihren Organisationsprozessen einen gemeinsamen Referenzrahmen – sodass Sie Ihre Prozessstruktur und -leistung mit anderen Unternehmen Ihrer Branche vergleichen können, die dieselbe Klassifizierung verwenden. Außerdem verhindert es den häufigsten Taxonomiefehler: Prozesse nach Ihrem aktuellen Organigramm zu organisieren, statt nach den tatsächlichen Geschäftsaktivitäten. Organigramme ändern sich. Die zentralen Prozesse eines Unternehmens verändern sich viel langsamer.

Betrachten Sie das APQC PCF als Ausgangskarte, nicht als Ziel. Ihre Architektur wird davon abweichen, abhängig davon, was Ihre Organisation tatsächlich tut. Das ist zu erwarten. Das Framework ist ein Plausibilitätscheck, kein Korsett.

Gestaltung von Prozessarchitekturen nach Falltyp und Geschäftsfunktion

Dijkmans zweidimensionales Designmodell, dokumentiert in der Forschung zum Design von Geschäftsprozessarchitekturen, gibt Teams eine praktische Methode für strukturelle Entscheidungen: Prozesse werden entlang zweier Achsen organisiert – Falltyp (welcher Entitäts- oder Anfragetyp verarbeitet wird) und Geschäftsfunktion (welche organisatorische Fähigkeit die Arbeit ausführt).

In der Praxis bedeutet das, bei jedem Prozess zwei Fragen zu stellen: Was wird bearbeitet (eine Kundenbestellung, ein Support-Ticket, eine Onboarding-Anfrage für Mitarbeitende, eine Rückzahlung) und welche Funktion übernimmt die Bearbeitung (Finanzen, Operations, Customer Success)? Dort, wo sich diese Dimensionen schneiden, finden Sie den Prozess. Die Wertschöpfungskette wird zu etwas, das Sie als Matrix lesen können statt nur als lineare Abfolge.

Das ist für das Design wichtig, weil viele Organisationen entweder zu stark nach Geschäftsfunktionen organisieren – was zu Architekturen führt, die das Organigramm spiegeln und mit organisatorischen Änderungen nicht mehr wartbar werden – oder nach Falltypen zu wenig organisieren – was zu Architekturen führt, in denen derselbe Fall durch multifunktionale Prozesse fließt, für die niemand klar verantwortlich sein kann. Dijkmans Modell hält beide Dimensionen sichtbar, wodurch die resultierende Architektur einfacher zu pflegen und als Grundlage für Automatisierungs- und Verbesserungsprojekte leichter nutzbar ist.

Ebenen der Geschäftsprozessarchitektur: Wie tief die Hierarchie gehen sollte

Die Eficio-Definition legt das Minimum von zwei Ebenen fest – Prozessgruppen und End-to-End-Prozesse –, doch die Hierarchie kann sich in beide Richtungen weiter erstrecken. Dieses Spektrum zu verstehen, verhindert die beiden Fehlermuster, die ich am häufigsten sehe: Architekturen, die so abstrakt sind, dass sie für operative Entscheidungen nutzlos werden, und Architekturen, die so granular sind, dass sie nicht mehr wartbar sind.

Hier ist eine praktische Ebenenübersicht:

Die Ebenen 1 und 2 bilden die Architektur im engeren Sinne. Die Ebenen 3 und 4 sind Prozessmodelle. Ebene 5 ist Dokumentation. Die Architektur umfasst, was auf organisatorischer Ebene existieren muss. Je tiefer Sie gehen, desto mehr erstellen Sie Inhalte für operative Verfahren statt Architektur.

Die meisten Teams mit weniger als 200 Mitarbeitenden müssen die Ebenen 1 bis 3 konsequent pflegen und die Ebenen 4 bis 5 in Dokumentationsform für risikoreiche oder volumenstarke Prozesse verfügbar halten. Für jeden Prozess in einem mittelgroßen Unternehmen bis Ebene 5 zu gehen, ist ein aussichtsloser Kampf. Der Pflegeaufwand übersteigt den Nutzen. Wählen Sie Ihre Tiefe bewusst.

Die BPM-Frage, die die meisten festgefahrenen Gespräche auslöst, lautet meist: „Wie granular müssen unsere Prozessaktivitäten auf Architekturebene sein?“ Die ehrliche Antwort lautet: granular genug, um Verantwortlichkeiten klar zu machen und Automatisierungsprojekte einzugrenzen, aber nicht granular genug für Schritt-für-Schritt-Schulungsmaterial. Das sind unterschiedliche Dokumente für unterschiedliche Zielgruppen.

Wo Enterprise Architecture mit Prozessebenen verbunden ist

Enterprise Architecture (EA) ist das umfassendere Organisationssystem, in das sich Geschäftsprozessarchitektur einfügt. EA umfasst Technologie, Daten, Anwendungen und Strategie – sie verbindet Strategie mit Ausführung auf der gesamten organisatorischen Ebene. BPA ist eine Schicht innerhalb von EA, die sich speziell auf die Prozessdimension konzentriert.

In der Praxis bedeutet das, dass die oberste Ebene Ihrer Prozesshierarchie – die Prozessgruppen – mit den Fähigkeiten und Wertströmen übereinstimmen sollte, die die Enterprise Architecture definiert. EA sagt Ihnen, welche Fähigkeiten die Organisation besitzen muss. Ihre Prozessarchitektur organisiert die Prozesse, die diese Fähigkeiten bereitstellen. Ohne diese Ausrichtung kann die Prozessarchitektur von strategischen Prioritäten abdriften – Sie erhalten dann ein gut organisiertes Bild dessen, was die Organisation tut, statt dessen, was sie tun muss.

Auch die Organisationsstruktur ist hier relevant: Ihre Prozessgruppen sollten unabhängig von der aktuellen Organisationsstruktur definiert werden, aber für das Führungsteam, dem diese Organisationsstruktur gehört, verständlich sein. Eine Architektur, die nur für die Architekten Sinn ergibt, steuert nichts.

Drei Missverständnisse, die Prozessarchitekturprojekte festfahren lassen

Jedes festgefahrene Prozessarchitekturprojekt, das ich gesehen habe, umfasst mindestens eines dieser Missverständnisse. Meistens zwei.

• BPA ist nur ein Workflow-Diagramm

Dieses Missverständnis führt dazu, dass Teams erklären: „Das haben wir bereits“, wenn jemand Prozessarchitektur als Bedarf anspricht. Ein Workflow-Diagramm bildet einen Prozess ab. Geschäftsprozessarchitektur organisiert alle Prozesse auf mehreren Ebenen und ergänzt sie um Governance, Prozessverantwortliche, Kennzahlen und Change Management. Die entscheidende Folge: Teams, die ihre Diagrammsammlung als Architektur behandeln, überspringen die Ebenen für Verantwortung und Messung vollständig. Das bedeutet, dass es beim ersten Prozesswechsel keinen Mechanismus zur Aktualisierung der Architektur gibt. Nach 12 Monaten sind die Diagramme veraltet und niemand vertraut ihnen mehr. Die Kohärenz bricht zusammen – eine undokumentierte Ausnahme nach der anderen.

• BPA ist nur für große Unternehmen nützlich

Kleinere Organisationen benötigen eine angemessene Architektur, nicht gar keine Architektur. Dieses Missverständnis führt dazu, dass mittelgroße Teams die Struktur vollständig überspringen und sich dann fragen, warum ihr Prozessverbesserungsprojekt lokale Vorteile gebracht, aber an anderer Stelle Nacharbeit verursacht hat. Ein SaaS-Unternehmen mit 60 Mitarbeitenden, fünf Abteilungen und 12 Produktintegrationen hat genug Prozesskomplexität, dass undokumentierte Übergaben regelmäßig Fehler verursachen werden. Die Architektur muss kein 300-seitiges Framework sein. Sie muss kohärent genug sein, damit jemand beantworten kann: Wem gehört dieser Prozess, und woran erkennen wir, dass er gut funktioniert?

• BPA kann einmal erstellt und dann unverändert gelassen werden

Prozessarchitektur ist kein Dokument, das Sie ablegen. Sie ist eine Betriebsdisziplin, die sich mit Ihrer Organisation weiterentwickelt. Teams, die sie als einmaliges Artefakt behandeln, stellen fest, dass sie innerhalb weniger Monate nicht mehr die Realität widerspiegelt – Strategien ändern sich, Systeme wechseln, Teams werden umorganisiert. Wenn die Architektur von den tatsächlichen Abläufen abweicht, hören Menschen auf, sie zu konsultieren, und kontinuierliche Verbesserung wird unmöglich, weil niemand ein präzises Bild davon hat, was aktuell existiert. Ein Prozessverbesserungsprojekt auf Grundlage einer veralteten Architektur zielt auf das falsche Ziel.

📊 In der Praxis:
Laut BPMInstitute erfordert effektive Prozessarchitektur Governance, Change Management und Messung – nicht nur ein Hierarchiediagramm. Organisationen, die die Hierarchie ohne diese unterstützenden Elemente aufbauen, geben die Architektur typischerweise innerhalb von 18 Monaten auf. Das visuelle Artefakt bleibt bestehen. Die Betriebsdisziplin entsteht nie. Die Prozessausführung driftet weiter vom dokumentierten Modell ab, bis die Lücke zu groß ist, um sie ohne einen kompletten Neustart zu schließen.

Wann Geschäftsprozessarchitektur sinnvoll ist – und wann sie überdimensioniert wäre

Geschäftsprozessarchitektur ist nicht für jede Situation die richtige Antwort. Ein Startup mit 12 Mitarbeitenden, einem Produkt und vier Prozessen braucht keine formale Architektur. Es braucht klare Verantwortlichkeiten und gute Dokumentation. So erkennen Sie den Unterschied.

Sie benötigen wahrscheinlich eine formale Architektur, wenn Ihre Organisation über 50 bis 75 Mitarbeitende hinauswächst und Übergaben zwischen Abteilungen Fehler oder Verzögerungen verursachen; wenn Sie eine Initiative zur digitalen Transformation durchführen, die mehrere Systeme und Teams betrifft; wenn Sie Compliance- oder Audit-Anforderungen haben, die nachvollziehbare Prozessverantwortung und eine dokumentierte Änderungshistorie verlangen; oder wenn Sie zwei oder mehr Prozessverbesserungsprojekte durchgeführt haben, die ein lokales Problem gelöst, aber an anderer Stelle ein neues geschaffen haben.

Das zuverlässigste Signal, das ich im Support und in Community-Gesprächen sehe: Automatisierungsprojekte, die immer wieder an Integrationspunkten zwischen Abteilungen scheitern. Das ist fast immer ein Architektursymptom. Wenn die Marketingautomatisierung funktioniert, die Vertriebsautomatisierung funktioniert, aber die Übergabe zwischen beiden nicht, liegt das Problem nicht bei den einzelnen Automatisierungen. Es ist das Fehlen eines gemeinsamen Prozessmodells, auf dessen Grundlage beide erstellt wurden.

Wann sie überdimensioniert wäre: bei einer Prozessverbesserung in einer einzelnen Abteilung, einem Automatisierungsprojekt eines kleinen Teams mit klarem Verantwortlichen oder jeder Situation, in der der Umfang eng genug ist, dass eine Person das Gesamtbild im Kopf behalten kann. Formale Architektur verursacht echten Pflegeaufwand. Wenden Sie sie nicht an, wenn eine gut gepflegte Prozesslandkarte mit klarer Verantwortung dasselbe Ergebnis erzielt.

Speziell beim Thema Automatisierung ist der Aufbau einer Prozessarchitektur vor der Automatisierung funktionsübergreifender Workflows einer der klarsten Anwendungsfälle mit hoher Hebelwirkung. Wenn sich Stakeholder auf die Architektur geeinigt haben, kann die Automatisierung auf Grundlage eines stabilen Prozessmodells gestaltet werden, statt auf Grundlage des jeweiligen aktuellen Ad-hoc-Zustands. Eine Leiterin Operations eines mittelgroßen Unternehmens, mit der ich kürzlich gearbeitet habe, brachte es klar auf den Punkt: Sobald sie die Onboarding-Architektur skizziert hatte – nur die Ebenen 1 und 2, klare Prozessgruppen, klare Verantwortliche –, wurden die Geschäftsziele der Automatisierungsinitiative offensichtlich. Sie konnte genau erkennen, welche Schritte für die Automatisierung geeignet waren und welche menschliches Urteilsvermögen erforderten. Vor der Architektur hatte sie geraten. Sie nutzte Latenode, um ihr CRM, Abrechnungssystem und Ticketing-Tool in einer Live-Ansicht darüber zu verbinden, wo sich Kunden im Prozess befanden, mit einem KI-Anreicherungsschritt, der Risikosignale aus Support-Tickets klassifizierte. Die Preisgestaltung pro Ausführung bedeutete, dass ihr mehrstufiger Workflow als eine einzelne Ausführung statt als sechs separate Aufgaben zählte. Doch die Technologie war nur so nützlich wie das Prozessmodell, das ihr zugrunde lag.

Prozesssignale, die auf eine Architekturlücke hinweisen

Diese Muster tauchen in der Arbeitswarteschlange auf, lange bevor jemand zugibt, dass die Architektur fehlt:

Dieselben Daten liegen in zwei Systemen mit unterschiedlichen Werten vor. Niemand weiß sicher, welches davon maßgeblich ist. Das ist ein Architekturproblem im Kostüm eines Datenqualitätsproblems.

Ein Automatisierungsprojekt scheitert bei der Übergabe zwischen zwei Abteilungen. Das BPM funktioniert auf jeder Seite. Die Abhängigkeit zwischen ihnen wurde nie in einem gemeinsamen Modell definiert.

Kennzahlen von zwei Teams widersprechen sich für denselben Prozess. Beide Werte sind nach der jeweiligen Teamdefinition technisch korrekt. Die Architektur war nie vorhanden, um eine einheitliche Definition festzulegen.

Ein neues Teammitglied fragt, welches Prozessdokument aktuell ist. Die Antwort umfasst mehr als zwei Dateien und den Satz „Ich glaube“.

Jeder Engpass, der in mehreren separaten Verbesserungsinitiativen „identifiziert“ wurde, aber nie tatsächlich gelöst wurde. Das bedeutet, er liegt an einer Grenze zwischen Bereichen mit unterschiedlichen Prozessverantwortlichkeiten – und genau dort befinden sich Architekturlücken.

Das Ergebnis eines beliebigen Prozessschritts entspricht nicht dem, was der nächste Prozessschritt als Eingabe erwartet. Jemand führt einen manuellen Abgleich in einer Tabelle durch, um Prozesse und Daten aufeinander abzustimmen, die bereits abgestimmt sein sollten. Das ist eine Architekturlücke in Vollzeit, nur getarnt.