08162018Thu
Last updateTue, 10 Jul 2018 11am

Design thinking e ingegneria dei sistemi

Verso una teoria generale della progettazione

Enrico Viceconte invita alla lettura di Cloutier R., Baldwin C., Bone M.A., Systems Engineering Simplified, CRC Press, 2015

Premessa

In un post precedente, all’apprezzamento per la scelta del taglio più pratico che teorico del libro “Overcrowded” di Roberto Verganti, aggiunsi che erano utili due approfondimenti.

  • Il primo sulla storia delle teorie sul significato delle cose artificiali. Spero di aver parzialmente assolto, nel breve spazio del post precedente, questo compito piuttosto ampio.
  • Il secondo approfondimento che ritenevo utile era sul ruolo che dovrebbe avere l’ingegneria nell’ambito del design strategico del sistema d’offerta, e, quindi, non solo nello sviluppo di un singolo e isolato nuovo prodotto.

L’idea che vogliamo qui sviluppare è che, ad esempio, nel progetto di una nuova vettura, come l’Alfa Romeo 4C che Roberto Verganti cita, è necessario il controllo e il miglioramento del processo ingegneristico. Anche se i design thinkers ci dicono, giustamente, che, benché necessario, questo non sia sufficiente. Ossia che la vettura, per aver successo, debba offrire “significato” al cliente.

Un processo, quello dell’ingegneria, che va dalla rilevazione dei customer needs, alla trasformazione di questi in requisiti tecnici, alla soluzione di molteplici problemi per massimizzare il soddisfacimento di tali requisiti al fine di giungere a soluzioni ingegneristiche atte a produrre, servire, utilizzare, manutenere (ed eventualmente dismettere e smaltire) quanto progettato. Tutto questo in una strategia complessiva che fa leva su una selezione di capability tecniche distintive (di processo e di prodotto) che, tra loro combinate in modo sapiente e spinte verso il mercato, siano in grado di fare la differenza e conquistare un vantaggio essenziale, relativamente alla concorrenza.

Nella sequenza di attività che abbiamo elencato è lo scopo e il fungere del Product Lifecycle Management (PLM) che utilizza i “body of knowledge” dei domini del Project Management e del Systems Engineering. Uno scopo, una funzione e dei domini di conoscenza che dovrebbero essere sempre più integrati al Design Management e alle conoscenze del dominio del Design Thinking. Tutto questo, a mio avviso, nel più ampio contenitore del design strategico.

Con questo vorremmo suggerire, ai teorici in grado di operare meglio di noi ampie sintesi, il compito di elaborare una teoria generale della progettazione che potrebbe trovare il suo posto naturale nelle Scienze dell’artificiale a cui Herbert Simon aveva dato un nome.

Ingegneria dei sistemi

Ma rimettiamo i piedi per terra e dedichiamoci al Systems Engineering di cui il libricino suggerito può costituire una prima sintesi per non addetti.

Project Management e Systems Engineering sono due discipline che condividono tre obiettivi:

  1. accrescere l’efficacia e l’efficienza dei progetti, in termini di flusso di valore pianificato e prodotto per un cliente o una parte interessata (quindi valore prodotto e tempo in cui viene prodotto) e di flussi di costi e di ricavi.
  2. Mitigare i rischi di mancare gli obiettivi di valore, tempo e costo rispetto a quanto richiesto e pianificato.
  3. Accumulare, migliorare e assicurarsi che sia diffuso e applicato un corpus di conoscenze metodologiche e saggezza proveniente dalle due comunità di pratica professionale di riferimento: i Project Manager (PM) e i Systems Engineer (SE). Tutta la conoscenza standardizzata, distribuita e utilizzata serve al raggiungimento dei primi due obiettivi.

Cosa distingue dunque l’approccio di un PM da quello di un SE? Per un progetto a bassa complessità sistemica le due figure potrebbero tranquillamente coincidere in una sola figura, nel caso in cui questi abbia la competenza per abbracciare sia tutto il ciclo di vita tecnico del progetto sia tutto quello gestionale.

Per la realizzazione di una torta commissionata a una pasticceria, la competenza tecnica e quella gestionale-organizzativa possono fondersi nella figura del pasticcere. Questi domina il contenuto tecnico di ogni attività (ingredienti, ricetta, impasto, cottura, decorazione, servizio) detenendo conoscenza esplicita e tacita, ma è anche in grado di applicare correttamente gli aspetti di pianificazione, controllo, organizzazione (di tipo manageriale e non tecnico) che concorrono al successo della singola torta e della pasticceria.

