När storsatsningar blir fiaskon

Det här är ett utdrag ur boken Kvalitetstårtan

Detta utdrag från kapitel 1.2 ”Systemtänkande och långsiktig förvaltning” visar varför så många stora IT-projekt misslyckas, och vad vi kan lära av det.

Media rapporterar regelbundet om IT-projekt som spränger budgetar och misslyckas spektakulärt. Svenska skattebetalare och aktieägare har genom åren förlorat enorma summor på IT-satsningar som lovat allt men levererat lite.

Dessa misslyckanden är inte bara intressanta som skräckexempel, de innehåller avgörande lärdomar om varför traditionella angreppssätt för systemutveckling inte längre fungerar i vår föränderliga värld.

Den svenska digitaliseringens kostsamma lärdomar

Skolplattformen i Stockholm, ett digitalt sandslott kollapsar

Stockholms stads skolplattform illustrerar perfekt vad som händer när ambitiösa visioner möter verklighetens komplexitet. Projektet startade 2013 med målet att skapa ett heltäckande IT-system för stadens skolor, allt från schemaläggning till föräldrakommunikation skulle hanteras i en enda plattform.

Den beräknade kostnaden: 670 miljoner kronor. Den verkliga kostnaden när systemet började rullas ut 2018: över en miljard kronor.

Men kostnaderna var bara toppen av isberget. Systemet byggdes som en monolitisk plattform bestående av 18 olika delsystem från olika leverantörer. Dessa komponenter kommunicerade inte effektivt med varandra, vilket skapade ett fragmenterat och svårnavigerat system. Användarna möttes av:

    • Långsamma svarstider som gjorde vardagsarbetet frustrerande

    • Återkommande inloggningsproblem

    • Svårigheter att hitta grundläggande information

    • Allvarliga säkerhetsbrister där personuppgifter tidvis låg oskyddade

En central orsak till misslyckandet var bristande användarfokus. De som faktiskt skulle använda systemet dagligen involverades först när det var för sent att göra fundamentala ändringar.

Millennium i Västra Götalandsregionen, när anpassning blir en mardröm

Västra Götalandsregionens implementation av journalsystemet Millennium visar att även internationellt beprövade system kan bli kostsamma fiaskon. Trots att systemet användes framgångsrikt i andra länder uppstod omfattande problem när det skulle anpassas för svenska förhållanden.

Implementationen som startade 2015 kännetecknades av upprepade förseningar och skenande kostnader. Systemets monolitiska natur gjorde att även enkla anpassningar krävde genomgripande modifikationer. Detta illustrerar en kritisk lärdom: anpassningskostnader underskattas systematiskt, särskilt när leverantörer har incitament att framställa sina system som flexibla.

PUST, när framgång förvandlas till fiasko

Polisens Utredningsstöd (PUST) är kanske det mest tragiska exemplet. Det började som en framgångssaga när PUST Java utvecklades 2010–2011 som ett mobilt system för fältrapportering. Pilotprojektet i Östergötland visade imponerande resultat:

    • Över hälften av ärendena slutredovisades inom ett dygn

    • Handläggningstider för vissa brott minskade med upp till 85%

Men sedan fattades det ödesdigra beslutet: systemet skulle skrotas till förmån för Oracles standardplattform Siebel CRM, som del av en standardsystemstrategi. Resultatet blev katastrofalt. Poliser återgick till pappersrutiner och systemet lades slutligen ned 2014 efter hundratals miljoner kronor i kostnader.

De dolda fiaskona i näringslivet

Det är avgörande att förstå att för varje offentligt IT-haveri som blir riksnyhet finns det sannolikt 3–5 liknande misslyckanden i privat sektor som aldrig når offentligheten. Dessa döljs bakom tystnadsavtal, rädsla för negativ påverkan på aktiekursen och en företagskultur som sällan tillåter offentliga erkännanden av misslyckanden.

Nordea NTP, miljardförlusten som få känner till

Nordeas Transformation Program blev ett av Nordens mest kostsamma IT-misslyckanden. Efter 6–7 år och över 5,3 miljarder kronor lades projektet ned 2012. En nedskrivning på 3,2 miljarder kronor gjordes senare. Grundproblemet: man underskattade dramatiskt komplexiteten i att harmonisera system från fyra olika länder med olika regelverk och affärskultur.

