Einen Prozess und seinen Informationsfluss modellieren

Wenn drei Listen denselben Auftrag beschreiben

Die Morgenrot Veranstaltungstechnik GmbH verleiht Präsentationstechnik an Schulen und Vereine. Eine Anfrage kommt über ein Webformular an. Der Kundenservice prüft die Angaben und überträgt sie in eine Tabellenliste. Danach fragt er das Lager per Chat, ob Beamer und Mikrofone verfügbar sind. Das Lager antwortet ebenfalls im Chat. Eine Mitarbeiterin kopiert das Ergebnis zurück in die Liste und verschickt eine Bestätigung oder Absage per E-Mail.

In einem Gespräch klingen diese Schritte überschaubar. Im Alltag bleiben jedoch Fragen offen:

• Wo beginnt und wo endet der betrachtete Prozess?
• Wer entscheidet, ob eine Anfrage vollständig ist?
• Welcher Eintrag zeigt verbindlich, dass Geräte reserviert sind?
• Was passiert, wenn Angaben fehlen oder das Lager nicht antwortet?
• Welche Information wird an welcher Stelle von Hand übertragen?

Dein Auftrag lautet: Überführe die Beschreibung in ein lesbares Ist-Modell und mache den Informationsfluss sowie die Brüche zwischen Medien und Systemen sichtbar.

Die Grundidee lautet: Ein Prozessmodell zeigt nicht jedes Detail des Betriebs. Es zeigt einen bewusst abgegrenzten Ablauf so genau, dass Beteiligte dieselbe Reihenfolge, dieselben Entscheidungen und dieselben Informationen erkennen.

Du brauchst keine Erfahrung mit Business Process Model and Notation (BPMN). Wir verwenden in dieser Lektion eine kleine, erklärte Auswahl von Elementen. Sie lehnt sich an Aktivitätsmodelle an, bildet aber nicht die vollständige BPMN-Spezifikation ab.

Lege zuerst die Prozessgrenze fest

Ohne Grenze wächst ein Modell schnell in alle Richtungen. Zur Geräteanfrage gehören auch Einkauf, Wartung, Rechnung und Rückgabe. Für die aktuelle Frage reicht aber der Weg von der eingehenden Anfrage bis zur versendeten Zu- oder Absage.

Eine belastbare Abgrenzung nennt vier Punkte:

1. Auslöser: Welcher Zustand setzt den Ablauf in Gang?
2. Ergebnis: Welcher fachliche Zustand beendet den betrachteten Ablauf?
3. Gegenstand: Welcher Vorgang wird betrachtet?
4. Außerhalb: Welche angrenzenden Abläufe werden bewusst nicht modelliert?

Für Morgenrot ergibt sich diese Grenze:

Ein Ereignis beschreibt einen eingetretenen fachlichen Zustand. “Anfrage eingegangen” passt deshalb als Startereignis. “Anfrage prüfen” wäre dagegen eine Aktivität, weil dort jemand handelt.

Trenne Ablauf, Zuständigkeit und Information

Eine gute Prozessaufnahme beantwortet nicht nur “Was passiert?”. Sie trennt drei Perspektiven:

• Der Kontrollfluss zeigt, in welcher Reihenfolge Aktivitäten, Ereignisse und Entscheidungen aufeinanderfolgen.
• Die Rolle zeigt, wer eine Aktivität ausführt oder eine fachliche Verantwortung trägt.
• Der Informationsfluss zeigt, welche Information eine Aktivität liest, erzeugt oder verändert.

Diese Trennung verhindert einen typischen Fehler: Ein Dokument wird nicht selbst tätig. Die Tabellenliste “prüft” keine Anfrage. Der Kundenservice prüft die Anfrage und verwendet dafür die Formulardaten.

Erfasse die Elemente in einer Arbeitsliste

Bevor du Pfeile zeichnest, zerlegst du die Beschreibung. Verben weisen häufig auf Aktivitäten hin. Zustände wie “eingegangen” oder “versendet” eignen sich als Ereignisse. Wörter wie “wenn” oder “falls” markieren oft eine Entscheidung.

