Ein Agent schreibt ins ERP: wo Lesen endet und Schreiben beginnt

Ein Einkaufsteam fährt einen Pilotversuch. Ein Agent liest offene Bedarfe, Bestände und Lieferzeiten, und drei Wochen lang tut er genau das, was alle gehofft hatten: Er schlägt Bestellungen vor, die Einkäufer prüfen sie, die Einkäufer tippen sie ins ERP. Dann stellt jemand die naheliegende Frage. Warum tippen wir ab, was der Agent schon vorbereitet hat? Gebt ihm Schreibzugriff.

An einem Montagmorgen zeigt das ERP zwei Bestellungen an denselben Lieferanten, gleiche Positionen, zwei Minuten auseinander. An einer hängt die Auftragsbestätigung des Lieferanten. Die andere ist unterhalb des Kopfes leer. Der Konnektor war beim ersten Versuch in einen Timeout gelaufen und hatte es erneut probiert; das ERP hat beide Hälften der Geschichte angenommen. Der Lieferant hat bereits begonnen, gegen eine der beiden zu kommissionieren, und niemand im Raum kann sagen, gegen welche.

An der Überlegung des Agenten war nichts falsch. Gescheitert ist der Schreibvorgang, und am Schreibvorgang scheitert jede Integration seit zwanzig Jahren. Aus einem Erfassungssystem zu lesen ist ein gelöstes und nahezu risikofreies Problem: Ein Lesevorgang lässt sich wiederholen, zwischenspeichern, vergleichen und wegwerfen. Ein Schreibvorgang verändert den Datenbestand, den der Rest des Unternehmens als Wahrheit behandelt, und der Datenbestand hat keine Möglichkeit zu wissen, ob die Änderung einmal oder zweimal gemeint war.

Warum Zurückschreiben ein anderes Problem ist

Lesen ist wiederholbar, Schreiben nicht. Bricht ein Lesevorgang auf halbem Weg ab, liest man noch einmal. Bricht ein Schreibvorgang auf halbem Weg ab, hat man ein Dokument, das zum Teil da ist, und der nächste Versuch dupliziert entweder den Teil, der angekommen ist, oder lässt den Teil aus, der fehlt. Jeder Abstimmungslauf zum Monatsende existiert wegen dieser Asymmetrie.

Ein halber Schreibvorgang ist schlimmer als keiner. Eine Bestellung mit Kopf und ohne Positionen besteht die Prüfung des ERP. Sie belegt aber auch die Nummer beim Lieferanten, erscheint in den offenen Verpflichtungen und wird vom nächsten Bericht aufgegriffen. Der Fehler ist genau dort unsichtbar, wo es darauf ankommt.

In einem Erfassungssystem gibt es kein Rückgängig. Buchhaltungssoftware ist so gebaut, dass nichts gelöscht wird. Eine falsche Buchung wird durch eine Stornobuchung korrigiert, eine falsche Rechnung durch eine Gutschrift. Jede Korrektur ist ein neues Dokument mit eigener Nummer und eigenem Prüfpfad, sodass ein Fehler in Maschinengeschwindigkeit Trümmer in Maschinengeschwindigkeit hinterlässt, die ein Mensch von Hand aufräumen muss.

Ein Timeout macht aus einer Absicht zwei Aktionen. Der Konnektor weiß nicht, ob das System die Anfrage erhalten hat und nur langsam geantwortet hat oder ob sie nie angekommen ist. Ohne eine Möglichkeit zu sagen „das ist dieselbe Anfrage wie vorhin“ zeigen die sichere Wahl und die richtige Wahl in entgegengesetzte Richtungen.

Der Schreibvorgang umgeht die Bedeutung. Das ERP prüft, ob Felder gefüllt sind und Schlüssel existieren. Es weiß nicht, dass dieser Kunde eine in einer Besprechung vereinbarte Kreditsperre hat oder dass dieser Lieferant nur für ein Werk verwendet werden darf. Diese Regeln leben in Menschen, und ein direkter Schreibvorgang läuft geradewegs an ihnen vorbei.

Niemand kann sagen, wer es geschrieben hat. Der Integrationsbenutzer, der die Bestellung angelegt hat, ist ein technisches Konto, das sich jeder Job teilt, der darüber läuft. Die Frage „wer hat das entschieden“ hat im Datenbestand keine Antwort, und genau darum geht es in eine Identität für Menschen und Agenten.

