Punti chiave
- La governance legacy sopravvive raramente intatta alla sostituzione di un sistema: flussi di lavoro di approvazione, modelli di accesso e percorsi di escalation si rompono spesso, trascinandosi dietro le inefficienze.
- Non tutti i controlli vanno conservati: alcune configurazioni esistono solo per i limiti della piattaforma, quindi individua le differenze prima della transizione per capire quali riprogettare e quali eliminare.
- La governance basata sui risultati regge quando i sistemi cambiano: definisci cosa deve accadere, non come lo gestisce una piattaforma, così i controlli diventano portabili e più facili da mantenere a ogni sostituzione.
- Durante una transizione la copertura di conformità può venire meno senza farsi notare: se il nuovo sistema non produce prove di audit equivalenti prima del cambio della piattaforma legacy, la lacuna emergerà solo quando sarà un audit a rilevarla.
Quando le organizzazioni IT sostituiscono i sistemi di gestione IT legacy, la governance non è la prima priorità. Eppure processi di approvazione, strutture di reporting, controlli di accesso e modelli di conformità sono costruiti attorno al funzionamento delle vecchie piattaforme e dei vecchi sistemi. Con il tempo, quei sistemi smettono di essere semplici strumenti e rendono la governance dipendente dal loro modo di funzionare.
La trasformazione della governance IT deve avvenire insieme alla sostituzione dei sistemi, non dopo. Se la governance non viene aggiornata durante la transizione, i team finiscono per ricostruire le stesse strutture di controllo nel nuovo ambiente. Così facendo, trasferiscono vecchie inefficienze e costi più alti proprio nella piattaforma che dovrebbe risolverli.
Come trasformare e far evolvere la governance IT quando si sostituiscono i sistemi di gestione IT legacy
Un framework di governance del change management offre ai responsabili IT un modo concreto per riprogettare controlli e responsabilità mentre i sistemi legacy vengono sostituiti.
Come i sistemi legacy plasmano la governance nel tempo
Capire in che modo i sistemi legacy hanno plasmato la governance esistente è il primo passo necessario prima di avviare qualsiasi riprogettazione. Senza questa analisi è piuttosto facile trascinarsi le stesse dipendenze nel nuovo ambiente senza accorgersene.
Ecco alcuni dei modi in cui le piattaforme legacy plasmano la governance nel tempo:
- Flussi di lavoro di approvazione imposti dalla logica del sistema: i processi di approvazione vengono costruiti attorno a ciò che il sistema legacy sa fare, non attorno alle esigenze dell’organizzazione. Quando i sistemi cambiano, quei flussi di lavoro potrebbero non corrispondere in modo pulito al nuovo flusso di lavoro.
- Formati di reporting legati agli output legacy: i team si abituano ai report generati dalla piattaforma legacy. Quei formati diventano lo standard, anche quando non rispecchiano più ciò che è utile o richiesto.
- Controllo degli accessi basato sui limiti della piattaforma: i modelli di autorizzazione sono spesso definiti da ciò che il sistema legacy era in grado di supportare, più che da requisiti di sicurezza o operativi. Questi modelli vengono trascinati in avanti se non vengono rivisti o sostituiti attivamente.
- Prove di audit generate da strumenti specifici: i processi di conformità vengono costruiti attorno agli output di uno strumento specifico. Quando quello strumento viene sostituito, la pista di audit può interrompersi se quegli output non vengono presi in considerazione durante il passaggio.
- Percorsi di escalation definiti dai vincoli del sistema: la logica di escalation viene cablata nel modo in cui la piattaforma legacy instrada i problemi. I team seguono quei percorsi senza chiedersi se abbiano ancora senso.
In generale, quando la governance è costruita attorno a una piattaforma anziché alle esigenze del business, raramente sopravvive intatta alla sostituzione di un sistema.
Individua gli elementi di governance legati ai sistemi legacy
Prima di riprogettare qualsiasi cosa, i team IT devono capire quali parti del framework di governance IT esistente sono essenziali e quali esistono soltanto perché la piattaforma legacy funzionava in un certo modo.
Le aree da esaminare alla ricerca di dipendenze legacy comprendono:
- Gerarchie di approvazione e punti decisionali: mappa il funzionamento attuale delle approvazioni e individua quali passaggi dipendono dalla logica del sistema anziché da una policy. Sono quelli che con maggiore probabilità verranno ricostruiti inutilmente nel nuovo ambiente e che vanno sostituiti.
- Modelli di autorizzazione e accesso: rivedi il modo in cui gli accessi vengono oggi concessi e limitati. Per esempio, se i modelli di autorizzazione rispecchiano i limiti della piattaforma e rispondono a malapena ai requisiti di sicurezza, vanno riprogettati anziché migrati.
- Requisiti di conformità e audit: individua quali controlli di conformità dipendono dagli output del sistema legacy. Hanno bisogno di una copertura equivalente nella nuova piattaforma prima che la vecchia venga dismessa.
- Aspettative e output di reporting: documenta quali report vengono prodotti e chi li utilizza, stabilendo anche se siano davvero necessari.
- Processi di gestione delle eccezioni: esamina come le eccezioni vengono oggi gestite e approvate. I processi che dipendono dai flussi di lavoro del sistema legacy potrebbero non trasferirsi in modo pulito e vanno ricostruiti con criterio.
Distinguere i controlli realmente necessari dalle implementazioni specifiche della piattaforma dà ai team IT un quadro più chiaro di ciò che deve davvero proseguire e di ciò che può essere semplificato o eliminato.
Dal controllo basato sugli strumenti alla governance basata sui risultati
La governance basata sugli strumenti si rompe ogni volta che cambia una piattaforma. La governance basata sui risultati definisce cosa deve accadere e resta coerente indipendentemente dal sistema usato per arrivarci.
Ecco alcuni esempi concreti:
- Garantire che le approvazioni avvengano, qualunque sia la piattaforma: il requisito è che le approvazioni abbiano luogo e siano documentate. Quale sistema gestisca il processo è secondario, purché il risultato sia coerente e verificabile.
- Validare i risultati di conformità anziché l’attività del sistema: i controlli di conformità devono confermare che i controlli richiesti stiano funzionando, rendendo la conformità portabile e coerente tra le piattaforme.
- Misurare le prestazioni del servizio anziché l’utilizzo degli strumenti: le metriche di performance devono riflettere la qualità con cui i servizi vengono erogati, non concentrarsi sull’uso degli strumenti.
- Far valere la responsabilità lungo tutti i flussi di lavoro: la responsabilità deve essere legata a ruoli e mansioni, non al modo in cui un sistema legacy instradava il lavoro.
Una governance definita attorno ai risultati anziché agli strumenti è più facile da mantenere, più facile da sottoporre ad audit e molto meno soggetta a rompersi quando cambiano i sistemi sottostanti.
Definisci titolarità e responsabilità durante la modernizzazione tecnologica
La governance può sgretolarsi se la titolarità non viene definita durante la modernizzazione tecnologica. Se le responsabilità non vengono riassegnate in modo esplicito, il lavoro rischia di essere duplicato in alcune aree e di non essere svolto affatto in altre.
Le best practice per definire titolarità e responsabilità durante la trasformazione della governance IT comprendono:
- Assegnare la titolarità per servizio o dominio: ogni area di servizio deve avere un responsabile nominativo per i risultati di governance.
- Definire la responsabilità in base ai risultati: la responsabilità deve essere legata ai deliverable, non al modo in cui il sistema legacy assegnava le attività. Così resta chiara anche quando i flussi di lavoro cambiano intorno a essa.
- Allineare i ruoli ai flussi di lavoro aggiornati: man mano che i processi vengono riprogettati, i ruoli vanno rivisti e aggiornati per riflettere come il lavoro scorre davvero nel nuovo ambiente. I ruoli modellati sui flussi di lavoro legacy non si adatteranno bene a un sistema modernizzato.
- Stabilire una titolarità chiara delle escalation: definisci chi è responsabile delle escalation nel nuovo ambiente prima che la transizione sia completata. I percorsi di escalation che si appoggiavano all’instradamento del sistema legacy vanno ricostruiti deliberatamente, senza dare per scontato che si trasferiscano da soli.
Una titolarità chiara durante la transizione mantiene la governance operativa anche quando l’ambiente attraversa problemi o instabilità.
Standardizza i principi di governance tra i sistemi
Una governance incoerente crea lacune difficili da individuare e ancora più difficili da colmare. Per questo è fondamentale standardizzare i principi di governance su tutti i sistemi: ti aiuta a mantenere intatto il modello di controllo mentre l’ambiente cambia intorno a esso.
Le aree chiave da standardizzare comprendono:
- Definizioni delle policy e criteri di applicazione: le policy devono significare la stessa cosa ed essere applicate allo stesso modo, indipendentemente dal sistema attraverso cui passa un flusso di lavoro.
- Modelli di controllo degli accessi: applica gli stessi standard di controllo degli accessi a tutti i sistemi coinvolti nella transizione. Modelli di autorizzazione diversi che convivono in parallelo generano confusione e aumentano il rischio di lacune nella copertura.
- Metriche e formati di reporting: definisci un insieme coerente di metriche e formati di reporting valido per tutti i sistemi. Così eviti che piattaforme diverse producano numeri diversi per la stessa misura.
- Metodi di validazione della conformità: i controlli di conformità devono produrre risultati equivalenti a prescindere dal sistema valutato. Se i metodi di validazione cambiano da piattaforma a piattaforma, le prove di audit diventano difficili da confrontare e da difendere.
La standardizzazione durante la transizione è ciò che impedisce al modello di governance di disgregarsi mentre i sistemi vengono aggiunti, sostituiti o dismessi.
Allinea i modelli di conformità e audit ai nuovi sistemi
La modernizzazione tecnologica introduce un rischio di conformità specifico che i team trascurano facilmente. Un nuovo sistema potrebbe non produrre prove di audit nello stesso modo del precedente. Se quella lacuna non viene individuata e colmata prima della dismissione del sistema legacy, la copertura di conformità viene meno senza che nessuno se ne accorga, finché un audit non la scopre in seguito.
I passaggi per allineare i modelli di conformità e audit ai nuovi sistemi comprendono:
- Individuare le prove di audit necessarie: documenta quali prove servono per ciascun requisito di conformità e da dove provengono oggi. Ottieni così un elenco chiaro di output che il nuovo sistema dovrà replicare o sostituire.
- Verificare che i nuovi sistemi sappiano generare output equivalenti: accertati che la nuova piattaforma sia in grado di produrre gli stessi tipi di prove di audit prima di spegnere il sistema legacy. In caso contrario, serve un piano per colmare la lacuna.
- Aggiornare documentazione e descrizioni dei controlli: la documentazione di conformità che fa riferimento ai processi del sistema legacy va aggiornata per riflettere il funzionamento dei controlli nel nuovo ambiente. La documentazione obsoleta è un rilievo di audit ricorrente durante le transizioni di sistema.
- Validare l’accuratezza del reporting: verifica che i report generati dal nuovo sistema siano accurati e completi prima di utilizzarli a fini di conformità. Gli errori nei primi report sono più facili da intercettare e correggere prima che entrino a far parte della documentazione di audit.
Allineare la conformità è molto più difficile a transizione conclusa. Il lavoro va svolto in parallelo alla sostituzione dei sistemi, per evitare lacune che poi sono difficili da colmare.
Introduci i cambiamenti di governance per fasi
Un framework di governance del change management funziona meglio quando i cambiamenti di governance vengono introdotti gradualmente anziché tutti insieme. Passare a un nuovo modello di governance nello stesso momento in cui si adotta un nuovo sistema aumenta il rischio che falliscano entrambi.
Le strategie efficaci per una transizione di governance per fasi comprendono:
- Far convivere in parallelo il modello di governance legacy e quello nuovo: mantieni attivi i controlli esistenti mentre introduci e validi quelli nuovi. Questo evita che si aprano lacune durante la transizione e dà ai team il tempo di adattarsi prima che il modello legacy venga dismesso.
- Aggiornare gradualmente le strutture di approvazione e reporting: modifica i flussi di lavoro di approvazione e i formati di reporting in modo incrementale, anziché sostituirli tutti in una volta. Ogni aggiornamento va validato prima di introdurre il successivo.
- Validare l’efficacia dei controlli a ogni fase: conferma che i controlli funzionino come previsto prima di passare alla fase successiva. I problemi intercettati nelle prime fasi di un rollout graduale restano circoscritti e sono più facili da risolvere rispetto a quelli scoperti dopo un passaggio completo.
- Correggere la rotta in base ai feedback operativi: raccogli i feedback dei team che usano il nuovo modello di governance e usali per affinare l’approccio prima di estenderlo ulteriormente. Una governance che funziona in teoria ma crea attrito nella pratica va corretta prima di diventare lo standard.
Un cambiamento di governance per fasi permette alle organizzazioni di modernizzarsi senza mettere a rischio la continuità del servizio durante la transizione.
Evita di ricreare gli schemi di governance legacy
Replicare gli schemi di governance legacy in un nuovo sistema è facilissimo, spesso senza nemmeno accorgersene. Quando i team sono sotto pressione durante una transizione, la scelta naturale è ricostruire ciò che già conoscono, anziché chiedersi se abbia ancora senso.
I segnali d’allarme che indicano la ricomparsa degli schemi legacy comprendono:
- Ricostruire catene di approvazione complesse: se il nuovo sistema finisce per avere lo stesso numero di passaggi di approvazione del vecchio, vale la pena chiedersi se ciascun passaggio sia davvero necessario o se sia stato trascinato per abitudine.
- Mantenere livelli di controllo superflui: i controlli aggiunti per aggirare i limiti del sistema legacy non hanno motivo di esistere in un ambiente moderno. Se un controllo non può essere ricondotto a un requisito attuale, va valutato per la rimozione.
- Replicare formati di reporting obsoleti: i report costruiti attorno agli output legacy potrebbero non rispecchiare più ciò che è utile. Ricostruirli nel nuovo sistema senza interrogarsi sul loro scopo significa conservare vecchie inefficienze in una confezione nuova.
- Conservare percorsi di escalation inefficienti: i percorsi di escalation modellati sull’instradamento del sistema legacy aggiungono spesso passaggi che rallentano la risoluzione. La transizione è il momento giusto per semplificarli, non per replicarli.
L’obiettivo della modernizzazione della governance non è spostare i controlli esistenti in un nuovo sistema. È progettare controlli che rispecchino ciò di cui l’organizzazione ha davvero bisogno oggi.
Fai in modo che la trasformazione della governance IT non lasci scoperto nulla
Sostituire un sistema legacy senza aggiornare la governance significa far girare piattaforme moderne con controlli obsoleti. La dipendenza non sparisce da sola: va individuata, riprogettata e validata come parte integrante della transizione.
Ecco perché le organizzazioni devono passare a una governance basata sui risultati. Inoltre, definire una titolarità chiara e adottare la standardizzazione dei controlli durante la modernizzazione tecnologica le aiuterà a uscire dal processo con un modello migliore e aggiornato, all’altezza delle esigenze degli ambienti IT di oggi.
Argomenti correlati:
