Eigenaarschap begint als de bouwers vertrekken

Twee weken lang voegde het rapportageteam van een private-equitygroep de cijfers van een net overgenomen bedrijf met de hand samen in de groepsrapportage, naast het systeem dat daarvoor was gebouwd. Zes maanden na de overdracht hadden de rekeningen van het nieuwe bedrijf één nieuwe mapping nodig: een regel die zegt welke rekening in welke regel van de groepsrapportage valt. Het team wist niet of het die mocht toevoegen, wie moest goedkeuren of hoe het zou merken als er iets stuk ging. De overdracht had geen eigenaar voor de mappings aangewezen, dus veranderde het team niets tot hun hoofd portfoliorapportage ons belde.

De overdrachtsdocumenten waren volledig en juist. Wat eigenaarschap in de praktijk vraagt, gaven ze niet door: het vertrouwen en de bevoegdheid om het systeem te wijzigen zonder de bouwers te vragen.

Na dat telefoontje veranderden we hoe we overdragen. Onze maatstaf nu: een overdracht is zo goed als de kleinste wijziging waarvoor het team van de klant zou aarzelen.

Documenten geven kennis door, geen bevoegdheid

Een typisch overdrachtspakket beschrijft hoe het systeem werkt: de opbouw, hoe data stroomt, stappenplannen voor bekende storingen. Het beantwoordt niet de vragen die een team stelt als het bedrijf verandert: mogen we dit wijzigen, wie moet akkoord gaan, hoe weten we dat het nog werkt, en wat doen we als dat niet zo is?

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

Zonder die antwoorden doet een zorgvuldig team het zorgvuldige: niets. Het systeem bevriest in de staat van de overdrachtsdag terwijl het bedrijf doorgaat. Een bevroren systeem kan op een succes lijken, tot het stilletjes wordt vervangen door een spreadsheet.

De wijzigingstabel maakt bevoegdheid expliciet

De kern van de overdracht is nu een wijzigingstabel: de soorten wijzigingen die het bedrijf nodig zal hebben, en per soort wie ze mag doen en wat er eerst moet gebeuren. Ze heeft drie kolommen.

Wijzigingen die het team zelf doet. Een mapping toevoegen voor de rekeningen van een bedrijf, een toegestane afwijking aanpassen binnen een bandbreedte die de controller goedkeurde, een redencode toevoegen, een routeringstabel bijwerken. Het systeem toetst de wijziging aan zijn grenzen en draait de relevante testgevallen; slagen die, dan gaat ze live.

Wijzigingen die een tweede persoon nodig hebben. Een nieuwe regel voor het samenvoegen van de groepscijfers, een nieuwe oorzaak van uitzonderingen, een afwijking buiten de bandbreedte, een nieuwe goedkeuringsgrens. Eén persoon maakt de wijziging, een aangewezen reviewer keurt haar goed, en alle testgevallen draaien voor de release.

Wijzigingen die een volledige hertest nodig hebben. Een nieuwe versie van het model, een nieuw documenttype, een nieuw soort bronsysteem, een wijziging in wat zonder controle doorgaat. Die krijgen een testrun met een schriftelijke vergelijking van resultaten, en de proceseigenaar tekent af.

De tabel is kort, specifiek voor het systeem en getekend door de proceseigenaar. Ze maakt van een vaag gevoel van risico een regel die iedereen kan opzoeken. De mapping uit dat telefoontje hoorde in de eerste kolom, en de overdracht had dat niet gezegd.

Elk wijzigbaar onderdeel heeft een aangewezen eigenaar

Een onderdeel zonder eigenaar is niet veilig te wijzigen, want niemand kan ja zeggen. Daarom heeft elk wijzigbaar onderdeel een eigenaar aan de kant van de klant: de acceptatieset (de echte gevallen met bekende juiste antwoorden waartegen elke wijziging wordt getest), de grenswaarden en rekeningmappings, de AI-instructies, de versie van het model, elke koppeling met een ander systeem en de data-afspraak erbij, de uitzonderingsoorzaken en redencodes.

Eigenaren zijn rollen met een benoemde persoon en een vervanger, zodat een functiewissel de rol opnieuw invult in plaats van haar wees te laten. De acceptatieset is het belangrijkst, omdat die mensen die het systeem niet bouwden, in staat stelt het met vertrouwen te wijzigen. Wie de set bezit, bezit het vermogen om al het andere te wijzigen. Dus moet de set zonder de bouwers draaien: heeft ze hun omgeving, scripts of kennis nodig, dan is het systeem nog niet helemaal van de klant.

Wijzigingen worden geoefend voordat de bouwers vertrekken

Lezen hoe een wijziging werkt, is niet hetzelfde als er een gedaan hebben. In de laatste weken van elke opdracht doet het team van de klant uit elke kolom een echte wijziging terwijl wij toekijken en zwijgen: een mapping zelfstandig, een regel met een reviewer, een volledige hertest op een kandidaatversie van het model. Elke wijziging doorloopt het hele proces, goedkeuringen inbegrepen.

Voor de oefeningen komt de angstinventaris. Elke eigenaar schrijft voor zichzelf op welke wijzigingen hij niet zou doen zonder ons te bellen. De lijsten zijn meestal kort en concreet: de AI-instructie voor mappings, de afwijking voor één lastig portfoliobedrijf, alles wat de kascijfers raakt. Elk punt gaat óf naar een kolom van de tabel, met een procedure en een testrun erachter, óf het is een gat in de overdracht dat we dichten voordat we gaan. De inventaris wordt in de laatste week herhaald. De overdracht is klaar als de lijsten leeg zijn of elk resterend punt een wijziging is die volgens de tabel toch al een tweede persoon vraagt.

De oefeningen brengen boven wat een documentreview mist: een stap die voor de bouwers vanzelfsprekend was en voor de overnemers onduidelijk, een goedkeuring die niemand wist te geven, een test die langer duurde dan een werkdag toestaat. Elk wordt opgelost terwijl de bouwers er nog zijn.

Wat op de laatste dag waar moet zijn

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

• Elke login, elk systeemaccount en elke toegangssleutel is van de klant en is gewijzigd sinds wij toegang hadden.
• AI-instructies, grenswaarden, mappings en regels staan in een opslag met versiebeheer die van de klant is, en elke wijziging, uit elke kolom, is daar een kleine beoordeelde aanpassing.
• Het team van de klant kan alle testgevallen op eigen systemen binnen een werkdag draaien.
• Aan de kant van de klant is iemand aangewezen die beslist wat er gebeurt als de modelaanbieder de gebruikte versie uitfaseert, en die al één volledige hertest heeft gedaan.
• De angstinventaris is leeg, of elk resterend punt hoort toch al in de tweede kolom.

Ondersteuning volgt de bedrijfskalender

Een rapportageworkflow heeft niet de 24-uursbereikbaarheid nodig van een publieke website. Hij heeft iemand nodig die beschikbaar is als het rapportageteam werkt, en meer nog in de dagen voor een boardpack. De overdracht noemt het eerste aanspreekpunt aan de kant van de klant tijdens kantooruren, wat die mag doen zonder te escaleren, en de escalatieroute in de rapportageweek.

Eigenaarschap is het vermogen om te wijzigen

Een klant bezit een AI-systeem als zijn eigen mensen het kunnen wijzigen in het tempo waarin het bedrijf verandert, en in een groep die bedrijven koopt, verandert het bedrijf met elke afgeronde overname. Vraag voordat u een overdracht aftekent elke eigenaar naar de kleinste wijziging die hij niet zelf zou doen. Wat hij noemt, is de afstand die nog te gaan is.