Zum Hauptinhalt springen

Pruefen

  1. id: validieren title: Validieren sidebar_position: 30 tags:
    • oBPM

Validieren - Prüfen in Bezug auf Modellierungsrichtlinien

Qualitätskriterien zur Überprüfung der Einhaltung von Modellierungsrichtlinien und Good Practices

Modellierungsrichtlinien (Modellierungskonventionen , Modeling Guidelines oder Conventions) sind ein verbindliches Regelwerk in einem Unternehmen, das festlegt, wie Geschäftsprozesse dokumentiert, gezeichnet und beschrieben werden müssen. Sie dienen als „Grammatik“ und „Stilhandbuch“ für das Prozessmanagement. Ohne solche Konventionen baut jeder Prozessmodellierer (BPM-Spezialist, Business Engineer oder Qualitätsmanager) seine Diagramme nach eigenem Geschmack, was dazu führt, dass die Prozesse firmenweit nicht mehr vergleichbar, schwer lesbar und unbrauchbar für die IT-Automatisierung sind.

Im Modellierungstool Adonis steht ein Standard Freigabe-Workflows zur Verfügung. Dieser Prozess orientiert sich an der ISO9001 - Dokumentenlenkung.

Modell-Freigabeworkflow (Standardkonfiguration)

Abbildung (Bildquelle = BOC - Adonis Handbuch)

Methodische Prüfung​

1. Qualitätsstufe

Die methodische, formale Prüfung die erste formale Qualitätsstufe innerhalb eines Freigabeworkflows. Bei der methodischen Prüfung kontrolliert ein zugewiesener Prüfer (Methodenverantwortlicher, Auditor, Reviewer) die Objekte und Modelle anhand der Modellierungsrichtlinien und -konventionen. Es geht hier ausdrücklich nicht darum, ob der Prozess in der Praxis logisch oder wirtschaftlich sinnvoll ist, sondern ob er handwerklich sauber gebaut wurde.

Geprüft werden standardmäßig folgende Aspekte / Q-Kriterien:

1. Sicherstellung der Vollständigkeit der Objekt-Attribute (Metadaten)​

Unter der Vollständigkeit der Objekt-Attribute (Metadaten) versteht man im Prozessmanagement die lückenlose und standardisierte Erfassung von Hintergrundinformationen zu den einzelnen Elementen eines Prozessmodells. Ein Prozessdiagramm besteht visuell meist nur aus Symbolen (wie Aufgaben, Ereignissen und Gateways). Die eigentliche „Intelligenz“ und der Wert für Analysen, Audits oder IT-Automatisierungen liegen jedoch in den unsichtbaren Datensätzen hinter diesen Symbolen – den sogenannten Attributen oder Metadaten. Wenn die Objekt-Attribute nicht vollständig gepflegt sind, bleiben die Informationsmodelle reine „Zeichnungen“ mit geringen operativen Nutzen.

  • Sprechender Objektname: Jedes Objekt muss ohne Erklärungsnot für Modellnutzer eindeutig benannt sein.
  • Kurzbeschreibung des Objektes: Der Objektname allein reicht oft nicht aus. Die Kurzbeschreibung liefert den Kontext.
  • Zuweisung eines Objekt-Owners (Zuständigkeit): Ist dem Objekt ein Owner / Care Taker zugewiesen? Dies ist ein Schritt zur operationalen Verankerung des "Accountability". Ein Objekt benötigt eine klare Governance: Der Owner ist dafür verantwortlich, dass dieses Objekt aktuell, korrekt und funktionstüchtig bleibt. Ändert sich ein System oder eine regulatorische Vorgabe, weiß das System sofort, wer benachrichtigt werden muss, um das betroffenen Objekt anzupassen.

Wenn diese Metadaten sauber gepflegt sind, ermöglicht das dem Unternehmen mächtige Auswertungen per Mausklick. Erst wenn diese Q-Kriterien mit „Ja“ beantwortet werden können, sollte der "Methoden-Reviewer" (Process-Analyst) zur syntaktischen Prüfung übergeben werden

2. Einhaltung der Notation (BPMN, syntaktische Regeln)​

Als Modellierungssprache wird BPMN verwendet. Die Objektsymbole sind im Modellierungstool definiert. Unter der Einhaltung der Notation versteht der Prozessanalyst die formale, grammatikalische Qualitätsprüfung eines Prozessdiagramms. Hierbei wird die Einhaltung die BPMN-Regeln kontrolliert.

  • Standardisierte Modellierungssprache (BPMN): Es dürfen ausschließlich die im Modellierungstool (z. B. ADONIS) freigegebenen Standard-Objektsymbole verwendet werden. Eigenmächtige Modifikationen, Zweckentfremdungen von Symbolen oder das Erfinden eigener Formen sind unzulässig. Dies sichert den globalen Standard, sodass auch externe Auditoren oder neue Mitarbeiter das Diagramm sofort lesen können.
  • Das Start-Ereignis & sein Trigger: Beginnt der Prozess mit genau einem Start-Ereignis? Ist der Trigger ausreichend beschrieben? Ein Standard-Geschäftsprozess sollte im Regelfall einen eindeutigen, definierten Anfangspunkt haben. Mehrere Start-Ereignisse sind in BPMN zwar syntaktisch erlaubt (z. B. bei unterschiedlichen Auslösern), stiften in operativen Modellen aber oft Verwirrung. Ausreichend beschriebener Trigger. Ein leeres Start-Ereignis ist ein methodischer Fehler. Es muss definiert sein, was den Prozess anstößt (z. B. ein zeitlicher Trigger wie „Jeden Montag um 08:00 Uhr“ oder ein Ereignis-Trigger wie „B2B-Ausschreibung eingegangen“).
  • Logische End-Ereignisse & Acceptance: Der Prozess darf nicht irgendwo im Nirgendwo aufhören. Jedes mögliche Prozessszenario (z. B. der Gut-Fall und der Schlecht-Fall) muss in einem logischen End-Ereignis münden. Abschluss / Acceptance beschrieben. Das End-Ereignis muss den finalen Zustand beschreiben (z. B. „Kunden-Projekt-Beschaffungsplan genehmigt“ oder „Ausschreibung abgelehnt“). Damit ist für nachgelagerte Prozesse (Schnittstellen) klar, welcher Status erreicht wurde.
  • Beschreibung der Prozesstätigkeiten (Tasks): Sind die Prozesstätigkeiten beschrieben? Jede Aktivität (Task) muss eine reale, nachvollziehbare Handlung darstellen. Reine „Warte-Schritte“ oder Kontrollschleifen ohne Aktion sind meist falsch modelliert. Die Tätigkeiten müssen durch die Verknüpfung mit Kurzbeschreibungen inhaltlich gestützt werden.
  • Korrekt geschlossene Gateways (Verzweigungen): Sind alle Gateways syntaktisch korrekt geschlossen? Die Symmetrie-Regel: Wenn ein Prozessfluss über ein Gateway aufgespalten wird (z. B. eine Entscheidung / exklusives OR oder eine Parallelisierung / AND), muss diese Verzweigung im weiteren Verlauf auch wieder sauber zusammengeführt werden.
  • Vermeidung von „Sackgassen“ (Dead Ends / Unconnected Objects): Gibt es „Sackgassen“ (Aktivitäten ohne ausgehenden Sequenzfluss)? Der logische Fluss: Jede Aktivität und jedes Gateway muss mindestens einen eingehenden und einen ausgehenden Sequenzfluss (Pfeil) besitzen. Wenn eine Aktivität keinen ausgehenden Pfeil hat, handelt es sich um eine Sackgasse. Der Prozess läuft dort in eine technologische und logische Blockade. Das Tool kann den Prozess nicht zu Ende rechnen, und der Mitarbeiter weiß nicht, wie es weitergeht.

Erst wenn alle diese syntaktischen Bedingungen mit „Ja“ beantwortet werden können, ist das Modell formal stabil und darf an den Fachverantwortlichen (Process Owner) zur inhaltlichen Prüfung übergeben werden.

3. Einhaltung der Benennungskonventionen (Nomenklatur, semantische Regeln)​

Unter der Einhaltung der Namenskonventionen (Nomenklatur, semantische Regeln) versteht man im Prozessmanagement die Standardisierung der Sprache innerhalb von Prozessmodellen. Während die Syntax (Notation) die Grammatik der Symbole regelt, bestimmen die semantischen Regeln, wie diese Symbole beschriftet werden müssen. Das Ziel ist eine präzise, unmissverständliche und firmenweit einheitliche Sprache. Wenn verschiedene Modellierer unterschiedliche Begrifflichkeiten oder Satzstrukturen verwenden, führt das zu Missverständnissen zwischen Fachabteilungen und der IT-Entwicklung.

  • Prozesstätigkeiten (Tasks / Aktivitäten): Die Substantiv-Verb-Regel. Aktivitäten beschreiben eine aktive Handlung, die einen Zustand verändert. Um dies sprachlich exakt abzubilden, gilt die strikte Vorgabe: [Substantiv im Akkusativ] + [Verb im Infinitiv]**. Damit die Beschriftungen klar und eindeutig sind, wird eine feste Sprachlogik vorgegeben (oft als Substantiv-Verb-Regel). Es zwingt den Modellierer, präzise zu benennen, was (Objekt/Substantiv) getan wird und wie (Aktion/Verb) es getan wird. Es eliminiert unnötige Füllwörter und hält das Diagramm schlank.

    • Richtig: „Systemdesign überprüfen“ (Substantiv + Infinitiv des Verbs).

    • Falsch: „Überprüfung“ (reines Nomen) oder „Wir prüfen das System“ (Ganzsatz).

  • Ereignisse (Events): Die Zustand-Partizip-Regel. Ereignisse beschreiben keine Handlungen, sondern einen erreichten Zustand oder einen Auslöser zu einem bestimmten Zeitpunkt. Daher lautet die Regel hier: [Substantiv/Objekt] + [Verb im Partizip Perfekt]. Es wird sofort klar, dass an dieser Stelle der Prozess so lange stoppt, bis dieser exakte Zustand eingetreten ist (Start-/Zwischenereignis) bzw. dass dies das messbare Endergebnis des Pfades ist (Endereignis).

    • Richtig: Ereignisse werden im Partizip Perfekt benannt: „Design validiert“, „Bestellung eingegangen“.

  • Exklusive Gateways (Entscheidungen): Die Frage-Logik. Obwohl in Ihrem Text nicht explizit aufgeführt, gehört dies fest zur semantischen Nomenklatur: Gateways steuern den Fluss basierend auf Bedingungen. Sie werden als klare Frage formuliert. Die ausgehenden Pfeile beschriften die logischen Antworten (meist „Ja“ / „Nein“ oder spezifische Zustände).

4. Sicherstellung der Lesbarkeit (Layout- und Design-Regeln)​

Unter der Sicherstellung der Lesbarkeit (Layout- und Design-Regeln) versteht man im Prozessmanagement die visuelle Ästhetik und standardisierte Anordnung von Prozesselementen. Während Syntax (Notation) und Semantik (Sprache) die logische Korrektheit garantieren, sorgen die Layout-Regeln dafür, dass das menschliche Gehirn das Diagramm schnell erfassen, fehlerfrei interpretieren und intuitiv verstehen kann. Ohne diese Regeln entstehen sogenannte „Spaghetti-Diagramme“: Ein wildes Labyrinth aus kreuzenden Linien, unstrukturierten Objekten und willkürlichen Farben, das selbst bei korrekter BPMN-Syntax unbrauchbar wird, weil niemand es gerne liest.

Das Auge liest mit. Diese Regeln verhindern „Spaghetti-Diagramme“.

  • Strikt vorgegebene Flussrichtung (Leserichtung): Das menschliche Auge im westlichen Kulturkreis ist darauf trainiert, von links nach rechts und von oben nach unten zu lesen. Prozessmodelle müssen genau dieser Dynamik folgen. Datenflüsse kreuzen den Prozessfluss idealerweise nicht.
  • Saubere Datenflüsse: Verknüpfungen zu Dokumenten, Datenobjekten oder IT-Systemen werden über gestrichelte Assoziationslinien abgebildet. Diese sollten den logischen Hauptprozessfluss (die dicken Pfeile) idealerweise niemals kreuzen, sondern oberhalb oder unterhalb der Aktivitäten angeordnet sein.
  • Standardisierte Farbcodierung (Corporate Design): Festlegung, welche Farben für welche Objekte genutzt werden (z. B. Grün für Start, Rot für Ende, Blau für IT-Systeme). Weniger ist mehr: Zu bunte Diagramme wirken unprofessionell und lenken ab. Der Hintergrund der Standard-Tasks sollte neutral (z. B. weiß oder ein sehr helles Pastellblau) bleiben.
  • Verwendung von Lanes/Schwimmbahnen & RACI-Abbildung: Lanes sind das wichtigste Werkzeug, um die organisatorische Verantwortung im Prozess sichtbar zu machen. Die Richtlinien müssen hier unmissverständlich definieren, wie Zuständigkeiten abgebildet werden. Werden Rollen (z. B. Solution Architect) oder Abteilungen als Lanes dargestellt? Wie wird eine RACI-Zuordnung im Modell abgebildet?
    • Lanes als Rollen (Best Practice): Eine Schwimmbahn repräsentiert in modernen Systemen fast immer eine Rolle (z. B. Solution Architect, Technical Design Authority, Procurement Lead) und keine konkrete Person oder starre Abteilung. Abteilungen ändern sich bei Reorganisationen – die benötigte Rolle im Prozess bleibt meist gleich.

Führungskräfte oder operative Mitarbeiter müssen den Ablauf innerhalb von wenigen Sekunden visuell „scannen“ können, um zu wissen, wer was wann tut. Mitarbeiter nutzen Prozessportale nur dann gerne, wenn die Diagramme aufgeräumt, modern und einheitlich aussehen. Schöne Diagramme steigern die gelebte Prozesskultur. Wenn Prozesse für Schulungsunterlagen, SOPs oder Audits in PDFs exportiert werden, garantiert ein festes Layout-Raster, dass die Grafiken nicht abgeschnitten werden oder unleserlich klein skaliert werden müssen.

Fachliche Prüfung​

2. Qualitätsstufe

Die fachliche, inhaltliche Prüfung ist die zweite Qualitätsstufe innerhalb des Freigabeworkflows, bevor ein Prozessmodell offiziell veröffentlicht (publiziert) wird und für das gesamte Unternehmen sichtbar ist. Während die vorangegangene methodische Prüfung rein formal kontrolliert, ob das Modell handwerklich sauber gebaut wurde (Syntax, BPMN-Regeln), geht es bei der fachlichen Prüfung um den Inhalt und die Realität.

Diese Prüfung wird vom Prozessverantwortlichen (Process Owner) oder einem designierten Fachexperten (Subject Matter Expert / SME) durchgeführt. Diese Person besitzt die fachliche Hoheit über den Ablauf und haftet operativ dafür, dass der dokumentierte Prozess effizient, korrekt und gesetzeskonform ist.

Geprüft werden standardmäßig folgende Aspekte (als Gedankenstütze wird die 3C-Methode herangezogen):

1. Vollständigkeit und Realitätscheck​

Completeness

