Millennium (Region Skånes nya system)

 

Nu har ledningen för Region Skåne annonserat hur man skall fortsätta med SDV, Skånes digitala vårdsystem.
Man säger att de finns tre vägar: 1. Fortsätta med Oracle, 2. köpa ett annat totalsystem, 3. bygga upp en struktur med flera olika mindre system, 4. att försöka inleda samarbete med några andra regioner och egenutveckla ett system.
Att fortsätta med Oracle skulle betyda att använda Oracles stora system, och är alltså ett exempel på alternativ 2.

Till att börja med: Vad var det som gick fel?

Först upphandlingen:
Man köpte ett system som det inte gick att bygga en fungerande lösning på.
Varför?
1. Tjänstemännen trixade av någon anledning bort det bästa alternativet på formella petitesser, så det fanns inget annat att välja än Millennium.
2: Troligtvis använde man en kravspec med en massa detaljerade krav. Det funkar inte. Man måste säkerställa att systemet kan vara bas i en  lösning som stödjer organisationens processer, vilket är en helt annan sak, men det absolut viktigaste. Bästa sättet vad jag vet är att göra studiebesök hos de som använder systemet. (Hur det skall göras inom lagen för offentligt upphandlig är knepigt och kräver en del ansträngning.)
3. Jag gissar att man i kravspecen införde en del onödiga krav som slog ut många bra alternativ.

Sedan projektgenomförandet:

Att införa ett stort totalsystem är en mycket svår uppgifter.
Man installerar inte ett program, man bygger en lösning. Lösningen består av många saker: Ett system i botten. Infrastruktur (datorer mm). Konfigurering av systemet (parametersättning). Begreppsdefinitioner och definitioner av data. Tillägg och anpassning av datasystemet. Integration med andra system. Konvertering av data från det gamla systemet. Procedurer och arbetsrutiner. Arbetsfördelning och ansvarsfördelning, ibland ny organisation. Utbildning. Säkerhetfunktioner. Användaradministration. Driftssäkerhet och återstartsrutiner. Manuella reservprocedurer.

De är tre faktorer som avgör om ett sådant här projekt lyckas:
1. Att systemet är tillräckligt bra att bygga på och lätt att komplettera med det som saknas.
2. Att organisationens högsta ledning har rätt inställning och styr projektet på rätt sätt.
3. Tillgång tilll duktiga experter på systemimplementation.

Systemet tycks inte ha varit bra nog.

Ledningen måste vara beredd på svårigheter och beredd att sätta till resurser. En stor systemimplementation är en mycket svår uppgift.
Ofta hamnar man i ett läge där projektet försenas och fördyras. Då brukar organisations ledning sätta press på projektledningen för att få till en projektstart så fort som möjligt (så lite försening som möjligt). Detta är katastrofalt. Hela inställningen i projektarbetet blir att försöka tysta invändningar och blunda för fel och brister. Brister som naturligtvis ändå visar sig och leder till dya omarbetningar och nya förseningar. Eller i värsta fall att man kör igång med en oanvändbar lösning.
Leverantörens experter blir agenter för att trycka igenom en dålig lösning, eftersom man lovat att den är bra. (De har ett stort psykologiskt övertag, och förklarar att motståndet bara beror på att referenspersonerna inte förstår eller inte accepterar förändring.)

(Det blir dyrare ju senare i processen man rättar till ett fel: Tänk dig att man bygger ett bostadshus. Du påpekar när du ser ritningen att sovrummen är för små så det inte får plats sängar. Du tystas ner för att bygget inte skall försenas. När man sätter upp väggarna blir det uppenbart, och man får börja ändra. Och bygget blir mycket dyrare och mycket försenat.)

Organisationens ledning måste skapa en miljö där användarnas invändningar och frågor ses som en tillgång! (Sen är det faktiskt sant att en hel del invändningar beror på att de inte kan föreställa sig den förslagna lösningen eller inte accepterar förändring.)
Man måste övervaka att man i projektet alltid seriöst utvärderar huruvida föreslagna lösningar fungerar. Inte försöka få klart så fort som möjligt.

