Operative Ebene
Ablage ist kein Unternehmensmodell
Atlas OS hält ein zusammenhängendes Modell des Unternehmens aktuell und speist es laufend aus den Systemen, in denen die jeweiligen Informationen entstehen. Das ist etwas anderes als ein Data Warehouse, ein Dashboard oder ein Wiki. Genau dieser Unterschied bestimmt, was ein System verstehen und tun kann.
Atlas OS ist das Fundament, auf dem jeder Einsatz von Atlas läuft. Es verbindet sich mit den Systemen, die ein Unternehmen bereits nutzt, und hält ein Modell dieses Unternehmens: was es gibt, wie es zusammenhängt, in welchem Zustand es ist, was entschieden wurde und was jede Person und jeder Baustein tun darf. Signal, Command und Forge schlussfolgern alle aus demselben Modell.
Die meisten Unternehmen besitzen schon mehr Software, als sie nutzen können. Der Mangel lag nie bei den Systemen. Er liegt darin, dass die Systeme zusammen kein Unternehmen ergeben, also tragen Menschen Informationen zwischen ihnen hin und her und werden selbst zur Integrationsschicht. Atlas OS ist dafür da, diese Schicht stattdessen zu halten.
Drei Dinge, die wie ein Unternehmensmodell aussehen
Ein Data Warehouse bildet Daten ab. Es ist gebaut, um sie zu speichern, umzuformen und auszuwerten, und moderne tun das mit Daten, die Minuten statt eine Nacht alt sind. Der Unterschied, auf den es ankommt, ist also nicht die Geschwindigkeit. Er liegt darin, dass ein Warehouse Zeilen über das Unternehmen hält, während Handeln Bedeutung über das Unternehmen braucht: welches Objekt diese Zeile beschreibt, womit es verbunden ist, wer dafür verantwortlich ist, was das Unternehmen damit erreichen will und was damit getan werden darf.
Ein Dashboard zeigt eine Auswahl. Jemand hat vorab entschieden, welche fünfzehn Zahlen zählen, und diese fünfzehn sieht jeder. Ein Dashboard ist eine Sicht auf ein Modell. Es ist keines.
Ein Wiki beschreibt, wie die Dinge funktionieren sollen. Ein System kann heute Prosa lesen, die Grenze liegt also nicht in der Lesbarkeit. Sie liegt in der Verbindlichkeit: Prosa, die Menschen zu einem bestimmten Zeitpunkt geschrieben haben, ist keine aktuelle, strukturierte, verlässliche Darstellung dessen, was jetzt gerade gilt, und nichts, woraus eine autonome Handlung abgeleitet werden sollte.
Alle drei wurden gebaut, damit ein Mensch sie liest. Ein Modell, auf dessen Grundlage ein System handeln kann, ist etwas anderes. Deshalb ergibt auch der Besitz aller drei noch keines.
Niemand pflegt eine zweite Kopie
Ein Modell, das Menschen aktuell halten müssen, ist ein Wiki mit besserer Formatierung, und es verfällt aus demselben Grund: Sie hören damit in der Woche auf, in der es hektisch wird. Deshalb leitet Atlas OS das Modell stattdessen laufend her. Jede Eigenschaft wird aus dem System gelesen, dem sie gehört, über die Schnittstellen, die dieses System ohnehin anbietet, und Atlas übernimmt das Abgleichen, das Auflösen und das Aktuellhalten. Nichts wird doppelt erfasst.
Das ist nicht dasselbe, wie ein Unternehmen in eine zentrale Datenbank zu kopieren. Zentral ist die Darstellung, nicht die Speicherung: eine zusammenhängende Beschreibung des Unternehmens, zusammengesetzt aus Datensätzen, die bleiben, wo sie sind.
Interessant ist der gewöhnliche Fall, in dem die Systeme sich nicht einig sind. Ein Kunde existiert als Verkaufschance im CRM, als Auftrag im ERP, als Liefertermin, den jemand in einer E-Mail zugesagt hat, und als Rollout im Projektwerkzeug. Vier Datensätze, vier Systeme, ein Unternehmen, und keine zwei beschreiben es gleich. Sie zu einem operativen Objekt aufzulösen ist die eigentliche Arbeit, und das Modell hält fest, woher jede Eigenschaft stammt, wann sie zuletzt gesehen wurde und ob ihr etwas widerspricht. Ein Modell, das einen Widerspruch verbirgt, ist schlechter als vier Systeme, die ihn zeigen, denn meist ist gerade der Widerspruch das, was man wissen sollte.
Manches existiert in gar keinem System. Ziele, Richtlinien, wer wofür verantwortlich ist, wie eine Kennzahl tatsächlich definiert ist: Das legen Menschen einmal fest, und danach wird es gehalten. Und wo etwas fehlt, meldet das Modell die Lücke, statt zu raten. Eine Tatsache, die nur in einem Gespräch vorkommt, ist nicht im Modell, bis sie irgendwo steht, wo ein System sie lesen kann.
Was das Modell halten muss, bevor irgendetwas darauf handeln kann
Handeln braucht mehr als Fakten. Es braucht das Wissen, worauf sich diese Fakten beziehen, wie sie zusammenhängen, was das Unternehmen will und was getan werden darf.
Deshalb hält das Modell die Objekte, also Kunden, Lieferanten, Produkte, Mitarbeitende, Prozesse, Projekte und Systeme, und den Zustand, in dem jedes davon ist. Es hält die Beziehungen zwischen ihnen, denn eine Lieferverzögerung zählt nur über das Projekt, das sie blockiert. Es hält Ziele, Schlüsselergebnisse, Budgets, Zusagen und wer wofür verantwortlich ist, denn ohne sie lässt sich die Bewegung einer Zahl nicht als gut oder schlecht beurteilen. Es hält ein Gedächtnis: was entschieden wurde und warum, was versucht wurde, was funktioniert hat und was schiefging.
Und es hält etwas, das in der Beschreibung eines Unternehmensmodells kaum je vorkommt: was das Unternehmen tatsächlich tun kann. Welche Systeme welche Handlungen anbieten, welche davon ein bestimmter Baustein aufrufen darf, was jede bewirkt und was es kostet, sich dabei zu irren. Zu wissen, was ein Unternehmen ist, erklärt es. Zu wissen, was es tun darf, macht Ausführung erst möglich.
Diese Aufzählung ist auch die Antwort auf die berechtigte Frage, die eine technische Leserin an dieser Stelle stellt: Was hält das, was eine gut integrierte Datenplattform und ein Sprachmodell nicht halten? Suche über Unternehmensdaten liefert flüssige Antworten über die Vergangenheit. Sie trägt weder die Beziehungen als eigenständige Objekte noch die Ziele, an denen eine Zahl gemessen wird, noch das Protokoll dessen, was schon entschieden wurde, noch die Verantwortlichkeiten, die Berechtigungen oder die verfügbaren Handlungen und ihre Wirkung. Das ist kein Kontext, den man sich erprompten kann. Es ist ein Modell, das jemand bauen muss.
Das Gedächtnis verdient einen eigenen Satz, denn es ist der Teil, den fast jedes Automatisierungsprojekt weglässt. Hier trainiert sich nichts selbst um: Gedächtnis heißt, dass Entscheidungen, Handlungen, Ergebnisse und Vorlieben aufbewahrt und der nächsten Schlussfolgerung zur Verfügung gestellt werden. Ein Unternehmen, das einen Prozess vierhundertmal durchlaufen hat, weiß Dinge darüber, die nirgends stehen, und ein System, das jedes Mal bei null anfängt, macht nächste Woche denselben Fehler, mit voller Überzeugung.
Jedes System beschreibt dasselbe Unternehmen, und keines von ihnen weiß es.
Berechtigung ist Teil des Modells, keine Hülle darum
Jeder Einsatz enthält die Vertrauensebene, in jeder Konfiguration, und sie ist kein Modul, das auf dem Modell sitzt.
Wem etwas gehört, wer es sehen darf, wer es freigeben darf, welche Handlungen eine Eskalation brauchen und unter welchen Bedingungen ein Baustein allein handeln darf, hält das Modell selbst, genauso wie ein Objekt oder eine Beziehung. Das ist Absicht, denn diese Fakten schränken die Schlussfolgerung nicht nur ein, sie sind ein Teil von ihr: Eine Empfehlung, die übergeht, wer sie ausführen darf, ist keine bessere Empfehlung, sondern eine falsche. Daneben läuft die Einsehbarkeit, damit ein Mensch sieht, was geschieht, warum, und wo eine menschliche Entscheidung nötig ist.
Atlas hat erwogen, Sicherheit und Governance zu einem eigenen Produkt zu machen, und sich dagegen entschieden. Alles, was einzeln verkauft wird, muss etwas sein, das ein Kunde allein kaufen und vollständig erhalten kann, und Sicherheit fällt in umgekehrter Richtung durch diesen Test: Einzeln verkauft wird sie zu etwas, das ein Kunde ablehnen kann, und ein System, das sich ohne seine eigenen Kontrollen einsetzen lässt, sollte niemand einsetzen.
Das Fundament ist enthalten, nie zuerst verkauft
Atlas OS ist kein viertes Produkt neben Signal, Command und Forge. Es ist die eine Plattform darunter, und jeder Einsatz enthält die Fähigkeiten von Atlas OS, die er braucht.
Das ist die kommerzielle Folge der Architektur und keine Paketierungsentscheidung. Signal kann ohne den Kontext des Unternehmens nicht beurteilen, welches Unternehmen relevant ist, Command kann keine Zahlen bewerten, die es nicht erreicht, und Forge kann nicht herleiten, wie ein Auftrag erledigt wird, ohne zu wissen, was das Unternehmen tut. Die Alternative wäre gewesen, zuerst die Plattform und danach den Baustein zu verkaufen. Das ist der klassische Weg, und er endet bekanntermaßen so: ein langes Grundlagenprojekt, eine Rechnung und ein Jahr lang nichts, worauf das Geschäft zeigen könnte. Atlas verkauft den Baustein und liefert das Fundament mit, das er braucht.
Der Einwand, den man ernst nehmen sollte
Das klingt nach einem Integrationsprojekt, und Integrationsprojekte haben sich ihren Ruf ehrlich verdient. Mehrjährige Zeitpläne, ein Datenmodell, das außerhalb des Projekts niemand versteht, und ein Geschäft, das seine Gestalt längst geändert hat, wenn alles live geht.
Ein Teil davon stimmt, und die ehrliche Fassung ist wichtig. Atlas OS entsteht nicht, indem man ein Unternehmen vollständig modelliert, bevor irgendetwas läuft. Es entsteht Anbindung für Anbindung, und jede Anbindung muss etwas zum Laufen bringen, das vorher nicht lief. Ein Unternehmen, das zuerst auf dem vollständigen Modell besteht, hat den Fehlschlag gewählt, statt ihn zu vermeiden.
Richtig bleibt: Das Modell hat einen Boden. Ein gewisser Kontext muss vorhanden sein, bevor ein autonomes System überhaupt handeln darf, und dieser Boden liegt höher, als ein Workflow-Werkzeug ihn braucht. Atlas behauptet nichts anderes, denn ein System, das mit voller Überzeugung auf einem unvollständigen Bild handelt, ist schlechter als eines, das gar nichts tut.
Was möglich wird
Jedes an das Modell angebundene System macht den Rest des Unternehmens präziser, und die Wirkung vervielfacht sich, statt sich nur zu addieren. Einkaufsdaten allein beantworten Einkaufsfragen. Einkaufsdaten neben Projektstand, Liquidität und Lieferantenhistorie beantworten Fragen, für die es bisher drei Menschen und eine Woche brauchte.
Deshalb wird das Fundament als Teil des Produkts behandelt und nicht als bloße Infrastruktur. Was ein Unternehmen wahrnehmen, beurteilen und ausführen kann, ist dadurch begrenzt, wie viel von sich selbst es für ein System lesbar gemacht hat. Atlas OS ist der Ort, an dem diese Lesbarkeit gehalten wird, und alles darüber ist durch ihre Qualität begrenzt.
Das Produkt dazu
Die Plattform, um die es in diesem Beitrag geht: die Architektur, ein Kunde, aufgelöst aus vier Systemen, und wo die Grenzen liegen.