Il lavoro intellettuale snello

Il Sistema di produzione Toyota è certamente l’invenzione più importante in campo operativo da quando il Modello T di Henry Ford ha cominciato a uscire dalla catena di montaggio. Ha generato diversi approcci al miglioramento della produzione, tutti basati sugli stessi principi: attenzione maniacale per i dettagli, impegno nella sperimentazione guidata dai dati e attribuzione ai lavoratori del compito di migliorare costantemente l’efficienza ed eliminare gli sprechi. Questo insieme di idee viene spesso definito lean, o “snello” e oggi la maggior parte delle aziende manifatturiere e alcune società di servizi ne stanno raccogliendo i risultati.

Tuttavia, i tentativi di applicare gli approcci snelli al lavoro intellettuale si sono rivelati frustranti. Molti nel mondo del business ritengono che il lavoro intellettuale non si presti ai principi lean perché, a differenza dell’assemblaggio di automobili, non è ripetitivo e non può essere definito in termini chiari e inequivocabili. Prendiamo come esempi un bancario che decida se concedere un prestito, un ingegnere che sviluppi un nuovo prodotto, un assistente sociale che stabilisca se l’ambiente in cui un bambino sta crescendo è sicuro: in ciascuno di questi casi il lavoro richiede competenza e capacità di giudizio che dipendono fortemente da conoscenze implicite: le conoscenze immagazzinate nella mente del lavoratore.

Tuttavia, le nostre ricerche sui servizi informatici, finanziari, tecnici e legali rivelano che in effetti anche questo tipo di lavoro può beneficiare dei principi del Sistema di produzione Toyota. Per prima cosa, una quantità significativa della conoscenza che si suppone implicita non è necessariamente tale; può essere espressa e messa per iscritto se l’organizzazione fa lo sforzo di “estrarla” dalla testa delle persone. In secondo luogo, tutto il lavoro intellettuale include attività che nulla hanno a che fare con la capacità di giudizio e che possono essere sveltite insegnando ai dipendenti a cercare e sradicare costantemente gli sprechi. Anche quando la conoscenza è davvero implicita, creare sistemi e regole per guidare le interazioni fra lavoratori può portare a una collaborazione più efficace.

Nella produzione manifatturiera c’è un comune bagaglio di conoscenze condivise in merito a come rendere snella un’attività e molte delle tecniche possono essere utilizzate da organizzazioni molto diverse tra loro. Ciò non vale per il lavoro intellettuale. Abbiamo però scoperto che una qualche forma di principio snello può essere applicata a quasi tutti i generi di lavoro intellettuale e generare benefici significativi: risposte più rapide, livelli di qualità e creatività più elevati, costi inferiori, meno sfacchinate e frustrazioni e maggiori soddisfazioni sul posto di lavoro.

WIPRO LEAN

Il nostro studio più ampio sull’applicazione dei principi snelli al lavoro intellettuale coinvolge un’iniziativa ambiziosa in Wipro Technologies. L’azienda, con sede a Bangalore, India, è una delle maggiori fornitrici al mondo di servizi informatici e di ingegnerizzazione di prodotto. Ha oltre 100.000 dipendenti e 72 centri di consegna in 55 Paesi.

L’attività che abbiamo analizzato realizza complessi software personalizzati. Non assomiglia per niente a una catena di montaggio. I progetti sono assegnati a gruppi i cui membri sono scelti sulla base delle competenze necessarie per affrontare i vari compiti, che vanno dalla progettazione del software di controllo per un decodificatore digitale alla creazione di nuove piattaforme per l’e-commerce. Così come un team di avvocati lavora su un grosso caso includendo di norma persone con una vasta gamma di competenze, allo stesso modo una squadra di programmatori in Wipro è composta da dipendenti con esperienze molto variegate. Alcuni sono navigati, altri stanno muovendo i primi passi; alcuni sono molto specializzati, altri hanno conoscenze generali; alcuni contribuiscono con sostegno e supervisione, mentre altri eseguono il lavoro. Ottengono soluzioni scambiandosi idee e provandole.

Nel 2004 diverse sfide hanno spinto Wipro a iniziare percorso per diventare lean. La necessità di dipendenti molto specializzati stava aumentando, insieme al turnover causato da una forte richiesta nel settore. Erano finiti i giorni in cui l’azienda era in grado di competere grazie al basso costo del lavoro. Non poteva nemmeno continuare a competere sulla base di una qualità superiore: i concorrenti principali si erano portati al suo livello. Alla ricerca di un vantaggio sostenibile, i leader di Wipro hanno deciso di costruire un sistema snello. Si rendevano conto che questo approccio non era stato testato con il lavoro intellettuale e che avrebbe richiesto una trasformazione profonda in azienda, ma ritenevano che il gioco valesse la candela, alla luce del ritorno possibile: la capacità di migliorare più rapidamente dei concorrenti.

