Model-Based Business Engineering, Blog by Dr. Juergen Pitschke, +49 351 30935193 Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!g

Klassifizieren, Klassifizieren, Klassifizieren, ...

Im letzten Blog-Beitrag habe ich die Bedeutung des Strukturieren für das Sammeln von Informationen, das Formalisieren (Modellieren) und das Auswerten und Analysieren betont. Das trifft auf alle Artefakte und Abstraktionen zu. Wie können wir einen Geschäftsprozess strukturieren? Wie können wir die einzelnen Aktivitäten klassifizieren? Wie können wir operative Entscheidungen klassifizieren? Wie können wir Risiken klassifizieren?

Die Frage "Wie läuft der Geschäftsprozess bei Ihnen ab?" oder die Frage "Wie ist die operative Entscheidung strukturiert?" ist als erste Frage oft nicht zielführend. Wir geben den Anwender Hilfe, indem wir nach bestimmten Klassen von Aktivitäten (oder operativen Entscheidungen) fragen. Es sei erinnert, dass wir iterativ vorgehen. Ein kritisches Review ist notwendig, damit wir keine Aktivität oder Entscheidung "vergessen".

Entsprechend bin ich immer auf der Suche nach Anregungen für die Klassifikation von Artefakten.

In der Geschäftsprozessmodellierung ist eine für mich hilfreiche Klassifikation in "Business Analysis" von Debra Paul und Donald Yates (Ed.) zu finden. Dort werden Aktivitäten folgendermaßen klassifiziert:

Weiterlesen

Strukturieren, Strukturieren, Strukturieren, ...

Im Blog-Beitrag "Styleguide und Architekturprinzipien" habe ich die Wichtigkeit einer guten Strukturierung für das Sammeln von Informationen, das Formalisieren in Modellen und das Auswerten und Analysieren der Modelle betont. Ich nutze für die Beantwortung der Frage der Strukturierung das "Zachman™-Framework for Enterprise-Architecture" (siehe zachman.com).  Andere Frameworks folgen ähnlichen Prinzipien (zum Beispiel das Archimate-Framework). Oft sind die Frameworks aufeinander abbildbar.

Leider definieren die Frameworks nur die Abstraktionen, die für uns von Interesse sind. In der Praxis stellt sich auch die Frage der Abstraktionsstufen. Prozesse werden global beschrieben, aber auch detailliert aus Sicht des Bearbeiters (siehe "siehe Komplex vs. Kompliziert").

Wir Strukturieren Geschäftsprozesse auch intern aus inhaltlichen Gründen. Man denke an das Element "Milestone" in CMMN. Wir Strukturieren den Prozess (den Case)  dabei nach der Frage der Informationen über den Case (nach dem Stand des Case Files). Um gute und einfach pflegbare Modelle zu erhalten, ist "Strukturieren" wichtiger als die exzellente Beherrschung einer einzelnen Notation (BPMN, CMMN, DMN, andere). 

 

Styleguide und Architekturpinzipien

Vor einiger Zeit waren Styleguides populär. Im Internet findet man immer noch einige der Angebote. Anwender fragen auch heute danach.

Wir bieten drei Dokumente als Hilfe-Stellung an

  • Den Styleguide
  • Die Modellierungsrichtinien
  • Governance-Regeln

Alle drei Dokumente geben Hilfe bei der Modellierung und sichern Einheitlichkeit bei der Modellierung. Erste Vorraussetzung ist ein Rollenverständnis der beteiligten Projektmitarbeiter. Nicht jede Regel adressiert jedes Projektmitglied.

  • Der Styleguide regelt, wie wir Notationen und Beschreibungsmittel einsetzen. Wir schränken Standardnotationen ein. Er gibt Beispiele und definiert Modellierungsmuster. Er regelt aber auch einfache Sachverhalte, wie die farbliche Gestaltung.
  • Die Modellierungsrichtlinien geben Hilfe, welches Vorgehen wir wählen, erklärt Arbeitstechniken und Soft-Skills wir anwenden und einsetzen.
  • Die Governance-Regeln sichern Konformität und Aktualität der Modelle. Hier spielen viele Spielregeln und „Zeremonien“ eine Rolle.

Eine Grundlage sind Architekturprinzipien. Architekturprinzipien setzen den Rahmen für die drei genannten Dokumente. TOGAF® gibt Beispiele für solche Prinzipien und betont, dass ein übliches Projekt nicht mehr als 20 Architekturprinzipien haben sollte. Hier sind Beispiele meiner Architekturprinzipien als Grundlage von Styleguide, Modellierungsrichtlinie, Governance-Regeln.

Weiterlesen