RouteOpt

Un’impresa di pulizie di Madrid pianificava a mano, in Excel, circa mille servizi a settimana: condomini, uffici, garage. Ogni servizio ha la sua fascia oraria e la sua durata, e ogni operatore ne concatena diversi al giorno spostandosi per Madrid con i mezzi pubblici.

Fatto a mano, il risultato sono tragitti incrociati, attese tra un servizio e l’altro e una domanda senza una risposta chiara: quante persone ci servono davvero?

In termini tecnici è un problema di instradamento con finestre temporali (VRPTW): distribuire fermate tra «veicoli» rispettando orari e turni. Il caso da manuale qui ha una particolarità: il veicolo è una persona e la mappa è la rete dei trasporti di Madrid.

1. Una mappa dei tempi multimodale. Ho caricato i dati aperti (GTFS) di Metro, Metro leggera e autobus EMT e ho calcolato, per ogni coppia di servizi, il modo migliore per arrivarci: a piedi (con OSRM sulle strade reali e un ripiego a 4,2 km/h, perché si cammina con l’attrezzatura), in metro (fino a 1,8 km a piedi fino alla stazione) o in autobus (al massimo un cambio, con 4 minuti di penalità). Oltre i 2,2 km andare a piedi è vietato, per forzare il trasporto pubblico.
2. Fase A: i percorsi di ogni giorno. Ogni giorno si risolve come un VRPTW con Google OR-Tools: una soluzione iniziale per arco più economico e poi ricerca locale guidata per 20 secondi. Ogni servizio ha una finestra temporale con un margine di flessibilità, ogni turno un massimo di minuti e ogni tragitto un tempo massimo.
3. Nessun servizio resta fuori. Lasciare una fermata senza assegnazione costa 1 miliardo nella funzione obiettivo. È un modo di scrivere in matematica una regola di business: ogni condominio è un contratto firmato e, piuttosto che lasciarlo senza servizio, il sistema preferisce chiedere una persona in più.
4. Fase B: dai percorsi ai contratti. I percorsi giornalieri vengono impacchettati in contratti settimanali reali (da 20 a 35 ore) con un algoritmo first-fit decreasing: nessuno fa due percorsi nello stesso giorno e gli straordinari hanno un tetto e un costo extra. Funziona in due modalità: progettare l’organico ottimale da zero o far entrare il lavoro nell’organico attuale e segnalare ciò che non ci sta.

Esecuzione di riferimento (17 marzo 2026) confrontata con la pianificazione reale dell’azienda, con gli stessi servizi (oltre 950) e le stesse ore di lavoro effettivo:

Le ore di lavoro non cambiano (1.594,6 h): quello che sparisce è il tempo perso tra un servizio e l’altro. Nell’esecuzione, 535 tratte si fanno a piedi e 125 in metro.

Oggi è in produzione e in uso all’interno dell’azienda, come strumento privato.

• Pannello web in Next.js con mappe (Leaflet e OpenStreetMap): inserimento di operatori e indirizzi, confronto tra il piano attuale e quello ottimizzato e visualizzatore dei percorsi.
• Multiazienda: ogni azienda vede solo i propri dati e le password sono salvate cifrate con scrypt. Il motore è un’API interna in Flask con cui parla solo il pannello.
• Ingegneria: test di contratto tra pannello e motore, matrice dei rischi con priorità, manuale operativo con rollback e messa in produzione su AWS con Nginx e systemd.

Un algoritmo da manuale non basta: il valore sta nel tradurre le regole del business («nessun condominio senza servizio», «nessuno fa due percorsi nello stesso giorno») nel linguaggio del solver, e nel misurare il risultato contro la pianificazione reale.