I manager di Wipro non riuscivano a trovare aziende che avessero impiegato delle tecniche snelle per produrre software personalizzato su vasta scala. E hanno scoperto che anche i principali consulenti strategici mancavano di esperienze significative in questo campo. Così, Sambuddha Deb, l’alto dirigente responsabile operativo, ha riunito altri nove manager Wipro. Il gruppo si è raccolto attorno a un tavolo e si è posto una semplice domanda: «Come facciamo?». La risposta è stata: «Ci auto-educheremo. Troveremo le idee per adattare l’approccio snello alla produzione software su vasta scala, e le metteremo alla prova».

I manager hanno iniziato a studiare come l’approccio snello era stato applicato alla produzione industriale. Hanno esaminato attentamente tutto il materiale scritto che sono riusciti a trovare, visitato le fabbriche snelle e parlato con un ex guru di Toyota. Hanno organizzato brainstorming per decidere come usare ciò che avevano imparato; ciascuno ha scelto un progetto esistente su cui testare le idee. Poco alla volta hanno identificato le pratiche che funzionavano.

Abbiamo studiato questa vicenda sin da principio e analizzato i risultati di 1883 progetti Wipro che prevedevano complesse ingegnerizzazioni di prodotto o la creazione di soluzioni informatiche. Tra questi progetti, 772 avevano usato un approccio “snello”, a differenza degli altri 1.111. Ne abbiamo anche osservati molti in corso di svolgimento.

Rendere snella un’attività è un viaggio che dura molti anni, non una rivoluzione istantanea, ma nonostante ciò abbiamo verificato che l’approccio snello sta già avendo un impatto significativo. I progetti snelli che abbiamo studiato non risultavano migliori degli altri quanto a qualità (difetti ed errori), forse perché gli standard erano già alti, ma producevano risultati superiori in termini di tempi e costi. In media i progetti snelli venivano completati in un tempo inferiore del 5% rispetto alle previsioni, mentre gli altri progetti di norma si concludevano alla data prevista. E i progetti snelli costavano il 9% in meno del budget preventivato, gli altri solo il 2% in meno. (Per ulteriori dettagli sui risultati, vedi Lean Principles, Learning, and Knowledge Work: Evidence from a Software Service Provider, di Bradley R. Staats, David James Brunner e David M. Upton, Journal of Operations Management, luglio 2011.)

Prendendo spunto dalla ricerca in Wipro, abbiamo delineato alcuni principi per rendere snelle le attività intellettuali. Abbiamo affinato le nostre idee dopo avere esaminato la letteratura esistente sulla produzione snella (per un articolo particolarmente utile, vedi Decoding the DNA of the Toyota Production System, di Steven J. Spear e H. Kent Bowen, HBR, settembre-ottobre 1999) e studiato gli esperimenti di “snellimento” in ambienti di lavoro intellettuale. Alla fine abbiamo elaborato sei principi, che descriveremo di seguito in dettaglio. Utilizzandoli, i manager possono creare gli approcci snelli personalizzati che si adattano meglio alla loro organizzazione.

ELIMINARE GLI SPRECHI

Taiichi Ohno, il principale artefice del sistema Toyota, diceva che esistono “sette sprechi” che tutti, nelle attività manifatturiere devono sforzarsi di eliminare: sovrapproduzione; movimentazioni non necessarie; scorte e spostamenti dei lavoratori; difetti; lavorazioni in eccesso; tempi morti. Le tipiche sedi del lavoro intellettuale sono piene di questi sprechi. In realtà il lavoro intellettuale comprende molte attività di routine che non richiedono capacità di giudizio o competenze e che possono divorare enormi quantità di tempo: la stampa di documenti, la richiesta delle informazioni necessarie per prendere una decisione, l’organizzazione di riunioni, per citarne solo alcune.

Abbiamo scoperto che i lavoratori intellettuali tendono a sottostimare enormemente la quantità di inefficienza che potrebbe essere eliminata dal loro lavoro. La chiave sta nel far sì che tutti nell’organizzazione rendano sistematicamente visibile lo spreco e che facciano qualcosa per eliminarlo. Ecco come coinvolgere le persone nella causa:

Insegnare a tutti a domandarsi i “cinque perché”. Lo spreco diventa evidente una volta esplicitato, ma scovarlo non è sempre facile perché di solito fa parte del paesaggio da molto tempo. Il rimedio: anziché dare per scontato che l’approccio usato per un processo sia corretto, presumere che sia sbagliato. Per far ciò, i manager di Toyota hanno inventato i “cinque perché”: il procedimento consiste nel porsi continuamente domande finché non si raggiunge la causa ultima di ogni attività eseguita. Perché partecipo a questa riunione? Perché sto scrivendo questa relazione? Perché me ne sto davanti alla stampante?