Aktivitäten formulierst du am besten mit einem Verb und einem fachlichen Objekt: “Verfügbarkeit prüfen” ist eindeutiger als “Lager” oder “Prüfung”. Entscheidungen formulierst du als Frage, deren ausgehende Wege eindeutige Bedingungen tragen.

Verwende wenige Elemente mit stabilen Leseregeln

Für das Ist-Modell reichen sechs Regeln:

1. Ein abgerundeter Knoten benennt ein Start- oder Endereignis als Zustand.
2. Ein rechteckiger Knoten benennt eine Aktivität mit Verb und Objekt.
3. Eine Raute stellt eine fachliche Entscheidung dar.
4. Ein durchgezogener Pfeil zeigt die Reihenfolge im betrachteten Ablauf.
5. Ein gestrichelter Knoten benennt ein gelesenes oder geschriebenes Informationsobjekt.
6. Bereiche mit Rollennamen ordnen Aktivitäten den zuständigen Rollen zu.

Das folgende Mermaid-Diagramm ist ein didaktisch vereinfachtes Aktivitätsmodell. Mermaid besitzt keine vollständige BPMN-Semantik. Deshalb solltest du seine Formen nicht als normgerechte BPMN-Symbole ausgeben. Entscheidend sind hier die offengelegten Leseregeln und die konsistente Anwendung.

Rollen bleiben trotz kompakter Grafik sichtbar

Für ein größeres Modell würdest du die Aktivitäten in Bereiche für Kundenservice und Lagerteam aufteilen, oft Swimlanes genannt. Im kompakten Diagramm ist die Zuständigkeit im Begleittext festgelegt:

• Der Kundenservice prüft Angaben, pflegt die Liste und versendet Rückmeldungen.
• Das Lagerteam prüft den physischen Bestand.
• Die anfragende Person liefert Daten und erhält die Rückmeldung, führt aber innerhalb der gewählten Grenze keine interne Aktivität aus.

Ein Pfeil zwischen zwei Aktivitäten sagt allein nichts über die Verantwortung. Wenn die Rollen für eine Übergabe wichtig sind, müssen sie im Modell oder in einer gleichwertigen Legende stehen.

Unterscheide Entscheidung und Parallelität

Eine exklusive Entscheidung bedeutet: Genau einer der ausgehenden Wege wird gewählt. Nach “Geräte verfügbar?” folgt entweder die Zusage oder die Absage. Bedingungen wie “ja” und “nein” machen die Auswahl nachvollziehbar.

Eine parallele Verzweigung bedeutet dagegen: Mehrere Wege laufen unabhängig voneinander an und werden später gemeinsam benötigt. Beispiel: Nach einer bestätigten Reservierung könnten Lager und Buchhaltung gleichzeitig einen Abholschein und eine Kautionsrechnung vorbereiten. Dieser Teil liegt außerhalb unseres Ist-Modells, zeigt aber den Unterschied.

Mache Medien-, System- und Übergabebrüche sichtbar

Ein Medienbruch liegt vor, wenn Informationen zwischen unterschiedlichen Darstellungs- oder Übertragungsformen wechseln und nicht durchgängig weiterverarbeitet werden. Das manuelle Übertragen aus einem Webformular in eine Tabellenliste ist ein Beispiel.

Ein Systembruch bezeichnet den Wechsel zwischen Systemen ohne durchgängige technische Übergabe. Webformular, Tabellenliste und Chat sind getrennte Systeme. Ein Medienbruch und ein Systembruch können gemeinsam auftreten, sind aber nicht dasselbe.

Ein Übergabebruch ist breiter. Er entsteht, wenn Verantwortung oder benötigte Information an einer Schnittstelle unklar bleibt. Selbst zwei technisch verbundene Systeme lösen dieses Problem nicht automatisch.

