BPM-Best-Practices, die sich in echten Unternehmen bewähren

Hier ist ein Muster, das ich immer wieder beobachte. Ein Team startet eine BPM-Initiative mit echtem Elan. Es beschafft ein Tool. Es dokumentiert einige Prozesse. Es automatisiert etwas. Sechs Monate später ist die Initiative still und leise ins Stocken geraten, und alle jagen wieder Genehmigungen über Slack hinterher.

Das Tool war nicht das Problem. Nicht einmal der Prozess war das Problem. Was fehlte, war alles, was das Programm zusammenhalten sollte: Verantwortlichkeiten, Messgrößen, Governance und ein Pilotprojekt, das den Nutzen nachweist, bevor der unternehmensweite Rollout geplant wird. Diese Dinge wurden nicht übersprungen, weil das Team es nicht besser wusste. Sie wurden übersprungen, weil die Führungsebene sofort Ergebnisse wollte und die Grundlagenarbeit wie eine Verzögerung wirkte.

Genau diese Lücke behandelt dieser Artikel. Nicht, welche BPM-Software Sie kaufen sollten. Sondern wie Sie die Disziplin aufbauen, durch die jede BPM-Investition tatsächlich dauerhaft Wirkung zeigt.

Die Disziplinlücke ist teurer als die Toollücke

• Business Process Management scheitert meist an fehlenden Verantwortlichkeiten und übersprungener Governance, nicht an schlechten Softwareentscheidungen.
• Einen Prozess vor seiner Abbildung zu automatisieren bedeutet nur, die fehlerhafte Version schneller auszuführen.
• Ein Pilot für einen messbaren Prozess ist besser als ein unternehmensweiter Rollout, der auf einer Präsentationsfolie geplant wurde.
• BPM ist eine fortlaufende operative Disziplin, kein Projekt mit einem Go-live-Termin.
• Die wichtigste Best Practice steht in keiner Funktionsliste eines Tools.

Warum die meisten BPM-Implementierungen scheitern, bevor sie skalieren

Gut umgesetzt liefert BPM echte Ergebnisse. Branchenanalysen zur Geschäftsprozessautomatisierung zeigen, dass die Automatisierung von volumenstarken, regelbasierten Prozessen wie der Rechnungsverarbeitung die Kosten pro Einheit um fast 80 Prozent senken kann, laut der Studie zur Unternehmensautomatisierung von Elementum.ai. Die Produktivitätsgewinne wirksamer BPM-Initiativen sind messbar und erheblich.

Doch diese Spanne ist groß genug, um etwas Wichtiges zu verdeutlichen: Nicht das Tool erledigt die Arbeit. Entscheidend ist die Umsetzungsdisziplin.

Der häufigste Fehler ist keine schlechte Softwareauswahl. Es sind isolierte Automatisierungsprojekte ohne Prozessverantwortliche, ohne definierte Erfolgskennzahlen und ohne Governance-Struktur, die Verantwortlichkeit sicherstellt. Jemand automatisiert eine Aufgabe, sie läuft eine Zeit lang, dann bricht sie still und leise oder driftet ab, und niemand bemerkt es, weil niemand dafür zuständig ist, sie zu überwachen. Die Benchmarking-Forschung von APQC beschreibt dies als „fragmentierte, zufällige Verbesserungsmaßnahmen“, die an anderer Stelle im Unternehmen unbeabsichtigte negative Folgen verursachen. Die Lösung war nicht die Automatisierung. Zuerst wurde ein Rahmenwerk benötigt.

Wirksame BPM-Initiativen scheitern nicht, weil das BPM-Projekt technisch falsch war. Sie scheitern, weil Governance- und Sponsoring-Schritte, die BPM als System funktionsfähig machen, als optional behandelt wurden. Wenn Prozessverantwortliche nicht zugewiesen werden, bevor die Automatisierung live geht, entstehen Automatisierungswaisen: Workflows, die niemand wartet, misst oder verbessert. Und die Vorteile von BPM erscheinen in den Prognosen, aber nicht in den Ergebnissen.

Der Lebenszyklus des Business Process Managements, den Sie tatsächlich einhalten müssen

Der Lebenszyklus des Business Process Managements wird in den meisten Leitfäden als Diagramm dargestellt. Entwerfen, modellieren, ausführen, überwachen, optimieren. Das wirkt ordentlich. Was das Diagramm nicht zeigt, ist, welche Phasen unter Zeitdruck verkürzt werden und was Sie das später kostet.

Hier ist die ehrliche Version jeder Phase und was passiert, wenn sie schlecht umgesetzt wird.

