Lean no és fer les coses més ràpid: és fer-ne menys

Toyota, després de la guerra, no tenia diners per competir amb Ford. Ford podia plantar-se amb línies gegantes, estocs enormes i produir a un volum que amortitzava qualsevol ineficiència. Toyota no. Tenia poc capital, poc espai i un mercat japonès massa petit per absorbir els lots grans que feien rendibles les fàbriques americanes. Taiichi Ohno, l’enginyer que hi va passar dècades, es va fer una pregunta diferent de la que es feia tothom més: en lloc de «com produïm més», «què estem fent que el client no pagaria si el veiés fer-se».

Aquesta pregunta és Lean sencer. Tot el que ve després, els pilars, les tècniques, els acrònims japonesos, és una manera de respondre-la de forma sistemàtica.

Què és, exactament, una pèrdua

Toyota en diu muda, i la defineix així: tot el que no sigui la quantitat mínima absolutament necessària d’equip, materials, peces, espai i temps de l’operari per afegir valor. No és «allò que no fa res». És «allò que fa alguna cosa, però que el client mai pagaria si li ho poguessis ensenyar per separat».

Un transport de tres quilòmetres dins la fàbrica costa diners de veritat, ocupa gent de veritat i triga temps de veritat. Però el client no compra «transport». Compra el producte acabat. Si li poguessis vendre el mateix producte sense aquest trajecte, no en notaria la diferència, i el preu li seria igual de bé. Aquest és el test: si treure-ho no canvia el que el client rep, era muda.

Aquí hi ha un matís que sol perdre’s quan algú explica Lean de pressa: no tota activitat que no afegeix valor és eliminable. Toyota en distingeix tres tipus:

• Activitat amb valor afegit. Transforma el producte de manera que el client ho reconeix i hi hauria d’estar disposat a pagar.
• Activitat necessària sense valor afegit. No canvia res que el client vegi, però el sistema no pot funcionar sense ella amb la tecnologia i les normes actuals. Un control de qualitat obligatori. Una revisió de seguretat. Una declaració fiscal.
• Pèrdua pura. No aporta res i, a més, es podria treure ara mateix sense que ningú se n’adonés.

Confondre el segon tram amb el tercer és l’error més freqüent quan algú aplica Lean sense el matís: es carrega un control que hi és per una raó real, i el problema torna disfressat de nou, uns mesos després, amb un cost superior al que s’havia estalviat.

Les set pèrdues, i la que les causa totes

Ohno va catalogar set formes en què apareix la pèrdua a qualsevol procés productiu, i encara es fan servir tal qual: sobreproducció, espera, transport, sobreprocessament, estoc, moviment i defectes.

El detall que sol quedar-se fora quan algú les llista és que Ohno no les considerava set problemes independents. En considerava una de sola, la sobreproducció, com la pitjor amb diferència, perquè és la que genera la resta. Produir més del que cal ara mateix vol dir que aquest excés s’ha d’emmagatzemar (estoc), s’ha de moure i vigilar (transport i moviment), i mentre espera, amaga qualsevol defecte que hi hagi (perquè ningú el revisa fins que arriba el seu torn). Les altres sis pèrdues, en bona part, són conseqüència d’aquesta primera.

És una idea que es trasllada bé fora d’una fàbrica: un informe que ningú ha demanat, una funcionalitat que es construeix «per si de cas», una reunió convocada per si algú hi vol dir alguna cosa. No costen només el temps de fer-los. Costen tot el que generen després: qui els ha de revisar, on s’han de guardar, qui els ha de mantenir actualitzats encara que ja no serveixin.

Mura i muri: per què la pèrdua torna

Eliminar una pèrdua un cop no la manté fora. Toyota hi afegeix dos conceptes més, i tots dos expliquen per què.

Mura és la variabilitat: fer una mateixa tasca de maneres diferents segons qui la faci, quin dia sigui o com estigui d’ocupat qui la fa. On hi ha mura, els temps de procés, la qualitat i la càrrega de feina ballen sense patró, i aquest ball genera pèrdua nova constantment, encara que ahir l’haguessis eliminat.

Muri és l’exigència injustificada: fer una activitat d’una manera concreta sense cap altra raó que «sempre s’ha fet així». No és que estigui mal fet, és que ningú ha tornat a preguntar per què es fa d’aquesta manera des que algú ho va decidir fa anys.

Per això Toyota no ataca només la pèrdua visible. Ataca la variabilitat i les exigències sense raó que la tornen a generar. Un procés estandarditzat (que tothom el faci igual) i revisat de tant en tant (que ningú el faci «perquè sempre ha estat així») és el que fa que una millora s’aguanti mesos després, en lloc de tornar a l’estat inicial al cap de sis setmanes.

Els dos pilars que ho sostenen

El sistema de producció de Toyota se sol dibuixar com una casa, i la imatge, tot i ser una mica de manual, funciona. A la base hi ha un terra estable: processos estandarditzats, gestió visual (qualsevol persona ha de poder veure d’un cop d’ull si un procés va bé o malament) i producció anivellada, és a dir, repartir la feina de manera constant en lloc d’alternar setmanes buides amb setmanes de pic. Sense aquesta base, no hi ha res a sobre que s’aguanti.

