När ett experiment byter status
En medarbetare bygger ett stöd för sitt eget arbete. En kollega börjar använda det. Sedan kopplas en datakälla in, en manuell kontroll tas bort och nästa steg i processen börjar vänta på resultatet. Ingen enskild händelse behöver kännas som ett systeminförande, men tillsammans har lösningen blivit en del av verksamheten.
Möjligheten finns nära problemet
Den som möter ett återkommande problem kan ibland bygga ett enkelt stöd utan att först göra frågan till ett centralt projekt. Små behov, lokala variationer och förbättringar som aldrig skulle nå en utvecklingskö kan då undersökas. Även ett misslyckat experiment kan ge värde genom att visa att grundproblemet är dålig information eller ett onödigt arbetssätt. Verksamhetsnära skapande är inte nytt; kalkylblad, makron och low-code har länge fyllt en liknande funktion. AI kan däremot påverka hastigheten, räckvidden och vilka som tar sig över det första konstruktionshindret. Det är en gradskillnad med möjliga organisatoriska följder, inte ett historiskt brott.
Från försök till Shadow Production
Här används Shadow Production som ett arbetsbegrepp för läget där en lokalt skapad lösning har blivit en återkommande del av produktionen utan att ansvar, förvaltning och kontroll har hunnit ikapp. Kraven bör växa med användning, beroende och konsekvens. Ett experiment behöver få vara provisoriskt. Men ”pilot” får inte bli en permanent etikett för något som hanterar verkliga data, påverkar kunder eller har blivit nödvändigt för leveransen.
Ägarskap och AI-skuld
När det blir billigt att skapa kan mängden använda men otillräckligt förvaltade lösningar växa. Dokumentation, test, behörigheter, versionshantering och avveckling hinner inte alltid med. Här används AI-skuld som ett arbetsbegrepp för den eftersläpningen. Skaparen är inte automatiskt rätt långsiktig ägare. Organisationen behöver kunna välja mellan att förvalta, flytta till en gemensam plattform, ersätta eller avveckla. Det obekväma beslutet är ibland att en uppskattad lösning måste tas över eller stängas därför att ingen kan bära ansvaret för den.
Vilken egenbyggd AI-lösning har redan blivit en verksamhetsförmåga utan utsedd ägare – och vem är beredd att ta över den eller stänga den?
Från tanke till handling
Tänkbara åtgärder
Några rimliga sätt att ta frågan vidare.
Bestäm tydliga övergångssignaler
Låt delning, nya datatyper, integration, borttagna kontroller och verksamhetsberoende utlösa en ny bedömning.
- Mål
- Upptäcka när ett försök har ändrat karaktär.
- Extra viktigt när
- lösningar växer gradvis utan projektbeslut.
Ge fungerande försök en väg vidare
Bestäm hur en lösning får ägare, stöd och proportionerliga krav – eller ett avvecklingsbeslut.
- Mål
- Bevara skaparkraft utan att lämna livscykeln åt individen.
- Extra viktigt när
- medarbetare annars blir informella systemägare.
Sätt ett faktiskt övertagande- eller avvecklingsdatum
För lösningar som redan används: utse ansvarig chef och ett datum då lösningen ska vara förvaltad, ersatt eller avvecklad.
- Mål
- Undvika permanent pilotstatus.
- Extra viktigt när
- en uppskattad lösning redan är ett beroende.