Entwerfen bedeutet, den Prozess, seine Grenzen und seine Verantwortlichen zu identifizieren. Wenn Teams diesen Schritt überspringen, beginnen sie mit der Automatisierung, ohne ein klares Bild davon zu haben, wie Erfolg aussieht. Verantwortung wird vorausgesetzt, statt zugewiesen.

Modellieren bedeutet, den aktuellen Zustand abzubilden – so, wie er tatsächlich abläuft, nicht wie er ablaufen sollte –, bevor der zukünftige Zustand gestaltet wird. Die meisten Teams springen direkt zum zukünftigen Zustand. Genau dort bilden sie das Falsche ab.

Ausführen ist der Rollout. Erst pilotieren, dann skalieren. Die meisten Teams führen zuerst unternehmensweit aus. Dann beginnen die Support-Tickets.

Überwachen ist die Phase, die Teams nach dem Go-live am häufigsten überspringen. Der BPM-Lebenszyklus endet nicht, wenn der Workflow live geht. Er tritt in eine neue Phase ein. Ohne Überwachung wissen Sie nicht, ob die Automatisierung wie erwartet funktioniert, sich langsam verschlechtert oder unbemerkt ausfällt. Das Dashboard zeigt Grün. Der Prozess ist es nicht.

Optimieren ist der Punkt, an dem Erkenntnisse aus der Überwachung in die Neugestaltung zurückfließen. Diese Phase existiert nur, wenn die Überwachung erfolgt ist. Keine Daten, kein Verbesserungszyklus. Kein Verbesserungszyklus, und das BPM-Programm wird irgendwann zur ungenutzten Software.

Phasen des Business-Process-Management-Zyklus, die die meisten Teams verkürzen

Zwei Phasen werden stärker verkürzt als alle anderen: Prozessmodellierung und die Einrichtung von Messgrößen. Beide wirken wie Vorarbeit. Keine von beiden erzeugt etwas, das Stakeholder in einer Demo sehen können. Daher werden sie auf einen halben Tag verdichtet oder ganz übersprungen, um schneller mit dem Tool arbeiten zu können.

Was nachgelagert schiefläuft, wenn Sie die Prozessmodellierung verkürzen: Sie automatisieren eine Version des Prozesses, die nicht widerspiegelt, was tatsächlich passiert. Eskalationspfade werden nicht gestaltet. Sonderfälle werden nicht berücksichtigt. Tritt eine ungewöhnliche Situation auf, fällt der Workflow entweder unbemerkt aus oder leitet sie falsch weiter. Dieses Muster beschreiben auch Untersuchungen von Sagitec und HighGear: Eskalationsdesign und dynamische Checklisten werden unter Zeitdruck übersprungen, weil Teams den Idealfall als vollständiges Prozessmodell behandeln.

Was schiefläuft, wenn Sie die Einrichtung von Messgrößen verkürzen: Sie gehen ohne Ausgangsbasis und ohne KPIs live. Sechs Monate später fragt jemand, ob die BPM-Initiative funktioniert hat. Sie haben keine eindeutige Antwort. Die Prozessleistung ist entweder gut oder nicht, aber Sie können keine der beiden Aussagen belegen. Dann beginnt die organisatorische Unterstützung für das Programm zu erodieren. Der Erfolg des gesamten Prozesses lässt sich ohne die Messgrößen, die zu Beginn definiert werden sollten, nicht nachweisen.

Eine funktionierende BPM-Methodik behandelt Modellierung und Messung als Freigabeschritte, nicht als optionale Vorbereitung. Wenn das Modell nicht dokumentiert und die KPIs nicht vor dem Go-live definiert sind, fehlt den nachfolgenden Phasen die Grundlage.

Prozessabbildung vor der Automatisierung: Warum die Reihenfolge entscheidend ist

Die Automatisierung eines fehlerhaften Prozesses behebt ihn nicht. Sie lässt ihn nur schneller, in größerem Umfang und mit weniger Möglichkeiten zur manuellen Fehlererkennung ablaufen.

Das klingt offensichtlich. In der Praxis wird es ständig missachtet. Ein Team identifiziert einen mühsamen manuellen Prozess, wählt ein Tool aus, beginnt mit dem Aufbau des neuen Prozesses in diesem Tool und stellt auf halbem Weg fest, dass es Workarounds abbildet, die ihm erst beim Versuch einer Visualisierung aufgefallen sind. Das neue Prozessdesign spiegelt die Einschränkungen des Tools wider, nicht die tatsächlichen Anforderungen des Unternehmens. Und das Prozessdesign ändert sich erneut, sobald jemand endlich den aktuellen Zustand dokumentiert und die drei Schritte erkennt, die gar nicht existieren sollten.

