#143 – Skitsystem – så bryter vi mönstret

Prenumerera på Transformationspodden på Spotify och andra ställen där poddar finns.

Transformationspodden avsnitt #143: Skitsystem, varför standardsystem som ska lösa allt går i diket

I avsnitt 143 av Transformationspodden pratar Tobias Eklund med Leif Renström, vd på Hello Future, om stora systeminföranden som havererar. Utgångspunkten är journalsystemet Millennium: Södra Älvsborgs sjukhus i Borås tände systemet den 12 november 2024 och pausade införandet tre dagar senare, med recept på gula blanketter och anmälningar till Arbetsmiljöverket, IVO och Läkemedelsverket, efter 3,7 miljarder kronor. Region Skåne la ner sin Millennium-satsning efter åtta år och över 2 miljarder kronor. Leif Renström säger att detta inte är ett problem för offentlig sektor utan finns i nästan alla större internationella bolag.

Med skitsystem menar de ett standardsystem som köps in med förhoppningen att det ska täcka alla behov, varpå organisationen måste anpassa sig helt efter systemet. Standard i den bemärkelsen är som att införa Excel: det kräver enormt mycket konfiguration innan det löser något. Standardsystem fungerar bra för smala, statiska behov som fakturering, ekonomi eller lokalbokning. Problemen kommer när systemet ska vara brett och täcka hela verksamheten. Ju fler avdelningar i samma system, desto större problem.

Hello Future har arbetat praktiskt med detta i 15 år, både med behovsdefinition och upphandling och som anbudsgivare. Ett återkommande fel är att kravspecifikationen är en önskelista i stället för prioriterade behov. Ett system som skulle kunna kosta några tiotusen kronor i månaden som standard blir en investering på många miljoner, eftersom varje önskemål kräver nyutveckling. Två logiker krockar: leverantören måste hålla sin produkt standard för att ha en affär, kunden hoppas att standard ska täcka allt. Ett annat fel är att plocka russinen ur flera befintliga system till en kravspec som inget system kan uppfylla.

Varför köps de ändå? Ingen får sparken för att ha valt SAP, och nästan hela offentlig sektor kör Microsoft av samma trygghetsskäl. En leverantör för allt känns enkelt, men lägger alla ägg i en korg. Leif Renström ifrågasätter också Arbetsmiljöverkets antagande att få system ger bättre digital arbetsmiljö än många: Hello Future använder omkring 40 system, men varje medarbetare använder sina fem eller sex. Många specialiserade system ger en skräddarsydd miljö.

Logiken med ett system för all data var rätt på 90-talet, när små system inte kunde prata med varandra. Den dog runt 2010 när molnlösningar och API:er gjorde integrationer enkla och billiga. Forskningen, bland annat Johan Magnusson vid Göteborgs universitet, visar att modulära lösningar byggda iterativt utifrån behov fungerar bättre än big bang-utrullningar. Polisens nedlagda system PUST ersattes av små applikationer byggda på patrullerande polisers behov, som att identifiera bilar, med gemensam arkitektur i grunden. Green Cargo har hoppat över en generation och satt AI direkt på frigjord data.

AI förstärker detta. Hello Future ser stor skillnad i hur mycket teamet får gjort på samma tid. Tumregeln att en digital produkt kräver minst 2 000 timmar håller inte längre på samma sätt. Ett fastighetssystem med avancerade integrationer byggdes och lanserades på tre månader, vilket inte hade varit möjligt utan AI-stöd. Gränsen för hur många utvecklare som ger utväxling bryts när AI skriver kod och utvecklaren blir arkitekt och kvalitetskontrollant. Nästa steg är att användare genererar mjukvara för stunden. Leif Rehnström har byggt en AI-agent med Hello Futures ekonomidata från 2010 och framåt ur ett tjugotal källor, som bygger beräkningar när han frågar. Stora leverantörer bygger in AI i sina plattformar, som Copilot i Microsoft 365, men det är en övergångsfas mot AI-first.

För vården föreslår han en statligt ägd plattform för journal och identifiering av medborgare och medarbetare, med tunna specialbyggda applikationer ovanpå för provtagning, röntgen eller operation. Standardisera där skalfördelarna finns, bygg custom där behovet är specifikt. Organisatoriskt ersätts förändringsledare, som behövs för att anpassa organisationen till mjukvaran, av produktägare som prioriterar utvecklingen. Hello Future tränar kundernas produktägare över tid.

Rådet: när ett IT-behov dyker upp, öppna parallellt dörren för att bygga från grunden. Gör en riktig behovsinventering, skanna efter standardsystem som passar, och upphandla aldrig efter en önskelista.

Nyckelord: standardsystem, skitsystem, Millennium, systeminförande, upphandling, kravspecifikation, custom mjukvara, modulära system, big bang-utrullning, produktägare, AI-utveckling, Johan Magnusson, Leif Renström, Hello Future, Transformationspodden.

FAQ

Varför misslyckas så många stora systeminföranden?

Enligt Leif Renström köps standardsystem in med förhoppningen att de ska täcka alla behov i en bred verksamhet. Då måste organisationen anpassa sig efter systemet i stället för tvärtom. Kravspecifikationen är ofta en önskelista, och varje önskemål kräver nyutveckling som leverantören måste passa in i en produkt som ska förbli standard. Big bang-utrullningar där alla byter system samma dag förvärrar det. Millennium i Västra Götaland och Skåne är exempel, men samma sak händer i stora internationella bolag.

När passar ett standardsystem?

När behovet är smalt, förutsägbart och ändras sällan: fakturering, ekonomi, lokalbokning. Där finns skalfördelar och få scenarier. Leif Rehnström menar också att gemensamma plattformar är rätt för det alla behöver, som journalsystem och identifiering i vården. Problemen börjar när ett system ska täcka en hel bred verksamhet med olika behov på olika avdelningar.

Är det inte dyrare att bygga egen mjukvara än att köpa ett standardsystem?

Inte längre, enligt Leif Renström. Sedan runt 2010 gör molnlösningar och API:er det enkelt och billigt att bygga små modulära system som delar data. AI har gjort utveckling snabbare, Hello Future byggde ett fastighetssystem med avancerade integrationer på tre månader. Att anpassa ett standardsystem kan kosta miljoner eftersom varje ändring måste fungera i alla installationer, medan en lösning byggd för en kund kan vara helt specifik. Den ekonomiska kalkylen har ändrats och räkna därför inte bort egen mjukvara.