Planview-bloggen

Din väg till smidighet i affärsverksamheten

Work Management för team

Begränsningar för WIP: Hur man reser säkert in i det okända (del 1 av 3)

Publicerad Av Stephen Franklin

Det låter motintuitivt, men om du begränsar ditt pågående arbete (WIP) förbättras faktiskt ditt flöde - och teamets produktivitet. I den här tredelade serien förklarar Stephen Franklin, CIO på Planview AgilePlace, utifrån sin erfarenhet de vanligaste hindren som du möter när du fastställer WIP-gränser och tips för att övervinna dem. 

Missade deadlines, ständiga byten av arbetsuppgifter och ineffektiva överlämningar är bara några av konsekvenserna av att ha för mycket pågående arbete (WIP). Under min karriär inom IT har jag själv sett de skadliga effekterna av att jonglera med för många bollar samtidigt, oavsett om det är på personlig nivå, i teamet eller på organisationsnivå. Jag har sett flodvågor av WIP som helt och hållet har dränkt hela organisationer. Jag har också sett hur effektivt det kan vara när team och organisationer tillämpar WIP-gränser och blir hyperproduktiva genom att fokusera sin uppmärksamhet på det arbete som är viktigast.

Att införa gränser för WIP är inte lätt och kan kännas som en resa in i det okända. Du måste vara beredd på vad som väntar, motstå frestelsen att vända om och vara fokuserad på att nå ditt mål. Med uthållighet kan man uppnå betydande förbättringar. Den här bloggserien i tre delar kommer att fungera som en guide.

Vad är WIP egentligen?

Innan vi diskuterar WIP-gränserna ska vi backa tillbaka en stund och definiera WIP. Enligt definitionen av tillverkningsindustrin avser "pågående arbete" alla material och delvis färdiga produkter som befinner sig i olika stadier av processen; råvaror i början av produktcykeln och färdiga produkter i slutet av produktcykeln ingår alltså inte.

I kunskapsarbete innebär detta vanligtvis en efterfrågan på värde som har påbörjats men som ännu inte ger kunden något värde. I princip är det en investering som inte ger någon avkastning och som minskar i värde med tiden.

Oavsett definition är det skadligt för alla system som levererar kundvärde att ha stora mängder arbete i process. Inom tillverkningsindustrin handlar Kanban om att optimera flödet av arbete genom systemet, påskynda leveransen av värde till kunden och undvika slöseri med lager av pågående arbete. Samma principer gäller för kunskapsarbete: snabb leverans av värde till kunden och en minskning av mängden oavslutade arbeten i processen, som kan täppa till systemet och skapa flaskhalsar och hinder för flödet.

Varför är WIP-gränser viktiga?

Att begränsa WIP och tillämpa WIP-gränser kräver att vi förstår effekterna av våra åtgärder på systemet som helhet.  Mängden pågående arbete måste anpassas till systemets totala kapacitet för att säkerställa ett flytande och konsekvent flöde.

Vi måste redan på förhand överväga hur nya arbetsuppgifter påverkar processer i efterföljande led så att vi inte oavsiktligt orsakar flaskhalsar som gör systemet långsammare.

Eftersom vårt primära mål är att leverera värde till kunden kan detta leda till att inte introducerar nytt arbete i systemet, vilket kan leda till - gasp - att teammedlemmar inte är på 100 % av sin kapacitet. Det är där det börjar bli svårt. Det ligger helt enkelt inte i vårt DNA att tänka på detta sätt. Trötid?! Som människor är vi betingade att sätta likhetstecken mellan personlig användning och produktivitet.

Varför är WIP-gränserna så svåra för oss?

Vi är i grunden programmerade att agera i vårt eget intresse. Fram till den industriella revolutionen arbetade människor i mindre beroende och mindre komplexa system där individuell produktivitet var mer anpassad till prestationer. Komplexiteten i dagens system har gjort att vi inte längre är i samklang med vår natur. För de flesta av oss har våra utbildningssystem inte heller gjort mycket för att hjälpa till; från tidig ålder har vi utvärderats utifrån individuella prestationer. Det sociala trycket bidrar ytterligare till vår önskan att belöna de individer som är mest aktiva och arbetar hårdast.

Det här är bara toppen av isberget när det gäller att förstå varför det är en konflikt med oss själva att begränsa WIP. När WIP-gränser införs på grupp- och organisationsnivå blir det exponentiellt svårare. På dessa nivåer har vi också att göra med ytterligare komplikationer i form av mänskliga interaktioner och interpersonell dynamik. För organisationer som inte förstår, tar till sig och främjar systemtänkande kan vi bara säga att det kan bli rörigt.

Finns det något vi kan göra för att göra det lättare att begränsa WIP?

Ja, det är inte förvånande att de flesta människor till en början motsätter sig tanken på att begränsa WIP. Det kräver en förändring i tankesättet som går emot den mänskliga naturen och som gör att människor inte längre har en "lokal effektivitetsfördom".

Vi kan övervinna detta, men förlorar inte hoppet. Nyckeln till framgång ligger i att förstå hur systemen fungerar. Människor måste lära sig att vara medvetna om hur deras handlingar påverkar systemet. Kunskap, förståelse och praktik kan hjälpa oss att ändra vårt beteende.

Allt som är svårt kräver tid, engagemang, tålamod och uthållighet. Begränsningar av WIP är en evolutionär resa, och du kommer att lära dig mycket på vägen. Människor och team kommer att tvingas ut ur sina bekvämlighetszoner. Det kommer att finnas ojämnheter på vägen, och ibland kommer du att gå tillbaka. Men för de individer, team och organisationer som börjar se kraften i att begränsa WIP och värdet av det fokus och den klarhet som det ger, kommer omvandlingen att bli fantastisk.

I mitt nästa inlägg kommer jag att diskutera några av de vanliga, vardagliga hinder som vi möter i vår strävan att begränsa det arbete som vi har under bearbetning. Jag kommer att titta på hur de första stegen i Kanbans mognadsmodell ger ett bra ramverk för att minska WIP. Jag kommer också att utforska några av de lärdomar som jag har dragit på vägen och ge dig några praktiska råd som hjälper dig att hålla dig på rätt spår när det gäller WIP-gränserna.

Relaterade inlägg

Skrivet av Stephen Franklin

Stephen Franklin är CIO och medgrundare av LeanKit. Innan LeanKit ledde han utvecklingsteam som praktiserade Lean och Kanban som domänarkitekt på Healthtrust Purchasing Group och som Chief Software Architect på eDoc4u. Följ Stephen på Twitter @leankitstephen.