TechTarget und Kissflow machen denselben Punkt deutlich: Dokumentation und Optimierung gehören vor die Technologieauswahl. Bilden Sie den aktuellen Zustand ab. Bereinigen Sie ihn. Definieren Sie den zukünftigen Zustand. Wählen Sie dann Tools für das Prozessdesign aus, die zu dem passen, was Sie bereits beschlossen haben aufzubauen – nicht umgekehrt. Prozessautomatisierung lässt sich wesentlich leichter korrekt umsetzen, wenn der Prozess selbst bereits durchdacht wurde.

Hier zeigt sich der Fehler „Tools vor Prozessen“ meist: nicht während der Auswahl, sondern sechs Monate nach Beginn eines Rollouts, wenn die Automatisierung einen Schritt fest eingebaut hat, den niemand begründen kann.

BPM-Best-Practices, die funktionierende Programme von gescheiterten Projekten unterscheiden

Das sind keine allgemeinen Empfehlungen. Jede benennt einen konkreten Fehlermodus, den sie verhindert, und eine Prüfung, die Sie tatsächlich durchführen können.

• Weisen Sie vor dem ersten Tag einen namentlich benannten Executive Sponsor zu

  Ohne sichtbares Engagement der Führungsebene werden BPM-Initiativen depriorisiert, sobald sie mit etwas Dringendem konkurrieren. Die praktische Prüfung: Können Sie eine Führungskraft benennen, die die Ressourcenverteilung des Programms in einem Quartalsreview verteidigt? Falls nicht, hat das Programm kein Sponsoring. Es wird lediglich toleriert.

• Definieren Sie Prozessverantwortliche, nicht nur Prozessbeteiligte

  Prozess-Governance einzuführen bedeutet, dass eine konkrete Person für jeden zentralen Geschäftsprozess verantwortlich ist – nicht das Team, nicht die Abteilung, eine Person. Der dadurch verhinderte Fehlermodus: Automatisierte Workflows verschlechtern sich langsam, weil niemand die Verantwortung für ihre Überwachung oder Verbesserung trägt. Prüfung: Weisen Sie für jeden Prozess im Umfang eine namentlich benannte verantwortliche Person mit dokumentierter Rechenschaftspflicht zu.

• Legen Sie KPIs vor dem Go-live der Automatisierung fest, nicht danach

  Eine der am häufigsten übersprungenen Best Practices bei der BPM-Einführung besteht darin, Erfolg zu definieren, solange Sie noch Ausgangsdaten zum Vergleich haben. Sobald der neue Prozess live ist, ist der vorherige Zustand verloren. Prüfung: Definieren Sie für jeden Prozess Kennzahlen für Durchlaufzeit, Fehlerquote und Volumen vor der Umstellung.

• Pilotieren Sie einen wirkungsvollen, klar abgegrenzten Prozess, bevor Sie skalieren

  Management-Best-Practices für BPM verweisen durchgängig auf Pilotprojekte als den Schritt, der Nutzen nachweist und Fehlermodi kostengünstig findet. Die Frameworks mit den 10 BPM-Best-Practices von TechTarget, Kissflow und BPMInstitute behandeln den Pilot als unverzichtbar. Die praktische Prüfung: Hat der Pilot einen definierten Umfang, ein messbares Ergebnis und eine echte Feedbackschleife mit Nutzern? Wenn es nur eine abgeschottete Demo ist, ist es kein Pilot.

• Behandeln Sie Change Management als parallelen Arbeitsstrang, nicht als Abschlussphase

  Teams behandeln Change Management oft als eine Kommunikationsmaßnahme zum Go-live. Das ist kein Change Management. Change Management in BPM bedeutet, die menschliche Seite zu steuern: Schulungen, Stakeholder-Abstimmung, Befähigung der Prozessverantwortlichen und Feedback-Erhebung während des gesamten Rollouts. Ohne diesen Ansatz scheitert die Einführung, selbst wenn die Technologie funktioniert.

• Richten Sie ein Kompetenzzentrum ein, wenn BPM mehr als eine Abteilung umfasst

  BPM-Teams, die abteilungsübergreifend ohne Governance-Struktur arbeiten, enden mit inkonsistenten Standards, doppelten Aufwänden und widersprüchlichen Prozessmodellen. Ein Kompetenzzentrum – selbst ein kleines – bietet eine gemeinsame Methodik, Governance für Vorlagen und einen zentralen Verantwortlichkeitspunkt für Prozessverbesserung und -management. Prüfung: Wenn mehr als zwei Abteilungen im Umfang enthalten sind, dokumentieren Sie, wer die Standards festlegt.

