Wem das System gehört, wenn die Entwickler gehen

Zwei Wochen lang konsolidierte das Reporting-Team einer Private-Equity-Gruppe die Zahlen eines neu übernommenen Unternehmens von Hand, direkt neben dem System, das genau dafür gebaut worden war. Sechs Monate nach der Übergabe brauchten die Konten des neuen Unternehmens ein einziges neues Mapping in die Berichtsebene der Gruppe. Das Team wusste nicht, ob es das Mapping anlegen durfte, wer die Änderung freigeben musste und woran es merken würde, wenn dabei etwas kaputtging. Die Übergabe hatte für die Mappings keinen Verantwortlichen benannt, also änderte das Team nichts, bis die Leiterin des Portfolio-Reportings uns anrief.

Die Übergabedokumente waren vollständig und korrekt. Nicht übertragen hatten sie, was Eigentum in der Praxis braucht: 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 seither: Eine Übergabe ist nur so gut wie die kleinste Änderung, bei der das Team des Kunden zögern würde.

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?

Bei KI-Systemen ist dieses Zögern nachvollziehbar. Sculley und Kollegen bei Google haben den Grund in „Hidden Technical Debt in Machine Learning Systems“ (NeurIPS 2015) benannt: Wer irgendetwas ändert, ändert alles. Eine Zuordnung, ein Prompt oder eine Modellversion kann Ergebnisse in Fällen verschieben, auf die gerade niemand schaut. Ein Team, das die Reichweite einer Änderung nicht sehen kann, zögert zu Recht.

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 kann wie ein Erfolg aussehen, 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 Mapping für die Konten eines Unternehmens 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 Konsolidierungsregel, 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 Art von Quellsystem, 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. Das Mapping aus jenem Telefonat gehörte in die erste Spalte, und die Übergabe hatte das nicht festgehalten.

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 Kontenzuordnungen, 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 der Abnahmedatensatz, denn mit ihm können Menschen, die das System nicht gebaut haben, es trotzdem mit gutem Gefühl ändern. Wer ihn verantwortet, verantwortet damit die Möglichkeit, alles andere zu ändern. Der Datensatz muss also ohne die Entwickler laufen: Braucht er deren Umgebung, deren Skripte oder deren Wissen, gehört das System dem Kunden noch nicht vollständig.

Ä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.

Vor diesen Übungen steht die Inventur der Scheu. Jede verantwortliche Person schreibt für sich auf, welche Änderungen sie nicht vornehmen würde, ohne uns anzurufen. Die Listen sind meist kurz und konkret: der Prompt für das Mapping, die Toleranz für ein schwieriges Portfoliounternehmen, alles, was die Cash-Zahlen berührt. Jeder Punkt landet an einer von zwei Stellen. Entweder er wandert in eine Spalte der Änderungsmatrix, mit einem Verfahren und einem Abnahmelauf dahinter, oder er ist eine Lücke in der Übergabe, und wir schließen sie, bevor wir gehen. In der letzten Woche wiederholen wir die Inventur. Die Übergabe ist fertig, wenn die Listen leer sind oder jeder verbleibende Punkt eine Änderung ist, für die die Matrix ohnehin eine zweite Person verlangt.

Die Übungen fördern Dinge zutage, die eine Durchsicht der Dokumente übersieht. Ein Schritt, der für die Entwickler selbstverständlich war und für das übernehmende Team unklar. Eine Freigabe, von der niemand wusste, wie man sie erteilt. Ein Test, der länger dauerte, als ein normaler Arbeitstag erlaubt. Jede dieser Lücken wird geschlossen, solange die Entwickler noch da sind.

Was am letzten Tag gelten muss

Ein Projekt endet, wenn diese Punkte erfüllt sind, nicht an einem Datum:

• Alle Zugangsdaten, technischen Benutzer und API-Schlüssel gehören dem Kunden und wurden geändert, seit wir Zugriff hatten.
• Prompts, Schwellenwerte, Mappings und Regeln liegen in einem Repository, das dem Kunden gehört, und jede Änderung, aus jeder Spalte der Matrix, ist dort eine kleine, geprüfte Differenz.
• Das Team des Kunden kann den vollständigen Abnahmedatensatz auf eigener Infrastruktur an einem Arbeitstag ausführen.
• Auf Kundenseite ist jemand benannt, der entscheidet, was passiert, wenn der Modellanbieter die eingesetzte Version abkündigt, und diese Person hat bereits einen Qualifizierungslauf durchgeführt.
• Die Inventur der Scheu ist leer, oder jeder verbleibende Punkt gehört ohnehin in die zweite Spalte.

Der Support richtet sich nach dem Geschäftskalender

Ein Reporting-Workflow braucht keine Rufbereitschaft rund um die Uhr wie eine öffentliche Website. Er braucht jemanden, der erreichbar ist, wenn das Reporting-Team arbeitet, und in den Tagen vor der Abgabe eines Board-Pakets 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 in der Reporting-Woche läuft.

Eigentum heißt, ändern zu können

Einem Kunden gehört ein KI-System dann, wenn seine eigenen Leute es im Tempo des Geschäfts ändern können, und in einer Gruppe, die Unternehmen kauft, ändert sich das Geschäft mit jedem Closing. Bevor Sie eine Übergabe abnehmen, fragen Sie jeden Verantwortlichen nach der kleinsten Änderung, die er nicht allein vornehmen würde. Was dabei genannt wird, ist der Weg, der noch fehlt.