Validera alla sidor

Konflikt är egentligen normaltillståndet, om vi med konflikter menar att vår personliga uppfattning bryts av mot omgivningens. Den stora majoriteten av alla dessa "konflikter" löses hela tiden i ett ständigt pågående medvetet eller omedvetet förhandlande om konsensus. Att harmoniera med vår omgivande grupp är något vi är byggda för.

Den gruppdynamiska processen som t ex Bruce Tuckman och Susan Wheelan ägnat så stor del av 60-70- respektive 80-90-talen att utforska, den mäter en grupps sammanhållning som dess förmåga att fatta gemensamma konstruktiva beslut. Man har noterat att en mogen grupp som kan detta samtidigt är en grupp som samarbetar väldigt bra och kan skapa stora värden genom att utnyttja medlemmarnas kunskaper och förmågor på ett produktivt sätt.

Men det kräver att gruppen under resans gång har tillskansat sig produktiva sätt att lösa konflikter på. Och det är inte helt självklart att sådana produktiva sätt uppstår. Den som är satt att göra det enklare för gruppen att nå dit, t ex en chef, en Scrummaster, en leanvägvisare, eller annan facilitator; behöver verktyg för att både förstå och intervenera i konflikter på ett bra sätt. För mig har praktiken att validera varit till stor hjälp, och jag tänkte berätta lite om hur den funkar.

För det första måste man förstå att alla beslut i en organisation, även inom en stark hierarki byggd på hot i själva verket är konsensusbeslut. För att en sträng hierarki ska fungera oss emellan måste vi vara överens om min underordning och din överordning. Så oavsett om vi försöker skapa en egalitär självstyrande smidig arbetsgrupp eller en preussisk armédivision så är den ömsesidiga överenskommelsen nödvändig. Och gruppen måste hjälpas åt att nå dit, inom den maktstruktur man bestämt ska råda.

Det betyder att allas perspektiv alltid kommer vara viktiga för gruppen, även i de fall där någon bestämt att vissa personers perspektiv ska spela mindre roll för helheten än andras.

För det andra måste man förstå att ingen kommer att ge sitt samtycke till en grupp om hen inte får plats i gruppen. Jag kanske inte får det inflytande i gruppen som jag önskar, men det behöver inte hindra mig. Deltagandet i gruppen behöver inte ens vara bra för mig, inte ens att sammanhanget är destruktivt hindrar mitt deltagande. Jag har själv deltagit i konstellationer där jag misshandlats och kränkts, men det blockerade inte mitt deltagande i konstellationen. Däremot: om jag inte kan delta i en grupp kommer det att hindra.

Det betyder att vissa invändningar mot det gruppen bestämt är av den arten att de faktiskt kommer att blockera gruppens arbete i sin nuvarande form, i det att en gruppmedlem faktiskt inte kan delta under rådande omständigheter. Det handlar inte om medlemmens vilja eller mandat, invändningen kommer inte att kunna förhandlas bort oavsett vilka metoder du tänker använda.

Ska du bygga ett smidigt arbetslag finns det inget alternativ till en egalitär struktur med ett skiftande ledarskap inom gruppen. Där är hänsynen till allas olika intressen självklar. Men vad många missar är alltså att den hänsynen är precis lika viktig även i konflikter där parterna har radikalt olika utgångslägen i maktstrukturerna.

Vad är det då som ska bekräftas hos var och en? Marshal Rosenberg, personen bakom "giraffspråket", även känt som ickevåldskommunikation, pratar om fyra aspekter när en människa vill något:

• Observation, man betraktar ett skeende och ger det sin tolkning. I kommunikationen: "Jag ser att..."
• Känsla, man reagerar på det man varseblir med en känsla: "Jag känner att..."
• Behov, man upplever att man har ett otillfredsställt behov: "Jag behöver..."
• Önskning, och sammantaget leder det fram till en konkret önskan: "Jag skulle vilja..."

Dessa aspekter finns hos varje individ i varje stund, i synnerhet i en konflikt, oavsett om vi väljer att uppmärksamma dem eller ej. När vi inte uppmärksammar dem kan det leda till stor frustration och många låsningar. Maktkamper kan äga rum om tolkningsföreträdet vad gäller observationen, samtidigt som man hävdar en önskning som kommer att slå mot den andra partens behov. De starka affekterna förvärrar situationen.

