Hier ist eine Verwirrung, die ich ständig erlebe – in Supportgesprächen, Onboarding-Calls und Projekten zur Neugestaltung von Organisationen: Jemand erhält den Titel „Business Process Manager“, und das Unternehmen ist sich nicht sicher, ob damit ein Analyst, ein Projektmanager oder einfach eine sehr gut organisierte Person im Operations-Bereich gemeint ist. Die Person in dieser Rolle weiß es oft ebenfalls nicht genau.
Das ist kein Branding-Problem. Es ist ein Problem der Rollendefinition. Und es verursacht reale Kosten: Wenn der Verantwortungsbereich unscharf ist, bricht die Governance auseinander, Prozessverbesserungen kommen zum Stillstand, und die Arbeit landet im Posteingang der Person, die gerade zufällig verfügbar ist.
Ein Geschäftsprozessmanager ist eine eigenständige Rolle. Kein umbenannter Analyst. Kein Projektmanager mit erweitertem Aufgabenbereich. Die Unterscheidung ist wichtig, weil sie verändert, wofür diese Person verantwortlich ist, wem sie Bericht erstattet und was tatsächlich schiefläuft, wenn die Position nicht angemessen besetzt ist.
Der kostspielige Teil ist die Verantwortlichkeit
- Ein Geschäftsprozessmanager verantwortet den gesamten Lebenszyklus von Geschäftsprozessen – von der Modellierung bis zur Governance – und nicht nur die Dokumentation.
- Der Prozesseigner legt die strategische Richtung fest; der Manager setzt sie um und steuert die tägliche Leistung. Das sind unterschiedliche Aufgaben.
- BPM ist eine operative Disziplin, nicht nur eine Softwarekategorie oder ein Methodenlabel.
- Eine Organisation benötigt diese Rolle wirklich, wenn bereichsübergreifende Komplexität oder regulatorische Anforderungen eine informelle Prozessverantwortung zu fragil machen.
Was ein Geschäftsprozessmanager tatsächlich macht
Der Titel klingt, als gehe es um das „Managen von Prozessen“, was technisch korrekt, als Beschreibung aber beinahe vollständig nutzlos ist. Die praktische Verantwortung eines Geschäftsprozessmanagers besteht darin, die Struktur, Ausführung und Verbesserung von Workflows in einer Organisation zu steuern – und das Wort „steuern“ unterschätzt den Umfang erheblich.
Dies ist keine Rolle, die Prozesse aus der Distanz beobachtet und Berichte schreibt. Ein Geschäftsprozessmanager trägt Ende-zu-Ende-Verantwortung dafür, ob ein Prozess funktioniert, ob er sich im Laufe der Zeit verbessert und ob er korrekt gesteuert wird. Das bedeutet: Diese Person bekommt den Anruf, wenn etwas an der Schnittstelle zwischen zwei Abteilungen bricht, und entscheidet, wie „besser“ tatsächlich aussieht, wenn ein Verbesserungsprojekt abgegrenzt wird.
Nach der Einordnung von SAP Signavio verantwortet der Geschäftsprozessmanager den vollständigen Prozesslebenszyklus – von der Modellierung aktueller Workflows über die Leitung von Verbesserungsinitiativen bis hin zur Festlegung von Governance und der Steuerung der Automatisierungsstrategie. Das ist bewusst ein weiter Aufgabenbereich, und genau so soll es sein. Die Alternative ist ein fragmentiertes Modell, in dem niemand die Verantwortung für das Gesamtbild trägt und Prozessverbesserungen zwischen Übergaben versanden.
Was ein Geschäftsprozessmanager nicht ist: ein Business Analyst, der Dokumentation erstellt und sie weiterreicht. Auch kein Projektmanager, der einen klar abgegrenzten Umfang liefert und zum nächsten Auftrag weiterzieht. Und keine IT-Ressource, die die Tools verantwortet. Der Analyst beobachtet und dokumentiert. Der Geschäftsprozessmanager verantwortet, was passiert, nachdem die Dokumentation erstellt wurde – die Verbesserung, die Ausführung, die Governance und die fortlaufende Messung.
Diese Unterscheidung ist nicht nur semantisch. Sie trennt eine Rolle, die Artefakte produziert, von einer Rolle, die Ergebnisse erzielt.
Der vollständige Prozesslebenszyklus, den sie verantworten
Verantwortung für den Lebenszyklus bedeutet Rechenschaft in jeder Phase, nicht nur in den angenehmen. Sie beginnt mit der Prozessmodellierung: dem Verständnis, wie der aktuelle Workflow tatsächlich aussieht, und nicht, wie die Dokumentation von 2021 behauptet, dass er aussehe. Darauf folgen Verbesserungsinitiativen auf Basis dessen, was die Modellierung offenlegt: Lücken, Engpässe, redundante Schritte und Übergaben, für die niemand formal verantwortlich ist.
Sie erstreckt sich auf die Prozess-Governance: die Regeln dafür festzulegen, wie sich Geschäftsprozesse verändern, wer Änderungen genehmigt, wie Ausnahmen behandelt werden und wie Compliance sichergestellt wird. Und sie reicht bis zur Automatisierungsstrategie – nicht als separates IT-Projekt, das an das Engineering übergeben wird, sondern als kontinuierlicher Bestandteil davon, wie der Manager den Prozess aktuell, funktionsfähig und skalierbar hält.
Analysten dokumentieren Ende-zu-Ende-Prozessabläufe. Das ist wertvolle Arbeit. Doch ein Geschäftsprozessmanager, der nur dokumentiert, bleibt beim einfachsten Teil der Aufgabe stehen. Die Prozessmodellierung ist die Startlinie, nicht das Ergebnis. Die Initiative – verbessern, steuern, automatisieren – ist das, was Prozess-Governance tatsächlich erfordert.
Wie Organisationsziele mit der täglichen Prozessarbeit verbunden werden
Prozessgestaltung existiert nicht isoliert. Laut der Rollenbeschreibung von Indeed UK verbessert ein Geschäftsprozessmanager die organisatorische Leistung, indem er Prozesse gestaltet, implementiert, überwacht, bewertet und kontrolliert, damit sie der Organisation helfen, ihre Ziele zu erreichen. Der letzte Teil dieses Satzes trägt viel Bedeutung.
Er bedeutet, dass die tägliche Arbeit eines Geschäftsprozessmanagers über messbare Prozessleistung mit Geschäftszielen verbunden ist – nicht nur über interne Effizienzkennzahlen. Die Verkürzung der Durchlaufzeit ist wichtig, weil sie mit Kundenzufriedenheitszielen verbunden ist. Genehmigungsengpässe sind wichtig, weil sie die Umsatzgeschwindigkeit beeinflussen. Jede Kennzahl im Blick eines Geschäftsprozessmanagers sollte auf ein organisatorisches Ergebnis zurückführbar sein – andernfalls betreibt man Prozesse um der Prozesse willen, eine bewährte Methode, schöne Dokumentation zu produzieren, die niemand verwendet.
Lebenszyklus des Geschäftsprozessmanagements: Wo der Manager angesiedelt ist
Geschäftsprozessmanagement (BPM) als Disziplin hat einen Lebenszyklus, den die meisten Frameworks mit Varianten derselben Phasen beschreiben: gestalten, modellieren, ausführen, überwachen, optimieren. Das Modell ist nützlich, lässt sich aber leicht als abstrakte Theorie missverstehen. Für einen Geschäftsprozessmanager bildet es den operativen Kontext der tatsächlichen Arbeit – jede Phase bringt konkrete Entscheidungen mit sich, für die er verantwortlich ist, und nicht nur Kontrollkästchen, die abzuarbeiten sind.
Der Lebenszyklus ist in der Praxis außerdem nicht linear. Eine Prozessverbesserung in der Überwachungsphase führt zurück zur Gestaltung. Die Einführung einer Automatisierung schafft neue Governance-Fragen. Der Manager befindet sich innerhalb des Lebenszyklus, nicht darüber, und die Phasen laufen bei verschiedenen gleichzeitig betreuten Prozessen oft parallel.
Phase der Gestaltung und Modellierung
In der Gestaltungsphase ist der Geschäftsprozessmanager dafür verantwortlich, zu definieren, wie ein Workflow funktionieren soll: seine Grenzen festzulegen, Eingaben und Ausgaben zu identifizieren und die aktuelle Ausprägung dem gewünschten Soll-Zustand gegenüberzustellen. Hier findet Prozessmodellierung statt – die strukturierte Darstellung eines Workflows, die Stakeholder aus verschiedenen Abteilungen vor der Implementierung lesen, diskutieren und auf die sie sich einigen können.
Die Abstimmung der Stakeholder ist in dieser Phase tatsächlich der schwierige Teil. Die BPM-Phasen sehen in Diagrammen sauber aus. Finanzwesen, Vertrieb und Operations dazu zu bringen, sich darauf zu einigen, wo ein Prozess endet und ein anderer beginnt, ist eine völlig andere Erfahrung. Das Modellierungsartefakt ist nicht nur Dokumentation – es ist das Instrument, das die Diskussion über Verantwortlichkeiten und Sonderfälle erzwingt, bevor der Workflow festgelegt wird.
Phase der Überwachung, Bewertung und Kontrolle
Nach der Implementierung verlagert sich die Rolle des Managers auf die Verfolgung der Prozessleistung gegenüber den während der Gestaltung festgelegten Zielen. Das bedeutet, Durchlaufzeiten zu beobachten, Engpässe zu identifizieren, an denen sich Arbeit ansammelt, und Prozessdaten zu nutzen, um zwischen einer einmaligen Ausnahme und einem strukturellen Problem zu unterscheiden, das eine Designänderung erfordert.
Der Kontrollaspekt wird häufig unterschätzt. Er bedeutet, dass der Geschäftsprozessmanager die Befugnis hat, Prozessabweichungen zu kennzeichnen, Änderungen einer Governance-Prüfung zu unterziehen und einen Workflow anzuhalten oder zu überarbeiten, der von seinem vorgesehenen Verhalten abweicht. Ohne diese Befugnis wird kontinuierliche Verbesserung zu einer Sammlung von Empfehlungen. Das ist eine erhebliche Abwertung.
Governance und Automatisierungsstrategie
Governance und Automatisierung sind keine separaten Arbeitsströme, die der Manager weitergibt. Sie sind Teil einer dauerhaften Prozessverantwortung. Governance-Modelle zu implementieren bedeutet zu entscheiden: Wer darf einen Prozess ändern, welche Nachweise sind für die Genehmigung einer Änderung erforderlich und wie wird Compliance nachverfolgt? Ein Geschäftsprozessmanagementsystem kann Prozessdaten sichtbar machen und Genehmigungen weiterleiten, doch die Governance-Logik selbst – die Regeln – wird vom Manager gestaltet.
Auch die Automatisierungsstrategie gehört hierher. Wo reduziert Automatisierung das Risiko in einem Prozess? Wo erhöht sie es? Was geschieht bei der Prozessausführung, wenn ein automatisierter Schritt fehlschlägt und der Fallback unklar ist? Das sind Fragen des Risikomanagements, und sie gehören zum Manager, der den Prozesslebenszyklus verantwortet – nicht zu dem Engineer, der die Integration erstellt hat.
Arten des Geschäftsprozessmanagements: Was der Manager in jeder Variante verantwortet
BPM ist nicht monolithisch. Unterschiedliche Prozesse haben unterschiedliche Eigenschaften, und der Governance-Ansatz des Managers verändert sich je nach BPM-Typ, mit dem er arbeitet. Die Standardklassifizierung – die reale Prozessunterschiede abbildet – umfasst drei Haupttypen.
| BPM-Typ | Primärer Prozessfokus | Was der Manager steuert | Wo Automatisierung eingesetzt wird |
|---|---|---|---|
| Menschenzentriertes BPM | Prozesse, in denen menschliches Urteilsvermögen und Entscheidungen im Mittelpunkt stehen (Genehmigungen, Eskalationen, Prüfungen) | Regeln für Aufgabenweiterleitung, Entscheidungsbefugnisse, SLA-Tracking, Behandlung von Ausnahmen | Benachrichtigungen, Erinnerungen, Routing-Logik – nicht die Entscheidung selbst |
| Integrationszentriertes BPM | Prozesse, die Daten zwischen Systemen bewegen, oft ohne menschliche Schritte im Kernablauf | Standards für Datenmapping, API-Governance, Regeln zur Fehlerbehandlung, Synchronisierungsfrequenz | Hoch – die meisten oder alle Schritte können automatisiert werden; der Fokus verlagert sich auf Überwachung und Wiederherstellung nach Fehlern |
| Dokumentenzentriertes BPM | Prozesse, die sich um die Erstellung, Prüfung, Genehmigung und Speicherung von Dokumenten organisieren | Dokumentvorlagen, Versionskontrolle, Genehmigungswege, Compliance-Aufbewahrung | Routing, Benachrichtigungen, Extraktion, Archivierung – Menschen bleiben in den Genehmigungsschritten beteiligt |
In der Praxis sind die meisten Geschäftsprozesse eine Mischung. Ein Workflow für das Kunden-Onboarding kann in der Eingangsphase dokumentenzentriert sein, nach der Identitätsprüfung integrationszentriert und bei der finalen Genehmigung wieder menschenzentriert. Die Aufgabe des Geschäftsprozessmanagers besteht darin, zu identifizieren, welche BPM-Logik in jeder Phase gilt, und entsprechend zu steuern – nicht ein einziges Modell auf alles anzuwenden und sich dann zu wundern, warum die Übergänge scheitern.
Prozessautomatisierung ist tendenziell dort am zuverlässigsten, wo integrationszentrierte Logik dominiert. Wo menschliches Urteilsvermögen tatsächlich erforderlich ist, automatisiert man das Gerüst, nicht die Entscheidung.
Geschäftsprozessmanager vs. Prozesseigner: Eine Unterscheidung, die die meisten Organigramme ignorieren
Der Prozesseigner und der Geschäftsprozessmanager haben nicht dieselbe Aufgabe. Das ist eine der hartnäckigsten Verwechslungen, die ich in Organisationen sehe – teilweise, weil viele Unternehmen die Titel austauschbar verwenden, und teilweise, weil in kleineren Organisationen manchmal eine Person beide Rollen übernimmt. Sie als Synonyme zu behandeln, verschleiert jedoch eine echte Aufteilung der Verantwortlichkeit.
Appian zieht diese Trennung klar: Der Prozesseigner definiert Strategie und langfristige Ausrichtung. Der Geschäftsprozessmanager setzt diese Strategie um, konzentriert sich auf die tägliche Leistung und stellt sicher, dass der Prozess reibungslos läuft. Das ist kein geringfügiger Unterschied in der Formulierung, sondern es sind zwei unterschiedliche Arten von Verantwortung mit zwei verschiedenen Zeithorizonten.
Ein konkretes Beispiel hilft. Nehmen wir einen Auftragsabwicklungsprozess bei einem mittelständischen Hersteller:
Der Prozesseigner – wahrscheinlich ein VP of Operations – entscheidet, dass die Abwicklung die durchschnittliche Durchlaufzeit im kommenden Jahr um 20 % reduzieren soll, um eine unternehmensweite Liefer-SLA-Verpflichtung zu unterstützen. Das ist eine strategische Geschäftsentscheidung, die mit Organisationszielen verbunden ist.
Der Geschäftsprozessmanager übernimmt dieses Ziel, modelliert den aktuellen Workflow, identifiziert, wo Verzögerungen tatsächlich auftreten, steuert den Change-Management-Prozess zur Neugestaltung der Engpassschritte, überwacht die tägliche Ausführung gegenüber dem neuen Design und kennzeichnet Abweichungen der Durchlaufzeitkennzahl vom Verbesserungspfad. Das ist Verantwortung für die tägliche Leistung.
Wer setzt Leistungsziele? Der Eigner, abgestimmt auf die Geschäftsstrategie. Wer überwacht die tägliche Ausführung? Der Manager. Wer genehmigt eine Prozessänderung? Das hängt vom Governance-Modell ab – typischerweise genehmigt der Eigner wesentliche Änderungen, während der Manager operative Anpassungen innerhalb der definierten Parameter genehmigt. Hier wird die organisatorische Entscheidungsstruktur wichtig: Ist sie nicht explizit, beginnen beide Personen, Dinge zu genehmigen, und keine der Änderungen bleibt konsistent.
🤔 Denken Sie darüber nach:
In vielen Organisationen sind weder die Eignerrolle noch die Managerrolle formal zugewiesen. Die Strategie existiert irgendwo in einem Foliensatz, und die Ausführung liegt bei der Person mit dem vermeintlich passendsten Jobtitel. Das ist kein Governance-Modell – es ist ein Prozess, der auf institutionellem Wissen basiert, bis dieses institutionelle Wissen die Organisation verlässt.
Was Geschäftsprozessmanager branchen- und abteilungsübergreifend tun
Diese Rolle ist nicht auf eine einzelne Funktion oder Branche beschränkt. Die konkreten Probleme unterscheiden sich, doch das zugrunde liegende Muster bleibt gleich: bereichsübergreifende Komplexität, die informelle Koordination in großem Maßstab nicht zuverlässig bewältigen kann.
Fertigung und Produktionsabläufe
Laut der Beschreibung von Indeed UK arbeiten Geschäftsprozessmanager umfangreich in Fertigungs- und Produktentwicklungsumgebungen und koordinieren Workflows über Beschaffung, Produktion, Qualitätskontrolle und Lieferung hinweg. Die Prozessherausforderung besteht darin, Übergaben zwischen Teams mit unterschiedlichen Anreizen und Messzyklen zu steuern. Informelles Workflow-Management funktioniert bei geringem Volumen; bei Skalierung versagt es, wenn ein übersehener Schritt in einer Phase Verzögerungen zwei Phasen später auslöst.
Produktentwicklung und Forschung & Entwicklung
Stage-Gate-Prozesse, Prüfungs-Workflows und Compliance-Dokumentation in regulierter Produktentwicklung erfordern eine strukturierte Governance, für deren Pflege niemand im Projektteam Zeit hat, während gleichzeitig die eigentliche Entwicklung vorangetrieben werden muss. Ein Geschäftsprozessmanager verantwortet die Workflow-Struktur, die diese Prozesse über Produktlinien und Auditzyklen hinweg konsistent hält.
Teams für digitale Transformation
Initiativen zur digitalen Transformation hängen davon ab, dass jemand übergeordnete Strategie in ausführbare Workflows übersetzt. Das klingt einfach und ist in der Praxis genau der Schritt, der am häufigsten ausgelassen wird – Strategiedokumente liegen auf einem geteilten Laufwerk, während der Betrieb unverändert fortgesetzt wird. Geschäftsprozessmanager machen Transformation auf Workflow-Ebene real, nicht nur in Präsentationen.
Personalmanagement und People Operations
Workflows für Onboarding, Offboarding, Leistungsbeurteilungszyklen und Compliance-Schulungen sind typische Beispiele für Prozesse, die einfach wirken, bis man verfolgt, wie viele Ausnahmen und manuelle Eingriffe sich darin ansammeln. HR-Teams, die diese Prozesse informell verwalten, verbringen einen erheblichen Teil ihrer Zeit damit, einzelnen Schritten nachzujagen; Teams mit einem definierten Prozessmanager – oder einem klaren Prozesseigner, der beide Verantwortlichkeiten trägt – investieren diese Zeit in wertvollere Arbeit.
Teams für Operational Excellence und kontinuierliche Verbesserung
Einige Organisationen verfügen über dedizierte Excellence-Funktionen mit dem ausdrücklichen Auftrag, Abläufe zu optimieren und kontinuierliche Verbesserung voranzutreiben. Geschäftsprozessmanager in diesen Teams bilden die Umsetzungsebene: Sie überführen eine Lean- oder Six-Sigma-Initiative von einer Methodik in einen tatsächlich veränderten Workflow, mit Kennzahlen, die den Erfolg belegen. Ohne diese Rolle liefern Programme zur kontinuierlichen Verbesserung Erkenntnisse. Mit ihr liefern sie Veränderungen.
Finanzdienstleistungen, Gesundheitswesen und andere regulierte Branchen
Compliance-Prozesse in regulierten Branchen erfordern dokumentierte Workflows, kontrollierte Abweichungen und auditierbares Change Management. Workflow-Management ist hier keine Option – es ist eine regulatorische Anforderung. Geschäftsprozessmanager in diesen Umgebungen verbessern nicht nur die Effizienz; sie pflegen die operative Dokumentation, die bei einem Audit geprüft wird.
Fähigkeiten und Verantwortlichkeiten, die diese Rolle vom Projektmanagement unterscheiden
Projektmanager liefern Dinge. Ein Geschäftsprozessmanager verantwortet Dinge kontinuierlich, nachdem die Lieferung abgeschlossen ist.
Das ist die Unterscheidung in ihrer kürzesten Form. Ein Projektmanager leitet eine begrenzte Initiative mit definiertem Anfang, Ende und Umfang. Er ist dafür verantwortlich, das Ergebnis innerhalb von Zeitplan und Budget zu liefern. Wenn das Projekt abgeschlossen wird, endet auch seine Verantwortung. Ein Geschäftsprozessmanager schließt nicht ab. Er übernimmt den Prozess nach der Implementierung und bleibt für dessen Leistung verantwortlich – möglicherweise auf unbestimmte Zeit.
Die Kompetenzprofile überschneiden sich stärker, als beide Gruppen gern zugeben. Beide erfordern Stakeholder-Management, Kommunikation über Funktionen hinweg und die Fähigkeit, mehrdeutige Ziele in strukturierte Arbeit zu übersetzen. Die Unterschiede zeigen sich in Umfang und Kontinuität: Prozessverbesserungsprojekte sind ein Teil dessen, was ein Geschäftsprozessmanager verantwortet, nicht die gesamte Aufgabe. Projektmanagement ist eine Liefermethodik. Geschäftsprozessmanagement ist ein Betriebsmodell für dauerhafte Governance und Verbesserung.
Während ein Projektmanager einen neu implementierten Genehmigungs-Workflow möglicherweise an Operations übergibt und zum nächsten Projekt weiterzieht, verfolgt ein Geschäftsprozessmanager, ob dieser Workflow drei Monate später seine Durchlaufzeitziele erreicht, erkennt, wenn eine Systemänderung eine Annahme aus dem ursprünglichen Design verletzt, und verantwortet die Entscheidung, ob der Workflow überarbeitet oder das Ziel angepasst wird.
Geschäftsverständnis ist hier auf eine Weise wichtig, wie es bei reiner Projektlieferung nicht der Fall ist. Ein Geschäftsprozessmanager, der die Prozessleistung nicht mit Geschäftsergebnissen verbinden kann, optimiert Prozesskennzahlen, die niemand in der Führungsebene interessieren. Die Perspektive der Business-Analyse – zu verstehen, wofür ein Prozess tatsächlich da ist – verhindert genau das.
Abteilungsübergreifende Koordination und Stakeholder-Management
Laut Indeed UK koordinieren Geschäftsprozessmanager über Fertigung, Produktion und Produktentwicklung hinweg, steuern die Stakeholder-Abstimmung und unterstützen Budgetierung sowie Ressourcenallokation für Verbesserungsprojekte. In diesem funktionsübergreifenden Auftrag liegt die tatsächliche Komplexität.
Abteilungsübergreifende Koordination bedeutet, dass der Geschäftsprozessmanager regelmäßig dort arbeitet, wo Funktionen unterschiedlicher Meinung sind. Der Vertrieb möchte schnellere Genehmigungen. Die Rechtsabteilung möchte mehr Prüfschritte. Das Finanzwesen möchte einen lückenloseren Audit-Trail. Jeder Stakeholder optimiert für ein legitimes lokales Anliegen, und die Aufgabe des Geschäftsprozessmanagers besteht darin, einen Workflow zu gestalten oder auszuhandeln, der das Geschäftsziel unterstützt, ohne die Arbeitsfähigkeit eines einzelnen Teams zu zerstören. Das ist eine andere Fähigkeit als die Leitung eines Projektteams mit demselben Ziel.
Das praktische Ergebnis guten Stakeholder-Managements auf dieser Ebene: Prozesse, die verschiedene Teams tatsächlich befolgen, statt Prozesse, die in der Dokumentation existieren, während die Arbeit über Umgehungslösungen und Slack-DMs erledigt wird. Das Ziel ist die Optimierung für tatsächliche Einhaltung – nicht für theoretische Compliance. Operative Effizienz auf Basis eines Workflows, dem niemand folgt, ist lediglich ein schönes Diagramm.
Prozessverbesserung vs. Lieferung: Wie KI die Arbeit verändert
Etwas verändert sich in dem, was diese Rolle tatsächlich umfasst, und es lohnt sich, das direkt zu benennen: KI-gestützte Prozessanalyse und Automatisierungstools gehören zunehmend zum Aufgabenbereich eines Geschäftsprozessmanagers und sind keine separate Funktion für Data Science oder IT mehr.
Die Entwicklung sieht so aus: KI-Tools können heute Prozessengpässe aus Logdaten sichtbar machen, die Ursachen wiederkehrender Ausnahmen klassifizieren und Workflow-Neugestaltungen aus unstrukturierten Prozessbeschreibungen entwerfen. Früher erforderte diese Arbeit ein separates Analytics-Team oder ein spezialisiertes Beratungsmandat. Zunehmend nutzt ein kompetenter Geschäftsprozessmanager diese Tools direkt und trifft analytisch fundierte Entscheidungen schneller, ohne auf dedizierte Datenressourcen angewiesen zu sein.
Die Kehrseite ist, dass die Automatisierungsstrategie – die früher bedeutete, „zu entscheiden, welche manuellen Schritte automatisiert werden sollen“ – nun auch Fragen umfasst, wo KI-basierte Entscheidungen in einem Workflow angesiedelt sind, wie diese Entscheidungen auditiert werden und was geschieht, wenn eine KI-Klassifizierung falsch ist. Das sind Fragen der Prozess-Governance, und sie gehören zu dem Manager, der den Workflow verantwortet. Die Studie von McKinsey aus dem Jahr 2025 ergab, dass zwar nahezu alle Unternehmen in KI investieren, aber nur etwa 1 % glauben, bei deren effektiver Nutzung Reife erreicht zu haben. Diese Lücke ist teilweise ein Tooling-Problem und teilweise ein Problem der Prozessdisziplin – genau der Bereich, in dem ein Geschäftsprozessmanager arbeitet.
Die Analyse der Harvard Business Review von Davenport und Redman formulierte es direkt: Prozessmanagement erlebt eine Wiederbelebung, weil KI sowohl den Wert als auch die Dringlichkeit guter Prozessgestaltung erhöht. KI, die auf einem schlecht gestalteten Prozess läuft, behebt den Prozess nicht. Sie skaliert seine Fehlfunktionen.
Wann eine Organisation tatsächlich einen Geschäftsprozessmanager braucht
Nicht jede Organisation benötigt eine dedizierte Person in dieser Rolle. In einem Unternehmen mit zehn Mitarbeitenden übernimmt der Gründer die Prozessverantwortung oft informell, und das funktioniert gut. Die entscheidende Frage betrifft nicht allein die Unternehmensgröße – sondern Komplexität, Skalierung und regulatorische Risiken.
Drei Signale, dass der Bedarf real ist:
Bereichsübergreifende Komplexität ist zu einer Koordinationsbelastung geworden. Wenn mehr als zwei Abteilungen gemeinsam für ein Prozessergebnis verantwortlich sind und niemand die Übergabe zwischen ihnen verantwortet, summiert sich der Koordinationsaufwand in Form von Nacharbeit, Eskalationen und Ausnahmen, die im Posteingang des Managements landen. Ein Geschäftsprozessmanager absorbiert diese Belastung strukturell, statt sie über die Kalender aller Beteiligten zu verteilen.
Initiativen zur kontinuierlichen Verbesserung liefern weiterhin Erkenntnisse, aber keine Veränderungen. Viele Organisationen führen Lean-, Six-Sigma- oder interne Prozessprüfungen durch, die gute Analysen erzeugen und anschließend nichts Umsetzbares liefern. Die Analyse endet an der Grenze der Verantwortlichkeit einer Person. Ein Geschäftsprozessmanager verantwortet in komplexen Geschäftsumgebungen die Umsetzungsseite von Verbesserungsarbeit, nicht nur die Diagnose.
Regulatorische oder Qualitätsanforderungen verlangen dokumentierte, kontrollierte Prozesse. In Branchen, in denen Qualitätsmanagement und Audit-Compliance real sind – Gesundheitswesen, Finanzdienstleistungen, Fertigung mit ISO- oder ähnlichen Zertifizierungen –, schafft informelle Prozessverantwortung regulatorische Risiken. Die Geschäftsprozesse, die Compliance steuern, benötigen jemanden, der kontinuierliche Verantwortung für ihre Genauigkeit und ihren Betrieb trägt. Hier zahlt sich auch ein gewisses Maß an Six-Sigma-Formalismus aus: nicht als Methodenübung, sondern als strukturierter Ansatz zur Prozesskontrolle, den eine Aufsichtsbehörde prüfen kann.
Unternehmen in wettbewerbsintensiven Geschäftsumgebungen, in denen operative Geschwindigkeit und Konsistenz die Ergebnisse unterscheiden, stellen oft fest, dass die informelle Verteilung der Prozessverantwortung ab einer bestimmten Größe nicht mehr tragfähig ist. Die informelle Variante funktioniert, bis sie es nicht mehr tut – und sie hört meist auf sichtbare und schmerzhafte Weise auf zu funktionieren: während einer Systemmigration, nachdem eine Schlüsselperson das Unternehmen verlässt oder bei schnellem Personalwachstum.
Ein praktisches Beispiel: Ein mittelgroßes SaaS-Operations-Team, mit dem ich vergangenes Jahr gesprochen habe, hatte seinen gesamten Kunden-Onboarding-Workflow aus einer Kombination von Tabellen, Slack-Kanälen und informellem Erfahrungswissen aufgebaut. Als das Team von 40 auf 80 Kunden pro Monat wuchs, verdreifachte sich der Koordinationsaufwand, und die Fehlerquote stieg entsprechend. Es brauchte nicht sofort bessere Tools – es brauchte jemanden, dessen explizite Aufgabe darin bestand, das Workflow-Design und die Governance zu verantworten. Die Tools kamen später. In Latenode verband das Team schließlich sein CRM, sein Ticketsystem und die zentralen Onboarding-Tools zu einer einzigen Pipeline, wobei automatisches OAuth die Integrationsebene übernahm und KI-Modelle Onboarding-Probleme aus unstrukturierten Notizen klassifizierten. Doch keine dieser Automatisierungen hielt, bevor jemand das Prozessdesign verantwortete, dem sie dienen sollte.
📊 In der Praxis:
In regulierten Branchen oder Umgebungen mit häufigen abteilungsübergreifenden Übergaben zeigt sich das Fehlen eines formal zugewiesenen Geschäftsprozessmanagers typischerweise bei Audits zur Prozesserhebung: undokumentierte Ausnahmen, inkonsistente Ausführung zwischen Teams und eine Änderungshistorie, die nur im Gedächtnis einzelner Personen existiert. Das sind keine Technologiefehler. Es sind Governance-Fehler, die sich als Technologiefehler tarnen.
Dort beginnt der Ticketvorgang in der Regel.
