IDEF / IGOE

IDEF0 ist eine Notation der Funktionsmodellierung, die das NIST als US-Bundesstandard veröffentlicht hat. Sie zeichnet eine Funktion in eine Box und heftet ihr vier Pfeilklassen an vier Seiten: was sie verbraucht, tritt links ein, was sie einschränkt, kommt von oben herunter, was sie erzeugt, tritt rechts aus, was sie ausführt, steigt von unten auf. Damit beantwortet sie zwei Fragen, die eine Sequenznotation offen lässt, was diese Funktion regelt und was sie ausführt, und sie zerlegt die Funktion in Ebenen, deren Nummerierung nachvollziehbar bleibt. Die Variante IGOE von Roger Burlton übernimmt dieselbe Geometrie unter Namen, die auf Dienstleistungsprozesse zugeschnitten sind, und wird als einzige Box gezeichnet: das Scope-Diagramm.

Zweck

Die Technik dient einer Entscheidung über den Geltungsbereich: was in die Funktion fällt, was ausserhalb bleibt, und in welcher Eigenschaft. Ein Gesetz, eine Weisung, eine Software, ein Dienstleister werden darin zu Objekten der Zeichnung, jedes an der Stelle, die seine Rolle trägt.

Die Pfeile tragen Einschränkungen: «Pfeile stellen weder Fluss noch Sequenz dar», sagt FIPS 183, und die Funktion, die sie empfängt, ist durch das eingeschränkt, was ihr zur Verfügung gestellt wird. Das Modell erkauft Governance und Ressourcen mit dem Preis der Zeit, denn die Reihenfolge der Schritte liest man im Flussdiagramm oder in BPMN. Der Liefergegenstand reicht vom Kontextdiagramm A-0, einer einzigen Box, die den Zweck und den Blickwinkel des Modells trägt, über die Zerlegung A0 bis zum Knotenindex.

Mehr Details finden Sie in unserem BPMN-Tutorial.

Einsatz

Wann einzusetzen

Abgrenzung einer Funktion vor einer Neugestaltung: eine Box, vier Seiten, und das Team einigt sich, was eintritt und was austritt.
Die Frage betrifft das, was die Arbeit regelt: Gesetze, Verordnungen, interne Weisungen und Verträge werden zu gezeichneten Objekten.
Die Frage betrifft die Ressourcen: Personen, Systeme und Dienstleister erscheinen unter der Funktion.
Unternehmensweite Funktionssicht, die zu zerlegen ist: die Knotennummerierung hält die Nachvollziehbarkeit von Ebene zu Ebene.

Wann nicht einzusetzen

Gefragt sind die Abfolge der Schritte und die Übergaben: hier gibt es keine Zeitachse, das Flussdiagramm nehmen.
Zwei Organisationen tauschen Nachrichten aus, oder das Modell muss in einer Engine laufen: BPMN nehmen.
Die interne Logik eines Anwendungsfalls ist festzulegen, mit Wächterbedingungen und echter Nebenläufigkeit: das UML-Aktivitätsdiagramm nehmen.

Beschreibung

Die Box und ihre vier Seiten

Die Box ist ein rechtwinkliges Rechteck in durchgezogener Linie, benannt mit einem aktiven Verb: «Monatslohn erstellen» ist eine Funktion, «Lohnwesen» ist ein Gegenstand, und der Standard weist ihn zurück. Ihre Boxnummer steht innen, in der unteren rechten Ecke, von 1 bis 6 und 0 auf dem Kontextdiagramm. Pfeilbeschriftungen sind Nominalphrasen.

Die vier Klassen bestimmen sich danach, was die Funktion mit ihnen tut, und jede hängt an einer Seite. Der Input trifft von links ein und wird umgewandelt oder verbraucht. Die Steuerung kommt von oben herunter und legt die Bedingungen fest, unter denen die Ergebnisse korrekt sind. Der Output tritt rechts aus. Der Mechanismus steigt von unten auf und stützt die Ausführung. Alles hängt an einer Frage: wird der Pfeil verbraucht? Die erfassten Stunden werden von der Lohnberechnung verbraucht, also treten sie links ein; der AHV-Satz überlebt den Lohnlauf und entscheidet, ob das Ergebnis stimmt, also kommt er von oben herunter. Gleiche Form auf dem Blatt, entgegengesetzte Rolle. Dieselbe Frage ordnet auch die Mechanismen ein: das Treuhandbüro führt die Funktion aus, ohne von ihr verbraucht zu werden, und es links zu zeichnen ist ein Fehler.

