Die Methodenontologie: Was es braucht, damit Methoden maschinell ausführbar werden

Zwischen einer Methode, der ein Mensch folgen kann, und einer Methode, die eine Maschine ausführen kann, liegt eine Lücke – und nahezu alles, was an Methodik veröffentlicht ist, liegt auf der falschen Seite davon.

Nehmen Sie ein beliebiges bekanntes Strategie-Framework. Es ist beschrieben in einem Buch, einem Diagramm und einer Reihe durchgearbeiteter Beispiele. Ein fähiger Berater liest es und kann es anwenden, weil er die enorme Menge an implizitem Wissen beisteuert, die die Beschreibung auslässt: wann es einschlägig ist, was als gültige Eingangsgröße zählt, was zu tun ist, wenn die Eingangsgröße unvollständig ist, wie sein Ergebnis an den nächsten Schritt anschließt.

Eine Maschine hat nichts davon. Geben Sie einem Sprachmodell dieselbe Beschreibung, und es bringt etwas hervor, das die Form des Frameworks hat, mit plausiblem Inhalt gefüllt und mit nichts verbunden.

Diese Lücke zu schließen ist ein Problem der Ontologie, und es ist der am wenigsten sichtbare und anspruchsvollste Teil dessen, was wir bauen.

Was eine Ontologie tatsächlich ist

Befreit von dem, was der Begriff im Philosophieseminar mitträgt, ist eine Ontologie eine formale Spezifikation der Entitäten einer Domäne und der Beziehungen zwischen ihnen.

Für die Methodik im Unternehmen heißt das, Fragen zu beantworten, die aufgeschriebene Methoden nie ausdrücklich beantworten:

• Welcher Art ist eine „Capability“? Wie verhält sie sich zu einem Prozess, einer Rolle, einem System, einem Wertstrom?
• Wenn zwei Methoden beide etwas hervorbringen, das „Kundensegment“ heißt – ist das dieselbe Entität, oder sind es zwei verschiedene?
• Wenn der Entwurf eines Betriebsmodells eine Capability verändert – welche nachgelagerten Artefakte sind davon betroffen?

Das klingt nach Wortklauberei. Es sind die Fragen, die darüber entscheiden, ob Methoden sich überhaupt zusammensetzen lassen. Ohne Antworten ist jede Methode eine Insel, und jede Übergabe zwischen zwei Methoden ist eine Übersetzung von Hand, geleistet von einem Menschen – und genau dieser Übersetzungsverlust macht Veränderungsarbeit teuer.

Eine Definition je Modell

Die Regel, an die wir uns halten, ist einfach zu formulieren und anspruchsvoll durchzuhalten: eine Definition je Modell.

Wenn zweihundert Methoden auf das „Geschäftsmodell“ verweisen, verweisen sie auf dieselbe Entität mit derselben Struktur und nicht auf zweihundert lokal stimmige Varianten. Wenn eine Jobs-to-be-done-Analyse ein Kundenbedürfnis hervorbringt, ist dieses Bedürfnis dieselbe Klasse von Objekt, die ein Geschäftsmodellmuster als Eingangsgröße entgegennimmt.

Deshalb kann sich der Korpus wie ein System verhalten und nicht wie eine Bibliothek. Das Ergebnis der einen Methode steht der nächsten tatsächlich als Eingangsgröße zur Verfügung, weil beide gegen dasselbe Modell des Unternehmens typisiert sind.

Diese Disziplin über mehr als 200 Modelle hinweg zu halten, ist keine einmalige Modellierungsübung. Es ist fortlaufende Arbeit: Jede neue Methode muss mit dem bestehenden Entitätsmodell abgeglichen werden, und gelegentlich muss sich das Entitätsmodell ändern – was heißt, alles noch einmal anzusehen, was davon abhängt.

Der Korpus pflegt sich nicht selbst.

Warum sich das nicht abgreifen lässt

Eine berechtigte Frage: Wenn die Methoden veröffentlicht sind – warum nicht ein Modell auf ihnen allen trainieren und sich die Ontologie sparen?

