Nel mese di aprile 2018, TSB Bank ha tentato di migrare 1.3 miliardi di record di clienti da una piattaforma di elaborazione legacy a un nuovo sistema costruito dalla sua azienda madre spagnola. La migrazione non ha rappresentato interdipendenze non documentate tra le strutture dati. Entro poche ore, 1,9 milioni di clienti sono stati bloccati dai loro conti. Alcuni hanno visto i bilanci degli altri clienti. I casi delle frodi sono scesi. L'estrazione è durata settimane.
Il costo totale: 330 milioni di sterline in bonifica, compensazione e ricavi persi (L'Indipendente). Il CEO Paul Pester si dimise sotto pressione (BBC News). Il Comitato del Tesoro del Regno Unito ha lanciato un'inchiesta parlamentare. L'Autorità per il controllo finanziario ha ceduto 48,65 milioni di sterline in multe (Reuters). Ottomila clienti hanno lasciato la banca.
Il consiglio di TSB non ha afferrato completamente il rischio fino a quando non è diventato un titolo. Questo è lo scenario che questa guida ti aiuta a prevenire. Il vostro consiglio non deve capire come funziona l'infrastruttura di transazione legacy. Hanno bisogno di capire cosa succede quando fallisce, che cosa costa fare nulla, e che cosa un investimento strutturato sembra. Questo articolo ti dà la lingua, i dati e un modello di presentazione pronto all'uso per fare quel caso.
Che cosa il Consiglio realmente interessa
I consigli non pensano nei linguaggi di programmazione. Pensano in tre categorie: responsabilità, resilienza e agilità. Ogni argomento che fai ha bisogno di atterrare in uno di quei secchi.
Esposizione di responsabilità e regolamentazione
Gli organismi normativi trattano sempre più i guasti del sistema come guasti della governance. La multa di 48,65 milioni di sterline di TSB non è dovuta a un bug del software, ma perché la FCA ha scoperto che la banca "ha pianificato correttamente la migrazione IT" e ha mancato "sistemi di gestione del rischio adeguate" (BBC News). Nell'ambito di strutture come il DORA nell'UE e le regole di resilienza operativa della FCA nel Regno Unito, i consigli di amministrazione svolgono una responsabilità personale per il rischio tecnologico. Un sistema che funziona sul codice che nessuno può mantenere non è un problema tecnologico. È una responsabilità fiduciaria.
I moderni standard di segnalazione del rischio di bordo rafforzano questo cambiamento. SecondoL'analisi 2025 di VComply delle aspettative del Consiglio, i direttori ora si aspettano rapporti di rischio che sono "chiari, previsionali e direttamente legati all'impatto aziendale". Se i vostri sistemi legacy non appaiono nella vostra impresa registro di rischio con esposizione finanziaria quantificata, avete un gap di governance.
Resilienza operativa e Rischio delle entrate
I sistemi di elaborazione core gestiscono le transazioni che generano ricavi. Quando falliscono, le entrate si fermano. AGuida alla valutazione del rischio CTOdocumenti che un 100-millisecondo aumento della latenza piattaforma e-commerce può ridurre i tassi di conversione del 7%. Per l'elaborazione di sistemi migliaia di transazioni all'ora, anche il degrado minore comporta un costo misurabile. Un outage completo è catastrofico.
L'onere di manutenzione compone il problema. Le organizzazioni che gestiscono l'infrastruttura di transazione legacy spendono fino all'80% del loro budget IT per mantenere i sistemi esistenti in esecuzione, lasciando la capacità minima per le nuove capacità (CTO Legacy Risk Guide). Non e' una denuncia tecnologica. Questo è un problema di ripartizione dei capitali che il consiglio può vedere su un bilancio.
Agility competitiva
Ogni caratteristica che il vostro team di ingegneria non può costruire perché stanno mantenendo il codice di elaborazione delle transazioni di 40 anni è una caratteristica la vostra nave concorrente prima. SecondoCTO Legacy Risk Guide, 62% delle organizzazioni continuano ad operare software obsoleto nonostante i rischi noti. Il motivo principale del ritardo? " Funziona ancora" (citato del 50% delle organizzazioni). Quella frase è la frase più costosa nell'IT aziendale. Il sistema funziona fino a quando non lo fa, e il costo del fallimento cresce ogni trimestre l'organizzazione ritarda.
I dati di cui hai bisogno prima di entrare
Una presentazione senza numeri duri è una conversazione. Una presentazione del consiglio con numeri duri è una decisione. Prima di richiedere una riunione, raccogliere questi sei punti di dati:
| Metrico | Perché il Consiglio Cura |
|---|---|
| Età del sistema (anni di produzione) | Stabilisce l'entità della responsabilità. I sistemi federali contrassegnati dalla gamma GAO da 23 a 59 anni. |
| Ultima data di cambiamento importante | Rivela quanto tempo il sistema è stato in modalità manutenzione. Nessun cambiamento = nessuno disposto a toccarlo. |
| Personale che può mantenere | Il 71% delle squadre mainframe è già sotto controllo. Se il tuo numero è a cifre singole, la scheda deve sapere. |
| Termine di pensionamento del personale | Il GAO ha scoperto che alcuni esperti che hanno mantenuto i sistemi federali critici sono "ritirati o deceduti". Mappa la tua linea temporale. |
| Costo per incidente (ultimi 3 anni) | Converte il rischio astratto in una cifra del dollaro che il CFO può convalidare. |
| Costo di fermo stimato all'ora | Ancora la matrice di rischio. Se il sistema elabora $1.2M all'ora, un'interruzione di 4 ore è $4.8M. |
Se non riesci a raccogliere tutti e sei, inizia con quello che hai. I dati incompleti presentati onestamente sono più credibili delle stime lucidate. L'obiettivo è quello di spostare la conversazione da "pensiamo che questo sia rischioso" a "qui è ciò che ci costa".
Cosa non dire (e cosa dire invece)
La lingua che usi determina se il consiglio ascolta una richiesta di tecnologia o un rischio di business. Ogni termine nella colonna di sinistra attiva il filtro "questo è un problema IT". La colonna di destra ridefinisce ogni concetto in lingua che si collega a responsabilità, entrate e posizione competitiva.
| Invece di dire... | Dillo. |
|---|---|
| "COBOL" | "Core sistemi di elaborazione delle transazioni (da 40 a 60 anni)" |
| "Debito tecnico" | "Responsabilità operativa differita" |
| "Unit test coverage" | "Rilevamento di guasti Validated" |
| "Stato ferito" | "Interdipendenze senza documenti" |
| "Modernizzazione" | "Investimento di resilienza operativa" |
| "Refactoring" | "Ridurre singoli punti di fallimento" |
| "Legacy migrazione" | "Trasferimento controllato alle infrastrutture supportate" |
| "Code freeze" | "Sistema che non può accettare in modo sicuro i cambiamenti" |
| "Fine della vita" | "Operare oltre il supporto del fornitore senza rete di sicurezza" |
| "Sprint velocity" | "velocità di consegna del prodotto" |
Praticare questo vocabolario prima dell'incontro. Un singolo slittamento in gergo dà il permesso del consiglio di classificare la vostra richiesta come "IT vuole più soldi" piuttosto che "l'azienda ha una responsabilità non decisa."
Lo scorrevole della matrice del rischio
Se la vostra presentazione ha una diapositiva che guida una decisione, questo è tutto. La matrice di rischio traccia ogni sistema di nucleo su due assi: probabilità di fallimento (basso ad alto) e impatto aziendale se si verifica un guasto (basso a catastrofico). Il risultato è una griglia a quattroquadri.
Come segnare probabilità di fallimento. Assegna ad ogni sistema un punteggio basato su: età della base di codice, numero di persone che possono mantenere, frequenza di incidenti recenti, e se ha conosciuto vulnerabilità di sicurezza. Il GAO ha scoperto che 7 di 11 sistemi federali critici hanno conosciuto vulnerabilità di sicurezza (FedGov oggi). Se i vostri sistemi condividono queste caratteristiche, la probabilità non è teorica.
Come segnare l'impatto aziendale. Utilizzare la cifra di fatturato per ora per ogni sistema. Livello sull'esposizione a fine normativa, sui costi di notifica delle violazioni e sulle stime dei danni reputazionali. Un sistema che elabora payroll per 50.000 dipendenti ha un profilo di impatto diverso da un cruscotto di report.
Cosa atterra nel quadrante in alto a destra. I sistemi con elevata probabilità di fallimento e impatto catastrofico delle imprese richiedono un'azione immediata. Questi sono i sistemi che il consiglio deve finanziare prima. Tutto il resto può essere sequenziato in fasi successive. Questo quadrante e' la tua domanda.
Presentare questa diapositiva a colori. Rosso per il quadrante in alto a destra (azione immediata), ambra per i quadranti adiacenti (azione pianificata), verde per sistemi a bassa probabilità / basso impatto (monitor). I membri del consiglio elaborano il rischio visivo in modo intuitivo.
Le guide visive di matrice del rischio rappresentano priorità d'azione.
Obiezioni di manipolazione
Ogni consiglio solleva le stesse tre obiezioni. Preparatevi a tutti loro.
" Funziona ancora."
Questa è l'obiezione più comune e più pericolosa. SecondoCTO Legacy Risk Guide, 50% delle organizzazioni ritardare l'azione perché "il sistema funziona ancora". La risposta: "Il sistema funziona, ma non può essere cambiato in modo sicuro, non può essere impiegato, e non può essere assicurato contro il fallimento. Un edificio con una fondazione incrinata è ancora in piedi. Questo non significa che sia sicuro occuparsi."
Torna qui con i dati degli incidenti. Quante mancanze negli ultimi 24 mesi? Quanto tempo ha richiesto l'ultimo outage non pianificato per risolvere? Qual era la causa principale, ed è stata fissata? Se le risposte sono scomode, sono esattamente ciò che il consiglio ha bisogno di sentire. Per il contesto della crisi del personale di fronte a questo rischio, i dati della forza lavoro sono inequivocabili.
"È troppo costoso."
Questa obiezione presuppone che l'alternativa alla spesa stia salvando. Non lo è. L'alternativa è spendere di più, lentamente, senza riduzione del rischio. Le organizzazioni consumano già fino all'80% dei loro bilanci IT sulla manutenzione legacy (CTO Legacy Risk Guide). I sette sistemi di eredità critica non fissi del governo federale degli Stati Uniti consumano 337 milioni di dollari all'anno in costi operativi (FedScoop).
Incorniciare l'investimento come una riduzione dei costi netti oltre 3-5 anni, non una spesa aggiuntiva. Mostra al consiglio un confronto: costo di manutenzione annuale corrente più costo incidente previsto rispetto al costo ammortizzato dell'investimento di resilienza più la manutenzione continua ridotta. I numeri quasi sempre favoriscono l'azione.
"Abbiamo provato prima e abbiamo fallito."
Questa è una preoccupazione legittima. I dati lo confermano: il 74% dei progetti di modernizzazione legacy viene avviato ma mai completato (CTO Legacy Risk Guide). La risposta non è quella di respingere la preoccupazione, ma di spiegare ciò che sarà diverso. I fallimenti precedenti di solito condividono cause comuni: hanno cercato di sostituire tutto in una volta, non hanno avuto sponsorizzazioni esecutive, o non hanno definito pietre miliari misurabili.
La tua proposta si rivolge a tutti e tre. La fase 1 mira solo ai sistemi a più alto rischio (il quadrante superiore destro). Il consiglio stesso fornisce la supervisione della governance attraverso le recensioni trimestrali. Ogni pietra miliare ha un risultato misurabile. Non si tratta di una ripetizione degli sforzi passati. È un investimento strutturato e limitato. Per una panoramica tecnica di ciò che comporta una migrazione, compreso l'approccio incrementale che riduce il rischio di consegna, vedere la nostra guida tecnica.
Cosa stai chiedendo
Non entrare nell'aula chiedendo "budget per fissare il vecchio codice". Questo inquadramento garantisce il rifiuto. Incorniciare invece la domanda in tre parti:
- Riduzione del rischio. "Stiamo richiedendo un investimento di $X per ridurre una responsabilità operativa annuale attualmente stimata a $Y. Questa responsabilità include i costi di fermo programmati, l'esposizione fine regolamentare, l'aumento della spesa di manutenzione, e il costo di opportunità di capacità ingegneristica bloccato nella manutenzione legacy."
- Sblocco di capacità. "Questo investimento libererà lo Z% della nostra capacità ingegneristica attualmente consumata dalla manutenzione legacy, permettendoci di fornire [specifiche capacità di prodotto o integrazioni] attualmente bloccate."
- L'analogia dei premi assicurativi. Le commissioni comprendono l'assicurazione. Non si acquista l'assicurazione antincendio perché il vostro edificio è in fiamme. Si acquista perché il costo del premio è una frazione del costo della perdita. Un investimento di resilienza operativa funziona allo stesso modo. L'investimento annuale è una frazione dell'esposizione che elimina. Se il consiglio non avrebbe funzionato senza assicurazione di proprietà, non dovrebbero operare senza copertura di resilienza per i sistemi che generano il loro reddito.
Sii specifico. "Stiamo chiedendo per 2,4 milioni di dollari su 18 mesi per ridurre un'esposizione di rischio annuale di 12 milioni di dollari e sbloccare 3 milioni di dollari nella capacità di sviluppo del prodotto" è una proposta finanziabile. "Dobbiamo modernizzare i nostri sistemi" non è.
La vostra tavola non ha bisogno di capire l'architettura. Devono capire l'esposizione. Date loro i dati, parlate la loro lingua e mostrate loro un percorso graduale, finanziato e misurabile. Il rischio di inazione non è più teorico. L'unica domanda è se la vostra organizzazione lo affronta sulla propria linea temporale o sulla linea temporale dettata dalla successiva estrazione, dalla successiva revisione, o dalla successiva lettera di pensionamento.