Die meisten Störungen im operativen Geschäft beginnen nicht mit einem defekten Tool. Sie beginnen mit einer Frage, die niemand beantworten kann: „Wer ist dafür verantwortlich?“
Jemand hat den Prozess eingerichtet. Jemand hat ihn dokumentiert. Jemand führt Teile davon gerade aus. Doch wenn er bei der Übergabe zwischen Vertrieb und Finanzabteilung scheitert, zwischen Onboarding und Abrechnung oder zwischen „Wir haben den Lieferanten freigegeben“ und „Der Lieferant wurde tatsächlich bezahlt“ – dann sagt das Schweigen im Raum alles. Es gibt keine einzelne Person, die sowohl die Befugnis als auch die Verantwortung hat, das Problem durchgängig zu lösen.
Genau diese Lücke soll ein Business Process Owner schließen. Ob das tatsächlich gelingt, hängt davon ab, ob das Unternehmen diese Funktion als echte Governance-Rolle behandelt oder lediglich als Namen auf einer Prozesskarte.
Die zentrale Aussage ist überprüfbar: Einen benannten Process Owner zu haben, ist nicht dasselbe wie Process Governance zu haben – und die meisten Unternehmen haben Ersteres ohne Letzteres.
Der Titel ist einfach. Die Verantwortung ist der schwierige Teil.
- Ein Business Process Owner trägt End-to-End-Verantwortung dafür, wie ein Prozess funktioniert – nicht nur dafür, wer ihn dokumentiert.
- Prozessverantwortung und Process Governance sind unterschiedliche Dinge – die meisten Unternehmen haben Ersteres und überspringen Letzteres.
- Die Rolle des Process Owners unterscheidet sich von der eines Prozessmanagers wie ein Vorstandsmitglied von einer Abteilungsleitung: Einer definiert die Governance, der andere setzt sie um.
- APQC-Daten zeigen, dass rund 77 % der Unternehmen Process Owner haben, aber weniger als eines von drei Unternehmen über die unterstützende Governance-Struktur verfügt, die Verantwortlichkeiten funktionsfähig macht.
- Ohne Befugnis über KPIs und funktionsübergreifende Entscheidungen ist ein Process Owner lediglich die Person, der die Schuld gegeben wird, wenn etwas schiefläuft.
Was ein Business Process Owner tatsächlich ist
Ein Process Owner ist eine Person, die für die End-to-End-Performance eines bestimmten Geschäftsprozesses verantwortlich ist – nicht nur für die Aufgaben innerhalb ihrer Abteilung, sondern dafür, wie der Prozess über alle beteiligten Teams hinweg läuft, vom Auslöser bis zum Ergebnis.
Die Definition eines Process Owners, die in der Praxis tatsächlich zählt: Diese Person ist dafür verantwortlich, Prozessänderungen freizugeben, messbar zu definieren, wie „funktionierend“ aussieht, und Verantwortung zu übernehmen, wenn die Leistung nachlässt. Nicht die Person, die die tägliche Arbeit erledigt. Nicht die Führungskraft, deren Team zufällig in der Mitte des Workflows sitzt. Sondern die Person, der der End-to-End-Prozess als System gehört.
APQC formuliert es präzise: Prozessverantwortung bedeutet, Aktualisierungen freizugeben und für Leistungsergebnisse einzustehen. Die Forschung des BPM Journal verankert dies in Governance-Begriffen: Prozessverantwortung ist eine strukturelle Rolle innerhalb eines Managementsystems, kein Jobtitel, der an die bestehenden Aufgaben einer Person angehängt wird.
Diese letzte Unterscheidung ist wichtig. Ich sehe dieses Muster im Support immer wieder: Ein Team sagt, es habe einen Process Owner, und meint damit eine Fachexpertin oder einen Fachexperten, die beziehungsweise der Fragen dazu beantworten kann, wie der Prozess heute funktioniert. Das ist nützlich. Aber es ist keine Governance. Der Process Owner ist die Person, deren Aufgabe es ist, den Prozess zu verbessern und Verantwortung zu übernehmen, wenn er nicht funktioniert.
Richtig umgesetzt ist Prozessverantwortung eine Kontrollfunktion, keine Dokumentationsfunktion.
Rollen und Verantwortlichkeiten eines Business Process Owners
Die Rollen und Verantwortlichkeiten eines Process Owners erstrecken sich über den gesamten Lebenszyklus eines Prozesses – nicht nur über den Tag, an dem eine Prozesskarte erstellt wird, sondern über jeden Tag, an dem der Prozess läuft, an Leistung verliert, durch angrenzende Teams verändert wird und schließlich neu gestaltet werden muss.
Die Aufgabe von Process Owners besteht in der End-to-End-Verantwortung über diesen gesamten Zeitraum. Mit diesem Verständnis sollte man sich auseinandersetzen, denn die meisten Rollenbeschreibungen für diese Position unterschätzen sie entweder – indem sie den Owner als Verwalter der Dokumentation behandeln – oder bleiben abstrakt, indem sie von „strategischer Ausrichtung“ sprechen, ohne zu erklären, was das bedeutet, wenn eine Übergabe an einem Mittwoch um 23 Uhr scheitert.
Das bedeutet konkret Folgendes.
Governance und Prozessverantwortung über den gesamten Lebenszyklus
Process Governance bedeutet, dass jemand die letzte Entscheidungsbefugnis darüber hat, wie ein Prozess definiert, verändert und gemessen wird. Die Struktur der Prozessverantwortung hängt davon ab, dass diese Befugnis real ist und nicht nur impliziert wird.
In der Praxis bedeutet die Etablierung von Process Governance: Der Owner genehmigt alle Änderungen am Prozess, bevor sie abteilungsübergreifend live gehen, verantwortet die Kommunikation, wenn sich Rollen verschieben oder Schritte hinzukommen, und steht für Ergebnisse ein, wenn der Prozess an funktionsübergreifenden Grenzen scheitert. Die Einordnung von APQC ist hier hilfreich: Der Owner genehmigt Aktualisierungen, ist aber nicht immer die Person, die sie vornimmt. Eine Operations-Analystin könnte den Rechnungs-Workflow neu gestalten; der Process Owner gibt frei, ob er live geht.
Diese Trennung ist wichtig. Ohne sie reduziert sich Governance auf die Person, die in dem Moment am lautesten im Raum ist, in dem über eine Änderung entschieden wird.
KPI-Definition, Performance-Monitoring und kontinuierliche Verbesserung
Genau diesen Teil überspringen die meisten Operations-Teams, wenn sie den Titel Process Owner vergeben, ohne zugleich die Befugnisse zu übertragen, die diesen Titel sinnvoll machen.
Ein Process Owner definiert die KPIs. Er berichtet nicht nur darüber – er legt sie fest. Er entscheidet, wie „gut“ für diesen End-to-End-Prozess aussieht, überwacht die Performance anhand dieser Definitionen und verantwortet den Verbesserungszyklus, wenn die Kennzahlen abweichen. Wichtige Leistungsindikatoren für einen Owner im Procure-to-Pay-Prozess könnten die Dauer des Freigabezyklus, die Ausnahmequote und der Anteil fristgerecht bezahlter Rechnungen sein. Das sind weder ausschließlich IT- noch ausschließlich Finanzkennzahlen – es sind Prozesskennzahlen, die beide Bereiche umfassen.
Auch der kontinuierliche Verbesserungszyklus gehört hierher. Wenn der Owner nur über die Prozessleistung berichtet und die Informationen nach oben weitergibt, damit jemand anderes entscheidet, was verbessert werden soll, ist er ein Kennzahlenverwalter und kein Process Owner. Die Befugnis zur Verbesserung ist untrennbar mit der Verantwortung für die Leistung verbunden.
Funktionsübergreifende Koordination und die Behebung von durch Silos verursachten Übergabefehlern
Process Owner existieren insbesondere deshalb, weil funktionsübergreifende Übergaben scheitern, wenn niemand die gesamte Abfolge verantwortet.
Jeder Prozess, der mehr als ein Team umfasst, enthält einen Moment, in dem Verantwortlichkeit unklar wird. Der Vertrieb sagt, der Lead sei qualifiziert gewesen. Das Marketing sagt, der Lead sei korrekt übergeben worden. Niemand weiß, warum der Deal zwischen diesen beiden Aussagen elf Tage lang stillstand. Genau in dieser Lücke arbeiten Process Owner.
Die funktionsübergreifende Koordinationsrolle bedeutet, dass der Owner diese Reibungspunkte sichtbar macht, abteilungsübergreifend Lösungen vorantreibt, statt darauf zu warten, dass jedes Silo das Problem intern löst, und die Prozessergebnisse als Ganzes verantwortet – selbst wenn einzelne Schritte von Teams ausgeführt werden, die von unterschiedlichen Funktionen geführt werden. Prozessverbesserung auf Übergabeebene ist fast unmöglich, wenn niemand dieses funktionsübergreifende Mandat innehat.
Business Process Owner vs. Prozessmanager: Woher die Verwirrung kommt
Die Verwirrung zwischen diesen beiden Rollen tritt ständig auf, und sie ist durchaus nachvollziehbar. Beide Titel klingen, als gehe es darum, Verantwortung für einen Prozess zu übernehmen. Der Unterschied liegt in der Art der Verantwortung – und dieser Unterschied entscheidet darüber, wer tatsächlich die Befugnis hat, wenn etwas geändert werden muss.
Die Verantwortung eines Process Owners liegt auf der Governance- und Strategieebene. Der Prozessmanager befindet sich auf der Ausführungsebene. Einer gestaltet das System und trägt Verantwortung für dessen Ergebnisse; der andere betreibt das System im Tagesgeschäft. Beide sind notwendig. Werden sie als dieselbe Rolle behandelt, endet das damit, dass eine Person zu tief im operativen Detail steckt, um das Problem auf Prozessebene zu erkennen, während eine andere Person ein strategisches Mandat hat, aber keinen Einblick in die operative Realität.
Der Vergleich mit Appian ist beliebt, weil er eine echte Quelle der Verwirrung darstellt – insbesondere in Unternehmen, die BPM-Implementierungen durchführen. Doch der Unterschied ist nicht nur definitorisch, sondern hat reale Folgen für Prozessgestaltung und Entscheidungsbefugnisse.
| Dimension | Business Process Owner | Prozessmanager |
|---|---|---|
| Primärer Fokus | Governance, KPI-Verantwortung, End-to-End-Verantwortung | Tägliche Ausführung und Teamkoordination |
| Umfang der Verantwortung | Vollständiger Prozesslebenszyklus über alle Teams hinweg | Operative Ergebnisse innerhalb des zugewiesenen Bereichs |
| Entscheidungsbefugnis | Genehmigt Prozessänderungen, definiert Leistungsstandards | Trifft Ausführungsentscheidungen innerhalb des definierten Prozesses |
| Beziehung zu KPIs | Definiert sie, verantwortet sie, treibt Verbesserungszyklen voran | Berichtet dazu und eskaliert Lücken |
| Funktionsübergreifende Reichweite | Obligatorisch – die Rolle existiert für funktionsübergreifende Prozesse | Begrenzt – in der Regel auf einen Funktionsbereich beschränkt |
Die Geschäftsstrategie bestimmt, wofür ein Process Owner verantwortlich ist. Die Prozessgestaltung beschreibt, wie er diese Verantwortung erfüllt. Der Manager setzt das Design um. Keine der beiden Rollen schafft ohne die andere eine funktionierende Governance.
📊 Die Zahlen:
Eine APQC-Umfrage aus dem Jahr 2023 ergab, dass etwa 77 % der Unternehmen Process Owner benannt haben – der Titel ist also weit verbreitet. Doch nur rund 35 % hatten Prozesssponsoren und nur rund 33 % einen Lenkungsausschuss eingerichtet. Prozessreife wird letztlich nicht daran gemessen, ob die Rolle existiert. Sie wird daran gemessen, ob die Governance-Infrastruktur um diese Rolle herum existiert. Die meisten Unternehmen haben das eine ohne das andere.
Was Business Process Management tatsächlich von einem Process Owner erfordert
Business Process Management ist kein Synonym für dokumentierte Prozesse. BPM ist eine Governance-Disziplin – ein strukturierter Ansatz, um zu definieren, zu messen, zu verbessern und zu steuern, wie Arbeit tatsächlich durch ein Unternehmen fließt. Der Process Owner ist eine Rolle innerhalb dieses Systems, nicht das gesamte System.
Der Process Owner verantwortet seinen End-to-End-Prozess innerhalb der umfassenderen BPM-Governance-Struktur. Diese Struktur kann auch Prozesssponsoren umfassen – leitende Führungskräfte, die das Prozessmandat finanzieren und schützen –, Lenkungsausschüsse – funktionsübergreifende Entscheidungsgremien, die Konflikte zwischen konkurrierenden Process Owners lösen – sowie Prozessverantwortliche – operative Rollen, die die Prozessdokumentation pflegen und Ausführungsdaten zwischen formellen Reviews überwachen.
Die Aufgabe des Process Owners innerhalb von BPM besteht darin, der zentrale Verantwortlichkeitspunkt für seinen spezifischen Prozess zu sein – die Person, an die der Lenkungsausschuss eskaliert, wenn etwas nicht funktioniert, und die Person, die Leistungsdaten und Verbesserungsvorschläge zurück in die Governance-Ebene einbringt. Process Owner haben die Aufgabe, ihren Prozess an der Unternehmensstrategie auszurichten und gleichzeitig nahe genug an den Ausführungsdaten zu bleiben, um Abweichungen zu erkennen, bevor sie zur Krise werden.
Hier kommt der Teil, der die meisten Operations-Verantwortlichen unruhig machen sollte: APQC-Daten zeigen, dass nur etwa 14 % der Unternehmen Prozessverantwortliche eingerichtet haben. Das bedeutet, dass die Mehrheit der Unternehmen, die behaupten, BPM zu betreiben, dies ohne die operative Ebene tut, die die Prozessleistung zwischen formellen Reviews tatsächlich aufrechterhält. Die kritischen Geschäftsprozesse dieser Unternehmen haben auf dem Papier Owner. Ob diese Owner über die Infrastruktur verfügen, um zu handeln, ist eine andere Frage.
Das ist kein theoretisches Governance-Problem. Es ist ein Problem am Montagmorgen – und so landet ein Process Owner in der Verantwortung, ohne Zugriff auf die Informationen zu haben, die er für sein Handeln braucht. Ich habe Process Owner selbst dabei erlebt, wie sie es beschrieben haben: Sie steuern einen Prozess im Blindflug, den sie eigentlich governancen sollen, und sind darauf angewiesen, dass IT-Administratoren Workflow-Konfigurationen extrahieren, auf die sie selbst keinen Zugriff haben. Das ist eine Lücke in der Governance-Struktur im technischen Gewand.
Global Process Owner: Wenn ein Prozess das gesamte Unternehmen umfasst
Ein Global Process Owner ist ein zentraler Verantwortlichkeitspunkt für die Steuerung eines bestimmten Geschäftsprozesses im gesamten Unternehmen – nicht nur innerhalb einer Region, einer Geschäftseinheit oder eines funktionalen Silos, sondern End-to-End über alle Regionen und Unternehmensbereiche hinweg, in denen der Prozess läuft.
Diese Rolle existiert, weil internationale ERP-Einführungen, Shared-Service-Transformationen und unternehmensweite Standardisierungsprogramme immer wieder dasselbe Problem aufzeigen: Ein Prozess, der gut funktioniert, solange jede Region ihre eigene Version verantwortet, erzeugt uneinheitliche Ergebnisse, Compliance-Lücken und Reporting-Chaos, sobald jemand regionsübergreifende Daten benötigt. Ein GPO löst dieses Problem, indem er die Prozessarchitektur global verantwortet und jede regionale Implementierung an gemeinsamen Standards misst.
Im Umfang unterscheidet sich diese Rolle von einem lokalen oder abteilungsbezogenen Process Owner, nicht nur in ihrer Hierarchieebene. Der GPO führt keine regionalen Teams – er verantwortet die Prozessdefinition, die Governance-Standards und den Performance-Rahmen, innerhalb dessen regionale Owner arbeiten. Operative Exzellenz auf Unternehmensebene erfordert diesen zentralen Entscheidungspunkt, wenn regionale Implementierungen auseinanderlaufen.
Programme zur Geschäftstransformation – SAP-S/4HANA-Migrationen, Konsolidierungen von Shared Services, globale CRM-Einführungen – schaffen fast immer ausdrücklich eine GPO-Rolle, denn ohne sie passt jedes regionale Team den Prozess an seine bestehenden Gewohnheiten an und die „globale Standardisierung“ löst sich innerhalb von sechs Monaten auf.
Ein praktisches Beispiel dafür, wie funktionsübergreifende End-to-End-Prozessverantwortung im großen Maßstab aussieht: Ein Global Process Owner für Order-to-Cash koordiniert, wie Aufträge in Nordamerika erfasst werden, wie Rechnungen in EMEA erstellt werden und wie der Zahlungseingang dort zugeordnet wird, wo sich die Bankkonten befinden. Wenn jeder dieser Schritte in unterschiedlichen Systemen mit unterschiedlichen Teams und unterschiedlichen Übergabekonventionen abläuft, wird eine Plattform, die den vollständigen Prozessstatus über all diese Systeme hinweg sichtbar macht, zur operativen Transparenzebene des GPO – nicht zu einem Luxus.
Für Teams, die mit dieser Art von Prozessautomatisierung über Systeme hinweg arbeiten, denen gute Reporting-APIs fehlen, bedeutet Latenodes Kombination aus mehr als 5.500 Integrationen und Headless-Browser-Funktionalität, dass ein GPO Prozessstatusdaten selbst aus Legacy-SaaS-Tools aggregieren kann, die diese nicht nativ bereitstellen – ohne darauf zu warten, dass die IT eine individuelle Integration entwickelt.
Drei Fehlannahmen über die Rolle des Process Owners, die echte Probleme verursachen
Dabei handelt es sich nicht um abstrakte Missverständnisse. Jedes davon erzeugt einen spezifischen, sichtbaren Fehlermodus, den ich immer wieder in Operations-Teams sehe, die ernsthaft versuchen, es richtig zu machen. Process Owner müssen diese Muster frühzeitig erkennen, denn sobald die Symptome offensichtlich sind, dauert die strukturelle Korrektur deutlich länger als das Gespräch, das sie hätte verhindern können.
- Der Process Owner ist dieselbe Person wie diejenige, die die Arbeit ausführt
Teams glauben das, weil die Person mit dem umfassendsten operativen Wissen über einen Prozess meist auch am tiefsten in dessen Ausführung eingebunden ist. Doch wenn beide Rollen gleichgesetzt werden, wird keine von beiden richtig erfüllt. Effektive Process Owner können einen Prozess nicht objektiv governancen und zugleich dessen primäre Ausführung verantworten. Die Governance-Rolle erfordert die Fähigkeit, infrage zu stellen, ob der Prozess anders funktionieren sollte. Menschen, die die Arbeit täglich ausführen, entwickeln Workarounds, Anpassungen und blinde Flecken, die diese Art der Hinterfragung strukturell erschweren. Wenn sich ein Process Owner auf die Ausführung konzentriert, gerät die Prozessverbesserungsinitiative ins Stocken und die Governance-Ebene verschwindet vollständig.
- Die Rolle betrifft nur Dokumentation, nicht Strategie oder Performance
Diese Annahme führt zu einem besonders frustrierenden Fehler: Das Unternehmen investiert in Prozessmapping, Process Owner pflegen diese Karten, und tatsächlich verbessert sich nichts. Prozessdokumentation ist ein Governance-Artefakt, nicht die Governance selbst. Process Owner verstehen, dass Dokumentation den Prozess so beschreibt, wie er konzipiert wurde; sie sagt nichts darüber aus, wie der Prozess unter realen Bedingungen funktioniert. Wenn die Rolle auf die Verwaltung der Dokumentation beschränkt wird, verantwortet niemand die KPIs, niemand treibt Verbesserungszyklen voran und die Prozesskarte wird zu einem historischen Nachweis dafür, wie die Dinge funktionierten, bevor sich die Workarounds angesammelt haben.
- Ein Process Owner deckt das gesamte Unternehmen ab
Das ist seltener eine formale Überzeugung als eine informelle Entscheidung zur Ressourcenverteilung: Das Unternehmen ernennt eine erfahrene Operations-Führungskraft zum „Process Owner“ für alles. Process Owner müssen auf spezifische End-to-End-Prozesse begrenzt sein, nicht auf das gesamte Unternehmen. Ein einzelner Owner kann für kein Unternehmen eine sinnvolle Verantwortung für jeden einzelnen Prozess aufrechterhalten. Das Ergebnis: Process Owner werden zu reaktiven Problemlösern statt zu proaktiven Governance-Verantwortlichen, und Prozesse, über die sich niemand sichtbar beschwert, erhalten keine Aufmerksamkeit, bis sie katastrophal scheitern. Ein Owner pro End-to-End-Prozess ist das richtige Modell.
Dort beginnt der Vorgang in der Regel.
🤔 Denken Sie darüber nach:
APQC-Daten zeigen, dass die meisten Unternehmen Process Owner benannt haben. Weniger als eines von drei Unternehmen verfügt über die Governance-Infrastruktur – Sponsoren, Ausschüsse, Prozessverantwortliche –, die Verantwortlichkeiten funktional macht. Das bedeutet: Der „Process Owner“ Ihres Unternehmens könnte ein benannter Kontakt auf einer Prozesskarte sein, der Verantwortung trägt, aber nicht die Befugnis hat, entsprechend zu handeln. Der Titel und die Rolle sind nicht dasselbe. Es lohnt sich zu prüfen, was Sie tatsächlich zugewiesen haben.
