Där jag i texten använder omställningskostnad kan man lika gärna använda termen transaktionskostnad.

En mängd delar behöver samspela för att vi ska kunna uppnå ”Maximalt värde med kortast möjliga hållbara ledtider”.

När vi förstår hur delarna förhåller sig till varandra är vi också mer benägna att optimera systemet som en helhet, där 1+1 ofta blir 3, till skillnad från lokal optimering där 1+1 ibland till och med kan bli 0. SAFe princip nummer 2 är en fördjupning i de teorierna.

Relationen omställningskostnad, lagerkostnad och total kostnad och storleken på våra jobb är ett exempel på det. Genom att vi förstår och förhåller oss till samtliga av de delarna optimerar vi systemet som en helhet och 1+1 kan bli 3.

Om du är bekant med begreppen omställningskostnad och lagerkostnad kan du hoppa över följande stycke och hoppa direkt till nästa rubrik.

Omställningskostnad och lagerkostnad kan förklaras med följande exempel

Omställningskostnaden är kostnaden för att förändra status eller placering av en produkt/tjänst/feature från ett läge till ett annat, alltså inte själva kostnaden av produkten. Detta gäller både i utvecklingsprocessen som utanför utvecklingsprocessen . Lagerkostnad är kostnaden för att hålla produkten/featuren i lager i och utanför utvecklingsprocessen med allt vad det innebär, dvs lagerkostnad, lagerförfall, cost of delay (försenad effekthemtagning) mm.

När jag handlar potatis i affären är omställningskostnad den insats i tid det tar för mig i tid att gå till och från affären, alltså insatsen i tid för att flytta produkten potatis från affären till mitt hem.

Säg att jag äter potatis varje dag. Den extrema omställningskostnaden skulle vara att varje dag gå till affären och köpa de potatisar jag behöver för det dagliga intaget. Det skulle ge en mycket hög omställningskostnad men samtidigt en mycket låg storlek på batch(så liten att jag kan bära hem potatisarna i min egen ficka). Det skulle också ge minsta möjliga lagerkostnad eftersom jag gör av med samma kvantitet jag köper in varje dag och således inte behöver något lager (skafferi).

I andra änden av ytterligheterna skulle vara att ha en extremt stor batch vilket skulle driva en mycket hög lagerkostnad men samtidigt en låg omställningskostnad. Om jag istället för varje dag köper potatis gör det en gång per år genom att använda en släpkärra kan jag ta hem en stor batch till en liten omställningskostnad (i tid skulle operationen med släpet motsvara i stort sätt samma insats som den dagliga insatsen).

Men stora batchar skapar behov av lager och binder kapital vilket i fallet med potatis skulle innebära att jag behöver investera i ett större skafferi och binda upp kapital i potatis för ett år. Och det skulle också generera ett lagerförfall då potatis på lager skulle kunna börja mögla, ruttna och angripas av skadedjur vilket resulterar i att en del av potatisarna på lagret förfaller (slöseri).

För den potatisälskande personen som vill äta potatis varje dag skulle nog den optimala storleken på batchen vara runt 21 potatisar (3 per dag) vilken skulle kunna motivera en omställningskostnad på en gång per vecka (personen går till affären en gång per vecka vilket känns rimligt). Den storleken på batch är fortfarande så låg att den inte skulle leda till ett behov av att investera i lager (större skafferi) med negativa effekter som lagerförfall, uppbundet kapital i lagret med ökad totalkostnad som följd.

Total kostnad = omställningskostnad + lagerkostnad

Den optimala storleken på våra jobb (batchar) ligger i spannet på en U-kurva, det är alltså ingen exakt vetenskap. Det viktiga är att vi förstår relationen omställningskostnad och små jobb och siktar på att minimera båda inom u-kurvan – vi är inte ute efter den perfekta analysen.

Total kostnad = omställningskostnad + lagerkostnad vilket betyder att om vi sänker omställningskostnaden sänker vi också den totala kostnaden!