Men när vi genom att lyssna och ställa frågor försöker kartlägga och bekräfta varje individs observationer, känslor, behov, och önskningar, så händer saker.

Vi behöver inte kriga om tolkningsföreträdet vad gäller observationerna. Vi kan konstatera att folk ser olika på saker och ting, och att ontologiska påståenden (utsagor om verkligheten) många gånger kan bekräftas eller förkastas genom ett enkelt experiment. En ontologisk fråga är antingen avgörbar på ett sånt sätt att ingen tvekan råder, eller så är den öppen och då är alla observationer likvärdiga och onödiga att strida om.

När man sätter ord på känslor mildras deras negativa inflytande över vår förmåga att tänka klart. Det kallas affect labeling och verkar fungera så att de delar av vår hjärna som tolkar verkligheten åt oss aktiveras och tar över processen från det mer primitiva paniksystemet som annars blockerar tänkandet.

När vi formulerar våra och andras behov accepterar vi dem. Vi kanske inte är benägna att tillgodose behoven, men det blir i så fall ett medvetet val och inte en dold konsekvens av att behoven ignoreras. Detta minskar också stressen hos var och en: att det alls finns ett språk för att uttrycka och hantera mina behov, och att det språket införs i vår gemensamma diskurs, det skapar en trygg miljö för mig att verka i. Att diskutera arbetssätt utan någon tänker på intäkter versus kostnader skapar otrygghet om du lever med vetskapen att intäkterna alltid måste överstiga kostnaderna för att det ska gå ihop. Att diskutera arbetsplatspolicies utan att någon nämner att de får olika konsekvenser beroende på vilket kön du tillhör skapar otrygghet om du lever med vetskapen att du kan drabbas negativt pga detta.

När vi slutligen blir konkreta och tydliga med våra önskemål om andras beteende kan vi äntligen börja analysera dem. Vad kostar en uppfylld önskning olika parter? Vilka behov uppfyller den? Falska önskningar om andras beteende som i själva verket är önskningar att något visst resultat ska uppnås oavsett om någon kan uppnå det, de avslöjas som orimligt önsketänkande. Och viktigast: om vi känner till de bakomliggande behoven kan vi börja förhandla om andra sätt att tillfredsställa dem.

Att hjälpa var och en i en konflikt att verbalisera detta skapar en miljö där man kan vara lösningsfokuserad. Kom ihåg att du som facilitator också ska verbalisera din vinkel av dessa fyra aspekter. Du är ju ingen utomstående betraktare utan deltagare i detta samspel. Folk behöver veta detta om dig för att vara trygga med var du står i konflikten och på så sätt bjuda in dig att hjälpa dem. Genom att själv verbalisera och kommunicera vad du verbaliserat tjänar också som ett föredöme.

Nästa steg blir nämligen att de olika sidorna ska bekräfta att de förstått varandras observationer, känslor, behov, och önskningar. Förstå och bekräfta är inte samma sak som att acceptera och böja sig inför. Här kan det finnas en liten känslomässig tröskel eftersom vi kan ha svårt att göra den skillnaden, särskilt om vi fortfarande befinner oss i affekt. Samtidigt är påståendena av typen: Jag ser, jag känner, jag behöver, jag önskar; omöjliga att säga emot. De är ju bara subjektiva observationer inifrån en människas hjärna och vi får ta dem för vad de är.

Har man väl kommit hit brukar resten gå av sig självt. Att blottlägga de inre aspekterna av konflikten fungerar som alla andra transparenshöjande smidiga tekniker: de gör det svårare att fatta destruktiva beslut. Däremot kan processen när man tillämpar denna praktik blottlägga så djupt liggande motsättningar att själva samspelet inom de befintliga strukturerna inte kan fortsätta. Det är en risk man måste vara medveten om.

Vad har du på menyn?

Vi blir ofta oerhört stressade av förfrågningar. Stressen är en sund signal, eftersom det vi blir stressade av sällan är förfrågningarna i sig, utan av att systemet vi arbetar inom inte har en vettig process för att hantera dem.

När förfrågningar plingar till i e-posten, eller när någon ringer och vill ha något gjort, så utmanar det flera av våra inre processer: vi tvingas växla uppmärksamhet, anstränga arbetsminnet ännu mer, fatta beslut på otillräcklig kunskap eller beslut om vi ska anstränga oss för att skaffa mer kunskap även om vi inte vet om det kommer att löna sig osv osv.

