Prozessdenken: Logik sichtbar machen

Das Problem: „Wir haben das halt immer so gemacht.” Prozesse existieren in Köpfen, Excel-Tabellen und E-Mail-Threads, aber nirgendwo als strukturierte Logik. Wenn dann jemand automatisieren soll, geht die Hälfte der wichtigen Regeln verloren.

---

Low-Code zwingt zum Denken in Prozessen

Jeder spricht über Prozesse. Kaum jemand sieht sie.

Low-Code ändert das. Denn jedes Element, ob Flow, App oder Dashboard, muss irgendwo starten, etwas tun, Entscheidungen treffen und wieder enden.

Prozessdenken bedeutet, Abläufe strukturiert, wiederholbar und logisch zu modellieren, mit Anfang, Verlauf und möglichem Ende.

---

Was einen Prozess ausmacht

Ein Prozess ist mehr als eine Aufgabenliste. Er hat:

Element	Frage	Beispiel
Auslöser	Was startet den Prozess?	Formular wird abgesendet
Verlauf	Was passiert in welcher Reihenfolge?	Prüfung → Genehmigung → Bestätigung
Entscheidungen	Welche Ja/Nein-Fragen gibt es?	Betrag > 1.000€?
Ergebnis	Was soll am Ende stehen?	E-Mail, Eintrag, Statusänderung
Rollen	Wer ist beteiligt?	Mitarbeiter, Führungskraft, HR
Grenzen	Was darf nicht passieren?	Doppelt genehmigen

---

Prozesse auf verschiedenen Ebenen

graph TD
 L1[" Strategische Ebene\nUnternehmensziele, Wertketten"] --> L2
 L2[" Taktische Ebene\nKernprozesse, Abteilungsabläufe"] --> L3
 L3[" Operative Ebene\nEinzelne Workflows, Tasks"] --> L4
 L4[" Technische Ebene\nFlows, Apps, Automatisierungen"]

 style L1 fill:#dbeafe,stroke:#3b82f6
 style L2 fill:#e0f2fe,stroke:#0ea5e9
 style L3 fill:#fef3c7,stroke:#f59e0b
 style L4 fill:#dcfce7,stroke:#22c55e

Low-Code arbeitet meist auf der operativen und technischen Ebene, aber ein gutes Low-Code-Projekt beginnt immer mit dem Verständnis der taktischen Ebene.

---

Vom Ablauf zum Prozessmodell

Ein Ablauf ist: „Schritt 1, Schritt 2, Schritt 3.” Ein Prozessmodell enthält zusätzlich:

• Rollen, Wer tut was?
• Regeln, Was darf wann passieren?
• Status, Wo befindet sich das Objekt gerade?
• Grenzen, Was darf nicht passieren?

Und es enthält Muster, die wiederverwendbar sind:

• 2-stufige Genehmigung
• Zustandslogik (genehmigt / zurückgestellt / abgelehnt)
• Eskalationspfade

---

BPMN: Ein kurzer Überblick

BPMN (Business Process Model and Notation) ist der internationale Standard für Prozessmodellierung. Du musst kein Experte sein, aber ein Grundverständnis hilft enorm.

BPMN-Element	Symbol	Bedeutung
Start-Ereignis	○	Was löst den Prozess aus?
Ende-Ereignis	●	Wie endet er?
Aktivität (Task)	□	Was wird getan?
Gateway (XOR)	◇	Entscheidung: Nur ein Pfad
Gateway (AND)	◇+	Parallel: Alle Pfade
Sequenzfluss	→	Reihenfolge
Pools / Lanes	[ ]	Wer ist für was zuständig?

Tools für einfache BPMN-Diagramme (kostenlos): draw.io, Lucidchart, Miro, Visio

---

Gute Praxis in Power Automate

graph LR
 subgraph Schlecht[" Unsichtbare Logik"]
 S1["Step1"] --> S2["Step2"] --> S3["Step3"] --> S4["???"]
 end
 subgraph Gut[" Sichtbare Logik"]
 G1[" Antrag empfangen"] --> G2{"Betrag > 1000€?"}
 G2 -->|Ja| G3[" Manager\nbenachrichtigen"]
 G2 -->|Nein| G4[" Auto-genehmigen"]
 G3 --> G5[" Status\nsetzen"]
 G4 --> G5
 end
 style Schlecht fill:#fee2e2,stroke:#ef4444
 style Gut fill:#dcfce7,stroke:#22c55e

Praktische Empfehlungen:

• Nutze klare Benennungen für Aktionen, Variablen und Bedingungen
• Kommentiere Logikblöcke (in Power Automate über „Notizen”)
• Gruppiere zusammengehörige Aktionen in Scopes
• Füge Logging hinzu: „Antrag wurde genehmigt durch X”

---

Der entscheidende Satz

„Ein Prozess ist erst dann verstanden, wenn er auf einen Blick erklärbar ist, auch ohne Fachvokabular.”

Wenn du deinen Flow einem Kollegen in zwei Minuten erklären könntest, der noch nie damit gearbeitet hat, dann ist er gut genug. Wenn nicht: Struktur fehlt.

---

Wer Prozesse sauber denkt, legt das Fundament für:

• Wiederverwendung, Prozessmuster einmal bauen, überall einsetzen
• Monitoring, Was läuft gut? Was hängt?
• Reporting, KPIs aus Prozessdaten ableiten
• Skalierbarkeit, Neue Anforderungen leicht integrierbar

Und das alles, ohne eine Zeile Code.

---