ICOM und IGOE: zwei Namenssätze, eine Geometrie

Zwei Vokabulare sind im Umlauf. ICOM (Input, Control, Output, Mechanism) gehört FIPS 183, also IDEF0, und es ist das Vokabular des BPM CBOK. IGOE (Input, Guide, Output, Enabler) gehört Roger Burlton, der zwei Klassen für Dienstleistungsprozesse umbenannt hat: der Guide beschreibt, wann, warum oder wie eine Aktivität abläuft, der Enabler ist die Ressource, die nötig ist, um einen Input in einen Output zu verwandeln. Es ist das Vokabular des BABOK. Die Geometrie bleibt identisch, vier Seiten unter zwei geänderten Beschriftungen; der Gebrauch unterscheidet sich, denn IGOE wird als eine einzige Box gezeichnet, der Prozess im Geltungsbereich, am Anfang einer Neugestaltung, während IDEF0 über mehrere Ebenen zerlegt.

Die Regeln, die das Modell tragen

Die aufschlussreichste Regel des Standards ist die kürzeste: jede Box trägt mindestens eine Steuerung und mindestens einen Output, während Inputs und Mechanismen fakultativ bleiben. Eine Funktion, die nichts verbraucht, dennoch geregelt ist und etwas erzeugt, ist eine zulässige Box. Die Geometrie lässt sich prüfen: durchgezogene Linie, waagrechte oder senkrechte Führung, Knicke als 90-Grad-Bogen, Enden, die den Umriss berühren und an einer Seite ansetzen, nie an einer Ecke. Ausserhalb des Kontextdiagramms zählt ein Diagramm drei bis sechs Boxen: darunter musste die Elternbox gar nicht zerlegt werden; darüber ist die Ebene falsch gewählt, und die Zeichnung nimmt jenes überladene Aussehen an, das der BPM CBOK als Schwäche der IDEF-Umsetzungen festhält.

Die Hierarchie liest man an den Knotennummern ab, und sie tragen keinen Dezimalpunkt. Diese Adresse macht die funktionale Dekomposition nachvollziehbar, und die ICOM-Codes verriegeln sie: nahe dem freien Ende eines Randpfeils sagt C3, dass dieser Pfeil die dritte Steuerung von links ist, die in die Elternbox eintritt. Die Rolle eines Pfeils ist relativ zu der Funktion, die ihn empfängt, denn eine Steuerung der Elternbox kann beim Kind ein Input sein. Die so sichtbar gemachten Steuerungen sind die Geschäftsregeln der Organisation, und das Modell liefert das Inventar, das die Geschäftsregelanalyse aufnimmt.

A-0Lohnwesen führen (Kontextdiagramm, eine einzige Box)
A0Lohnwesen führen
- A1Monatslohn erstellen
  - A11Erfasste Stunden prüfen
  - A12Beiträge und Abzüge berechnen
  - A13Lohnabrechnungen ausstellen
- A2Löhne auszahlen
- A3Jahresabrechnungen erstellen

Der Knotenindex des Lohnmodells, in der eingerückten Liste, die der Standard selbst verwendet: die Knotennummer einer Box entsteht, indem ihre Boxnummer an diejenige des Diagramms angehängt wird, das sie trägt.

Das Modell führen

Zweck, Blickwinkel und Kontext festlegen, vor der ersten Box. Es gibt einen einzigen Blickwinkel pro Modell: zwei Blickwinkel erzeugen zwei unvereinbare Diagramme derselben Funktion.
Das Kontextdiagramm A-0 zeichnen, eine einzige Box, die den gesamten Geltungsbereich umfasst, mit den Pfeilen, die sie mit ihrer Umgebung verbinden. Das ist im Kern Burltons Scope-Diagramm und oft der gesamte Liefergegenstand eines Mandats.
In A0 zerlegen, in drei bis sechs wesentliche Teilfunktionen. Dieses Diagramm A0 ist die Spitze des Modells.
Jede Box ausarbeiten: alles auflisten, was um die Funktion kreist, nach den vier Seiten ordnen und prüfen, dass die Liste die Elternbox vollständig abdeckt.
Die Randpfeile codieren, was die Entsprechung zwischen dem Kinddiagramm und seiner Elternbox verriegelt.

