Gång på gång misslyckas stora projekt, typ storslagna standarder, gemensamma databaser, enhetliga gränssnitt, “en patient/en journal”. Små projekt, däremot, fortsätter att lyckas i förfärande omfattning, trots den uppenbara amatörismen i många fall, medan dom stora projekten ofta leds av folk som borde veta bättre (dubbelmeningen var avsiktlig). Man behöver inte vara ett under av perceptivitet för att inse att det faktiskt är så, men det är uppenbarligen svårt att greppa att det inte är en tillfällighet utan faktiskt en lag som ligger bakom detta, och det är inte lagen om alltings naturliga, hum, motsträvighet.

Rent intuitivt kan man ju tro att ett dubbelt så stort system kommer att kosta dubbelt så mycket jobb att göra. Eller t.o.m. mindre, eftersom man kan återanvända kod, talang, management m.m. Men det är grundligt felresonerat. Större utvecklingsprojekt tillför nya komplicerande faktorer i högre grad än de sparar arbete. För en summering av dessa faktorer, se Brooks [1].

Om vi ser hur mycket ansträngning det kostar i praktiken att bygga ett stort system jämfört med ett litet system så vet vi att detta inte är en linjär funktion av storleken, men en exponentiell funktion. Exponenten är enligt flera studier ungefär 1,5 (se ref [1]). Barry Boehm [2] beskriver snarare exponenter mellan 0,95 och 1,2. (Innan ni bejublar värdet 0,95 alltför mycket är det värt att läsa texten och att upptäcka att detta uppnåtts enbart hos NASA och anförvanter som ju också är en av de få organisationer som uppnått CMM level 5. Vill vi jämföra någon av våra producenter med NASA? Nej, tänkte väl det.)

Så, låt oss ta exponenten 1,5 vilket jag tycker låter vettigt för de utvecklingsorganisationer vi i allmänhet ser i vården idag. Det finns nog inget objektivt skäl att tro att någon av dessa organisationer systematiskt har arbetat för bättre skalexponenter, om dom ens hört talas om dom. Nu har ni haft tråkigt länge nog, så dags för action!

Exponenten 1,5 innebär att en fördubbling av storleken på ett utvecklingsprojekt ger att arbetet multipliceras med 2,8 i stället för 2 (ta fram gamla räknedosan och beräkna 2 upphöjt till 1,5). Det låter ju inte bra. Om projektet är tre gånger så stort växer arbetet med 5,1 gånger. Om projektet blir 4 gånger så stort, blir arbetet 8 gånger så stort. Lek med siffrorna en stund. Gör gärna en grafik. Notera när den slår i taket, kul va?

Det blir ju lite handviftande och fingret i luften, men låt oss i alla fall försöka oss på ett praktiskt exempel. Ta ett typiskt primärvårdsjournalsystem som utvecklats för 10 år sen eller så. Vad kan det ha kostat i man-år innan det blev användbart… 5 man i 3 år? Dvs 15 man-år? Låt oss ta det som värde.

Hur mycket större är en “gemensam journal” typ Cosmic än ett typiskt PV journalsystem? Dubbelt så stort? Tre gånger så stort? Mer realistiskt bör vi nog gissa minst 20 gånger, tycker jag.

Ok, vi gissar 20 gånger… det blir alltså en faktor av 20 upphöjt till 1,5, vilket ger… sätt er ner… 89,4… i runda tal ger det alltså 1350 man-år. Det låter ungefär rätt när man ser med vilken takt det går framåt (elakt, men sant).

Vi kan ju ha alla sorts anmärkningar på den här beräkningen. Kanske det inte är 20 gånger större, men 10. Eller 40. Välj själv och gör om beräkningen.

Kanske modernare utvecklingsmetoder är så mycket bättre att det kompenserar? Nej, ingen metod är så bra, tro mig. Kanske utvecklingsverktygen och språken är så mycket bättre? Nej, inget verktyg eller språk har hittills gett mer vinst än 15% av totala utvecklingstiden, se [1] igen.