Detta får sekundära effekter: vi anar en ökad risk att misslyckas inför oss själva och dem vi känner har ett inflytande på oss, vi undrar vad som händer med relationerna till folk om vi kanske tvingas säga nej till dem nu, vi upplever oss trängda med ett krympande antal valmöjligheter, och den allmänna osäkerheten ökar när systemet på grund av allt detta blir mer oförutsägbart.

Vi är byggda för att bli stressade i de lägena, och om du inte erfar den stressen så är du att gratulera för då har du antingen utvecklade personliga strategier som skyddar dig eller så arbetar du på ett ställe där ni har systematiska sätt att möta detta på. Personliga strategier är en sorts första hjälpen, men smidiga arbetssätt handlar om att lösa problemet vid roten genom att göra strategierna gemensamma och tydliga.

Människans stressystem är byggt för att trigga fysisk respons (slåss, springa etc), stänga av känslor och intryck utom ett fåtal (tunnelseende), och inte blanda in det långsamma analytiska och energikrävande förnuftet. Den som funderar för mycket under en tigerattack blir lunch. Människans stressystem är alltså inte byggt för kunskapsarbete. Därför ska kunskapsarbete alltid utformas så att stressystemen inte aktiveras. Och det är det vi gör med hjälp av tjänstemodeller.

Tanken är enkel: för ett arbetssteg vi upplever som sårbart (t ex mycket av det vi gör på kontoret) separerar vi mottagandet av förfrågningen från utförandet. Att utföra är proaktivt, att hantera förfrågningar är reaktivt. Om vi inte skyddar utförandet från förfrågningarna kommer utförandet alltid att haverera.

Jag vet inte hur många organisationer jag sett där förfrågningar skickas som e-postmeddelanden eller telefonsamtal till individer, där man jagar individer, där man i princip försöker tjata sig till att individen ska byta prioritering och ägna sig åt en själv, oavsett vad detta innebär för hela organisationens förmåga att skapa värde. Detta skapar sårbara flödessteg där utförandet tar enorma mängder stryk.

För att minska stressen behöver man se över arbetsgången för de olika förfrågningar som skickas på en. Helst gör man det i grupp, och formerar sig kring en gemensam inkorg för förfrågningar som man sedan samarbetar om. Det skapar en mycket mindre sårbar organisation utan så stora personberoenden. Men även om man tvingas agera individuellt är angreppsättet detsamma: ställ frågan Vad har jag på menyn?

Ofta tror man att man har en meny som är mycket mindre än vad den är. Jag möter t ex systemutvecklingslag som tror att de har två saker på menyn: planerad utveckling och buggfixar. Men i verkligheten efterfrågar folk en massa saker från dem: tekniskt säljstöd, uttala sig om något, estimera en framtida lösning osv: och för inget av detta finns det en ordnad arbetsgång. Det rings och jagas istället.

Så skriv ner din meny. Vad har du lovat, implicit eller explicit, din omgivning att göra för dem? Inom vilka tidsramar? Inte sällan förväntar sig folk bara ett fåtal saker från dig, låt säga tre. Men de kan ha flera olika uppfattningar om vilka tidsramar som bör gälla: nu, inom några dagar, eller längre fram. Det kan vara en god idé att tänka på dessa som sex eller nio olika tjänster, för arbetsgången för den snabba pucken är inte alltid densamma som för den långsamma.

Ett nästa steg kan vara att se hur detta du lovar att göra, och när, passar in i det värdeskapande flödet. VARFÖR ska du överhuvudtaget göra det? För det är kanske inte någon bra idé att ägna möda åt att specificera ett arbete som ändå inte ger så högt värde. Och omvänt: om man vet varför det ger ett högt värde så blir det lättare att utforma arbetet bra. Men det får vi ta en annan gång.

Priolistan, hur man ökar värdet i en kö

Vi såg hur effektivt det är att beskriva sin verksamhet som ett flöde där vi steg för steg förädlar ett värde åt någon. Vi såg också hur ett dragande flöde skyddar varje steg från överlast och skyddar hela flödet från ojämnhet. Men eftersom det ofta finns tryck, åtminstone i början av ett flöde vid ärendemottagningen, så kommer det någonstans uppstå en ansamling av obehandlade ärenden. Inflödet är ofta större än utflödet. Vi såg hur en enkel kö troligen är den sämsta strategin för att hantera detta.

