Ich habe die Ontologie eines Produkts geschrieben. Dreimal dachte ich, ich sei fertig.

Eine Frage landet in Slack: Kann das Produkt das, für diesen Kunden, in genau diesem Fall?

Keine abstrakte Frage. Keine Überlegung zur Fünfjahresvision. Eine Frage aus der Praxis, die innerhalb einer Stunde beantwortet werden muss. Also öffnet jemand eine Testumgebung, baut den Fall nach, prüft. Eine halbe Stunde. Zweimal bezahlt: von der Person, die sucht, und von der, die sie unterbricht.

Das ist kein Dokumentationsproblem. Dokumentation gibt es, und sie ist aktuell. Das Problem ist, dass das, woraus das Produkt besteht — die Objekte, die es verarbeitet, die Regeln, die sie beherrschen, die Wörter, mit denen wir darüber reden —, nirgends in einer abfragbaren Form steht. Es existiert an zwei Orten: im Code, den einige Leute lesen können, und in den Köpfen genau dieser Leute.

Also habe ich versucht, es aufzuschreiben. Das Ergebnis existiert: 52 beschriebene Objekte, 250 Regeln, 208 Verknüpfungen zwischen ihnen. Dieser Artikel erzählt, wie ich dahin gekommen bin — und vor allem, was ich unterwegs falsch gemacht habe, denn das ist der Teil, der sich übertragen lässt.

Drei Vorwarnungen, bevor es losgeht.

Die erste: Dieser Bericht handelt vom Bau des Referenzmodells, nicht von seiner Nutzung. Es existiert, es ist gemessen, es hat seine ersten Nebenprodukte geliefert. Aber die Nutzungsphase hat nicht begonnen. Ich kann also nichts über den Return on Investment behaupten. Wer dir zu diesem Zeitpunkt eine Zahl verkauft, erfindet sie.

Die zweite: Die Beispiele stammen aus einem fiktiven Fall — ein Unternehmen, das ein Verwaltungs-SaaS verkauft, ein ERP, mit seinen Kunden, seinen Aufträgen, seinen Positionen und seinen Rechnungen. Was sich von einem Produkt auf ein anderes überträgt, sind nicht meine Fundstücke, sondern die Art des Problems, die man findet: ein Zustand, der überall neu berechnet und nirgends definiert wird, eine Regel, die nur auf einer Seite greift, ein Wort, das Kunden benutzen und das Produkt nicht kennt. Diese drei hast du auch. Die Details des Falls interessieren dagegen niemanden.

Die dritte: Es ist lang, eine halbe Stunde Lesezeit. Es ist ein Bericht, kein Blogpost — ich habe lieber alles gesagt als kurz geschrieben. Wenn du nur einen Abschnitt liest, nimm „Drei Abbruchkriterien. Dreimal falsch.“: Der Rest ist der Kontext darum. Die Anhänge nützen nur denen, die die Arbeit selbst machen wollen.

Eine Ontologie ist kein angereichertes Glossar

Das Wort ist eine Falle. Den einen sagt es Philosophie, den anderen ein Fachgebiet mit komplizierten Werkzeugen, den meisten überhaupt nichts. Also klären wir es sauber.

Eine Ontologie ist die explizite, strukturierte Beschreibung dessen, woraus ein Bereich besteht: - die Typen von Objekten, die existieren, - was sie kennzeichnet, - was sie verbindet, - was über sie wahr ist, - die Wörter, mit denen wir sie benennen.

Auf Software angewandt beantwortet sie fünf Fragen. Jede entspricht etwas, das man aufschreibt, und jede hat einen gelehrten Namen, den du danach nicht mehr brauchst:

Im weiteren Artikel sage ich, um die gelehrten Begriffe zu vermeiden, „Objekte“, „Eigenschaften“, „Verknüpfungen“, „Regeln“ und „Wörter“. Das ist dasselbe.

Diese fünf Kästchen dienen auch als Filter: Was in keines passt, hat im Referenzmodell nichts zu suchen.

Warum noch ein Dokument

Es gab schon ein Glossar, ein Datenbankschema, Dokumentation. Das Glossar definiert Wörter einzeln. Das Schema ordnet Daten nach technischen Zwängen, nicht nach dem Fach. Die Dokumentation erzählt, für einen menschlichen Leser.

Was sie von einer Ontologie unterscheidet, lässt sich auf einen Punkt bringen: Die Verknüpfungen zählen genauso viel wie die Definitionen. Ein allein beschriebenes Objekt lehrt wenig. Dasselbe Objekt, über präzise Verben mit fünf anderen verbunden — erteilt von, enthält, fakturiert in —, beschreibt ein Produkt.

Was sie zusammenbringt

Dasselbe Objekt trägt in einem Unternehmen drei Namen. Nimm den Kundenauftrag:

Diese drei Vokabulare entwickeln sich getrennt, und der Abstand zwischen ihnen ist eine wertvolle Information. Das Referenzmodell hält ihn fest: das offizielle Wort, die Wörter der Kunden und die, die wir unterwegs aufgegeben haben. Genau das erlaubt es, den Satz eines Nutzers in ein Produktobjekt zu übersetzen — und umgekehrt.

Was ich nicht gemacht habe

Es gibt sehr gelehrte Wege, all das zu tun: eigene Sprachen, Werkzeuge, die aus den gegebenen Regeln Schlüsse ziehen, dazugehörige Normen. Das ist ein echtes Fachgebiet, und ich bin nicht hineingegangen (unter anderem aus Mangel an Kompetenz).

Ich habe mit dem angefangen, was ich sicher beherrschte: eine Karte pro Objekt, in einer Textdatei. Ein Titel, ein paar Felder, Verknüpfungen zu den anderen Karten. Nichts, was ein Texteditor nicht öffnen kann. Solange ich nicht weiß, wozu das Referenzmodell dienen wird, weiß ich nicht, wie viel Strenge ich brauche — und einfach anzufangen, um später komplizierter zu werden, kostet immer weniger als umgekehrt.

Der Code wurde die Quelle der Wahrheit. Die Bedeutung blieb draußen.

Rund um dieses Produkt werden die Dokumentation, das Änderungsprotokoll, die Support-Dokumentation, die Antworten auf Produktfragen und die Spezifikationen aus dem Code neu erzeugt. Die Überlegung ist einfach: Die Wahrheit eines Produkts ist, was läuft, nicht, was geplant war.

Dieser Wechsel streicht eine ganze Arbeit — nämlich Dokumente von Hand aktuell zu halten, die etwas anderes beschreiben als die Realität. Das ist ein erheblicher Gewinn, und ich würde ihn weiter verteidigen.

Aber er verschiebt das Problem.

Was der Code nicht liefert

Der Code legt fest, wie das Produkt funktioniert. Die Bedeutung entsteht darüber.

Nimm den Auftrag und seinen Status. Der Code liefert die Struktur: Hier sind die Felder, hier sind die möglichen Werte. Vier Informationen machen ihn erst wirklich nutzbar, und keine davon steht dort:

• die Regel — ein fakturierter Auftrag nimmt keine Position mehr auf. Das Produkt setzt das durch, aber die Regel steht nirgends: Die Prüfung ist über fünf Dateien verstreut, und jede macht nur einen Teil. Um sie in einem Satz zu formulieren, muss man alle fünf gelesen haben;
• die Sonderfälle — ein Eilauftrag ist ein Auftrag, mit zusätzlichen Einschränkungen;
• das Vokabular — die Nutzer sagen „Deal“, und ein anderer Begriff wurde vor drei Jahren aufgegeben;
• der Geltungsbereich — das Produkt umfasst zwei Anwendungen, die ich A und B nenne, und jede legt ihre eigene Bedeutung hinter dasselbe Wort.

Zusammengenommen verwandeln diese vier Informationen eine Datenstruktur in eine Produktbeschreibung. Genau das ist der Inhalt einer Karte. Und keine davon liegt am selben Ort: Sie verteilen sich über den Kern des Codes, die Datenbank, die Masken und die Übersetzungen.

Die echten Kosten fallen woanders an

Die Frage vom Anfang ist nur einer von vielen Fällen. Alles, was das Produkt jemandem beschreibt, ist eine Rekonstruktion, jedes Mal neu, parallel, von jeder Abteilung: die Dokumentation, die Antworten auf Ausschreibungen, die Einarbeitung neuer Leute, die Sprache des Supports. Jeder fängt wieder beim Code an, oder beim Gedächtnis von irgendjemandem.

Genau diese Ausgabe soll verschwinden. Sie steht in keinem Budget, was erklärt, warum wir sie seit Jahren bezahlen, ohne sie zu sehen.

Eine KI kann nicht fragen. Sie rät.

Bisher wurde das, was das Produkt wirklich ist, mündlich weitergegeben. Man fragte die richtige Person, bekam die Regel und ging wieder an die Arbeit. Das Modell des Produkts lebte in einigen Köpfen, und das ging gut, weil man immer an eine Tür klopfen konnte.

Eine KI klopft an keine Tür.

Wenn man ihr eine Änderung überträgt, beschreibt man sie in ein paar Sätzen. In unserem Kopf steckt ein vollständiges Modell: was ein Auftrag ist, welche Zustände er durchläuft, was verboten ist und ab wann. Der Agent hat nur unsere paar Sätze, plus das, was er im Code lesen kann. Den Rest füllt er auf — plausibel, kohärent und manchmal falsch.

Der Abstand zwischen dem, was wir wollten, und dem, was wir zurückbekommen, ist genau der Teil unseres mentalen Modells, den wir nicht aufgeschrieben haben.

Ein Referenzmodell ist dieses aufgeschriebene mentale Modell. Es einem Agenten zu geben macht ihn nicht klüger: Es verhindert, dass er dort erfindet, wo eine Regel existiert. Daraus folgen drei Verwendungen, und die interessieren mich.

Eine Änderung anfordern, ohne das Produkt neu zu erklären. „Füge einen Rabatt auf Aufträge hinzu.“ Mit dem Referenzmodell im Kontext weiß der Agent, dass ein fakturierter Auftrag keine Position mehr aufnimmt, dass ein Rabatt eine Obergrenze hat und dass „Auftrag“ auch Eilaufträge und Daueraufträge umfasst. Ohne es entdeckt er eine dieser drei Sachen beim Review — im besten Fall.

Schneller analysieren. Einen Bug zu untersuchen beginnt immer damit, das Modell des betroffenen Bereichs zu rekonstruieren. Diese Rekonstruktion wird jedes Mal neu gemacht, von jeder Person und von jedem Agenten. Einmal geschrieben, liest sie sich in wenigen Sekunden. Und ein paar hundert Karten passen in einen Kontext, in den tausende Codedateien nicht passen: Der Agent liest, was nötig ist, statt zufällig zu graben.

Tests schreiben und Meldungen entscheiden. Eine Regel ist eine überprüfbare Aussage. „Ein fakturierter Auftrag nimmt keine Position mehr auf“ ist ein Test, genau so, formuliert in der Fachsprache. 250 Regeln sind 250 Testkandidaten, die niemand aus dem Code herleiten muss. Und bei einer Kundenmeldung wird die Frage mechanisch: Widerspricht das einer geschriebenen Regel — dann ist es ein Bug; oder ist es eine Regel, die niemand aufgestellt hatte — dann ist es eine Produktentscheidung, kein Defekt. Heute fällt dieses Urteil aus Erfahrung, von der Person mit der längsten Zugehörigkeit im Team.

Nichts davon ist gemessen, gemäß der Vorwarnung am Anfang. Der Mechanismus erscheint mir solide — man streicht den geratenen Teil —, aber ich habe den Test nicht gemacht. Den werde ich machen: rund dreißig Anfragen nehmen, die Hälfte mit dem Referenzmodell im Kontext bearbeiten und die andere Hälfte ohne, dann Zeitaufwand und Nacharbeit vergleichen. Bis das erledigt ist, ist dieser Abschnitt eine Erwartung, kein Ergebnis.

Die Methode: skizzieren, um zu wissen, wonach man sucht

Ein Dilemma zeigt sich sofort. Ohne ein Modell, und sei es grob, weiß man nicht, welches Material man sammeln soll — und läuft an wichtigen Informationen vorbei, ohne es zu merken. Ohne Material weiß man nicht, welches Modell man halten soll.

Iterieren, nicht sequenzieren. Man skizziert gerade genug, um zu wissen, wonach man sucht, sucht, und nimmt das Modell mit dem Gelernten wieder auf. Eine Bedingung zieht sich durch alle Runden: Was man sammelt, wird in der einfachsten möglichen Form gespeichert, und immer mit dem Hinweis, woher es kommt. Ein Modellwechsel darf nie dazu zwingen, schon Gesammeltes erneut zu holen.

Wo anfangen: zwanzig Fragen, die man uns schon gestellt hatte

Ein Produkt hat Dutzende Bereiche — die Fakturierung, den Einkauf, die Zugriffsrechte, die Suche, die Benachrichtigungen. Mit welchem fängt man an? Die theoretische Antwort ist bekannt: Man schreibt zuerst die Fragen auf, die das Referenzmodell beantworten muss, und sie grenzen das Feld ab. Das Problem ist, dass Fragen, die kalt in einem Besprechungsraum entstehen, immer so aussehen wie das, was wir für wichtig halten.

Also habe ich sie nicht geschrieben. Ich bin sie holen gegangen.

Seit Monaten wird jede eingehende Produktfrage — über Slack, in einem Meeting, von einem Vertriebler, der eine Antwort vorbereitet, vom Support vor einem Ticket — mit ihrer Antwort archiviert. Ich habe alle noch einmal gelesen und dann zu zwanzig generischen Fragen verdichtet. Keine ist erfunden; jede deckt zwischen fünf und zwanzig echte Fragen ab.

Auf das fiktive ERP übertragen sehen sie so aus:

• Welche Zustände hat ein Auftrag, und welche Übergänge zwischen ihnen sind erlaubt?
• Was lässt sich noch stornieren, und ab welchem Moment nicht mehr?
• Was ist der Saldo eines Kunden, und durch welche Bewegungen verändert er sich?
• Wem gehört ein automatisch erzeugter Auftrag, und was passiert mit ihm, wenn diese Person das Unternehmen verlässt?
• In welchen Fällen sieht ein Nutzer einer Tochtergesellschaft die Aufträge einer anderen Tochtergesellschaft?
• Wie nennen die Nutzer den Auftrag, und in welchen Sprachen?

