Ein Erfassungssystem kann nicht handeln

Unternehmenssoftware ist seit vierzig Jahren um eine Idee herum gebaut: korrekt festhalten, was das Unternehmen getan hat. Erteilte Aufträge, bewegte Bestände, gestellte Rechnungen, bezahlte Löhne. Der Datenbestand ist maßgeblich, prüfbar und abstimmbar, und enorm viel Ingenieursarbeit ist darin geflossen, ihn vertrauenswürdig zu machen.

Er ist aber auch, strukturell, unfähig, irgendetwas zu tun. Jede Aktion darin entsteht außerhalb – bei einem Menschen, der etwas entschieden und es dem System danach mitgeteilt hat. Das ist keine Lücke in den Produkten. Das ist das Design.

Was aus dem Design folgt

Die Verzögerung ist menschlich. Der Datenbestand ist nur so aktuell, wie oft ihn jemand pflegt. Zwischen den Aktualisierungen ist er ein historisches Dokument, das wie ein aktuelles gelesen wird, und jede Entscheidung, die darauf beruht, beruht auf veralteten Informationen.

Der Durchsatz ist menschlich. Die Organisation kann genau so viele Vorgänge bearbeiten, wie ihre Menschen erfassen können. Mehr Kapazität heißt mehr Personal – deshalb wächst die Verwaltung fast überall mit dem Umsatz.

Das Urteil wird nicht festgehalten. Der Grund für eine Entscheidung steht in einer E-Mail, steckt in einem Gespräch oder im Gedächtnis von jemandem. Das System speichert das Ergebnis und verliert die Begründung – deshalb wird dieselbe Frage jedes Jahr neu verhandelt.

Ausnahmen entwischen. Der dokumentierte Weg deckt den Standardfall ab. Alles andere erledigen erfahrene Menschen über Kanäle, die der Datenbestand nie sieht. Er beschreibt also ein ordentlicheres Unternehmen als das, das tatsächlich existiert.

Was Handeln stattdessen bedeutet

Ein Handlungssystem geht von denselben Daten aus und läuft in die andere Richtung. Der Auftrag wird abgeschlossen, also wird die Rechnung entworfen. Ein Bestand unterschreitet eine Schwelle, also wird die Nachbestellung vorbereitet. Eine Maschine fällt aus, also wird der Plan neu aufgebaut, und die betroffenen Kunden werden ermittelt. Das System erzeugt den nächsten Schritt und fragt, ob es weitergehen soll.

Der Unterschied ist keine Automatisierung im alten Sinn. Regelbasierte Automatisierung gibt es seit Jahrzehnten, und sie scheitert an den Ausnahmen – deshalb blieb sie am Rand. Geändert hat sich die Fähigkeit darunter: Mit superintelligenten Modellen im Hintergrund kann ein System heute eine unstrukturierte E-Mail lesen, eine ungewöhnliche Lage verstehen und einen vernünftigen Entwurf für einen Fall erstellen, für den niemand eine Regel geschrieben hat.

Warum das einen Datenbestand braucht, nicht Integration

Ein handelndes System braucht das ganze Bild. Um eine Rechnung zu entwerfen, braucht es den Auftrag, die Lieferung, die Preisvereinbarung, die Zahlungshistorie des Kunden und die Information, ob eine Reklamation offen ist. Diese Dinge liegen in vier Produkten, und sie im Moment der Entscheidung an einem Ort zusammenzubringen, ist die Arbeit, mit der Integration nie ganz fertig wird.

Deshalb lautet die Antwort: ein Datenbestand statt besserer Konnektoren. Nicht, weil Integration technisch schwierig wäre, sondern weil eine Aktion eine konsistente Sicht zu einem einzigen Zeitpunkt verlangt – und synchronisierte Systeme sind nur in den Pausen zwischen Änderungen konsistent.

Was mitgeliefert werden muss

Ein handelndes System liegt manchmal falsch, und die Kosten eines Fehlers fallen jetzt in Maschinengeschwindigkeit an statt in menschlicher. Die brauchbare Variante kommt deshalb mit drei Dingen, und keines davon ist optional.

Grenzen – was jeder Agent berühren darf und bis zu welchem Betrag. Ein Entscheidungsprotokoll – was er gesehen, geschlossen und getan hat, lesbar für einen Menschen auch Monate später. Und eine Freigabe für alles Unumkehrbare, denn ein falscher Entwurf kostet eine Minute und eine falsche Zahlung erheblich mehr.

Stimmen diese drei, lässt sich die Autonomie verantworten. Fehlen sie, hat man etwas Beeindruckendes gebaut, für das kein Unternehmen geradestehen kann – und das ist dasselbe, wie gar nichts gebaut zu haben.