L’autore di questo post è Silvano Joly, country manager di Centric Software Italia, che dal 1995 lavora in aziende high tech seguendo il mercato italiano e del Mediterraneo – 

I tragici fatti del Boeing 737 Max precipitato lo scorso 10 marzo dopo il decollo mi hanno causato grande tristezza, ma mi hanno anche fatto fare qualche considerazione.

Rispetto ai modelli precedenti il “Max” ha infatti un motore più efficiente, scelto perché consuma il 20% di carburante in meno. Questo turbogetto è costruito da Snecma (una joint venture tra GE e Safran) ed è più grande e pesante di quello che i 737 montavano in precedenza. Pertanto, gli ingegneri della Boeing lo hanno dovuto installare più avanti e più in alto sull’ala, modificando il bilanciamento dell’aereo.

In base a quanto dicono gli esperti, è diventato così quasi impossibile far volare il nuovo aereo ed è stato necessario usare un software per governarlo. Un sistema informatico per il controllo di volo, al posto del pilota. Proprio così: Boeing ha installato il sistema come parte dei comandi emessi dal computer dell’aereo che governano in automatico l’aereo, “bypassando” i piloti nella correzione dell’angolo d’attacco, cioè quello tra l’ala e la direzione relativa del vento.

A quanto pare il sistema MACA che doveva aiutare i Piloti – ed ovviamente proteggere i Passeggeri – è stato proprio la causa del disastro e sono in corso gli aggiornamenti, le modifiche, gli aggiustamenti a quella tecnologia abilitante che invece è stata dannosa, addirittura mortale.

Ma quanto spesso succede che lo stesso software, perché sempre di software si tratta, sia disabilitante se non dannoso invece che utile, anche nelle aziende che installano programmi informatici per migliorare i loro processi?

Molto, molto spesso. Ma come è possibile? È una questione di prospettive: nelle aziende le scelte e gli investimenti (Business Initiatives) si fanno in base alle indicazioni degli Azionisti (Corporate Objectives) e le prime dovrebbero far succedere le seconde attraverso delle Unit Actions (cioè azioni operative dei vari reparti).

Semplificando il caso Boeing, l’obiettivo corporate era “La concorrente Airbus ha fatto un aereo per il corto–medio raggio che consuma meno. Facciamolo anche noi, per aumentare il market share e aumentare lo stock value”. Di conseguenza la Business Initiative: “Mettiamo dei soldi sì, ma dato che non ne abbiamo abbastanza per fare un aereo nuovo, cambiamo solo i motori di un best-seller come il B737”.

E si è arrivati alla realizzazione con una “technical implication”: con i motori nuovi dovremmo modificare ali, impennaggio e tutto l’aereo. La Unit Action come sappiamo è stata inserire un software per aiutare i piloti… e conoscete il resto della storia.

Che peraltro è ancora in corso, visto che Boeing non ha rilasciato l’aggiornamento definitivo e chi sale in aereo spera che alla cloche ci sia uno come Chesley Sully Sullenberger che alla faccia di tutti i manuali e piloti automatici, salvo i suoi passeggeri ammarando sul fiume Hudson.

Ma quanto tutto ciò c’entra con le aziende ed i programmi? C’entra, c’entra… specie se lo vediamo dal punto di vista del processo Corporate Objective, Business Initiative, Unit Actions.

Pensiamo all’azienda che ha l’obiettivo corporate di espandersi all’estero, ed attiva la Business Initiative di cambiare Gestionale o di comprarsi un sistema PLM (Product Lifecycle Management). Qual è il modo giusto di dare corso alle Unit Action, “lasciare fare” ai responsabili dei reparti o mantenere il controllo a livello del CdA?

Per rispondere ho chiesto aiuto a due giovani professionisti con i quali ho la fortuna di lavorare e che rispetto molto: un management consultant di una delle più grandi società di consulenza nei settori CRM, Digital Marketing e Product Development specie per Fashion e Consumer Goods, e una giovane donna, anche lei management consultant in una delle Top 5, poliglotta ed esperta in Omnichannel Customer Experience, Retail Innovation, Store of the future, Strategy Consulting. Entrambi nel loro lavoro rendono possibile la promessa che i Consigli di Amministrazione chiedono ai dirigenti, affiancandoli ed aiutandoli a “fare i compiti” prima di far decollare l’aereo tento per restare in tema aeronautico.

Al primo, BBA all’Università del Sacro Cuore e Master alla Bocconi, ho domandato: “Quanto è importante la fase di analisi, preparazione e studio che deve precedere la scelta e la successiva messa in produzione di un sistema software?” Ecco come il mio “nipote di business” mi ha risposto:

La scelta di un nuovo software da inserire all’interno dell’azienda è sempre una decisione delicata in quanto l’adozione di una piattaforma dovrebbe generare dei reali benefici per l’intera azienda, che però è costituita da risorse con diversi backgrounds, interessi e ruoli che quindi potrebbero portare ad avere visioni differenti sul reale beneficio che un nuovo software può creare.

Altro fattore rilevante riguardo la decisione di adottare un nuovo software è capire quanto il nuovo sistema è in grado di integrarsi con le altre piattaforme già esistenti all’interno dell’azienda, creando un reale surplus di valore. Queste sono solo alcune delle ragioni che rendono di fondamentale importanza l’analisi preliminare da realizzare prima di arrivare a scegliere un nuovo software. Per analisi intendiamo non uno studio a tavolino ma una vera e propria immersione in quella che è la realtà del cliente, spesso costituita da realtà contrastanti che sottolineano la necessità di avere una piattaforma agile e flessibile che possa migliorare i processi senza stravolgerli.

Guardando ad esempio all’ambito dello sviluppo prodotto, (il processo che va dall’Idea dello Stilista alla Commercializzazione del Prodotto, NdR) spesso capita di dover coniugare mondi creativi e tecnici in cui la tecnologia deve agire da elemento invisibile in grado di aumentare la collaborazione ma rispettando sempre le esigenze dei singoli attori coinvolti. Oggi una semplice dimostrazione del software da implementare, se non tradotta nel linguaggio del cliente, rischia di essere un boomerang che distrugge il valore di quello che si vuole proporre invece che esaltarne le funzionalità!

Analoghi ragionamenti sono validi anche per la configurazione della piattaforma, una volta che il software è stato scelto. Il nuovo, soprattutto se riferito alla tecnologia, spesso spaventa le aziende per paura di andare ad alterare meccanismi e processi che negli anni hanno accresciuto il valore dell’azienda e quindi fin dai primi istanti di messa in produzione diventa importante co-creare valore con tutti i diversi attori coinvolti in questo importante processo di trasformazione digitale.

Il primo passo del coinvolgimento è rappresentato dall’analizzare sia il singolo ruolo di ogni attore ma anche come la sua funzione si inserisce nell’ecosistema azienda al fine di iniziare a capire quali sono le dinamiche aziendali in modo da non alterarle durante la successiva realizzazione della piattaforma. Per raffinare quanto emerso dall’analisi con ciascun attore, in fase di disegno del modello che costituisce la base su cui costruire il nuovo software è fondamentale avere tutti gli attori attorno allo stesso tavolo per misurare le loro reazioni man mano che il modello da implementare viene definito. Durante questa serie di workshop l’obiettivo da raggiungere è arrivare a definire quei macro-requisiti fondamentali per iniziare lo sviluppo della piattaforma e arrivare alla definizione dei dettagli solo in fase di test del nuovo sistema con i diversi attori in quanto prima di provare la nuova piattaforma difficilmente si riesce a comprenderne a pieno le funzionalità e gli impatti sul proprio lavoro. 

Questo metodo viene spesso definito “AGILE” e al giorno d’oggi, con piattaforme sempre più innovative, diventa fondamentale utilizzare simili approcci per evitare di creare a tavolino un “mostro” impossibile da utilizzare.

La metodologia Agile in pillole

E sentite cosa mi ha detto la seconda, Laurea e Master alla Bocconi, quando le ho chiesto:
“Dov’è e quanto è grande il valore dell’analisi del cosiddetto ecosistema, sia interno – di sistemi, operazioni e processi – che esterno – di fornitori, clienti, partner ed anche concorrenti – per cercare di capire quali siano state le scelte, possibilmente quelle buone, e gli errori – possibilmente da non ripetere – effettuati sul mercato ed in giro per il mondo?“

Caro Silvano, pensa alla Open innovation l’espressione coniata dallo scrittore ed economista statunitense Henry Chesbrough nel 2006, per definire “un paradigma che afferma che le imprese possono e debbono fare ricorso ad idee esterne, così come a quelle interne, ed accedere con percorsi interni ed esterni ai mercati se vogliono progredire nelle loro competenze tecnologiche.

Nel nostro lavoro di oggi giorno questo si traduce in una relazione sempre più sinergica con l’ecosistema, costituito da partner, competitor, clienti e fornitori, dove la contaminazione è la chiave per superare i propri limiti. Delinea un cambio di paradigma e mentalità per aprirsi al nuovo, quasi una tendenza alla ribellione nei confronti di un rigido sistema di conoscenza (software aziendale) per abbracciare un modello dove co-creazione e collaborazione tra imprese differenti siano i veri abilitatori del successo.