Quando un team di Wipro, i cui progetti erano in ritardo rispetto alla tabella di marcia, ha svolto questo esercizio ha scoperto in primo luogo che i suoi membri stavano continuando a risolvere sempre lo stesso problema. Le domande successive hanno rivelato una questione più grave: la squadra era talmente impegnata a cercare di non consegnare in ritardo che stava tralasciando di creare soluzioni standard e di addestrare il suo personale. In questo modo solo alcuni dei membri avevano le competenze per affrontare una varietà di problemi diversi. Come risposta, il team ha rivisto il progetto lungo linee funzionali, ha nominato dei leader e vice-leader per ogni funzione e li ha resi responsabili della creazione di soluzioni standard e dell’addestramento di altri membri della squadra. Il personale è stato fatto ruotare tra le diverse funzioni ogni trimestre per essere certi che ognuno acquisisse competenze più diversificate. Inizialmente queste misure hanno aumentato il tempo necessario a eseguire il lavoro, ma presto il team è stato in grado di velocizzarsi e ha consegnato il progetto entro i tempi previsti.

Incoraggiare tutti a trovare anche le più piccole forme di spreco, non solo le più grandi. Le aziende di maggior successo hanno già eliminato le forme di spreco più macroscopiche ed evidenti, ma i pavimenti delle attività intellettuali sono spesso coperti di centesimi che nessuno si è preso la briga di raccogliere. Pensate al vostro stesso posto di lavoro. Quante email intasano la casella di posta elettronica perché qualcuno vi ha messo in copia senza che fosse necessario? Quanto avete dovuto aspettare prima di iniziare una riunione regolarmente programmata perché i partecipanti sono arrivati alla spicciolata? Quante relazioni vengono scritte e mai lette?

Per identificare e sradicare in modo costante lo spreco, un’organizzazione deve imparare a preoccuparsi delle piccole cose. Ciò significa aiutare le persone a vedere quanto spreco le circonda e a capire che eliminandolo saranno libere di dedicarsi a un lavoro più proficuo (e gratificante). Significa applicare i “cinque perché” a ogni cosa. E significa dedicare tempo e altre risorse all’eliminazione dello spreco.

Un team di progetto che abbiamo osservato all’inizio del viaggio di Wipro sapeva di dover identificare le fonti di spreco più piccole, ma non sapeva esattamente come. Ha deciso di usare una mappa della catena del valore per dare al processo la spinta iniziale. Una mappa della catena del valore non cattura soltanto i singoli stadi dettagliati di un progetto in corso, ma identifica anche il valore aggiunto e lo spreco. La squadra deve indicare ogni passo che compie e chiedersi: «Perché l’abbiamo fatto?». Ciò le permette di creare un elenco degli elementi da eliminare secondo una scala di priorità.

Il team che abbiamo studiato stava sviluppando dei driver per stampanti (i software che le fanno funzionare). Man mano che scrivevano il codice, i membri lo provavano su una stampante. La mappatura della catena del valore ha evidenziato diverse forme di spreco. Per esempio, ognuna delle quattro persone che usavano la stessa stampante spesso si ritrovava ad aspettare l’esito del proprio test in piedi accanto alla macchina mentre questa lo stampava. La frequente rotazione tra gli utenti implicava anche che trascorressero molto tempo regolando i settaggi della stampante secondo le proprie necessità specifiche. E siccome la stampate si trovava a un piano diverso dell’edificio, tutti e quattro correvano in continuazione su e giù per le scale, impiegando dai cinque a dieci minuti per viaggio.

Avendo evidenziato queste forme di spreco, il team ha trasferito la stampante e destinato delle fasce orarie a ciascun utilizzatore. Questi e molti altri piccoli cambiamenti hanno permesso di dedicare molto più tempo al lavoro vero e proprio.

Rivedere periodicamente la struttura e il contenuto di ogni mansione. Molte mansioni di lavoro intellettuale sono vaghe e non strutturate. Tendono a espandersi gradualmente con l’aggiunta di un’attività dopo l’altra. Le persone finiscono per avere troppo da fare e per dover dedicare troppo tempo a compiti di basso livello.

I manager dovrebbero valutare con regolarità i compiti dei loro dipendenti, compresi i tempi richiesti per lo svolgimento. Un’organizzazione dedicata allo sviluppo di prodotto ha intrapreso questa revisione e scoperto che la lentezza nello svolgere i compiti, l’inadeguatezza nell’assegnare priorità d’incarico e la mancanza di comprensione rispetto alla composizione del carico di lavoro aveva creato una situazione in cui i suoi tecnici avevano mediamente il doppio del lavoro che potevano realisticamente eseguire. Ciò causava gravi intasamenti nel lavoro, un’alternanza eccessiva tra compiti diversi, il mancato rispetto delle date di scadenza e l’esaurimento psicofisico dei dipendenti. L’azienda ha quindi ridotto i carichi di lavoro in modo che nessuno eccedesse il 100% delle capacità del dipendente. Ciò ha comportato l’impossibilità di programmare tutto il lavoro che era stato pianificato e i manager hanno dovuto prendere decisioni difficili. Ma la produttività e la soddisfazione dei dipendenti è aumentata.

