170 flussi, un AS400 e zero downtime
Ottimizzare i processi aziendali significa risparmiare ore di lavoro a basso valore aggiunto, ma anche ridurre errori, rischi e costi inutili. E’ proprio quello che abbiamo fatto con Caredio, un’azienda logistica italiana che gestisce flussi di dati da decine di clienti e fornitori diversi.
Nata in Piemonte negli anni 60, comprende 4 poli logistici e organizza spedizioni nazionali e internazionali per diversi settori, dal food& beverage all’automotive, con una presenza capillare sul territorio italiano grazie a filiali proprie o di partner.
Per gestire un’infrastruttura così complessa si avvaleva di un gestionale legacy, che troppo spesso richiedeva l’intervento del reparto IT.
L’AS400 funzionava. Il problema era tutto quello che gli si era accumulato intorno negli anni impattando su organizzazione aziendale e gestione dei processi.
Il collo di bottiglia invisibile
Caredio aveva accumulato oltre 170 flussi informativi diversi: tracciati in ingresso da clienti, fornitori, partner logistici, ognuno con il proprio formato, il proprio protocollo, le proprie eccezioni. Per una corretta gestione del flusso di lavoro, il team IT aveva costruito nel tempo una stratificazione di tool, script, connettori e workaround, uno sopra l’altro.
Funzionava? Tecnicamente sì. Ma a un costo che non compariva in nessun budget: il team IT passava le giornate a fare manutenzione. Ogni nuovo cliente con un formato dati diverso diventava un progetto. Ogni integrazione nuova diventava una implementazione custom specifica e richiedeva settimane. E quando qualcosa si rompeva (di notte, nel weekend, durante un picco di attività) la persona che sapeva come ripararlo era sempre la stessa e stava per andare in pensione.
Prenotazioni mancanti o duplicate, errori nei flussi: ogni anomalia pesava fino al 10–15% sul tempo dedicato alle attività operative.
Un paradosso frequente nelle PMI logistiche in crescita: l’azienda acquisiva nuovi clienti, ma ogni nuovo cliente aumentava la complessità IT, e il team che doveva gestirla restava lo stesso. La crescita, invece di essere un’opportunità, diventava un peso infrastrutturale.
L’opzione che tutti suggeriscono (e che non abbiamo seguito)
La risposta standard dei consulenti a un problema così è: sostituite l’AS400. Migrate tutto su un ERP moderno. Fate un progetto da 12-18 mesi.
Caredio non aveva bisogno di sostituire il gestionale. L’AS400 faceva il suo lavoro. Il problema era il layer tra l’AS400 e il mondo esterno.
Inoltre, sostituire un sistema in uso da oltre 30 anni, poteva tradursi in costi di processo molto elevati e difficili da quantificare a priori.
Gli obiettivi da perseguire per l’ottimizzazione dei processi aziendali erano chiari:
- Semplificare l’importazione dei flussi di spedizione dei clienti
Serviva una soluzione per la gestione dei processi aziendali in grado di coordinare, standardizzare e gestire i flussi di import da piccoli o medi clienti, con formati differenti, permettendo di configurare un nuovo cliente senza dover implementare del nuovo codice. Il sistema doveva essere slegato da AS400, per poter cambiare gestionale senza difficoltà.
- Indipendenza del Customer Service
Per ottimizzare i processi aziendali interni e favorire lo scambio automatizzato e sicuro di documenti commerciali (ordini, fatture, bolle) tra diverse sedi o divisioni, bisognava trasformare il servizio EDI (Electronic Data Interchange). Da servizio accessorio, doveva diventare un prodotto a sé stante, parametrizzabile e gestito in autonomia dal Customer Service. In questo modo sarebbe stato possibile intervenire sugli errori di import in maniera autonoma e guidata, scalando sul reparto IT solo per problematiche gravi
- Controllo di gestione: costi, ricavi e statistiche
Bisognava favorire l’importazione di informazioni collaterali (Fatture, bolle, etc.) per la riconciliazione, semplificare la visualizzazione e la gestione di ogni singolo processo, possibilmente includendo analisi di KPI, costi e ricavi su cliente/commesse/etc.
- Evoluzioni future e integrazioni
Non serviva semplicemente un software per la gestione dei processi aziendali “chiavi in mano”, ma qualcosa che potesse evolvere nel futuro, aggiungendo funzionalità o integrandosi con altri strumenti (da ERP, TMS, etc.) e con la Control Tower
Che cosa abbiamo costruito
Un tool API Cloud per la gestione dei processi aziendali che fa una cosa sola, ma la fa bene: gestire qualsiasi tracciato in ingresso, qualunque formato, protocollo e frequenza. Il cuore del sistema è parametrico: configurabile anche da personale non tecnico. Quando arriva un nuovo cliente con un formato dati diverso, non serve uno sviluppatore. Un operatore configura i parametri del nuovo flusso, il sistema lo accoglie e lo normalizza. Quello che prima richiedeva settimane ora richiede ore.
L’integrazione con l’AS400 è bidirezionale e opera in affiancamento. L’AS400 continua a fare quello che fa da anni. Il tool API Cloud gestisce tutto ciò che entra e esce, traducendo, validando, instradando. Operatività garantita h24.
Le fasi del progetto
Il progetto si è articolato in 3 step: prima di tutto è stata implementata e rilasciata l’architettura cloud necessaria all’esecuzione e allo sviluppo del software nel cloud. E’ stato poi realizzato un Proof Of Concept (POC) per verificare che la soluzione architetturale proposta fosse effettivamente quella desiderata prima di passare alla fase di produzione. Infine, si è passati allo sviluppo di un MVP (Minimum Viable Product) per implementare tutta la logica applicativa necessaria a gestire un formato di file che copra il maggior numero delle casistiche (80%).
La tecnologia
Lo stack tecnologico utilizzato si è basato su un’architettura a microservizi.
Per la parte di computing ci si è affidati ad AWS Lambda. Lambda permette di non dover dimensionare a priori il server per i picchi di carico ma di «atomizzare» il processo di gestione del singolo file per ogni singola esecuzione. A livello economico, questa scelta ha il vantaggio di non pagare server quando non sono utilizzati, ma di pagare esclusivamente ad esecuzione della singola funzione (pay per use) e delle risorse applicate.
Con Amazon Aurora, inoltre, ci si è dotati di un database relazionale che fornisce velocità e disponibilità dei database commerciali di fascia alta al costo ridotto di quelli open source, completamente compatibile con MySQL
I microservizi coinvolti avevano specifiche funzioni: recuperare un file da una repository, trasferirlo alla destinazione indicata, controllare che un file fosse formalmente valido, immettere i metadati sul database e normalizzarli, per poi convertirli in un formato desiderato, da importare sui sistemi WMS (Warehouse Management System) e TMS (Transportation Management System) di Caredio.
Un esempio: il microservizio “Importer” convertiva le diverse unità di misura e le convenzioni che i diversi clienti utilizzano, per restituirli in un formato univoco prestabilito: per scrivere 1000 alcuni clienti comunicano 1.000, altri 1,000, altri 1000000 con 3 zeri non significativi per non dover gestire i decimali. Inoltre per alcuni indicano i kg, per altri le tonnellate.
Il tool sviluppato da Eleva aveva appunto l’obiettivo di prendere formati diversi e restituirli in un formato unico.
Il risultato
Il risultato è stato un software e piattaforma server (EDI Hub Module) che raccoglie e traccia tutti i dati scambiati tra azienda, clienti e partner, tiene traccia delle trasmissioni (timing, assegnazioni, anomalie), abilita controllo operativo e finanziario e rende i team informati in tempo reale sulle attività e sui problemi.
Attraverso una Control Tower operativa viene abilitato un controllo centralizzato dei flussi, con alert automatici in caso di anomalie (ordini mancanti, doppi, errati). Il sistema è accessibile anche a personale non IT e gli utenti sono parte attiva nella gestione operativa.
Infine, grazie all’architettura serverless, il sistema si attiva solo all’arrivo di un file e non genera nessun costo quando non viene utilizzato. In tal modo, il cliente paga solo per importazione, con un forte risparmio su costi di infrastruttura e manutenzione.
Come abbiamo lavorato
Durante la product discovery è stato preso in considerazione un flusso standard sul quale sono stati definiti i comandi per andare a gestire gli ordini provenienti dai clienti. Per ciascun cliente, il team di Caredio definiva uno script che conteneva una serie di comandi per interpretare il file in ingresso e gestirne il corretto flusso all’interno delle lambda. Ciascuna lambda si occupava di una funzione del processo ed implementava dei comandi specifici.
Durante il processo di mappatura dei flussi – tutt’ora in essere – sono stati creati man mano nuovi comandi e applicati dei refinements su comandi già esistenti. Questo approccio ha permesso di mappare il 90% dei flussi in modo astratto con i comandi implementati, permettendo di mappare il restante 10% tramite evolutiva.
Il progetto, gestito con metodologia agile, si è sviluppato in 2 fasi da 4 sprint ciascuna.
Il team di Caredio è stato coinvolto attivamente negli sviluppi, fornendo tutte le specifiche dei comandi da implementare all’interno delle funzioni lambda. Dopo l’implementazione, si effettuavano test congiunti per definire l’effettiva correttezza del risultato atteso
E’ stato definito e allocato un team dedicato allo sviluppo del prodotto, che affiancasse l’azienda passo passo nella migrazione, oltre a un team di supporto operativo, capace di garantire nel tempo la manutenzione ordinaria e straordinaria delle architetture dell’azienda.
Pur mantenendo in Caredio la governane, è stato possibile garantire quindi la presenza di un team che desse continuità di servizio nel tempo, slegandosi dalle persone, fornendo tutta la documentazione sui concetti chiave.
Conclusioni
Il team IT di Caredio ha smesso di occuparsi della manutenzione dei flussi informativi. Le risorse interne ora lavorano su progetti a valore, quelli che prima venivano rimandati perché “non c’è tempo.”
I tempi di onboarding per nuovi clienti si sono ridotti significativamente e grazie a una maggiore autonomia nella gestione delle anomalie operative, il reparto IT è stato sgravato da attività a basso valore aggiunto.
La standardizzazione dell’infrastruttura permette una maggiore flessibilità in caso di cambio di gestionale o personale e il passaggio a un modello serverless ha consentito una considerevole riduzione dei costi.
Miglioria stimata 20–25%: prima di realizzare il progetto, circa un quarto del lavoro operativo era assorbito da attività di questo tipo.
Ma la cosa più interessante in prospettiva è un’altra: Caredio ora può scollegare il tool API Cloud dall’AS400 senza conseguenze per il layer di integrazione. Se domani l’azienda decide di migrare a un ERP moderno, il layer resta. Se decide di acquisire un’altra azienda con sistemi diversi, il layer accoglie i nuovi flussi senza ristrutturare nulla.
Cosa abbiamo imparato
Se c’è una cosa che questo progetto ci ha confermato, è che non serve per forza sostituire tutto per risolvere il problema. A volte basta affiancare qualcosa di nuovo a ciò che funziona già e risolvere il punto specifico che blocca la crescita.
Il nostro approccio ai software gestionali parte sempre dall’esistente.
Se il vostro team IT passa più tempo a tenere in piedi i sistemi che a costruire cose nuove, vale la pena parlarne.