Go-live firas som mål – det är bara halva jobbet

Ett nytt affärssystem levererades i tid, korrekt konfigurerat, utan produktionsstopp. Champagne på fredagen, tillbaka till vanligt jobb på måndagen. Vi har sett mönstret upprepas i en verksamhet inom kollektivtrafik som nyss tagit över driften av ett fordonsunderhållssystem: den tekniska leveransen var i mål, men ingen ägde det som hände sen. Fyra månader senare arbetade vi fortfarande med att säkra att organisationen faktiskt använde systemet som det var tänkt – inte för att tekniken krånglade, utan för att ingen hade ansvar för det.

Det är den vanligaste missuppfattningen i IT- och AI-projekt: go-live behandlas som slutdatum istället för startdatum. Så fort tekniken fungerar antas resten sköta sig självt.

Varför fokus försvinner precis när det behövs som mest

Projektbudget och projektteam är dimensionerade för att leverera en lösning – inte för att förvalta ett beteende. När systemet är konfigurerat, testat och driftsatt upplöses projektorganisationen, ofta samma vecka som lanseringen. Kvar står linjeorganisationen med ett nytt verktyg och samma gamla vanor, utan att någon längre har mandatet – eller tiden – att driva förändringen vidare.

Utan någon som aktivt äger frågan "används det här rätt?" faller organisationen tillbaka på det som är bekant: kringgående lösningar i Excel, informella genvägar, frågor som studsar mellan leverantör, IT och linjechef utan att landa hos någon. Systemet finns där, men verksamhetsnyttan uteblir – inte för att tekniken är fel, utan för att ingen bar ansvaret för förändringen efter att den tekniska leveransen var klar. Det är precis det gap som gör att så många AI- och systeminvesteringar aldrig syns på sista raden.

Det som faktiskt säkrar att ett systembyte landar

I fallet ovan löste vi det genom att explicit förlänga ansvaret bortom go-live, snarare än att lämna över och gå vidare. Varje arbetsmoment i systemet dokumenterades som process – inte som teknisk manual, utan som arbetssätt som kommunicerades till verksamheten tills det blev vana och rutin. Utan den kommunikationen stannar ett systembyte som ett IT-projekt istället för att bli en del av hur jobbet faktiskt görs.

Vi tog också rollen som verksamhetens enda kontaktpunkt för allt som rörde systemet, istället för att frågor skulle spridas mellan leverantör, IT och linjechefer utan tydlig ägare. Det gjorde det möjligt att prioritera vidareutveckling utifrån vad verksamheten faktiskt stötte på i vardagen – inte utifrån vad som var enklast att bygga härnäst.

Den tredje och kanske viktigaste delen var en etablerad kommunikationsplan mellan verksamheten, förvaltningen och utvecklingsprojektet, genom samtliga faser, med veckovis avstämning och rapportering till ledningsgruppen. Det höll frågan om faktisk användning lika synlig som budget och tidplan redan var – istället för att vara det ingen frågade om förrän ROI:n uteblev.

Resultatet av att äga tiden efter lansering

Efter fyra månader var systemet inte bara tekniskt implementerat – det var förankrat: dokumenterade och kommunicerade processer, en tydlig kommunikationsplan och en verksamhet som visste exakt vart de skulle vända sig med frågor. Det är den skillnaden som avgör om en IT- eller AI-investering syns i resultatet, eller bara i en driftbudget ingen längre minns varför den finns.

Konkret takeaway: Avsätt inte hela projektbudgeten på leverans till go-live. Reservera explicit tid, mandat och en namngiven kontaktperson för de första månaderna efter lansering – för det är just då förändringen riskerar att utebli, långt efter att alla andra redan gått vidare.