• Bilden Sie Ihre bestehenden Prozesse ab, bevor Sie BPM-Software auswählen

  Dies ist der Punkt der 10 Best Practices, dessen Reihenfolge am häufigsten umgedreht wird. Teams bewerten Tools, bevor sie verstehen, was sie aufbauen. Das Ergebnis: Sie wählen Software aus, um etwas zu automatisieren, das sie noch nicht verstehen. Diese Best Practices einzuhalten bedeutet, dass Dokumentation der Technologieauswahl vorausgeht. Die BPM-Verbesserung durch die Bereinigung des Prozesses ist oft größer als die Verbesserung durch die Automatisierung der unübersichtlichen Version.

• Integrieren Sie Eskalations- und Ausnahmebehandlung in jedes Prozessdesign

  Ein Prozessmodell, das nur den Idealfall abdeckt, wird beim ersten Ausnahmefall scheitern. Jeder Workflow benötigt einen definierten Pfad für Eskalation, Ablehnung, Zeitüberschreitung und Fehler. Der dadurch verhinderte Fehlermodus: Automatisierte Workflows kommen bei einem Sonderfall unbemerkt zum Stillstand oder leiten ihn falsch weiter, weil während der Modellierung niemand den Ausnahmepfad gestaltet hat.

• Verknüpfen Sie BPM-Ziele mit Geschäftsergebnissen und Unternehmenszielen

  BPM-Programme, die ihre Verbindung zu Umsatz, Kosten, Kundenzufriedenheit oder Risiko nicht darlegen können, verlieren im Laufe der Zeit organisatorische Unterstützung. Jede Initiative sollte einem messbaren Geschäftsergebnis zugeordnet werden. „Wir haben den Genehmigungs-Workflow automatisiert“ ist kein Business Case. „Wir haben die Durchlaufzeit für Vertragsgenehmigungen von 8 Tagen auf 1,5 Tage reduziert und dadurch die Vertriebszyklen um durchschnittlich 6 Tage verkürzt“ ist einer.

📊 Die Zahlen:
Laut der Studie zur Unternehmensautomatisierung von Elementum.ai kann die Automatisierung von volumenstarken, regelbasierten Prozessen die Verarbeitungskosten pro Einheit im Finanzbereich um fast 80 Prozent senken. Diese Spanne ist groß, weil eine Business-Process-Management-Implementierung mit hoher Disziplin Ergebnisse am oberen Ende erzielt, während schwache Governance zu Ergebnissen führt, die eher am unteren Ende liegen. Das Tool ist dasselbe. Die Praktiken sind es nicht.

So führen Sie eine erfolgreiche BPM-Implementierung durch, ohne sie zu groß anzulegen

Der häufigste Fehler, den ich bei BPM-Einführungen sehe, ist nicht eine zu geringe Ressourcenausstattung. Es ist ein zu großer Umfang der ersten Phase. Die Führungsebene will einen unternehmensweiten Rollout. Das Team braucht einen Pilot. Diese beiden Dinge stehen in direktem Spannungsverhältnis, und wenn die Führungsebene diese Diskussion gewinnt, beginnen die Support-Tickets.

Ein phasenweiser Ansatz zur BPM-Einführung ist die einzige Variante, die zuverlässig funktioniert. Die Phasen sind keine bürokratischen Etappen. Jede löst ein konkretes Problem, von dem die nächste Phase abhängt.

Die Phasen in groben Zügen:

Erkundung und Abstimmung. Bilden Sie den Zielprozess ab. Identifizieren Sie Stakeholder, Prozessverantwortliche und die Ausgangskennzahlen. Definieren Sie, was der Pilot nachweisen muss. Diese Phase endet, wenn sich alle Beteiligten darauf geeinigt haben, wie Erfolg aussieht. Diese Einigung ist das Ergebnis, nicht die Dokumentation.

Pilot und Nutzennachweis. Setzen Sie den BPM-Ansatz für einen Prozess mit definiertem Umfang, messbarem Ergebnis und einer echten Feedbackschleife um. Lassen Sie ihn lange genug laufen, um Fehlermodi zu erkennen, Nutzerfeedback zu sammeln und mit der Ausgangsbasis zu vergleichen. Hier liegt der Business Case für die nächste Phase.

Skalierter Rollout. Erweitern Sie auf zusätzliche Prozesse auf Grundlage dessen, was der Pilot gezeigt hat. Kein Copy-and-Paste des Piloten, sondern eine fundierte Erweiterung, die bereits Antworten auf die Fragen liefert, die der Pilot aufgeworfen hat.