Variationen mellan bra och dåliga utvecklare är ju som bekant upp till 5 gånger, 10 gånger, eller 50 gånger (beroende på vilken publikation man läser), så kanske de större utvecklingsföretagen har många fler superprogrammers än de små nånsin hade? Finns det något som tyder på det? Nej, trodde väl det. Snarare tvärtom, faktiskt.

Kanske Boehm har mer rätt än Brooks och exponenten är 1,2 i stället? I så fall skulle Cosmic “bara” behöva 36,4 gånger så mycket resurser för att få projektet klart som ett typiskt PV system från förra seklet, dvs dryga 500 man-år. Tjohej, säger jag då.

Den naturliga reaktionen vore då att sätta 500 man på projektet, så blir det klart på ett år. Men likaväl som 9 kvinnor inte kan föda ett barn på en månad, så funkar det här inte heller. Det blir oerhört dyrt att komprimera utvecklingstiden under den nominella och den absoluta gränsen uppträder redan vid 25% förkortning. Det är också en exponentiell funktion, fast en ännu värre. Så den iden är körd redan från början. För detaljer, se kapitel 8 i McConnell [3].

Vart vill jag komma med det här? Jo, intuitivt verkar det ju som om det vore enklare att bygga stora enhetliga system än flera små delsystem, men det är alltså helt enkelt inte sant. Det är precis tvärtom och det finns mer än tillräckligt med bevis för detta. Det vittnar om stor naivitet hos både beställare och producenter att fortsätta att förespråka stora gemensamma lösningar för att, t.ex. eliminera behovet av integration.

Det är lätt att falla i en annan fälla, nämligen de stora gemensamma standarderna i stället. Typ: “från och med nu ska alla system kopplas ihop med den heltäckande standarden X”, eller “nu ska vi alla använda samma heltäckande termkatalog”. Och “heltäckande” kan oftast översättas till “komplext”.

Är det så konstigt att alla dessa projekt går på pumpen? Nej, det vore snarare riktigt förvånande om dom någonsin lyckas genomföras.

Referenser:

[1] F. Brooks: The Mythical Man-Month, Addison-Wesley, 1995
[2] B. Boehm et al.: Software Cost Estimation with Cocomo II, Prentice-Hall, 2000
[3] S. McConnell: Rapid Development, Microsoft Press, 1996

Inlägget har 17 kommentarer:

Jag känner mig träffad av det stora naivitet som tycks råda. Inte för att jag anser mig själv vara naiv och inte därför att jag själv arbetar med stora journalsystem just nu, utan därför att jag är en stark förespråkare av tanken på en helhet. Det fordras därför en kommentar. Detta är ett intressant inlägg, mycket intressant. Ur ett teoretiskt perspektiv är det antagligen mycket svårt att argumentera emot, men jag saknar två viktiga parametrar. Den ena är det faktum att det idag inte finns två system, dvs ett för slutenvård och ett för primärvård hos respektive landsting. Sanningen är i många fall att det finns flera hundra system. Då bör i ärlighetens namn utvecklingstiden för alla dessa system vara med i jämförelsen. Den andra parametern jag saknar är marknaden. Ingen leverantör bygger stora eller små system för ”tack ska du ha”. När Siemens bestämde sig för att påbörja utvecklingen av Soarian (som har sin grund i Sverige), så kom man ganska snabbt fram till att den Svenska marknaden inte ensam kunde bära en så stor utvecklingskostnad. Detsamma gällde Norden och Europa. Beslutet blev att man ville utveckla en helhet, som kunde följa patientens väg genom vården oavsett var i världen man befinner sig. Man ville utveckla ett system som kunde säljas med världen som marknad. På så sätt kunde man på sikt få lönsamhet i projektet Soarian. Denna satsning är det emellertid mycket få som kan realisera. Det krävs enorma resurser och ett stort mått av ekonomisk uthållighet för att kunna genomföra något dylikt. Kommer då alla andra leverantörer att försvinna? Nej, det tror inte jag, men jag tror att det kommer att bli färre på sikt. Vad gäller projekten (alltså inte produkterna) i sig och dess svårighet att lyckas är att det fortfarande är väldigt svårt att tänka i landstingsgemensamma banor. Det finns för många som vill tycka åt alla möjliga håll. Att tycka är bra, men tankarna måste hållas ihop. Jag vill avsluta med att citera (dock inte ordagrant) Dr Pattersson, medicinskt ansvarig vid införandet av ett enhetligt system på ett sjukhuskomplex i Ohio. – Folk här är hjärtligt välkomna att klaga, komma med idéer, stjäla idéer från andra system, MEN alla synpunkter ska ha bäring på det system vi nu har valt att införa. Annars kommer vi aldrig vidare! Av Odehammar, 070620 12:56