Per la realizzazione di una spedizione su Marte, che possiamo considerare di complessità sistemica maggiore di quella di una torta, nasce l’esigenza di una divisione del lavoro tra chi si occupa dell’aspetto gestionale, per mitigare il rischio di fallire gli obiettivi per motivi organizzativi, e chi si occupa dell’aspetto tecnico (ingegneristico, in questo caso), per mitigare il rischio di fallire gli obiettivi per motivi tecnici e tecnologici.

La responsabilità del PM e quella del SE coprono tutto il ciclo di vita del progetto. Ma possiamo dire che il contributo del PM è più sensibile nelle fasi di pianificazione, esecuzione, controllo e chiusura del progetto, mentre quella del SE è più sensibile nella fase di inizio, nella quale si possono fare errori grossolani nella raccolta dei customer needs, nella trasformazione di questi bisogni in requisiti tecnici e nell’assegnazione ai team tecnici specialistici di obiettivi dei diversi pacchetti di lavoro che saranno poi integrati in un unico sistema. Insomma, semplificando molto con un esempio, si rischia di progettare un motore che alla fine risulta troppo pesante per la struttura (con problemi strutturali) o una struttura troppo pesante per il motore (con problemi di prestazione). Con il rischio di ricominciare daccapo, perdendo tempo e denaro.

In sintesi, un buon lavoro di un SE all’inizio di un progetto di sviluppo prodotto, facilita il lavoro del PM nella pianificazione, nell’esecuzione, nel controllo e nella chiusura. E tutti e due contribuiscono al raggiungimento degli obiettivi degli stakeholder del progetto. Migliore è la qualità dei propri SE e dei propri PM e delle metodologie applicate, più competitiva sarà una certa organizzazione rispetto a quelle concorrenti.

 

 

Figura 1. L’impiego di Systems Engineers nella fase iniziale del progetto, consente di prevenire problemi che potrebbero comparire troppo tardi, riducendo il costo complessivo (l’area sottesa alla curva), il tempo e i rischi. La figura è puramente qualitativa.

Le competenze e la formazione del Systems Engineer

Ho diretto un programma di formazione ispirato a questi principi che accomunano o distinguono i compiti del SE e del PM. Il programma si intitolava “Systems Engineering & Project Management” e si rivolgeva, con moduli in aule a volte congiunte e a volte separate, a SE e PM del CIRA, Centro Italiano di Ricerche Aerospaziali, un organismo di livello internazionale in grado di sviluppare progetti ad elevatissima complessità sistemica per i quali si può scoprire in corso d’opera, in fase molto avanzata nel progetto, correndo rischi altissimi, che il lavoro del team delle strutture, quello dei propulsori, quello dei sistemi di bordo e quelli dei sistemi di terra siano di difficile integrazione o non adeguati, una volta integrati, al concept operativo (Concept of Operations) o alla missione complessiva richiesta dal committente. Durante il corso avemmo testimonianze di Thales Alenia Space e di Avio-ELV (Settore Space), MBDA e Selex (Settore Defense), Centro Ricerche Fiat (Settore Automotive).

Dopo questa esperienza pioneristica per l’Italia, abbiamo affiancato al modulo di PM un modulo di Systems Engineering sia in un programma Master per neolaureati in ingegneria (MOM, Master in Operations Management) sia nell’Executive Master in Tecnologie e Sistemi Avanzati per la Produzione Aeronautica, programma a contenuto prevalentemente manageriale per ingegneri e tecnici delle imprese della supply chain di Alenia Aermacchi (oggi Leonardo). Infine, abbiamo sviluppato un modello di competenze del Systems Engineer per L’Aerospazio, il cui profilo professionale è stato inserito nel repertorio delle qualificazioni regionali e nell’Atlante del Lavoro dell’INAPP- Ministero del Lavoro, a livello EQF 7.

Quali convergenze tra Design Thinking e Systems Engineering?

Gli esempi che ho portato di applicazione della Systems Engineering sembrano escludere di avere qualcosa in comune col Design Thinking e suggerire che un tale approccio metodologico possa essere di utilità solo sui mega-progetti di aerospazio e difesa, dove si è sviluppata la disciplina. In realtà il libro che vi propongo, che mostra in copertina una macchinetta per il caffè privata della “carrozzeria”, come l’Alfa 4C nella foto del primo post, ci aiuta ad applicare alcune metodologie del SE anche per singoli prodotti, meno complessi di un’astronave.

Viste una ad una, le metodologie del SE non sono altro che metodologie strutturate per co-operare, co-progettare, co-creare, co-validare più intensamente e più efficacemente con il cliente (anche quello interno), gli stakeholder e gli esperti delle singole discipline, in fase precoce del progetto di un nuovo prodotto o sistema prodotto e in fasi successive del ciclo di vita. Lo stesso obiettivo del Design Thinking.