ESPLICITARE IL LAVORO

La pratica di descrivere esattamente come eseguire un compito, definendone chiaramente la sostanza, l’ordine, i tempi e il risultato desiderato, ha portato valore importante alle attività di produzione. Permette di confrontare gli esiti attesi con quelli ottenuti. Se non combaciano, l’organizzazione sa di avere un problema con l’adesione fedele al processo o con il processo stesso e può attivarsi per risolverlo.

A prima vista questo approccio può non sembrare importante per le attività intellettuali, nelle quali molti dei processi sono eseguiti all’interno della mente del dipendente; possono essere invisibili agli altri e difficili da esplicitare in passaggi concreti e replicabili. Un banchiere d’affari, per esempio, potrebbe trovare difficile spiegare come ha convinto qualcuno ad accettare un accordo.

Inoltre, in un’attività intellettuale il lavoro può cambiare rapidamente e ogni giorno le persone potrebbero dover seguire un mix di compiti, alcuni che richiedono capacità di giudizio o intuizione, altri che potrebbero essere ridotti a un protocollo perché il problema e il modo migliore per affrontarlo sono già ben chiari. Proprio a causa del fatto che di solito eseguono entrambi i tipi di lavoro, esse stesse e le loro organizzazioni danno per scontato che molti compiti non siano standardizzabili, quando in realtà lo sono.

Nonostante queste difficoltà, una quantità sorprendente di lavoro intellettuale può essere definita e descritta e quindi continuamente migliorata. Il segreto sta nello sfidare il concetto che tutta la conoscenza sia di per sé implicita. Un’azienda manifatturiera di nostra conoscenza aveva un esperto in pianificazione che assegnava il lavoro in tutta la fabbrica. I leader aziendali, che volevano migliorare il processo di pianificazione, hanno chiesto a un dirigente senior di intervistarlo. Inizialmente il dipendente ha risposto alle domande in modo vago. Ma quando il manager ha insistito, chiedendogli di spiegare perché prendeva una decisione piuttosto che un’altra, questi ha iniziato a fornire risposte concrete e dettagliate. Poco alla volta il manager ha scoperto le regole implicite usate dal pianificatore. L’azienda le ha perfezionate e le performance sono migliorate.

Specificare il lavoro intellettuale comporta quattro passaggi:

Individuare parti di processo ripetibili e codificarle. Quasi tutte le aree del lavoro intellettuale hanno più cose in comune di quanto sembrerebbe. In Wipro, le squadre trovavano difficile descrivere il processo generale di scrittura del codice, perché spesso comportava soluzioni una tantum. Ma quando hanno riformulato la domanda chiedendosi: «Cos’è che facciamo ripetutamente?» si sono accorti che molti aspetti del processo, inclusi la revisione tra pari, l’integrazione quotidiana nel programma dei pezzi di codice scritti in giornata, i test e le prove dei clienti, si verificavano frequentemente all’interno di un progetto e in progetti diversi e potevano essere standardizzati.

Non cercate di esplicitare tutto all’inizio, né possibilmente mai. Alcuni compiti si presentano talmente di rado che non vale la pena descriverli. E talvolta, si ha una comprensione così scarsa del problema che bisogna ricorrere alla consulenza di un esperto per sapere com’è meglio affrontarlo. Ma parti del processo possono essere specificate anche in questi casi.

Una banca giapponese che voleva aumentare il business dei mutui casa ha scoperto che rivolgersi a un esperto nell’analisi del credito per ottenere la crescita desiderata sarebbe stato costoso e difficile. Ma i dirigenti si sono resi conto di essere in grado, studiando attentamente le decisioni di prestito del passato, di ricavare le regole usate per prenderle e di inserire queste regole in un sistema informatico. Il sistema non ha eliminato del tutto la necessità di esperti che si pronunciano su casi insolitamente complessi o con fattori particolari. Ma la stragrande maggioranza dei casi può essere gestita automaticamente, consentendo all’azienda di far crescere rapidamente e in sicurezza il suo settore mutui.

Usare i dati per raccogliere consenso. Uno dei benefici principali dell’esplicitare i processi ripetibili è che i lavoratori di concetto diventano liberi di concentrarsi sulle parti del lavoro in cui possono creare il valore maggiore. Ma molti professionisti con competenze di alto livello non ritengono che il loro lavoro possa essere descritto. Per esempio, anche se esplicitare il lavoro può migliorare i risultati in campo sanitario, spesso i medici oppongono una strenua resistenza, sostenendo che la loro capacità di giudizio e la competenza non possono essere ridotti a una serie di regole. (Vedere nel box “Ulteriori letture su HBR” gli articoli su questo argomento scritti da Richard Bohmer e Steven Spear.)

