Wem das System gehört, wenn die Entwickler gehen

Zwei Wochen lang führte das Reporting-Team einer Private-Equity-Gruppe die Zahlen eines neu gekauften Unternehmens von Hand in die Gruppenberichte zusammen, neben dem System, das genau dafür gebaut war. Sechs Monate nach der Übergabe brauchten die Konten des neuen Unternehmens eine neue Zuordnung: eine Regel, welches seiner Konten in welche Zeile der Gruppenberichte fließt. Das Team war unsicher, ob es sie anlegen durfte, wer sie freigeben sollte und woran es merken würde, wenn es etwas kaputt gemacht hätte. Die Übergabe hatte für die Zuordnungen keinen Verantwortlichen benannt, also änderte das Team nichts, bis der Leiter des Portfolio-Reportings uns anrief.

Die Übergabedokumente waren vollständig und korrekt. Was Eigentum in der Praxis braucht, gaben sie nicht weiter: die Sicherheit und die Befugnis, das System zu ändern, ohne die zu fragen, die es gebaut haben.

Nach diesem Anruf haben wir unsere Übergaben geändert. Unser Maßstab heute: Eine Übergabe ist nur so gut wie die kleinste Änderung, vor der das Team des Kunden zögern würde.

Dokumente geben Wissen weiter, keine Befugnis

Ein typisches Übergabepaket beschreibt, wie das System funktioniert: seinen Aufbau, wie Daten fließen, Schritt-für-Schritt-Anleitungen für bekannte Störungen. Es beantwortet nicht die Fragen, die ein Team stellt, wenn sich das Geschäft ändert: Dürfen wir das ändern, wer muss zustimmen, woran sehen wir, dass es noch funktioniert, und was tun wir, wenn nicht?

Bei KI-Systemen ist dieses Zögern vernünftig. Sculley und Kollegen bei Google benannten den Grund in „Hidden Technical Debt in Machine Learning Systems“ (NeurIPS 2015): Wer irgendetwas ändert, ändert alles. Eine Zuordnung, eine KI-Anweisung oder eine Modellversion kann Ergebnisse in Fällen verschieben, auf die niemand geachtet hat. Ein Team, das nicht sieht, wie weit eine Änderung reicht, zögert zu Recht.

Ohne diese Antworten tut ein sorgfältiges Team das Sorgfältige, nämlich nichts. Das System erstarrt im Zustand des Übergabetags, während das Geschäft weiterläuft. Ein erstarrtes System kann wie ein Erfolg aussehen, bis es still durch eine Tabellenkalkulation ersetzt wird.

Die Änderungstabelle macht Befugnis ausdrücklich

Kern der Übergabe ist heute eine Änderungstabelle: die Arten von Änderungen, die das Geschäft brauchen wird, und für jede, wer sie machen darf und was vorher geschehen muss. Sie hat drei Spalten.

Änderungen, die das Team allein macht. Eine Zuordnung für die Konten einer Gesellschaft hinzufügen, eine zulässige Abweichung innerhalb einer Spanne anpassen, die das Controlling freigegeben hat, einen Begründungscode ergänzen, eine Weiterleitungstabelle aktualisieren. Das System prüft die Änderung gegen seine Grenzen und lässt die passenden Testfälle laufen; bestehen sie, geht sie live.

Änderungen, die eine zweite Person brauchen. Eine neue Regel für das Zusammenführen der Gruppenzahlen, eine neue Ausnahmeursache, eine Abweichung außerhalb der Spanne, eine neue Freigabegrenze. Eine Person macht sie, ein benannter Prüfer gibt sie frei, und vor dem Release laufen alle Testfälle.

Änderungen, die einen vollen Neutest brauchen. Eine neue Modellversion, eine neue Dokumentart, eine neue Art von Quellsystem, eine Änderung daran, was ohne Prüfung durchläuft. Sie bekommen einen Testlauf mit schriftlichem Ergebnisvergleich, und der Prozessverantwortliche gibt frei.

Die Tabelle ist kurz, auf das System zugeschnitten und vom Prozessverantwortlichen unterschrieben. Sie macht aus einem vagen Risikogefühl eine Regel, die jeder nachschlagen kann. Die Zuordnung aus jenem Anruf gehörte in die erste Spalte, und die Übergabe hatte das nicht gesagt.

Jeder änderbare Teil hat einen benannten Verantwortlichen