Jag behöver kanske betona att detta inte är “teori” men resultatet av ett stort antal väl utförda studier över många år av många kunniga praktiker i många länder. Studier baserade på reella projekt och deras utkomst. Inte någon gång har jag sett en studie som säger motsatsen. Din sista anmärkning mystifierar mig. Betyder det att hur klantigt man än väljer och implementerar ett system, så är det användarnas och skattebetalarnas skyldighet att jubla i efterhand? Av mwehlou, 070620 13:06

Måste nog vara lite tydligare. Vad jag menar med min sista anmärkning är att ledingen har bestämt sig för att köpa in och införa ett system. Man har utsett en projektledning och informationen till alla anställda är att kom gärna med synpunkter, men prata inte om att köpa andra system. Vi har gjort en bedömning av olika system och nu ska det vi valt tas i bruk på bästa sätt. Jag jublar själv aldrig åt slöseri med skattemedel (något som de som känner mig vet) och har ingen anledning att tro att någon annan vettig människa heller skulle göra det. Av Odehammar, 070620 13:35

Martin, jag har läst ditt inlägg några gånger nu och jag har en fråga. Jag syftar på stycket nedan: “Hur mycket större är en “gemensam journal” typ Cosmic än ett typiskt PV journalsystem? Dubbelt så stort? Tre gånger så stort? Mer realistiskt bör vi nog gissa minst 20 gånger, tycker jag.” Om man istället vänder på det och utgår från ett sjukhussystem. Vi kan ta vilket som helst på marknaden som exempel. Skulle det bli 20 gånger större om det anpassades till primärvården? Om ditt svar är nej, så kan vi väl utgå från sjukhussystem och göra anpassningar som passar primärvården som handsken. Om ditt svar är ja, så skulle jag (och säkert många med mig) väldigt gärna vilja veta vilka dessa enorma skillnader är, som gör ett system som ska passa båda världarna 20 gånger större. Av Odehammar, 070620 15:05

Det finns många sätt att besvara dig, men om du förväntar dig en komplett kravspec i en kommentar, så får jag nog göra dig besviken. Om du vill ta ett fullt utvecklat och fungerande monolitiskt sjukhussystem och sen expandera det till att även involvera primärvården, så är första utmaningen att hitta vilket sjukhussystem det skulle vara. När vi kommer till strukturering av projekt och modularitet i senare inlägg, kommer diskussionen att bli mera meningsfylld och blir det tydligare vad jag menar med “monolitiskt system”. Av mwehlou, 070620 17:15

Jag förväntar mig ingen kravspec och min fråga var enkel. Kommer ett sjukhussystem (monolitiskt eller inte) att bli 20 gånger större för att kunna uppfylla primärvårdens krav? Jag ser fram emot att få lära mig mer om monolitiska system. Av Odehammar, 070620 18:19

