Ogni fase del ciclo di vita di un veicolo si basa su un software diverso. I team di sviluppo utilizzano piattaforme di simulazione. I team di collaudo si avvalgono di registratori di dati e suite di validazione. I team di produzione eseguono i test di fine linea sui propri sistemi dedicati. I team di assistenza post-vendita utilizzano un ulteriore set di strumenti diagnostici. Ogni team sceglie ciò che funziona meglio per il proprio specifico ambito di competenza.
Il problema è ciò che accade tra una fase e l’altra e trasversalmente alle fasi, non al loro interno. Pensate al ciclo di vita tradizionale di un veicolo come a una staffetta. Lo sviluppo passa il testimone al collaudo. Il collaudo passa il testimone alla produzione. La produzione passa il testimone all’assistenza. Ad ogni passaggio, le conoscenze devono essere riorganizzate o ricostruite. Spesso la situazione è anche peggiore: gli strumenti di ciascuna fase non condividono tra loro alcuna conoscenza o apprendimento. Ciò genera tre costi che aumentano ad ogni trasferimento:
- I costi di gestione del sistema aumentano esponenzialmente, poiché ogni strumento aggiuntivo nella catena rappresenta un ulteriore sistema per cui è necessario ottenere la licenza, integrare, applicare le patch e fornire assistenza.
- I costi di formazione aumentano poiché i nuovi assunti e i team interfunzionali devono imparare a utilizzare uno strumento diverso per ogni fase del processo di cui si occupano.
- Ma soprattutto, si interrompe la continuità delle conoscenze. Il contesto di cui disponeva un ingegnere durante lo sviluppo di una funzionalità non viene trasmesso in modo chiaro a chi, sei mesi dopo, deve risolvere i problemi sul campo.
Nulla di tutto ciò è da attribuire a un singolo team. Si tratta di un costo strutturale derivante dal considerare la progettazione, lo sviluppo, il collaudo, la produzione e l’assistenza come cinque flussi di lavoro distinti anziché come un unico processo continuo. Per gli OEM, tale costo si traduce in tempi aggiuntivi in ogni fase: sviluppo più lento, collaudo più lento, analisi dei guasti più lenta, oltre a una duplicazione degli sforzi e alla perdita di conoscenze istituzionali nel passaggio da un team all’altro.
Cosa rendeva irrealistica l'unificazione in passato
Per gran parte della storia del software, unificare questi strumenti non era realistico. Il software è progettato per scopi specifici. Uno strumento di test è concepito per verificare che un sistema si comporti come previsto in un insieme definito di condizioni, mentre uno strumento diagnostico serve a individuare la causa principale di un guasto una volta che qualcosa è andato storto. Adattare uno strumento per svolgere il compito dell’altro significa riscrivere parti sostanziali del codice. Se un ingegnere vuole spostare un pulsante o modificare un flusso di lavoro, ciò comporta un ciclo di sviluppo.
AI sta iniziando a cambiare questa equazione perché le soluzioni di " AI " basate sull'agente, in tutte queste fasi, condividono sempre più spesso le stesse basi. Il modello linguistico di grandi dimensioni (LLM) alla base di uno strumento di test è, fondamentalmente, lo stesso modello alla base di uno strumento di diagnostica sul campo. Che si tratti di analizzare un caso di test di convalida prima del lancio o di risolvere un problema di un cliente dopo la vendita, l'AI e che effettua il ragionamento è lo stesso. Cambia solo il contesto circostante.
Anziché creare un sistema separato per ogni dominio, le organizzazioni possono estendere la stessa intelligenza di base alle fasi di sviluppo, test e produzione, adattandola al contesto di ciascun team senza dover ripartire da zero ogni volta. Questa è l’idea alla base del Sonatus Fastlane™ Platform, una piattaforma di " AI " a ciclo chiuso che trasferisce i dati e le conoscenze relative ai veicoli da una fase all’altra del ciclo di vita. Si tratta di un punto di partenza significativamente diverso rispetto a quello che il settore ha avuto in passato, anche se la maggior parte delle organizzazioni è ancora alle prime fasi di attuazione.
Il lavoro più difficile è quello organizzativo
I primi segnali in tal senso sono visibili in tutto il settore, anche laddove le organizzazioni attualmente mettano in pratica solo una o due di queste iniziative:
- Inserire in modo più diretto i guasti sul campo nei cicli di aggiornamento over-the-air, grazie a soluzioni di " AI " integrate nel veicolo, quali Sonatus Fastlane™ Edge contribuiscono a chiudere il ciclo dal problema alla soluzione implementata.
- Reintegrare le conoscenze acquisite dal service desk nei criteri di progettazione e collaudo per il prossimo anno modello: è proprio in questo ambito che uno strumento come Fastlane™ Insight può trasformare i risultati diagnostici in informazioni utili per i team di ingegneri
- Utilizzo dei dati relativi alle anomalie rilevate in produzione per confrontare la qualità dei componenti tra i diversi fornitori.
- Valutare se i dati di validazione provenienti dalla fase di sviluppo possano essere trasferiti sul veicolo per accelerare le diagnosi di assistenza sin dal primo giorno, con il supporto delle informazioni sul contesto del veicolo fornite d AI Sonatus Fastlane™ Collector.
Nessuna di queste questioni è stata ancora risolta completamente da nessuna parte, ma ciò indica la direzione che il settore sta prendendo una volta che gli strumenti smetteranno di azzerarsi ad ogni passaggio di consegne.
Non si tratta nemmeno semplicemente di sostituire un software. L’unificazione degli strumenti nelle diverse fasi del ciclo di vita comporta solitamente l’unificazione della responsabilità, del budget e dei processi tra team che hanno operato in modo indipendente per anni. Ciò crea una sfida legata alla gestione del cambiamento tanto quanto una sfida tecnica. Le organizzazioni che considerano questa scelta semplicemente come una decisione relativa agli strumenti rischiano di scoprire che il lavoro più difficile è di natura organizzativa.
Elaborazione della strategia di unificazione
In base alla mia esperienza, questo tipo di trasformazione organizzativa tende a seguire alcuni principi fondamentali:
- Adottare l’unificazione come strategia a livello aziendale. L’unificazione dei dati, delle conoscenze e dell’ AI e deve essere un mandato della dirigenza, non un progetto affidato a un singolo team.
- Indicare dei referenti per ciascuna fase del processo. L’iniziativa deve poter contare su sostenitori presenti in tutte le fasi di sviluppo, collaudo, produzione e assistenza.
- Individua ciò che rientra nel contesto condiviso. Non tutti i dati, le conoscenze o gli artefatti devono passare da una fase all’altra, ma i segnali giusti sì.
- Implementate innanzitutto soluzioni " AI " per uno o due casi d'uso, che sfruttino in modo specifico il flusso bidirezionale di conoscenze durante l'intero ciclo di vita, anziché procedere a un'implementazione completa in un'unica soluzione.
- Considerate le prime implementazioni come un punto di partenza. Imparate da esse, miglioratele e ampliatele.
Perché non si può rimandare
La pressione per affrontare la questione di questi strumenti sta aumentando. Man mano che i veicoli diventano sempre più “definiti dal software” e il ritmo delle iterazioni accelera, il costo degli strumenti isolati cresce. Ogni strumento aggiuntivo specifico per una fase rappresenta un altro punto in cui il know-how aziendale rimane intrappolato, un altro punto di integrazione da gestire e un altro ritardo tra il momento in cui viene individuato un problema e quello in cui viene implementata una soluzione.
Ciò che colma questo divario è l’utilizzo degli stessi strumenti — o almeno della stessa intelligenza di base — in ogni fase del processo. Le aziende che riescono a considerare la progettazione, lo sviluppo, il collaudo, la produzione e l’assistenza come un unico sistema continuo, anziché come cinque funzioni separate, possono ottenere vantaggi competitivi strutturali:
- Individuare i problemi in anticipo, poiché le informazioni raccolte in una fase vengono trasmesse più rapidamente a quella successiva.
- Riduzione del numero di veicoli di prova fisici e delle attività di convalida duplicate, grazie al trasferimento dei dati e del contesto.
- Ridurre la distanza tra un segnale reale e una soluzione implementata.
Le giustificazioni tecniche per mantenere una struttura a compartimenti stagni sono ormai in gran parte superate. Ciò che rimane è una scelta di leadership: continuare a ottimizzare ogni fase del ciclo di vita del veicolo oppure iniziare a considerare il ciclo di vita come un unico sistema interconnesso che opera su una catena di strumenti unificata. In un settore in cui i tempi di avvio della produzione (time-to-SOP) e la rapidità nella risoluzione dei problemi stanno diventando i veri fattori di differenziazione competitiva, tale scelta non rimarrà a lungo facoltativa. Le organizzazioni che la adotteranno per prime detteranno il ritmo che tutti gli altri saranno costretti a seguire.
Sei pronto a scoprire come si presenta nella pratica un ciclo di vita connesso? Esplora il Sonatus Fastlane Platform per scoprire come gli OEM e i fornitori stanno utilizzando l’ AI a ciclo chiuso per accelerare i tempi, dallo sviluppo alla produzione e all’assistenza.