BPMN Artefakte & Datenobjekte: Informationen und Hinweise im Prozess sichtbar machen

Wenn du die bisherigen Artikel dieser Serie gelesen hast, verfügst du bereits über ein solides Fundament. Du weißt, wer arbeitet (Pools & Lanes), wann es losgeht (Events) und wie die Arbeit verrichtet wird (Activities & Gateways). Das ist das logische Skelett eines jeden Prozesses.

Doch wenn wir ehrlich sind, fehlt noch eine entscheidende Dimension. Ein Geschäftsprozess ist niemals ein Selbstzweck. Wir führen ihn nicht aus, nur um Pfeile abzulaufen. Wir führen ihn aus, um Informationen zu verarbeiten oder Dinge zu erzeugen. Wir prüfen einen Antrag, wir schreiben eine Rechnung, wir speichern einen Kundendatensatz.

Das ist das "Was" im Prozess.

Stell dir deinen Prozess wie eine moderne Fertigungsstraße vor. Die Activities sind die Maschinen, die Gateways die Weichen und die Sequenzflüsse das Förderband. Aber ein Förderband, auf dem nichts liegt, produziert keinen Wert. Es läuft leer. Um zu verstehen, was wirklich passiert, müssen wir sehen, welches Material (Input) in die Maschine hineingeht und welches fertige Produkt (Output) hinten herauskommt.

In der BPMN-Welt nutzen wir dafür Artefakte und Datenobjekte. Sie beeinflussen den Fluss deines Prozesses technisch gesehen nicht – der Token läuft einfach an ihnen vorbei. Aber für den menschlichen Betrachter (und für die spätere IT-Umsetzung) sind sie unverzichtbar, weil sie den Kontext liefern. Sie beantworten die Fragen: "Welches Dokument brauche ich hier?" und "In welcher Datenbank landet das Ergebnis?".

In diesem Artikel lernst du, wie du dein "Prozess-Förderband" mit den richtigen Paketen bestückst, ohne das Diagramm zu überladen.

Das Symbol, das dir in diesem Zusammenhang am häufigsten begegnen wird, ist das Datenobjekt (Data Object). Du erkennst es sofort: Es ist das kleine, stehende Blatt Papier mit der umgeknickten Ecke oben rechts. Dieses Symbol repräsentiert Informationen oder Dokumente, die während des Prozesses benötigt oder erzeugt werden.

Dabei ist BPMN herrlich agnostisch, was das Format angeht. Ob dieses "Blatt Papier" in der Realität ein physischer Urlaubsantrag, eine PDF-Rechnung oder ein temporärer Datensatz im Arbeitsspeicher ist, spielt für das Symbol keine Rolle. Es symbolisiert einfach den "Stoff", mit dem deine Aktivitäten arbeiten.

Input und Output

Die Funktion des Datenobjekts ist dual. Es dient entweder als Input, also als notwendige Zutat, damit eine Aufgabe überhaupt starten kann – ohne Rechnung kann man sie nicht prüfen. Oder es dient als Output, also als das Ergebnis, das eine Aufgabe produziert – nach dem Schreiben ist die Rechnung fertig. Ein Datenobjekt existiert dabei logisch gesehen immer im Kontext der laufenden Prozessinstanz. Stell es dir wie eine physische Laufmappe vor, die von Schreibtisch zu Schreibtisch weitergereicht wird.

Profi-Tipp: Zustände sichtbar machen

Ein Konzept, das in "Method & Style" besonders hervorgehoben wird und deine Diagramme enorm aufwertet, ist die Nutzung von Zuständen (States). Ein Dokument bleibt im laufe des Prozesses selten unverändert. Es durchläuft eine Evolution.

Stell dir einen Beschaffungsprozess vor. Am Anfang hast du eine Bestellung. Nachdem der Chef draufgeschaut hat, ist es immer noch eine Bestellung, aber jetzt hat sie eine andere Qualität. Statt nun neue, verwirrende Namen zu erfinden, nutzt du dasselbe Datenobjekt, fügst aber den Zustand in eckigen Klammern hinzu.

So wird aus der Bestellung [erfasst] nach der Prüfung eine Bestellung [genehmigt] oder Bestellung [abgelehnt]. Wenn du diese Zustandsänderungen im Diagramm modellierst, erzählst du eine viel dichtere Geschichte: Der Betrachter sieht nicht nur, dass gearbeitet wird, sondern wie sich die Datenqualität von Schritt zu Schritt verbessert.

Während das Datenobjekt wie eine Akte ist, die von Schreibtisch zu Schreibtisch wandert, fungiert der Datenspeicher (Data Store) als das Archiv oder die Bibliothek deines Unternehmens. Du erkennst ihn an dem klassischen Symbol für eine Datenbank: dem kleinen Zylinder oder der "Tonne".

