Introduzione

“Adottare un approccio iterativo e incrementale nello sviluppo del prodotto”.

“Far lavorare insieme gli sviluppatori e gli stakeholders”.

“Ridurre i tempi di ideazione e sviluppo per migliorare il time-to-market di un prodotto”.

“Riconoscere l’importanza di team interdisciplinari e della comunicazione efficace fra di essi”.

Sicuramente avrete già sentito queste enunciazioni, anche troppe volte. Ogni introduzione alle metodologie Agile per lo sviluppo del software, ma anche ogni approfondito corso di Scrum, non potrà fare a meno di ripetere, magari in forma leggermente diversa, quanto avete appena letto. Ovviamente accanto ad altri concetti e a ben specifiche pratiche.

Ma questa volta non stiamo parlando di Scrum o Kanban e di processo di sviluppo software, bensì di un metodo utilizzato in ambito ingegneristico per la progettazione di “manufatti” meccanici, elettronici, per la realizzazione di velivoli e altri mezzi di trasporto, e così via: parliamo del cosiddetto Concurrent Engineering (CE) o “ingegneria simultanea”.

Ma, prima di vedere meglio in cosa consiste, quali sono le pratiche che prevede e perché ha tutte queste similitudini con le metodologie agili conosciute nell’ambito dei processi di sviluppo software, partiamo proprio da qui: che cosa è stato realizzato con il Concurrent Engineering, il che comincerà fin da subito a farci capire quanto sia potente questo approccio, ma anche qualcos’altro di interessante.

Alcuni prodotti realizzati con Concurrent Engineering

Ci sono svariati esempi in cui il Concurrent Engineering ha avuto un ruolo riconosciuto nel progetto. Vediamone di seguito solo alcuni.

• Uno dei casi più noti è quello della Boeing con il progetto del Boeing 777. Fin dalle prime fasi del progetto, ingegneri, progettisti, fornitori e clienti sono stati fatti lavorare insieme proprio come previsto nel Concurrent Engineering, al fine di sviluppare al meglio il progetto dell’aereo. Per quanto possa suonare abbastanza trito, l’azienda ha dichiarato che in tal modo si sono ridotti i tempi di sviluppo e si è migliorata la qualità del design perché è stato possibile integrare rapidamente il feedback dei clienti.
• L’azienda automobilistica Ford ha utilizzato il Concurrent Engineering per sviluppare nuovi modelli. Durante la progettazione e la realizzazione della Ford Taurus, sono stati coinvolti team interdisciplinari per lavorare simultaneamente su diverse parti del progetto. Questo ha portato a una significativa riduzione dei tempi di sviluppo e a un miglioramento della qualità complessiva del veicolo.
• General Electric (GE) ha applicato il Concurrent Engineering nello sviluppo di nuove turbine a gas. In tal modo, è stato possibile coordinare meglio le attività di progettazione, ingegnerizzazione e messa in produzione: il prodotto finale ha dimostrato ottime prestazioni a fronte di una riduzione del cycle time.
• Lockheed Martin ha utilizzato il Concurrent Engineering nello sviluppo dell’aereo da combattimento F-35. Anche qui, l’integrazione di team di progettazione, ingegneria e produzione fin dalle prime fasi ha consentito di affrontare e risolvere rapidamente i problemi, migliorando l’efficienza e la qualità del progetto.
• Toyota è nota per il suo approccio avanzato alla produzione e allo sviluppo dei prodotti: è in quest’azienda che è nato il metodo di produzione Toyota, tradotto in Occidente come Lean. E vedremo quanto questo sia connesso con il Concurrent Engineering che è stato usato, per esempio, nello sviluppo del modello Prius.
• Apple utilizza il Concurrent Engineering per sviluppare i suoi prodotti, come gli iPhone e i MacBook. Coinvolgendo designer, ingegneri hardware e software, produttori e altri stakeholder fin dalle prime fasi del processo, Apple è in grado di ridurre i tempi di sviluppo e garantire che i suoi prodotti siano altamente integrati e di alta qualità.

Cosa ci dicono queste brevi note? Sì, che il Concurrent Engineering è un metodo applicato nelle più importanti aziende e anche su prodotti abbastanza differenziati. Ma ci indicano ancora di più un’altra cosa: se guardiamo ai prodotti appena citati, capiamo che non si tratta di una novità, ma di un approccio applicato da decenni. La Ford Taurus risale alla seconda metà degli anni Ottanta, il Boeing 777 risale a metà anni Novanta, la Toyota Prius è stata lanciata sul mercato mondiale nel 2000, dopo tre anni dalla prima produzione per il mercato giapponese. E allora? Come stanno in rapporto il Concurrent Engineering e le metodologie agili per lo sviluppo del software, ispirate dal celebre Manifesto [1] che è del 2001?

Un po’ di storia

