Francesco ConsiglioExecutive Strategy Lab
AnalisiGovernance

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.

Francesco Consiglio

· 5 min

Un semaforo ferroviario con luce gialla accesa lungo un binario elettrificato al tramonto, a rappresentare un segnale di stato nel deployment ERTMS.
Indice dell'articolo
  1. 01Il divario tra avanzamento tecnico e capacità operativa
  2. 02Una rete non si trasforma progetto per progetto
  3. 03Dal progress reporting alla dependency governance
  4. 04Governare le interfacce prima dei ritardi
  5. 05Una lezione trasferibile ai programmi di trasformazione
  6. 06Implicazioni manageriali
  7. 07Fonti

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.

Stato del deployment ERTMS a fine 2024 e principali milestone della rete TEN-T al 2030, 2040 e 2050.
A fine 2024 ETCS risultava operativo su circa 12.400 km, pari al 10% della rete TEN-T, mentre 8.730 veicoli, il 19% della flotta ferroviaria UE, risultavano equipaggiati. Le scadenze TEN-T rendono il coordinamento del deployment una variabile critica del programma.Executive Strategy Lab — elaborazione su dati European Commission e European Union Agency for Railways

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.

Schema delle dipendenze tra infrastruttura, flotta, sistemi legacy, persone e autorizzazioni che determinano la readiness operativa di un programma complesso.
La capacità operativa emerge quando le dipendenze critiche raggiungono una readiness coerente: completare i singoli progetti non è sufficiente se infrastruttura, sistemi, persone e autorizzazioni non sono sincronizzati.Executive Strategy Lab — elaborazione propria

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.

Un plastico dettagliato di infrastruttura ferroviaria — galleria, viadotto, segnali — suddiviso in segmenti di colore diverso, a rappresentare il deployment coordinato su più tratte della rete.
Executive Strategy Lab — visual originale

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.

  1. 01System Layer
  2. 02Data Layer
  3. 03Governance Layer
  4. 04Decision Layer
Esplora Decision Layer Framework

Implicazioni manageriali


Fonti

  • European Commission — DG MOVE23 febbraio 2026

    Third Work Plan on the status of ERTMS deployment

  • European Union Agency for Railways23 febbraio 2026

    Third ERTMS Work Plan — deployment status and acceleration priorities

  • Parlamento europeo e Consiglio dell’Unione europea13 giugno 2024

    Regolamento (UE) 2024/1679 — TEN-T

Analisi correlate

Tre scene in sequenza — componenti hardware appena imballati, un rack server in esercizio, una scheda elettronica danneggiata a terra — a rappresentare il ciclo di vita completo dall'acquisto al fine vita.
01Aggiornamento normativoGovernance

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

Una sfera scura che avanza lungo un percorso scavato nel marmo, tra segnalatori luminosi in sequenza, verso un pulsante finale: una catena di controlli da attraversare prima che un'azione venga eseguita.
02AnalisiGovernance

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

Due blocchi di pietra con forme scavate a rappresentare sistemi distinti, collegati da un piccolo ponte metallico, a rappresentare una connessione che i sistemi da soli non forniscono.
03FrameworkGovernance

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