Den sänkta omställningskostnaden i bilden nedan gör att den optimala batch-storleken minskar och även den totala kostnaden. Se hur den prickade vertikala linjen flyttar sig till vänter när omställningskostnaden sjunker.

Leverera tidigt och ofta

Tillbaka till början av texten. En mängd delar behöver samspela för att vi ska kunna uppnå ”Maximalt värde med kortast möjliga hållbara ledtider”.

För att skapa värde med korta hållbara ledtider är vår förmåga att leverera ofta och tidigt viktigt. I lena-agil utveckling stödjer processerna det genom inkrementell och iterativ utveckling. SAFe princip nummer 1 är en fördjupning i de teorierna.

För att kunna leverera ofta och tidigt behöver vi bryta ner våra jobb i minder delar. Vi talar om att reducera storleken på våra batchar (jobb).

Lean betonar flödesoptimering (med hållbara ledtider) där små jobb (batchar) flödar snabbare i processen än stora jobb (batchar). SAFe princip nummer 6 är en fördjupning i de teorierna.

Små batchar ger en mängd fördelar. Bland annat

• Ökad förutsägbarhet
• Accelererad feedback
• Hemtagning av effekt tidigare och oftare
• Kortare ledtider
• Reducerad risk

Men det bygger på att vi har låga omställningskostnader. Den primära faktorn som möjliggör små jobb (batchar) är just en låg omställningskostnad per jobb. Om vi reducerar storleken på jobben utan att reducera omställningskostnaden blir vi tvungna att betala omställningskostnaden mer ofta vilket ökar vår totala kostnad.

Om vi bara bryter ner våra jobb till mindre batchar riskerar vi att suboptimera, dvs 1+1 blir noll. Samtidigt som vi bryter ner våra jobb måste vi också sänka våra omställningskostnader. Dvs optimera systemet som en helhet.

Om vi blir duktiga på att bryta ner våra batchar i mindre delar och tex kan utveckla en features på två veckor men bara leverera varannan månad får vi inte ut nyttan av att våra batchar är små. Vi behöver med de små batcharna samtidigt få ner omställningskostnaderna (i exemplet varannan månad).

Automatisering och DevOps är nyckeln

Nyckeln till att sänka omställningskostnaden är automatisering, DevOps och tvärfunktionella team och tåg med kompetens att leverera ”end-to-end”. Att sänka omställningskostnaden innebär vi måste fokusera på och investering i infrastruktur, automatisering, och aktiviteter som CI (Continuous Integration), DevOps, automatiserade byggen, automatiserade regretonstetser med mera.

Sammanfattning

• Små batchar gör att vi kan leverera ofta och tidigt
• Den ekonomiskt optimala batchstorleken beror både på lagerkostnad (kostnaden för försenad återkoppling, lagerförfall och försenad leverans av värde (cost of delay)) och omställningskostnaden (kostnaden för att förbereda och implementera batchen). 
• För att reducera storlek på våra batchar behöver vi sänka omställningskostnaden
• Sänker vi omställningskostnaden sänker vi också den totala kostnaden!
  • Total kostnad = omställningskostnaden + lagerkostnad
• Att sänka omställningskostnaden innebär att portfölj, tåg, team och projekt måste fokusera på och investering i infrastruktur, automatisering, och aktiviteter som CI (Continuous Integration), DevOps, automatiserade byggen, automatiserade regretionstester med mera.
• Den teoretiska optimala storleken på våra jobb (batchar) är där omställningskostnaden och lagerkostnaden möts inom spannet på en u-kurva.

Referenser

• https://www.scaledagileframework.com/safe-lean-agile-principles/
• Donald G. Reinertsen  – The Principles of Product Development Flow: Second Generation Lean Product Development  https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?crid=2KXFBEG27ECXG&keywords=don+reinertsen&qid=1581246775&sprefix=don+reiner%2Caps%2C853&sr=8-1