Piattaforma SAP BTP per riparazione veicoli e gestione sinistri
Piattaforma SAP BTP che unisce riparazione di veicoli grandinati, pratiche assicurative e fatturazione: backend SAP CAP su HANA Cloud, 22 app SAPUI5 su OData V4 in un unico launchpad, integrazione con ERP SAP e con il preventivatore WinCar.
Descrizione
La piattaforma cloud di un operatore italiano specializzato nella riparazione di danni da grandine su flotte di veicoli con tecnica PDR (riparazione senza verniciatura) e nella gestione delle relative pratiche assicurative. Copre il ciclo completo: apertura dell'operativa di riparazione, censimento dei veicoli per VIN, assegnazione delle operazioni ai tecnici con tempi e prezzi, magazzini e trasporti, pratica di sinistro con documenti e preventivi, fino alla fatturazione verso l'ERP SAP. È composta da un backend SAP Cloud Application Programming Model (CAP) in Node.js su SAP HANA Cloud e da 22 applicazioni SAPUI5 riunite in un unico launchpad. Ho realizzato il primo mock di fattibilità per il cliente e, all'avvio del progetto, ne sono diventato team lead: ho guidato tre sviluppatori per l'intera durata — circa un anno e due mesi — assegnando le attività, coordinandomi con il delivery manager e conducendo di persona le call con il cliente per raccogliere le specifiche.
Il problema
L'azienda lavorava con un'applicazione precedente esterna al mondo SAP: i dati raccolti sul campo restavano lì e non arrivavano all'ERP del gruppo. Intorno allo stesso veicolo operano persone diverse — i tecnici che riparano in cantiere, i responsabili che controllano l'avanzamento, il back office che fattura — e ognuno vedeva solo la propria parte. Le informazioni sui veicoli circolavano in file Excel, le pratiche di sinistro vivevano fuori dai sistemi aziendali e chi fatturava doveva ricostruire a mano cosa era stato fatto, su quale veicolo e da chi. Mancava un percorso tracciabile tra il lavoro svolto sul campo e il documento contabile emesso in SAP.
Vincoli
La piattaforma doveva inserirsi tra sistemi già in produzione: l'ERP SAP del gruppo, il preventivatore di carrozzeria WinCar e un flusso di integrazione già esistente, tutti raggiungibili solo tramite destination e connectivity di SAP BTP. Le specifiche funzionali sono cambiate a piattaforma già costruita e già popolata dai dati delle prove sul campo: nel codice restano entità e campi dichiarati non più utilizzati dopo i cambi di requisito. Il rilascio doveva restare gestibile su tre landscape (sviluppo, test, produzione) con lo stesso codice. Il lavoro era distribuito su quattro sviluppatori sullo stesso monorepo: senza convenzioni condivise su modello dati, servizi e naming, 22 applicazioni sarebbero diventate 22 dialetti diversi.
Architettura
Monorepo Multi-Target Application (MTA) su SAP BTP, Cloud Foundry runtime.
- Backend: SAP Cloud Application Programming Model (CAP) per Node.js (
@sap/cds9): un catalogo OData V4 con oltre 80 entità esposte, più sei servizi applicativi con logica custom in JavaScript (operazioni, fatture, report, anagrafiche, preventivi esterni). - Dati: SAP HANA Cloud in container HDI, ~90 entità CDS, viste
.hdbviewscritte a mano per le aggregazioni, sinonimi e ruoli HDI per il consumo da SAP Datasphere. - Frontend: 22 applicazioni SAPUI5 freestyle (~39.000 righe di controller, 103 viste XML, 74 fragment) su html5-apps-repo, riunite in un launchpad con navigazione incrociata. L'applicazione dei tecnici gira su SAP Build Work Zone, pensata per l'uso in cantiere: si sceglie l'operativa, si digita il VIN, si lavora.
SAPUI5 (22 app, launchpad) app tecnici (SAP Build Work Zone)
\ /
managed approuter (XSUAA)
|
CAP OData V4 (Node.js)
|
+---------------+----------------+
v v
SAP HANA Cloud (HDI) destination BTP
~90 entità CDS |
viste .hdbview +-----------+-----------+
| v v v
v ERP SAP WinCar iFlow / SMTP
SAP Datasphere (fatture) (preventivi) Google Drive API
(reportistica)
Il modello delle operazioni è il cuore del sistema. Un'operativa nasce con i suoi responsabili e l'elenco degli utenti abilitati: solo loro vedono quei dati. I veicoli entrano da un caricamento XLS o CSV di VIN; le lavorazioni entrano da un catalogo che il cliente si configura da solo. Da lì valgono tre regole:
- sequenza vincolata: un'operazione si apre solo se quella che la precede è chiusa, e il tecnico che ci prova riceve l'avviso invece di un errore generico;
- permessi per operazione: ogni utente vede le lavorazioni che è abilitato a fare, quindi il sistema propone la prima operazione disponibile per lui su quel veicolo, non la prima disponibile in assoluto;
- assegnazione casuale in fase PDR: il veicolo viene estratto fra quelli pronti per quell'operazione, non scelto.
Ogni passaggio lascia traccia: quale operazione, su quale VIN, da chi, quando, con quale esito. È da lì che nascono lo storico per veicolo, la gestione dei veicoli bloccati e gli aggregati di reportistica.
Risultato
Cosa è stato consegnato#
Le due metà del programma sono state costruite entrambe: la riparazione PDR — operative, veicoli, lavorazioni, cantiere — e la gestione delle pratiche assicurative, con i preventivi recuperati da WinCar e storicizzati accanto al veicolo. Tecnici, responsabili e back office lavorano sullo stesso modello dati e sullo stesso launchpad, dentro il perimetro SAP invece che sull'applicazione esterna di prima. Ogni riga di lavoro tecnico porta con sé il codice fattura, il numero d'ordine SAP, il payload inviato e l'eventuale errore restituito: un problema di fatturazione si ricostruisce dal dato, non dalle email. Le viste HANA esposte a SAP Datasphere hanno aperto la reportistica oltre il perimetro dell'applicazione.
La prova sul campo#
La piattaforma è stata provata due volte con operatori veri, non in laboratorio. La prima volta su un'operativa di riparazione seguita per due o tre settimane. La seconda in cantiere: gli operatori hanno usato l'applicazione per circa una settimana e per tre di quei giorni siamo stati fisicamente sul posto a guardarli lavorare e a raccogliere i feedback direttamente da loro, senza il filtro di un verbale. Per un'applicazione che si usa con i guanti addosso, accanto a una macchina da riparare, è il solo modo serio di capire se funziona.
Una regola che arriva dal cantiere, non dal requisito tecnico#
In fase PDR il veicolo non si sceglie: il sistema lo estrae fra quelli pronti per quell'operazione. Non è un dettaglio implementativo. A parità di tariffa conviene lavorare i veicoli meno danneggiati, e lasciare la scelta agli operatori creava tensioni; il cliente ha chiesto esplicitamente che nessuno potesse selezionare il proprio lavoro. La stessa idea di imparzialità regge la sequenza vincolata delle operazioni e i permessi per utente: il sistema decide cosa si può fare adesso, e lo motiva.
Il mio ruolo#
Il primo mock, quello che è servito al cliente per capire cosa si poteva fare, l'ho costruito io. All'avvio del progetto sono diventato team lead e l'ho seguito fino alla fine, circa un anno e due mesi: tre sviluppatori da coordinare, le attività da assegnare, le convenzioni tecniche da tenere insieme su un monorepo che è arrivato a 22 applicazioni, e le call con il cliente condotte di persona per raccogliere e negoziare le specifiche.
Come è finita#
Il cliente ha sospeso il programma per priorità interne, prima dell'apertura alla popolazione completa: la piattaforma era dimensionata per un migliaio di utenti fra operatori e responsabili, con operative che arrivano a qualche migliaio di veicoli ciascuna. Alla sospensione il descrittore MTA era alla versione 2.0.58, cioè un rilascio incrementale ogni pochi giorni per oltre un anno.