Das sind keine eleganten Fragen. Es sind die, die jemanden mehrmals im Monat eine halbe Stunde kosten.

Was das sofort liefert: die Arbeitsreihenfolge. Jede Frage berührt einen oder mehrere Bereiche des Produkts; man muss nur zählen. Elf von zwanzig Fragen trafen denselben Bereich — er wurde der erste. Fünf einen zweiten, vier einen dritten. Die Reihenfolge ist keine Vorliebe mehr, sie ist eine Auszählung.

Und sie dienen ein zweites Mal, am Ziel. Ist ein Bereich fertig, nimmt man seine Fragen wieder vor und prüft, dass das Referenzmodell sie ohne Öffnen des Codes beantwortet. Die Prüfung auf halbem Weg ergab 18 vollständige Antworten von 20. Die zwei fehlenden fielen auf dieselbe Weise durch: eine allgemein formulierte Regel, wo die Frage das Detail erwartete — „bestimmte Vorgänge verlangen dies“, ohne je zu sagen, welche.

Das ist der wahrscheinlichste Fehler bei dieser Art Arbeit, und der schwerste zu sehen. Karten zu zählen hätte ihn nie gezeigt.

Eine Karte pro Objekt, und Verknüpfungen dazwischen

Eine Karte pro Fachobjekt, in einer Textdatei mit seinem Namen. Jedes Mal, wenn eine Karte ein anderes Objekt nennt, tut sie es über eine Verknüpfung.

Dieses Detail sieht kosmetisch aus. Ist es nicht. Die Karten und ihre Verknüpfungen bilden ein Netz, und dieses Netz lässt sich darstellen: Jede Karte ist ein Punkt, jede Verknüpfung ein Strich. Eine Verknüpfung, die auf eine noch nicht existierende Karte zeigt, sieht man sofort — das ist das Signal, dass ein Objekt noch beschrieben werden muss.

Das Netz ist damit kein schönes Bild mehr, sondern die Arbeitswarteschlange: Solange es Verknüpfungen ins Leere gibt, gibt es Karten zu schreiben.

Die Realität auf der einen Seite, die Absicht auf der anderen

Ein Referenzmodell kann zwei sehr verschiedene Dinge beschreiben: was das Produkt tut oder was es tun sollte. Jedes allein ist unvollständig. Das erste bringt niemals einen Defekt zum Vorschein. Das zweite verliert die Spur dessen, was wirklich existiert.

Ich behalte beides, an zwei getrennten Stellen derselben Karte. Der Rumpf der Karte beschreibt die Realität, so wie sie im Code steht. Ein eigener Block am Ende der Karte listet die Abweichungen: jede Stelle, an der diese Realität von dem abweicht, was wir wollen würden.

Absolute Regel: Eine Abweichung ändert niemals den Rumpf der Karte.

Was die Trennung rechtfertigt, ist, dass die beiden Teile nicht dieselbe Lebensdauer haben:

Der Rumpf ergibt sich aus dem Code: Man kann ihn wegwerfen und neu machen, ohne etwas zu verlieren. Die Abweichungen tragen Urteil — sie finden sich nirgends wieder, wenn man sie verliert. Sie zu trennen heißt, den Teil zu schützen, der teuer zu erzeugen ist.

Ein Punkt, der oft falsch verstanden wird: Wenn alles in Ordnung ist, schreibt man nichts. Tut das Produkt, was es tun soll, steht die Regel einfach im Rumpf der Karte. Der Abweichungsblock enthält nur die Divergenzen. Eine Karte ohne Abweichung signalisiert ein konformes Objekt, und das ist selbst eine Information.

Fünf Arten von Abweichung genügen, und sie machen aus dem Referenzmodell erst Arbeitsmaterial:

Der Ausgangspunkt: eine Momentaufnahme

Man beschreibt das Produkt so, wie es zu einem bestimmten Zeitpunkt ist. Eine Version des Codes und alles, was mit ihr läuft: die Datenbank, wie sie in dieser Version aussieht, die Masken dieser Version, die Übersetzungen dieser Version. Das ist die Momentaufnahme.

Was darauf zu sehen ist, ist der Anfangszustand, ohne Geburtsdatum: Ich versuche nicht herauszufinden, wann jedes Feld entstanden ist. Die Geschichte des Produkts zu rekonstruieren würde bedeuten, Jahre von Archiven zu durchwühlen, für null Nutzen.

Später macht man eine neue Aufnahme und aktualisiert die Karten mit dem, was sich zwischen beiden bewegt hat. Das ist der ganze Mechanismus.

Das Einzige, worauf zu achten ist, und da bin ich hereingefallen: Eine Quelle, die nicht zur Momentaufnahme gehört, ist keine Quelle. Dazu weiter unten mehr.

Vier Orte zu lesen, keiner optional

Dasselbe Objekt ist an vier Orten im Produkt beschrieben, und jeder sagt, was die anderen verschweigen:

Ein Bereich des Produkts ist erst fertig, wenn alle vier gelesen wurden. Eine Regel kann gut in nur einem davon existieren.

Die Masken liest man nach dem Kern des Codes und bevor man das Thema schließt. Das ist keine Forderung nach Vollständigkeit, das ist eine Maschine, die Abweichungen findet:

Eine Regel, die nur in der Maske steht, ist fast immer eine Abweichung.

Entweder ist es eine echte Fachregel an der falschen Stelle — eine Reibung. Oder sie lässt sich umgehen, indem man an der Maske vorbeigeht, über einen Dateiimport oder über die Schnittstelle, die das Produkt externen Entwicklern anbietet — seine API. Und dann ist es ein Defekt, mit einem Sicherheitsaspekt: Was die Maske verbietet, erlaubt ein anderer Weg.

Der umgekehrte Fall existiert und wird gleich behandelt. Eine Regel, die der Kern des Codes durchsetzt, die Maske aber nicht spiegelt, erzeugt eine unverständliche Fehlermeldung: Der Nutzer bekommt seine Aktion verweigert, ohne zu sehen, was er falsch gemacht hat.

Zwei Beobachtungen zu diesem Lesen der Masken.

Erstens: Die Aufteilung der Masken deckt sich nicht mit der des Codes. Zwölf Zonen der Oberfläche hatten keine entsprechende Zone auf der Serverseite. Die Zuordnung erfolgt daher Objekt für Objekt, niemals Ordner für Ordner.

Zweitens ein Trick, der in den unordentlichsten Teilen des Codes Gold wert ist: Die Namen der technischen Fehlermeldungen sind oft die beste Quelle für Regeln. Ein Entwickler, der eine Aktion verweigert, erzeugt einen Fehlerfall und benennt ihn. Ein Fehler namens CannotEditInvoicedOrder — „ein fakturierter Auftrag kann nicht bearbeitet werden“ — formuliert eine Regel für sich allein. Man muss nur die Liste dieser Namen lesen, und das verlangt keine Programmierkenntnisse.

Nichts davon ist originell

Das ist vielleicht der nützlichste Punkt dieses Abschnitts. Ontologien zu bauen ist ein etabliertes Fach mit eigener Literatur, und die Methode oben greift nur bekannte Erkenntnisse auf:

• Iterativ statt Wasserfall. Die historischen Methoden reihten die Schritte in Ordnung: spezifizieren, entwerfen, formalisieren, umsetzen. Sie wurden von Ansätzen aus kleinen, neu kombinierbaren Teilen verdrängt. Diese Debatte ist seit etwa fünfzehn Jahren entschieden.
• Der Rahmen über Fragen. Zuerst die Fragen aufzuschreiben, die das Referenzmodell beantworten muss, ist das Standardvorgehen; es hat sogar einen Namen, competency question. Sie im Support zu holen statt kalt zu schreiben steht in keinem Handbuch. Es kostet nichts und ändert, was man findet.
• Von der Mitte aus starten. Man beginnt bei den zentralsten Fachobjekten, steigt dann zu den weiteren Kategorien auf und zu den Sonderfällen hinab. Die beiden anderen Wege scheitern: Von der Datenbank auszugehen heißt, die technische Struktur unverändert abzuschreiben, mit ihren Tabellen, die fachlich nichts bedeuten; von einer allgemeinen Theorie des Seienden auszugehen ergibt ein Gebäude, das jedes Maß des Bedarfs sprengt.
• Strenge im Verhältnis zur Nutzung. Man macht es sich schwer, wenn man es braucht, nicht aus Prinzip.
• Nicht neu erfinden, was schon normiert ist. In den meisten Branchen gibt es maßgebliche Klassifikationen. Man muss sie sich ansehen — und jede Divergenz zwischen dem eigenen Modell und ihnen als zu untersuchende Frage behandeln, nicht als Detail.

Drei Abbruchkriterien. Dreimal falsch.

Das ist der Teil, für den dieser Artikel existiert.

Zuerst zwei verworfene Strategien

Zu wissen, was man sucht, sagt nicht, in welcher Reihenfolge man das Produkt durchgeht. Zwei Ansätze bieten sich natürlich an, und beide scheitern.

Alles lesen, in der Reihenfolge der Dateien. Ohne Priorität gibt es keine Reihenfolge des Eintreffens und keine Struktur, die entsteht. Die Ordnerorganisation hat nichts mit fachlicher Wichtigkeit zu tun, und was nur aus technischen Gründen da ist, wird auf derselben Ebene beschrieben wie die echten Fachobjekte. Man erhält eine Masse von Karten, ohne zu wissen, welche zählen.

Von der Datenbank ausgehen und eine Karte pro Tabelle machen. Nützlich, aber unzureichend, und auf einer Verwechslung gebaut: Eine Tabelle ist kein Fachobjekt. Viele Tabellen dienen nur dazu, zwei andere Tabellen zu verbinden, eine technische Spur zu halten, Anmeldetoken oder Zwischenergebnisse zu speichern. Für jemanden, der über das Produkt spricht, bedeuten sie nichts.

Also habe ich einen dritten Weg gewählt: ein Produktbereich nach dem anderen, vom Kern des Fachs zur Peripherie, gestützt auf die Aufteilung, die der Code schon mitbringt. Eine etwas größere Software ist in Module geteilt — Codezonen, die grob den Bereichen des Fachs entsprechen: die Fakturierung, der Einkauf, die Zugriffsrechte. Diese Aufteilung haben Entwickler gemacht, aber sie ist schon eine teilweise Beschreibung des Fachs, kostenlos und durch die Nutzung bestätigt.

Das war die richtige Entscheidung. Sie hat nicht verhindert, was danach kam.

Erstes Kriterium: „Das Netz der Karten ist geschlossen“

Alle genannten Karten existieren, keine Verknüpfung zeigt mehr ins Leere. Also ist es fertig.

Das ist falsch, und der Grund ist mechanisch. Eine Menge von Karten, die sich nur untereinander zitieren, schließt ihr Netz lange bevor sie das Produkt abgedeckt hat. Bei mir schloss sich das Netz, als erst zwölf von zweiunddreißig Modulen eine Karte hervorgebracht hatten.

Was diese Prüfung wirklich bewies: dass die Menge in sich hält. Nichts weiter. Es ist eine gute Prüfung, man soll sie behalten — aber sie beantwortet die gestellte Frage nicht.

Die danach durchgeführte Prüfung der Abdeckung brachte zwei zentrale Fachobjekte zum Vorschein, die im Netz nichts verlangt hatte.

Zweites Kriterium: „Ich habe alle meine Quellen durchgearbeitet“

Der Code beider Anwendungen, die Datenbank, die API, das Glossar, die Gesprächsprotokolle, die Support-Tickets. Nichts mehr zu öffnen.

Das stimmt, und es beweist nichts. Es ist eine Aussage darüber, was ich geöffnet habe, nicht darüber, was existiert. „Ich habe meinen ganzen Stapel gelesen“ sagt nichts über die Bibliothek: Solange das Produkt nicht aufgezählt ist, hat „alles“ keinen Nenner. Ein Modul, das nie auf meiner Liste stand, steht auch nicht in meinem „alles“.

Drittes Kriterium: „Jeder Bereich wurde an allen vier Orten gelesen“

Der Kern des Codes, die Datenbank, die Masken, die Übersetzungen.

Auch wahr, und aus demselben Grund unzureichend: Es gilt nur für die Bereiche, die ich erkannt hatte. Das Kriterium misst die Tiefe, es sagt nichts über die Breite. Man kann vier Orte über zwölf Module lesen und zwanzig andere ignorieren — genau das ist passiert.

Die Diagnose

Nehmen wir alle drei und das, was jedes wirklich bewies.

Alle drei sagen dasselbe: Ich habe beendet, was ich angefangen hatte. Keines sagt: Es bleibt nichts übrig.

Man wählt ein Kriterium, das man erfüllen kann, statt eines, das die geleistete Arbeit beweist.

Es ist der Unterschied zwischen „Ich habe alles aufgeräumt, was auf meinem Schreibtisch lag“ und „Hier ist die Liste dessen, was ich aufräumen sollte, alles abgehakt“. Der erste Satz ist wahr und verpflichtet zu nichts. Der zweite setzt voraus, dass man die Liste vor dem Anfangen gemacht hat.

Das ist keine Unehrlichkeit, das ist eine Kostenfrage.

Ein Kriterium, das man erfüllen kann, hat man schon zur Hand: Man schaut auf das, was man gerade getan hat, und stellt fest, dass es getan ist. Ein Kriterium, das beweist, verlangt dagegen, etwas Zusätzliches herzustellen — die Liste dessen, was existiert, eine Art, sie zu zählen, eine Zahl, die ein anderer nachrechnen könnte. Das ist zusätzliche Arbeit, gefordert genau in dem Moment, in dem man glaubt, fertig zu sein.

Daher das einzige Gegenmittel, das ich kenne: das Abbruchkriterium am Anfang wählen, nicht am Ende. Es am Ende zu suchen bedeutet, es unter denen auszuwählen, die man sicher schon erfüllt.

Das einzige Kriterium, das hält

Das Produkt aus mehreren unabhängigen Blickwinkeln aufzählen und für jeden den Anteil messen, der einer Karte entspricht.

Jeder Blickwinkel sieht, was die anderen nicht sehen können:

Und vor allem: Das nützliche Signal ist die Uneinigkeit zwischen zwei Blickwinkeln. Ein Objekt, das in einem vorkommt und in den anderen fehlt, ist entweder ein übersehenes Fachobjekt oder technische Infrastruktur. Die Frage entscheidet sich in einer Zeile — aber sie entscheidet sich ausdrücklich, nie im Vorbeigehen.