Håller med Martin om att det är märkligt att ansvariga i IT-Sverige inte verkar ha läst den litteratur som faktiskt finns. Själv har jag väl inte precis någon hög ansvarsposition, men jag har faktiskt läst två att böckerna Martin hänvisar och jag kan rekommendera båda: Brooks om man vill ha nåt lättläst, McConnel om man är ute efter tyngre fakta. Till litteraturlistan skulle jag vilja lägga undersökningarna från Standish Group. De samlar med jämna mellanrum in data från 10 000 IT-projekt i USA. Deras resultat bekräftar det Martin skriver: smått är bättre. Här är en talande tabell från dem: http://www.vardit.se/standish.gif . Av Torbjorn…, 070620 18:20

Jag ifrågasätter inte vare sig Martin eller de källor han hänvisar till. Jag frågar mig bara om ett journalsystem växer med 20 gånger om det ska anpassas till primärvården? Om inte, så faller nämligen stora delar av de resursuppskattningar som gjorts. Plötsligt slog det mig att projektkomplexitet är inräknad. Är det så? Det innebär förvisso en del, men jag är fortfarande tvivlande till en förstoring på 20 gånger. Av Odehammar, 070620 18:50

Nej, det är klart att det inte växer 20 gånger. Det växer kanske med 50%, vem vet? Men du börjar ju redan på en betydligt högre programstorlek. Det här är elementär aritmetik och du kommer till i stort sett samma resultat, men vill du finna en ny vändning, så ber jag dig att först ta till dig bokverken i mina referenser, åtminstone nr 1 och 3, som borde vara förpliktad lektyr för alla som hanterar dylika bedömningar. Din fråga besvaras många gånger om i dessa böcker (och i många andra) med siffror och exempel. Av mwehlou, 070620 19:30

Min fråga var; Växer ett journalsystem framtaget för slutenvården med 20 gånger om det ska anpassas till primärvården? Besvaras detta i böckerna ”The Mythical Man-Month” och ”Rapid Development”? Jag tror säkert att de innehåller en massa nyttigheter, men berörs verkligen journalsystem? Jag vet inte, för jag har inte läst böckerna. Jag får försöka hitta böckerna och boka hängmattan i sommar helt enkelt. Den senaste uppgiften om storleksskillnad är nu 50% (vilket jag fortfarande tycker är högt, men jag lämnar det nu). Jag citerar en mening från den senaste kommentaren ”Men du börjar ju redan på en betydligt högre programstorlek”. Vad har det med saken att göra? De funktionerna behövs ju på andra håll inom landstinget och installationen finns på plats. Primärvården behöver ju bara använda de funktioner som man behöver. Jag vill igen påpeka att jag inte kritiserar kunskapen bakom inlägget. Inte heller kritiserar jag riktigheten i de källor som redovisas. Jag menar bara att man måste granska siffrorna bakom och vad de egentligen betyder får vård it i realiteten. Av Odehammar, 070621 08:59

För det första är det ingenting speciellt med vårdrelaterad utveckling av programvara. Den lyder under samma naturlagar som all annan programvara. “Programstorlek” bedöms på ett antal sätt, t.ex. KLoc, eller function points. Arbetet för att bygga ett system är en exponentiell funktion av storleken på hela systemet. Arbetet att bygga till en viss mängd function points är alltså exponentiellt större om det redan existerande systemet är stort än om det är litet. Du förefaller tro (och många med dig, vilket är problemet) att en viss funktionalitet kostar ett visst arbete oberoende av var den tillfogas, vilket ju är helt fel. Ett annat sätt att säga det: om du utvecklar en viss primärvårdsfunktionalitet med X function points i isolation som ett nytt eller löst kopplat system, kostar det en viss summa. Samma antal function points implementering i ett system med redan existerande stort antal function points, kommer att kosta samma arbete multiplicerat med en faktor som är det totala antalet function points i systemet upphöjt till exponenten 1,5. Dvs att arbetet för att tillfoga samma funktionalitet kommer att bli 89 ggr dyrare, om man tar mitt exempel ovan. Har det aldrig förundrat dig varför det bara verkar bli svårare och svårare att tillfoga funktioner till stora system i stället för lättare? Nu vet du varför. Det finns alltså alla skäl att begränsa storleken på varje monolitiskt system. Av mwehlou, 070621 10:29