För alla ärenden i ansamlingen är troligen inte lika viktiga, sett ur hela flödets synvinkel. Om man istället kan hitta principer för att värdera och prioritera ärendena kan vi inrikta oss på att göra det som i varje stund är mest värdefullt. Inom sjukvården kallar man det för triage (efter franskans "sortera/utvälja"), för att se till att de mest brådskande akutpatienterna får hjälp först. I metoden Scrum i systemutvecklingen lägger man ärendena i en backlogg och kräver att en person, som man kallar Produktägare, med hela organisationens mandat i ryggen prioriterar mellan dem.

Medan det inte alltid fungerar så bra att peka ut en enda människa att i ensamt majestät prioritera (som man gör i Scrum), så är det riktigt att prioriteringen måste ske med hela organisationens mandat. Hur man väljer att prioritera i ansamlingen av ärenden inför ett steg, kommer nämligen inte att bara påverka det steget. Det kommer att styra hela flödets beteende.

Nu blir det lite svårt. Det finns ofta ingen på nivån ovanför flödesstegen som har kunskap och insikt om detaljerna i flödena för att kunna diktera villkoren på ett bra sätt, och det blir därför ofta fel när de gör det. Inom IT ser vi ständigt beslut om prioritering som fattas utifrån ett snävt perspektiv utan hänsyn till tekniska realiteter, vilket orsakar stora problem. Men att delegera är inte heller lösningen: den som prioriterar ärendena för en del av flödet kommer att suboptimera utan insikt om helheten.

Lösningen är att dels hitta de i samarbetet som bäst kan ta tillvara den glada mottagarens intresse genom hela flödet; och dels att alla de som samarbetar om flödet sammanstrålar inom ramen för sitt förbättringsarbete för att hitta och ta bort alla hinder för ett smidigt flöde. Ledningens ansvar i den processen är att ge golvet förutsättningarna (mandatet och förmågan) att förbättra flödena.

Jag kommer att återkomma med konkreta tekniker för hur man kan arbeta med att bestämma sin prioritering.

Infarkten

När flöden är tryckande finns inga garantier för att undgå överlast i dem. Effekten av överlast är ett tvärstopp. Men innan dess har saker påverkats: redan när du närmar dig det absoluta kapacitetstaket går processen långsamt. Jämför med att försöka ställa upp lite för många koppar på en kökshylla. Det går snabbt i början, men sedan börjar pusslet för att få plats med alla.

När saker börjar gå märkbart långsammare på ett ställe i flödet kommer de att orsaka trögheter, överlast, och ojämnhet även på andra ställen. Dessa kan i sin tur orsaka ännu mer tröghet och obalans som orsakar mer som orsakar mer.

Förseningen ledde fram till att projektledaren hann sluta och det ledde till att den nya projektledaren inte lärde sig lika bra och vissa fel släpptes igenom och för att komma ikapp försökte folk jobba dubbelt men då gick det ännu trögare och...

För att inte drabbas av varken överlast eller ojämnhet måste flöden vara dragande. Folk ska själva dra till sig ärenden att arbeta med. Ingen tjänar på att trycka arbete på någon annan. Det finns psykologiska skäl att låta bli, det finns matematiska skäl att låta bli, och den stora faran är om dessa effekter samverkar och skapar en infarkt.

Ibland kan man inte göra på något annat sätt. Inflödet av ärenden kan inte stoppas. Då blir det en ansamling. Vi såg förut hur köer nog är det sämsta sättet att hantera en ansamling på. Ett bättre alternativ är behovslistan, "backloggen". Den tänkte jag skriva en hel serie inlägg om. Men först ska jag till Agile Tour Vilnius och prata lite.

De usla jonglörerna

Det spelar ingen roll vad du säger i ditt CV eller på anställningsintervjun: Du är faktiskt inte bra på att hålla många bollar i luften samtidigt.

Det kan hända att du utvecklat strategier för att uppgiftsväxla mer effektivt inom vissa fält, och det kan hända att du har ett riktigt gott arbetsminne och stor förmåga att rikta uppmärksamheten. Det är naturligtvis intressant att veta, men frågan är varför du ödslar sådana förmågor på det spill som kallas uppgiftsväxling.