Poiché la possibilità di esplicitare con successo il lavoro spesso dipende dal coinvolgimento dei lavoratori, è essenziale superare questa resistenza. Per scardinarla è indispensabile provare l’efficacia del processo. Wipro se ne è resa conto ben presto e ha iniziato a monitorare dove e come la descrizione dei compiti migliorava le performance. Quasi subito si è accorta che beneficiava in particolare i progetti in ritardo sui tempi di consegna. I dirigenti sono quindi riusciti a usare i dati relativi ai miglioramenti ottenuti da quei progetti per guadagnarsi l’interesse di altre parti dell’organizzazione.

Continuare a studiare il lavoro che è stato ritenuto indefinibile. Anche se il lavoro non è stato specificato oggi, non significa che non possa esserlo domani. Un evento poco comune oggi potrebbe verificarsi di frequente in futuro e la comprensione di problemi complicati può migliorare nel tempo. In “Una cura radicale per l’assistenza medica” (HBR aprile 2010) Richard M.J. Bohmer descrive Intermountain Healthcare, un’azienda operante in Utah e Idaho, che eccelle nel migliorare regolarmente i protocolli per i trattamenti medici. Uno degli approcci che impiega consiste nel permettere ai medici di agire in deroga ai protocolli nelle situazioni dubbie. L’azienda raccoglie e analizza i dati delle deroghe e usa quanto appreso dai casi di successo per migliorare il protocollo. Se una deroga produce risultati negativi, l’azienda usa i dati per convincere i medici ad attenersi più spesso alla routine. Intermountain ha creato persino un’unità per mettere alla prova le idee e le intuizioni dei dottori: un test ha permesso di migliorare i criteri per il trasferimento dei pazienti dai reparti alla terapia intensiva.

Specificare il lavoro nel modo sistematico che abbiamo descritto permette a un’organizzazione basata sul lavoro intellettuale di impegnarsi costantemente nell’apprendimento disciplinato. Intraprendere quest’opera spesso richiede risorse dedicate. Wipro ha creato un ufficio produttività per individuare le best practice, esaminare nuove idee, sostenere lo sforzo educativo e aiutare a creare procedure standard che possano essere utilizzate da team diversi.

STRUTTURARE LA COMUNICAZIONE

Riconoscendo che molti problemi sono troppo grossi o complessi per essere affrontati da una sola persona, sempre più spesso le organizzazioni affidano il lavoro intellettuale a dei team. Ma, se si coinvolgono diversi individui in un unico processo diventa essenziale una comunicazione efficace, specialmente perché questi gruppi potrebbero essere composti da persone di ogni parte del mondo. Un sistema “snello” può promuovere una buona comunicazione articolando i modi in cui va effettuata. Ecco come:

Definire chi deve comunicare, cosa e quanto spesso. I lavoratori di concetto devono capire chi userà ciò che producono. Se il fornitore d’opera è in contatto diretto con il “consumatore” (di solito un membro della stessa squadra), i due possono collaborare per far sì che il prodotto funzioni come ci si aspetta. Se la comunicazione frequente genera un ricco flusso di informazioni i problemi possono essere individuati e risolti subito. E quando il contenuto della comunicazione è esplicitato, le persone ottengono le informazioni di cui hanno bisogno e non devono perdere tempo cercando di capire cosa l’altro stia cercando di dire. Uno degli strumenti che Wipro ha adottato per migliorare la comunicazione è la matrice DSM (design structure matrix). I compiti di un progetto sono elencati come righe e colonne della matrice e il team indica se una voce è collegata a un’altra, definendo ogni relazione in termini di dipendenza diretta o di ciclo di feedback. L’algebra matriciale può quindi individuare un ordine consigliato per lo svolgimento dei compiti. (Per ulteriori informazioni sulla matrice DSM, si veda “Are Your Engineers Talking to One Another When They Should?” di Manuel E. Sosa, Steven D. Eppinger e Craig M. Rowles, HBR novembre 2007). Questo tipo di matematica è abbastanza complicato, ma Wipro ha usato una versione semplificata su un foglio elettronico che qualsiasi team era in grado di comprendere. Premendo un tasto il programma elencava i compiti e identificava quale membro della squadra doveva interagire per ciascuno di loro e quando.

Creare una comprensione condivisa. I membri dei team di lavoro intellettuale operano sempre più spesso a cavallo delle frontiere geografiche, culturali, linguistiche e funzionali. Questo significa che potrebbero non avere la stessa comprensione di ciò che viene comunicato; le parole stesse possono avere significati diversi per persone diverse. Prendiamo per esempio le interazioni tra il personale di un’azienda statunitense e il suo provider indiano di servizi informatici. Uno degli scambi che abbiamo documentato riguardava una domanda apparentemente semplice: «Riuscite a finire il lavoro entro una certa data?». Per gli americani, un sì significa sì e un no significa no, e se qualcosa va storto possono urlare e picchiare pugni sul tavolo. Per contro, spesso gli indiani comunicavano un no in modo così indiretto che la controparte negli USA capiva sì. E quando gli indiani sollevavano qualche problema, lo inquadravano sotto forma di domande talmente blande da essere perlopiù ignorate dai lavoratori americani, che non erano abituati a tali sottigliezze. Benché la comunicazione tra i due gruppi fosse strutturata (con aggiornamenti regolari tra parti ben definite, focalizzati su argomenti di discussione concordati), i messaggi non passavano. L’azienda statunitense ha imparato che quando si relazionava con un nuovo fornitore, aveva bisogno di specificare esattamente il modo in cui questo avrebbe dovuto comunicare.