Diversi sono i casi esemplari di questo cambiamento: sicuramente uno è Adidas che incentra la sua strategia sul concetto di “Open Source”, in cui atleti, consumatori e clienti sono chiamati a definire e contribuire al futuro del brand.

Anche la consulenza, esempio emblematico di “old/legacy”, dove il pensiero e di conseguenza la difesa/copyright del “paper” definivano il valore del pensiero, si sta aprendo a questo approccio. Come ben sai io lavoro in Accenture, il nostro mantra è NEW APPLIED NOW e la filosofia del centro di innovazione ACIN che tu frequenti da sempre è quella un Hub, dove l’apertura si concretizza nella collaborazione con partner come Google e WeChat. Le tecnologie emergenti identificate vengono poi applicate ai clienti attraverso la costruzione di una proposizione congiunta con startup, partner, fornitori, dove il valore di ogni stakeholder viene esaltato.

Proprio in questa direzione è andato l’evento svolto a settembre in ACIN in collaborazione con il gigante di Mountain View, durante il quale abbiamo mostrato come le tecnologie di Google, nello specifico l’IA, possono apportare valore lungo tutta la value chain del Fashion. Evento che ha seguito quello con WeChat ed quello con Centric Software, proprio nel filone di proporre non software ma tecnologie abilitanti lungo un processo definito oppure all’interno di uno nuovo o rinnovato, capace appunto di usare le nuove soluzioni, una per tutte l’AI che solo pochi anni fa era dominio della sola ricerca applicata.

Oggi tutto è cambiato, o meglio la chiave di lettura è completamente diversa. Ci si deve predisporre all’utilizzo della “proprietà intellettuale” come strumento di collegamento, anziché soltanto di esclusione. E non ci si può “opporre”, è sbagliato fare resistenza, sono troppi i fattori che hanno portato ad un’accelerazione di questo modello, ed i più importanti e potenti sono la maggiore accessibilità alla informazioni e il minore attaccamento alla conoscenza rigida.

Quanto mi hanno detto questi giovani amici, preparati e modesti a differenza di tanti tromboni over 50 come me, è alla base delle best practise dell’ingegneria ma spesso viene disattesa. Un vecchio capo mi diceva sempre: “Vigilate and be paranoid with your projects. Since everyone understand but few execute”. Infatti succede proprio così: le indicazioni di corporate sono chiare, essendo obbiettivi, le iniziative di business possono esserlo altrettanto ma solo se attivate dopo un attenta analisi di quanto una nuova soluzione può compromettere quelle esistenti. Massima cautela nelle azioni a livello di reparto dove il rischio di realizzare qualcosa di opposto ai desiderata è altissimo.

Il dilemma dell’altalena è un tipico esempio, come lo è tristemente la storia del software sul 737 Max. Dove una catena di iniziative ha portato anziché alla realizzazione di un utile per Boeing ad un epicamente tragico risultato finale.

Il processo precedentemente descritto dall’obiettivo di corporate alla realizzazione tramite iniziative di business e la messa in opera con le attività di dipartimento richiede attenzione e controllo, che come detto prima va espletato con rigore. L’ Innovazione è possibile ma bisogna pensare ed ancora pensare prima di iniziare a fare e poi accettare di farsi aiutare. Prima, durante e dopo.

Non solo quindi nel far funzionare un nuovo sistema che abbiamo preso a scatola chiusa, ma anche nello sceglierlo costruendo una griglia di valutazione che sia oggettiva ed efficace, disegnandola sui propri processi e verificando se essa possa funzionare per tempo. E poi occorre disegnare il percorso del progetto, senza mai perdere l’attenzione di quel Board of Directors che ci ha chiesto di far succedere una cosa attraverso dei progetti e dei cambiamenti.

Un mio maestro, il professor Claudio Luini, insegnava Progettazione Meccanica al Politecnico di Milano e amava l’innovazione. Ma già nel 99 e parlando dei primi sistemi CAD tridimensionali diceva che la Tecnologia è sempre buona ma “con un cattivo impiego si comporta come una tigre, mentre con un impiego corretto diventa docile e potente come un elefante.” Aveva proprio ragione, anche dopo vent’anni il suo consiglio è valido e reso ancora più attuale dalla potenza e dall’ampiezza funzionale che la tecnologia ha raggiunto. Allacciate le cinture, ma prima preparatevi bene, fatevi aiutare e non perdete di vista l’obiettivo facendo compromessi nella messa in opera del progetto che si è intrapreso.

Il professor Luini e come addomesticare i sistemi di terza generazione (SlideShare)

Twitter @sjoly_ita