Integration und Optimierung. Verbinden Sie den Prozess mit angrenzenden Systemen und Workflows. Hier ist systemübergreifende Transparenz wichtig. Wenn Ihr BPM-Tool, Ihr CRM und Ihr ERP nicht miteinander kommunizieren, bleiben Lücken in der Prozesstransparenz bestehen, selbst wenn einzelne Workflows sauber laufen. Tools wie Latenode sind in dieser Phase nützlich, weil ein mehrstufiger Integrations-Workflow – etwa ein neuer Vertrag, der Onboarding-Aufgaben in CRM-, Abrechnungs- und Kollaborationstools auslöst – in ihrem Preismodell als eine einzelne Ausführung zählt. Das hält die Kosten berechenbar, wenn der Umfang wächst.

Kontinuierliche Verbesserung. Das Programm ist nie abgeschlossen. Überwachungsdaten fließen in die Entwurfsphase zurück. Prozessverantwortliche prüfen ihre Kennzahlen. Das Kompetenzzentrum wahrt die Standards über Abteilungen hinweg. Diese Phase ist dauerhaft.

So wählen Sie den richtigen Pilotprozess zur Validierung Ihrer BPM-Strategie aus

Nicht alle Prozesse eignen sich als Pilotprojekte. Der richtige Prozess zur Validierung einer BPM-Initiative hat drei Eigenschaften: Er ist sichtbar genug, damit die Ergebnisse für jemanden mit Budgetverantwortung zählen, sein Umfang ist eng genug, damit Sie innerhalb von 60 bis 90 Tagen Ergebnisse sehen können, und er verfügt über eine messbare Ausgangsbasis, bevor Sie beginnen.

Hohe Wirkung bei geringem Risiko bedeutet hier etwas Konkretes. Hohe Wirkung bedeutet, dass das Ergebnis für den Geschäftsbereich sichtbar und relevant ist. Geringes Risiko bedeutet, dass der Fehlermodus beherrschbar ist: Wenn der Pilot nicht funktioniert, kann das Team zurückkehren, ohne einen kritischen Prozess zu beschädigen. Wählen Sie für den ersten Pilot nicht den kritischsten Prozess im Kerngeschäft. Wählen Sie etwas, das wichtig genug ist, um Nutzen nachzuweisen, und klein genug, um es kontrollieren zu können.

Eine hilfreiche Checkliste, bevor Sie sich auf einen Pilotprozess festlegen:

• Ausgangskennzahlen liegen vor (Volumen, Durchlaufzeit, Fehlerquote)
• Ein namentlich benannter Prozessverantwortlicher hat der Teilnahme zugestimmt
• Der Umfang passt in ein Team oder eine Abteilung
• Erfolgskriterien sind definiert und vereinbart, bevor der Aufbau beginnt
• Nutzerfeedback kann während des Piloten gesammelt werden, nicht erst am Ende

BPMInstitute und Kissflow empfehlen beide, vor der Skalierung mit wirkungsvollen Prozessen zu beginnen. Der Schwerpunkt liegt dabei auf messbarer Wirkung, nicht nur auf wahrgenommener Wirkung. Wenn Sie den Vorher- und Nachher-Zustand nicht in Zahlen definieren können, kann der Pilot nicht nachweisen, dass die BPM-Initiative funktioniert hat.

BPM in großen Organisationen skalieren, ohne Governance zu verlieren

BPM in Ihrer Organisation über mehrere Abteilungen hinweg zu skalieren, ist der Punkt, an dem Governance entweder trägt oder zusammenbricht. Was für den Prozess-Rollout eines Teams funktioniert, skaliert nicht automatisch. Unterschiedliche Abteilungen haben unterschiedliche Prozessverantwortliche, unterschiedliche Auslegungen gemeinsamer Begriffe, unterschiedliche Veränderungstoleranzen und unterschiedliche bestehende Tool-Stacks. Ohne gemeinsame Governance-Struktur enden Sie mit fünf seriös wirkenden BPM-Implementierungen, die nicht miteinander kommunizieren können.

Die Lösung ist nicht mehr Kontrolle. Es ist die richtige Struktur auf der richtigen Ebene. Ein Kompetenzzentrum stellt Methodenstandards, Governance für Vorlagen und eine Koordinationsebene bereit, ohne jede Prozessentscheidung selbst zu treffen. Change Management im großen Maßstab bedeutet Fürsprecher auf Abteilungsebene, nicht nur Kommunikation von oben nach unten. BPM-Lösungen für einen unternehmensweiten Rollout sollten danach bewertet werden, ob sie Governance-Strukturen für mehrere Teams unterstützen, nicht nur danach, ob sie einzelne Workflows sauber automatisieren.

Business Architecture bedeutet in diesem Kontext, Prozessverantwortung mit der Organisationsstruktur auszurichten, sodass die Personen, die in der Organisationsstruktur für einen Prozess zuständig sind, auch für seine Pflege im BPM-System verantwortlich sind. Wenn das nicht dieselben Personen sind, fällt die Wartung in die Lücke zwischen beiden Zuständigkeiten.