La necessità di strutturare le comunicazioni e di condividere la comprensione era evidente anche in una rivista che conosciamo bene. Uno dei redattori acquisiva un lungo articolo da un collaboratore esterno e lo passava a un collega perché lo editasse. Il compito di trasformare questi contributi in articoli di buona qualità entro le scadenze era spesso difficile e stressante. Il management vedeva il problema ma pensava fosse irrisolvibile: credeva che i passaggi di consegne fossero intrinsecamente difficili perché l’editing comporta una conoscenza implicita della materia e di come esprimere le idee e due redattori non affrontano mai un pezzo alla stessa maniera.

Tutte cose vere, ma parte del problema stava nella mancanza di un processo specifico tramite il quale due redattori comunicassero lo scopo dell’articolo e come raggiungerlo. Spesso non si parlavano proprio. E quando lo facevano, la conversazione non era strutturata. I due potevano avere idee totalmente diverse riguardo alla bozza di articolo e al lavoro necessario per renderla pubblicabile, e non esisteva un mezzo formale per riconciliare i due punti di vista contrastanti.

La rivista aveva un procedimento specifico per la valutazione delle proposte di articoli: ciascuna doveva comprendere una descrizione scritta del valore del pezzo e un piano di revisione. Ma spesso la proposta era basata sulla descrizione, da parte dell’autore, di un articolo previsto, e la bozza che alla fine veniva consegnata si discostava parecchio dalla proposta. A volte capitava che un redattore saltasse il processo presentando al capo redattore una proposta in forma orale.

Un approccio più efficace avrebbe prescritto, in primo luogo, che ogni redattore sottoponesse la proposta per iscritto, in modo che i motivi per pubblicare l’articolo (il valore che avrebbe portato ai lettori) venissero registrati. Una volta ricevuta la bozza completa dell’articolo, sia il redattore che l’aveva acquisita sia il redattore che l’avrebbe editata avrebbero dovuto scrivere una recensione dettagliata e un piano di revisione. (Quest’ultimo poteva includere la struttura e la lunghezza del pezzo, la necessità di arricchire i contenuti, l’utilizzo di esempi e una stima dei tempi necessari per completare il lavoro). Il passaggio finale sarebbe stato una conversazione strutturata, facilitata da un redattore senior, durante la quale tutti e tre avrebbero raggiunto un accordo sulle questioni.

Con comunicazioni molto specifiche, le persone comprendono il lavoro che stanno assumendo in carico e possono quindi usare il tempo per risolvere i problemi anziché per cercare di capire cosa devono fare.

Risolvere i dissensi con i fatti, non con le opinioni. Una lunga serie di ricerche evidenzia i modi in cui le emozioni e l’irrazionalità possono distorcere il processo decisionale. Può essere un problema particolarmente grave quando il lavoro prevede conoscenze implicite, perché spesso non è chiaro come un esperto sia arrivato a una particolare decisione e in quale grado la decisione sia dettata dall’intuito o dall’emozione piuttosto che dai fatti.

Uno dei progetti snelli di Wipro illustra le difficoltà e i benefici di una comunicazione esplicita all’interno di un gruppo. Il team in questione aveva implementato un sistema di rendiconti periodici con cui i membri più esperti valutavano il codice software scritto dai colleghi meno esperti. Lo scopo era eccellere nel trovare e sistemare tipi diversi di errore, aiutare le persone più giovani a migliorare e permettere ai membri del team di conoscersi. Sfortunatamente, i valutatori senior usavano standard diversi e comunicavano in modo differente le loro analisi. Quello che per uno era codice ben scritto, per un altro era un errore. Anche quando i valutatori concordavano su uno sbaglio, spesso lo chiamavano con nomi diversi. La mancanza di standard e metodi di comunicazione condivisi ha danneggiato il morale dei dipendenti junior.

Uno dei valutatori ha individuato il problema e ha chiamato a raccolta il team per discuterne. Il gruppo ha ammesso di avere la possibilità di standardizzare la comunicazione, così come il lavoro svolto. Alcuni dei membri senior hanno steso una lista di errori comuni con le relative definizioni, a uso di tutti i valutatori. L’esercizio ha portato il team ad accettare che molti errori considerati casuali (per esempio il modo di definizione delle variabili o di inserimento delle spiegazioni all’interno del codice) erano in realtà abbastanza frequenti. E una volta esplicitati, sono stati risolti in maniera sistematica.