Weil die Ontologie nicht in den Veröffentlichungen steht. Sie ist die Schicht darunter – die Entscheidungen des Abgleichs, die Definitionen der Entitäten, die Semantik der Beziehungen. Ein veröffentlichtes Framework sagt Ihnen, was zu tun ist. Es sagt Ihnen nicht, dass sein Begriff von „Capability“ gröber ist als der, mit dem die Methode zum Betriebsmodell drei Kapitel später arbeitet, und auch nicht, wie beide in Einklang zu bringen sind, wenn sie auf dasselbe Unternehmen angewendet werden.

Dieser Abgleich ist eine Sache des Urteilsvermögens; er wird von Menschen geleistet, die beide Methoden gründlich verstehen, und er sammelt sich über Jahre an. Das ist der Teil, den fünfzehn Jahre Transformationsarbeit hervorgebracht haben und den ein Textkorpus nicht enthält.

Es gibt einen zweiten Grund. Methoden, die nie veröffentlicht wurden – die, die in Mandaten entstanden sind, an echten Vorhaben erprobt und überarbeitet, wenn sie scheiterten –, machen einen erheblichen Teil des Korpus aus. Es gibt sie, weil die Arbeit stattgefunden hat.

Von der Ontologie zur Ausführung

Die Ontologie ist es, die die ausführbare Schicht möglich macht. Sind Entitäten und Beziehungen erst festgelegt, lässt sich jede Methode als Spezifikation ausdrücken, die Folgendes trägt:

• Festgelegte Eingangsgrößen – welche Entitäten sie braucht, in welchem Zustand
• Festgelegte Operationen – was sie mit ihnen tut
• Festgelegte Ergebnisse – welche Entitäten sie hervorbringt oder verändert
• Anwendbarkeitsbedingungen – zu welchen Typen von Vorhaben sie gehört

An diesem Punkt ist eine Methode kein Dokument mehr. Sie ist eine Komponente. Und Komponenten lassen sich zusammensetzen: Geben Sie der Engine einen Vorhabenstyp, und sie kann bestimmen, welche Methoden gelten, in welcher Reihenfolge und mit welchen Abhängigkeiten untereinander – weil diese Information in den Spezifikationen steht und nicht im Kopf eines Beraters.

Das ist der Mechanismus hinter dem Schritt, den sonst niemand leistet: aus einem Briefing einen strukturierten Workflow zu machen, mit den angewandten Methoden ausgefüllt.

Das Wissensmodell des Unternehmens

Die andere Hälfte des Bildes ist das Modell des Unternehmens selbst.

Eine ausführbare Methode braucht etwas, worauf sie ausgeführt wird. Das ist das Wissensmodell des Unternehmens: eine lebende, geprüfte Karte davon, wie das Unternehmen tatsächlich arbeitet – seine Bausteine und wie sie zusammenhängen. Kein Architekturdiagramm, das Systeme beschreibt, und kein Organigramm, das Berichtswege beschreibt. Ein strukturelles Modell des Geschäfts.

Methoden lesen daraus und schreiben hinein. Eine Standortbestimmung der Capabilities liest die Capability-Entitäten und schreibt ihren bewerteten Zustand zurück. Der Entwurf eines Betriebsmodells schlägt Änderungen an genau denselben Entitäten vor. Weil beide auf einem Modell arbeiten, kann die zweite sehen, worauf die erste gekommen ist.

Das ist unspektakuläre Infrastruktur, und genau dort sitzt der Hebel. Die Alternative – jede Methode trägt ihr eigenes, privates Bild des Unternehmens mit sich – ist der Grund, warum herkömmliche Methodenarbeit grundsätzlich nicht skalierbar ist.

Warum sich der Aufwand lohnt

Arbeit an der Ontologie ist teuer, langsam und für Nutzer unsichtbar. Niemand hat je Software wegen eines Entitätsmodells gekauft.

Aber sie ist der Unterschied zwischen einem System, das Text erzeugt, der wie Strategie aussieht, und einem System, das ein echtes Vorhaben strukturiert. Alles, was am Produkt sichtbar ist – die Erzeugung des Workflows, die Provenienzkette, die Fähigkeit, die Herleitung von der Strategie bis in die Umsetzung zu tragen –, beruht darauf.

Ist das Modell falsch, sind die Ergebnisse im Einzelnen plausibel und im Ganzen widersprüchlich. Ist das Modell richtig, setzen sich Methoden zusammen – und die Wirkung beginnt sich aufzusummieren.