Ein fehlerfreies BPMN-Diagramm nützt dem Unternehmen nichts, wenn es einen Prozess beschreibt, der in der Realität zu Lieferverzögerungen, Budgetüberschreitungen oder Qualitätsmängeln führt.

  • Verständlichkeit der Prozessziele und der Erfolgsmessung. Ziele und PIs (Performance Indicators) legen fest, warum der Prozess existiert und wie effizient er läuft. Ein Prozess ohne messbare Ziele ist wie ein Schiff ohne Kompass – man bewegt sich zwar, weiß aber nicht, ob man ankommt.

    • Die Goal-Alignment Prüfung: Der fachliche Prüfer (Process Owner) muss validieren, ob der dokumentierte Prozess überhaupt auf die übergeordneten Unternehmens- oder Projektziele einzahlt. Fokus auf das „Warum“: Welchen Zweck erfüllt der Prozess?
    • Die Erfolgs-Prüfung: PIs machen die Zielerreichung messbar. Sie sind die Kontrollinstrumente für den Process Owner. Beim Realitätscheck wird geprüft, ob die im Prozess definierten Messpunkte (Daten) überhaupt realistisch erfasst werden können. Häufig werden Process-PIs im Prozessmanagement nach dem Prozesspentagon Menge/Quantität, Zeit, Qualität, Kosten, Kundenzufriedenheit/Flexibilität) bewertet.

  • Vollständigkeit und funktionale Korrektheit des Soll-Ablaufs. Es wird geprüft, ob das Modell den definierten Zielzustand (Soll-Ablauf) lückenlos abbildet. Bildet das Diagramm den tatsächlichen Soll-Ablauf vollständig und korrekt ab? Wurden wichtige Prozessschritte vergessen oder sind Abläufe falsch dargestellt?

  • Das mathematisch-logische Prinzip: O = f(I) - (Output ist eine Funktion des Inputs:. Wurden die Prozessinputs und -Outputs vollständig erfasst und spezifiziert? Dieses Prinzip ist das Fundament des prozessorientierten Denkens. Jede Aktivität und jeder Gesamtprozess wandelt einen definierten Eingangszustand (Input) in ein messbares Ergebnis (Output) um.

    • Die Input-Prüfung: Sind alle notwendigen Dokumente, Datenströme und Informationen vorhanden, um die Aktivität überhaupt starten zu können? (Z. B. Kann der Purchase Plan ohne die validierte Customer Business Requirements Specification erstellt werden? Nein – also ist die BRS ein zwingender Input).
    • Die Output-Prüfung: Erzeugt die Aktivität einen echten Mehrwert? Ist der Output eindeutig definiert und qualitätsgesichert? Nur wenn der Input sauber verarbeitet wird, kann nachgelagert ein stabiler Output entstehen.

  • Praxis-Validierung anhand von konkreten Anwendungsfällen (User Stories, Use Cases): Der Prüfer simuliert den Prozess im Kopf (oder anhand von Testfällen) mit realen Szenarien aus dem Berufsalltag

    • Die Use-Case-Prüfung: Sind repräsentative Anwendungsfälle identifiziert? Kann die Beschreibung der User Stories / Testfälle zur Validierung des Ablaufes herangezogen werden.

Der Realitätscheck schützt das Unternehmen vor „Papiertigern“ – also Prozessen, die nur für das ISO-Audit existieren, aber von den Mitarbeitern ignoriert werden. Er stellt sicher, dass die Dokumentation eine echte, verlässliche Arbeitsanleitung für die Belegschaft ist.

2. Inhaltliche Korrektheit der Informationsobjekte und deren Verknüpfungen​

Correctness

Unter der Korrektheit der Datenobjekte (Semantische Integrität) versteht man im Prozessmanagement die logische und fehlerfreie Verknüpfung des Prozessflusses mit der realen Struktur der Organisation, der IT-Systeme und der Dokumentenlandschaft.

Während die visuelle BPMN-Grafik festlegt, wann etwas getan wird, bestimmt die Korrektheit der Datenobjekte, womit, worauf und durch wen es geschieht. Es geht hierbei um die Vermeidung von logischen Brüchen an den Schnittstellen zwischen Abteilungen und Systemen.

  • Inhaltliche Aktualität und Gültigkeit: Der Prüfer kontrolliert, ob das verknüpfte Informationsobjekt auf dem neuesten Stand ist.
  • Semantische Korrektheit des Dateninhalts (Die logische Wahrheit): Entspricht der Reifegrad der Information den Erwartungen? Es wird geprüft, ob die Information, die aus einem Schritt herauskommt (Output), logisch überhaupt die Bedingungen erfüllt, die der nächste Schritt als Input benötigt.
  • Korrektheit der System- und Medienquellen. Der Realitätscheck prüft, ob die Quelle stimmt.
  • Zugriffs- und Sicherheitskonformität (Data Governance): Informationsobjekte enthalten oft sensible Daten. Die fachliche Prüfung validiert die Governance.

Die inhaltliche Korrektheit der Informationsobjekte stellt sicher, dass das Prozessmodell nicht nur eine schöne Grafik ist, sondern als verlässliche Wissensbasis dient. Wenn ein Mitarbeiter im operativen Geschäft den Prozess aufruft und auf das Informationsobjekt klickt, muss er darauf vertrauen können, dass der dort beschriebene Datenfluss exakt so in der Realität gelebt wird.

3. Konsistenz mit Vorgaben und Compliance​

Consistency

Unter der Konsistenz mit Vorgaben und Compliance versteht man im Prozessmanagement die lückenlose Absicherung, dass ein dokumentierter Geschäftsprozess weder gegen interne Regeln noch gegen externe Gesetze oder regulatorische Rahmenbedingungen verstößt. In der fachlichen Prüfung (2. Qualitätsstufe) fungiert dieses Kriterium als rechtliches und strategisches Schutzschild des Unternehmens. Ein Prozess kann syntaktisch perfekt gezeichnet und operativ hochgradig effizient sein – wenn er jedoch gegen Gesetze wie NIS2, das Barrierefreiheitsgesetz (BaFG) oder interne Sicherheitsvorgaben verstößt, darf er unter keinen Umständen freigegeben und publiziert werden.

  • Integration des Internen Kontrollsystems (IKS): Das IKS sichert das Unternehmen gegen Fehler, Betrug und operative Risiken ab. Der fachliche Prüfer kontrolliert, ob an den kritischen Stellen im Prozess die erforderlichen Kontrollpunkte physisch eingebaut sind.
    • Das Vier-Augen-Prinzip: Ist bei risikoreichen Schritten (z. B. der Freigabe eines Customer Project Purchase Plans mit hohem 3rd-Party-Budget) sichergestellt, dass eine zweite Instanz (z. B. die Technical Design Authority) zustimmen muss?
    • Dokumentation der Kontrolle: Wird im ADONIS an dem jeweiligen Kontrollschritt hinterlegt, wie die Prüfung stattfindet und wo der Nachweis (Audit Trail) revisionssicher gespeichert wird?
  • Einhaltung von Sicherheitsrichtlinien & gesetzlichen Regelungen. Hier erfolgt der Abgleich mit dem aktuellen regulatorischen Umfeld (Stand 2026). Prozesse dürfen keine rechtlichen Grauzonen oder Sicherheitslücken erzeugen.
    • Regionale Gesetzgebung: Werden im Prozess berührte Vorgaben (wie das österreichische Barrierefreiheitsgesetz - BaFG bei kundenorientierten Systemen) berücksichtigt, um Strafzahlungen oder Compliance-Verstöße im B2B-Geschäft proaktiv zu verhindern?
    • Normen und interne Vorgaben bilden das formale Regelwerk, das bestimmt, innerhalb welcher Leitplanken sich ein Geschäftsprozess bewegen darf. Der Prüfer muss sicherstellen, dass eine hohe Transparenz über die Vorgaben besteht und dass das Prozessdesign nicht nur gesetzeskonform ist, sondern auch exakt den zertifizierten Industriestandards (Normen) des Unternehmens sowie den internen Management-Richtlinien entspricht. Ein Abweichen von diesen Vorgaben kann zum Verlust von Zertifikaten oder zu Qualitätsverlusten führen. Damit Normen und interne Vorgaben nicht in dicken PDF-Handbüchern verstauben, werden sie in ADONIS als Vorgabe-Objekte angelegt und direkt mit den Prozessen vernetzt. Kommt ein externer Auditor ins Haus, muss man nicht mühsam Dokumente suchen. Man zieht in ADONIS einen Report über die Norm und das Tool listet auf Knopfdruck alle Geschäftsprozesse und Einzeltasks auf, die diese Norm operativ erfüllen.
  • Risikoidentifikation und Verknüpfung mit Kontrollen (Risk-Control-Matrix). Ein professionelles Prozessmodell deckt Schwachstellen auf, bevor sie in der Praxis Schaden anrichten. Der Prüfer validiert die Risiko-Governance im Modell.
    • Risiko-Zuordnung: Sind an den verletzlichen Tasks spezifische Risiko-Objekte hinterlegt?
    • Kontroll-Hinterlegung (Mitigation): Ist diesem Risiko eine wirksame Kontrolle zugewiesen?

Weiterführende Ressourcen​

Die methodische Prüfung sorgt dafür, dass die Objekte und Modell sauber gebaut wurden. Die fachliche Prüfung sorgt dafür, dass die Mitarbeiter im Unternehmen nach einer korrekten und sicheren Anleitung arbeiten.