Overleveringsproblemet: hva teamet ditt må eie før konsulentene går

Et AI-prosjekt har to avslutninger. Den første er lanseringen, som alle feirer. Den andre er stillere og kommer måneder senere, når en leverandør endrer et skjema, et regelverk justeres, eller en modellversjon fases ut, og systemet begynner å gi dårligere svar. Da er spørsmålet enkelt: hvem fikser det?

Hvis det ærlige svaret er «vi måtte ha ringt konsulentene tilbake», kjøpte du ikke et system. Du leide et, og telleren går fortsatt.

Hva eierskap faktisk betyr

Eierskap er ikke en mappe med dokumenter som overleveres på siste dag. Det er fire praktiske evner inne i selskapet ditt.

Dere kan drifte det: noen vet hvordan de sjekker om det fungerer i dag, og får beskjed når det ikke gjør det. Dere kan endre det: noen kan justere en regel, legge til en dokumentkilde eller oppdatere en instruksjon uten å opprette en supportsak. Dere kan vurdere det: noen kan skille godt fra dårlig resultat, med dokumentasjon i stedet for inntrykk. Og dere kan erstatte det: dere vet hva systemet er avhengig av, hva det ville koste å flytte, og hvem andre som kunne gjort jobben.

De fleste overleveringer leverer den første evnen og hopper over de tre andre. Det er derfor systemer driver ut av kurs.

Dokumentasjonen som betyr noe

Dokumentasjon skrives for å oppfylle en kontraktsklausul, så den beskriver arkitektur ingen noensinne kommer til å røre og utelater det folk faktisk trenger. Hold listen kort, og krev disse:

• En feilhåndteringsmanual. De fem tingene som mest sannsynlig går galt, hvordan hver av dem ser ut utenfra, og de tre første stegene for hver. Skrevet for personen på vakt, ikke for en ingeniør.
• Et evalueringssett. Hundre til to hundre reelle saker med riktig svar for hver, godkjent av dem som gjør jobben. Dette er det mest verdifulle enkeltartefaktet i hele prosjektet.
• En endringslogg med begrunnelser. Ikke bare hva som ble konfigurert, men hvorfor en regel finnes. Regler uten begrunnelse blir slettet av den neste personen.
• En avhengighets- og kostnadsoversikt. Hver modell, hvert API og hver leverandør; hva det koster per måned; datoer for kontraktsfornyelse; hva som ryker hvis det forsvinner.
• Et datakart. Hvilke data som går hvor, hvem som kan se dem, hvor lenge de oppbevares. Juridisk avdeling og sikkerhetsteamet vil trenge dette uten forvarsel.

Alt annet er valgfritt. Hvis et dokument ikke hjelper noen med å drifte, endre, vurdere eller erstatte systemet, er det pynt.

De tre personene du trenger

Du trenger ikke å ansette et maskinlæringsteam. Du trenger tre navngitte personer, og du bør navngi dem før prosjektet starter, ikke i siste måned.

En forretningseier som bestemmer hva systemet skal gjøre og har budsjettet. Vedkommende godkjenner endringer og sier nei til omfangsutglidning. Dette er ikke en teknisk rolle.

En teknisk forvalter som kan lese konfigurasjonen, gjøre en kontrollert endring, teste den og sette den i produksjon. Ofte en utvikler dere allerede har, eller en IT-ingeniør med avsatt kapasitet. Vedkommende trenger ikke å bygge modeller; vedkommende må kunne endre og distribuere det som finnes.

En kvalitetseier fra avdelingen systemet betjener — den erfarne saksbehandleren, den ledende sykepleieren, kundeservicesjefen. Vedkommende vedlikeholder evalueringssettet og avgjør hva «godt» betyr. Uten denne rollen blir kvalitet et spørsmål om meninger i løpet av uker.

Samlet intern kostnad: som regel en brøkdel av én heltidsstilling hver, når systemet er stabilt. Feilmodusen er ikke kostnad. Den er at ingen ble navngitt.

Test overleveringen mens du fortsatt kan klage

Ikke godta dokumentasjon som bevis på overføring. Kjør en reell test i de siste ukene av oppdraget, mens konsulentene fortsatt er under kontrakt.

Velg en ekte endring — legg et nytt produkt inn i kunnskapsbasen, stram inn en regel om hva systemet nekter å svare på, bytt inn en oppdatert prisliste. Be ditt eget team gjøre den, med konsulentene til stede i rommet, men tause. Ta tiden. La deretter kvalitetseieren kjøre evalueringssettet og bekrefte at ingenting annet ble ødelagt.

Hvis teamet ditt gjør dette på en dag, eier dere systemet. Hvis det tar en uke og tre spørsmål, har dere funnet nøyaktig de hullene som må tettes før fakturaene tar slutt. Begge utfall er langt mer verdt enn et signert overleveringsskjema.

Skriv dette inn i kontrakten fra starten. Milepæler for overlevering, et navngitt mottakerteam og en overvåket endringstest er alle lettere å forhandle om før arbeidet begynner enn etterpå.

Vi bygger på denne måten i Hercules A, og det betyr at oppdragene våre tar slutt. Det er hele poenget. Målet på et godt AI-prosjekt er ikke hvor dypt konsulentene sitter inne et år senere — det er hvor trygt deres egne folk endrer systemet uten å ringe noen.