Ledningen måste också se till att tillräckligt med resurser tillsätts, framför allt när det gäller projektdeltagare från organisationen. När enheter och avdelningar skickar personer som projektmedarbetare skall det vara de smartaste man skickar. Det händer tyvärr ibland att man inte gör så. (I värsta fall blir enheten glada för att skicka iväg latoxar som inte gör någon nytta och dessa uppskattar att få slippa jobba.)

Duktiga Experter är nödvändigt! Att bygga och starta upp en stor integrerad datalösning är en mycket speciell uppgift. Det räcker inte med att man har skickliga IT-specialister, de måste vara experter på systemimplementation. Sådana finns i begränsat antal hos leverantören och hos olika konsultfirmor. Är kundens projektledning slö, så kommer dessa att skicka sina medelmåttor, och inget av sina ess. Och ett projekt med för få ess bland experterna misslyckas.

Medarbetarna är inte experter på att utveckla systemlösningar eller förstå hur man bygger något som kommer att fungera. Det är implementations-experternas ansvar att säkerställa att lösningen fungerar genom att vara lyhörda för vad användarna säger.

En faktor som kan ha skadat Millennium-projektet är att Oracle köpte Cerner, och kommer att lägga ner Millennium. Det finns alltså inget större intresse för att supporta systemet, och konsulter flyr.

 

Region Skånes alternativ:

Se ovan: 1. Fortsätta med Oracle, 2. köpa ett annat totalsystem, 3. bygga upp en struktur med flera olika mindre system, 4. att försöka inleda samarbete med några andra regioner och bygga ett eget system.

Att bygga upp en struktur med flera olika system (3), är en dålig idé. Man kan visserligen få de bästa systemen för vissa enskilda arbetsuppgifter. Men Integration mellan skilda system innebär en betydligt större kostnad än man tror, och innebär också sämre lösning totalt.
Olika system har t ex olika begreppsdefinitioner. Det innebär att man förlorar information i översättning. Det försvårar också kommunikationen mellan användare som arbetar i olika systemdelar.
Själva integrationerna mellan systemen som skall byggas innebär extra risker för fel och driftstsörningar.

Att försöka inleda samarbete med några andra regioner och tillsammans ta fram en lösning (4) är en god idé. Men inte att utveckla ett eget system. Det blir ett alldeles för strot projekt och de kommer inte att få ihop kvalificerad personal tillräckligt för det.
En egen lösning bör bygga på ett standardsystem i botten, som bidrar med en massa grundteknik och -funktioner. Då hamnar vi ungefär i alternativ 2, alltså att installera ett stort komplett system. Dock med skillnaden att man från början inte förväntar sig att systemet uppfyller alla organisationens krav, utan bara skall utgöra en grund för att utveckla en komplett lösning.

Jag är ganska säker på att rätt väg att gå är att installera ett stort komplett system (2), byggt på ett standardsystem.

Att fortsätta samarbetet med Oracle (1) kan vara en god idé.

Oracle är en av de ledande globala leverantörerna av stora administrativa system, och varit i branschen i många år. Den variant av sitt standardsystem som jag förmodar de håller på att utveckla blir nog bra. (Med tiden…..)

Uppköpet av Cerner (Millenniums leverantör), var förmodligen en del i en strategi att etablera sig på sjukvårds-marknaden. Jag förmodar alltså att man håller på att ta fram en specialvariant av sitt stora standardsystem, och utnyttjar design och kompetens från Cerner och Millennium.
Region Skåne, och helst några andra regioner i samarbete, skulle kanske kunna bli en pilot för Oracle, med extra mycket support och större möjlighet att få systemet anpassat efter sina behov. Oracle skulle vara angelägna att projektet lyckas. Och man skulle kanske kunna klämma ur Oracle ett förmånligt avtal, med tanke på att de på sätt och vis är ansvariga för Millennium-projektens misslyckande, och nog är beredda att betala en del för att få fortsätta och rädda sitt anseende.

För Region Skåne kan det också innebära att man i något högre grad kan dra nytta av arbetet i Millennium-projektet, om man fortsätter med Oracle.