FAAC nasce dall’idea di un imprenditore edile, Giuseppe Manini, il quale nota che nei condomini i cancelli restavano sempre aperti. Le persone erano obbligate a scendere dall’auto per aprirli ma poi nessuno li richiudeva. Così Giuseppe Manini realizza in modo artigianale il primo sistema di movimentazione automatica per i cancelli ad ante battenti ricorrendo alla tecnologia oleodinamica e alla catena di distribuzione fornita dal territorio bolognese nel settore idraulico. Nel 1965 fonda a Zola Predosa la FAAC Fabbrica Automatismi Apertura Cancelli. L’azienda si rivela molto innovativa e con lo sviluppo dell'elettronica, nascono le schede elettroniche a microprocessore che permettono di creare impianti che vanno al di là della sola apertura e chiusura. La produzione di nuove idee viene protetta da innumerevoli brevetti che sanciscono la creatività e capacità innovativa della FAAC.
Nel 1979 inizia l’espansione all’estero che porterà l’azienda nel 2011 a diventare FAAC Group con un fatturato di 210 milioni, più di mille dipendenti e filiali in 16 paesi. Con la scomparsa del fondatore la guida dell'azienda passa in mano al suo unico figlio, Michelangelo Manini (1962-2012) e lo sviluppo continua costante. Nel 2012, a seguito della prematura scomparsa del socio di maggioranza Michelangelo Manini, viene designata come unico erede l’Arcidiocesi di Bologna, che diviene così proprietaria del 66% delle azioni del Gruppo. Con il subentro della nuova proprietà in occasione dell’evento successorio subisce una forte accelerazione il processo di separazione tra azionariato e gestione, già iniziato con la seconda generazione della famiglia fondatrice nel primo decennio degli anni duemila: la gestione della società viene infatti affidata ad un Consiglio di Amministrazione composto da professionisti per lo più indipendenti e ad un management team fortemente responsabilizzato che continua lo sviluppo dell’azienda. nel 2023 il fatturato dl gruppo FAAC ha sfiorato i 700 M€ e un utile operativo di 87.2 milioni, in crescita del 22,3% rispetto all’anno precedente, l’indebitamento è inesistente. (Liberamente tratto da: https://it.wikipedia.org/wiki/FAAC, https://faac.it/storia-2/, https://faactechnologies.com/la-nostra-storia/)
Nel 2008 Luigi Pasquali, allora responsabile delle progettazioni meccaniche, propone un esperimento al Direttore Tecnico Marco Monterastelli: poiché si stava introducendo il Lean Thinking in produzione , perchè non applicare l’approccio Toyota, all’epoca praticamente ignoto, allo sviluppo di nuovi prodotti? Questo approccio si chiama Obeya e venne utilizzato, forse sarebbe meglio dire creato, in Toyota nel 1993. Vi erano poche tracce sull’utilizzo di questo approccio e quel poco veniva dalle pubblicazioni di quegli autori che avevano fatto parte delle ricerche del International Motor Vehicle Program del MIT, un programma che agli inizi degli anni ’80 studiò l’industria automobilistica in 70 fabbriche in 14 paesi per dieci anni.
Obeya è un termine giapponese che significa ‘grande stanza’. Nel 1993 Toyota decise di seguire una nuova strategia e di preparasi al XXI secolo, così il management diede il compito di
con l’obiettivo di minimizzare il volume del veicolo, massimizzare gli spazi interni e economizzare il consumo di carburante (20 km per litro). Venne dato l’incarico a Takeshi Uchiyamada, un ingegnere che non aveva mai lavorato nel disegno di sviluppo dei veicoli proveniente dall’area di test. Toyota reinventa la propria architettura organizzativa selezionando intenzionalmente persone non esperte nel settore che quindi tendono a non seguire percorsi già noti di cui hanno esperienza consolidata. La richiesta era che venisse presentato il concept in tre mesi. Chiaramente non erano sufficienti per fare un prototipo ma al comitato non bastava la presentazione solo di idee, così si predisposero a mostrare un blueprint a metà scala. Mentre il prototipo avrebbe dovuto essere presentato alla fiera dell’automobile di Tokyo 2 anni dopo. Toyota impiegava già la metà del tempo per progettare le nuove auto rispetto ai loro competitors americani ed europei, ma qui si trattava di impiegare meno della metà del tempo che di solito utilizzava. La sfida era notevole, così Uchiyamada mise insieme tutti gli ingegneri dei diversi dipartimenti, un team di 30 persone, e predispose una grande stanza, Obeya, dove tutto ciò che riguardava il progetto era reso visibile e aggiornato costantemente. Vi erano lo stato di avanzamento di ogni area e ogni fornitore chiave, gli scostamenti dai target stabiliti, profit & loss e altri importanti indicatori di performance, i componenti dello smontaggio di parti dei competitors, i disegni del progetto, informazioni sulla forza lavoro. Qualsiasi componente del team poteva revisionare questi strumenti, mentre ogni responsabile doveva mantenere costantemente aggiornate le proprie informazioni, qualsiasi scostamento di performance o dai tempi era immediatamente visibile a tutti. Questo modo di procedere su più ipotesi contemporaneamente prese il nome di set-based concurrent engineering reso possibile solo attraverso Obeya. Come risultato non solo il team sviluppò quella che sarebbe diventata l’auto ibrida più venduta del mercato, lo fece nella metà del tempo e presentò il prototipo al pubblico con due mesi di anticipo rispetto alla data prevista di lancio.
Così Luigi mise in piedi una Obeya per il progetto di sviluppo di una innovativa automazione per cancello scorrevole. Lavorarono nel corso del 2008 e in parte nel 2009. L’approccio Obeya di sviluppo nuovi prodotti portò risultati eccellenti non solo in termini di qualità dei prodotti sviluppati ma anche in termini di rapidità, meno della metà dei tempi convenzionalmente impiegati. Insomma fu un successo, il prodotto è felicemente sul mercato dal 2009.
La lezione di Luigi non rimase inascoltata. Aveva introdotto un approccio allo sviluppo dei nuovi prodotti molto diverso dai metodi tradizionali, capace di portare risultati di maggior impatto e in tempi molto più rapidi. Così nel 2018 Obeya diventò l’approccio standard utilizzato per tutti i progetti di sviluppo prodotto aziendali, ha cambiato la configurazione organizzativa e ha dissolto i dipartimenti. Oggi in FAAC sono al lavoro 9 Obeya di sviluppo prodotto, 1 di sviluppo multiprodotto per gestire le modifiche a prodotti già sul mercato, 3 Obeya di miglioramento di processi esistenti.
Quando ci incontriamo a Zola Predosa, il 13 febbraio 2024, a ricevere me e Gianluca Metalli, caro amico e CEO di Fattor Comune Società Benefit, ci sono Luigi Pasquali, Chief Operations Officer, Francesco Cevenini, Project Leader, Francesco De Sario, Facilitation Methodologies Manager. Nella grande sala fatta di poltrone e tavoli bassi adatti ad incontri informali su un muro campeggia la scritta OBEYA e in caratteri diversi: monitoraggio - indicatori visivi - sincronismo - collaborazione - comunicazione visiva - velocità - permanenza - snellimento - anticipazione - proattività - velocità - efficienza - partecipazione, Ovvero le caratteristiche dell’approccio Obeya. Le scritte proseguono: 2018 FAAC introduce OBEYA nel proprio reparto di Progettazione.
Obiettivi:
Dopo esserci presentati e averci offerto un caffè Francesco Cevenini ci conduce alla scoperta dell’applicazione Obeya in FAAC. Ogni Obeya è dedicata ad un progetto di sviluppo prodotto specifico. Ogni stanza ha il nome di uno scienziato. Ogni stanza ospita le board di Obeya, il prototipo in fase di evoluzione, i tecnici che lavorano a tempo pieno o parziale sul progetto e, naturalmente, è il luogo dove avvengono i meeting davanti alla parete dove sono appese tutte le informazioni.
Prima di parlare delle boards e della configurazione della stanza vediamo come l’organizzazione ha cambiato modalità organizzative grazie a questo approccio. Precedentemente i progetti venivano sviluppati secondo un processo lineare a fasi in cui completata una fase il dipartimento incaricato di quello sviluppo passava il proprio output al dipartimento successivo senza però che vi fosse una sincronizzazione sui progetti in processo, il che comportava lunghi tempi di attesa. Benché esistesse una roadmap progetti ben definite, inevitabilmente non a tutti coloro che si occupavano di sviluppo prodotto erano chiare le priorità strategiche.
L’approccio Obeya implica il simultaneous engineering che comporta che tutte le competenze che concorrono alla costruzione di valore del progetto sono nel team di progetto. Durante la prima esperienza nel 2008 la rivoluzione fu coinvolgere gli esperti di produzione, qualità, marketing, e acquisti fin dalle prime fasi di progettazione. Oggi, che Obeya è un approccio consolidato e standardizzato, le funzioni che partecipano ai team di progetto sono ancora di più:
Alcuni progetti si sono avvalsi di team di 25 persone. Naturalmente non per tutti i meeting di progetto occorre avere la presenza di tutti e naturalmente non tutti sono coinvolti per il 100% del tempo su quel progetto. Così per esempio la funzione dei buyer è stata suddivisa in due, una parte dedicata continuativamente agli ordini per la mass production e 3 buyer di progetto che si dividono su più progetti. Lo stesso accade con i tecnici specialisti in cui non occorre tutto il loro tempo sullo stesso progetto, per questo lavorano in contemporanea su diversi progetti. L’approccio Obeya evita accuratamente la trappola delle organizzazioni a matrice per cui le risorse all’interno di un dipartimento funzionale hanno un capo di dipartimento e una capo progetto il che genera conflitti sull’impiego delle risorse e frammenta a tal punto il tempo delle singole risorse da non permettere di ottenere risultati tangibili nei tempi previsti. Come dire, “Il miglior modo di fallire nell’inventare qualcosa è di farne il lavoro part-time di qualcuno”(Dyer, Jeff e Gregersen, Hal, How Does Amazon Stay at Day One, “Forbes”, August 8, 2017). In FAAC Francesco è project leader di due progetti. Mentre i progettisti lavorano a tempo pieno in una sola Obeya, altri specialisti di sviluppo prodotto si dividono su due, al massimo tre progetti. Si noti che i project leader gestiscono ferie e permessi dei progettisti che lavorano in Obeya.
Obeya non ha solo cambiato il modo di sviluppare nuovi prodotti, ha cambiato la configurazione organizzativa rendendola più snella e flessibile, ha cambiato ruoli e responsabilità rendendoli diretti e trasparenti, ha dissolto i silos dipartimentali per riconfigurare una parte dell’organizzazione in team auto-organizzati responsabili del processo end to end. Quando chiediamo di quanto l’approccio ha ridotto i tempi di sviluppo dei nuovi prodotti Francesco ci racconta che il la media dei progetti durava 21 mesi, il caso peggiore durò cinque anni, il progetto con Obeya del 2008 è durato 9 mesi, un altro pilota fatto da Francesco nel 2016 durò 6 mesi.
Francesco ci spiega che esiste un Portfolio di progetti strategici deciso dal leadership team che, avendo oggi piena consapevolezza delle capacity progettuale dell’azienda, è in grado di prioritizzare e di decidere quali prodotti sviluppare e di limitarne il numero in base alla reale capacità. Il leadership team passa le consegne al team di sviluppo con obiettivi, vincoli e tempi di progetto senza tralasciare il perché di tempi, vincoli e obiettivi, più o meno come abbiamo descritto nel caso Toyota. I team di sviluppo studiano i tempi in base ad una serie di criteri piuttosto ben corroborati e danno al leadership team le loro stime di fattibilità. Vengono quindi applicati il principio della piramide rovesciata dove all’apice vi è il team di sviluppo autonomo nel prendere le decisioni e misurare i propri risultati supportato dal project leader che conosce i dettagli del progetto, aiuta il team nel prendere le decisioni, è responsabile insieme al team dei risultati. In mezzo vi sono gli specialisti interni ed esterni a supporto che vengono interpellati dal team quando devono risolvere problemi specifici e dove si trovano spesso i fornitori chiave. Alla base della piramide rovesciata vi è il leadership team che, dopo aver passato scopo, obiettivi, confini e vincoli al team, viene interpellato dal team in caso di necessità quando il team è in difficoltà o quando deve prendere decisioni strategiche sulle quali non ha competenze, ad esempio quali siti produttivi utilizzare rispetto alle specificità del progetto o sugli investimenti.
Come si può facilmente vedere l’approccio Obeya prevede una linea di confine tra il leadership team e i team operativi dove il leadership team è responsabile del COSA e del PERCHÉ, di rendere visibili scopo, obiettivi, vincoli e di fornire tutte le informazioni necessarie ai team operativi per fare il lavoro. I team operativi sono responsabili del COME e CHI, di come creano valore, come si auto-coordinano, di come prendono decisioni insieme e di come apprendono e migliorano continuamente. Questo approccio permette di soddisfare i due criteri alla base di Obeya: da una parte costruire il Visual Management System che rende visibile il lavoro, rende visibile le performance, permette ai problemi di emergere e di essere risolti contestualmente e subito attraverso l’applicazione del ciclo PDCA. Dall’altra costruire l’architettura collaborativa che permette la collaborazione tra professionisti con funzioni diverse, il loro auto-coordinamento, di prendere decisioni informate e condivise e di far incontrare strategia ed execution.
Francesco cita i principi utilizzati nelle loro Obeya. Abbiamo visto la piramide rovesciata a cui si aggiungono l’autoqualità, la comunicazione visuale, la condivisione delle informazioni, il mutuo soccorso, l’adattabilità, il controllo frequente e cadenzato, il tempo in banca (una aliquota di tempo allocata a priori per difendersi dagli inevitabili imprevisti che si verificheranno e non è possibile prevedere a inizio progetto) e il focus sul tempo ciclo non sul lead time. Ogni Obeya viene istituita in base ad uno scopo, lo sviluppo di un nuovo prodotto ad esempio, e il team si costituisce in base alle caratteristiche del prodotto. I team sono altamente inter-funzionali e quasi tutte le persone che vi lavorano lo fanno a tempo pieno, tranne alcuni specialisti che vengono convocati a chiamata.
È venuto il momento di entrare in Obeya. A suo tempo Luigi Pasquali aveva elaborato un modello di come sarebbe stata Obeya in cui aveva dedicato una parete a tutte le informazioni grafiche, un information radiator, un tavolo centrale per il lavoro in team dove sono situati anche i computer dei progettisti a tempo pieno, un tavolo dove vi è il prototipo in fase di costruzione con i pezzi stampati in 3D che vengono man mano aggiunti e assemblati, una parete con la progettazione della linea produttiva. FAAC ha costruito le stanze Obeya reali in una nuova parte dei loro edifici seguendo le indicazioni della piantina di Luigi.
Appena entrati le Board presentano in alto il progetto nelle sue linee essenziali secondo le indicazioni strategiche del leadership team. Quindi tutti i KPI chiave tra cui il target di costo diretto e gli investimenti (distinti fra CAPEX ed OPEX). Sebbene siano forniti i grafici di andamento del progetto, l’elemento chiave che permette a chiunque di capire come sta andando sono una lancetta magnetica tra due poli a sinistra quello verde e a destra uno rosso con l’indicazione della percentuale. La lancetta viene spostata tra i due poli che rappresentano per esempio il target cost, piuttosto che il time to market, rendendo immediatamente visibile anche ai non addetti ai lavori l’andamento del progetto.
Ci sono poi le board di pianificazione, la board di lungo periodo dove una timeline di progetto rende visibile per ogni componente chiave le attività e ne monitora l’andamento. Questa board permette una visualizzazione chiara di come sta procedendo il progetto ed evidenzia le interdipendenze critiche, rende possibile la prioritizzazione delle attività e permette l’auto-organizzazione delle stesse all’interno del team semplificando la gestione delle risorse attraverso una visione realistica del progetto. Non è un Gantt, molto più semplicemente utilizza degli sticky notes che evidenziano i punti critici mese per mese, potremmo piuttosto definirli dei milestones. Vi è poi la programmazione settimanale basata su un kanban board tradizionale con le colonne (TO DO - READY TO GO - WIP - DONE) in cui le swimlane suddividono le funzioni. Vi è anche una board di ripianificazione in cui sono evidenti le attività dettagliate delle prime due settimane mentre nei mesi successivi ci sono solo le macro attività previste. Questa board, poco utilizzata, ha la funzione di auto-coordinare il lavoro delle persone in base agli adattamenti contingenti, se per esempio un lavoro avrebbe dovuto arrivare ed é in ritardo, le persone che avrebbero dovuto svolgere delle attività in base all’output di quel lavoro si riorganizzano facendo altro utile al progetto. Questa attività di sincronizzazione tra professionisti e attività diverse permette di salvaguardare del tempo che viene salvato nella cosiddetta banca del tempo. Infatti la prima cosa in alto a sinistra che si nota sulla parete sono le regole che quella Obeya si è data:
PRESENZA
ATTENZIONE
SINTESI
VERSAMENTO ORE (WEEKLY)
NO EMAIL (bordato)
Cosa significa no email? Significa che ogni componente del team ha la responsabilità di tenere aggiornati i dati relativi alle proprie attività in Obeya, di tenersi aggiornato andando a vedere in Obeya l’andamento del progetto attraverso l’aggiornamento fatto dagli altri e di partecipare alle riunioni settimanali e, se previste, quelle giornaliere per discutere insieme agli altri i problemi che sorgono durante il progetto e prendere insieme decisioni informate e condivise.
Prima di iniziare la pianificazione il team affronta il progetto mettendo in una matrice tutti i potenziali rischi del progetto. Naturalmente sono congetture basate sull’esperienza e in quanto tali piuttosto realistiche. I rischi vengono valutati in base a criteri di sicurezza, prestazione, qualità, consegna e costo. La matrice prevede sull’asse y delle ordinate la frequenza (bassa - media - alta) e sull’asse x delle ascisse orizzontale l’impatto (basso - medio - alto) formando così una matrice a nove quadrati, tre verdi, tre arancioni in diagonale e tre rossi che indicano la tollerabilità del rischio (zona verde), dove il rischio va tenuto sotto stretta vigilanza (zona arancione) e zona rossa dove occorre creare un piano per mitigare i rischi attraverso una serie di attività che rientreranno nella pianificazione del progetto. Anche i rischi nella zona gialla vengono considerati e probabilmente mitigati.
La matrice ha quindi due funzioni, quella di valutare la fattibilità del progetto in base ai rischi e quella di valutare i tempi del progetto in base alle attività di mitigazione del rischio che vengono ad aggiungersi alle attività di sviluppo. È solo dopo questa analisi che il team può presentare al leadership team gli effettivi tempi di sviluppo del prodotto. La matrice di rischio non finisce con la parte di analisi iniziale, rimane attiva per tutto il periodo del progetto, poiché andando avanti nel progetto emergono nuovi rischi che non era possibile identificare in fase iniziale. I nuovi rischi vengono quindi categorizzati all’interno della matrice e rientrano negli actions plan di mitigazione.
Ogni rischio a un suo numero identificativo, cui è associata una scheda:
La parte centrale contiene la descrizione delle strategie di mitigazione del rischio che possono mirare a ridurne la probabilità di accadimento (frequenza) o la magnitudine dell’impatto nel caso si verifichi. Quindi si progetta dove il rischio si trasferirà nella matrice se la mitigazione avrà successo (il post it verrà fisicamente spostato quando la/le mitigazioni saranno state poste in atto. Ovviamente mitigazioni che si lasciano in zona rossa di rischio sarebbero considerate insufficienti. Nella parte inferiore del foglio vengono elencate le azioni necessarie all’implementazione delle mitigazioni, specificandone da chi saranno attuate, con quale scadenza e lo stato (in attesa, WIP, completata).
Il lavoro del team inter-funzionale non si limita allo sviluppo del prodotto e alla sua prototipazione, si estende alla sua industrializzazione e, come vedremo, segue un ciclo di verifica e miglioramento nei tre anni successivi all’uscita sul mercato. Abbiamo visto all’inizio che il team è composto dalla filiera di funzioni che contribuiscono alla realizzazione del prodotto e alla sua produzione a partire dal marketing, gli acquisti, ingegnerizzazione, produzione oltre alle funzioni tecniche che sviluppano il prodotto. Il team è infatti responsabile di identificare come produrre il prodotto e quindi di costruire la catena di produzione e assemblaggio individuando cosa produrre in casa e cosa e da quali fornitori approvvigionare i componenti necessari, dopo averli testati e comprovati. Il team rende quindi il tutto visuale attraverso diversi strumenti:
La mappa di assemblaggio presenta quindi la sequenza, alloca ogni scheda di processo e componente ad ogni fase, rende visibile il flusso e i potenziali impedimenti, mostra quali attrezzature occorrono e di conseguenza l’investimento necessario, le specifiche da rispettare, i fornitori chiave e quelli di secondo e terzo livello. Questa mappa è anche il punto di partenza per la matrice di auto-qualità.
La matrice di auto-qualità è costituita sia sull’asse verticale che sull’asse orizzontale dalle fasi del processo a partire dal fornitore. Si incrociano sull’asse orizzontale in quale fase è stato creato il problema e in quella verticale in quale fase è stato intercettato il problema. Chiaramente un problema riscontrato sull’asse verticale nella fase, immaginiamo, 50 può essere originato dalla fase 20 dell’asse orizzontale. Sulla scheda di assemblaggio è previsto uno spazio in cui riportare il punto di origine e quello di impatto.
La matrice di auto-qualità è strettamente correlata alla mappa di assemblaggio e le due relative schede ed è un approccio per analizzare, ancor prima di aver realizzato la catena di montaggio e di aver acquistato le macchine, dove possono insorgere i problemi e trovare quindi le potenziali soluzioni. Questo approccio viene definito di upstream e serve per risolvere i problemi prima che accadano. Vi sono diverse tecniche e strumenti che si possono utilizzare, ne citiamo alcuni.
La matrice di auto-qualità è strettamente correlata alla mappa di assemblaggio e le due relative schede ed è un approccio per analizzare, ancor prima di aver realizzato la catena di montaggio e di aver acquistato le macchine, dove possono insorgere i problemi e trovare quindi le potenziali soluzioni. Questo approccio viene definito di upstream e serve per risolvere i problemi prima che accadano. Vi sono diverse tecniche e strumenti che si possono utilizzare, ne citiamo alcuni.
La scheda di descrizione del processo, descrizione visiva attraverso un disegno schematico con i relativi numeri sequenziali, che aiuta l’operatore ad eseguire il processo nel modo in cui è stato sperimentato e corroborato come il più efficace (sappiamo che nel mindset Lean la standardizzazione è la base del miglioramento continuo che implica il fatto che il processo viene sempre successivamente migliorato). Poi vi sono le check list di controllo che l’operatore utilizza per verificare che ciò che ha prodotto non abbia difetti e si assicura di non passare un pezzo difettoso a valle del processo (queste tipologie di check list sono state adottate anche in sede ospedaliera soprattutto nelle sale operatorie). Vi è il poka yoke, che letteralmente significa ‘a prova di errore’, e viene applicato in sede di progettazione per realizzare componenti che possono essere assemblate senza lasciare spazio ad interpretazioni individuali (per esempio la possibile inversione dei cavi o la mancanza di inserimento di un cavo fa emergere la domanda Cosa posso fare in sede di collaudo per verificare la polarità dei cavi?). Il jidoka che dota la macchina di un automatismo che la blocca nel momento in cui si genera un problema di sicurezza o un difetto rilevato dai sensori (ideata da Sakichi Toyoda per le macchine tessili, significa ‘automazione con intervento umano’ e permette ad una persona di non dedicare il suo tempo al controllo di ciò che produce una macchina ma di intervenire solo nel momento in cui la macchina produce un malfunzionamento). Quindi l’andon che permette all’operatore di interrompere il flusso per risolvere il problema immediatamente evitando che scenda a valle (andon è una corda o un pulsante collegato alla macchina o alla fase del processo che accende una luce e un segnale acustico per richiamare l’aiuto di supervisori e manager dove si sta verificando il problema).
Non é tutto. L’approccio Obeya è diventato uno standard in FAAC e il miglioramento continuo ha esteso l’approccio introducendo una serie di gate di controllo (alcuni preferiscono chiamarli milestones) che permettono di verificare lo stadio di avanzamento del progetto e di prendere decisioni, anche drastiche, sul da farsi. Il modello ideato da FAAC prevede una fase di ricerca che fornisce gli input di progetto prima di iniziare un Obeya. A questo punto inizia la vera e propria Obeya con l’analisi di tutti i fattori critici di successo, significa l’analisi dei rischi di progetto e di prodotto, la creazione dei disegni dei componenti critici, l’analisi dei costi attraverso l’analisi dei componenti critici, la ricerca di una lista di fornitori chiave, l’analisi dei requisiti essenziali per la sicurezza (sulla parete una mappa geografica identifica dove si trovano i fornitori e la distanza dal punto di produzione). Questa fase definita di concept ha lo scopo di decidere se ha senso portare avanti il progetto oppure modificarlo o sospenderlo ed evita di prendere decisioni drammatiche quando il progetto si trova in uno stadio avanzato. Passato questo gate si entra nella fase di design dove si realizzano i prototipi dei componenti (spesso utilizzando una stampante 3D o attraverso prototipi prodotti dai fornitori), si convalida la lista dei fornitori, si definisce il piano di ingegnerizzazione della produzione attraverso la mappa di assemblaggio che abbiamo visto precedentemente e si stabiliscono i costi del prodotto finito e dell’acquisto dei macchinari di produzione. L’obiettivo di questa fase è di arrivare alla decisione relativa agli investimenti e al coinvolgimento dei fornitori per la produzione degli stampi. La terza fase è quella di sviluppo vero e proprio dove si realizza la linea assemblaggio e la pre-serie che funge da vero e proprio test con il collaudo della linea di assemblaggio e dei componenti prodotti dai fornitori e la creazione delle istruzioni di prodotto. Quando la pre-serie è collaudata e pronta e tutte le modifiche iniziali sono state approntate si passa alla fase di test vero e proprio che include test LAB, Field test e Beta test, prove fisiche svolte da veri e propri installatori che montando il prodotto identificano eventuali difficoltà e suggeriscono modifiche. Una volta testato il prodotto sul campo è arrivato il momento di lanciare la produzione vera e propria e anche di verificare la reazione del mercato. Per questo vengono monitorati dei KPI su tre anni successivi per misurare il successo del prodotto. I KPI forniscono dati sul numero di richieste di modifiche sul prodotto, il numero di pezzi rientrati in garanzia, il numero di non conformità suddivisi tra rottura di componenti e manutenzioni, numero di pezzi venduti a verifica dei forecast di vendita. Questa suddivisione in fasi di progetto successive costituisce la ciclicità di avanzamento che permette di suddividere l’investimento per ogni ciclo di avanzamento e di decidere se impegnarsi nella fase successiva solo dopo aver acquisito un consistente grado di certezza e di aver apportato le modifiche emerse durante la fase precedente. Ogni fase è anche uno sbarramento decisionale che può implicare la sospensione o la modifica del progetto. È un modo per diminuire i rischi e aumentare l’efficacia.
Infine FAAC ha introdotto a partire dal 2009 il database denominato “lessons learned”. Si tratta di una raccolta di ‘fallimenti’ suddivisa per tipologia di sottogruppi funzionali in cui vengono elencate, secondo una serie di criteri (da risolvere - non applicabile - risolta - non verificata, da convalidare - non risolvibile), che cosa non ha funzionato e come è stato risolto. Significa che le sperimentazioni fatte da un team non rimangono esclusiva conoscenza di quel team ma possono essere condivise all’intera organizzazione e, soprattutto, con gli altri team che hanno a che fare con componenti simili. Lo scopo è quello di non ripetere errori già commessi e di sperimentare nuove strade. Anche questa, se volete, è una forma di standardizzazione al contrario ed è il metodo più efficace di diffondere conoscenze tacite all’intera organizzazione. Quando inizia un progetto tutto il team sa che può ricorrere ad una storia dei fallimenti relativi ad un determinato sottogruppo funzionale ed evitare quindi di ripeterli.
Concludendo ho chiesto di sintetizzare i vantaggi che FAAC ha trovato in Obeya. Il primo elemento di impatto è la consistente riduzione dei tempi di sviluppo di un nuovo prodotto il che spiega il fatto che oggi in FAAC ci sono dieci Obeya di prodotto e tre di processo. Poi c’è il fatto che creare dei team poli-funzionali con tutte le diverse expertise focalizzate su un unico progetto permette di velocizzare enormemente i tempi, di ridurre errori e impedimenti, di comunicare velocemente, grazie al Visual Management System in Obeya, di essere sempre aggiornati in tempo reale (ricordate NO email), aumenta lo scambio di idee anche grazie al fatto di avere fonti di conoscenza che provengono da punti di vista differenti, il che potenzia le prospettive di analisi e di qualità per anticipare i problemi, permette decisioni rapide, informate e condivise (ricordo che il team è autonomo e responsabile dei risultati del progetto). Quello che FAAC ha ottenuto è una maggiore efficacia comunicativa, una drastica riduzione dei tempi, processi decisionali veloci e precisi, informazione aggiornate praticamente in tempo reale, maggior senso di appartenenza del team, un maggior allineamento tra strategia, team, funzioni, dipartimenti e fornitori, in realtà col tempo ha dissolto i silos e quindi ridotto la funzione dei dipartimenti. Obeya è un approccio sistemico il che include sia l’interfunzionalità che la larghezza dei confini del progetto con lo scopo di apprendere collettivamente e prendere decisioni al momento considerando tutti i punti di vista. Non ultimo il grande valore dell’approccio Obeya è la netta riduzione dei cosiddetti difetti di ‘gioventù’ che rappresentano la maggiore vulnerabilità dei nuovi prodotti nella fase di lancio sul mercato con i conseguenti costi di rilavorazione e l’impatto reputazionale che prodotto e brand subiscono.