Tutte e due le metodologie hanno a che fare con il valore per il cliente e con il processo creativo necessario a configurare un prodotto o un servizio. Nel caso del SE il processo creativo che parte dai singoli esperti (di estrazione tecnica) deve essere “moderato” e incanalato verso l’integrazione finale, nel caso del DT il processo creativo deve essere “amplificato”. La sequenza di fasi divergenti e convergenti, attraverso cui fluiscono le attività di progetto, è comune ai due approcci.

La differenza sostanziale è nel verso del vettore che collega il cliente con il gruppo di progetto. Il design thinking opera inside-out, come dice Verganti, sviluppando interazioni significative coi clienti a partire da una visione interna al nucleo del gruppo di progetto, il systems engineering opera outside-in, a partire da requisiti specificati dal cliente (anche interno) e dalle altre parti interessate.

Una somiglianza sostanziale è nel principio per cui il prodotto si sviluppa con un processo e una modalità organizzativa del team “agile”, prevedendo uno spacchettamento più granulare delle diverse attività, un timeboxing più fitto e regolare, la validazione ad ogni passo, la ritualizzazione di frequenti e regolari riunioni di avanzamento brevi, in forma di stand-up meeting assistiti da strumenti di visualizzazione posti sulle pareti. Tale aspetto accumuna i due approcci all’”Agile Project Management”, nato nell’ambito dello sviluppo software ed esteso a tutti gli altri settori e al “Lean Product Development”, nato, con finalità di concurrent engineering, in contesto automotive e sviluppato anche in altri settori. La co-location di un numero elevato di persone coinvolte nella progettazione, in ambienti aperti opportunamente concepiti, accomuna le diverse metodologie.

Una seconda somiglianza è nell’utilizzo di “narrative” per simulare in fase precoce di sviluppo, durante la elaborazione del concept per validare il concept in base alla simulazione delle sequenze operative in cui il prodotto verrà impiegato. Nel caso del Design Thinking parliamo, ad esempio, di Customer Experience Journey, nel caso del Systems Engineering parliamo, ad esempio, di Concept of Operations (ConOps).

Una terza somiglianza è nell’ambizione delle due metodologie di potersi occupare di tutto il Product Lifecycle Management, vale a dire non solo della componete paradigmatica del prodotto (l’albero gerarchico delle funzioni sviluppate e quello dei componenti che costituiscono il prodotto), ma anche di quella sintagmatica, la sequenza delle fasi che abbiamo poc’anzi detto: analisi dei bisogni, concezione del prodotto, configurazione, progettazione, validazione, gestione dei cambiamenti in corso d’opera, ingegnerizzazione e sviluppo del processo produttivo, produzione, distribuzione, connessione/integrazione del prodotto ad altri prodotti e servizi, utilizzo, service, dismissione ed eventuale smaltimento).

Il SE si adatta allo sviluppo di prodotti in cui è preponderante il requisito tecnico e funzionale (di cui l’astronave è un esempio estremo). Il DT si adatta invece allo sviluppo di prodotti in cui è preponderante il significato e lo stato d’animo che il cliente assocerà all’utilizzo del prodotto (di cui un’opera d’arte è un esempio estremo). Poiché tra questi due estremi sono collocate tutte le esperienze di utilizzo e di consumo intermedie, dalla torta all’automobile sportiva, è auspicabile che le due discipline possano convergere.

Se il Systems Engineering mostra, anche nel nome, una sua discendenza dall’ ingegneria, dalla scienza e dalla tecnica, il Design Thinking mostra la sua discendenza dall’architettura e quindi dalle discipline della forma, dalle scienze umane e del linguaggio.

Una possibile Teoria generale della progettazione, che, come dicevamo potrebbe iscriversi nelle scienze dell’artificiale di Herbert Simon, dovrebbe favorire la convergenza possibile dei due approcci. Il che promette interessantissimi nuovi filoni di ricerca.

In figura (fonte):

un tipico diagramma a V (Vee diagram) del Systems Engineering che mostra come la sequenza di blocchi in cui si articola lo sviluppo di un prodotto, possa essere piegato a V, e prevedere a ciascuno dei livelli di sistema, sotto-sistema e componente, un’attività di verifica e validazione (orizzontale) che, al livello più alto in cui viene stabilita l’architettura generale del sistema, consente di testare precocemente se il concept, l’architettura e lì operatività saranno considerate idonee relativamente ai requisiti di accettazione da parte del cliente.

 

 

Enrico Viceconte

Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

Pin It