← Tutti i case study

Logistica e trasporti

Una piattaforma di gestione trasporti costruita da zero, per sei mestieri diversi

Corriere nazionale. Dalla discovery al rilascio: piattaforma web, app di magazzino, app per i driver, ottimizzazione dei giri con AI predittiva.

  • Il mio ruoloSenior Digital Product Owner — discovery, requisiti, backlog, coordinamento dei team, rilascio
  • DurataCirca due anni e mezzo
  • AmbitiDiscovery · Design della soluzione · AI predittiva · Integrazione magazzino robotizzato · App mobile
Contesto

Un operatore logistico nazionale gestiva gli ordini dei propri clienti e-commerce e la pianificazione dei giri di consegna con strumenti scollegati fra loro. Non esisteva un sistema unico: ogni reparto lavorava sul proprio pezzo, e le informazioni passavano da un reparto all’altro a mano.

Il problema vero

La richiesta iniziale era «ci serve un TMS». Il problema vero, emerso dalle interviste, era un altro: sei mestieri diversi — magazziniere, autista, customer support, finance, logistica, operation — con bisogni, priorità e condizioni di lavoro incompatibili fra loro. Il magazziniere lavora in piedi, con i guanti, con un lettore di barcode in mano. L’autista è in strada, spesso con una mano sola. Il finance ha bisogno di dati puliti a fine mese. Un unico strumento pensato «in media» per tutti sarebbe stato inutilizzabile per ciascuno.

Come ci siamo arrivati
  1. 01

    Esplorare e capire

    Interviste a ogni categoria di utente e ai responsabili di reparto, osservazione sul campo, mappatura dei processi as-is. È qui che è emerso che il progetto non era un sistema, ma sei esperienze diverse su un unico impianto di dati.

  2. 02

    Disegnare

    Architettura funzionale e design della soluzione: una piattaforma web con sezioni e permessi differenziati per ruolo — il magazziniere non vede la fatturazione, il finance non vede la gestione colli — più due applicazioni mobili progettate sulle condizioni reali di lavoro.

  3. 03

    Costruire

    Prototipi validati con gli utenti finali prima dello sviluppo, reparto per reparto. Le correzioni più pesanti sono arrivate in questa fase, quando cambiare costava poco.

  4. 04

    Consegnare

    Backlog e sprint su un arco di circa due anni e mezzo, coordinando i team tecnici e tenendo allineati stakeholder con priorità in conflitto. Rilascio progressivo, reparto per reparto, invece di un unico passaggio in produzione.

Cosa è andato in produzione
  • Piattaforma web per l’orchestrazione di tutti gli ordini provenienti dai clienti e-commerce, con viste e permessi per ruolo.
  • App di magazzino per la gestione dei colli in transito: scansione dei barcode e assegnazione automatica al giro o al viaggio più conveniente.
  • App per i driver dell’ultimo miglio: esitazione delle consegne, raccolta firme, gestione dei PIN.
  • Logiche di AI predittiva per la previsione dinamica dei carichi e l’ottimizzazione dei giri di inoltro e di consegna.
  • Integrazioni con il magazzino robotizzato, con le piattaforme e-commerce dei clienti, con le notifiche di avanzamento spedizione, con la fatturazione attiva e passiva.
Quando si ripropone

Lo schema si ripropone ogni volta che un processo operativo coinvolge mestieri molto diversi fra loro. La tentazione è costruire un sistema unico e uniforme; la cosa che funziona è un impianto di dati unico con esperienze separate. Riconoscerlo in fase di discovery, e non dopo il primo rilascio, è la differenza fra un progetto che arriva in fondo e uno che si arena.

Il cliente non è nominato per riservatezza. Settore e dimensione sono reali, come tutto il resto.

Hai una situazione simile?

Se qualcosa qui somiglia al tuo caso, scrivimi due righe. Se non è terreno mio te lo dico subito.