Săptămâna aceasta mi s-a adresat următoarea întrebarea: Cum este mai bine să limitezi cantitatea de muncă în Kanban? pentru fiecare persoană? sau pentru fiecare etapă? S-ar putea ca subiectul să prezinte interes pentru mai multă lume, motiv pentru care m-am gândit să scriu un articol.
Ce este limitarea cantității de muncă?
Limitarea cantității de muncă este una din cele șase practici ale metodologiei Kanban, și reprezintă principalul mod de a stimula debitul de cereri într-un sistem de tip trage:
- Vizualizarea fluxului de lucru,
- Limitarea cantității de muncă,
- Gestiunea fluxului de lucru,
- Politici explicite,
- Feedback regulat,
- Ameliorarea continuă bazată pe empirism și modele științifice cunoscute.
De unde a venit nevoia de a limita cantitatea de muncă?
Există mai multe motive excelente pentru care ar trebui să limităm cantitatea de muncă:
- pentru evitarea saturării globale a sistemului (teoria cozii de așteptare),
- pentru evitarea saturării locale a sistemului (teoria constrângerilor),
- pentru diminuarea variabilității sistemului (controlul statistic al procesului),
- pentru diminuarea elementelor risipitoare din sistem (activitățile fără sau cu puțină valoarea adăugată din Lean, via harta fluxului de valori),
- ș.a.m.d.
Articolul ar fi mult prea mare dacă ar fi să explic acum fiecare punct, însă voi reveni cu câte un altul pentru fiecare din motivele de mai sus.
Presupunând că există un minim de cunoștințe privind cele de mai sus, voi continua să răspund la întrebarea inițială.
Cum este mai bine să limitezi cantitatea de muncă în Kanban? pentru fiecare persoană? sau pentru fiecare etapă?
În primul rând, contează să conștientizăm ce anume dorim să optimizăm. Dacă dorim să optimizăm sistemul Kanban (debitul), atunci este bine să asociem limite etapelor de lucru din procesul stabilit. Dacă scopul este să optimizăm ciclul de producție al fiecărui individ în parte, atunci limităm cantitatea de muncă pentru fiecare persoană.
Un grup de oameni care lucrează la același produs va obține rezultate mai bune în echipă decât separat, adică, atunci când integrarea și sincronizarea lor este imbricată în activitățile zilnice. Altfel, este nevoie de încă un proces de integrare și de sincronizare, ceea ce are repercursiuni majore asupra ciclului de producție.
Atunci când vorbim despre proces, sau mai bine zis despre ameliorarea procesului, pierdem multe ocazii de a optimiza debitul.
Exemplul – limitarea muncii pentru fiecare persoană
T1
Nu există nimic în progres. Echipa se concentrează să optimizeze pentru început doar munca din etapele [Etapa 1..Etapa4]:
- Etapa 1 – pregătirea cererii
- Etapa 2 – execuția muncii
- Etapa 3 – inspecția muncii (acceptanța cu clientul)
- Etapa 4 – ameliorarea muncii (retrospectiva)
Echipa agreează că nu ar fi bine să aibă mai mult de 2 cereri afectate fiecărui membru. În cazul în care trebuie să aștepte pe o anumită cerere, există muncă de rezervă pe cea de-a doua cerere.
T2
În prima zi, fiecare își alege câte o cerere și încep s-o pregătească.
T3
Radu și Luci constată că sunt blocați pe cererile 005 și 008, motiv pentru care vor trece la cea de-a doua cerere, în așteptarea unor răspunsuri. Ion și Ana progresează mai încet, dar nu sunt blocați.
T4
Radu și Luci și-au început munca pe 004 și 011, dar au fost deblocați pe cererile 005 și 008. Astfel, 004 și 011 rămân suspendate (muncă parțial finalizată).
T5
Radu și-a terminat munca pe 005 și așteaptă ca munca să-i fie acceptată de către client. Între timp, lucrează pe 004. Luci a reușit și el să-și trimită înspre acceptanță 008-ul și continuă să pregătească 011. Ana și Ion sunt blocați pe 007 și 009. Le-a picat un server de teste, și trec la 029 și respectiv 020.
T6
005 și 008 au fost acceptate de către client. Urmează să se facă o retrospectivă (în etapa 4) pe ambele cereri separat, înainte de a le considera gata.
T7
Radu reușește să închidă 005 cu un ciclu de producție complet de 6 zile și ajunge cu 004 în acceptanță. Cu toții sunt blocați pe câte o cerere din cauza indisponibilității clientului.
T8
Clientul încă nu este disponibil să trateze 004. Abia a reuști să lucreze pe 009.
T9
Și observăm că este un fel de ambuteiaj în etapa 4 (inspecția/acceptanța clientului) – sistemul este saturat local. Însă echipa nu poate jongla cu limitele deoarece aceste constrângeri sunt pentru fiecare persoană separat, în loc să fie pentru fiecare etapă.
Exemplul – limitarea muncii pentru fiecare etapă
T1
Echipa consideră că nu va lucra niciodată pe mai mult de 6 cereri în paralel.
T2
T3
T4
T5
T6
Ne apropiem de ambuteiaj. Clientul nu poate accepta 4 cereri dintr-o dată.
T7
Echipa dispune de mai multe variante de îmbunătățire a sistemului. Eu voi prezenta 2 cazuri ipotetice.
Prima variantă
A doua variantă
Exemplu de caz în care munca poate fi limitată pentru fiecare persoană
Există însă și cazuri când un grup de oameni este considerat o echipă lucrând rareori împreună pe aceeași cerere/același proiect. Cu toate acestea, ei continuă să fie o echipă:
- au o viziune comună
- au o strategie comună,
- au o selecție a ordinii în care sunt tratate cererile făcută tot împreună,
- au retrospective comune, schimbul de cunoștințe, lecții învățate (retrospectivele nu țin de un proiect neapărat, ci de ansamblul echipei),
- etc.
Firmele de consultanță pot intra în această categorie. Să spunem că avem o firmă cu 4 formatori. Împreună, ei se autoguvernează, fiind și acționarii firmei. Ei au o viziune comună, o strategie și-și vor filtra și ordona cererile de cursuri împreună. Însă rareori se întâmplă să țină cursuri împreună și fiecare își urmărește debitul propriu, în funcție de tipologia prestațiilor. Cu toate acestea, în momentul în care își vor extinde spectrul Kanban, și vor include, de exemplu, ordonarea cererilor, atunci se creează un mixt între cele două tipuri de constrângeri a muncii în progres (etapă sau persoană).
Limitarea muncii în progres pentru fiecare persoană
Singura regulă eficientă pe care o văd în acest sens este: fiecare persoană lucrează la cel mult o cerere, pentru a evita diverse elemente risipitoare în proces: munca parțială, întreruperi, etc. Orice blocaj este o ocazie de învățare, dacă ne construim un stoc de rezervă, putem împiedica ameliorarea procesului.
Cum este mai bine să limitezi cantitatea de muncă în Kanban? pentru fiecare persoană? sau pentru fiecare etapă?
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 2832 ori