Ben presto il linguaggio parlato dal team è diventato così preciso che persino una macchina poteva comprenderlo: il programma di scrittura del codice poteva valutare in automatico se i membri stavano seguendo le linee guida e segnalare gli eventuali errori.

Alla fine il team si è ritrovato a passare meno tempo litigando sulla definizione degli errori e di più a lavorare su come prevenirli. Il risultato è stato il crollo dell’incidenza degli errori.

AFFRONTARE I PROBLEMI RAPIDAMENTE E IN MODO DIRETTO

Uno degli scopi principali del Sistema di produzione Toyota è trasformare un’operazione in un motore per la soluzione dei problemi. Il nucleo del motore è il metodo scientifico: esplicitare in modo chiaro e misurabile le ipotesi su come migliorare alcuni aspetti del lavoro, mettere le ipotesi alla prova in maniera oggettiva e, se i dati confermano le ipotesi, rendere standard l’approccio. Ma c’è molto altro ancora. Ecco come adattare il metodo scientifico a un ambiente di lavoro intellettuale:

Se sorge un problema, lo deve risolvere chi l’ha creato. I problemi possono accumularsi perché il processo di lavoro è difettoso o perché il lavoratore ha commesso uno sbaglio. In ogni caso, coinvolgere il dipendente nella soluzione del problema di solito porta a una soluzione più rapida perché le persone più vicine al problema di norma sono quelle che lo conoscono meglio. Se ciò non è possibile, il lavoratore dovrebbe partecipare all’applicazione della soluzione. Ricordiamoci che in Wipro i membri senior di un gruppo di programmatori controllavano il codice scritto dai novellini. Se trovavano un errore, la responsabilità della soluzione toccava ai novellini, non agli esperti, i quali li aiutavano solo se necessario. Questo faceva sì che i meno esperti sapessero di aver fatto un errore e capissero in cosa avevano sbagliato, così da ridurre la possibilità che gli stessi errori si ripetessero in futuro.

I problemi dovrebbero essere risolti dove sorgono. Il luogo fornisce importanti informazioni sul contesto, senza le quali chi cerca di risolvere un problema non riesce a riprodurre esattamente l’accaduto e ha minori probabilità di riuscita.

In un’epoca in cui spesso i membri di un team sono sparpagliati in tutto il mondo, l’idea “snella” che chiunque cerchi di risolvere un problema debba essere in grado di vederlo in prima persona sembra inattuabile. Ma la tecnologia moderna la rende possibile. Per esempio, alcuni membri di uno dei gruppi Wipro che abbiamo osservato doveva testare il software nella sede di un cliente USA; altri membri che si trovavano in India dovevano risolvere i bug che venivano rilevati. In questo caso i membri del team non erano solo in località diverse, ma anche su fusi orari differenti. Un gruppo dormiva mentre l’altro lavorava. Talvolta i tecnici in India non riuscivano a replicare gli errori che i colleghi negli USA avevano trovato e quindi non riuscivano a risolverli. Alla fine, il team ha stabilito che il gruppo negli Stati Uniti utilizzasse una webcam per registrare i passaggi che faceva e le configurazioni di sistema che avevano prodotto l’errore, e questo ha facilitato l’identificazione delle cause e la soluzione del problema da parte dei tecnici in India.

Risolvere i problemi appena emergono. Più l’informazione sul problema è fresca, meno è soggetta a distorsioni, più è facile trovarne la causa. Aggredire un problema appena si presenta aiuta anche a trasformarlo in un’occasione di apprendimento. Ecco perché Toyota fa sì che i dipendenti suonino un allarme quando si scorgono un intoppo. Anche se installare sistemi d’allarme in uno studio legale o in un laboratorio farmaceutico è improponibile, è comunque possibile applicarne il principio. Con questo spirito, un team Wipro che controllava il nuovo codice con periodicità settimanale ha cominciato a farlo quotidianamente, e i capigruppo hanno deciso di valutare il lavoro del team ogni due o tre giorni. L’incidenza degli errori è diminuita drasticamente.

Usando il metodo scientifico e facendo in modo che chi ha provocato l’errore lo risolva dove e quando si presenta, un’organizzazione basata sul lavoro intellettuale può creare un motore per la soluzione dei problemi che spinge al miglioramento continuo.

PIANO PER UN VIAGGIO INCREMENTALE

Applicare i principi “snelli” al lavoro intellettuale non significa semplicemente copiare gli strumenti che hanno avuto successo nel lavoro manuale. Occorre inventare qualcosa di nuovo. Probabilmente non ci si riuscirà al primo colpo, ma nel tempo si potrà ottenere un sistema di miglioramento costante seguendo questi consigli:

Iniziare dal piccolo. Per esplorare la possibilità di un approccio snello Wipro ha lanciato dieci progetti pilota. Quando otto di questi hanno mostrato risultati promettenti, ha incaricato l’ufficio produttività di allargare l’iniziativa a tutta l’impresa. Poco alla volta, l’azienda ha imparato a distinguere le idee che funzionavano da quelle che andavano perfezionate e da quelle da scartare.