Il termine Concurrent Engineering, a volte anche Simultaneous Engineering (ingegneria simultanea), fu utilizzato per la prima volta negli Stati Uniti nel 1988 in un articolo della rivista Fortune [2] che trattava, appunto, del successo dell’automobile Ford Taurus. Gli anni Ottanta del Novecento furono infatti quelli in cui l’industria automobilistica mondiale conobbe il successo del sistema produttivo Toyota, che in molti casi cercò di imitare, non sempre capendone appieno la sottostante mentalità. Si trattò peraltro di un periodo in cui il comparto automotive dovette trovare nuove modalità di produzione in un periodo di notevoli cambiamenti.

Riflessione e definizione del Concurrent Engineering

L’interesse intorno al tema crebbe nel decennio successivo, con il tentativo di sistematizzare le “lezioni” del Concurrent Engineering. In un articolo del 1993, più orientato agli aspetti di Project Mangement [3] che a quelli tecnici — che vedremo più avanti — del Concurrent Engineering, si affrontava un problema che già allora appariva cruciale: come favorire e gestire l’integrazione fra i diversi team coinvolti nel progetto, problema che veniva risolto con un misto di tecniche abbastanza vecchio stile ma anche con una serie di concetti e pratiche che oggi consideremmo sicuramente Lean/Agile. Tra queste seconde, spicca chiaramente la constatazione che

…the most effective means to integrate separate teams is to facilitate and ensure strong and direct communication links across the project organization.

Che il Concurrent Engineering vada fatto risalire a quel mondo nordamericano che studiava, interpretava e cercava di mettere in pratica i principi del modello produttivo Toyota lo testimonia bene anche un articolo del 1999 [4] in cui si mette in guardia coloro che tentano di copiare le pratiche o i processi di Toyota come da un libro di ricette: non si tratta di step o di processi pronti all’uso, notano gli autori, quanto piuttosto di un insieme di principi da comprendere ed adattare ai diversi contesti.

Concurrent Engineering e Agilità: due filoni con un’origine comume

Ora che abbiamo qualche tassello in più per ricostruire il periodo e l’ambito in cui nasce questa metodologia, ci tornerà più facile comprendere come ci troviamo proprio in quel contesto industriale e temporale da cui — a partire dalle intuizioni di due autori giapponesi [5] che paragonano la gestione di prodotti elettromecanici ed elettronici al gioco del rugby e nel 1986 coniano la denominazione di Scrum — nascerà l’applicazione dei principi “lean” al mondo dello sviluppo software con la proposta di Ken Schwaber [6] che nel 1995 rappresenterà un primo punto fermo sull’evoluzione di Scrum.

Pertanto, per chiudere questo excursus storico, sia Concurrent Engineering, sia metodologie come Scrum, muovono i loro primi passi dalla reinterpretazione nordamericana dei principi e delle pratiche nate in Toyota e diffusesi prima in varie aziende automotive e poi in aziende di altri settori.

Concurrent Engineering resterà legato al mondo della progettazione e produzione industriale. Scrum, e le altre metodologie che verranno conosciute come “agili”, si applicheranno al mondo dello sviluppo del software. Salvo tornare, un paio di decenni dopo, in contesti produttivi industriali più affini a quelli da cui erano nati i principi che ne sono alla base.

Concurrent Engineering, in breve

Adesso, però, è il momento di fornire un quadro sintetico ma complessivo, su quali siano i principi e le pratiche tipiche di Concurrent Engineering. Come vedremo, ci sono degli aspetti tecnici legati all’adozione di determinate tecnologie che collocano questo approccio chiaramente nel mondo della produzione industriale. Ma ai lettori non sfuggiranno le numerose affinità che lo legano a metodologie come Scrum e Kanban, sicuramente più familiari a chi si occupa di sviluppo software.

Una possibile definizione

Il Concurrent Engineering — detto a volte anche Concurrent Design an Engineering (CDE) oltre che “ingegneria simultanea” o “processo parallelo” — è un approccio alla progettazione e ingegnerizzazione di prodotti caratterizzato dall’essere iterativo, cross-functional e integrato/interconnesso. Lo scopo sta nel migliorare il processo di ideazione, progettazione e sviluppo, con uno sguardo d’insieme a tutte le fasi del ciclo di vita del prodotto. Questo approccio richiede cambiamenti di mentalità e di organizzazione rispetto al classico sistema produttivo sequenziale e pone grande enfasi sull’importanza di team interdisciplinari ben formati in termini di competenze, sul feedback fornito dalle varie aree funzionali, sulla necessità di riconciliare le divergenze nella fase di progettazione. La sua caratteristica più evidente è che le fasi di progettazione che interessano le diverse aree funzionali vengono svolte simultaneamente e non in sequenza.

I risultati che ne derivano sono una riduzione dei tempi di consegna e un miglioramento della qualità del prodotto, nel senso di maggiore aderenza alle necessità reali del cliente e di individuazione precoce dei difetti, con conseguente loro correzione. Nulla di nuovo, come già detto; ma, di sicuro, qualcosa di fondamentale.

I principi del Concurrent Engineering