Damunt, dos pilars.

Just in Time: produir exactament el que cal, quan cal, en la quantitat que cal. Ni abans (perquè aleshores és estoc, que és pèrdua) ni després (perquè aleshores el client espera, que també és pèrdua). És el sistema que «estira» la producció des de la demanda real, en lloc d’«empènyer-la» des d’una previsió.

Jidoka: sovint traduït com «automatització amb toc humà». La idea és que qualsevol part del sistema, una màquina o una persona, ha de poder aturar el procés en el moment que detecta un problema, en lloc de deixar-lo passar avall i que el defecte s’acumuli invisible fins que arriba al client. Ohno ho comparava amb un equip de beisbol: el Jidoka és l’habilitat dels jugadors, el Just in Time és la jugada que decideixen fer amb aquesta habilitat. Cap dels dos serveix de res sense l’altre.

Anar a veure-ho, no preguntar-ho

Dins del pilar del Jidoka hi ha una pràctica que val la pena separar de la resta perquè és, de totes, la que faig servir més sovint jo mateix: genchi genbutsu, «anar al lloc real i veure la cosa real». A Toyota vol dir que, quan hi ha un problema a la línia, ningú el resol des d’un despatx amb un informe al davant. Algú hi va físicament, mira la peça, mira la màquina, parla amb qui hi és cada dia.

En processos d’oficina, l’equivalent és seure amb la persona que fa la feina i mirar-la treballar, en lloc de demanar-li que t’expliqui el procés de memòria. Gairebé sempre hi ha una diferència entre el que algú diu que fa i el que fa de veritat, i aquesta diferència sol ser exactament on viu el problema. Un manual diu «es valida la comanda»; mirant-ho en directe, descobreixes que la validació real és que la Marta obre un segon full de càlcul que ningú més coneix, perquè fa tres anys el sistema oficial es va equivocar un cop i des d’aleshores no se’n refia.

Quan finalment identifiques la causa d’un problema, Toyota hi aplica una altra pràctica senzilla i eficaç a parts iguals: els cinc perquès. Preguntar «per què» repetidament sobre la mateixa causa, no un cop, cinc, fins que la resposta deixi de ser una altra persona o un altre departament i comenci a ser un fet del sistema. «Per què ha arribat tard la factura?» Perquè l’aprovació ha trigat tres dies. Per què ha trigat tres dies? Perquè qui l’havia d’aprovar era fora. Per què no hi havia ningú més que pogués fer-ho? Perquè el procés només preveu un aprovador. Per què només un? Perquè quan es va dissenyar, l’empresa tenia dues persones al departament. Cinc preguntes més tard, el problema ja no és «en Joan estava de vacances», és «el procés no té substitut previst», que és un problema diferent, i l’únic que val la pena arreglar de veritat.

Com es millora de veritat: petit i verificat

Lean no assumeix que trobaràs la solució correcta al primer intent. Assumeix el contrari: que qualsevol canvi és una hipòtesi, i que cal comprovar-la abans de generalitzar-la. Per això Toyota adopta el cicle que William Edwards Deming va popularitzar (i que ell mateix atribuïa al seu mentor, Walter Shewhart): planificar, fer, verificar, actuar. En anglès, PDCA.

Planifiques un canvi petit i concret. El fas a escala reduïda, no a tota l’operació de cop, perquè si surt malament, el mal que fa és petit. Verifiques amb dades si ha funcionat de veritat, no si «sembla que ha anat bé». I actues: si funciona, l’estens; si no, tornes a planificar amb el que has après.

Per què això no és cosa de fàbriques

No munto cadenes de producció. El que faig és, en el fons, la mateixa pregunta que es va fer Ohno aplicada a processos d’oficina: aquest pas, aquest informe, aquesta aprovació, el pagaria el client si el veiés fer-se? El vocabulari canvia (parlo de tiquets, no de peces; de pantalles, no de màquines), però el criteri és idèntic, i per això val la pena entendre’l bé abans d’automatitzar res.

Hi ha una temptació fàcil quan algú sent parlar de Lean per primer cop: pensar que és un manual de com córrer més. No ho és. És un manual de com preguntar-se, sistemàticament, què s’hauria de deixar de fer. Ohno no va guanyar a Ford construint cotxes més de pressa amb els mateixos recursos que Ford. Va guanyar construint-ne menys malament fets, amb menys estoc parat, menys gent esperant i menys informació que ningú necessitava. La velocitat va ser una conseqüència, no l’objectiu.

Automatitzar una pèrdua no l’elimina. Només fa que passi més ràpid, i costa diners fer-ho. Per això, abans de tocar cap eina, els dos passos que segueixo són sempre els mateixos: primer, posar tot el procés sobre la taula perquè es vegi sencer, no a trossos. Després, mirar-lo amb la lupa de les mudes i decidir què és valor, què és necessari encara que no ho sembli, i què és, simplement, el que sobra. El primer pas el faig amb SIPOC i post-its. El segon és el tema del pròxim article.