ERTMS e il limite della gestione per progetti: quando il deployment diventa un problema di governance

Il Terzo Work Plan ERTMS pubblicato nel febbraio 2026 fotografa un programma europeo che continua ad avanzare, ma con una velocità e una distribuzione ancora insufficienti rispetto alle scadenze della rete TEN-T. A fine 2024 l’European Train Control System era operativo su circa 12.400 chilometri, pari al 10% della rete TEN-T, mentre risultavano equipaggiati circa 8.730 veicoli, il 19% della flotta ferroviaria dell’Unione.

Il Regolamento TEN-T stabilisce una traiettoria precisa: completamento della core network entro il 2030, della extended core entro il 2040 e della comprehensive network entro il 2050. Prevede inoltre la progressiva dismissione dei sistemi nazionali di classe B e l’evoluzione verso ERTMS radio-based.

Il problema, quindi, non è l’assenza di una tecnologia comune né di milestone regolatorie. È la capacità di sincronizzare un insieme di trasformazioni che procedono con tempi, responsabilità e vincoli differenti.

ERTMS rende particolarmente visibile una caratteristica dei programmi complessi: il completamento delle singole componenti non coincide necessariamente con la disponibilità della capacità finale.

Il deployment trackside deve essere coordinato con l’equipaggiamento onboard. Entrambi devono essere compatibili con le versioni tecnologiche previste, con i processi autorizzativi e con le condizioni operative. A questi elementi si aggiungono formazione del personale, migrazione dai sistemi legacy, disponibilità finanziaria e coordinamento tra gestori dell’infrastruttura, imprese ferroviarie, autorità nazionali, fornitori e istituzioni europee.

La stessa Commissione osserva che una strategia efficace richiede deployment sincronizzato tra infrastruttura e veicoli: i benefici del sistema diventano pienamente disponibili solo quando entrambe le componenti sono pronte.

Questo cambia il significato del monitoraggio. Sapere che due progetti sono entrambi completati all’80% dice poco se il restante 20% di uno impedisce l’entrata in esercizio dell’altro.

Il Terzo Work Plan indica esplicitamente la necessità di superare un approccio project-by-project e costruire piani coordinati a livello di rete, accompagnati da governance più forte e finanziamenti sufficientemente stabili.

È un passaggio rilevante per il program management.

In un programma tradizionale il PMO raccoglie milestone, budget, rischi e avanzamenti dei singoli workstream. In una trasformazione interdipendente deve aggiungere un secondo livello: capire quali capacità dipendono da quali componenti e in quale sequenza devono diventare disponibili.

Come esempio ipotetico, una tratta ETCS pronta sei mesi prima della flotta compatibile può risultare tecnicamente completata, mentre la capacità operativa rimane invariata. Lo stesso accade quando una piattaforma dati viene rilasciata prima delle integrazioni che devono alimentarla, oppure quando un nuovo processo viene approvato prima che ruoli e sistemi siano pronti a sostenerlo.

La metrica utile diventa quindi la readiness della capacità, non soltanto la percentuale di completamento del progetto.

Questo approccio richiede che le dipendenze siano trattate come oggetti di governance. Per ciascuna capacità critica occorre conoscere almeno il componente che la abilita, l’owner, la milestone necessaria, le dipendenze upstream e downstream e la decisione richiesta quando una di esse devia.

Il vantaggio non è produrre un reporting più sofisticato. È anticipare il momento in cui un ritardo locale diventa un ritardo sistemico.

ERTMS offre anche un secondo insegnamento: più aumenta il numero degli attori, meno è sufficiente una governance basata esclusivamente sulle gerarchie organizzative. Il deployment attraversa organizzazioni, Stati, infrastrutture e flotte diverse. Le responsabilità devono quindi essere costruite intorno alle interfacce del programma, non soltanto agli organigrammi.

Finché il nuovo sistema affianca quello nazionale senza sostituirlo, convivono due baseline tecnologiche, apparati di bordo e di terra diversi, procedure distinte e competenze da mantenere su entrambi. Ne ricavo una lettura, che è dell'autore e non del Work Plan: il doppio regime aumenta il carico di test, formazione e manutenzione, e senza una data credibile di dismissione il sistema legacy tende a diventare permanente per assenza di una scadenza, non per scelta.

Per questo l'avanzamento va misurato anche sull'uscita: corridoi operabili end-to-end, quota di flotta compatibile, sistemi legacy effettivamente dismessi, autorizzazioni completate, personale formato. I chilometri attrezzati descrivono lo sforzo compiuto, non il valore generato. Come proposta di metodo, configurazioni standard, lotti di retrofit organizzati per corridoio e flotta realmente utilizzabile e autorizzazioni pianificate in anticipo riducono la variabilità che ogni progetto isolato reintroduce.

A mio giudizio il meccanismo riguarda molte trasformazioni digitali e infrastrutturali. Una migrazione cloud dipende da applicazioni, reti, sicurezza, contratti e competenze. Un sistema account-based ticketing richiede coordinamento tra validazione, back office, payment service provider, clearing e regole tariffarie. Un programma ERP modifica contemporaneamente processi, dati, ruoli e controlli.

In tutti questi casi il rischio cresce quando ogni stream ottimizza il proprio piano ma nessuno governa la sequenza attraverso cui il sistema complessivo produce valore.

ERTMS mostra quindi un problema manageriale più generale. Nei programmi ad alta interdipendenza, il successo non deriva dalla somma dei deliverable completati. Dipende dalla capacità di trasformare componenti tecniche e organizzative in una capability operativa sincronizzata.

Per il program management significa spostare l’attenzione dal controllo dei progetti alla governance delle dipendenze che determinano quando il beneficio diventa realmente utilizzabile.