AstraZeneca, när produktion stannar

Läkemedelsföretaget AstraZeneca drabbades 2012 av allvarliga produktionsstörningar vid implementation av SAP. Målet att ersätta 40 specialiserade produktionssystem med en generell plattform resulterade i intäktsbortfall på cirka 2 miljarder kronor. Inom läkemedelsindustrin, där spårbarhet och regelefterlevnad är kritiskt, blev konsekvenserna katastrofala.

Vad gick fel? Fyra återkommande problem

När vi analyserar dessa projekt ser vi samma misstag upprepas:

1. ”Big Bang”-strategin

Alla försökte leverera allt på en gång. Komplexiteten blev ohanterlig och när problem uppstod påverkades hela verksamheten samtidigt.

2. Monolitisk arkitektur

Enorma, sammanhängande system där problem i en del skapar dominoeffekter genom hela plattformen. Som vi såg med Skolplattformen kan 18 delsystem som inte kommunicerar vara värre än 18 separata system.

3. Användarna kommer sist

De som faktiskt ska använda systemen involveras för sent eller inte alls. System designas utifrån konsulters antaganden, inte verklighetens behov.

4. Icke-funktionella krav som eftertanke

Fokus ligger på funktionella checklistor. Kritiska aspekter som prestanda, säkerhet och användbarhet behandlas som ”nice to have”, tills systemet går i produktion.

Varför fortsätter det hända?

Trots alla väldokumenterade misslyckanden ser vi samma misstag om och om igen. En förklaring är att det institutionella minnet är kort, de som fattar beslut om nya system var sällan med när förra katastrofen inträffade. Lärdomar dokumenteras dåligt och försvinner när nyckelpersoner byter jobb.

Konsultbranschens incitamentsstruktur förstärker problemet. Stora, komplexa projekt genererar högre intäkter än små, modulära lösningar. Säljkonsulter får bonus baserat på kontraktsvärde, inte levererad affärsnytta. Detta skapar en inbyggd konflikt mellan vad som är bäst för kunden och vad som är lönsamt för konsultföretaget.

Ett annat grundproblem är kompetensglappet mellan vision och verklighet. Beslutsfattare som ska investera miljontals kronor saknar ofta den tekniska kompetens som krävs för att kritiskt granska glättade säljpresentationer. Kravanalytiker från konsultföretag har naturliga incitament att överdriva systemets flexibilitet och underskatta komplexiteten. De erfarna utvecklare som verkligen förstår riskerna är sällan med i säljprocessen. Resultatet blir att det går att bygga systematiskt förväxlas med det är en bra idé att bygga.

Men kanske är den starkaste kraften den förföriska enkelheten i visionen om ”ett system för allt”. Tanken på en leverantör, en supportkontakt, ett system låter så mycket enklare än att hantera verklighetens komplexitet. PowerPoint-presentationer med eleganta pilar mellan komponenter döljer effektivt de månader av integrationsarbete som varje pil representerar. När beslutsfattare jämför med konsumentprodukter (”vi vill ha något som Facebook fast för vår verksamhet”) avslöjar de en fundamental oförståelse för företagssystems inneboende komplexitet.

Vägen framåt

Det är viktigt att påpeka att många IT-projekt faktiskt lyckas. Men vi lär oss mer av att studera misslyckandena, de visar med smärtsam tydlighet vad som händer när vi ignorerar fundamentala principer för komplex systemutveckling.

Dessa haverier är inte oundvikliga. De är direkta konsekvenser av felaktiga antaganden om hur komplexa system bör byggas i en föränderlig värld. För att undvika att bli nästa rubrik om IT-haveri måste vi acceptera komplexitet istället för att försöka gömma den i monolitiska system. Vi måste bygga för förändring från början istället för att hoppas att världen står still. Vi måste leverera värde iterativt och involvera användare kontinuerligt. Och framför allt måste vi behandla icke-funktionella krav som det de är, fundamentala förutsättningar för framgång, inte trevliga tillägg som kan hanteras senare.

Det här var ett utdrag till min bok Kvalitetstårtan som du kan läsa mer om på den här sajten. Här kan du även ladda ner checklistorna jag nämner här.