La Control Room Alstom Service è una piattaforma operativa a supporto del monitoraggio degli impianti ferroviari, della gestione delle segnalazioni, della tracciabilità delle attività tecniche, delle richieste RMA e della documentazione di impianto e di prodotto.
Lo strumento nasce per l'utilizzo interno da parte dei team di assistenza tecnica e viene successivamente esteso anche al cliente. In ambito operativo può essere indicato anche come web tool. L'obiettivo principale è offrire un punto di accesso strutturato alle informazioni tecniche necessarie per comprendere lo stato degli impianti, analizzare anomalie, gestire richieste di supporto e seguire il ciclo di riparazione dei materiali.
La guida è organizzata per lezioni autonome. Ogni lezione descrive una sfaccettatura della Control Room e può essere letta separatamente: contesto Service, navigazione, tecnologie, impianti, allarmi, diagnostica, ticketing, RMA, logistica, documentazione tecnica, flussi interni e miglioramento continuo.
La Control Room nasce a supporto della struttura di Service, distribuita principalmente tra Bologna, Firenze e Roma Nomentana. Il perimetro organizzativo comprende diversi team e un ordine di grandezza di circa settanta risorse. In questo contesto il team di assistenza tecnica/help desk rappresenta la prima interfaccia verso il cliente quando si verifica un problema in impianto.
Il cliente dovrebbe essere autonomo nella manutenzione di primo livello, grazie alla formazione ricevuta in fase di attivazione dell'impianto e alla disponibilità dei manuali di manutenzione. La formazione fa parte delle attività contrattuali di Service: prima dell'attivazione, o in parallelo all'attivazione, i colleghi competenti per ciascuna tecnologia formano il cliente e consegnano la documentazione necessaria.
Quando il cliente non riesce a risolvere autonomamente un problema, può contattare l'assistenza tecnica tramite diversi canali, tra cui centralino, e-mail o chiamata diretta. La procedura ufficiale prevede l'uso di un numero verde attivo 24 ore su 24 e 7 giorni su 7, con un menu guidato che indirizza il manutentore alla tecnologia corretta; nella pratica possono arrivare anche e-mail o chiamate dirette a colleghi già conosciuti dal cliente.
Quando necessario, i colleghi di assistenza tecnica si collegano da remoto agli impianti tramite una VPN separata dalla rete Alstom, identificata come rete Fastweb. Gli impianti non sono accessibili da Internet: l'accesso remoto serve a entrare nella rete chiusa di impianto, consultare i sistemi di diagnostica, scaricare log e verificare le informazioni disponibili sugli apparati.
La schermata iniziale della Control Room presenta quattro macro-aree tecnologiche, ciascuna rappresentata da un riquadro/indicatore:
Queste aree costituiscono i principali domini funzionali del sito. La parte interlocking è particolarmente rilevante per le attività sugli allarmi, perché comprende molti dei controlli diagnostici e delle verifiche operative utili al team.
L'interlocking comprende i sistemi attinenti alla sicurezza della circolazione ferroviaria. Si tratta di sistemi automatici che devono rispettare standard di sicurezza elevati; per i sistemi vitali il riferimento è SIL4, Safety Integrity Level 4. La funzione fondamentale dell'interlocking è governare in sicurezza la circolazione ferroviaria.
In termini pratici, l'interlocking verifica che esistano le condizioni di sicurezza affinché un treno possa percorrere una determinata tratta. Se le condizioni sono soddisfatte, predispone gli enti di campo e gli apparati necessari affinché il movimento possa avvenire. La distinzione essenziale è quindi tra l'esigenza di far circolare i treni e l'obbligo di farlo rispettando la logica di sicurezza dell'impianto.
Il TMS, o Traffic Management System, è l'insieme dei sistemi usati dalle figure operative che eserciscono la linea ferroviaria. In italiano si fa riferimento al CTC, controllo del traffico centralizzato. Tra le figure operative rientrano il DCO, dirigente centrale operativo, e il DM, dirigente movimento: sono operatori del cliente che lavorano dalle rispettive postazioni per governare la circolazione.
A differenza dell'interlocking, il TMS non ha come scopo primario la sicurezza vitale, ma la gestione della circolazione: l'operatore richiede la formazione di un itinerario, ad esempio per far passare un treno dalla stazione A alla stazione B rispettando programma e tabella oraria. Il TMS si interfaccia quindi con l'interlocking, che verifica la sicurezza e autorizza o meno la predisposizione degli enti di campo.
Per la parte CTC è rilevante anche FMS, Field Monitoring System. Si tratta di un tool storicamente esterno alla Control Room, sviluppato in origine da una società esterna e usato per monitorare variabili OPC, log presenti sui server di circolazione e stato dei processi delle macchine TMS. L'obiettivo evolutivo è integrare progressivamente FMS nella Control Room; tra le basi di lavoro rientra un primo mockup per il progetto neozelandese KiwiRail.
Ogni treno è equipaggiato con un sistema di bordo. Se la linea è attrezzata con ERTMS, standard europeo per la circolazione ferroviaria con diversi livelli implementativi, il sistema di bordo interagisce con il Radio Block Center (RBC), assimilabile a una torre di controllo.
L'RBC riceve informazioni sullo stato della linea tramite l'interlocking e rilascia, quando possibile, la Movement Authority, cioè l'autorizzazione al treno per approcciare una determinata porzione di linea. La comunicazione tra bordo e RBC è sicura e basata su onde radio GSM-R cifrate. L'RBC può autorizzare il movimento perché conosce, tramite l'interlocking, se il tratto di linea è libero e non occupato da un altro treno.
La parte bordo è collegata anche all'aspetto dei segnali: se l'interlocking verifica che il tratto è libero, può comandare il passaggio di un segnale da rosso a verde, mentre il sistema di bordo conosce in anticipo l'informazione necessaria alla marcia. In condizioni più restrittive, ad esempio se il segnale è giallo o se il macchinista non frena per tempo, intervengono sistemi automatici di protezione e frenatura.
La parte trackside riguarda gli enti di piazzale installati lungo la linea, in particolare casse di manovra dei deviatoi e altri apparati fisici di campo. Il presidio di questa tecnologia è associato soprattutto a colleghi di Service basati a Firenze, con alcune risorse anche a Roma.
Storicamente, interlocking e bordo sono le aree più mature della Control Room, mentre CTC e trackside sono state aggiunte successivamente. La parte trackside è però in progressiva maturazione grazie al lavoro con il team dedicato e sta diventando sempre più completa dal punto di vista funzionale.
La Control Room dispone di una vista laterale ad albero che rappresenta la base installata. La struttura consente di navigare tra clienti, DOIT, impianti e locali. Nel caso italiano, le DOIT sono legate alla suddivisione territoriale di RFI, anche se non corrispondono necessariamente alla geografia amministrativa delle regioni. Un esempio riguarda una DOIT che comprende aree non immediatamente coincidenti con una singola regione amministrativa, come Ancona e l'area Rimini/Riccione.
La tree view contiene anche riferimenti a progetti esteri, come Singapore, India ed Egitto. Per questi progetti la copertura funzionale è al momento limitata e riguarda soprattutto la parte RMA. Nella stessa vista compaiono anche altri clienti o contesti italiani oltre a RFI, tra cui Metro Milano, Trenitalia, Trenord, Ferrotranviaria e Ferrovie del Gargano.
Una vista geografica consente inoltre di visualizzare gli impianti sulla mappa, con indicatori e raggruppamenti numerici. I colori visibili nella navigazione e nelle viste di sintesi rappresentano diverse tipologie di allarmi e permettono di capire rapidamente se un impianto o un insieme di impianti richiede attenzione.
Selezionando un impianto o un locale, la Control Room mostra gli apparati monitorati e il loro stato. Gli esempi di Bologna Centrale e Ortona mostrano come, partendo dalla tree view, si possa scendere dal livello impianto al livello locale tecnologico e quindi agli apparati specifici. Le schermate evidenziano:
In questa vista sono presenti anche link come Visualizza architettura locale, usati per approfondire la composizione dell'impianto e la struttura degli apparati. L'accesso a pulsanti come VNC o TELNET deve essere letto nel contesto della rete chiusa di impianto e della VPN descritta in precedenza: non si tratta di apparati esposti pubblicamente, ma di sistemi raggiungibili solo attraverso i canali operativi previsti.
La funzione di visualizzazione dell'architettura locale consente di consultare l'elenco degli apparati aggregati per tipologia. L'esempio di Bologna Centrale mostra apparati di circolazione come CLC, SCC gateway, HDLC gateway e altri sistemi, ciascuno con informazioni di indirizzamento e stato.
Questa vista è importante perché collega il dato sintetico dell'allarme alla struttura reale dell'impianto: permette di capire quali apparati fanno parte di una certa tipologia, se sono ridondati e quale sezione risulta in servizio o disponibile in un determinato momento.
Un concetto ricorrente nella guida è quello di ridondanza. Molti apparati sono indicati con le lettere N e R, cioè normale e riserva. Questo vale per il CLC, ma anche per apparati come SCC gateway e HDLC gateway.
Un sistema ridondato dispone di una sezione in servizio e di una sezione disponibile. Se la sezione in servizio presenta un degrado, il sistema dovrebbe essere in grado di commutare automaticamente sull'altra sezione. La ridondanza è a caldo: una sezione governa l'impianto, mentre l'altra è pronta a subentrare senza richiedere un intervento manuale ordinario.
Il CLC è il "cervellone" dell'impianto. L'acronimo è ricondotto a calcolatore logico computerizzato. In termini funzionali, è l'apparato che contiene la logica dell'impianto e che invia comandi al campo, ricevendo al tempo stesso controlli dagli enti di campo.
La logica è contenuta nel software e nelle configurazioni installate sulle schede del CLC, con riferimento anche a una card/micro-SD. Il CLC stabilisce ad esempio quale debba essere l'aspetto di un segnale, se un segnale debba passare da rosso a verde o viceversa, oppure se una cassa di manovra debba ricevere alimentazione per muovere un deviatoio. La richiesta può arrivare dalla parte TMS/CTC, ma l'autorizzazione effettiva dipende dalla verifica della logica di impianto da parte del CLC.
Nel perimetro interlocking rientrano anche le famiglie di prodotto Smartlock 300 e Smartlock 400, a volte chiamate sinteticamente 300 e 400, e alcuni casi ibridi. Sono prodotti Alstom diffusi in Italia; per confronto, gli impianti ex Bombardier avevano prodotti con nomi diversi, come Ebilock, pur assolvendo funzioni analoghe.
Un degrado sul CLC può avere impatti molto rilevanti: con una sola sezione fuori servizio l'impianto può ancora funzionare, ma con entrambe le sezioni fuori servizio la circolazione può essere interrotta.
La Control Room usa colori e categorie per rappresentare le situazioni di degrado o anomalia. La sezione allarmi risponde a due esigenze emerse nell'estensione del tool al cliente: rendere visibili le condizioni critiche degli impianti e supportare i flussi RMA. La sperimentazione con il cliente viene collocata nel 2023, a partire dalla DOIT Bologna di RFI, dopo incontri con la direzione centrale RFI a Roma e con referenti manutentivi locali.
Le principali categorie considerate sono:
Gli allarmi derivano da informazioni raccolte dagli impianti e dai sistemi di diagnostica. Gli applicativi della Control Room non devono essere invasivi verso l'impianto: leggono le liste allarmi prodotte dai sistemi diagnostici, le copiano sui server e applicano regole o filtri automatici. Questo requisito di non intrusività viene ribadito più volte: RFI ha richiesto anche attestazioni formali per dimostrare che il monitoraggio non scrive sugli impianti e non interferisce con i sistemi in esercizio.
Gli allarmi standard sono indicati in giallo. Un allarme standard può rappresentare un apparato non raggiungibile tramite ping per un certo periodo. Il colore giallo segnala quindi una condizione da verificare, distinta dagli allarmi a tempo rossi, che rappresentano degradi più critici o reiterati.
La Control Room esegue controlli automatici sugli apparati dotati di indirizzo IP all'interno della rete chiusa di impianto. Dopo una serie di ping falliti e oltre una soglia temporale configurata, viene alzato un allarme standard. La soglia non è fissata in modo definitivo, perché è un parametro configurabile e soggetto ad aggiornamenti.
Gli allarmi standard vengono anche riepilogati in e-mail giornaliere, come la mail Stato Allarmi, che fotografa la situazione degli allarmi attivi alle 10 del mattino. In ambito interlocking è presente anche la mail Stato Allarme IXL Italia, inviata ai colleghi del gruppo interlocking e, su richiesta, anche a contesti cliente come le DOIT Bologna e Roma.
Gli allarmi a tempo sono allarmi più critici, contrassegnati in rosso. Non rappresentano semplicemente un ping fallito, ma una condizione critica o un degrado reiterato nel tempo. Vengono generati dagli applicativi della Control Room quando le regole configurate trovano, nelle liste allarmi scaricate dal campo, condizioni coerenti con un degrado.
Tra gli esempi citati:
Il caso dei rimbalzi riguarda apparati ridondati che dovrebbero commutare correttamente tra sezione normale e riserva. Questi sistemi commutano normalmente in automatico, spesso di notte. Se una sezione che era disponibile prova ad andare in servizio ma non riesce, ad esempio per un guasto o degrado su una scheda del cestello, può tornare allo stato disponibile; se questo comportamento si ripete, la Control Room può segnalarlo come possibile degrado.
Un'attività operativa utile consiste nel verificare la veridicità di questi allarmi, confrontando gli eventi SDM e le liste allarmi. Se l'allarme non trova riscontro nei dati, può trattarsi di un falso allarme da segnalare agli sviluppatori.
Il rilascio degli allarmi di mancata commutazione sugli ZLC deve essere graduale. L'obiettivo è evitare di abilitarli "a pioggia" su tutte le DOIT e generare improvvisamente un numero ingestibile di allarmi a tempo; è preferibile procedere con un'estensione progressiva, ad esempio una DOIT alla volta.
Gli allarmi a tempo possono essere riconosciuti dagli operatori di assistenza tecnica. Il riconoscimento serve a indicare che il problema è noto e a escludere l'allarme dal conteggio degli allarmi attivi.
Questo comportamento è utile quando i colleghi sanno già dell'esistenza del degrado e preferiscono non includerlo nel computo operativo degli allarmi da attenzionare. Il riconoscimento è collegato anche alle e-mail giornaliere: la fotografia degli allarmi attivi deve evidenziare ciò che richiede attenzione, non ripetere problemi già noti e già presi in gestione.
Gli allarmi non ricevuti indicano situazioni in cui la Control Room non riesce momentaneamente a ricevere da un impianto la lista allarmi. La lista può essere prodotta dal server di manutenzione o dal Support System Server, a seconda della tecnologia dell'impianto.
La generazione della lista allarmi avviene secondo una schedulazione variabile. Sugli SM è presente un applicativo/task schedulato, non intrusivo, che più volte al giorno genera un file Excel/CSV poi compresso; la Control Room lo scarica e lo porta sui propri server per l'elaborazione.
I possibili scenari sono tre:
Il tab Non aggiornati raccoglie apparati per i quali ci si aspetterebbe di trovare informazioni nelle liste allarmi, ma per i quali tali informazioni non sono presenti.
La causa è un degrado del sistema di diagnostica dell'impianto, indipendente dal controllo eseguito dalla Control Room. In questi casi la Control Room non dovrebbe alzare un allarme a tempo sullo stesso apparato, perché mancano i dati di base da cui derivare l'allarme: sarebbe un'informazione ridondata o non affidabile.
Un esempio è l'ACC di Pavia, dove non risultano disponibili informazioni sugli ZLC 1 e 2, normale e riserva.
Dal punto di vista operativo, questi casi richiedono un coinvolgimento dei team di prodotto o di chi presidia la diagnostica dell'impianto. L'attività non è banale, perché può significare intervenire su sistemi in esercizio e spesso molto datati, con riferimenti a versioni storiche di Windows come Windows 95, Windows NT e Windows XP.
I sistemi di diagnostica producono liste allarmi. La lista allarmi è un file CSV contenente gli eventi diagnosticati dal sistema. A seconda della tecnologia, la diagnostica può essere il server di manutenzione/SM per impianti Smartlock 300 oppure il Support System per impianti Smartlock 400; nei casi ibridi possono coesistere entrambe le logiche.
I file prodotti dai sistemi di diagnostica possono essere compressi e poi decompressi dagli applicativi della Control Room. Le strutture dei CSV possono variare tra SM e Support System, ma il principio resta lo stesso: la Control Room acquisisce il dato diagnostico e applica regole automatiche per riconoscere condizioni di interesse.
Le colonne citate includono: timestamp/data allarme, elemento o oggetto monitorato, stato dell'evento, codice errore in formato esadecimale, descrizione dell'errore.
Gli applicativi della Control Room applicano regole automatiche su questi dati. Se una condizione configurata è soddisfatta, viene generato l'allarme corrispondente. Le regole possono cercare la presenza di determinati codici esadecimali, stati o combinazioni di stati su apparati specifici.
Un esempio mostra lo ZLC4N e lo ZLC4R alternarsi tra stato disponibile e stato in servizio: un giorno la sezione normale è disponibile e la riserva è in servizio, il giorno successivo avviene lo scambio, e poi le sezioni tornano nuovamente ad alternarsi. Questo caso spiega come i dati delle liste allarmi possano essere usati per verificare commutazioni e possibili degradazioni.
Se la commutazione risulta regolare nelle liste allarmi, ma la Control Room ha comunque generato un allarme di mancata commutazione, il caso deve essere trattato come possibile falso allarme da approfondire lato applicativo.
Gli eventi SDM sono associati ai log prodotti dal server di manutenzione. SDM e SM sono usati quasi come sinonimi quando si parla della diagnostica degli impianti Smartlock. Gli eventi Ssys, invece, derivano dalle liste allarmi del Support System Server; Ssys è l'abbreviazione di Support System Server.
La Control Room registra questi eventi a database e permette di consultarli tramite tabelle e filtri. La pagina Eventi SDM rappresenta quindi la versione interrogabile a database delle righe presenti nei log o nelle liste diagnostiche.
Nel controllo operativo, gli eventi SDM possono essere usati per verificare se un allarme a tempo è effettivamente coerente con quanto accaduto in impianto. Ad esempio, se un allarme segnala una mancata commutazione, si può cercare negli eventi SDM se lo ZLC stia invece commutando regolarmente.
La sezione Eventi Ssys segue lo stesso principio degli Eventi SDM, ma applicato ai dati provenienti dal Support System. Può contenere un numero molto elevato di record, nell'ordine di migliaia o anche molti più eventi; per questo motivo il caricamento può risultare pesante.
La Control Room include anche eventi SDM ex BT, dove BT sta per Bombardier Transportation. Il monitoraggio degli impianti ex Bombardier è più limitato rispetto agli impianti Alstom.
Il motivo è architetturale: in molti casi, per raggiungere il server di manutenzione o il Support System Server degli impianti ex Bombardier, sarebbe necessario passare dal CLC dell'impianto. Questa operazione è delicata per i vincoli di non invasività e sicurezza discussi in precedenza.
Per questo motivo, il monitoraggio ex BT è stato aperto solo in casi semplici e meno rischiosi, come alcuni impianti nelle DOIT di Roma, Firenze e Palermo. Tra gli esempi nominati compaiono Roma Tiburtina, Campo di Marte/Rovezzano e Canicattì.
Oltre al monitoraggio, la Control Room viene usata anche per creare e consultare ticket. Quando un collega riceve una chiamata o una mail dal cliente, può consultare lo storico dei ticket relativi allo stesso impianto, locale tecnologico o apparato, oppure può crearne uno nuovo.
Questa tracciabilità è stata particolarmente importante durante il periodo di lockdown, ma resta utile anche nell'operatività quotidiana, perché i colleghi possono trovarsi in smart working, in trasferta, in ferie o in reperibilità.
La reperibilità copre a turno le fasce fuori dall'orario d'ufficio, indicativamente dalle 17 alle 9 del mattino successivo, con cellulare aziendale acceso. La Control Room consente quindi non solo di gestire il problema tecnico, ma anche di tracciare formalmente le attività svolte e i passaggi di consegne.
La tracciabilità permette di ricostruire: il problema segnalato dal cliente, la soluzione adottata, le attività svolte, eventuali passaggi di consegne.
Le RMA, Return Material Authorization, sono richieste di riparazione materiali. Il cliente apre una richiesta tramite la Control Room e l'intero ciclo viene tracciato nel web tool, nel database della piattaforma e, per gli aspetti gestionali, in SAP/GSI. Il flusso sostituisce progressivamente lo scambio destrutturato via e-mail e fogli Excel: la richiesta diventa un ticket con dati obbligatori, allegati, stati, responsabilità operative e aggiornamenti automatici.
Il numero RMA inizia tipicamente con 840 ed è generato nel gestionale aziendale. La Control Room mantiene anche un proprio ID interno, che non coincide necessariamente con l'identificativo SAP/GSI. La gestione di data entry e aggiornamento verso SAP/GSI è svolta da Finsoft/Present; le attività di validazione tecnica restano invece in carico all'assistenza tecnica Alstom.
Il flusso descritto in questa lezione è il flusso standard per i materiali assegnati ai siti logistici Alstom di Sesto San Giovanni e Firenze. Questi due siti sono considerati standard perché dotati di magazzino, logistica ed entrata merci strutturata. Bologna e Roma possono ricevere ticket di riparazione, ma sono casi con deviazioni operative perché legati più a laboratori o materiali interni che a una logistica completa. Ucinet e Sysnet possono essere usati come fornitori esterni, in particolare per hardware commerciale CTC.
Le modifiche più recenti ai flussi RMA nascono soprattutto da esigenze della parte wayside, con applicazione iniziale a interlocking e trackside. La stessa logica è destinata a essere estesa anche al CTC; per il bordo l'applicazione resta invece un punto da valutare. Il cliente ATM/Metro Milano è citato come caso con flusso leggermente diverso rispetto allo standard qui descritto.
La motivazione operativa degli stati nuovi è duplice: da un lato tracciare meglio i casi in cui il corriere non passa nel giorno previsto o dichiara un passaggio non riscontrato dal cliente; dall'altro ridurre l'accumulo di schede presso il cliente prima dell'invio effettivo in riparazione. Entrambi i fenomeni possono generare ritardi sul reintegro e quindi impatti contrattuali.
Gli ambienti di lavoro sono organizzati su più macchine e database. In ambito operativo ricorrono spesso i riferimenti alle macchine 99, 100 e 98:
L'architettura è stata riorganizzata per rispondere a esigenze di cybersecurity e ridurre l'esposizione dei sistemi. Il concetto operativo è assimilabile a un data diode: i dati devono fluire dal campo verso le macchine di Control Room, evitando che più macchine si interfaccino direttamente con gli impianti.
Per le prove applicative esistono più ambienti DEV, associati ai diversi sviluppatori. Il ciclo operativo descritto prevede che lo sviluppatore recepisca una richiesta di modifica o bug fix tramite GitLab, sviluppi in locale, pubblichi sul proprio ambiente di test e, dopo verifica e commento della issue, promuova la modifica verso la produzione.
Le utenze cliente sono legate alla struttura manutentiva del cliente. Per RFI, l'associazione avviene per UMIS, cioè unità manutentive infrastrutture di segnalamento. Un utente appartenente a una UMIS vede soltanto gli impianti e i locali di pertinenza. L'anagrafica utenti è gestita nel database APS, nella tabella users.
Il cliente accede al web tool con un'utenza profilata. Una volta selezionato il locale, la Control Room mostra l'elenco degli apparati monitorati. Il cliente individua l'apparato oggetto del guasto, ad esempio un CLC, e seleziona la relativa casella. A quel punto può scegliere tra due azioni:
Il form RMA è la versione digitale del precedente foglio Excel che il cliente compilava e inviava via e-mail. Alcuni campi vengono precompilati dal sistema in base al contesto selezionato: DOIT, impianto, locale, apparato e data avaria. I campi obbligatori sono contrassegnati con l'asterisco.
Il campo Scorta indica se il materiale guasto proviene dal magazzino scorte del cliente. Quando un impianto viene consegnato al cliente, vengono consegnate anche scorte utili a sostituire rapidamente componenti guasti. Se il materiale oggetto della RMA è una scorta, i campi relativi all'intervento manutentivo vengono disabilitati: non c'è un intervento di campo vero e proprio da descrivere, perché il problema emerge nel momento in cui la scorta viene provata o installata.
Se il guasto non riguarda una scorta, il cliente può descrivere l'intervento svolto, la durata, l'ente eventualmente impattato e il messaggio diagnostico.
La sezione Componenti Ticket è divisa in due riquadri: Componente Rimosso (materiale guasto) e Componente Installato (materiale installato in sostituzione).
Il cliente può identificare il materiale guasto in due modi: tramite part number o tramite etichetta/descrittiva.
Il part number identifica il tipo di materiale secondo la nomenclatura Alstom. Il serial number identifica invece l'esemplare fisico. In un flusso di riparazione tradizionale Alstom può riparare e restituire lo stesso seriale; in un flusso di fast repair/fast exchange può reintegrare un materiale equivalente con lo stesso part number ma seriale diverso.
Quando il cliente seleziona la ricerca per part number, il sistema propone l'elenco dei part number associati all'impianto. Questo elenco deriva dalle tabelle PBS/PTS e partnumber: la PBS, Product Breakdown Structure, associa a un impianto i componenti installati, i relativi part number, le descrittive e le quantità.
Se il part number non è presente, il cliente non viene bloccato: può scegliere l'opzione per indicare il part number mancante nel campo nota. Il campo Part Number Cliente dovrebbe contenere il categorico del cliente, cioè la nomenclatura interna usata dal cliente per mappare il materiale Alstom.
Il cliente può scegliere tra Salva in attesa e Invio richiesta.
Dopo l'invio, il ticket compare nella sezione RMA. Il tab RMA Aperte non contiene solo i ticket in stato OPEN: contiene tutti i ticket non ancora arrivati allo stato CLOSED.
La richiesta inviata dal cliente entra inizialmente in stato OPEN. L'assistenza tecnica Alstom verifica la completezza e la correttezza della richiesta.
Il ticket può essere rifiutato quando: il cliente ha compilato la richiesta in modo insufficiente o non chiaro; il materiale non rientra nell'accordo quadro; la riparazione deve seguire un canale diverso.
In caso di rifiuto, l'operatore seleziona lo stato RIFIUTATO/REJECTED e inserisce nel campo note la motivazione da comunicare al cliente.
Se la richiesta è corretta, l'assistenza tecnica seleziona VALIDATO/VALIDATED e assegna il ticket a un sito Alstom o a un fornitore esterno. Per il flusso standard l'assegnazione tipica è Sesto o Firenze. Per alcune riparazioni CTC, soprattutto su hardware commerciale, possono essere coinvolti Ucinet o Sysnet.
Quando il cliente sceglie l'opzione per part number mancante, può essere necessario mettere il ticket in SUSPENDED: lo stato segnala che il part number deve essere verificato o aggiunto a database per l'impianto corretto.
All'apertura, alla validazione o al rifiuto possono partire e-mail automatiche.
Dopo la validazione, il ticket passa alla gestione Finsoft/Present. La società è citata spesso come Finsoft anche se ufficialmente indicata come Present. L'utenza Finsoft ha una visibilità limitata: nella navigazione laterale non vede la base installata e nella navbar accede sostanzialmente alla sola sezione RMA.
Finsoft/Present inserisce le informazioni ricavate da SAP/GSI, in particolare: Equipment, associato al part number; RMA o RMA/STO, cioè il codice gestionale della richiesta.
Se Finsoft/Present rileva incongruenze nelle informazioni inserite dal cliente, può compilare le note interne e impostare lo stato CHECK. In questo modo il ticket torna all'attenzione dell'assistenza tecnica, che deve verificare i dati prima di proseguire.
Nel caso nominale, Finsoft/Present inserisce Equipment e RMA, quindi usa l'azione di chiusura RMA compresa. Il ticket passa allo stato WAITING PICK-UP.
Finsoft/Present può anche usare Modifica Ticket per correggere informazioni chiave, come part number, serial number, RMA e STO. Questa funzione serve quando il materiale arrivato fisicamente a magazzino non corrisponde a quanto dichiarato dal cliente: in quel caso è necessario aggiornare sia SAP/GSI sia la Control Room, tracciando il cambio anche a livello di ticket.
Quando il ticket arriva in WAITING PICK-UP, la palla torna al cliente. Il cliente entra nella sezione DDT, cioè Documento di Trasporto, e seleziona i ticket per cui richiede il ritiro del materiale guasto.
La Control Room impedisce di combinare nella stessa richiesta ticket assegnati a siti di riparazione diversi. Il corriere deve avere una destinazione univoca: se un materiale è assegnato a Bologna e un altro a Sesto, il cliente deve generare due richieste separate.
Nella parte inferiore della pagina sono presenti due opzioni:
Il cliente compila inoltre i dati logistici necessari alla spedizione: numero DDT incrementato automaticamente, aspetto esteriore dei colli, numero colli e peso.
Dopo la generazione del DDT, il ticket passa in CONFIRMED PICK-UP. Il sistema genera un documento di trasporto, chiamato anche bolla, che riprende il template cliente: intestazione, logo, destinatario, elenco materiali e dati dei colli.
Quando il ticket è in CONFIRMED PICK-UP, interviene il collega incaricato di prenotare il ritiro sui portali dei corrieri (DHL/TNT), prenotare il ritiro e caricare nel web tool l'etichetta del corriere.
Il collega può selezionare i ticket singolarmente oppure usare Caricamento Multiplo Etichetta, che filtra automaticamente i ticket in stato Confirmed pick-up.
La maschera di upload consente di inserire note del ritiro, numero della lettera di vettura e allegare l'etichetta corriere. La lettera di vettura è il tracking number usato poi dalle API: TNT usa tipicamente stringhe precedute da MY, mentre DHL usa numerazioni proprie.
Dopo il salvataggio, il ticket passa in BOOKED PICK-UP e l'etichetta diventa un allegato consultabile nel dettaglio del ticket.
Le colonne API Tracking Status e API Tracking Date riportano lo stato della spedizione restituito dai sistemi dei corrieri e la data dell'ultimo aggiornamento. Gli script interrogano i portali DHL/TNT usando la lettera di vettura come input, scrivono il risultato a database e la Control Room lo mostra in tabella.
Il funzionamento operativo distingue due livelli di automazione: le API di tracking girano al mattino presto, intorno alle 5:00, e aggiornano il database con lo stato restituito dal corriere; altri script di fine giornata lavorativa, indicativamente tra le 17:30 e le 18:00, aggiornano poi lo stato dei ticket in funzione delle informazioni acquisite.
I messaggi possono variare in base al corriere. Per TNT possono comparire valori come "Spedizione consegnata" o frasi in italiano; per DHL sono frequenti valori in inglese come "Delivered".
Se dopo tre giorni lavorativi un ticket resta in BOOKED PICK-UP, il sistema interpreta la situazione come probabile mancato passaggio del corriere. Il ticket viene portato nello stato BOOKED PICK-UP FAILED. Per riprogrammare, l'operatore usa Aggiornamento Multiplo Etichetta, che filtra i ticket in Booked pick-up failed. Dopo il nuovo caricamento delle informazioni di ritiro, il ticket torna in BOOKED PICK-UP.
Il ticket passa da BOOKED PICK-UP a COMPLETED PICK-UP quando le API indicano che il corriere ha effettivamente preso in carico il pacco. Per DHL il riferimento può essere un messaggio come "Shipment picked up"; per TNT può essere un valore come "La spedizione è in transito".
Il passaggio successivo è ARRIVED, quando il materiale arriva a destinazione nel sito di riparazione. Anche questo passaggio può essere alimentato dai messaggi API: "Delivered" per DHL o "Spedizione consegnata" per TNT.
Lo stato REGISTERED indica un passaggio ulteriore: il materiale ha fatto entrata merci. Il dato non deriva solo dal tracking corriere, ma dalle estrazioni SAP/GSI. Una transazione SAP, indicata operativamente come ZSESO11 o forma equivalente, esporta un CSV sulla macchina di Control Room. Il file viene letto quotidianamente dagli script della piattaforma. Usando come chiave il numero RMA, gli script recuperano la data di entrata merci, la scrivono a database e abilitano il passaggio a Registered.
Arrived significa che il pacco è stato consegnato; Registered significa che l'entrata merci è stata registrata formalmente. I due stati non devono essere confusi.
Il ticket diventa CLOSED solo quando il materiale è stato reintegrato al cliente. Il reintegro può avvenire in due modi:
Per rispettare vincoli contrattuali, ad esempio reintegro entro 30 giorni dalla richiesta di riparazione, Alstom può anticipare la restituzione di un materiale equivalente prima ancora che il pezzo guasto sia arrivato o sia stato riparato.
Il reintegro viene tracciato tramite informazioni SAP/GSI, tra cui il DDT reintegro e la data di reintegro.
Quando il reintegro è completato, il ticket è visibile nel tab RMA Chiuse. Questo è il punto corretto in cui considerare chiuso il ciclo, non il semplice arrivo del materiale guasto al sito di riparazione.
| Stato | Attore principale | Significato operativo | Passaggio successivo |
|---|---|---|---|
| DRAFT | Cliente | Richiesta salvata in bozza, visibile solo al cliente. | Invio richiesta da parte del cliente. |
| OPEN | Cliente / Assistenza tecnica | Richiesta inviata e visibile ad Alstom. | Validazione, rifiuto o sospensione. |
| SUSPENDED | Assistenza tecnica | Dati da verificare, ad esempio part number mancante o anagrafica da aggiornare. | Correzione dati e ripresa del flusso. |
| REJECTED | Assistenza tecnica | Richiesta non accettata, con motivazione nelle note. | Chiusura del caso rifiutato. |
| VALIDATED | Assistenza tecnica | Richiesta accettata e assegnata a sito/fornitore. | Presa in carico Finsoft/Present. |
| CHECK | Finsoft/Present / Assistenza tecnica | Incongruenza riscontrata da Finsoft/Present, da verificare. | Correzione o conferma da assistenza tecnica. |
| WAITING PICK-UP | Finsoft/Present / Cliente | RMA e dati gestionali inseriti; il cliente può generare il DDT. | Generazione DDT da parte del cliente. |
| CONFIRMED PICK-UP | Cliente / Operatore spedizioni | DDT generato e richiesta di ritiro formalizzata. | Prenotazione ritiro e caricamento etichetta. |
| BOOKED PICK-UP | Operatore spedizioni / API corriere | Ritiro prenotato, etichetta caricata, tracking disponibile. | Completed pick-up o booked pick-up failed. |
| BOOKED PICK-UP FAILED | Operatore spedizioni | Il corriere non risulta passato entro tre giorni lavorativi. | Riprogrammazione ritiro. |
| COMPLETED PICK-UP | API corriere | Il corriere ha preso in carico il pacco. | Consegna al sito di riparazione. |
| ARRIVED | API corriere / sito logistico | Il pacco è stato consegnato al sito. | Entrata merci SAP/GSI. |
| REGISTERED | SAP/GSI / script Control Room | Entrata merci registrata formalmente. | Riparazione/reintegro. |
| CLOSED | SAP/GSI / Control Room | Reintegro completato e ticket chiuso. | Visibilità nel tab RMA Chiuse. |
Questa distinzione tra stati evita l'errore operativo più rilevante: considerare chiuso un ticket solo perché il materiale guasto è arrivato al sito. Il completamento reale del ciclo coincide con il reintegro del materiale funzionante al cliente.
Le riparazioni affidate a fornitori esterni riguardano soprattutto hardware commerciale, in particolare nel perimetro CTC. I fornitori citati sono Ucinet e Sysnet. Il flusso è molto vicino al flusso standard, ma introduce una differenza sostanziale nella gestione del codice RMA: queste riparazioni non vengono tracciate nel SAP/GSI Alstom e quindi il fornitore non valorizza il campo RMA con la codifica Alstom, cioè con numerazioni del tipo 840…. Il fornitore usa invece la propria codifica, coerente con il proprio gestionale.
Al momento le integrazioni API strutturate sono disponibili verso DHL e TNT. I fornitori esterni possono però utilizzare corrieri diversi: Ucinet è indicata come realtà che tende ad appoggiarsi a Bartolini, mentre Sysnet viene associata a GLS.
Nel flusso A2 il cliente apre il ticket e l'assistenza tecnica lo valida assegnandolo al fornitore esterno. Restano possibili gli stati di sospensione o rifiuto, come nel flusso standard.
Dopo la validazione, il fornitore valorizza il campo RMA con il proprio riferimento e il cliente procede nella sezione DDT, genera il documento di trasporto e porta la richiesta in CONFIRMED PICK-UP.
La particolarità del flusso fornitore è il passaggio successivo. Dopo il Confirmed pick-up, il fornitore carica la propria etichetta o bolla di ritiro e il ticket passa in BOOKED PICK-UP.
Una volta avvenuta la ricezione del materiale, il fornitore conferma la ricezione nella Control Room. Superato questo step, il ticket passa in REGISTERED. In questo scenario Registered non deriva dall'entrata merci SAP/GSI Alstom, ma dalla conferma operativa del fornitore, perché il materiale non entra in un magazzino Alstom tracciato a GSI.
Quando la riparazione è conclusa e il fornitore è pronto a reintegrare il materiale al cliente, il flusso rientra nella logica già vista per il reintegro: vengono popolati i campi di reintegro, viene allegata l'eventuale etichetta e si usa Conferma Reintegro. Solo a questo punto il ticket passa in CLOSED.
Il flusso A3 riguarda riparazioni assegnate al Service di Bologna o Roma con richiesta di presa del materiale. La prima parte è sostanzialmente analoga al flusso standard.
La differenza principale è che le riparazioni assegnate a Bologna o Roma non sono tracciate su SAP/GSI come le riparazioni del flusso standard su Sesto o Firenze. Per questo il campo RMA viene precompilato con l'ID ticket della Control Room. È una convenzione operativa concordata per gestire correttamente casi che non dispongono di un RMA SAP/GSI con codifica 840.
Dopo la generazione del DDT e la richiesta di presa, interviene il collega che prenota il ritiro. In questo scenario rientrano le integrazioni con DHL/TNT: quando l'etichetta di ritiro viene caricata, il ticket passa in BOOKED PICK-UP. Gli aggiornamenti successivi seguono la stessa logica del flusso standard basato su API corriere: COMPLETED PICK-UP, ARRIVED.
Il passaggio ad ARRIVED non chiude il ciclo. Bologna e Roma non sono descritti come siti logistici formalmente attrezzati con magazzino ed entrata merci SAP/GSI; quindi, per evitare che il ticket resti indefinitamente in Arrived, i colleghi di assistenza tecnica devono entrare nella Control Room, compilare i campi richiesti e usare Conferma Ritiro. Questa azione porta il ticket in REGISTERED.
Quando il materiale è stato riparato ed è pronto per tornare al cliente, gli stessi campi logistici vengono usati in senso inverso per il reintegro. Il personale compila le informazioni di reintegro e clicca Conferma Reintegro. Solo questa azione porta il ticket in CLOSED.
Il flusso A4 rappresenta il caso di consegna brevi manu verso il Service Bologna. È un caso più raro, ma viene mantenuto per completezza perché può verificarsi quando la vicinanza geografica consente al cliente o a chi presidia il sito di portare direttamente il materiale da riparare, senza attivare un ritiro tramite corriere.
Anche nel flusso A4 il campo RMA non deve essere interpretato come RMA SAP/GSI: trattandosi di riparazioni su Bologna non tracciate nel gestionale Alstom, il riferimento corretto è l'ID ticket o una codifica coerente con la convenzione adottata per questi casi.
La consegna manuale bypassa gli stati legati al corriere. Non essendoci prenotazione, presa in carico tramite API, mancato ritiro o consegna tracciata dal corriere, il ticket non attraversa la catena BOOKED PICK-UP, BOOKED PICK-UP FAILED, COMPLETED PICK-UP e ARRIVED. Dopo la validazione e la scelta della consegna manuale, il ticket può arrivare direttamente in REGISTERED.
Le riparazioni trackside rientrano sostanzialmente nel flusso standard, perché sono gestite in modo prevalente su Firenze. Per questo non serve duplicare l'intera catena degli stati.
La differenza significativa è nel form di apertura RMA. Nel caso trackside è presente un menu a tendina aggiuntivo per indicare l'indirizzo di ritiro/reintegro. Il motivo è fisico e logistico: i materiali trackside possono essere molto più ingombranti dei componenti tipici interlocking o CTC. Una stessa UMIS può quindi disporre di più punti di ritiro o magazzini.
| Variante | Ambito | Differenza principale | Stati da presidiare |
|---|---|---|---|
| A2 - Fornitore esterno | Ucinet/Sysnet, soprattutto hardware commerciale CTC | RMA valorizzata con codifica fornitore; ricezione confermata dal fornitore, non da entrata merci SAP/GSI Alstom. | Confirmed pick-up, Booked pick-up, Registered, Closed. |
| A3 - Bologna/Roma con richiesta presa | Service Bologna o Roma con ritiro tramite corriere | Campo RMA precompilato con ID ticket; tracking DHL/TNT fino ad Arrived; Registered confermato manualmente dal Service. | Booked pick-up, Completed pick-up, Arrived, Registered, Closed. |
| A4 - Consegna brevi manu Bologna | Consegna manuale senza corriere | Bypass degli stati di spedizione; passaggio diretto verso Registered dopo ricezione manuale del materiale. | Registered, Closed. |
| Trackside | Riparazioni prevalentemente su Firenze | Flusso standard, ma form arricchito con indirizzo di ritiro/reintegro per gestire punti logistici diversi. | Stati standard; attenzione all'indirizzo scelto in apertura. |
Il criterio comune resta lo stesso: Closed non deve mai significare soltanto "materiale arrivato". Closed deve rappresentare il reintegro concluso; prima di quel momento, anche quando il pezzo è fisicamente presso Alstom o presso un fornitore, lo stato corretto è Registered o uno stato precedente coerente con il percorso seguito.
La sezione DOC è suddivisa in due tab principali: Prodotto e Impianto.
La documentazione di prodotto è trasversale: contiene manuali di manutenzione, installazione o uso legati a un prodotto o apparato, come CLC o ZLC. Questi documenti vengono rilasciati dai team di prodotto a valle del design e possono esistere in più versioni, coerenti con le diverse configurazioni del prodotto.
La documentazione di impianto, invece, è specifica di un determinato impianto. Nell'esempio di Bologna Centrale, la raccolta dei documenti avviene recuperandoli dalle repository aziendali ufficiali; una risorsa Finsoft è dedicata full time a questo lavoro e procede impianto per impianto secondo una tabella di marcia. Per Bologna Centrale sono caricati documenti come: quadri luminosi, fronte/retro armadi, release note, safety case, schemi elettrici, schemi di allacciamento.
La release note è un documento che traccia le baseline dei sistemi in esercizio sull'impianto e mappa gli allegati rilasciati dal team di progetto, indicando dove rintracciarli nelle repository aziendali.
La disponibilità della documentazione di impianto aggiornata è un requisito contrattuale, in particolare per clienti come RFI. L'obiettivo è offrire un servizio a 360 gradi: non solo allarmi e riparazioni, ma anche accesso strutturato alla documentazione tecnica.
Questa lezione approfondisce il modo in cui la Control Room deve evolvere senza generare rumore operativo. Il filo conduttore è il rilascio graduale delle nuove regole e la verifica della loro affidabilità prima dell'estensione a un perimetro più ampio.
Gli allarmi a tempo relativi alle mancate commutazioni degli ZLC devono essere rilasciati progressivamente in produzione. L'obiettivo non è soltanto tecnico, ma anche operativo: prima di estendere massivamente una regola a molte DOIT, è necessario verificarne la veridicità su un perimetro limitato.
Il rilascio graduale permette di: controllare che gli allarmi generati corrispondano effettivamente a condizioni reali di impianto; evitare di passare improvvisamente da poche decine di allarmi a un numero molto più alto, con il rischio di generare confusione o panico operativo; intercettare falsi allarmi prima che la regola venga estesa a un numero elevato di impianti; costruire un metodo di verifica basato su confronto tra Control Room, eventi diagnostici e liste allarmi.
Un approccio pratico consiste nell'attivare la regola su una DOIT alla volta, verificare insieme ai referenti tecnici la coerenza degli allarmi e procedere solo dopo aver acquisito sufficiente confidenza. Il caso della DOIT Bari viene utilizzato come riferimento iniziale; lo stesso tipo di controllo deve poi essere replicato su altre DOIT, tra cui Ancona.
La documentazione di impianto è particolarmente importante per i colleghi di assistenza tecnica che lavorano in reperibilità. In caso di chiamata urgente, soprattutto durante la notte, non è sempre sufficiente basarsi sull'esperienza generale: può essere necessario recuperare rapidamente un documento specifico.
La Control Room mette a disposizione una vista delle note di impianto che ricostruisce la cronostoria tecnica dell'impianto. Nel caso di Ancona Centrale, le note mostrano le baseline associate all'impianto e permettono di capire quali configurazioni siano state attive in momenti diversi.
Le baseline rappresentano lo stato dei dati caricati sui sistemi dell'impianto. Un impianto funziona in virtù di determinati dati e configurazioni; quando l'impianto viene riconfigurato, possono cambiare una o più baseline.
La vista delle note permette quindi di comprendere che: un'attivazione o riconfigurazione recente compare in alto; le note più vecchie restano consultabili scorrendo la pagina; un cambio di configurazione può modificare una o più baseline; alcune baseline possono rimanere invariate anche quando altre vengono aggiornate.
Per recuperare la documentazione dai repository aziendali è necessario conoscere l'input corretto associato al progetto, identificato nel campo Confidentiality, che può essere letto come una chiave o label di progetto.
Tra i documenti più utili in reperibilità rientrano i fronte/retro armadi. Se il cliente segnala un problema su una scheda, un cestello o un server, il collega di assistenza tecnica può consultare il documento per capire quale hardware sia installato, dove si trovi e come sia identificato.
Questi documenti permettono ai colleghi di "districarsi" più rapidamente tra configurazioni fisiche e riferimenti di materiale. In un contesto di assistenza remota o reperibilità, ridurre il tempo necessario per capire la configurazione installata può essere determinante.
La pagina DDT nasce per gestire il documento di trasporto collegato al ritiro dei materiali da riparare. DDT sta per Documento di Trasporto. Il flusso si inserisce nel ciclo RMA: quando una richiesta di riparazione arriva a un determinato stato, il cliente deve chiedere formalmente il ritiro del materiale guasto.
Storicamente il flusso era gestito via e-mail: il cliente scriveva segnalando il guasto del materiale; Alstom rispondeva assegnando un RMA alla richiesta; il cliente comunicava di aver imballato i pezzi e chiedeva la spedizione o il ritiro; il materiale veniva inviato verso Sesto, Firenze, Bologna, Roma o altri siti in base al caso.
La logistica ufficiale viene indicata soprattutto su Sesto San Giovanni e Firenze. Bologna e Roma Nomentana non sono descritti come siti logistici in senso stretto, ma dispongono di laboratori e materiali di riserva.
La standardizzazione tramite Control Room ribalta lo schema precedente: in condizioni ordinarie è Alstom che organizza il ritiro del pezzo guasto tramite corriere. Questa scelta serve anche a ridurre il rischio che il cliente accumuli più materiali e li invii molto tempo dopo l'apertura dell'RMA.
Per RFI viene citato un vincolo contrattuale rilevante: il reintegro di un pezzo funzionante deve avvenire entro 30 giorni dall'assegnazione dell'RMA alla richiesta di riparazione. Se il pezzo guasto viene inviato molto tardi, il rispetto della scadenza diventa più difficile e può generare penali.
Nella vista cliente, l'utente può selezionare i ticket relativi ai materiali per cui richiede il ritiro. La Control Room impedisce di combinare nella stessa richiesta ticket destinati a siti di riparazione diversi.
Dopo la richiesta, la Control Room genera un allegato indicato operativamente come bolla o IDT. Il documento riprende la struttura del template Excel che in precedenza veniva compilato e inviato via e-mail, ma viene generato automaticamente dalla piattaforma. Il documento di trasporto può cambiare aspetto in funzione del cliente loggato: ad esempio, il logo visualizzato viene adattato al cliente.
La Control Room è stata estesa anche per consentire agli utenti Alstom di aprire direttamente RMA. Questa esigenza nasce dalla gestione di materiale di laboratorio inviato in riparazione verso fornitori esterni, in particolare Ucinet e Sisnet, usati soprattutto per hardware commerciale come server e workstation.
Prima di questa modifica, la creazione di un RMA era prevalentemente una funzione disponibile al cliente. Con l'estensione interna, i colleghi Alstom possono creare un RMA per materiale aziendale o di laboratorio e gestire successivamente la richiesta di ritiro.
Il percorso operativo passa dall'area Service Alstom, all'interno della quale è presente un apparato di tipo Chiamata generica. In questo contesto operativo è stato aggiunto anche l'accesso alla creazione RMA per gli utenti Alstom, accanto alle azioni già esistenti.
Il form compilato dagli utenti Alstom è sostanzialmente lo stesso che il cliente usa quando apre una richiesta RMA. Questo consente di mantenere un flusso coerente e tracciato anche per richieste interne.
Per supportare l'adozione del web tool da parte delle UMIS RFI è stata predisposta una guida operativa. La guida descrive funzionalità come login al sito, gestione degli RMA, apertura di richieste di riparazione e creazione di ticket chiamata per richieste di analisi da remoto.
Un punto particolarmente importante della guida è l'appendice dedicata ai flussi RMA. I flussi cambiano in base al tipo di materiale e al sito o fornitore a cui viene assegnata la riparazione. Tra le assegnazioni possibili compaiono Bologna, Firenze, Sesto, Roma, Ucinet e Sisnet.
A seconda del percorso scelto, cambia il ciclo di vita del ticket nella Control Room. Per questo motivo è utile costruire uno schema a blocchi o diagramma di stato che rappresenti i vari passaggi del ticket: apertura, validazione, attesa pickup, arrivo materiale, registrazione, reintegro e chiusura.
La guida deve essere mantenuta coerente con l'evoluzione reale del web tool. I punti di controllo principali sono:
Questa distinzione è importante perché evita di comunicare al cliente uno stato amministrativo o logistico non corretto. Un ticket può essere arrivato e registrato, ma non ancora chiuso: la chiusura deve rappresentare il completamento del reintegro.
Dalle attività operative emergono anche alcuni miglioramenti puntuali da tracciare internamente:
Le modifiche alla Control Room non devono essere gestite solo tramite scambi verbali o messaggi estemporanei. Il riferimento operativo per tracciare problemi, migliorie e nuove funzionalità è la sezione Issues del progetto GitLab dedicato al web tool.
Una issue rappresenta un elemento da sviluppare, correggere, analizzare o migliorare. Può quindi descrivere: un bug riscontrato nella Control Room; una miglioria o enhancement da implementare; una nuova funzionalità richiesta dagli utenti; un'attività di verifica o test collegata a una modifica già sviluppata.
Non ogni mail o segnalazione ricevuta dal cliente deve diventare automaticamente una issue. La issue è lo strumento corretto quando il problema è sistematico, quando richiede una modifica applicativa, quando introduce una funzionalità nuova o quando serve tracciare formalmente una verifica su una modifica già sviluppata.
Le issue sono compilate usando template, in modo che le informazioni principali siano sempre presenti e leggibili. Una issue ben compilata contiene almeno:
Le issue possono essere etichettate per tipo, ad esempio bug o enhancement, e possono avere anche una priorità e un effort.
Il ciclo di vita delle issue segue una sequenza di stati che consente di capire a che punto si trovi l'attività. Il flusso tipico è:
Lo stato Testing è particolarmente importante per il team operativo: indica che qualcuno deve provare la modifica, riprodurre il caso e confermare se il comportamento è corretto.
Per provare una modifica non ancora rilasciata in produzione si usa l'ambiente DEV del collega che ha sviluppato la funzionalità. La logica di accesso è basata sull'URL della Control Room: la parte webtool viene sostituita con dev_<nome sviluppatore>.
Quando il test non è risolutivo, la issue non deve essere considerata completata. Se la modifica non passa il test, la issue non deve avanzare a Ready for Production. Il tester lascia il riscontro, il DEV corregge e, quando rende disponibile una nuova versione, la verifica deve essere ripetuta.
Il riscontro deve essere scritto nella sezione commenti della issue. Il commento deve essere specifico: ambiente usato, utenza usata, stato del ticket o del caso testato, azioni eseguite, risultato osservato ed eventuali screenshot.
Un buon commento di test evita formule generiche come "non funziona" e indica invece cosa è stato provato. Ad esempio:
Questo approccio consente al DEV assegnato alla issue di ricevere una notifica e di capire rapidamente dove intervenire.
Un nuovo membro del team può contribuire progressivamente su alcune attività operative:
Queste note non limitano l'uso della guida, ma indicano i punti da verificare o completare quando saranno disponibili ulteriori elementi tecnici. La struttura a lezioni consente di aggiornare o ampliare singoli moduli senza riscrivere l'intero documento.
Fine documento.
Nota: le didascalie originali delle figure/screenshot (es. "Figura 1 - ...") sono state omesse in questa migrazione perché le immagini stesse non sono state copiate — vanno riallegate manualmente se si vuole una parità completa con l'originale.