Concurrent Engineering è caratterizzato quindi dalla gestione parallela di attività tradizionalmente sequenziali nel processo di sviluppo del prodotto. Invece di completare una fase prima di passare alla successiva, le attività di progettazione, ingegnerizzazione, produzione e marketing vengono eseguite contemporaneamente, in modo integrato e collaborativo. Ma questo è possibile perché si seguono dei principi che vengono applicati adeguandoli al contesto specifico in cui si sta operando. Vediamoli di seguito.

• Simultaneità: le attività di sviluppo del prodotto sono svolte contemporaneamente invece che in sequenza.
• Integrazione: coinvolgimento di team interdisciplinari (ingegneri, designer, produttori, esperti di marketing) fin dalle prime fasi del progetto.
• Collaborazione: comunicazione e collaborazione continua tra i diversi attori del progetto. Questo principio comporta anche la necessità di mettere a punto modalità opportune di comunicazione e coordinamento fra i team che, senza una adeguata “integrazione”, non potrebbero confrontare il loro lavoro e trovare la sintesi migliore.
• Iterazione e feedback rapido: Iterazione continua su cicli brevi e feedback immediato per correggere eventuali errori e migliorare il design in tempo reale. Anche per questo principio vale quanto appena detto: modalità efficaci per dare e ricevere feedback sono cruciali all’interno dell’organizzazione.
• Uso di Strumenti Digitali: Utilizzo di strumenti avanzati di progettazione assistita da computer (CAD), gestione del ciclo di vita del prodotto (PLM), simulazione e prototipazione virtuale. L’aspetto pratico di questo principio verrà discusso tra poco.

Gli strumenti digitali in Concurrent Engineering

Uno degli aspetti che colpiscono in CE è la sua attenzione, fin da subito, al massiccio uso di strumenti digitali per la progettazione e la gestione di processo. Se questo oggi ci appare banale, non dimentichiamoci che questo approccio è presente fin dai primi anni Novanta, periodo in cui ‘uso combinato di tali strumenti era davvero innovativo. Nella moderna Industry 4.0, certi principi e certi sistemi hanno raggiunto una estesa adozione, ma non era così per molte fabbriche dei primissimi anni Novanta del secolo scorso. È chiaro anche come tutto questo richiese investimenti significativi in tecnologie di supporto e formazione del personale.

Gli strumenti e le tecnologie fondamentali per il Concurrent Engineering sono elencati di seguito.

• CAD (Computer-Aided Design): strumenti per la progettazione dettagliata e la visualizzazione 3D dei prodotti.
• CAE (Computer-Aided Engineering): software per la simulazione e l’analisi ingegneristica.
• PLM (Product Lifecycle Management): sistemi per la gestione del ciclo di vita del prodotto, dall’ideazione alla dismissione. Nell’attuale, non rinviabile, ottica di sostenibilità economica e ambientale, strumenti come questi consentono di conoscere i reali rapporti costi/benefici tenendo in considerazione non solo la costruzione del prodotto, ma anche il suo esercizio e il suo smaltimento.
• PDM (Product Data Management): sistemi per la gestione dei dati di prodotto e della documentazione tecnica.
• Collaborative Platforms: piattaforme digitali per la collaborazione e la comunicazione tra i team di progetto.

Conclusioni

Ecco spiegate brevemente le similitudini e le diversità tra il Concurrent Engineering e i metodi agili come Scrum: le esperienze industriali e il contesto culturale e da cui prendono le mosse sono gli stessi e affondano le loro radici nel sistema di produzione Toyota, poi rielaborato come lean manufacturing, tra la fine degli anni Settanta e la prima metà degli anni Ottanta del secolo scorso.

Pur con tutta l’evoluzione, l’adattamento e la necessità di calarli nel nuovo contesto economico e produttivo che si è configurato negli ultimissimi anni, i principi che connotano questi due filoni metodologici restano validi per i tempi a venire.

Riferimenti

[1] Manifesto for the Agile Software Development

https://agilemanifesto.org/iso/en/manifesto.html

[2] Alex Taylor – Charles A. Riley, Why Fords sell like Big Macs. Fortune Magazine, 21/11/1988
https://money.cnn.com/magazines/fortune/fortune_archive/1988/11/21/71294/index.htm

[3] Kent R. McCord – Steven D. Eppinger, Managing the Integration Problem in Concurrent Engineering. Working Paper, MIT – Sloan School of Management, August1993
https://mitsloan.mit.edu/shared/ods/documents?PublicationDocumentID=9590

[4] Durward K Sobek II – Allen C Ward – Jeffrey K Liker , Toyota’s Principles of Set-Based Concurrent Engineering. Sloan Management Review, Winter 1999; 40, 2
https://www.researchgate.net/publication/248139929_Toyota%27s_Principles_of_Set-Based_Concurrent_Engineering

[5] Hirotaka Takeuchi – Ikujiro Nonaka. The New New Product Development Game. Harvard Business Review, January 1986
https://hbr.org/1986/01/the-new-new-product-development-game

[6] Ken Schwaber, SCRUM Development Process. 1995
https://www.thescrummaster.co.uk/wp-content/uploads/2016/09/SCRUM-Development-Process-K-Schwaber.pdf