Der entscheidende Unterschied zum einfachen Datenobjekt liegt in der Lebensdauer – oder technisch ausgedrückt: in der Persistenz. Ein Datenobjekt existiert nur, solange der Prozess läuft. Sobald der Auftrag erledigt ist, verschwindet die virtuelle "Laufmappe" (sie wird archiviert oder vernichtet).

Ein Datenspeicher hingegen überdauert den Prozess. Die Informationen, die dort liegen, bleiben erhalten, auch wenn gerade niemand arbeitet. Das macht den Data Store zum idealen Symbol für IT-Systeme wie dein CRM, dein ERP oder ein physisches Aktenarchiv.

Warum ist diese Unterscheidung für dein Modell wichtig? Weil ein Datenspeicher prozessübergreifend ist. Ein Prozess ("Neukunde anlegen") schreibt Daten in den Speicher hinein. Ein völlig anderer Prozess ("Jahreskampagne planen"), der vielleicht Monate später läuft, liest diese Daten wieder aus. Wenn du also zeigen willst, dass Informationen nicht nur kurzfristig genutzt, sondern dauerhaft für das ganze Unternehmen gesichert werden, greifst du zur Datenbank-Tonne. Es ist der Ort, an dem das Wissen deiner Firma wohnt, unabhängig vom einzelnen Vorgang.

Jetzt, wo wir die Symbole für unsere Daten auf dem Spielfeld haben, müssen wir sie mit den Aktivitäten verbinden. Und hier lauert ein Fehler, den ich in fast jedem Einsteiger-Diagramm sehe: Viele verbinden das Datenobjekt intuitiv mit einem durchgezogenen Pfeil (Sequenzfluss). Das ist logisch zwar nachvollziehbar ("Erst Daten, dann Arbeit"), aber in der BPMN-Syntax strikt verboten.

Warum? Der Sequenzfluss ist ausschließlich für den zeitlichen Ablauf reserviert – er sagt "Dann passiert das". Ein Dokument ist aber kein Handlungsschritt. Ein Dokument passiert nicht, es ist einfach da.

Die Assoziation (Der gepunktete Pfeil)

Um Datenobjekte korrekt anzubinden, nutzen wir die Assoziation. Du erkennst sie an der gepunkteten Linie. Sie dient als universeller Klebstoff, um Informationen (Artefakte) mit dem Prozessfluss zu verknüpfen, ohne den Fluss selbst zu stören.

Die Richtung entscheidet: Lesen oder Schreiben

Wenn du Daten modellierst, ist die Pfeilspitze dieser gepunkteten Linie entscheidend. Sie erzählt uns, was die Aufgabe mit den Daten macht. Wir sprechen hier von einer gerichteten Assoziation (Directed Association).

• Pfeil vom Datenobjekt zur Aufgabe (Input):

  Das bedeutet "Lesen". Die Aufgabe benötigt diese Daten, um starten zu können. Wenn du einen gepunkteten Pfeil von der Rechnung zur Aufgabe Rechnung prüfen ziehst, sagst du damit: "Lieber Sachbearbeiter, fang gar nicht erst an, bevor dieses Dokument nicht auf deinem Tisch liegt."
  
  

• Pfeil von der Aufgabe zum Datenobjekt (Output):

  Das bedeutet "Schreiben" oder "Erzeugen". Die Aufgabe produziert diese Daten als Ergebnis. Wenn der Pfeil von Rechnung prüfen wegführt zu einem Datenobjekt Rechnung [geprüft], sagst du damit: "Das Ergebnis meiner Arbeit ist dieses Dokument in diesem Zustand."
  
  

Diese Unterscheidung zwischen Input und Output ist besonders wichtig, wenn du später in Richtung Automatisierung (Service Tasks) gehst, da Computerprogramme sehr genau wissen müssen, welche Parameter sie "fressen" und welche sie "ausspucken".

Manchmal reicht die formale Logik von Aufgaben und Gateways nicht aus, um einen Prozess wirklich verständlich zu machen. Du hast zwar modelliert, dass eine Rechnung geprüft wird, aber im Diagramm steht nicht, nach welchen Kriterien das geschieht. Oder du möchtest zeigen, dass fünf völlig unterschiedliche Aufgaben logisch zur "Phase 1: Initialisierung" gehören, ohne gleich die Prozessstruktur umzubauen.

Für genau diese Fälle bietet BPMN zwei Elemente an, die keinen Einfluss auf den technischen Ablauf haben (die Process Engine ignoriert sie komplett), aber für den menschlichen Leser Gold wert sind.

