Sjukvården lär oss konsten att prioritera

12 april, 2020 Lean-Agile Inga kommentarer 10 minuters läsning

Går vi en grundkurs i livräddning är bland det första vi får lära oss att om vi behöver prioritera bland flera skadade inte börja hjälpa den som skriker högst. Till vår hjälp för att ta det beslutet lär vi oss prioriteringsmodeller och riktlinjer för livräddande insatser i situationer där kapaciteten understiger behoven.

En grundläggande prioriteringsmodell för livräddande insatser på olyckplatser och på akutmottagningar under hög belastning är Triage och en välkänd riktlinje är ABC. Med ABC lär vi oss att först säkra Andning, sen stoppa Blödning och sen hantera Chock. ABC blir således riktlinjen som gör att vi inte springer fram till den som skriker högst det första vi gör – då den som skriker högst bevisligen kan andas (A). Det är en princip som föräldrar även lär sig ganska snabbt. Ser man barnet ramla följt av att det skriker kan man andas ut. Ett skrikande barn är ett levande barn.

Men varför är det ofta just den som ”skriker högst” vi prioriterar inom andra fält, tex inom IT- och affärsutveckling? Svaret ligger till viss del i avsaknaden av tydliga prioriteringsmodeller och riktlinjer baserade på att fungera i en dynamisk kontext där flöden inte är homogena. Utan att göra några övriga jämförelser mellan akutsjukvård och IT- och affärsutveckling delar de samma förutsättningar då de befinner sig i en kontext som är i allra högsta grad dynamisk med icke homogena flöden och med en ofta slumpvis efterfrågan.

Där det finns en kö – där finns behov av prioritering och sekvens

Det första vi behöver förstå är att prioritering bara behöver göras om behovet understiger kapaciteten. En akutmottagning kan mycket väl ledas enligt principen ”i tur och ordning” eller FIFO (first-in-first-out). En akutmottagning eller en IT- och affärsutvecklingsprocess lever dock sällan under de förutsättningarna. Kontexten är dynamisk och flöden är inte homogena, FIFO fungerar således inte. Och inte heller ”den som skriker högst prioriteringen”.

Från TPS och Lean tillverkning lär vi oss att arbete i processen sker enligt FIFO (first-in-first-out), objekt med samma värde går igenom flödet i en jämn och förutbestämd takt (takttid) i produktionsceller. Det som går först in i produktionscellen kommer först ut. Det här är en optimal approach när kontexten är statisk och flödena homogena, vilket de är i en tillverkningsindustri.

Flöde

En bärande mekanism för att skapa förutsättningar för flöde i en process är att utveckla sekventiellt – att behandla patienter en och en, inte parallellt. Det vill säga hålla ner antalet saker vi gör samtidigt och göra tillräckligt klart innan vi påbörjar nytt.

Om vi bara påbörjar avancerade hjärtoperationer men aldrig avslutar några av dem må vi se sysselsatta ut i processen men vi skapar inget värde. För att optimera för flöde och inte för resursnyttjande arbetar vi i team där vi till viss del kan varandras uppgifter och den lediga kompetensen drar (pull) ett jobb istället för bli tilldelad genom push.

För att det ska fungera behöver vi en gemensam modell för prioritering och sekvensering. Annars drar vi jobb på olika premisser vilket kommer att skapa suboptimering före det önskade i att optimera systemet som en helhet.

Värdet och storleken på innehållet i kön är avgörande

Givet att vi har en kö behöver vi kunna kvantifiera värdet och storleken på de objekt som befinner sig i kön. Annars kan vi inte vikta objekten i relation till varandra när vi ska prioritera dem. I ett system som optimerar för flöde är utveckling sekventiellt nyckeln. För att veta hur sekvensen ska se ut behöver vi prioritera genom att resonera kring två parametrar:

Vad är Cost of Delay för behovet (det vi vill utveckla)
Vad är kostanden att implementera behovet där kostnaden utgörs av flera rörliga delar (tex ledtid, produktionskostnad, utvecklingskostnad)

Det är här Cost of Delay kommer in i bilden. Cost of Delay kombinerar tid (hur bråttom det är) med det potentiella värdet – två parametrar som människor inte är särskilt bra på att skilja mellan. För att fatta ekonomiska beslut måste vi förstå både hur potentiellt värdefullt något är och hur brådskande det är. Adderar vi storleken på jobbet (kostnaden att göra det) får vi prioriteringsmodellen WSJF som vi går igenom nedan.

”Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organization.” – Donald G. Reinertsen

På akutmottagningen har en hjärtinfarkt en högre CoD än en bruten arm. Det gör att vi enkelt kan prioritera mellan dem.

I vår IT- och affärsutveckling hjälper Cost of Delay oss utifrån tre viktiga aspekter: ta ekonomiska beslut baserade på avvägningar mellan flera rörliga parametrar, förbättra prioriteringen och fokusera dialogen på värde och hastighet.

Utvecklingen i en dynamisk kontext är full av olika avvägningar – vi behäver ta hänsyn till flera rörlig delar. Vi behöver kunna resonera utifrån olika parametrar med ett livscykel perspektiv. Till exempel: Om vi ökar antalet utvecklare ökar vi också kostnaden, får vi igen den kostnaden i och med kortare ledtider? Vad är i så fall den kortare ledtiden värd?
Cost of Delay hjälper oss att lägga gissningar och magkänsla åt sidan och fokusera på vad som har potentiellt värde och vad som är bråttom. CoD i WSJF hjälper oss att utveckla det som ger oss mest värde snabbast.
I en organisation som har lite koll på värde och hur brådskande saker är i relation till varandra kommer att försöka optimera för andra saker som att sänka kostnader och hålla deadlines vilket skapar beteende som inte optimera för flöde av värde i dynamisk kontext.

En process har flera köer

När vi förstår att en kö bara uppstår om kapaciteten understiger behovet och att vi behöver kvantifiera innehållet i kön baserat på potentiellt värde och hur brådskande det är, är nästa princip vi behöver förstå att det finns flera köer i processen. Det finns en kö ”in service” och en kö ”out of service”, dvs det finns en kö utanför den värdeskapande delen i processen och det finns en kö i den värdeskapande delen i processen.

Flyget hjälper oss att förstå. Där har vi en kö på marken ”out of service” med plan som väntar på att lyfta och vi har en kö i luften ”in service” med flygplan som väntar på att få landa. Att ha en kö i luften med flygplan kostar flygbolaget mer än att ha en kö på marken med flygplan. Därför kan flygplan tillsynes utan nåra köer på marken bli stående innan start för att flygledningen vet att det kommer bli kö 4 timmar senare i den värdeskapande delen i processen i luften. Vi föredrar alltid att ha kön utanför den värdeskapande processen. Att ha en kö ”in service” kostar oss mer än att ha den utanför ”out of service”.

Viktigt är dock att vi minimera båda köerna, men vi gör det på olika sätt.

Genom att minimera köerna utanför utvecklingsprocessen minskar vi ledtiderna i utvecklingsprocessen.

För att inte få långliggare i systemet i sjukvården i situationen som råder nu behöver vi ”out of service” minska smittspridning på äldreboenden så att patienten inte blir en långliggare ”in service”. Vi hanterar alltså köerna på helt olika sätt. Genom att minimera köerna utanför utvecklingsprocessen minskar vi ledtiderna i utvecklingsprocessen.

Storleken på våra köer är ledande indikatorer (leadning indicators) på våra ledtider (time to market). Kom ihåg att time to market är ett konstaterande mätetal (lagging indicator). Vi har mer att tjäna på att reducera köerna före vi går på våra flaskhalsarna i en IT- och affärsutvecklingsprocess. På samma sätt i sjukvården – vi har mer att vinna på att minimera smittan (reducera köerna) än att bygga bort flaskhalsarna i processen. En process har alltid minst en flaskhals, när vi har reducerat en uppstår en annan.

Olika prioriteringsmetoder för sekventiell utveckling

Modellerna nedan beskrivs i Don Reinertsens bok ”The Principles of Product Development Flow: Second Generation Lean Product Development”.

SJF – Shortest Job First

Om kostnaden av att vara sen är samma bör vi göra det jobb som tar minst tid först. Om vi gör det jobb som ta längst tid först kommer många små jobb att försenast. Då får vi något som kallas ”convoy effect” vilket syftar på att en långsam bil på en smal väg kan försena alla andra bilar på vägen.

Således:

Om två personer kommer in till akuten med liknande benbrott och således samma Cost of Delay men den ena personen är döv och behöver en teckenspråkstolk som är tillgänglig först om 5 timmar gipsar vi det andra benbrottet först.
Om vi ska uppdatera den judiska informationen för två stycken likadana köpflöden för två liknande produkter med samma Cost Of Delay men den ena flödet behöver även byta ut alla produktbilder väljer vi att göra det utan bilder först eftersom det är ett mindre jobb.