Das Ist-Modell bewertet diese Stellen noch nicht als “schlecht”. Es zeigt sie so, dass eine spätere Analyse Daten erheben kann. Ein manueller Schritt kann beispielsweise bewusst als Kontrolle vorgesehen sein. Erst Beobachtungen zu Fehlern, Aufwand oder Wartezeit tragen eine Bewertung.

Verfolge jedes Informationsobjekt durch den Ablauf

Für jedes wichtige Informationsobjekt beantwortest du vier Fragen:

1. Wo entsteht die Information?
2. Welche Aktivität liest sie?
3. Welche Aktivität verändert oder ergänzt sie?
4. Welche Fassung gilt als verbindlich?

Bei Morgenrot entsteht die Anfrage im Webformular. Der Kundenservice liest die Anfragedaten und erzeugt daraus einen Eintrag in der Reservierungsliste. Das Lager erzeugt eine Verfügbarkeitsmeldung im Chat. Der Kundenservice liest diese Meldung und versendet daraus die Rückmeldung.

Dabei fällt auf: Es gibt keine eindeutig benannte, verbindliche Reservierungsbestätigung des Lagers. Die Tabellenliste enthält eine übertragene Aussage, die ursprüngliche Chatmeldung bleibt an anderer Stelle. Genau diese Unklarheit ist ein Ergebnis der Ist-Aufnahme. Du brauchst noch keine technische Lösung, um sie sichtbar zu machen.

Validiere das Modell mit konkreten Durchläufen

Ein Modell wird nicht dadurch richtig, dass alle Knoten verbunden sind. Prüfe es mit Beteiligten und mindestens drei Fällen:

• Normalfall: vollständige Anfrage und Geräte verfügbar,
• Alternativfall: vollständige Anfrage und Geräte nicht verfügbar,
• Ausnahmefall: Pflichtangaben fehlen oder eine Rückmeldung bleibt aus.

Gehe jeden Fall vom Auslöser bis zum Ergebnis durch. Frage an jeder Aktivität: Wer handelt? Welche Information liegt vor? Welcher Zustand entsteht danach? So findest du fehlende Schleifen, unbeschriftete Entscheidungen und stillschweigende Annahmen.

Was du jetzt aus dem Ist-Modell ableiten kannst

Du hast den Ablauf so weit strukturiert, dass andere Personen ihn prüfen können. Das Modell zeigt:

• den Auslöser und zwei fachliche Endzustände,
• die Zuständigkeiten von Kundenservice und Lagerteam,
• zwei exklusive Entscheidungen,
• Anfragedaten, Reservierungsliste und Chatmeldung als Informationsobjekte,
• manuelle Übertragungen und eine offene Übergabe als Ansatzpunkte für die Analyse.

Damit ist noch keine Optimierung begründet. Eine spätere Lektion kann Bearbeitungszeiten, Fehler oder Wartephasen mit Kennzahlen untersuchen. Erst danach werden Lösungsvarianten und ein Soll-Prozess entwickelt.

Quellenbasis und Grenzen

Der KMK-Rahmenlehrplan ordnet die Analyse und Gestaltung von Prozessen dem Lernfeld 11c zu. Die Ausbildungsordnung trägt die Analyse von Arbeits- und Geschäftsprozessen sowie das Analysieren und Bereitstellen von Daten über die Berufsbildpositionen D1 und D2. Der Prüfungskatalog nennt für Prozessmodelle unter anderem Ereignisse, Funktionen oder Aufgaben, Organisationseinheiten, Objekte, Kontroll- und Informationsflüsse sowie Verzweigungen.

Die Lektion verwendet diese Themenbreite, übernimmt aber keine Prüfungsaufgabe. Morgenrot und Velofix, alle Abläufe und alle Daten sind neu erstellt. Das Mermaid-Diagramm ist kein normgerechtes BPMN-Diagramm. Es reduziert die Darstellung auf erklärte Aktivitätselemente. Wer BPMN in einem Projekt verbindlich einsetzt, braucht zusätzlich die vollständigen Regeln der gewählten BPMN-Konformitätsklasse und ein dafür geeignetes Modellierungswerkzeug.