Håller helt med delen om finansiering. Kan vi ha ett system för tandläkare som bygger på ersättning för levererad behandling så borde vi kunna ha det även för sjukvården. Idag har vi t ex mängder med problem under semesterperioden då folk inte besöker sitt vanliga sjukhus mm. Landstingsorganisationen blir egentligen också överflödig med en sådan lösning. Mängder med fördelar då olika sjukhus är duktiga på olika typer av beahandlingar. Hur kan man få politikerna att inse det vettiga i en sådan lösning? Av claseng, 070621 11:49

Några tankar om hur mycket man kan klumpa ihop saker i en jättemodell (monolitisk?) eller istället hålla isär som flera mindre, någorlunda avgränsade men samverkande modeller/system inom medicinsk informatik: http://hl7-watch.blogspot.com/2006/10/harmonisation-cen-and-hl7.html Det inlägget inleds med en massa diskussion om standarder och ev. harmonisering, men det som handlar om delmodeller och är relevant för denna diskussion finns på slutet. Scrolla ner till rubriken “Semantic interoperability” nära slutet och läs därifrån. Upplever ni att detta har bäring diskussionen om systemkomplexitet i journalsystem? Av erisu, 070624 23:57 | Anmäl

Kom på att innehållet på den länkade sidan i min kommentar nyss nog ter sig kryptisk utan en del bakgrundsinfo. Begreppen “two level model”, och metamodellerna “Document” + “Clinical Model” förklaras t.ex. i en text från 2002, se http://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf Där jämförs “traditionell” systemutveckling (fig 1, sid 3) med “Two-level Methodology” (fig 2, sid 6). Idén att dela upp systemet för att få en mindre, stabilare och enligt blogginläggets resonemang troligen bättre storlek på mjukvara är inte ny eller unik. Delar av det finns t.ex. i diverse mallmekanismer i dagens journalsystem. Ett annat (möjligen naivt) exempel är ett kalkykprogram t.ex. Excel, där man har en generell mjukvara som tillåter domänexperter (t.ex. ekonomer) att utveckla egna domänkunskapsbaserade modeller (specifika kalkylark/kalkylmallar) utan att ändra underliggande mjukvara. Man kan läsa vidare konkret hur detta kan implementeras i distribuerade semantiskt interoperabla journalsystem i t.ex. openEHRs “Architecture Overview” http://svn.openehr.org/specification/BRANCHES/Release-1.0.1-candidate/publishing/architecture/overview.pdf Vore kul med kommentarer om detta. Är det en bra idé att försöka göra mjukvaran mindre och där det är möjligt något tydligare försöka dela upp ansvarsområden mellan sjukvårdsexperter och IT-experter? En tänkbar kommentar är att man bara flyttar komplexiteten från den traditionella programvaruimplementetionen till ett annat format. Mer om det någon annan gång. Av erisu, 070625 02:04

Toppen! Tack för länkarna! Du måste ge mig chansen att gå in på detta i ett separat inlägg, det finns ingen chans i världen att göra ämnet rättvisa i en kommentar. Men du har helt rätt att det rör sig om två fundamentellt skilda underliggande modeller, med allt vad det innebär. Av mwehlou, 070625 09:18

Dina tankar är alls inte dumma Erik. Jag har inte hunnit läsa vad som finns bakom dina länkar ännu, men tror att det är en förutsättning att man bygger helheten i moduler, som var för sig måste kunna slås av och på samt konfigureras på olika sätt för olika enheter. Jag tror däremot att det blir väldigt svårt att göra detta med moduler från olika leverantörer. Det finns exempel i Sverige på hur man försökt bygga en plattform med fritt konkurrerande moduler. Det blir svårt att sy ihop en helhet av det hela. Av Odehammar, 070625 11:08