Rutinärenden kan vi automatisera i våra hjärnor och vi behöver därmed inte blanda in så mycket av vårt medvetna tänkande. Om vi gör något som tar vissa sinnen i bruk gör det inte så mycket om vi samtidigt gör något som tar andra sinnen i bruk. Det går med andra ord att lyssna på radio och vika tvätt samtidigt. Vi kan klara oss med partiell uppmärksamhet på varje uppgift.

Men ska vi göra två saker samtidigt, och dessa tar samma hjärnresurser i anspråk, så tvingas vi till ständig uppgiftsväxling mellan dem. En uppgiftsväxling innebär att vi måste flytta uppmärksamheten till det nya, bygga upp en ny mental bild av det nya, orientera oss i den bilden för att komma på vad vi ska göra, och sedan börja göra det.

När uppgiften är kognitivt enkel och inte skiljer sig så mycket från den förra uppgiften (som t ex i Henrik Knibergs namnskyltsexperiment) så blir påslaget minst 20% per sak att växla mellan. Skillnaden mellan att göra två namnskyltar en i taget respektive två samtidigt är i bästa fall cirka 20%.

När uppgiften är kognitivt svår blir den nya bilden i huvudet mycket mödosam att bygga upp. När man programmerar är det ju inte ovanligt att det kan ta en timme innan man åter befinner sig i den konceptuella värld som är systemets ännu orealiserade mekanismer och kan navigera i den obehindrat.

Blir man avbruten där har man dessutom problemet att insikter man gjort mentalt men som ännu inte omvandlats till kod försvinner. Ledtiden vid växling består alltså inte bara av att bygga upp det nya, utan även av att snabbt förpacka sammanhanget kring den befintliga uppgiften på ett sätt som inte gör tiden runt den förspilld.

En av vinsterna med att synliggöra sina flöden är att det går att börja kontrollera dem. Största orsaken till att vi tvingas jonglera mellan flera saker är att flödena har utformats tryckande. De har troligen inte utformats medvetet tryckande, men effekten av designen har blivit sådan. Arbetsuppgifterna ramlar på folk, likt bilar som utan att behöva köa i god ordning kör fram till betjäningsluckor lite hursomhelst.

Men genom att synliggöra sina flöden kan man se var uppgiftsväxlingarna uppstår så att det är möjligt att göra sig av med dem. Systemen måste göras dragande. Och när man synliggjort flödena börjar folk se på vilket sätt de samverkar i flödena. Att balansera arbetsbördor, att utforma strategier för hur man skyddar varandra från händelsestyrt arbete, det blir kort sagt möjligt att styra arbetet överhuvudtaget.

Och man gör sig av med den enorma produktivitetsförlust som uppgiftsväxling och samtidigt arbete utgör.

Begränsa er och bli bättre

Ett sätt att balansera sina flöden är att begränsa antalet samtidigt pågående ärenden i dem. "Limit Work In Progress (WIP)" som det heter. Detta är kontraintuitivt för många: hur kan en begränsning av antalet samtidiga ärenden förbättra flödets förmåga att leverera?

Svaret är trefalt: dels finns det en matematisk (köteoretisk) verklighet som inte bryr sig om våra intuitioner, dels är vi människor ytterst dåliga på att ha många saker igång samtidigt eftersom vi måste aktivt flytta vårt fokus mellan dem, och dels ökar många samtidiga ärenden systemrisken såpass mycket att saker brakar ihop för oss mycket oftare än när vi gör en sak i taget.

Köteori och begränsningar av pågående arbete