Was es geben muss, bevor ein Agent schreibt

Idempotente Vorschläge. Jede beabsichtigte Änderung trägt eine Kennung, die vor dem ersten Versuch erzeugt wird. Zweimal gesendet muss sie ein Ergebnis liefern, und die empfangende Seite muss „schon erledigt“ sagen können, statt es noch einmal zu tun. Kann das Zielsystem das nicht leisten, muss es die Schicht davor tun: prüfen, bevor sie sendet, und festhalten, was sie gesendet hat.

Ein Freigabeschritt, den ein Mensch verantwortet. Keine Benachrichtigung, eine Entscheidung: der Vorschlag, die Belege dahinter und das Risiko, das er trägt, genehmigt, geändert oder abgelehnt von jemandem, dessen Name in den Datenbestand eingeht. Welche Schreibvorgänge das brauchen, ist keine Geschmacksfrage; es steht pro Aktion schriftlich fest, und Geld, das das Haus verlässt, oder eine eingegangene Verpflichtung stehen immer auf der Liste.

Ein nachspielbares Protokoll. Was der Agent gesehen hat, was er daraus geschlossen hat, was vorgeschlagen wurde, wer es freigegeben hat, was gesendet wurde, was zurückkam. So geschrieben, dass ein Mensch Monate später der Kette folgen kann, und so strukturiert, dass die Kette gegen eine Kopie des Systems nachgespielt werden kann, wenn etwas rekonstruiert werden muss.

Eine Grenze, die die Ontologie ausdrücklich macht. Die Aktionen, die es auf jedem Geschäftsobjekt gibt, die Zustände, die jedes Objekt annehmen darf, die Regeln, die eine Änderung erfüllen muss, und welche Aktionen als kritisch gelten. Ein Agent, der nur in diesen Begriffen handelt, kann nichts schreiben, was das Modell nicht erlaubt, und ein Mensch, der das Modell liest, sieht genau, was der Agent darf.

Abstimmung nach dem Schreiben. Zurücklesen, was angekommen ist, und mit dem vergleichen, was gesendet wurde. Die meisten doppelten Buchungen findet der Lieferant oder der Prüfer; finden sollte sie das System, das sie erzeugt hat, innerhalb von Minuten.

Ein Test, den Sie heute machen können

Nehmen Sie die neueste Integration, die in Ihr ERP oder Ihre Buchhaltung schreibt. Ein Agent muss nicht beteiligt sein; ein Webshop-Konnektor oder ein Tabellen-Upload reicht. Stellen Sie den Leuten, die sie gebaut haben, drei Fragen und schreiben Sie die Antworten auf.

Was passiert, wenn dieselbe Nachricht zweimal ankommt? Was passiert, wenn die Übertragung nach der dritten von sieben Positionen abbricht? Wo ist festgehalten, wer das geschriebene Dokument freigegeben hat, und auf welcher Grundlage?

Wenn Sie eine Testumgebung haben, probieren Sie anschließend die ersten beiden aus und zählen Sie die Korrekturen, die nötig sind, bis der Datenbestand wieder der Wahrheit entspricht.

Lautet eine der Antworten „das würden wir vom Lieferanten erfahren“ oder „das würden wir zum Monatsende sehen“, ist die Integration nicht reif für einen Agenten, egal was der Agent lesen kann. Die Lücke liegt nicht im Modell; sie liegt im Schreibpfad, und es ist dieselbe Lücke für einen Menschen wie für Software.

Hurukan zieht hier seine eigene Grenze. Agenten bereiten vor, entwerfen und schlagen vor, innerhalb schriftlich festgelegter Grenzen, und sie handeln nur in den Begriffen, die die Ontologie definiert. Was an die Buchhaltung geht oder an ein bestehendes System, das parallel weiterläuft, geht erst, nachdem ein Mensch es freigegeben hat, über einen Konnektor, mit Vorschlag, Entscheidung und Ergebnis in einem Protokoll. Kritische Vorgänge warten in jeder Konfiguration auf einen Menschen. Warum man einem Erfassungssystem nicht zutrauen kann, von sich aus zu handeln, steht in ein Erfassungssystem kann nicht handeln; der Schreibpfad ist der Punkt, an dem Hurukan beginnt.