Im Workshop entsteht das Scope-Diagramm in einer Sitzung mit dem Neugestaltungsteam: eine Box, und man geht die vier Seiten durch. Die Diskussion verhärtet sich immer bei den Guides, weil die Organisation dort entdeckt, dass sie sich über die Regeln, die sie binden, nicht einig ist.

Was die Notation ausdrückt

Wer die drei anderen Notationen der Prozessmodellierung gewohnt ist, sucht zuerst die Sequenz, und das Diagramm reicht ihm das Inventar dessen, was die Funktion einschränkt und was sie ausführt: Einschränkungen lassen das Wie und das Wann weg, so der Titel eines Anhangs des Standards. Der Weg der Daten durch ein System gehört dagegen zum Datenflussdiagramm.

Notation	Sequenz oder Geltungsbereich?	Nachrichten über eine Organisationsgrenze hinweg?	Typisierte Ereignisse?	Von einer Engine ausführbar?	Formale Semantik?	Swimlanes möglich?
Flussdiagramm	Sequenz	nein	nein	nein	nein	ja
BPMN	Sequenz	ja	ja	ja	ja	ja
UML-Aktivitätsdiagramm	Sequenz	nein	nein	nein	ja	ja
IDEF / IGOE	Geltungsbereich	nein	nein	nein	ja	nicht anwendbar: weder Swimlanes noch Zeit

Die vier Notationen der Prozessmodellierung und die Frage, die jede von ihnen beantwortet. Alle drei Sequenznotationen lassen Swimlanes zu, die eine notationale Ergänzung und keine eigenständige Notation sind: sie unterscheiden keine von ihnen. IDEF / IGOE kennt weder Swimlanes noch Zeit.

KI-Überlegungen

Zwei Anwendungen tragen. Die Einordnung: die Rohliste aus einem Workshop, alles, was um die Funktion kreist, ordnet sich in Inputs, Steuerungen, Outputs und Mechanismen, womit die Sitzung eine Fassung erhält, die sie bestreiten kann. Das Entwerfen der Steuerungskandidaten aus Weisungen, Verordnungen und Verträgen, denn das ist die Seite, die Teams am schlechtesten füllen.

Der Verbrauchstest lässt sich nicht delegieren: zu wissen, ob eine Sache von der Funktion umgewandelt wird oder ob sie sie regelt, verlangt Kenntnis davon, wie das Unternehmen tatsächlich arbeitet, und das Modell ruht auf dieser Unterscheidung. Ein Modell, das nach «den gesetzlichen Vorgaben der Schweizer Lohnbuchhaltung» gefragt wird, liefert plausible Artikelnummern und Sätze, veraltet oder falsch, und jede Steuerung gesetzlichen Ursprungs wird an ihrer Quelle geprüft. Zweck und Blickwinkel sind Entscheidungen der Anspruchsgruppen.

Beispiele

Die Funktion Monatslohn erstellen eines Schweizer KMU, Box A1 des Lohnmodells. Jeder Pfeil gehört zu genau einer Klasse, die der Verbrauchstest entscheidet.

ZWECK:die Lohnfunktion abgrenzen, vor der Neugestaltung des Lohnsystems.

BLICKWINKEL:derjenige der Personalleitung.

KNOTEN:A1

Input (linke Seite): wird von der Funktion verbraucht
Steuerung (obere Seite): schränkt ein, ohne verbraucht zu werden
Output (rechte Seite): wird von der Funktion erzeugt
Mechanismus (untere Seite): führt die Funktion aus

Die Funktion Monatslohn erstellen, Box A1 des Lohnmodells. Die Ziffer 1 in der unteren rechten Ecke ist die Boxnummer; A1 ist die Knotennummer, die Adresse der Box in der Hierarchie. Die ICOM-Codes werden für Steuerungen und Mechanismen von links nach rechts nummeriert, für Inputs und Outputs von oben nach unten.

Die obere Seite ist diejenige, die zu lesen ist. Sechs Steuerungen sind dort benannt, aus vier Ordnungen: Bundesrecht für das Obligationenrecht, die AHV/IV/EO-Sätze und das BVG, ein Branchen-GAV für den Gesamtarbeitsvertrag, ein kantonaler Tarif für die Quellensteuer, die individuelle Vereinbarung für den Arbeitsvertrag. Ein Flussdiagramm, ein BPMN-Modell oder ein UML-Aktivitätsdiagramm derselben Funktion würden alle eine Box «Lohn berechnen» zeichnen und diese sechs Quellen in einen Kommentar verweisen, obwohl genau sie das sind, was die Analyse zu ermitteln hat. Die untere Seite bewirkt dasselbe für die Ressourcen: die Funktion hängt von einem externen Dienstleister ab, dem Treuhandbüro, und diese Abhängigkeit liest sich als Tatsache des Modells.