Codificare le lezioni apprese. È importante che qualcuno all’interno dell’organizzazione abbia una visuale completa sull’iniziativa, pena la perdita di lezioni importanti. In Wipro il compito è stato affidato all’ufficio produttività, che ha valutato ogni progetto snello, ha svolto un ruolo educativo e ha aiutato a standardizzare le pratiche.

Cercare sempre nuovi metodi di lavoro. I progressi di Wipro sono stati costanti in termini di numero di progetti snelli intrapresi, ma i manager senior hanno ammesso che l’adozione generalizzata era soltanto una delle misure del successo e che l’implementazione doveva arrivare in profondità.

Tre anni dopo l’avvio dell’iniziativa, tutti i segnali esteriori erano promettenti. I dipendenti erano molto coinvolti, i clienti esprimevano interesse nell’applicazione dei nuovi metodi Wipro alle proprie attività informatiche e la crescita del numero di progetti snelli era notevole. Tuttavia, durante la valutazione costante dei risultati, i leader dell’iniziativa si sono accorti che alcuni team applicavano gli approcci snelli solo ad alcune parti dei loro progetti. Preoccupati che i gruppi potessero adottare solo pochi strumenti superficialmente attraenti e non cambiare fondamentalmente il modo in cui lavoravano, i leader hanno smesso di avviare progetti e si sono presi il tempo di riesaminare l’esperienza fatta. Hanno creato una serie di raccomandazioni specifiche applicabili a vari tipi di progetto. Infine hanno ammesso che mancavano delle risorse per sostenere capillarmente l’opera di “snellimento” e hanno deciso di concentrarsi sui progetti più grossi, con i maggiori benefici potenziali. Completato questo lavoro preparatorio (in tre o quattro mesi) hanno rilanciato l’operazione e i benefici sono aumentati.

Ricordare che l’approccio snello non è sempre utile. Se il lavoro che si svolge è visionario, sperimentale e richiede di inventare sempre nuovi modi di eseguire un compito, non cercate di applicare ovunque i principi snelli. I compiti ripetitivi possono e devono essere affrontati con idee snelle. Ma l’innovazione soffrirà se il tempo necessario per ideare e testare idee “folli” sarà classificato come spreco ed eliminato.

COINVOLGETE I MANAGER

Nel lungo termine, i principi snelli producono un miglioramento bottom-up (verso l’alto): il personale della front line genera e implementa nuove idee mentre i manager svolgono un ruolo di supporto. Ma stiamo parlando del risultato finale e raramente un’organizzazione parte da lì. I manager middle e senior sono fondamentali nell’avvio del processo.

I project manager e altri leader di livello intermedio devono addestrare e motivare i loro gruppi. Ciò richiede un investimento significativo di tempo. Durante la nostra ricerca abbiamo scoperto che i team con leader fortemente coinvolti nell’iniziativa snella (che educavano i loro gruppi e li convincevano che gli sforzi avrebbero migliorato le performance) avevano più successo degli altri. In Wipro, il training iniziale era condotto dal project manager o da un istruttore certificato nelle pratiche “snelle”. Poi però toccava al project manager spingere il team ad applicare le idee.

I leader senior devono dare l’esempio nel lungo termine. Molte organizzazioni soffrono di sindrome da miglioramento dei processi. I loro leader appoggiano a parole l’iniziativa del mese e, ovviamente, i dipendenti non la prendono troppo sul serio.

Trasformare un’organizzazione in un sistema snello implica di reinventare il modo in cui si lavora dalle fondamenta. Vale per il lavoro intellettuale quanto per quello manuale. La trasformazione richiede un investimento protratto nel tempo, un’enorme quantità di addestramento, una nuova cultura e nuovi processi. Una leadership aziendale matura deve trattarla come un programma di cambiamento a lungo termine.

Azim Premji, il presidente di Wipro, l’ha capito bene: è stato molto coinvolto nell’iniziativa fin da principio, ha valutato personalmente i progetti snelli, incontrato regolarmente i responsabili dell’iniziativa e ne ha parlato all’esterno dell’azienda. Il suo impegno pubblico ha chiarito ai dipendenti che il programma era lì per restare.

TRASFORMARE un impianto manifatturiero in un sistema snello richiede uno sforzo enorme, accanito. Il segreto è la perseveranza, non la genialità.

Trasformare un’attività intellettuale, che ha processi molto meno ripetitivi e codificabili, in un sistema snello è ancora più difficile. Ma, come abbiamo potuto toccare con mano, è possibile. La difficoltà stessa rende difficile a un concorrente copiare il sistema. E questa è la sua forza. 

Bradley R. Staats è ricercatore di Management della produzione, delle tecnologie e dell’innovazione alla Kenan-Flagler Business School dell’Università del North Carolina.

David M. Upton è Professore di Management operativo alla Saïd Business School dell’Università di Oxford.