A cura di Sandrine Olivencia, Lean coach, Operae Partners
“Quando sono in ritardo per andare in aeroporto, dico al tassista ”raddoppio il prezzo della corsa se riesce a non farmi perdere l’aereo”. Nove volte su dieci, arrivo in tempo. Se faccio una proposta simile al mio Direttore IT, finisco col pagare tre volte più caro sforando comunque la scadenza prevista!”
Ecco come uno dei nostri clienti, il CEO di una grande banca europea, si è espresso durante il nostro primo incontro.
Questo fenomeno è confermato dal noto studio di Standish Group: in media il 29% dei progetti informatici in azienda ha successo, nelle grandi aziende solamente il 9%. Si oltrepassano i budget, non si rispettano le scadenze, con conseguenti penali per il ritardo, e la qualità ne soffre. In certi casi, a fine progetto, il progetto viene anche rifiutato dal cliente perché non risponde più alle sue necessità.
Noi ci miglioriamo, ma troppo lentamente. Senza un cambiamento radicale nella maniera di gestire i nostri progetti informatici, ci vorranno ancora due generazioni prima di essere in grado di condurre dei progetti IT di successo al primo colpo … con un po’ di fortuna.
Lo studio indica inoltre che più della metà dei progetti IT costa in media due volte più caro rispetto al preventivo iniziale. Ovviamente, questo non è comprensivo dei costi addizionali derivanti dalle opportunità perse, che sono di difficile misurazione, ma che potrebbero essere nell’ordine di milioni di euro.
Di recente, ho analizzato un campione di una ventina di progetti IT di medio-grande dimensionamento ed emerge lo stesso tipo di problema: ritardi di consegna da 30 a 100% rispetto alle scadenze iniziali. Il Lead Time di un progetto è definito come il periodo fra la data della richiesta del cliente e la data in cui viene accettato come completo.
Al problema del ritardo, si aggiungono lamentele dei Direttori dei Sistemi Informatici (DSI): “Non c’è trasparenza sui nostri progetti informatici”, “i nostri team sono mal organizzati” e, ancora, “abbiamo la sensazione di essere continuamente in una situazione di crisi. Durante le nostre giornate non facciamo altro che gestire le emergenze legate alle lamentele di clienti insoddisfatti ”
Osservando sul campo le operazioni dei team IT (il cosiddetto “Gemba”, secondo il linguaggio della Lean) ci rendiamo conto che certi problemi si presentano continuamente:
• Affidabilità delle specifiche, senza una chiara comprensione dei problemi del cliente
• Una visione frammentata del progetto
• Mancanza di sincronia tra i differenti attori del progetto
• Schede progetto non corrispondenti alla realtà perché realizzate senza il coinvolgimento degli operativi sia nella fase di stima che in quella di pianificazione
• Identificazione tardiva dei problemi (ritardi, errori, “not right first time”)
• Turnover in seno ai team con conseguente perdita d’expertise
• Scarso coinvolgimento dell’utilizzatore finale
L’approccio Lean
L’approccio Lean permette di aggredire queste ed altre tipologie di problemi e si effettua in quattro tempi:
1. Visualizzare la produzione per rilevare i problemi
2. Reagire immediatamente
3. Risolvere i problemi uno per uno
4. Migliorando i metodi di lavoro
Tale approccio non è un’azione puntuale di miglioramento, quanto, piuttosto, un sistema di gestione che si applica sul campo quotidianamente. Lo spirito di collaborazione è assolutamente cruciale per implementare questa maniera di lavorare. Le persone del team svilupperanno delle nuove prassi lavorative, delle nuove azioni e dei nuovi strumenti che garantiranno l’efficacia operativa sul lungo periodo.
1. Visualizzare la produzione per rilevare i problemi
La prima tappa del metodo Lean è la visualizzazione della produzione. Nella Lean ciò che permette di visualizzare la produzione nei progetti informatici è l’Obeya, la gestione visiva del progetto. L’Obeya, termine giapponese che significa “grande stanza”, è uno spazio nel quale sui muri si affiggono tutte quelle informazioni che permettono di condurre efficacemente i progetti e di ridurre il “time-to-market” dei suoi prodotti.
Ogni giorno, i rappresentanti di tutti i team che partecipano al progetto si riuniscono nell’Obeya per sincronizzare le loro attività e trattare rapidamente i problemi prima che questi possano compromettere il raggiungimento degli obiettivi.
Presso la Toyota, l’Obeya è utilizzata nella fase di concepimento di prodotti e nella gestione dei progetti. Le riunione nell’Obeya viene condotta dall’ingegnere capo e dal rappresentante di ognuna delle differenti attività chiave (ricerca, sviluppo, QA, ecc). L’ingegnere capo indica una chiara direzione progettuale, si assicura del buon seguito degli indicatori di performance, dell’osservanza dei piani d’azione e delle scadenze, del rispetto della qualità e della risoluzione dei problemi identificati di volta in volta.
L’Obeya non si rivolge ad un’attività o ad un contesto particolari. Nei progetti informatici, l’animatore dell’Obeya potrebbe essere il Direttore IT o un responsabile del progetto. I partecipanti ad un progetto di sviluppo informatico di media dimensione potrebbero essere il marketing, i gestori del prodotto, gli sviluppatori, i tester, gli integrator e la produzione informatica.
In generale, i team si riuniscono regolarmente nell’Obeya in maniera che tutti siano aggiornati. Il team si incontra:
• Al mattino per circa quindici minuti (il cosiddetto flash meeting). Ogni partecipante aggiorna gli indicatori e il planning dei rispettivi team, presenta gli obiettivi della giornata del proprio team e condivide quei problemi operativi che possono avere un impatto sul progetto.
• Una volta alla settimana viene pianificata la settimana successiva, ciò che permette di dare al progetto un ritmo di consegna cadenzato, vengono sincronizzati i piani d’azione, condivise le “lessons learned” (lezioni apprese), aggiornati gli indicatori settimanali e risolti i principali problemi.
• In maniera puntuale, per risolvere dei problemi bloccanti.
2. Reagire immediatamente:
Di fronte ad un incidente o un errore, ci si ferma (“stop the line”). Si corregge/ripara immediatamente l’incidente per riuscire a proteggere il cliente.
3. Risolvere i problemi uno per uno:
Durante il flash meeting quotidiano, il team segnala i gap di performance evidenziati dagli indicatori e dai piani d’azione, e condivide i problemi del giorno prima. Dopo il flash meeting, ai problemi vengono attribuite delle priorità; le criticità vengono segnate e scritte sul foglio della risoluzione dei problemi e affrontate uno per uno seguendo rigorosamente l’approccio del Plan Do Check Act (PDCA), il processo interattivo di risoluzione dei problemi ideato da Deming e d’ispirazione scientifica:
1. Identificare e misurare il problema
2. osservare il problema sul campo
3. trovare le ipotetiche cause attraverso brainstorming in seno al team
4. sperimentare localmente, su scala ridotta
5. misurare i risultati/verificare le ipotesi
6. trarre gli insegnamenti, cambiare le pratiche e metodi lavorativi e ricominciare nuovamente
4. Migliorando i metodi di lavoro:
I membri del team, tutti insieme, verificano se le loro azioni di risoluzione dei problemi hanno portato dei frutti. Se è il caso, allora mettono in piedi dei nuovi standard di lavoro, cioè, creano delle nuove prassi lavorative che vengono poi condivise con i restanti attori del progetto.
Testimonianza di un progetto
L’esempio che verrà presentato qui di seguito è quello relativo ad un team di sviluppo di applicazioni web di una grande banca europea. Questo team deve gestire circa trenta progetti all’anno. Ha deciso di costruire un’Obeya per fare fronte all’emergenza progettuale. Chiameremo questo team il “webteam”.
Il webteam è composto da 10 persone, tutte sul posto. E’ stato creato come alternativa al normale processo di sviluppo IT e gode di una grande indipendenza. Ha per missione quella di rispondere efficacemente alle richieste puntuali provenienti dalla rete di agenzie su dei nuovi strumenti web o degli strumenti esistenti migliorati. Il suo valore è legato alla capacità di consegnare rapidamente delle applicazioni rispondenti esattamente ai bisogni delle agenzie, in meno di 4 mesi per le richieste più complesse. Gli obiettivi stabiliti dal Direttore IT sono di 10 consegne nell’anno in corso (da marzo a dicembre) e di 30 per l’anno successivo (da gennaio a dicembre).
Nella foto qui sotto, un team di sviluppo informatico, simile al web team. Cosa succede?
Niente di anormale, direte voi. Ed invece, questo team è al limite di una crisi.
Come lo si può vedere? Ebbene, giustamente non vediamo niente ed è proprio questo il punto. Non si vede come procede il progetto, né lo stato di soddisfazione dei clienti. Altro sintomo evidente di un team in difficoltà: le persone intervistate non sono neppure a conoscenza dell’andamento dei loro progetti, e, da ciò che emerge dalle interviste fatte, non sembrano rendersi conto della situazione critica nella quale si trovano. Né tantomeno conoscono i loro clienti. D’altra parte, i clienti percepiscono in maniera palese che la situazione è ben distante dall’essere soddisfacente.
Da settembre del primo anno era stata consegnata solamente un’applicazione mentre le altre erano in ritardo di consegna di parecchie settimane ed anche di mesi. La qualità del team webteam (misurata dal numero di rilavorazioni richieste prima che il cliente accetti l’applicazione) ne stava chiaramente soffrendo.
Il team non aveva consapevolezza di avere un problema né tanto meno aveva la percezione di essere in ritardo: “è il cliente che domanda ogni giorno sempre più, stiamo cercando di soddisfare le sue richieste”. D’altro canto, la maggior parte dei clienti diceva che le versioni consegnate erano incomplete, contenevano errori e che i ritardi di consegna erano troppo alti.
Il web team ha così deciso di mettere in piedi il metodo Lean e creare la propria Obeya per risolvere i propri problemi. Qui di seguito le principali azioni intraprese:
1. Visualizzare la produzione per rilevare i problemi:
La prima settimana il web team ha affisso al muro le informazioni necessarie per costruire la prima Obeya. E’ stata affissa la “voce del cliente” creata durante il workshop Kaizen, il back log dei progetti, un nuovo macro planning, un “task board” per seguire la produzione giornalmente, diversi indicatori di performance concepiti durante il workshop (ritmo della consegna, errori, carichi di lavoro) ed infine un cartellone con tutti gli incidenti di produzione.
Hanno inoltre aggiunto il foglio della risoluzione dei problemi (alla fine del progetto un’intera parete della stanza era utilizzata per la risoluzione dei problemi). Gradualmente, il team ha integrato altri elementi utili per l’Obeya, come il “red basket” per mettere in evidenza i problemi di qualità, il “customer sastisfaction survey” ed il box dei suggerimenti.
Il team ha fatto ricorso a degli strumenti poco costosi e di facile utilizzo (post-it, lavagne).
Nelle foto qui sotto, potere vedere la prima versione dell’Obeya costruita dal web team. Successivamente la loro Obeya è stato ulteriormente sviluppata:
2. Reagire immediatamente:
Tutti gli incidenti sia in ambiente di test che in produzione sono immediatamente evidenziati nei “red basket” e analizzati con priorità. Nelle foto qui di seguito, potete vedere due incidenti di produzione che sono identificati e aggiunti nel taskboard per essere trattati prima di ogni altra cosa dal primo sviluppatore disponibile. Non appena l’incidente è categorizzato come “bloccante”, un esperto interrompe il proprio lavoro per risolvere il problema, in generale con il supporto del team leader.
3. Risolvere i problemi uno per uno:
Nell’esempio qui sotto, a sinistra, il team segnala diversi ritardi di uno dei progetti sul planning. Identifica delle ipotesi delle cause del ritardo: “non comprendiamo bene le specifiche dei clienti e attendiamo a lungo dei chiarimenti da parte loro”.
Il team segna con una croce ogni volta che c’è un ritardo e ne attribuisce una causa.
Dopo qualche sperimentazione locale mirante a migliorare la maniera con la quale raccogliere e capire i bisogni dei clienti, il problema è quasi scomparso. Il punto chiave è ovvio (linea verticale in nero) e conferma che il team ha trovato una soluzione efficace.
4. Migliorando i metodi di lavoro:
Completando i cicli di risoluzione dei problemi, il team ha tratto numerosi insegnamenti e ha cambiato i propri metodi lavorativi. A titolo di esempio, a seguito dell’analisi dei problemi legati al ritardo sul planning, pocanzi descritto, e dopo diverse soluzioni sperimentate, il team ha radicalmente modificato la maniera di raccolta delle necessità dei clienti.
Allo stato attuale, il webteam segue uno standard semplice ma preciso che ha creato in collaborazione con i clienti e che ha affisso sui muri dell’Obeya. Questo standard richiama ad un ciclo di sviluppo interattivo, demo sistematiche con i clienti, l’uso di template e check-list durante il processo di raccolta delle richieste.
I risultati ottenuti dal webteam in tre mesi sono spettacolari:
• 8 applicazioni consegnate in novembre e un totale di 11 prima della fine di dicembre (obiettivi superati)
• Qualità: nessun incidente nel corso dell’ultimo mese di misurazione
• Tempi: in media, un’applicazione consegnata ogni 10 giorni, capaci di soddisfare le richieste del cliente (la cosiddetta frequenza “takt time”, secondo la Lean)
• Indice di soddisfazione cliente: +61%
• Costi: in media, l’80% delle ore-uomo sono state impiegate in attività a valore aggiunto per il cliente contro 50% all’inizio del progetto
Le condizioni necessarie per il successo
Trattandosi di un approccio dinamico e collaborativo, l’Obeya genera numerosi e scontati benefici. Consente di promuovere e sviluppare il teamwork, permette al team di vedere e risolvere i problemi molto rapidamente; è uno strumento di monitoraggio e riduce il “Lead Time” dei progetti. Sebbene i team percepiscano i suoi vantaggi, hanno spesso delle difficoltà ad integrare l’Obeya nella routine quotidiana.
Il webteam ha conseguito dei successi appropriandosi della metodologia Obeya per diverse ragioni: innanzitutto per la rapidità dei primi risultati ottenuti. In appena tre mesi il team è riuscito non solo a conseguire gli obiettivi stabiliti ma addirittura a superarli con 11 applicazioni consegnate anziché Grazie all’Obeya, il team ha rapidamente imparato ad identificare i “veri problemi”, ciò che rappresenta un decisivo fattore per il successo di ogni progettualità Lean. Tuttavia, per garantire la perennità del metodo Lean e per essere certi che sia applicato nel lungo periodo, è necessario il verificarsi anche di altre condizioni.
La prima s’incarna nel concetto di “sfida manageriale”: il Direttore IT e i manager del webteam hanno effettuato delle visite sistematiche nell’Obeya in modo da spronare il team sulle performance e per sostenerle nella risoluzione dei problemi operativi. Anche il CEO della banca ha visitato l’Obeya per costatare i progressi apportati dal progetto pilota. “Vedo finalmente la luce in fondo al tunnel”, ha dichiarato. Le visite regolari del Management costituiscono senz’altro un supporto necessario e motivano nel perseguimento del miglioramento continuo.
La seconda condizione è legata alla capacità del team di appropriarsi dell’approccio e di adattarlo al proprio contesto. Il webteam ha implementato la propria versione dell’Obeya. Ha scelto i propri strumenti di gestione, i propri indicatori di performance e sviluppato una reale autonomia e acquisito la capacità di innovare attraverso la risoluzione dei problemi. Il team ha imparato a “vedere” il cliente per capirne le necessità. Il team ha soprattutto sviluppato uno “spirito guerriero” che non possedeva in precedenza: il desiderio di lottare non solamente per i propri progetti, ma anche e specialmente nell’interesse dei propri clienti.
