Eigenaarschap begint als de bouwers vertrekken

Twee weken lang consolideerde het rapportageteam van een private-equitygroep de cijfers van een pas overgenomen bedrijf met de hand, naast het systeem dat daarvoor was gebouwd. Zes maanden na de overdracht hadden de rekeningen van het nieuwe bedrijf één nieuwe mapping nodig naar de rapportagelaag van de groep. Het team wist niet zeker of het die mocht toevoegen, wie de wijziging moest goedkeuren en hoe het zou merken of er daarna iets stuk was. De overdracht had geen eigenaar voor de mappings benoemd, dus veranderde het team niets, tot het hoofd portfoliorapportage ons belde.

De overdrachtsdocumentatie was compleet en klopte. Alleen droeg ze niet over wat eigenaarschap in de praktijk nodig heeft: het vertrouwen en de bevoegdheid om het systeem aan te passen zonder toestemming te vragen aan de mensen die het bouwden.

Na dat telefoontje hebben we onze manier van overdragen veranderd. De maatstaf die we nu hanteren: een overdracht is zo goed als de kleinste wijziging waarover het team van de klant zou aarzelen.

Documentatie draagt kennis over, geen bevoegdheid

Een gangbaar overdrachtspakket beschrijft hoe het systeem werkt: architectuur, datastromen, runbooks voor bekende storingen. Het beantwoordt de vraag hoe iets werkt. Het beantwoordt niet de vragen die een team stelt als het bedrijf verandert: mogen we dit aanpassen, wie moet akkoord geven, hoe weten we dat het daarna nog werkt en wat doen we als dat niet zo is?

Bij AI-systemen is die aarzeling terecht. Sculley en collega's bij Google gaven de reden in "Hidden Technical Debt in Machine Learning Systems" (NeurIPS 2015): wie iets verandert, verandert alles. Een mapping, een prompt of een nieuwe versie van het model kan resultaten verschuiven in gevallen waar niemand naar kijkt. Een team dat de reikwijdte van een wijziging niet kan zien, aarzelt met reden.

Zonder die antwoorden doet een zorgvuldig team wat zorgvuldig lijkt: niets. Het systeem blijft steken in de vorm die het had op de dag van de overdracht, terwijl het bedrijf verder verandert. Zo'n systeem kan op een succes lijken, tot het ongemerkt door een spreadsheet wordt vervangen.

De wijzigingsmatrix legt de bevoegdheden vast

De kern van onze overdracht is nu een wijzigingsmatrix: de soorten wijzigingen die het bedrijf nodig zal hebben, en per soort wie de wijziging mag doorvoeren en wat daarvoor eerst moet gebeuren. De matrix heeft drie kolommen.

Wijzigingen die het team zelfstandig doorvoert. Een mapping voor de rekeningen van een bedrijf toevoegen, een tolerantie aanpassen binnen een bandbreedte die de controller heeft goedgekeurd, een redencode toevoegen, een routeringstabel bijwerken. Het systeem toetst de wijziging aan de afgesproken grenzen en draait de relevante acceptatiegevallen. Slagen die, dan gaat de wijziging live.

Wijzigingen waarvoor een tweede persoon nodig is. Een nieuwe consolidatieregel, een nieuwe uitzonderingsoorzaak, een tolerantie buiten de bandbreedte, een nieuwe goedkeuringsdrempel. Eén persoon voert de wijziging uit, een aangewezen reviewer keurt haar goed en de volledige acceptatieset draait voor de release.

Wijzigingen die herkwalificatie vragen. Een nieuwe versie van het model, een nieuw documenttype, een nieuw soort bronsysteem, een wijziging in wat zonder tussenkomst wordt verwerkt. Die doorlopen een kwalificatierun met een schriftelijke vergelijking van de resultaten, en de proceseigenaar tekent af.

De matrix is kort, geldt specifiek voor dit systeem en is ondertekend door de proceseigenaar. Een vaag gevoel van risico wordt zo een regel die iedereen kan opzoeken. De mapping uit dat telefoontje hoorde in de eerste kolom, en de overdracht had dat niet vastgelegd.

Elk aanpasbaar onderdeel heeft een aangewezen eigenaar

