Ihr Unternehmen hat schon eine Ontologie. Sie steckt in den Köpfen

Eine neue Vertriebskoordinatorin fängt im Unternehmen an. In ihrer ersten Woche lernt sie, dass „aktiver Kunde“ drei verschiedene Dinge bedeutet. Im Vertrieb ist es jeder, der kürzlich bestellt hat. In den Finanzen jeder mit einem offenen Kreditlimit. In der Logistik jeder mit einer verifizierten Lieferadresse. Niemand liegt falsch; jedes Team braucht seine eigene Bedeutung für seine eigene Arbeit.

Sie lernt auch, dass ein Eilauftrag die Produktionsreihenfolge nur überspringen darf, wenn der Account-Verantwortliche zustimmt, dass eine bestimmte Kundengruppe nie eine Teillieferung erhalten darf und dass die Muttergesellschaft im System nicht diejenige ist, die bezahlt. Nichts davon steht in der Software. Es steckt in den Köpfen von drei erfahrenen Kollegen und in einem Tabellenblatt namens „nicht löschen“.

Das ist eine Ontologie: eine Beschreibung dessen, was es im Geschäft gibt, wie diese Dinge zusammenhängen und welche Regeln für sie gelten. Das Wort klingt akademisch. Die Sache ist alltäglich, und jedes Unternehmen hat eine. Das Problem ist, dass sie implizit ist – von Menschen getragen, durch Einarbeitung weitergegeben und nur teilweise in Feldnamen und Tabellenformeln festgehalten. Software speichert Felder. Menschen halten die Bedeutung.

Jahrelang war das erträglich, weil die Menschen, die die Arbeit machen, die Bedeutung über Monate aufnehmen konnten. Ein Agent kann das nicht. Er kann nur dem folgen, was aufgeschrieben ist. Bitten Sie einen Agenten, die Lieferungen dieser Woche vorzubereiten, und er schickt fröhlich eine Teillieferung an genau den Kunden, von dem alle wissen, dass er nie eine bekommen darf.

Wo sich die verborgene Ontologie zeigt

Wörter, die mehreres bedeuten. Aktiv, Kunde, geliefert, abgeschlossen, erledigt. Jedes Team nutzt dasselbe Wort für einen anderen Zustand, und jeder teamübergreifende Bericht vermischt sie unbemerkt.

Regeln als Reflexe. „Für einen Neukunden bieten wir nie unter Selbstkosten an, außer wenn …“ Die Ausnahme ist echt und wichtig, und sie existiert nur als Gewohnheit der Person, die meist die Angebote vorbereitet.

Beziehungen, die niemand modelliert hat. Die Gruppe, der der Kunde gehört, der Standort, der bestellt, die Adresse, die die Ware erhält, und die Gesellschaft, die bezahlt, sind vier verschiedene Dinge. Das System hat einen Kundendatensatz mit einem Notizfeld.

Ausnahmen als Folklore. Die Liste der Sonderfälle führen die dienstältesten Mitarbeitenden, und weitergegeben wird sie im Gespräch. Sind sie im Urlaub, werden die Ausnahmen falsch behandelt.

Tabellen als Schattenschema. Zusätzliche Spalten entstehen überall dort, wo das System keinen Platz für eine Tatsache hatte, die das Geschäft brauchte. Jede davon ist ein Stück des Modells, das außerhalb des Modells gewachsen ist.

Wie man sie aufschreibt, ohne ein Zwei-Jahres-Projekt

Beginnen Sie nicht mit einem Workshop zur Taxonomie. Beginnen Sie mit Entscheidungen, denn in Entscheidungen wird die Bedeutung angewandt.

Einen Prozess wählen und seine Entscheidungen sammeln. Fragen Sie zu jeder Entscheidung die Person, die sie trifft, drei Dinge: Worauf haben Sie geschaut, welche Regel haben Sie angewandt, und was hätte Sie anders entscheiden lassen?

Die Objekte und Beziehungen benennen, die die Entscheidungen nutzen. Kunde, Standort, Auftrag, Lieferung, Kreditlimit. Schreiben Sie dann die Beziehungen schlicht auf: Eine Lieferung gehört zu einem Auftrag, geht an einen Standort und wird einer Gesellschaft in Rechnung gestellt.

Die Regeln neben die Objekte schreiben, für die sie gelten, jeweils mit einem Verantwortlichen und einer Begründung, damit die Regel später auch von jemandem hinterfragt werden kann, der nicht im Raum war.

Unterschiede offenlegen, statt sie mit Gewalt aufzulösen. Verstehen Finanzen und Vertrieb unter „aktiv“ Verschiedenes, behalten Sie beides unter verschiedenen Namen. Das Ziel ist eine Bedeutung je Wort, nicht ein Wort für das ganze Unternehmen. Dieselbe Disziplin, angewandt auf Kennzahlen, beschreibt eine Definition von Umsatz.

Sie aus der Nutzung wachsen lassen. Fragen Sie jedes Mal, wenn eine Ausnahme behandelt wird, ob sie in Wahrheit eine neue Regel ist. Wenn ja, kommt sie mit ihrem Verantwortlichen ins Modell.

Das ist die Aufgabe der Ebene Ontologie in Hurukan: ein beschriebenes, versioniertes Modell aus Objekten, Beziehungen und Regeln, das jedes Modul und jeder Agent liest. Es ist darauf ausgelegt, sich selbst weiterzuentwickeln, während das System erweitert wird: Ein Agent schlägt ein neues Objekt oder eine neue Regel vor, ein Mensch gibt sie frei, und die Änderung wird festgehalten. Weil sich das Unternehmen ständig ändert, muss sich auch das Modell sicher ändern lassen – darum geht es in wenn sich das Unternehmen ändert, muss sich die Ontologie mitändern.

Ein Test, den Sie heute machen können

Nehmen Sie drei Wörter, die Ihr Unternehmen jeden Tag verwendet. „Kunde“, „Auftrag“ und „erledigt“ eignen sich gut. Bitten Sie je eine Person aus Vertrieb, Finanzen und Betrieb, jedes davon in einem einzigen Satz zu definieren – getrennt, schriftlich und ohne Absprache.

Legen Sie die neun Sätze nebeneinander. Jeder Unterschied ist ein Stück Ihrer Ontologie, das in jemandes Kopf steckt.

Setzen Sie sich dann eine halbe Stunde mit der erfahrensten Person eines Teams zusammen und stellen Sie eine einzige Frage: Was wissen Sie, was das System nicht weiß? Schreiben Sie alles auf, was sie sagt. Diese Liste ist der erste Entwurf des Modells Ihres Unternehmens, und sie ist genauer als die meisten Spezifikationen, die für ein neues System geschrieben werden. Steht sie erst auf Papier, kann sie zu etwas werden, das Software und Agenten lesen können – und genau dort setzt Hurukan an.