Prozessverbesserung und kontinuierliche Überwachung nach dem Go-live

Der teuerste Fehler bei BPM ist keine schlechte Implementierung. Es ist, die Implementierung als Ziellinie zu behandeln.

Ich beobachte das ständig. Ein Team bildet einen Prozess ab, baut den Workflow, startet ihn, prüft das Dashboard, bestätigt, dass er läuft, und widmet sich der nächsten Initiative. Sechs Monate später bemerkt jemand, dass die Ergebnisse seit Wochen abdriften: Die Durchlaufzeiten steigen, das Ausnahmevolumen hat zugenommen, eine nachgelagerte Übergabe funktioniert nach einem Systemupdate nicht mehr, das niemand dem Workflow-Verantwortlichen mitgeteilt hat. Doch das Dashboard zeigte weiterhin Grün. Es zeigt immer Grün. Das Dashboard zeigt den Ausführungsstatus, nicht das Geschäftsergebnis.

Prozessverbesserung nach dem Go-live muss als eigenständige operative Disziplin mit eigener Taktung behandelt werden, nicht als Phase, die mit dem Projekt endet. Das Seven-Tenets-Framework von APQC stellt dies ausdrücklich klar: Kontinuierliche Messung, Prozessverantwortung und Reifegradbewertung sind fortlaufende Verantwortlichkeiten, keine Aktivitäten, die mit dem Go-live enden. Organisationen, die BPM als Projekt behandeln, stellen irgendwann fest, dass sie Prozessverbesserungen durchführen, um Probleme zu beheben, die eine bessere Überwachung nach dem Start Monate früher erkannt hätte.

So sieht die operative Praxis nach dem Go-live konkret aus:

• SLA-Überwachung nach einem definierten Zeitplan, nicht nur reaktive Alarmierung
• Regelmäßige Reviews durch Prozessverantwortliche (monatlich ist ein guter Anfangsrhythmus; quartalsweise ist das Minimum)
• Strukturierte Feedbackschleifen von Prozessbeteiligten, nicht nur Fehlerprotokolle
• Eine dokumentierte Optimierungspipeline: In der Überwachung gefundene Probleme fließen in einen priorisierten Verbesserungs-Backlog zurück
• Überprüfung von Ausnahmemustern: Wenn dieselbe Ausnahme wiederholt auftritt, ist das ein Signal zur Neugestaltung, nicht nur eine Überwachungsnotiz

Die Frage zum Performance Management, die Sie jedes Quartal stellen sollten: Sind die KPIs, die wir beim Go-live festgelegt haben, noch die richtigen? Das Unternehmen zu verbessern erfordert oft, erneut zu prüfen, ob Sie tatsächlich das messen, was relevant ist, statt nur über das zu berichten, was beim Start bequem messbar war. Geschäftsprozesse ändern sich. Die Messgrößen müssen Schritt halten.

KPIs definieren, die Prozessverbesserung messbar machen

Ein nützlicher BPM-KPI ist an ein konkretes Prozessergebnis gebunden, nicht an Workflow-Aktivität. „Anzahl ausgeführter Workflows“ ist eine Aktivitätskennzahl. „Durchschnittliche Durchlaufzeit für Vertragsgenehmigungen“ ist eine Kennzahl für ein Prozessergebnis. Nur die zweite sagt Ihnen, ob sich der Gesamtprozess wie beabsichtigt verhält.

Legen Sie KPIs vor dem Go-live der Automatisierung fest. Das ist der nicht verhandelbare Teil. Sobald der BPM-Prozess läuft, ist der vorherige Zustand verloren und Sie können nachträglich keine aussagekräftige Ausgangsbasis mehr erstellen. Definieren Sie das Ziel für einen effizienten Prozess, messen Sie den aktuellen Zustand, legen Sie den Schwellenwert fest, der signalisiert, dass der Prozess Aufmerksamkeit benötigt, und weisen Sie die Verantwortung für die Prüfung zu.

Ein KPI-Framework als Ausgangspunkt für einen einzelnen Prozess:

• Durchlaufzeit: Startereignis bis Abschlussereignis, in Stunden oder Tagen
• Fehlerquote: Prozentsatz der Ausführungen, die eine manuelle Korrektur oder Nacharbeit erfordern
• SLA-Einhaltung: Prozentsatz der Fälle, die innerhalb des definierten Zeitfensters abgeschlossen werden
• Ausnahmevolumen: Anzahl der Fälle, die an den Eskalationspfad statt an den Standardpfad weitergeleitet werden

