Ich beschrieb ein fremdes System aus dem Bauch heraus. Alles passte, außer der Wahrheit

Ich schrieb den Weg eines Dokuments durch ein Bürosystem auf — Anfrage, Angebot, Vertrag, Rechnung — und kam an die Stelle, an der der Prozess bricht: Dubletten im Kundenstamm. Derselbe Kunde dreimal, in jeder Kopie ein Teil der Historie.

Die Ursache schrieb ich aus dem Stand hin, weil sie naheliegend schien: Die Suche verlangt den genauen Namen, und bei einem Kunden in der Leitung ist es schneller, einen neuen Datensatz anzulegen, als den alten zu finden. Der Satz klang gut. Jeder, der je in einem Büro gearbeitet hat, hätte genickt.

Er war falsch.

Was die Prüfung ergab

Ich zeigte den Text einer Person, die fünf Jahre in diesem System gearbeitet hatte. Die Antwort drehte den Absatz um 180 Grad.

Die Suche war gut. Sie suchte nach Name, nach Kundennummer und nach dem Kennzeichen des Fahrzeugs — nach jedem beliebigen Bruchstück, mit einer Vorschlagsliste während der Eingabe. Im Büro suchte man meist nach dem Kennzeichen, weil es das Einzige ist, was ein Kunde am Tresen immer bei sich hat.

Die Dubletten entstanden trotzdem, denn gebrochen war eine ganz andere Stelle: Beim Anlegen eines Kunden prüfte das Programm nichts. Man konnte zehn Datensätze mit identischem Namen und identischer Adresse anlegen. Unterscheiden ließen sie sich nur durch die fortlaufende Kundennummer.

Sichtbar wird das erst später, in den Suchergebnissen — zwei oder drei nicht unterscheidbare Einträge. Um zu entscheiden, welcher „der richtige" ist, muss man jeden öffnen und nachsehen, an welchem die Aufträge und Rechnungen hängen. Zusammenführen konnte man nicht, also erfanden die Nutzer ihre eigene Umgehung: Beim aufgegebenen Datensatz wurde eine Notiz ergänzt, „inaktiv, siehe Kundennummer …".

Zwei Funktionen, die nichts miteinander zu tun haben

Das ist der Kern, nicht der Irrtum selbst.

„Man findet gut" und „man kann keine Dublette anlegen" sind zwei getrennte Funktionen des Systems. Nichts verbindet sie — weder der Code noch die Maske noch der Zeitpunkt der Arbeit. Die erste wirkt beim Lesen, die zweite beim Schreiben. Ein System kann die eine vollständig haben und die andere gar nicht.

Meine falsche Beschreibung verschmolz sie zu einem einzigen Mechanismus, weil der gesunde Menschenverstand es so nahelegt: Wenn es Dubletten gibt, war das Original wohl schwer zu finden. Die Überlegung ist vernünftig und führt an den falschen Ort.

Bei der Abnahme einer Einführung wird fast immer die erste getestet. Man tippt ein Namensfragment, sieht die Vorschläge, nickt. Die Frage nach der zweiten wird selten gestellt, und sie lautet:

Was passiert, wenn ich einen zweiten Kunden mit genau denselben Daten anlege?

Die Antwort ist manchmal Stille und ein neuer Datensatz. Ein Jahr Bereinigung des Kundenstamms kostet ein Vielfaches einer einzigen Warnung im Moment des Speicherns.

Warum ich es nicht selbst bemerkte

Weil in der falschen Version nichts zu bemerken war.

Man vergleiche die beiden Sätze:

Dubletten entstanden, weil die Suche den genauen Namen verlangte und es daher schneller war, einen neuen Kunden anzulegen, als den alten zu finden.
Dubletten entstanden, weil das System beim Anlegen eines Kunden nicht prüfte, ob es ihn schon gab.

Beide haben einen vernünftigen Mechanismus. Beide enden im selben Ergebnis. Beide klingen wie eine Erinnerung aus dem Büro, nicht wie Theorie. Beim Lesen lässt sich nicht zeigen, welcher erfunden ist — denn das Erfundene enthält keinen Fehler, es enthält Plausibilität.

Der Unterschied ist genau einer und lässt sich erst erkennen, wenn man die wahre Version kennt: Die wahre enthält ein Detail, das der Leser nie selbst erfinden würde. Dass ein System mit guter Suche über drei verschiedene Felder gar keine Prüfung beim Speichern haben kann. So etwas errät man nicht, weil es nicht logisch ist — und Bürosysteme wachsen über Jahre und sind nicht verpflichtet, logisch zu sein.

Was ich NICHT getan habe

Ich bin nicht zur Suche zurückgekehrt, um sie „trotzdem zu erwähnen". Es war verlockend, denn der Absatz war geschrieben, las sich ordentlich, und es war schade, ihn zu löschen — man hätte ihn als zweite, nebensächliche Ursache stehen lassen können.

Das wäre schlimmer gewesen als der Fehler selbst. Der Satz „und nebenbei war die Suche mitunter umständlich" ist genau dieselbe Unwahrheit, nur im Hintergrund versteckt, wo sie keiner prüft. Der Absatz ging vollständig in den Papierkorb.

Ich habe dem Text auch keinen Hinweis „diese Beschreibung kann ungenau sein" hinzugefügt. Ein Unsicherheitsvermerk hat Sinn, wenn sich wirklich nicht prüfen lässt. Hier ging es — es genügte, zu fragen. Der Hinweis hätte nur die Kosten der Prüfung auf den Leser abgewälzt, der dafür schlechtere Werkzeuge hat als ich.

Die Schlussfolgerung, die ich weiternehme

Prozessdokumentation, die „aus dem gesunden Menschenverstand" geschrieben wird, enthält keinen sichtbaren Fehler. Sie enthält eine glatte Unwahrheit. In ihr gibt es keine Stelle, die knirschen würde — deshalb besteht sie jedes Korrekturlesen, jedes Vorlesen und jedes „klingt vernünftig".

Das Einzige, was sie aufdeckt, ist jemand, der dabei war. Kein Gutachter, kein zweites Augenpaar, kein Sprachmodell — ein Zeuge. Seit ich das gesehen habe, teile ich jeden Absatz über ein fremdes System in zwei Kategorien: was ich gesehen habe oder belegen kann, und was ich ergänzt habe, weil es passte. Die zweite Kategorie ist nicht schlecht. Sie muss nur zur Prüfung hinaus, bevor jemand sie als Tatsache liest.

Nicht zu verwechseln mit dem Fall, dass eine Messung misslang oder von einem anderen Tag stammte. Hier gab es gar keine Messung — es gab eine plausible Hypothese in der Rolle einer Tatsache. Das ist der am schwersten zu fassende Fall, weil es nichts gibt, was man womit vergleichen könnte.