Visualisierungen

Die Geometrie ist der Inhalt. Die Seite, über die ein Pfeil eintritt, ist seine Rolle, sodass ein von oben eintreffender Mechanismus etwas Falsches aussagen und ein an einer Ecke angehängter Pfeil gar nichts aussagen würde. Die vier Seiten werden deshalb visuell unterschieden, denn die vier Rollen sind der ganze Gegenstand der Abbildung. Zweck und Blickwinkel stehen unter dem Diagramm, so wie es der Standard selbst hält, wo sie als seine Gebrauchsanweisung dienen. Der Knotenindex wird als Text gegeben und trägt die Hierarchie, die die Diagramme jeweils nur eine Ebene auf einmal zeigen.

Aufwand

Phase	Stufe	Begründung
Vorbereitung	Mittel	Zweck, Blickwinkel und Kontext werden vor der ersten Box festgelegt. Die eigentliche Vorarbeit besteht darin, die Quellen zusammenzutragen, die zu Steuerungen werden, Gesetze, Verordnungen, Weisungen, Verträge, und die Personen zu versammeln, die sie kennen.
Durchführung	Mittel	Ein Scope-Diagramm mit einer Box passt in eine moderierte Sitzung, was günstig ist. Eine vollständige Zerlegung über mehrere Ebenen ist eine Reihe von Sitzungen, und jede Ebene bringt die Prüfung der Entsprechung mit ihrer Elternbox mit sich.
Dokumentation	Hoch	Das Modell besteht aus Diagrammen, Texten und einem Glossar, und sein Wert hängt daran, dass Knotenindex, ICOM-Codes und Eltern-Kind-Entsprechungen konsistent bleiben, während es sich ändert. Diesen Unterhaltsaufwand lässt sich das Modell bezahlen.

Werkzeuge

Für das Scope-Diagramm genügt das Whiteboard, und diese Sparsamkeit ist eine Eigenschaft der Technik: eine Box und vier Seiten passen auf ein Flipchartblatt, weshalb die Variante IGOE im Workshop auch mit Leuten funktioniert, die nie Modelle zeichnen. Allgemeine Zeichenwerkzeuge, Visio, diagrams.net oder Lucidchart, führen IDEF0-Schablonen und erzeugen korrekte Diagramme; ihr Beitrag endet bei der Zeichnung, und die Entsprechung zwischen dem Randpfeil eines Kinddiagramms und der Kante seiner Elternbox besteht dann nur noch im Kopf der Autorin.

Unternehmensweite Modellierungsumgebungen, ARIS oder Sparx Enterprise Architect, halten die Hierarchie, den Knotenindex und die ICOM-Codes als Objekte eines Repositoriums und verkraften das Umbenennen oder Verschieben einer Funktion ohne Nacharbeit. Die Investition rechtfertigt sich, sobald das Modell zwei Ebenen überschreitet oder länger leben muss als das Mandat. Da die Regeln des Standards maschinell prüfbar sind, ist eine Fähigkeit vom Werkzeug zu verlangen: eine Box ohne Steuerung oder ohne Output zurückzuweisen, und einen Randpfeil ohne Code zu melden.

Quellen

NIST, FIPS PUB 183, Integration Definition for Function Modeling (IDEF0), 1993: der primäre Standard, der die Syntax von Box und Pfeilen, die vier ICOM-Klassen und die Regeln des Modells trägt.
IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: die IDEF-Notation und die IGOE-Diagramme unter den Notationen der Prozessmodellierung und der Einsatz der Technik zur Festlegung des Geltungsbereichs.
ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.6 IDEF: das ICOM-Vokabular, die Verknüpfung der Prozesse über die Detaillierungsebenen hinweg und die anerkannte Schwäche der Umsetzungen.
ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: Swimlanes sind eine notationale Ergänzung und keine eigenständige Notation.
Kathy A. Long, What is an IGOE?, Business Rules Journal, Januar 2012: die Definitionen von Input, Guide, Output und Enabler, zugeschnitten auf Prozesse des Dienstleistungssektors.
Paul Harmon, Deming, IT, and BPM IDEF0 Diagrams, BPTrends: die Zuschreibung von IGOE an Roger Burlton und sein Gebrauch als Scope-Diagramm.