Als erster Schwellenwert für erforderliche Workflow-Aufmerksamkeit gilt: Wenn die SLA-Einhaltungsrate in einer bestimmten Woche unter 90 % fällt, ist das ein Auslöser für eine Prüfung. Wenn die durchschnittliche Durchlaufzeit über einen Zeitraum von 30 Tagen um mehr als 20 % steigt, erhält der Prozessverantwortliche eine Benachrichtigung. Dies sind illustrative Ausgangswerte; Ihre Schwellenwerte hängen davon ab, um welchen Prozess es geht und welche geschäftlichen Folgen Verzögerungen tatsächlich haben.

Arten des Business Process Managements und wann Sie sie einsetzen sollten

Es gibt drei Hauptarten von BPM, und die falsche Art für einen Workflow zu wählen, ist ein tatsächlicher Grund dafür, dass Automatisierungsprojekte nicht die erwarteten Ergebnisse liefern. Es geht nicht um eine Taxonomieübung. Es ist ein Auswahlproblem.

Integrationsorientiertes BPM verarbeitet Prozesse, die Daten mit wenig oder keiner menschlichen Intervention zwischen Systemen bewegen. Der Workflow wird durch ein Systemereignis ausgelöst, läuft über verbundene Anwendungen und wird abgeschlossen, ohne dass eine Person etwas genehmigen oder ausführen muss. Beispiele sind Procure-to-Pay-Automatisierung, CRM-zu-ERP-Synchronisierung und Datenanreicherungspipelines. Das Erfolgskriterium sind Ausführungsgeschwindigkeit und Fehlerquote. Integrationsorientiertes BPM ist der Bereich, in dem durchgängige Automatisierung den sichtbarsten ROI liefert.

Ein mittelgroßes SaaS-Unternehmen, das beispielsweise ein hohes Vertragsvolumen verarbeitet, könnte integrationsorientiertes BPM nutzen, um CRM, Abrechnungsplattform und Dokumentenspeicher zu verbinden, ohne an jedem Schritt manuell gesteuerte Übergaben zu benötigen. In Latenode zählt ein solcher Workflow unabhängig davon, wie viele Systeme er berührt, in seinem Preismodell als eine einzelne Ausführung. Das ist relevant, wenn Sie für Skalierung statt für einen Proof of Concept entwerfen. BPM ermöglicht echte Durchsatzgewinne, wenn der Prozess tatsächlich durchgängig regelbasiert ist.

Menschenorientiertes BPM eignet sich für Prozesse, bei denen in zentralen Phasen menschliches Urteilsvermögen erforderlich ist. Genehmigungen, Prüfungen, Eskalationen und Entscheidungen, die nicht vollständig kodifiziert werden können. Finanzfreigaben über bestimmten Schwellenwerten, Compliance-Abzeichnungen und komplexe Kundeneskalationen gehören in diesen Bereich. Die Tools müssen um den menschlichen Schritt herum aufgebaut sein: Aufgabenverteilung, Benachrichtigungen, Fristenverfolgung und Transparenz für die genehmigende Person. Diese Prozesse ausschließlich anhand der Ausführungsgeschwindigkeit zu messen, verfehlt den Punkt – die Qualität der menschlichen Entscheidung ist ebenso wichtig wie die Bearbeitungszeit.

Dokumentorientiertes BPM konzentriert sich auf den Lebenszyklus eines Dokuments: Erstellung, Prüfung, Genehmigung, Versionskontrolle und Archivierung. Vertragsmanagement, Veröffentlichung von Richtlinien und regulatorische Einreichungen sind Beispiele. Beim Workflow geht es darum, dass das Dokument einen definierten Prozess durchläuft, statt Daten zwischen Systemen zu bewegen. Geschäftsprozessverbesserung in dokumentorientierten Kontexten erfordert oft weniger Automatisierung und mehr strukturierte Weiterleitung, Zugriffskontrolle und Audit-Trail-Protokollierung.

Unterschiedliche BPM-Arten erfordern unterschiedliche Bewertungskriterien für Tools. Eine BPM-Art, die für menschenorientierte Genehmigungs-Workflows entwickelt wurde, sollte anhand ihres Aufgabenmanagements und Benachrichtigungsdesigns bewertet werden. Ein integrationsorientiertes BPM-Tool sollte anhand seiner Connector-Bibliothek und Fehlerbehandlung bewertet werden. Beides in einer einzigen Toolauswahlfrage zu vermischen, ist einer der einfacheren Wege, bei der falschen Lösung zu landen.

Business-Process-Management-Software auswählen, ohne sich zu viel verkaufen zu lassen

