Eigenaarschap begint als de bouwers vertrekken

Twee weken lang verwerkte een financeteam de facturen van een nieuwe leverancier met de hand, naast een systeem dat juist was gebouwd om ze te verwerken. Zes maanden na de overdracht was het bedrijf gaan inkopen bij een nieuw type leverancier, waarvan de facturen een iets ruimere tolerantie nodig hadden. Het team wist niet zeker of het die mocht aanpassen, wie de wijziging moest goedkeuren en hoe het zou merken of er daarna iets stuk was. Dus veranderde het niets, en uiteindelijk belde de finance lead ons.

De overdrachtsdocumentatie was compleet en klopte. Alleen droeg ze het ene niet over waar eigenaarschap echt om draait: 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, is eenvoudig. De kwaliteit van een overdracht blijkt uit de kleinste wijziging die het team van de klant niet aandurft.

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?

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 lijkt een succes, 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 leveranciersmapping 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 matchingregel, 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 nieuwe entiteit of markt, 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 tolerantie uit dat telefoontje hoorde in de eerste kolom. Niemand had het team dat verteld.

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 toleranties, 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 het eigenaarschap van de acceptatieset. Dat is het vangnet waarmee mensen die het systeem niet hebben gebouwd, het toch met vertrouwen kunnen aanpassen. Wie eigenaar is van de acceptatieset, kan al het andere veilig veranderen. Daarom dragen we nooit een acceptatieset over die alleen wij kunnen draaien. Is daarvoor onze omgeving, onze scripts of onze kennis nodig, dan is de klant geen 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.

Zo'n oefening brengt de gaten in een overdracht sneller aan het licht dan welke review ook. Een stap die voor ons vanzelf spreekt en voor hen niet. Een goedkeuring waarvan niemand wist hoe die gegeven moest worden. Een test die te lang duurt om op een gewone werkdag te draaien. Elk gat wordt gedicht zolang wij er nog zijn.

Ondersteuning volgt de bedrijfskalender

Een financeworkflow heeft geen 24-uursbereikbaarheid nodig zoals een publieke website. Er moet iemand beschikbaar zijn als finance werkt, en vooral rond de maandafsluiting. 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 tijdens de afsluiting geldt.

Eigenaarschap is het vermogen om te veranderen

Een klant is pas eigenaar van een AI-systeem als de eigen mensen het net zo snel kunnen aanpassen als het bedrijf verandert. De kleinste wijziging die ze niet aandurven, laat zien hoe ver ze daar nog vanaf zitten.