Wem das System gehört, wenn die Entwickler gehen

Zwei Wochen lang bearbeitete ein Finanzteam die Rechnungen eines neuen Lieferanten von Hand, direkt neben einem System, das genau dafür gebaut worden war. Sechs Monate nach der Übergabe hatte das Unternehmen begonnen, bei einer neuen Art von Lieferanten einzukaufen, deren Rechnungen eine etwas größere Toleranz brauchten. Das Team wusste nicht, ob es die Toleranz ändern durfte, wer die Änderung freigeben musste und woran es merken würde, wenn dabei etwas kaputtging. Also änderte es nichts, und irgendwann rief uns die Finanzleiterin an.

Die Übergabedokumente waren vollständig und korrekt. Nur das eine, worauf es bei Eigentum ankommt, hatten sie nicht übertragen: die Sicherheit und die Befugnis, das System zu ändern, ohne die Entwickler zu fragen.

Nach diesem Anruf haben wir unsere Übergaben umgestellt. Unser Maßstab ist seither schlicht: Wie gut eine Übergabe war, zeigt die kleinste Änderung, an die sich das Team des Kunden nicht herantraut.

Dokumente vermitteln Wissen, keine Befugnis

Ein typisches Übergabepaket beschreibt, wie das System funktioniert: Architektur, Datenflüsse, Runbooks für bekannte Störungen. Es erklärt das Wie. Die Fragen, die sich ein Team stellt, wenn sich das Geschäft verändert, beantwortet es nicht: Dürfen wir das ändern? Wer muss zustimmen? Woran erkennen wir, dass danach noch alles funktioniert? Und was tun wir, wenn nicht?

Ohne Antworten darauf tut ein sorgfältiges Team das vermeintlich Sorgfältige, nämlich nichts. Das System erstarrt in dem Zustand, den es am Tag der Übergabe hatte, während sich das Geschäft weiterentwickelt. Ein erstarrtes System sieht wie ein Erfolg aus, bis es unbemerkt von einer Excel-Tabelle abgelöst wird.

Die Änderungsmatrix regelt die Befugnisse

Im Mittelpunkt der Übergabe steht heute eine Änderungsmatrix: die Arten von Änderungen, die das Geschäft brauchen wird, und für jede, wer sie vornehmen darf und was vorher passieren muss. Sie hat drei Spalten.

Änderungen, die das Team allein vornimmt. Ein Lieferanten-Mapping hinzufügen, eine Toleranz innerhalb einer vom Controller freigegebenen Spanne anpassen, einen Begründungscode ergänzen, eine Routing-Tabelle aktualisieren. Das System prüft die Änderung gegen ihre Grenzen und führt die zugehörigen Abnahmefälle aus. Sind sie bestanden, geht die Änderung live.

Änderungen mit Vier-Augen-Prinzip. Eine neue Abgleichsregel, eine neue Ausnahmeursache, eine Toleranz außerhalb der Spanne, eine neue Freigabeschwelle. Eine Person nimmt die Änderung vor, ein benannter Prüfer gibt sie frei, und vor dem Release läuft der vollständige Abnahmedatensatz.

Änderungen, die eine erneute Qualifizierung erfordern. Eine neue Modellversion, eine neue Belegart, eine neue Gesellschaft oder ein neuer Markt, eine Änderung daran, was ohne Prüfung durchläuft. Dafür gibt es einen Qualifizierungslauf mit schriftlichem Ergebnisvergleich, und der Prozessverantwortliche gibt die Änderung frei.

Die Matrix ist kurz, auf das jeweilige System zugeschnitten und vom Prozessverantwortlichen abgezeichnet. Aus einem diffusen Risikogefühl wird so eine Regel, die jeder nachschlagen kann. Die Toleranz aus jenem Telefonat gehörte in die erste Spalte. Nur hatte das niemand dem Team gesagt.

Jeder änderbare Bestandteil hat einen benannten Verantwortlichen

Was niemandem gehört, lässt sich nicht sicher ändern, weil niemand zustimmen kann. Deshalb hat jeder änderbare Bestandteil einen Verantwortlichen auf Kundenseite: der Abnahmedatensatz, die Schwellenwerte und Toleranzen, die Prompts, die Modellversion, jede Schnittstelle mit ihrem Datenvertrag, die Ausnahmeursachen und Begründungscodes.

Verantwortlich sind Rollen mit einer benannten Person und einer Vertretung. Wechselt jemand die Stelle, wird die Rolle neu besetzt, statt verwaist zurückzubleiben. Am wichtigsten ist die Verantwortung für den Abnahmedatensatz. Er ist das Sicherheitsnetz, mit dem Menschen, die das System nicht gebaut haben, es trotzdem mit gutem Gefühl ändern können. Wer ihn verantwortet, verantwortet damit die Möglichkeit, alles andere zu ändern. Deshalb übergeben wir nie einen Abnahmedatensatz, den nur wir ausführen können. Braucht es dafür unsere Umgebung, unsere Skripte oder unser Wissen, gehört das System nicht wirklich dem Kunden.

Änderungen werden geübt, bevor die Entwickler gehen

Nachzulesen, wie eine Änderung funktioniert, ist etwas anderes, als sie selbst durchgeführt zu haben. In den letzten Wochen jedes Projekts nimmt das Team des Kunden aus jeder Spalte eine echte Änderung vor, während wir danebensitzen und uns zurückhalten: ein Mapping, allein hinzugefügt, eine Regel, mit Prüfer ergänzt, ein Qualifizierungslauf mit einer neuen Kandidatenversion des Modells. Jede Änderung durchläuft den vollständigen Prozess, einschließlich Abnahmelauf und Freigaben.

Solche Übungen decken Lücken einer Übergabe schneller auf als jede Durchsicht. Ein Schritt, der für uns selbstverständlich und für das Team unklar ist. Eine Freigabe, von der niemand wusste, wie man sie erteilt. Ein Test, der im normalen Tagesgeschäft zu lange dauert. Jede Lücke wird geschlossen, solange wir noch vor Ort sind.

Der Support richtet sich nach dem Geschäftskalender

Ein Finanz-Workflow braucht keine Rufbereitschaft rund um die Uhr wie eine öffentliche Website. Er braucht jemanden, der erreichbar ist, wenn der Finanzbereich arbeitet, und zum Monatsende erst recht. Die Übergabe legt fest, wer auf Kundenseite während der Geschäftszeiten als Erster reagiert, was diese Person ohne Eskalation tun darf und wie die Eskalation während des Abschlusses läuft.

Eigentum heißt, ändern zu können

Einem Kunden gehört ein KI-System dann, wenn seine eigenen Leute es so schnell ändern können, wie sich das Geschäft ändert. Die kleinste Änderung, an die sie sich nicht herantrauen, zeigt, wie weit der Weg noch ist.