HDCF – High Delay Cost First

När storleken på jobben är den samma men kostnaden av att vara sen skiljer sig åt är den ekonomiska approachen att göra de jobb med hög Cost of Delay först.

Således:

Om två personer kommer in till akuten med varsin fiskekrok i respektive tumme där person nummer 1 har en en gammal rostig krok och person nummer 2 har ny rostfri krok väljer vi att behandla person nummer 1 eftersom kostnaden att behandlas sent med en rostig krok i tummen troligen är högre än att behandlas sent med en krok som inte är rostig.
Om vi ska förenkla köpflödet för två stycken köpflöden och det kommer krävas samma tid för respektive flöde börjar vi med det köpflöde som har högst Cost Of Delay.

WSJF – Weighted Shortest Job First

När både storleken på jobbet och CoD varierar använder vi WSJF. Det här är den komplexa verklighten vi möter både på akutmottagningen och i den moderan IT- och affärsutvecklingen.

Bäst strategi i en dynamisk kontext är att göra det uppskattade värdefullaste och kortaste jobbet först (WSJF). I de här fallen prioriterar vi baserat på jobbstoleken och jobbets CoD. Formelen för det är att ta CoD genom jobbets storlek vilket ger siffran vi använder för vår prioritering för sekventiell utveckling.

Vad kan vi lära oss genom att betrakta det som händer just nu iom Corona

Fastna inte i om vi är för få eller för många – optimera för flöde av värde
Stora projekt stoppar upp flödet – det finns flera köer i en process
Värdet på kön sätts globalt, insatsen i tid lokalt – Vad vi optimerar för och Varför vi gör det behöver vara tydligt
Det är alltid en avvägning mellan flera parametrar – utgå från att vi behöver beakta flera rörliga delar

Fastna inte i om vi är för få eller för många

Hanne Kjöller, Dagens Nyheter, 2020-03-27. ”Redan när jag läste till sjuksköterska på 1980-talet lärde jag mig att det inte finns något som heter ”fullt på intensiven”. Är alla sängar upptagna flyttar man helt enkelt den som är minst sjuk till en lägre vårdnivå om man kan tänkas använda den platsen bättre.”

Resursoptimering i sig är destruktivt för flöde. Med en inställning att vi aldrig kan vara för får eller för många skiftar vi fokus från resursoptimering till att optimera för flöde med de kompentenser vi har – oavsett hur många/få de är. Till vår hjälp tar vi en gemensam och transparant prioriteringsmodell.

Stora projekt stoppar upp flödet

Dagens Nyheter, 2020-04-05, Mattias Bergström: ”Långliggare är dåligt för systemet, de proppar igen platserna. Det blir ingen omsättning.”

Att reducera storleken på våra jobb och handera köer i och utanför den värdeskapande processen skapar förutsättningar för flöde.

Värdet på kön sätts globalt, insatsen i tid lokalt

Dagens Nyheter, 2020-04-10: ”I måndags skickades ett dokument ut med tydliga åldersgränser till chefer på Karolinska, för prioriteringar inom intensivvården. Personer med biologisk ålder över 80, biologisk ålder 70–80 och svikt i två eller fler organ och personer med biologisk ålder 60–70 med svikt i tre eller fler organ ska inte ges intensivvård.”

Cost of Delay är en global parameter som behöver sättas av ledningen för att skapa tydlighet och fokus. Storleken, tiden, sätts av de som är närmast informationen.

Det är alltid en avvägning mellan flera parametrar

Lena Andersson, Dagens Nyheter, 2020-04-11:
”Saker och ting kan inte jämföras endast med avseende på antal dödsfall. Fenomenens karaktär och hur saker sker måste beaktas.”

I en dynamisk kontext med icke homogena flöden är ekononiska beslut alltid en avvägning mellan flera parametrar.

Sammanfattning

I en dynamisk kontext med icke homogena flöden behöver vi prioritera och utföra vår utveckling sekventiellt.
För att ha en hypotes kring i vilken ordning vi ska utföra vår utveckling behöver vi kvantifiera innehållet i kön baserat på det potentiella värdet, hur bråttom det är och storleken.
Vi behöver vara flexibla och anpassningsbara (dvs agila) kopplat till parameterna ”Vad vill vi optimera för?” men hålla oss till en gemensam och stabil modell för prioritering.

Klas Fjärstedt