Gestire venti linee scolastiche e gestirne quattrocento non sono lo stesso problema su scale diverse. Sono due problemi differenti. Con venti linee una persona conosce ogni conducente, ogni istituto e ogni punto critico, e il telefono risolve quello che il sistema non vede. Oltre alcune decine di linee quel modello si rompe, e lo fa in silenzio: nessuno smette di lavorare, semplicemente si smette di sapere.
Questo articolo è una griglia di criteri per scegliere un software quando la volumetria è il vincolo principale, cioè per un'AOM, una città metropolitana o un grande operatore con una rete scolastica estesa su più istituti e più comuni.
Cosa cambia con la volumetria
Quattro cose si rompono quando il numero di linee cresce, e ognuna corrisponde a un criterio di scelta.
La supervisione diventa reattiva. Con poche linee qualcuno nota l'anomalia. Con centinaia, il primo segnale è la telefonata di un istituto che chiede dov'è il pulmino. A quel punto sono passati venti minuti.
L'informazione si frammenta per territorio. Ogni comune, ogni subaffidatario e a volte ogni istituto mantiene il proprio canale. Nessuno ha la vista d'insieme, e riconciliare le versioni consuma più tempo dell'esercizio.
Il subappalto diluisce la responsabilità. Le grandi reti scolastiche si operano quasi sempre con più subaffidatari. Se ognuno rendiconta a modo suo, il titolare del servizio non può dimostrare la conformità sull'insieme.
La rendicontazione diventa un progetto. Quando bisogna dimostrare che il servizio è stato svolto, con quale puntualità e con quali imprevisti, la risposta si costruisce a mano da fonti diverse. Ogni ciclo di rendicontazione è un lavoro nuovo.
Criterio 1: allerta, non sorveglianza
L'errore di impostazione più comune è cercare di aumentare la capacità di osservazione. Più schermi, più personale, più mappe. Non funziona, perché nessuno supervisiona quattrocento veicoli guardando.
Il modello che regge inverte la logica: il sistema conosce il programma di ogni linea e avvisa quando la realtà se ne discosta. La persona non sorveglia, gestisce eccezioni.
Cosa chiedere in fase di valutazione: quali avvisi sono configurabili, con quali soglie, e per linea o solo globalmente. In ambito scolastico gli avvisi che contano sono pochi:
- Corsa non partita all'orario previsto, l'unico che lascia margine di reazione
- Ritardo al punto di raccolta, con soglia distinta se ci sono minori in attesa
- Fermata non effettuata, la più grave e impossibile da rilevare senza associazione al programma
- Uscita dal percorso previsto, che in ambito scolastico è quasi sempre un imprevisto e non un'ottimizzazione
Un sistema che genera decine di avvisi al giorno viene silenziato entro due settimane. Poche soglie affidabili valgono più di molte soglie rumorose.
Criterio 2: il calendario scolastico come programma di esercizio
Questo è il criterio che scarta più fornitori, ed è quello che si verifica meno spesso in fase di gara.
Il trasporto scolastico non segue un orario settimanale stabile. Segue un calendario con giorni di sospensione, uscite anticipate, rientri pomeridiani, periodi di esami e variazioni per singolo istituto. Un software che modella solo un orario settimanale ricorrente produrrà avvisi falsi ogni giorno non scolastico, e gli avvisi falsi distruggono la fiducia nel sistema.
Da chiedere in modo esplicito: come si modella una sospensione su un singolo istituto, come si gestisce un'uscita anticipata che modifica solo alcune linee, e quanto lavoro richiede un cambio di orario a metà anno.
Criterio 3: modellazione multi-entità
Una linea affidata a un subaffidatario deve essere visibile nell'insieme e allo stesso tempo imputata a quel subaffidatario, per responsabilità e per rendicontazione. Un sistema che modella un solo operatore obbliga a mantenere due verità e a riconciliarle a mano.
Collegato a questo, i profili di accesso. Un istituto vede le proprie linee. Un subaffidatario vede le proprie. Il titolare vede tutto. Senza questa segmentazione il sistema o si apre a tutti o si chiude a tutti, e in entrambi i casi la gestione torna via email.
Criterio 4: comportamento in assenza di copertura
Le linee scolastiche attraversano aree periurbane e rurali con copertura discontinua. Il sistema deve memorizzare le posizioni a bordo e riconciliarle al ripristino della connessione.
Il motivo è diretto: un sistema che tratta un buco di copertura come assenza di servizio segnalerà imprevisti che non sono accaduti, e ogni segnalazione falsa va poi smentita davanti a un istituto o a un genitore. È una domanda tecnica da porre in gara, non un dettaglio implementativo.
Criterio 5: comunicazione con un solo inserimento
Su larga scala i destinatari sono tre e hanno bisogno di informazioni diverse. L'istituto deve sapere se il pulmino dei suoi alunni è in ritardo e di quanto. Il subaffidatario deve avere l'imprevisto sul proprio perimetro. Il titolare deve avere l'aggregato.
La prova pratica è quante volte si digita un avviso perché arrivi a tutti e tre. Se la risposta è più di una, nei giorni difficili l'avviso non verrà inviato, ed è esattamente il giorno in cui serve.
Criterio 6: rendicontazione riproducibile
La domanda da porre non è se il software produce report. Tutti li producono. La domanda è se un periodo passato qualsiasi può essere rigenerato in automatico, senza intervento manuale, e in un formato che il titolare del servizio accetta.
Collegata a questa, la consultazione puntuale. Di fronte a un reclamo la domanda è cosa è successo martedì sulla linea 87. Se rispondere richiede mezza giornata, il sistema non serve per l'uso che conta di più.
Criterio 7: recuperabilità dei dati
Un anno di dati di esercizio scolastico è il patrimonio più utile che si accumula, perché permette di ridisegnare le linee invece di gestire ogni giorno le stesse deviazioni: margini sistematicamente insufficienti, punti di raccolta che generano ritardo ricorrente, sovrapposizioni tra linee di comuni diversi che potrebbero essere accorpate, veicoli con occupazione strutturalmente bassa.
Chiedere un'esportazione di esempio prima di firmare, non una clausola che ne promette una.
Domande frequenti
Serve una sala operativa dedicata per gestire centinaia di linee?
No, se il sistema lavora per eccezioni. L'obiettivo realistico è una o due persone che gestiscono le eccezioni su tutto il territorio, non un presidio per zona.
Si possono supervisionare i subaffidatari senza installare apparati sui loro veicoli?
Un'applicazione su dispositivo omologato permette di partire rapidamente su flotte subaffidate e miste. Quello che non funziona è accettare la dichiarazione manuale del subaffidatario come fonte di verità.
Come si evita di saturare le famiglie di notifiche?
Avvisando per linea interessata e non per rete, e solo oltre una soglia con conseguenza reale. Un sistema che avvisa di tutto si silenzia da solo.
Qual è il lavoro preliminare da prevedere?
Il programma di ogni linea in formato utilizzabile: fermate con coordinate, orari, percorso e calendario per istituto. È la parte più sottovalutata e quella da cui dipende tutto il resto.
Come impostare il confronto
Costruire una sola griglia, mettere tutti i fornitori sulle stesse righe, e pretendere una dimostrazione sui propri dati con due scenari: un giorno di sospensione parziale su alcuni istituti, e un imprevisto su una linea subaffidata. Quasi tutte le differenze rilevanti tra software di trasporto scolastico emergono in quei due scenari, e quasi nessuna emerge in una presentazione.
Se gestisci una rete scolastica estesa e vuoi vedere come si comporta la supervisione centralizzata su centinaia di linee multi-operatore, il team di Pysae può ripercorrerlo sulla struttura della tua rete.