Die anderen Fehler

Vier kleinere, alle teuer.

Eine Quelle lesen, die nicht auf der Momentaufnahme war. Der Datenbank-Export, den ich hatte, war fünf Monate vor der Codeversion erzeugt worden, die ich beschrieb. Ich habe ihn gelesen, als beschriebe er dasselbe Produkt. Er beschrieb ein älteres: In einem ganzen Bereich standen die Objekte im Code, ohne entsprechende Tabelle im Export, und ich schloss daraus, dass sie nicht existierten.

Die Regel ist einfacher als ich damals dachte. Sie lautet nicht „das Datum prüfen, bevor man schließt“ — sie lautet, dass eine Quelle, die nicht zur Momentaufnahme gehört, keine Quelle ist. Man ersetzt sie durch eine aktuelle Version, oder man verzichtet.

Und die Präzisierung, auf die es ankommt, weil ich sie zuerst übersehen hatte: Wenn zwei Teile derselben Momentaufnahme sich widersprechen — der Code auf der einen Seite, die Datenbank oder die Maske auf der anderen, zum gleichen Zeitpunkt, in Produktion —, ist das kein Zeitversatz. Es ist eine Inkonsistenz des Produkts. Genau das sucht man.

Eine Suche für eine Bestandsaufnahme halten. Ich hatte den gesamten Code in einer Suchmaschine nach Bedeutung indexiert — das Prinzip von RAG: Man stellt seine Frage in Alltagssprache, das Werkzeug bringt die Passagen, die ihr am nächsten kommen. Das ist verblüffend wirksam, um eine Regel wiederzufinden, die mitten in einer Datei begraben liegt und deren Name nichts verrät.

Aber eine Maschine dieser Art antwortet immer, und sie antwortet immer mit einer Rangfolge: Hier sind die zehn Passagen, die deiner Frage am nächsten kommen. Sie sagt nie „es gibt keine“. Eine Suche, die nichts Interessantes bringt, kann also zwei Dinge bedeuten — die Sache existiert nicht, oder ich habe die Frage schlecht gestellt. Unmöglich zu entscheiden.

Daher die Regel: erst aufzählen, dann suchen. In der anderen Richtung bekommt man ein Referenzmodell aus dem, was die Maschine gerade hergeben wollte.

Zwei Details, die teuer sind. Die Maschine hatte ihr eigenes Datum, eine Version hinter dem Code. Und man muss die Frage in der Sprache des Codes stellen: Eine Abfrage auf Deutsch gegen englisch geschriebenen Code liefert mittelmäßige Ergebnisse, selbst wenn die Antwort dort steht.

Dieselbe Regel an drei Stellen schreiben. Unterwegs entstanden drei Dokumente: - die Kartenvorlage zum Ausfüllen, - das Methodendokument, - die Arbeitsanweisungen, die ich dem Agenten gab.

Eine und dieselbe Regel — zum Beispiel „eine Abweichung ändert niemals den Rumpf der Karte“ — landete in allen drei, jedes Mal mit etwas anderen Worten.

Solange sich nichts ändert, stört das niemanden. An dem Tag, an dem sich die Regel weiterentwickelt, korrigiert man eines, vergisst die anderen zwei, und drei Dokumente widersprechen sich, ohne dass jemand weiß, welches gilt. Eine KI weniger als alle anderen: Sie liest alle drei, ohne zu sehen, dass sie auseinandergehen, und stützt ihre Analyse auf das, was sie zuerst geöffnet hat.

Jede Regel wohnt jetzt an einer einzigen Stelle. Die Kartenvorlage beschreibt nur die Form — welche Felder, welche erlaubten Werte — und verweist für alles andere auf die Methode. Eine einzige Quelle pro Regel.

Die Ironie fiel mir damals nicht auf: Ich baute ein Referenzmodell, das doppelte Definitionen abschaffen sollte, und verdoppelte dabei seine eigenen Regeln über drei Dateien.

Falsch zählen. Ich wollte wissen, welche Wörter Kunden wirklich benutzen und wie oft. Also habe ich die Vorkommen jedes Fachbegriffs in 261 Gesprächsprotokollen gezählt.

Erstes Ergebnis: Ein Kürzel aus zwei Buchstaben kam 3.525 Mal vor. In Wirklichkeit waren es 2. Die Suche zählte jedes Mal mit, wenn diese zwei Buchstaben innerhalb eines anderen Wortes vorkamen. Such so nach „CA“, und du erntest „Scanner“, „Casting“ und jedes „ca.“ im Text.

Man muss also ganze Wörter zählen und die Groß- und Kleinschreibung berücksichtigen, wenn der Begriff ein Kürzel ist. Ein falscher Zähler ist schlimmer als kein Zähler: Er sieht aus wie eine Zahl.

Der umgekehrte Fehler existiert auch und ist heimtückischer. Ein Begriff, den ich für abwesend hielt, stand im Produkt, aber in völlig anderer Bedeutung, in einer technischen Ecke ohne Bezug zum Fach. Eine Abwesenheit prüfen, bevor man auf eine Lücke schließt.

Und eine Abweichung, die keine war

Ich hatte eine Abweichung erfasst, die behauptete, eine bestimmte Art von Verknüpfung zwischen Objekten sei im Produkt nicht korrekt beschrieben. Nach Prüfung: Sie war es doch.

Die Abweichung bleibt in der Karte, als abgelehnt markiert, mit dem Grund der Ablehnung. Sich zu irren gehört zur Arbeit, vorausgesetzt der Irrtum lässt eine brauchbare Spur — sonst macht in sechs Monaten jemand anderes denselben Fehler.

Der Agent erfasst. Der Mensch öffnet wieder.

Die Arbeit hat ein Agent geleistet — eine KI, der man eine lange Aufgabe überträgt — unter meiner Leitung. Das ist wohl der übertragbarste Teil dieses Berichts, weil er nicht nur von Ontologie handelt.

Eine methodische Präzisierung: Dieser Abschnitt stützt sich auf niemandes Erinnerung. Das Entscheidungsregister des Vorhabens ist das Tagebuch meiner Eingriffe — jeder Eintrag trägt seinen Grund, also was ich korrigiert habe und warum. Das Fortschrittstagebuch zeigt, was der Agent zwischen zwei Abwägungen produziert hat. Alles Folgende lässt sich in diesen zwei Spuren lesen.

Was ein Agent bemerkenswert gut macht: aufzählen, abgleichen, zählen, eine Nachverfolgung Zeile für Zeile führen und die Übersetzungen des zwölften Bereichs so gründlich lesen wie die des ersten. Diese Arbeit ist massiv repetitiv, und genau das machte sie bisher unbezahlbar.

Was er schlecht macht: die Arbeit für beendet erklären. Die drei falschen Abbruchkriterien kamen nicht aus dem Nichts — jedes wurde als Beweis der Fertigstellung vorgeschlagen, und jedes Mal musste es abgelehnt werden. Die Verzerrung ist dieselbe wie bei einem müden Menschen am Projektende, nur hat er die Müdigkeit nicht als Entschuldigung: Berichten mit Liefern verwechseln.

Meine Eingriffe, wie sie in den Gründen der Entscheidungen stehen, fallen in drei Kategorien:

• Einen Geltungsbereich erweitern, den er implizit verengt hatte. Der Agent las den Kern des Codes und hörte dort auf. Die Regel der vier Orte, Masken inklusive, kommt daher — und genau in den Masken stecken die interessantesten Abweichungen.
• Eine Struktur korrigieren, die auseinanderlaufen würde. Dieselbe Regel an drei Stellen: Er hatte sie aus dem Wunsch heraus kopiert, es gut zu machen, was genau das war, was er nicht tun sollte.
• Ein zu bequemes Abbruchkriterium ablehnen. Dreimal.

Was diese Abwägung möglich macht, lässt sich auf vier Vorkehrungen bringen, und die gelten für jede delegierte Arbeit — an eine Maschine wie an einen anderen Menschen:

1. Ein von Dritten überprüfbares Abbruchkriterium. Nicht „ich habe alles gelesen“, sondern eine Liste und eine Quote.
2. Eine Messung, die man neu laufen lassen kann, statt einer Behauptung. Zwischen „das ist abgedeckt“ und „hier ist der Befehl, der es prüft“ liegt der ganze Abstand zwischen Versprechen und Tatsache.
3. Eine schriftliche Nachverfolgung in der richtigen Körnung. Eine Zeile pro Bereich und pro zu lesendem Ort, laufend aktualisiert. Sie überlebt die Unterbrechung der Arbeit, und sie verhindert, dass man dasselbe zweimal macht.
4. Aufzählen vor Suchen. Das Sichere zuerst, das Wahrscheinliche danach und als Ergänzung.

52 Objekte und sieben Wege zu prüfen, dass keines fehlt

Was dabei herauskam, nachdem das richtige Kriterium angewandt war.

52 beschriebene Fachobjekte. 250 Regeln. 208 Verknüpfungen zwischen ihnen. 124 erfasste Abweichungen. Keine Verknüpfung mehr, die ins Leere zeigt.

Die zwanzig Ausgangsfragen finden ihre Antwort, ohne den Code zu öffnen.

Die Abdeckung, gemessen

Das Prinzip besteht aus drei Handgriffen. Ich liste die Objekte eines Blickwinkels auf — die Module, die Tabellen, die Ereignisse, die Masken, die von der API angebotenen Ressourcen. Ich schaue für jedes, ob es einer Karte entspricht. Ich zähle.

Die Messung lässt ein kleines Programm erneut laufen. Das ist der wichtige Punkt: Es ist keine Behauptung, es ist eine Prüfung, die jemand anderes wiederholen kann.

Und es ist eine schwache Messung, was im selben Satz gesagt werden muss. Die Zuordnung läuft über die Namen: Eine Tabelle sales_order wird als Karte „Sales Order“ erkannt, Groß- und Kleinschreibung, Bindestriche und Plurale beiseitegelassen.

Das funktioniert etwa in einem von zwei Fällen. Beim Rest gleichen sich die Namen überhaupt nicht — eine Tabelle kann so_header heißen, wo die Karte „Sales Order“ heißt. Also habe ich daneben eine Zuordnungsliste geführt, Zeile für Zeile geschrieben, wie ich darüber stolperte: diese Tabelle ist dieses Objekt.

Diese Liste ist ein Urteil, keine Regel. Vergesse ich eine Zeile, erscheint das Objekt als nicht abgedeckt, obwohl es abgedeckt ist. Füge ich eine zweifelhafte hinzu — „komm, diese Tabelle muss doch zu dieser Karte gehören“ —, blase ich meinen eigenen Stand auf. Und selbst wenn die Namen übereinstimmen, kann es Zufall sein: zwei verschiedene Dinge mit demselben Wort.

Die Messung beweist also nichts. Sie zeigt, wo man hinschauen soll.

Warum ich nicht 100 % anstrebe

Das ist der unmittelbare Einwand: Wenn ich weiß, dass mir 19 % der Module fehlen, weiß ich, welche — man muss sie nur beschreiben.

Nur ist das fehlende Kästchen keine Aufgabe, sondern eine Frage. Jedes Objekt ohne Karte ist entweder ein übersehenes Fachobjekt oder technische Infrastruktur ohne jede fachliche Bedeutung: eine technische Warteschlange, ein Bildskalierer, eine Tabelle mit Anmeldetoken, eine Navigationsmaske. 100 % zu erreichen würde bedeuten, eine Karte „Warteschlange“ und eine Karte „Token“ anzulegen — also das Referenzmodell zu verschmutzen, um eine Zahl zu heben.

Der Zähler hat daher drei Zustände, nicht zwei:

Was 100 % erreichen muss, ist die dritte Zeile auf null — nichts mehr, das nicht geprüft wurde. Der angezeigte Prozentsatz steigt nicht auf 100 und muss das auch nicht.

Hier wurde der Rest von Hand durchgesehen: Technik, interne Mechanismen, Masken ohne eigenes Fachobjekt. Kein Fachobjekt hatte sich dort versteckt. Aber das ist eine manuelle Prüfung, bei jeder Änderung zu wiederholen — und das ist die Schwäche, die bleibt.

Die Zahl dient also etwas anderem als dem Messen von Fortschritt. Sie dient dem Vergleich der Blickwinkel untereinander. 69 % bei den Objekten der Anwendung B gegen 93 % bei den Ereignissen heißt nicht „es bleiben 31 % Arbeit“: Es heißt „die Anwendung B verarbeitet Dinge, die der Rest des Produkts nicht kennt, schaut dort nach“. Diese Uneinigkeit hat die vier folgenden Fundstücke hervorgebracht.

Was die Blickwinkel eingebracht haben

Vier Objekte, die kein anderer Weg gefunden hätte:

• Über die Tabellen der Datenbank. Ein Objekt, das das Produkt anzeigt, das aber zu keinem Bereich des Codes gehört — im fiktiven ERP wäre es die anstehende Rechnungsfälligkeit: Der Kunde sieht sie in seinem Zahlungsplan, aber sie existiert erst richtig in dem Moment, in dem die Rechnung gestellt wird. Diese Zweideutigkeit erklärt eine ganze Familie von Kundenbeschwerden.
• Über die Ereignisse. Eine ganze Teilmenge eines Bereichs, den wir für abgedeckt hielten, aufgedeckt durch die Ereignisse, die er aussendete und die niemand irgendwo zugeordnet hatte.
• Über die API. Zwei Objekte, über fünf verschiedene Module verteilt — also unsichtbar, solange man Bereich für Bereich vorgeht, und dennoch vertraglich nach außen angeboten.
• Über die Anwendung B. Zwei Objekte, die sie verarbeitet und die die Anwendung A nicht kennt.

Die Probleme, die überall wiederkehren

Hier sind die Fundstücke, auf das fiktive ERP übertragen. Es sind Problemtypen, keine Einzelfälle — und ich würde wetten, dass keines in deinem Produkt fehlt.

Ein Zustand, überall neu berechnet, nirgends definiert. Der Status eines Auftrags, abgeleitet aus einigen Daten und dem Zustand seiner Positionen, in jeder Maske neu berechnet, ohne zentrale Regel. Zwei Masken sagen am Ende nicht mehr dasselbe, und niemand weiß, welche recht hat.

