Die Illusion der Klarheit: Warum klassische Flussdiagramme im Arbeitsalltag scheitern
Auf dem Papier wirkt der Prozess eindeutig: Ein Kästchen folgt auf das nächste, eine Raute entscheidet über den weiteren Weg. Im Arbeitsalltag entstehen jedoch Fragen, die das Diagramm nicht beantwortet. Was passiert, wenn zwei Prüfungen parallel laufen? Wer reagiert auf eine fehlende Freigabe? Darf die Fertigung beginnen, während ein Dokument noch geprüft wird?
Erfahrene Mitarbeitende kennen die Antworten meist. Sie wissen, wen sie anrufen, welche E-Mail sie weiterleiten und wann eine Ausnahme zulässig ist. Das Flussdiagramm zeigt deshalb nicht den vollständigen Prozess. Es zeigt nur dessen sichtbare Oberfläche.
Wenn das Diagramm endet, beginnt die Nebenabsprache
Viele MedTech-Unternehmen dokumentieren ihre Abläufe sorgfältig. Trotzdem müssen Mitarbeitende an wichtigen Übergaben nachfragen, Freigaben manuell verfolgen oder Sonderfälle außerhalb des beschriebenen Prozesses lösen.
So entsteht neben dem offiziellen Ablauf ein zweiter, informeller Prozess. Ein Teil steckt in ergänzenden Texten, ein anderer in E-Mails und Arbeitsanweisungen. Der entscheidende Rest bleibt Erfahrungswissen einzelner Personen.
Im eingespielten Team fällt diese Lücke kaum auf. Problematisch wird sie bei Vertretungen, Personalwechseln oder neuen Schnittstellen. Dann interpretieren Beteiligte denselben Ablauf unterschiedlich. Rückfragen häufen sich, Vorgänge bleiben liegen und Fehler lassen sich nur schwer zurückverfolgen.
Das Problem liegt nicht in fehlender Dokumentation. Es liegt in fehlender Eindeutigkeit.
Warum Software keine Zwischenzeilen lesen kann
Spätestens bei der Digitalisierung treten die verdeckten Regeln offen zutage. Eine Workflow-Anwendung kann keine erfahrene Person fragen, wie ein Sonderfall „normalerweise“ behandelt wird. Sie benötigt eindeutige Angaben:
- Welches Ereignis startet den nächsten Schritt?
- Welche Prüfungen dürfen gleichzeitig laufen?
- Was geschieht bei einer Abweichung?
Fehlen diese Regeln, muss das Projektteam sie während der Umsetzung nachträglich ermitteln. Fachbereich, Qualitätsmanagement und IT diskutieren dann nicht nur die Software. Sie rekonstruieren zunächst den tatsächlichen Prozess.
Das führt zu zusätzlichen Abstimmungen, geänderten Anforderungen und wiederholten Tests. Je später ein ungeklärter Prozesspfad auffällt, desto aufwendiger wird seine Korrektur.
Software verursacht diese Unklarheiten nicht. Sie legt sie offen.
Prozessqualität entscheidet über den Nutzen der Digitalisierung
Ein digitaler Workflow wird nicht automatisch besser, nur weil er papierlos läuft. Übernimmt das System einen unklaren Ablauf unverändert, automatisiert es auch dessen Rückfragen, Warteschleifen und unnötige Übergaben.
Deshalb beginnt Digitalisierung nicht mit der Auswahl eines Werkzeugs. Sie beginnt mit einem Prozessmodell, das den realen Arbeitsablauf abbildet. Dazu gehören Standardfälle ebenso wie parallele Aufgaben, Ausnahmen und Abbrüche.
Ein belastbares Modell hilft Anwendern unmittelbar. Zuständigkeiten werden verständlicher, Übergaben nachvollziehbarer und Sonderfälle beherrschbar. Zugleich sinkt der spätere Klärungsaufwand für IT und Qualitätsmanagement.
Genau an dieser Stelle stößt das klassische Flussdiagramm an seine Grenzen. Für komplexe MedTech-Prozesse braucht es eine Sprache, die nicht nur Schritte zeigt, sondern auch deren Logik eindeutig beschreibt.
Die Anatomie von BPMN 2.0: Eine gemeinsame Sprache für den Arbeitsalltag
BPMN 2.0 schlägt die Brücke zwischen gelebtem Prozess und technischer Anforderung. Die Notation beschreibt Geschäfts- und Produktionsabläufe mit klar definierten Symbolen, sodass Prozessverantwortliche, Qualitätsmanagement und IT dieselbe Prozesslogik erkennen und verstehen.
Warum BPMN-Symbole mehr sind als Kästchen und Pfeile
Viele Prozesse scheitern nicht an fehlender Dokumentation, sondern daran, dass unterschiedliche Personen dieselbe Darstellung unterschiedlich interpretieren. Genau hier setzt BPMN an: Jedes Symbol steht für eine feste logische Bedeutung und reduziert damit den Spielraum für mündliche Nebenabsprachen.
Das Modell wird dadurch zur verbindlichen Referenz für alle Beteiligten. Fachbereiche können ihre Abläufe verständlich beschreiben, Qualitätsmanagement kann die Logik prüfen und IT-Teams erkennen, welche Bedingungen, Ausnahmen und Übergaben systemseitig abgebildet werden müssen.
Pools, Lanes und Flusselemente: Die Struktur hinter dem Prozess
BPMN zeigt nicht nur, was passiert, sondern auch, wer beteiligt ist und warum ein Prozess seinen Weg fortsetzt. Pools und Lanes ordnen dafür Verantwortlichkeiten und organisatorische Grenzen.
Ein Pool steht für einen eigenständigen Teilnehmer, etwa das eigene Unternehmen, einen Lieferanten oder ein externes System. Lanes unterteilen diesen Teilnehmer in Rollen, Teams oder Abteilungen wie Qualitätsmanagement, Produktion oder Einkauf.
Während Pools und Lanes die Zuständigkeiten ordnen, entsteht die eigentliche Dynamik durch drei Flusselemente: Aktivitäten beschreiben die konkrete Arbeit, Gateways steuern den weiteren Prozessweg und Ereignisse reagieren auf Nachrichten, Fristen, Fehler oder andere Zustandsänderungen.
Aktivitäten stehen für konkrete Aufgaben wie „Bauteil prüfen“, „Dokument freigeben“ oder „Lieferant informieren“. Sie zeigen, welche Tätigkeit tatsächlich ausgeführt wird.
Gateways legen fest, ob ein Prozess einen von mehreren Wegen einschlägt, mehrere Tätigkeiten parallel startet oder auf Ergebnisse aus unterschiedlichen Pfaden warten muss. Sie zeigen, nach welcher Regel der Prozess weiterläuft.
Ereignisse verbinden den geplanten Ablauf mit der Realität. Sie reagieren auf eingehende Nachrichten, Fristen, Fehler oder andere Zustandsänderungen und sorgen dafür, dass der Prozess kontrolliert auf neue Situationen reagieren kann.
Zusammen bilden diese drei Elemente die Grundlogik eines BPMN-Modells: Aktivitäten führen Arbeit aus, Gateways lenken den Prozess und Ereignisse lösen Reaktionen aus. Wer dieses Prinzip versteht, kann bereits einen Großteil typischer Geschäfts- und Produktionsprozesse lesen und nachvollziehen.
Innerhalb eines Pools werden diese Elemente durch den Sequenzfluss miteinander verbunden. Zwischen unterschiedlichen Pools erfolgt die Kommunikation dagegen über Nachrichtenflüsse. Diese Trennung zeigt, wo das eigene Team den Prozess steuert und wo die Verantwortung an einen anderen Beteiligten übergeht.
Die Sprachanalogie: Vom Grundvokabular zur Prozesspräzision
Der Einstieg in BPMN ähnelt dem Erlernen einer Sprache. Zuerst reichen wenige Grundbegriffe aus, um einfache Zusammenhänge verständlich auszudrücken. Anwender starten mit Aktivitäten, Ereignissen und Gateways und modellieren zunächst ihre Kernprozesse.
Mit zunehmender Erfahrung kommen weitere Symbole hinzu, etwa für Nachrichten, Zeitgrenzen oder automatisierte Entscheidungen. So wächst das Modell mit der Aufgabe: Es bleibt für Fachbereiche lesbar und liefert zugleich eine präzise Grundlage für Audits, Digitalisierung und Automatisierung. Damit ist die Sprache geklärt. Entscheidend wird BPMN, wenn reale Vorgänge durch das Modell laufen und Engpässe, Abzweigungen oder Wartepunkte erkennbar werden.
Das Flipper-Prinzip: Wie Token und Instanzen Durchlaufzeiten sichtbar machen
Ein BPMN-Modell ist mehr als ein statischer Ablaufplan. Sein eigentlicher Nutzen zeigt sich, wenn mehrere reale Vorgänge gleichzeitig durch denselben Prozess laufen. Dafür hilft die Flipper-Analogie: Das Modell ist das Spielfeld mit Bahnen, Weichen, Stoppern und Zielpunkten. Es legt fest, welche Wege möglich sind und wo ein Vorgang abzweigt, wartet oder wieder zusammengeführt wird.
In der Metapher stehen die Kugeln für reale Vorgänge: ein Kundenauftrag, eine CAPA, eine Reklamation oder eine Änderungsanforderung. In BPMN entspricht jede Kugel einer Prozessinstanz. Ein Token zeigt, wo sich diese Instanz gerade im Modell befindet. So wird aus der Metapher ein praktisches Denkmodell: Das Spielfeld beschreibt die Prozesslogik, die Instanzen zeigen die Bewegung im Alltag.
Wenn mehrere Vorgänge gleichzeitig durch denselben Prozess laufen
Im Arbeitsalltag läuft selten nur ein einzelner Vorgang durch einen Prozess. Während ein Standardauftrag bereits in der Montage ist, wartet eine Reklamation auf Bewertung, eine Änderung durchläuft die technische Prüfung und ein Lieferant meldet eine Abweichung. Alle Vorgänge nutzen denselben Prozessrahmen, befinden sich aber an unterschiedlichen Stellen des Spielfelds.
- Standardvorgänge (1) folgen dem vorgesehenen Pfad, wenn alle Informationen vollständig sind und keine zusätzliche Prüfung erforderlich ist. Sie erreichen ohne Umweg die nächste Freigabe.
- Sonderfälle (2 und 3) nehmen andere Wege, weil eine Abweichung, eine fehlende Freigabe oder eine zusätzliche Bewertung weitere Schritte auslöst. Ein Teil des Vorgangs kann parallel weiterlaufen, während ein anderer Teil auf Klärung wartet. Erst wenn die erforderlichen Ergebnisse wieder zusammengeführt sind, darf der Prozess in die nächste Phase wechseln.
Abbildung 1: Prozessmodell über drei Abteilungen mit vier unterschiedlichen Instanzen
Instanz-Planung: Engpässe erkennen, bevor sie entstehen
Der Vorteil dieses Denkmodells liegt darin, dass ein Prozess nicht mehr nur als Idealablauf betrachtet wird. Stattdessen wird erkennbar, wie viele Vorgänge gleichzeitig unterwegs sind, welche Pfade sie nutzen und wo sich Arbeit staut.
So lassen sich Pufferzeiten, Liegezeiten und Kapazitäten bereits im Modell realistischer einschätzen. Teams erkennen früher, ob eine Prüfstelle zum Engpass wird, ob parallele Aufgaben wirklich Zeit sparen oder ob eine scheinbar kleine Ausnahme den gesamten Ablauf verzögert. Der Prozess wird nicht erst nach dem Go-live optimiert, sondern bereits vor der Umsetzung belastbarer geplant.
Von der Planung zur Kontrolle: Der Schritt in die digitale Ausführung
Diese Vorarbeit zahlt sich aus, sobald der modellierte Ablauf digital ausgeführt wird.
Aus dem geplanten Flipper-Modell wird dann ein operatives Kontrollbild. Jedes digitale Token trägt Zeitinformationen und Statusdaten. Dadurch wird nachvollziehbar, wo Vorgänge warten, welche Übergaben regelmäßig stocken und welche Prozesspfade mehr Kapazität binden als erwartet.
Statt Durchlaufzeiten erst im Rückblick zu diskutieren, können Teams den Prozess laufend beobachten und gezielt verbessern. Die Flipper-Analogie bleibt dabei einfach: Das Modell definiert das Spielfeld, die Instanzen zeigen die Bewegung und Engpässe entstehen dort, wo sich Vorgänge im Modell sammeln.
Die Gateway-Logik: Wie BPMN Entscheidungen, Parallelität und Synchronisation beherrschbar macht
Sobald reale Vorgänge im Modell erkennbar werden, stellt sich die nächste Frage: Nach welchen Regeln nehmen sie welchen Weg? Gateways beantworten genau diese Frage. In der Flipper-Analogie sind sie die Weichen im Spielfeld: Jede Instanz wird nach klaren Regeln weitergeleitet, gebremst, geteilt oder wieder zusammengeführt.
Der Unterschied zu klassischen Flussdiagrammen liegt in der Präzision. Eine einfache Raute kann Bedingungen enthalten. BPMN geht weiter: Es unterscheidet, ob genau ein Pfad gewählt wird, mehrere Pfade gleichzeitig starten oder optionale Pfade später wieder synchronisiert werden müssen. Damit werden aus offenen Interpretationen belastbare Prozessregeln.
XOR und AND: Eindeutig entscheiden oder bewusst parallelisieren
Das XOR-Gateway steht für eine exklusive Entscheidung: Der Prozess nimmt genau einen von mehreren möglichen Wegen. Ein Vorgang wird beispielsweise entweder freigegeben, zur Nacharbeit zurückgegeben oder abgelehnt. Dadurch entstehen keine doppelten Bearbeitungen und keine offenen Interpretationen darüber, welcher Pfad gültig ist.
Das AND-Gateway verfolgt den gegenteiligen Zweck: Es startet mehrere Pfade gleichzeitig und führt sie später wieder zusammen. Das ist hilfreich, wenn zum Beispiel technische Prüfung, Dokumentenfreigabe und Materialbereitstellung parallel laufen können. Der nächste Schritt beginnt erst, wenn alle erforderlichen Ergebnisse vorliegen.
Das inklusive OR-Gateway: Flexibilität ohne Kontrollverlust
Das inklusive OR-Gateway wird benötigt, wenn je nach Situation ein oder mehrere Pfade aktiv werden können. Es ist flexibler als XOR, weil nicht nur eine Option gewählt wird, und präziser als eine lose Nebenabsprache, weil alle aktivierten Pfade später kontrolliert zusammengeführt werden.
Ein Beispiel ist die Qualitätsfreigabe einer gefertigten Komponente. Je nach Prüfbefund kann eine manuelle Nacharbeit erforderlich sein, eine zusätzliche Messung notwendig werden oder beides parallel stattfinden. BPMN konkretisiert diese Varianten und legt fest, welche Ergebnisse vorliegen müssen, bevor der Prozess weiterlaufen darf.
Synchronisation: Warum das Zusammenführen genauso wichtig ist wie das Aufteilen
Gateways sind nicht nur Weichen. Sie sorgen auch dafür, dass getrennte Prozesspfade an der richtigen Stelle wieder zusammenlaufen. Genau hier entsteht Prozesssicherheit: Ein nachfolgender Arbeitsschritt wird erst freigegeben, wenn alle dafür notwendigen Voraussetzungen erfüllt sind.
In der Praxis kann das vor einer Endmontage entscheidend sein. Bauteile müssen verfügbar sein, Dokumente müssen freigegeben sein und Maschinen müssen bereitstehen. Werden diese Pfade sauber synchronisiert, entsteht kein Start auf Verdacht und kein zeitraubendes Nachfragen nach dem Status anderer Bereiche.
Für Anwender bedeutet das weniger Abstimmung per E-Mail, weniger ungeplante Stopps und klarere Übergaben. Für das Prozessdesign bedeutet es: Parallelität wird nur dort genutzt, wo sie wirklich beschleunigt, und der nächste Schritt startet erst dann, wenn die logischen Voraussetzungen vollständig erfüllt sind.
Events in BPMN: Wie Prozesse auf Fristen, Fehler und Rückmeldungen reagieren
Events, also Ereignisse in BPMN, ergänzen die geplanten Wege um konkrete Auslöser: eine neue Meldung, eine ablaufende Frist, eine Qualitätsabweichung oder eine unerwartete Rückmeldung. So beschreibt das Modell nicht nur den Soll-Ablauf, sondern auch, wie der Prozess auf solche Situationen geregelt reagiert.
Schleifen ohne Chaos: Wiederholen, bis das Zielkriterium erfüllt ist
Viele Prozesse enthalten notwendige Wiederholungen. Ein Prüfschritt muss erneut durchlaufen werden, eine Abweichung wird korrigiert oder ein Dokument geht nach einer Bewertung nochmals zurück in die Bearbeitung. Ohne klare Regeln entstehen daraus schnell unübersichtliche Rücksprünge und informelle Korrekturschleifen.
BPMN bildet solche Wiederholungen über definierte Schleifen ab. Entscheidend ist dabei die Abbruchbedingung: Der Prozess läuft nur so lange erneut, bis ein festgelegtes Ziel erreicht ist, zum Beispiel eine toleranzkonforme Messung, eine vollständige Freigabe oder eine abgeschlossene Nacharbeit. Dadurch bleibt die Wiederholung beherrschbar und der nächste Prozessschritt startet erst, wenn das Ergebnis tatsächlich vorliegt.
Angeheftete Ereignisse: Geplante Unterbrechung statt improvisierter Notfall
Reale Prozesse verlaufen selten störungsfrei. Während einer laufenden Montage kann ein Materialfehler gemeldet werden, während einer Prüfung kann eine kritische Abweichung auftreten oder während einer Freigabe kann eine fehlende Information auffallen. Ohne vordefinierten Umgang führen solche Ereignisse häufig zu Hektik, Rückfragen und uneinheitlichen Entscheidungen.
BPMN löst dieses Problem mit angehefteten Ereignissen, sogenannten Boundary Events. Sie sind direkt mit einer laufenden Aktivität verbunden und legen fest, was passieren soll, wenn ein bestimmtes Ereignis eintritt. Der Prozess kann kontrolliert unterbrochen, auf einen Alternativpfad geführt oder mit einer Eskalation fortgesetzt werden. So wird aus einer Störung kein improvisierter Ausnahmefall, sondern ein bewusst modellierter Prozesspfad.
Nicht-unterbrechende Events: Vorbereitung starten, ohne den Hauptprozess zu stoppen
Nicht jedes Ereignis muss den laufenden Schritt stoppen. Manchmal soll der Hauptprozess weiterlaufen, während im Hintergrund bereits eine Vorbereitung beginnt. Genau dafür nutzt BPMN nicht-unterbrechende Ereignisse: Sie lösen einen zusätzlichen Prozesspfad aus, ohne die aktuelle Aktivität zu beenden.
Während beispielsweise eine finale Qualitätsprüfung läuft, können parallel dazu die Verpackung vorbereitet, ein Transport organisiert oder eine Benachrichtigung an den nächsten Bereich ausgelöst werden. Das reduziert Wartezeiten, ohne den laufenden Prüfprozess zu destabilisieren. Für Anwender wird somit deutlich, dass Ereignisse nicht nur Reaktionen auf Probleme sind. Sie helfen auch, Arbeitsschritte rechtzeitig vorzubereiten und Übergaben besser zu timen.
Audits und Prozesssicherheit: Nachvollziehbarkeit statt Erklärungsaufwand
Ein gutes BPMN-Modell macht nachvollziehbar, wie ein Prozess tatsächlich gesteuert wird: welche Entscheidung wann getroffen wird, welche Ausnahme wohin führt und welche Nachweise an welcher Stelle entstehen. Genau diese Eindeutigkeit ist für Audits in regulierten MedTech-Umgebungen entscheidend.
Compliance by Design: Prozesslogik vor dem Audit klären
Auditoren prüfen nicht nur, ob Dokumente vorhanden sind. Sie wollen verstehen, ob die beschriebene Prozesslogik schlüssig, vollständig und im Alltag beherrschbar ist. Unklare Flussdiagramme erzeugen deshalb schnell Rückfragen: Was passiert bei einer Abweichung? Wer entscheidet über den nächsten Schritt? Welche SOP beschreibt die Ausnahme?
Ein BPMN-Modell unterstützt hier einen „Compliance by Design“-Ansatz. Entscheidungen, Ereignisse, Verantwortlichkeiten und Ausnahmen werden bereits bei der Modellierung explizit gemacht. Dadurch sinkt der Erklärungsaufwand im Audit, weil die Prozesslogik nicht nachträglich rekonstruiert werden muss.
Vom SOP-Text zur ausführbaren Prozesslogik
Zwischen QM-Anweisung und gelebter Praxis entsteht häufig eine Übersetzungslücke. Eine SOP beschreibt, was gelten soll. BPMN ersetzt die SOP nicht. Es übersetzt ihren Anspruch in prüfbare Prozesslogik: Wer handelt, wer entscheidet, welche Ausnahme wohin führt und welche Nachweise entstehen.
Workflow-Engines: Automatisierung beginnt mit eindeutigen Regeln
Workflow-Engines können Prozessschritte nur dann zuverlässig ausführen, wenn die zugrunde liegenden Regeln eindeutig beschrieben sind. Je klarer Aktivitäten, Entscheidungen, Ereignisse und Verantwortlichkeiten modelliert sind, desto einfacher lassen sie sich später in digitale Abläufe übertragen.
Das reduziert Missverständnisse zwischen Prozessverantwortlichen und IT-Teams. Gleichzeitig wird früher geklärt, welche Annahmen noch fehlen, welche Sonderfälle geregelt werden müssen und an welchen Stellen eine spätere Softwarevalidierung besondere Aufmerksamkeit braucht. Automatisierung wird dadurch nicht automatisch einfach, aber planbarer und besser prüfbar.
Stufenweise Digitalisierung: Erst stabilisieren, dann automatisieren
Der Nutzen von BPMN entsteht nicht erst, wenn ein Prozess vollständig automatisiert wird. Schon die Modellierung schafft Klarheit über Rollen, Übergaben, Varianten und Kontrollpunkte. Dadurch können Teams ihre Abläufe stabilisieren, bevor Software ins Spiel kommt.
- Im ersten Schritt klären Teams Rollen, Übergaben, Varianten und Sonderfälle. Reibungsverluste und informelle Umgehungen werden erkennbar und können bereinigt werden.
- Im zweiten Schritt werden die stabilisierten Abläufe in Workflow-Systeme, Validierung und Prozesskennzahlen übersetzt.
So wird BPMN zu einem pragmatischen Fahrplan: Heute verbessert es Verständlichkeit und Prozesssicherheit, später erleichtert es die technische Umsetzung. Unternehmen müssen nicht alles auf einmal automatisieren, sondern können dort beginnen, wo Unklarheiten, Wartezeiten oder Auditrisiken den größten Einfluss haben.
Fazit: Dokumentiert heißt nicht ausführbar
BPMN 2.0 ist kein Selbstzweck und kein weiteres Diagramm für die Prozessablage. Der Nutzen entsteht dort, wo Rollen denselben Ablauf bisher unterschiedlich verstanden haben: bei unklaren Übergaben, uneinheitlichen Entscheidungen, informellen Nebenwegen oder fehlenden Nachweisen.
Anwender verstehen Übergaben schneller. Qualitätsmanagement kann die SOP-Logik prüfen. IT-Teams erhalten präzisere Anforderungen für Workflow-Systeme.
Der erste Gewinn entsteht bereits, wenn Kernprozesse eindeutig modelliert, informelle Nebenwege offengelegt und kritische Übergaben geklärt werden. Erst danach lohnt sich die gezielte Digitalisierung stabiler Prozesspfade.
Der entscheidende Unterschied liegt nicht zwischen Papier und Software. Er liegt zwischen dokumentierten Abläufen und ausführbarer Prozesslogik. BPMN 2.0 hilft, genau diese Lücke zu schließen: erst im Modell, dann im Audit und schließlich in der digitalen Ausführung.
Q&A – Wann BPMN 2.0 im MedTech-Alltag wirklich hilft
Die folgenden Fragen greifen typische Entscheidungspunkte aus Prozessarbeit, QM, Auditvorbereitung und Digitalisierung auf. Sie zeigen, wann BPMN 2.0 über reine Dokumentation hinausgeht und wie aus beschriebenen Abläufen prüfbare, ausführbare Prozesslogik wird.
Warum reichen klassische Flussdiagramme im MedTech-Alltag oft nicht aus?
Klassische Flussdiagramme zeigen meist den idealen Ablauf, nicht die tatsächliche Prozesslogik. Sie lassen offen, wer bei Abweichungen entscheidet, welche Schritte parallel laufen und wann ein Vorgang weitergehen darf. Dadurch funktionieren sie im Alltag oft nur mit Erfahrungswissen, Nebenabsprachen und zusätzlichen Erklärungen.
Das Kernproblem liegt in der scheinbaren Klarheit. Ein Diagramm kann sauber aussehen und trotzdem entscheidende Regeln offenlassen: Ausnahmewege, Wartebedingungen, Eskalationen oder die Übergabe an andere Rollen. Solange eingespielte Teams diese Lücken mündlich schließen, fällt das kaum auf.
Spätestens bei Audit, Vertretung oder Digitalisierung wird daraus ein Problem. Der nächste Schritt ist deshalb nicht ein schöneres Diagramm, sondern die Klärung der Prozessregeln: Was startet den nächsten Schritt, wer entscheidet bei Abweichungen und welche Nachweise müssen entstehen?
Wann lohnt sich BPMN 2.0 für MedTech-Prozesse?
BPMN 2.0 lohnt sich, wenn ein Prozess nicht nur beschrieben, sondern gesteuert, auditiert oder digital ausgeführt werden soll. Der Nutzen entsteht bei unklaren Übergaben, parallelen Prüfungen, wiederkehrenden Sonderfällen und Prozessen, die mehrere Rollen oder Systeme verbinden.
Der häufige Denkfehler besteht darin, BPMN erst als Thema für Automatisierung zu sehen. Tatsächlich beginnt der Nutzen früher. Schon die Modellierung zeigt, wo Rollen unklar sind, wo Varianten nicht geregelt wurden und wo Teams im Alltag improvisieren.
Die nächste Handlung ist ein begrenzter Einstieg: Wählen Sie einen Prozess mit wiederkehrenden Rückfragen, Auditbedarf oder geplanter Digitalisierung. Modellieren Sie nicht sofort alles, sondern zuerst Start, Ende, Rollen, Entscheidungen, Ausnahmen und Nachweise. Dort zeigt sich schnell, ob BPMN die bisherigen Unklarheiten tatsächlich klärt.
Was passiert, wenn Prozesswissen nur in Köpfen und Nebenabsprachen steckt?
Implizites Prozesswissen macht Abläufe abhängig von einzelnen Personen. Solange erfahrene Mitarbeitende verfügbar sind, funktioniert der Prozess scheinbar stabil. Bei Vertretung, Wachstum, Audit oder Digitalisierung fehlen dann aber belastbare Regeln. Die Folge sind Rückfragen, uneinheitliche Entscheidungen und schwer nachvollziehbare Abweichungen.
Das Risiko entsteht oft an Schnittstellen. Dort klären Teams Sonderfälle per E-Mail, telefonisch oder durch Erfahrung. Im Alltag wirkt das pragmatisch. Für ein Prozessmodell, ein Audit oder ein Workflow-System ist es jedoch zu ungenau.
Die nächste Handlung ist eine Schnittstellenprüfung: Wo wird nachgefragt? Wo warten Vorgänge auf persönliche Klärung? Wo existieren Sonderwege außerhalb der SOP? Diese Punkte sollten nicht als Randfälle behandelt werden. Sie gehören in die Prozesslogik, weil sie später über Stabilität, Nachvollziehbarkeit und digitale Ausführbarkeit entscheiden.
Wie helfen Token und Instanzen bei Durchlaufzeiten und Engpässen?
Token und Instanzen zeigen, wie mehrere reale Vorgänge gleichzeitig durch denselben Prozess laufen. Dadurch wird erkennbar, wo Arbeit wartet, welche Pfade häufig genutzt werden und welche Ressourcen überlastet sind. Durchlaufzeiten werden so nicht erst rückblickend erklärt, sondern bereits im Modell gezielter geplant.
Das Problem liegt im Einzelfall-Denken. Viele Diagramme zeigen einen Vorgang von Start bis Ende. Der Arbeitsalltag besteht aber aus vielen parallelen Vorgängen: Aufträge, Reklamationen, Änderungen und Prüfungen laufen gleichzeitig und konkurrieren um dieselben Personen, Prüfplätze oder Freigaben.
Die nächste Handlung ist eine Instanz-Sicht auf den Prozess: Welche Vorgänge laufen gleichzeitig? Wo sammeln sie sich? Welche Sonderfälle blockieren den Standardpfad? Erst diese Perspektive zeigt, ob Parallelisierung wirklich Zeit spart oder nur neue Wartepunkte erzeugt.
Warum sind Gateways mehr als einfache Ja-nein-Entscheidungen?
Eine einfache Raute kann Bedingungen abbilden. Gateways gehen darüber hinaus, weil sie unterschiedliche Entscheidungslogiken ausdrücklich unterscheiden: exklusiv, parallel oder optional kombiniert. Dadurch wird klar, ob genau ein Pfad startet, mehrere Aufgaben gleichzeitig laufen oder Ergebnisse später wieder zusammengeführt werden müssen.
In einfachen Abläufen reicht eine Raute mit Bedingung oft aus. Kritisch wird es, wenn ein Prozess mehrere Prüfungen, Ausnahmen oder Rückmeldungen gleichzeitig berücksichtigen muss. Dann reicht die Frage „ja oder nein?“ nicht mehr. Entscheidend ist, welche Pfade aktiv werden und wann der nächste Schritt tatsächlich starten darf.
Als nächstes steht eine Gateway-Prüfung an kritischen Entscheidungspunkten an. Stellen Sie nicht nur die Frage, welche Bedingung gilt, sondern auch, welche Prozesswirkung daraus entsteht. Wird ein Pfad gewählt, werden mehrere Pfade gestartet oder müssen Ergebnisse wieder synchronisiert werden? Genau diese Unterscheidung verhindert spätere Missverständnisse in Modell, Audit und digitaler Umsetzung.
Wie unterstützt BPMN Audits, ohne die SOP zu ersetzen?
BPMN ersetzt keine SOP. Es übersetzt die SOP in prüfbare Prozesslogik: Wer handelt, wer entscheidet, welche Ausnahme wohin führt und welche Nachweise entstehen. Dadurch sinkt der Erklärungsaufwand im Audit, weil die Logik nicht erst während der Prüfung rekonstruiert werden muss.
Eine SOP kann formal vollständig wirken und den tatsächlichen Ablauf trotzdem nicht eindeutig steuern. Wenn Entscheidungen, Ausnahmen oder Nachweise nur im Text angedeutet sind, bleiben Interpretationsspielräume. Auditoren fragen dann nicht nach mehr Diagrammen, sondern nach schlüssiger Prozesslogik.
Die nächste Handlung erfolgt ein Abgleich zwischen SOP und Modell. Prüfen Sie dabei, ob alle relevanten Rollen, Entscheidungen, Ausnahmen und Nachweisstellen im BPMN-Modell enthalten sind. Fehlt ein Element, so ist das kein Darstellungsproblem, sondern ein Hinweis auf eine ungeklärte Prozessregel.