Der Auswahlfehler, den ich häufiger als jeden anderen sehe: Teams bewerten BPM-Software, bevor sie ihre Prozesse dokumentiert oder optimiert haben. Sie wählen Software aus, um etwas zu automatisieren, das sie noch nicht verstehen. Die Toolauswahl wird zum Ersatz für Prozessdesign, und das Ergebnis ist ein teures Tool, in das ein schlecht gestalteter Prozess fest eingebaut ist.

Dokumentieren und optimieren Sie zuerst. Wählen Sie dann das Tool aus, das zu dem passt, was Sie bereits beschlossen haben aufzubauen.

Wenn Sie über eine klare Prozessabbildung und einen definierten Prozesstyp verfügen, ist dies ein praktisches Framework zur Bewertung von BPM-Softwareoptionen:

Einige praktische Hinweise. Kissflow ist das Tool, das ich Teams empfehlen würde, die menschenorientierte Genehmigungen benötigen und keine Engineering-Ressourcen haben. Das Risiko drei Monate später: Niemand erinnert sich daran, wer die Routing-Regeln konfiguriert hat, und das Hinzufügen einer neuen Genehmigungsstufe wird zu einem Projekt von zwei Tagen. HighGear nimmt SLA-Überwachung ernst, was sein wichtigstes Unterscheidungsmerkmal im Bereich Service Operations ist. Asana ist in keinem strengen Sinn ein BPM-Tool – es ist Projektmanagement mit Workflow-Funktionen, was völlig in Ordnung ist, wenn Sie genau das benötigen. Es BPM-Software zu nennen, weckt falsche Erwartungen.

Für integrationsorientierte Workflows, bei denen mehrere Systeme ohne manuelle Übergaben verbunden werden müssen und das Team mindestens eine Person hat, die mit Logik und Konfiguration vertraut ist, ist Latenodes Modell, einen mehrstufigen Workflow als eine einzelne Ausführung zu behandeln, für die Kostenmodellierung nützlich. Die hier wichtigsten BPM-Anwendungen verbinden sich mit jedem System, das Sie bereits nutzen, durch Business Process Management, bei dem nicht jede nachgelagerte App einen formalen BPM-Standard unterstützen muss.

Integrationen für Enterprise Resource Management und Customer Relationship Management sind bei der Auswahl von BPM-Technologien echte Bewertungskriterien. Es lohnt sich, zwischen „Dieses Tool hat eine Salesforce-Integration“ und „Dieses Tool kann damit umgehen, wenn die Salesforce-Daten falsch sind“ zu unterscheiden. Content-Management-Systeme haben eigene BPM-Anforderungen, insbesondere bei Versionskontrolle und Genehmigungsrouting. Das schließt allgemeine Automatisierungstools aus, die nicht für Dokumentenlebenszyklusmanagement entwickelt wurden.

🤔 Moment.
Die meisten Teams wählen BPM-Software, bevor sie den Prozess verstehen, den sie verwalten wollen. Die Forschung von APQC zu Process Mining und Prozessverbesserung ist hier eindeutig: Toolauswahl vor Prozessdokumentation bedeutet, dass Sie Software zur Automatisierung von etwas auswählen, das Sie noch nicht optimiert haben. Die gewählte Lösung wird das Problem abbilden, nicht beheben. Bilden Sie den Prozess ab. Bereinigen Sie ihn. Kaufen Sie dann das Tool.

BPM ist eine Disziplin, keine Bereitstellung

Die Teams, die mit BPM langfristigen Nutzen erzielen, behandeln es als fortlaufende operative Praxis. Sie haben Prozessverantwortliche. Sie messen, bevor sie automatisieren. Sie pilotieren, bevor sie skalieren. Sie überwachen nach dem Go-live und führen Erkenntnisse in die Neugestaltung zurück. Nichts davon ist kompliziert. Alles davon erfordert bewusste Verbindlichkeit.

Die Teams, die einen Backlog an Support-Tickets und still und leise aufgegebene Workflow-Diagramme in Confluence erzeugen, haben die grundlegenden Schritte übersprungen, weil diese Schritte auf einer Demo-Zeitachse nichts Sichtbares erzeugen. Das ist ein echter organisatorischer Druck. Es ist auch der Grund, warum die meisten BPM-Initiativen in Ihrer Organisation ins Stocken geraten, bevor sie Ergebnisse liefern.

Wenn Sie heute eine BPM-Initiative starten, lautet die nützlichste erste Frage nicht „Welches Tool?“. Sondern: Wer verantwortet diesen Prozess, wenn er an einem Dienstagmorgen ausfällt und ich nicht verfügbar bin? Wenn Sie dafür einen Namen haben, haben Sie ein Fundament. Alles andere kann darauf aufgebaut werden.

Wenn Sie noch keinen Namen haben, finden Sie einen, bevor Sie die Software öffnen.