Ein Objekt, das der Nutzer sieht und nicht wiederfinden kann. Die Rechnungsfälligkeit, von der ich sprach: im Zahlungsplan angezeigt, in den Suchergebnissen abwesend, weil sie als Dokument noch nicht existiert. Der Nutzer hat sie aber auf dem Bildschirm gesehen — er sucht sie also, findet sie nicht und öffnet ein Ticket. Der Support antwortet seit Jahren Fall für Fall, ohne dass die Ursache irgendwo aufgeschrieben wäre.

Ein Wert, der keiner ist. Der Saldo eines Kunden ist keine irgendwo abgelegte Zahl: Er ist das Ergebnis einer Rechnung über alle seine Rechnungen, Zahlungen, Gutschriften und Korrekturbuchungen. Solange das implizit bleibt, greift jede neue Funktion, die „den Saldo liest“, zum falschen Objekt und liefert eine leicht andere Zahl, je nachdem, welche Bewegungen sie einzubeziehen gedacht hat. Drei Masken, drei Salden.

Eine Regel, die nur auf einer Seite greift. Die Rabattobergrenze wird im Eingabeformular geprüft und nirgends sonst — also umgehbar über einen Dateiimport oder über die API. Das ist die Abweichungsmaschine, von der ich oben sprach, und ihr Ertrag ist bemerkenswert.

Eine Berechtigung, aus sechs Quellen berechnet, ohne eine Stelle, die sie zusammenführt. Die Rolle der Person, der gebuchte Tarif, die aktivierten Optionen, die Beschränkung der Testphase, der Bereich ihrer Tochtergesellschaft, eine Ausnahmeliste. Keine Stelle im Produkt sagt: „So wird eine Berechtigung berechnet.“ Jede Änderung entdeckt es auf eigene Kosten neu.

Dasselbe Objekt, in jeder Etage anders benannt. „Auftrag“ auf der Maske, ein Wort im Code, ein anderes in der zweiten Anwendung, „Deal“ in der Praxis. Vier Vokabulare für das zentralste Objekt des Produkts.

Ein Wort, das Kunden dauernd benutzen und das Produkt nicht kennt. In 261 Gesprächsprotokollen kommt ein Begriff 79 Mal wieder, ein anderer 29 Mal. Weder der eine noch der andere existiert im Produkt, unter keinem Namen. Das sind keine Vokabularabweichungen, das sind Entwurfslücken — und sie zeigen sich nur, wenn man vergleicht, was Kunden sagen, mit dem, was das Produkt tut.

Die Nebenprodukte

Keines war das Ziel. Alle sind aus der Arbeit gefallen.

Bug-Kandidaten. Das Produkt widerspricht einer irgendwo geschriebenen Erwartung. Jeder kommt mit seinem Beleg und seiner Folge, nicht mit einer Ahnung.

Ein Kundenvokabular mit Häufigkeiten. Zählt man die Wörter über 261 Gesprächsprotokolle und 365 Support-Tickets, erhält man für jedes Produktobjekt die tatsächlich benutzten Begriffe und ihr Gewicht. Wer mit dem Kunden spricht, weiß dann, welches Wort er nehmen soll. Ein Begriff kommt 168 Mal für einen Bereich vor, den das Produkt anders nennt; ein anderer 141 Mal für das zentrale Objekt.

Und diese zwei Textmengen sagen nicht dasselbe. Die Gespräche sagen, was Kunden bauen wollen. Die Tickets sagen, was kaputtgeht. Dasselbe Wort kann in einer dominieren und in der anderen fehlen. Beide zusammen zu zählen heißt, schief zu priorisieren.

Eine Bestandsaufnahme der Übersetzungen. Das mehrsprachige Glossar deckt nur 15 der 52 Objekte ab. Unter den Fehlenden werden zwei dem Nutzer trotzdem in allen Sprachen angezeigt: Für sie existiert keine Referenzübersetzung. Und von den neunzehn Sprachen des Glossars sind nur zwei gegengelesen.

Was es kostet, und was die Methode weiterhin nicht sagt

Die Kosten

Unter sechs Stunden. So lange hat das Ganze gedauert: die 52 Karten, die 250 Regeln, die Messungen der Abdeckung. Eine Sitzung, von Anfang bis Ende.

Vor dem Start hatte ich einige Dutzend Stunden geschätzt, Bereich für Bereich verteilbar. Ich habe mich um eine Größenordnung geirrt — und dieser Schätzfehler ist vielleicht der wahre Grund, warum diese Arbeit vorher niemand gemacht hat: Man hält sie für unerreichbar, also fängt man nicht an.

Drei Vorbehalte zu dieser Zahl, damit sie ehrlich bleibt. Es ist eine Messung an einem Produkt, einmal, kein Mittelwert. Die Quellen waren schon gesammelt und lokal indexiert; die Einrichtungszeit steckt nicht darin. Und die Zahl sagt so viel über das Werkzeug wie über die Methode: Dieselbe Arbeit von Hand hätte Wochen gebraucht, was genau der Grund ist, warum sie nie gemacht wurde.

Die Bedingung für Rentabilität ist dagegen klar: einen Bereich fertigstellen, bevor man einen anderen aufmacht. Ein vollständiges Referenzmodell über einen Geltungsbereich nützt sofort allen Funktionen in diesem Bereich. Ein halbfertiges Referenzmodell über fünf Bereiche nützt niemandem.

Die Pflege

Das ist die Frage, die immer als zweite kommt, und sie ist berechtigt: Ein Referenzmodell, zu dem nicht gesagt wird, wie es lebendig bleibt, interessiert niemanden.

Die Referenzversion dient als Marke: Mit einem einzigen Befehl liefert sie die genaue Liste dessen, was sich im Produkt seit der letzten Aktualisierung bewegt hat — also die Liste dessen, was noch festzuhalten ist.

Jede Karte trägt ein Tagebuch, in dem Einträge ergänzt werden, ohne die vorherigen je zu korrigieren. Ein Eintrag, der eine Codeversion nennt, zeigt an, dass sich das Produkt geändert hat. Ein Eintrag ohne Versionsangabe zeigt etwas anderes an: Unser Verständnis hat sich geändert, nicht das Produkt. Die Unterscheidung wirkt nebensächlich; sie erlaubt es, sechs Monate später zu wissen, ob wir eine Karte korrigiert haben oder ob die Software sich weiterentwickelt hat.

Zwei Bewegungen verdienen eine Erwähnung, weil kein Werkzeug sie erzählt: das Verschmelzen zweier Objekte, die wir für getrennt hielten, und das Aufteilen eines Objekts, das zwei verbarg. Das sind die häufigsten Bewegungen, wenn ein Referenzmodell reift.

Und schließlich: Wird ein Objekt von Grund auf neu gedacht, ändern wir nicht seine Karte, sondern legen eine neue an, und die alte bleibt. Sie beschreibt, was das Produkt war, und sie bleibt nötig, um Daten und Vorgänge von vor der Änderung zu deuten.

Was ich entschieden habe, nicht zu tun

• Keine Rekonstruktion der Vergangenheit des Produkts.
• Geltungsbereich geschlossen bei den Datenexporten, die abgeleitete Sichten auf das Produkt sind und nicht das Produkt selbst.
• Kein gelehrtes Werkzeug, solange keine Nutzung es verlangt.

Was die Methode noch nicht sagt

