ERTMS e il limite della gestione per progetti: quando il deployment diventa un problema di governance
Il deployment ERTMS mostra perché nei programmi complessi il completamento dei singoli progetti non coincide con la disponibilità della capacità finale. La variabile da governare sono le dipendenze tra infrastruttura, sistemi, asset, persone e decisioni.
· 5 min

Indice dell'articolo
Il divario tra avanzamento tecnico e capacità operativa
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.

Una rete non si trasforma progetto per progetto
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.
Dal progress reporting alla dependency governance
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.
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.
Governare le interfacce prima dei ritardi
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.
Una lezione trasferibile ai programmi di trasformazione
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.
Framework applicato
Decision Layer Framework
ERTMS mostra che molte criticità non risiedono nei singoli sistemi, ma nelle decisioni che attraversano organizzazioni, infrastrutture, flotte e processi. Il Decision Layer permette di spostare la governance dalla responsabilità verticale dei progetti alle decisioni trasversali necessarie per rendere operativa una capability.
- 01System Layer
- 02Data Layer
- 03Governance Layer
- 04Decision Layer
Implicazioni manageriali
Fonti
Analisi correlate

Cyber Resilience Act: procurement oltre il collaudo
Patchability, supporto e gestione delle vulnerabilità diventano requisiti di continuità lungo l'intero ciclo di vita del prodotto digitale — non condizioni verificate una sola volta al momento dell'accettazione.
· 4 min

Quando l'AI agisce, non basta etichettare l'output
L'AI Act rende verificabile la provenienza di un contenuto generato. Ma quando un sistema AI non genera soltanto testo, immagini o audio, bensì agisce attraverso strumenti, dati e applicazioni, la domanda cambia: chi ha autorizzato quell'azione, e come si dimostra.
· 6 min

Le decisioni attraversano l'organizzazione. I sistemi no.
Il Decision Layer Framework distingue System, Data, Governance e Decision Layer: la trasformazione digitale produce valore quando cambia la qualità della decisione finale, non quando aumenta soltanto il numero di sistemi collegati.
· 4 min