Agilisten David Lowe (stolt medlem av Sällskapet För Begränsandet Av Pågående Arbete har gjort en liten film som visar den matematiska sidan av saken:

Scenen är en servering för bilburna där folk i bilar i tur och ordning beställer, betalar, och får sin mat, i tre olika luckor. Luckorna tar olika lång tid, där den sista luckan tar längst tid: 40 sekunder (de övriga tar 20 respektive 30 sekunder). Tillåter du en bil i taget genom hela systemet blir den totala omloppstiden summan av alla luckor: 90 sekunder. Kötiden mellan luckorna är ju noll eftersom alla bara väntar på nästa bil. 90 sekunder är den kortast möjliga omloppstiden.

Genomströmningen är dock bara en bil per 90 sekunder. Kan man inte tjäna mer genom att tillåta fler samtidigt? Filmen visar vad som händer i systemet med olika begränsningar. Man kan konstatera att genomströmningen aldrig blir högre än flaskhalsen, den sista luckan som tar 40 sekunder. En kund var 40:e sekund är systemets maximala kapacitet.

Däremot ökar omloppstiden dramatiskt när man släpper in fler i systemet, eftersom köerna mellan luckorna växer. Med fem samtidiga bilar får du vänta i flera minuter, till största delen i kön till betalningen. Detta utan att systemet förmår hjälpa fler. Ett optimum nås runt 2-3 samtidiga.

Att begränsa antalet bilar i systemet kan alltså förbättra flödet på olika sätt. Notera dock att förmågan att hitta ett optimum förutsätter ett välordnat flöde till att börja med. Tjänsterna i luckorna levereras inom en stabil tid ("is under statistical control" som Deming skulle sagt), och den smala asfaltsremsan gör att ingen bil kan köra fram utan att det först finns en lucka framför att köra fram i (systemet är alltså dragande).

Varierar tjänstetiden och flera bilar kan köra fram till samma lucka samtidigt (systemet är tryckande) är funderingen kring optimala begränsningar i systemet helt meningslösa. Man måste först skapa ett förutsägbart dragande system för att kunna räkna på det. Stabilitet först, utjämning sedan.

I senare poster tänkte jag tala om nästa aspekt av att inte begränsa sig: vår bristande mänskliga förmåga att hålla flera bollar i luften samtidigt.

Sluta börja, börja sluta

OK, så vi har ett flöde där det ena steget trycker på fler ärenden än det andra steget klarar av. Det riskerar att bli en kö av ansamlingen av ärenden, och att blint öka resurserna i vår del av flödet hjälper inte helheten. Vad ska vi göra?

Första steget är att titta från höger. Tänk dig att flödet går från vänster till höger. Längst ut till höger är en glad människa. Det är för den människans skull flödet alls finns. Den människan blir inte glad för att flödet börjar att behandla en massa ärenden. Den människan blir inte glad för att ett visst steg i flödet börjar samla på sig ärenden i en väntekö. Den människan blir inte ens glad om bara delar av flödet blir bättre på att hantera sina ärenden. Den människan blir bara glad om förbättringen leder till att värdet kommer henne till del.

Så vad kan vi göra för att ta bort de sista hindren? De som hindrar ärendena från att ta det sista klivet till FÄRDIGT? Sedan: vad kan vi göra för att ta bort de näst sista hindren? De som hindrar ärendena från att ta det näst sista klivet till steget omedelbart innan FÄRDIGT? Och så vidare...

Att ha många saker på gång samtidigt ger en känsla av upptagenhet. Vi förväxlar gärna den känslan med en känsla av produktivitet. Men produktiva organisationer är organisationer där man inte har en massa saker igång samtidigt. Känslan i en produktiv organisation kan tvärtom vara rätt sömnig. Men det är ju för att man har sina saker under kontroll. Man levererar i ett stadigt tempo utan detta gigantiska spill som består i att försöka ha många saker igång samtidigt.

Henrik Kniberg har skapat ett enkelt experiment som avslöjar hur mycket omställningstid som förbrukas när en verksamhet försöker göra flera saker samtidigt. Jag har själv kört det experimentet som en övning på mängder av kurser, och resultatet är hela tiden det samma: När man har några parallella projekt igång blir tidsåtgången minst den dubbla jämfört med om man skulle göra en sak i taget.

Genom att börja från höger och metodiskt arbeta bort alla hinder för att leverera färdiga ärenden så ökas genomströmningen och väntan i flödet försvinner, ett steg i taget. Vi tittade på hur kapacitetsökningar i allmänhet är dåliga på att förbättra hela flöden. Att arbeta metodiskt från "höger", dvs från flödets mål: den nöjda människan, är däremot bra. Ha fokus på att avsluta ärenden, att få dem färdiga. Ha inte fokus på att påbörja många saker.

I nästa inlägg ska jag beskriva hur man kan begränsa antalet ärenden som får lov att befinna sig i varje steg, och hur den stelbentheten tvingar fram ett snabbare flöde.

Den fåfänga kapacitetsökningen

Om ett steg i ett flöde får ärenden i snabbare takt än det hinner behandla dem uppstår som sagt ansamlingar som vi tvingas hantera. Vi såg i en tidigare post hur köer är ett dyrt sätt att hantera dem. Är det bättre att öka kapaciteten?

Det är i alla fall lätt att dra slutsatsen att steget har för låg kapacitet. Att öka kapaciteten (tillföra mer resurser av något slag) är en förståelig impuls. Problemet är bara att detta inte nödvändigtvis gör hela flödet bättre. Den glada människan i slutet av flödet blir inte lyckligare av att en liten del av flödet fungerar något bättre. Det är färdiga saker som ger värde. Saker som ramlar ut i slutet av flödet.

Ökas kapaciteten i ditt steg kanske du överproducerar och skapar en ansamling inför nästa steg. Då har du egentligen inte löst någonting, bara flyttat problemet ett snäpp åt höger. Till en kostnaden av kapacitetsökningen dessutom.

Ökas kapaciteten i hela flödet ("Vi anslår mer resurser till hela verksamheten!") kan det hända att du får totalt sett mer ut av det. Men det är långt ifrån säkert! Om flödet i princip ser ut som tidigare, fast har en jämnt fördelad ökning av kapaciteter på olika håll, kommer du inte bara att producera mer nyttigheter utan även mer spill. Detta kan leda till överlast som blockerar än mer, så att slutresultatet är värre än innan.

Flöden är komplexa saker, och flaskhalsar flyttas runt när obalanser får systemet att skaka. Utfallet är inte linjärt mot insatsen. Man kan säga att alla obalanserade flöden lider av konstant resursbrist, oavsett den totala mängden resurser, eftersom någon del alltid kommer att vara underdimensionerad i förhållande till sina grannar.

Det rätta sättet att hantera den lokala kapacitetsbristen är att jämna ut flödet. Balansera det. Hur det kan gå till tänkte jag beskriva som nästa strategi.

Köer

Lite mer om flöden (fortsättning på detta inlägg) då...

Om varje steg i ett flöde jobbar dragande, dvs drar ärenden från steget innan, så blir inget steg överlastat, och flödet blir utjämnat (både överlast och ojämnhet är ju kända källor till spill).

Men flödena startar någonstans. Ärenden skapas utan hänsyn till flödets faktiska kapacitet. Det är inte akutintaget som bestämmer antalet patienter, utan den mängd olyckor och plötsliga sjukdomsfall som sker. Beställningar om ändrad systemfunktionalitet kan komma plötsligt och vara mycket högt prioriterade. Och flödet kan även själv innehålla steg som på samma sätt trycker ärenden till andra.

När ett steg agerar tryckande i en snabbare takt än vad nästa steg hinner med att behandla uppstår en ansamling av ärenden. Den måste man hantera. Jag tänkte beskriva några strategier i denna och kommande poster, tillsammans med kommentarer.

Kö - En kö är en ansamling där man säger att det ärende som väntat längst ska behandlas först. Man betar av dem i turordning. Denna strategi kan uppfattas som rättvis, eftersom kapacitetsbristen drabbar alla ärenden lika. En annan upplevd fördel är att kön är ett bevis på att nyttjandegraden av stegets resurser är 100%. Primitiva suboptimerande ekonomiska modeller ser lägre nyttjandegrad som spill och föredrar istället köer. Problemet är att värdet i ärenden som har en kortare genomströmningstid ofta är många gånger högre än ärenden som måste vänta; varför man snabbt förlorar stort på denna "besparing".

Grundproblemet är förstås att modellen bara beaktar flödets kostnader, utan att ställa dem i relation till flödets värdeproduktion. Att optimera på att resurserna ska vara tillgängliga så mycket som möjligt är ofta bättre. Att lägga ärenden i en kö är inte sällan den sämsta strategin. Om flödet består av flera steg där varje steg är överlastat på detta sätt, kommer ett ärende ha enormt långa ledtider där ärendet tvingas vänta på att tas omhand.

Och väntan, när ingen ökar värdet på ärendet utan det bara ligger och skräpar, är som bekant spill.

Bilden är från Boxoid och visar en resurs - en väg - som har en nyttjandegrad på nästan 100%. Varenda kvadratmeter av asfalten är täckt av bil. Visst måste det vara effektivt?