Een onderdeel zonder eigenaar is niet veilig aan te passen, want niemand kan er ja tegen zeggen. Elk aanpasbaar onderdeel heeft daarom een eigenaar aan de kant van de klant: de acceptatieset, de drempels en rekeningmappings, de prompts, de versie van het model, elke koppeling met het bijbehorende datacontract, de uitzonderingsoorzaken en de redencodes.

Eigenaarschap is belegd bij een rol, met een aangewezen persoon en een vervanger, zodat bij een functiewissel de rol opnieuw wordt toegewezen en niet onbeheerd achterblijft. Het zwaarst weegt de acceptatieset, want daarmee kunnen mensen die het systeem niet hebben gebouwd, het toch met vertrouwen aanpassen. Wie eigenaar is van de acceptatieset, kan al het andere veilig veranderen. De set moet dus draaien zonder de bouwers: is daarvoor hun omgeving, hun scripts of hun kennis nodig, dan is de klant nog niet volledig eigenaar van het systeem.

Wijzigingen worden geoefend voordat de bouwers vertrekken

Lezen hoe een wijziging werkt, is iets anders dan er zelf een hebben doorgevoerd. In de laatste weken van elke opdracht voert het team van de klant uit elke kolom een echte wijziging door, terwijl wij toekijken en ons erbuiten houden: zelfstandig een mapping toevoegen, met een reviewer een regel toevoegen, een kwalificatierun op een nieuwe kandidaatversie van het model. Elke wijziging doorloopt het volledige proces, inclusief de acceptatierun en de goedkeuringen.

Aan die oefeningen gaat de inventaris van de aarzeling vooraf. Elke eigenaar schrijft voor zichzelf op welke wijzigingen hij niet zou doorvoeren zonder ons te bellen. De lijsten zijn meestal kort en concreet: de prompt voor de mapping, de tolerantie voor één lastige portfoliomaatschappij, alles wat de kascijfers raakt. Elk punt komt op een van twee plekken terecht. Of het gaat naar een kolom van de wijzigingsmatrix, met een procedure en een acceptatierun erachter, of het is een gat in de overdracht en we dichten het voordat we vertrekken. In de laatste week herhalen we de inventaris. De overdracht is klaar als de lijsten leeg zijn, of als elk overgebleven punt een wijziging is waarvoor de matrix toch al een tweede persoon vraagt.

De oefeningen brengen dingen boven die een review van de documentatie mist. Een stap die voor de bouwers vanzelf sprak en voor het team dat het overneemt niet. Een goedkeuring waarvan niemand wist hoe die gegeven moest worden. Een test die langer duurde dan een gewone werkdag toelaat. Elk van die gaten wordt gedicht zolang de bouwers er nog zijn.

Wat op de laatste dag moet kloppen

Een opdracht eindigt als dit klopt, niet op een datum:

• Elk wachtwoord, serviceaccount en elke API-sleutel is van de klant en is vervangen sinds wij er toegang toe hadden.
• Prompts, drempels, mappings en regels staan in een repository van de klant, en elke wijziging, uit welke kolom van de matrix ook, is daarin een klein, beoordeeld verschil.
• Het team van de klant kan de volledige acceptatieset op de eigen infrastructuur draaien, binnen een werkdag.
• Aan de kant van de klant is iemand aangewezen die beslist wat er gebeurt als de modelaanbieder de gebruikte versie uitfaseert, en die persoon heeft al een kwalificatierun gedaan.
• De inventaris van de aarzeling is leeg, of elk punt dat er nog op staat, hoort toch al in de tweede kolom.

Ondersteuning volgt de bedrijfskalender

Een rapportageworkflow heeft geen 24-uursbereikbaarheid nodig zoals een publieke website. Er moet iemand beschikbaar zijn als het rapportageteam werkt, en vooral in de dagen voordat een boardpakket klaar moet zijn. In de overdracht leggen we vast wie aan de kant van de klant tijdens kantooruren als eerste reageert, wat die persoon zonder escalatie mag doen en welke escalatieroute in de rapportageweek geldt.

Eigenaarschap is het vermogen om te veranderen

Een klant is pas eigenaar van een AI-systeem als de eigen mensen het kunnen aanpassen in het tempo waarin het bedrijf verandert, en in een groep die bedrijven koopt, verandert het bedrijf bij elke overname. Vraag voordat je een overdracht aftekent elke eigenaar naar de kleinste wijziging die hij niet alleen zou doorvoeren. Wat ze noemen, is de afstand die nog te gaan is.