Einen Teil, der niemandem gehört, kann man nicht sicher ändern, weil niemand Ja sagen kann. Deshalb hat jeder änderbare Teil einen Verantwortlichen auf Kundenseite: den Abnahmedatensatz (die echten Fälle mit bekannten richtigen Antworten, gegen die jede Änderung getestet wird), die Grenzwerte und Kontenzuordnungen, die KI-Anweisungen, die Modellversion, jede Verbindung zu einem anderen System samt Datenvereinbarung, die Ausnahmeursachen und Begründungscodes.

Verantwortliche sind Rollen mit einer benannten Person und einer Vertretung, sodass ein Jobwechsel die Rolle neu besetzt, statt sie verwaisen zu lassen. Am wichtigsten ist der Abnahmedatensatz, denn er lässt Menschen, die das System nicht gebaut haben, es mit Sicherheit ändern. Wem er gehört, dem gehört die Fähigkeit, alles andere zu ändern. Deshalb muss er ohne die Entwickler laufen: Braucht er ihre Umgebung, ihre Skripte oder ihr Wissen, gehört das System dem Kunden noch nicht ganz.

Änderungen werden geprobt, bevor die Entwickler gehen

Zu lesen, wie man eine Änderung macht, ist nicht dasselbe, wie eine gemacht zu haben. In den letzten Wochen jedes Auftrags macht das Team des Kunden aus jeder Spalte eine echte Änderung, während wir zusehen und schweigen: eine Zuordnung allein, eine Regel mit Prüfer, einen vollen Neutest mit einer Kandidaten-Modellversion. Jede durchläuft den ganzen Prozess, Freigaben eingeschlossen.

Vor den Proben steht die Angstinventur. Jeder Verantwortliche schreibt für sich auf, welche Änderungen er nicht ohne Anruf bei uns machen würde. Die Listen sind meist kurz und konkret: die KI-Anweisung für Zuordnungen, die Abweichung für eine schwierige Portfoliogesellschaft, alles, was die Cash-Zahlen berührt. Jeder Punkt wandert entweder in eine Spalte der Tabelle, mit Verfahren und Testlauf dahinter, oder er ist eine Lücke in der Übergabe, die wir schließen, bevor wir gehen. Die Inventur wird in der letzten Woche wiederholt. Die Übergabe ist fertig, wenn die Listen leer sind oder jeder verbleibende Punkt eine Änderung ist, die laut Tabelle ohnehin eine zweite Person braucht.

Die Proben bringen ans Licht, was eine Dokumentenprüfung übersieht: einen Schritt, der den Entwicklern klar und den Übernehmenden unklar war, eine Freigabe, die niemand zu erteilen wusste, einen Test, der länger dauerte als ein Arbeitstag erlaubt. Jedes davon wird behoben, solange die Entwickler noch da sind.

Was am letzten Tag gelten muss

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

• Jeder Login, jedes Systemkonto und jeder Zugriffsschlüssel gehört dem Kunden und wurde geändert, seit wir Zugriff hatten.
• KI-Anweisungen, Grenzwerte, Zuordnungen und Regeln liegen in einem versionierten Speicher, der dem Kunden gehört, und jede Änderung, aus jeder Spalte der Tabelle, ist dort eine kleine geprüfte Bearbeitung.
• Das Team des Kunden kann alle Testfälle auf eigenen Systemen innerhalb eines Arbeitstags laufen lassen.
• Auf Kundenseite ist jemand benannt, der entscheidet, was passiert, wenn der Modellanbieter die genutzte Version abschaltet, und der schon einen vollen Neutest gemacht hat.
• Die Angstinventur ist leer, oder jeder verbleibende Punkt gehört ohnehin in die zweite Spalte.

Support folgt dem Geschäftskalender

Ein Reporting-Workflow braucht nicht die Rund-um-die-Uhr-Bereitschaft einer öffentlichen Website. Er braucht jemanden, der verfügbar ist, wenn das Reporting-Team arbeitet, und mehr noch in den Tagen vor einer Vorstandsvorlage. Die Übergabe benennt die erste Ansprechperson auf Kundenseite während der Geschäftszeiten, was sie ohne Eskalation tun darf, und den Eskalationsweg in der Reporting-Woche.

Eigentum ist die Fähigkeit zu ändern

Einem Kunden gehört ein KI-System, 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 abgeschlossenen Kauf. Bevor Sie eine Übergabe abzeichnen, fragen Sie jeden Verantwortlichen nach der kleinsten Änderung, die er nicht allein machen würde. Was er nennt, ist die Strecke, die noch fehlt.