Die Text-Annotation: Dein Regie-Kommentar

Das erste Werkzeug ist die Text-Annotation. Du erkennst sie an der offenen eckigen Klammer, die mit einer gepunkteten Linie an ein Element geheftet ist. Sie ist der ideale Ort für Zusatzinformationen, die den Rahmen eines Task-Namens sprengen würden.

Stell dir vor, du hast ein Gateway, das entscheidet: "Genehmigung erforderlich?". Technisch reicht das. Aber für den neuen Mitarbeiter wäre es hilfreich zu wissen, wann genau eine Genehmigung erforderlich ist. Mit einer Annotation schreibst du einfach "Nur bei Beträgen > 5.000 €" an das Gateway. So lagerst du Business-Regeln und Erklärungen sauber aus, ohne die Beschriftung der Symbole zu überladen.

Die Gruppe: Das Gummiband

Das zweite Werkzeug ist die Gruppe (Group). Sie wird als Rechteck mit abgerundeten Ecken und einer strich-punktierten Linie dargestellt.

Hier müssen wir kurz innehalten, denn die Verwechslungsgefahr mit dem Subprozess ist riesig. Optisch sehen sie ähnlich aus, aber funktional sind sie Gegensätze. Ein Subprozess ist ein fester Container – was drin ist, gehört ihm. Eine Gruppe hingegen ist eher wie ein loses Gummiband, das du auf den Tisch legst, um ein paar Dinge optisch zusammenzufassen.

Der entscheidende Unterschied: Eine Gruppe hat keinerlei technische Bedeutung. Sie verändert den Sequenzfluss nicht, sie kapselt keine Daten und sie erstellt keinen neuen Geltungsbereich. Das macht sie aber extrem flexibel. Du kannst mit einer Gruppe Dinge einkreisen, die technisch gar nicht zusammengehören – zum Beispiel drei Tasks aus dem Pool "Vertrieb" und zwei aus dem Pool "Marketing", um zu zeigen: "Das alles gehört zu unserer Kampagne". Ein Subprozess könnte niemals über Pool-Grenzen hinweg gehen – eine Gruppe schon.

Nutze Gruppen also immer dann, wenn du dem Leser eine visuelle Orientierungshilfe ("Das hier ist Phase A") geben willst, ohne die strenge Hierarchie des Prozesses anzufassen.

Artefakte sind mächtig, aber sie bergen eine große Gefahr: die Datenflut. Ich sehe oft Diagramme, die vor lauter Datenobjekten kaum noch lesbar sind. Da wird jeder einzelne Parameter, jede E-Mail und jeder Datenbankeintrag als eigenes Symbol an den Task geklebt. Das Ergebnis ist ein "Spaghetti-Diagramm" aus gepunkteten Linien, bei dem niemand mehr den eigentlichen Prozessfluss erkennt.

Die Regel der Relevanz

Die wichtigste Regel für saubere Diagramme lautet: Modelliere nur die Daten, die für das Verständnis des Ablaufs kritisch sind.

Frage dich bei jedem Objekt: "Versteht der Leser den Prozess nicht, wenn ich dieses Dokument weglasse?"

• Wenn eine Abteilung eine physische Akte an eine andere übergibt, ist das ein kritisches Datenobjekt. Das muss ins Bild.

• Wenn ein Task im Hintergrund fünf temporäre Variablen berechnet, ist das für das Prozessmodell meist irrelevant. Lass es weg.

Business vs. Executable

Hier müssen wir kurz differenzieren. Wenn du Prozesse für die Automatisierung (Executable BPMN) designst, musst du extrem penibel sein. Ein Service Task braucht exakt definierte Inputs und Outputs, sonst stürzt die Software ab. Aber diese technischen Details versteckt man oft in den Eigenschaften des Elements und malt sie nicht alle als grafische Symbole auf die Leinwand. Für das fachliche Prozessmodell, das Menschen lesen sollen, gilt immer: Übersichtlichkeit schlägt Vollständigkeit.

Artefakte und Datenobjekte sind das Salz in der Suppe deiner Prozessmodelle. Ohne sie ist der Prozess vielleicht technisch korrekt ("Wir laufen von A nach B"), aber er schmeckt fad und inhaltsleer. Erst durch die Information, welche Dokumente bearbeitet werden und welche Systeme wir nutzen, entsteht ein Bild der realen Arbeitswelt.

Nutze sie weise. Ein gut platziertes Datenobjekt mit einem klaren Zustand (z. B. [genehmigt]) erzählt oft mehr als drei zusätzliche Tasks.

Hier ist dein Spickzettel für die tägliche Arbeit: