CAFM: Workflow- und Prozesskonfiguration

Workflows bestehen im BPMN-Modell im Wesentlichen aus Ereignissen, Aktivitäten/Tasks und Gateways. Ein Start-Ereignis (meist ein leerer Kreis) löst den Prozess aus, z. B. die Erstellung eines Tickets oder Empfang einer E‑Mail[7]. Aktivitäten (Rechtecke) repräsentieren Arbeitsschritte – etwa „1st-Level-Support prüft Ticket“ oder „Vertrag wird erstellt“. Gateways (Rauten) steuern den Ablauf verzweigt z. B. „Ist Genehmigung erforderlich? Ja/Nein?“. An Zwischenereignissen können Timer (Uhr), Nachrichten oder Eskalationen angehängt sein, um automatische Wartezeiten oder Eskalationspfade abzubilden. So zeigt ein klassisches Beispiel: Startevent: Ticket eingereicht → Aktivität: 1st-Level prüft → Gateway: „Problem lösbar?“ – Ja: direkt gelöst und Ende; Nein: Aktivität „an 2nd-Level eskalieren“, dann lösen und Ende. Solche Diagramme visualisieren auch Eskalationsschritte (z. B. wann Prioritäten erhöht oder Vorgesetzte informiert werden). Die ikonische Darstellung (siehe Abbildung) hilft allen Beteiligten, den Prozessablauf auf einen Blick zu erfassen.

Ein Workflow muss den Personen und Rollen im CAFM zugeordnet werden. In BPMN geschieht dies über Pools/Lanes – z. B. eine Lane „Helpdesk“, eine „Abteilungsleitung“ usw. Innerhalb dieser Lanes werden die Tasks platziert. Ergänzend kann die oben erwähnte RACI-Matrix helfen, Verantwortlichkeiten zu klären. Zum Beispiel kann ein RACI-Diagramm zeigen, dass der Projektleiter für einen Aufgabenbereich Responsible ist, der Abteilungsleiter Accountable, Fachexperten Consulted und die Finanzabteilung Informed.

Die Workflow-Engine muss Regeln erhalten, um Prozessen Leben einzuhauchen. Dazu gehören Trigger (z. B. neuer Request, Eingangsdatum, Schwellenwerte), Bedingungen (z. B. „sofortige Freigabe, wenn Betrag < X“), Fristen/Timer (z. B. „Genehmigung spätestens 3 Werktage“), und Eskalationsregeln. Konkrete Beispiele: Ein mehrstufiger Genehmigungsprozess kann so eingerichtet werden, dass Projektleiter einen Antrag zuerst prüfen und Abteilungsleiter abschließend genehmigen. Die Konfiguration muss flexibel sein – z. B. kann man eine „automatische Freigabe unterhalb eines Schwellwertes“ definieren und im Fehlerfall den Anwender zur Korrektur zurückschicken. Für Eskalation legt man Regeln fest wie: „Wenn nach X Tagen keine Rückmeldung, informiere den Vorgesetzten automatisch“. In einem effektiven Eskalationsmanagement werden solche Regeln bereits hinterlegt – zum Beispiel kann ein Ticket automatisch in die nächste Prioritätsstufe gehoben werden, wenn es zu lange unbeantwortet ist. Schleifen für Nacharbeit werden meist durch „Abgelehnt → zurück zum Antragsteller“ abgebildet.

Workflows im CAFM operieren stets auf Basis der Stammdaten im System. Beispielsweise werden Maintenance-Aufträge mit Anlagen- oder Raum-IDs verknüpft, Verträge mit Vertragsnummern, Umzugsanträge mit Personen- oder Abteilungsdaten. In BPMN kann man dies durch Datenobjekte (Data Objects) visualisieren – etwa ein an eine Aktivität angehängtes Formularsymbol oder Dokument, das den Asset-Namen oder Vertragstitel zeigt. So weiß das System bei jeder Aufgabe automatisch, auf welchen Datensatz sie sich bezieht. Die Parameter eines Workflows (z. B. Anlagen-ID, Kostenstelle, Vertragsart) werden meist über das CAFM-Formular oder die Datenbank während der Prozessauslösung übergeben. Durch diese enge Verknüpfung mit Stammdaten sind Statusmeldungen, Historien und Berichte jederzeit eindeutig rückverfolgbar.

Zur Steuerung der Abläufe kommuniziert das CAFM-System automatisch mit den Beteiligten. Üblich sind E-Mail-Benachrichtigungen oder interne Aufgabenlisten (Task-Management) für jeden Arbeitsschritt. Beispielsweise erhält ein Genehmiger eine Nachricht „Ein neuer Wartungsauftrag wartet auf Freigabe“. Moderne Systeme können auch Push-Mitteilungen (App/Smartphone) oder Kalendertermine erzeugen. In jedem Fall bleiben die Beteiligten durch diese automatisierten Hinweise über anstehende Aufgaben informiert. Kommt es zu Verzögerungen, werden vordefinierte Eskalationen aktiv – etwa eine weitere Benachrichtigung an einen Vorgesetzten, wenn die erste Genehmigung nicht fristgerecht erfolgt ist. Monitoring-Tools im CAFM zeigen zudem den aktuellen Workflow-Status (Ampel, Dashboard), so dass Engpässe oder SLA-Verstöße frühzeitig erkannt werden. Insgesamt sorgt die Kombination aus Benachrichtigungen und klarer Aufgabenverteilung dafür, dass jeder Schritt zuverlässig abgearbeitet wird und keine Anfrage „unter den Tisch fällt“.

Vor Produktivsetzung müssen alle Workflows ausführlich getestet werden. Empfehlenswert ist ein schrittweises Vorgehen: Zuerst einfache Kern-Workflows modellieren und testen, dann nach und nach Komplexität aufbauen. In Testprotokollen werden verschiedene Szenarien simuliert: z. B. genehmigte, abgelehnte oder eskalierte Fälle. Jede Regel (Trigger, Eskalation, Schleife) wird daraufhin überprüft, dass sie wie erwartet funktioniert. Fallbeispiele aus der Praxis helfen beim Validieren – z. B. fiktive Meldungen für Helpdesk oder Wartung mit bekannten Entscheider- und Eskalationswegen. Idealerweise prüft man außerdem, ob die Verknüpfungen zu Stammdaten korrekt sind (z. B. ob nach Prozessende der richtige Anlagenstatus gesetzt wird). Erst wenn Testläufe zeigen, dass alle Pfade korrekt arbeiten (inklusive Fehlerszenarien), geht der Workflow live.

Einmal definierte Workflows müssen gepflegt werden – hier sind Governance und Change-Prozesse essenziell. Jeder Workflow sollte dokumentiert sein (z. B. im SOP-Dokument) und einen Owner (Prozessverantwortlichen) haben. Wird ein Prozess geändert (z. B. neue Eskalationsstufe, andere Genehmiger), durchläuft die Änderung das Change-Management: Dokumentation neuer Version, Abnahme durch zuständige Manager und schließlich Rollout der angepassten Konfiguration. Praktisch bewährt haben sich regelmäßige Reviews: Bei festgelegten Terminen (oder nach betrieblichen Änderungen) werden die BPMN-Modelle gemeinsam mit den Stakeholdern überprüft und bei Bedarf aktualisiert. So bleiben Prozessmodelle und Abläufe konsistent mit der Realität. Versionsverwaltung im CAFM hält frühere Prozessstände (bzw. Konfigurationsstände) fest, um im Zweifelsfall zu einer validierten Version zurückkehren zu können. Diese kontinuierlichen Governance-Maßnahmen verhindern, dass Workflows „verfallen“ oder schlecht dokumentiert sind.

• Zu komplexe Workflows: Wenn ein Diagramm zu viele Verzweigungen oder Schleifen enthält, wird es unübersichtlich. Dies führt zu Fehlern bei der Umsetzung.

• Best Practice: Prozesse ggf. in Teilprozesse unterteilen und nur wesentliche Schritte modellieren

• Unklare Rollen und Verantwortlichkeiten: Fehlen eindeutige Zuweisungen (z. B. durch RACI/Swimlanes), ist oft niemand für bestimmte Schritte zuständig.

• Empfehlung: Zuständigkeiten früh festlegen und – wie gezeigt – in BPMN-Lanes oder RACI-Matrix dokumentieren

• Fehlende Eskalationsregeln: Ohne definierte Eskalationspfade bleiben Prozesse hängen, wenn z. B. ein Genehmiger ausfällt. Immer Eskalations- und Fallback-Regeln vorsehen (wer informiert wird, wenn etwas nicht termingerecht erledigt ist).

• Überdetaillierung: Zu viele Details im Modell können es unlesbar machen. Man sollte auf den geschäftsrelevanten Detaillierungsgrad achten – technische Feinheiten gehören nur ins System, nicht ins Grafikmodell

• Mangelnde Dokumentation & Schulung: BPMN ist für alle verständlich, aber Teams müssen geschult werden. Als Best Practice hat sich gezeigt, Prozessdiagramme gemeinsam mit Fachbereich und IT zu erarbeiten und Schulungen anzubieten.So steigt die Akzeptanz und die Abbildung stimmt mit der gelebten Praxis überein.

• Es empfiehlt es sich, iterativ vorzugehen: mit einfachen Standard-Workflows zu starten, diese gründlich zu testen und dann sukzessive anzupassen. Integrieren Sie konsequent Feedback der Anwender, dokumentieren Sie jeden Schritt und halten Sie Prozesse aktuell. So entsteht ein schlankes, flexibles Workflow-System mit klaren Abläufen – die ideale Basis für ein erfolgreiches CAFM.