• Wie weit die Strenge des Formats gehen soll. Das hängt von der Nutzung ab, und die Nutzung hat nicht begonnen.
• Wie man ein altes Datum dem richtigen Zustand eines Objekts zuordnet, wenn dieses Objekt zwischenzeitlich neu gedacht wurde.
• Wer eine Karte gegenliest, und nach welchen Kriterien, bevor sie ins Referenzmodell kommt.
• In welchem Rhythmus der Ausgangspunkt aktualisiert wird, und damit alles nachgeholt wird, was sich seither bewegt hat.

Ein Methodendokument, das sich für vollständig ausgibt, lügt. Dieses trägt einen Abschnitt „was es noch nicht sagt“, und der schrumpft, während die Fragen entschieden werden.

Fazit: Das Abbruchkriterium ist die eigentliche Lieferung

Wenn ich aus diesem Vorhaben nur eine Sache behalten müsste, wäre es der Satz, der die drei Fehlstarts erklärt:

Man wählt ein Kriterium, das man erfüllen kann, statt eines, das die geleistete Arbeit beweist.

Er betrifft nicht nur Ontologien. Er gilt für ein Audit, eine Migration, eine Sicherheitsprüfung, den Abbau technischer Schulden. Jedes Mal, wenn eine Arbeit mit „ich habe alles angeschaut“ endet, lautet die Frage: Alles, also was? Hast du die Liste?

Zwei Prüfungen, nie nur eine. Dass die Menge in sich hält, prüft man, indem man die Karten gegeneinander betrachtet. Dass sie vollständig ist, prüft man, indem man das Produkt aufzählt. Beides zu verwechseln hat hier ein Drittel des Produkts gekostet.

Es bleibt das Interessanteste, und es ist nicht getan: die Abweichungen. Alle warten darauf, untersucht zu werden — die Bug-Kandidaten zuerst, dann die, für die es schon eine Kundenanfrage gibt, dann die Lücken, dann die Designschulden. Das ist keine Beschreibung mehr, das ist Produktentscheidung.

Das ist ein anderer Artikel, und er lässt sich erst danach schreiben.

Anhang A — Wie eine Karte aussieht

Dieser Anhang ist der technischste Teil des Artikels; man kann davor aufhören, ohne etwas vom Argument zu verlieren.

Die Karte unten ist auf das fiktive ERP übertragen. Sie beschreibt die Form — die Regeln, die sie steuern, wohnen im Methodendokument, an einer einzigen Stelle.

Was eine Karte enthält

Die Karte selbst

Die Datei trägt den Namen des Objekts — das lässt die Verknüpfungen zwischen den Karten von selbst auflösen.

---
concept: Sales Order
definition: Lieferzusage gegenüber einem Kunden, verfolgt von der Erfassung bis zur Fakturierung.
parent:
enfants: ["[[Rush Order]]", "[[Standing Order]]"]
attributs:
  - nom: status
    type: enum
    valeurs: [draft, confirmed, shipped, invoiced]
relations:
  - verbe: placed-by
    cible: "[[Customer]]"
    cardinalite: 1..1
  - verbe: contains
    cible: "[[Order Line]]"
    cardinalite: 1..n
axiomes:
  - Ein fakturierter Auftrag kann keine Position mehr aufnehmen
lexique:
  fr: [commande, commande client]
  en: [sales order]
  es: [pedido]
  synonymes_terrain: [affaire, dossier]
  deprecies: [bon de commande client]
sources:
  - erp.sql:table `sales_order`
  - fr.json:order.status.draft
ecarts:
  - id: E1
    nature: manque
    portee: relations
    attendu: eine Verknüpfung zu "[[Attachment]]", wie sie "[[Customer]]" hat
    consequence: eine unterschriebene Bestellung kann nicht angehängt werden
    statut: confirme
    date: 2026-08-10
historique:
  - date: 2026-08-10
    action: creation
    motif: erste Beschreibung, auf der Referenzversion
---

# Sales Order

Lieferzusage gegenüber einem Kunden, verfolgt von der Erfassung bis zur Fakturierung.

## Verknüpfungen

- *placed-by* → [[Customer]] (genau einer)
- *contains* → [[Order Line]] (mindestens eine)
- Sonderfälle → [[Rush Order]], [[Standing Order]]

## Historie

| Datum | Was passiert ist | Codeversion | Grund |
|---|---|---|---|
| 2026-08-10 | Anlage | — | erste Beschreibung |

Nur eine Sache steht zweimal: die Verknüpfungen. Einmal im Kopfbereich, damit Werkzeuge sie lesen können; einmal im Rumpf, damit sie in der Netzansicht erscheinen. Alles andere existiert an einer einzigen Stelle.

Drei Qualitätskriterien, die man jeder Karte entgegenhalten kann: Die Definition passt in einen Satz und beißt sich nicht in den Schwanz; jede Verknüpfung ist mit einem präzisen Verb benannt, nie mit „ist verbunden mit“; das Vokabular ist mehrsprachig und trägt die Wörter der Kunden.

Anhang B — Das Raster der Abweichungen

Was man zu jeder Abweichung notiert:

Die fünf Arten:

Was passiert, wenn die Abweichung verschwindet. Man markiert sie als gelöst, und sie bleibt in der Karte. Der Rumpf der Karte wird aktualisiert, um die neue Realität zu beschreiben, und eine Zeile kommt ins Tagebuch. Die beiden antworten einander: Die Abweichungen tragen die Absicht, das Tagebuch trägt die Bewegung.

Ein Schutzgeländer. Eine Abweichung beschreibt eine strukturelle Divergenz, keinen Vorfall. Eine Zeile, ein Link zum Ticket. Die Screenshots, die Reproduktionsschritte und das Detail bleiben im Ticketsystem. Eine Karte ist kein Bugtracker.

Anhang C — Die Blickwinkel der Aufzählung

Alle durchgehen und paarweise gegenüberstellen.

Drei Anwendungsregeln:

1. Das Signal ist die Uneinigkeit zwischen zwei Blickwinkeln, nicht der Wert eines Blickwinkels allein.
2. Jedes nicht zugeordnete Objekt wird ausdrücklich entschieden — Fachobjekt oder Technik. Nie durch Auslassen.
3. Zwei Kundentextmengen, getrennt gezählt: Die Gespräche sagen, was Kunden bauen wollen, die Tickets, was kaputtgeht. Beide Häufigkeiten ins Vokabular tragen — die eine steuert die Roadmap, die andere Dokumentation und Schulung.

Wo die Regeln stecken, nach abnehmendem Ertrag:

1. Die Namen der technischen Fehlermeldungen. In den unordentlichsten Teilen des Codes oft die einzige Quelle — und sie liest sich ohne Programmierkenntnisse.
2. Die Prüfungen am Anfang eines Vorgangs, bevor irgendetwas geändert wird.
3. Die Bedingungen der Datenbank — was eindeutig sein muss, was nicht leer bleiben darf. Sie widersprechen manchmal dem Fach, und diese Abweichung ist ein Defekt.
4. Die Eingabeprüfungen in den Masken — der am häufigsten vergessene Teil, und der, der die interessantesten Abweichungen liefert.

Ein Objekt, das ohne jede Regel beschrieben ist, signalisiert eine oberflächliche Beschreibung, nie ein Fach ohne Regeln.