Definizione della fattibilità minima con Constellation Energy

Per “minima vitalità” si intende l’insieme più ristretto di capacità essenziali – persone, processi e tecnologia – necessarie per mantenere operativa un’azienda durante un grave evento di interruzione. 

Richiede decisioni da parte della leadership, allineamento tra le diverse funzioni aziendali e definizione delle priorità dei risultati, rendendola una disciplina aziendale strategica piuttosto che un semplice esercizio tecnico. 

Con interruzioni che spesso durano settimane, la “funzionalità minima” offre il percorso più rapido per aiutare a ripristinare le operazioni essenziali e ridurre l’impatto finanziario e reputazionale. 

Attraverso un’analisi interfunzionale delle dipendenze, dei flussi di lavoro e dei servizi di identità, che spesso porta alla luce sistemi critici precedentemente trascurati. 

La funzionalità minima è una responsabilità condivisa tra i reparti IT, sicurezza, operazioni, Risk, finanza e la dirigenza esecutiva. 

Per la trascrizione con indicazione dei tempi, guarda il video qui

Ciao e benvenuti a questa puntata del podcast SHIFT.

L’argomento principale è come definire la “minimum viability” (viabilità minima), rendendola il fattore più
importante per la vostra azienda.

Ciao a tutti, sono Vidya Shankaran, Field CTO di Commvault, e oggi sono qui con Ha
Hoang, CIO di Commvault Technologies, e Jay, CIO di Constellation Energy.

Grazie per essere qui con noi oggi.

Grazie per averci invitato.

Grazie per averci invitato.

Certamente.

In genere, quando si parla di operatività minima, il tempo medio di inattività registrato
nel settore, secondo le stime più ottimistiche, è di 24 giorni.

Ma per la maggior parte delle aziende, si tratta di un periodo troppo lungo da sostenere.

Non è solo questo, ma c’è anche l’impatto in termini di ricavi che può avere sulle aziende,
per non parlare del danno reputazionale che l’azienda subisce durante i 24 giorni di

inattività.

Pertanto, oggi il settore definisce la “minima viabilità” come un insieme minimo di capacità che
comprende le persone, i processi e, naturalmente, lo stack tecnologico che costituiscono quella

attività minimamente sostenibile.

E il raggiungimento di tale “viabilità minima” diventa il momento decisivo per stabilire se l’azienda
possa sopravvivere e prosperare dopo un attacco informatico.

Dato che la MV è l’argomento della nostra discussione odierna, sono lieto che Ha.

e Jay.

E la mia prima domanda per Ha sarebbe: come definiresti la “viabilità minima”
al di là di quella che probabilmente è una concezione errata diffusa nel settore, secondo cui si tratterebbe semplicemente di una lista di controllo informatica?

Come la gestiresti con una mentalità da leader?

Per me, la “funzionalità minima” riguarda meno lo stack tecnologico e più la chiarezza decisionale.

Si tratta quindi di chiedersi: qual è l’insieme minimo di capacità di cui abbiamo bisogno per far andare avanti l’azienda
mentre tutto il resto è inattivo, giusto?

È quindi una mentalità che impone disciplina, ovvero dare priorità ai risultati e non solo
all’infrastruttura, giusto?

Penso quindi che, applicando questa prospettiva, la pianificazione del Recovery diventi una discussione a livello dirigenziale
sui compromessi e non sia solo un esercizio tecnico, giusto?

E questo aiuta anche a costruire una responsabilità condivisa tra le unità aziendali, la gestione dei rischi e
, ehm, l’IT.

Ha perfettamente senso.

Ora, visto che abbiamo il piacere di averti qui con noi oggi, Jay, cosa significa “minima
operatività” per un’azienda di infrastrutture critiche come Constellation Energy, dove

i tempi di inattività non sono assolutamente un’opzione?

Beh, penso che probabilmente mi allineerei un po’ a ciò di cui stavi parlando.

È lo sport di squadra per eccellenza.

Giusto?

Voglio dire, non è una discussione che riguarda solo l’IT.

Non è una discussione con le singole unità aziendali.

Non è una discussione con il reparto sicurezza o con l’IT.

È davvero una discussione che coinvolge tutti.

Perché in realtà ciò che si intende per “azienda minimamente funzionante” è proprio questo, giusto?

Cosa significa per me continuare a far funzionare il mio core business?

Giusto?

E come si traduce tutto questo nella pratica?

Quindi, per me, penso che il messaggio più importante sia quello di lavorare in squadra, perché non è un’impresa
individuale

Nessun gruppo può farcela da solo.

Mi piace molto questa idea.

E devo chiedere questo a entrambi.

Probabilmente darei la parola prima a Ha.

Ci sono state insidie o sorprese che vi hanno colto alla sprovvista mentre stilavate l’elenco
delle risorse critiche minime indispensabili?

Sì, assolutamente.

Ce ne sono state alcune.

Alcuni dei sistemi o delle applicazioni fondamentali

che pensavamo fossero una sorta di “punto di partenza”, capisci, non c’erano affatto, giusto?

Oppure non sono stati inseriti nel nostro elenco.

E poi penso che proprio sistemi come quello di gestione delle identità, che secondo me è stato considerato quasi come un ripensamento, fossero
in realtà uno degli aspetti più critici.

E a volte, ehm, ci concentriamo principalmente su ciò che vede il cliente, ovvero le
applicazioni, giusto?

Ma se si pensa a servizi come “Jump”, alla gestione delle identità o semplicemente
ai sistemi di interdipendenza di base,

quelli sono, secondo me, quelli fondamentali.

Mi piace molto.

Vorrei aggiungere che la questione ti riguarda da vicino.

E se qualcuno ti dice che non è così, allora se lo sta inventando.

Nessuno l’ha mai fatto prima, giusto?

È la prima volta che abbiamo davvero iniziato a pensarci: abbiamo parlato per sempre di
prodotti minimamente funzionanti, ma non di aziende minimamente funzionanti.

Penso che la cosa più importante per me sia che avevamo una visione molto tradizionale del mondo, in cui c’erano
app ad alto valore commerciale, app a medio valore commerciale e app a basso valore commerciale.

E ci siamo detti: «Beh, è facile.

Ci limiteremo a recuperare le app ad alto valore commerciale e il gioco è fatto.

Quello che abbiamo imparato è che un bel po’ di quelle app a basso valore commerciale probabilmente facevano
qualcosa per alimentare o fornire qualcosa alle app ad alto valore commerciale.

Quindi ragionare in termini che sembravano molto assoluti non funziona quando si parla di “azienda
minimamente funzionante”, giusto?

Perché si sta parlando di un sistema, non di singole applicazioni.

E questa è stata la scoperta più importante per noi.

E scommetterei che lo sia stata anche per molte altre persone.

Penso che sia un’

espressione che ha appena usato, ovvero che non si tratta di un prodotto minimo funzionante, ma di un’azienda minima
funzionante.

Il che mi porta al punto successivo.

In tutto questo percorso, quanto è stata proficua la collaborazione con il vostro CISO,
soprattutto nella definizione di alcune di quelle risorse critiche e delle responsabilità relative alle decisioni di Recovery

decisioni di ripristino?

Sì, hai menzionato le risorse critiche, ma poi chi aiuta a

stabilire le priorità delle operazioni di Recovery?

Sì.

Caspita, come ho detto, è un lavoro di squadra, ma serve anche un arbitro.

Quindi penso che, sotto molti aspetti, il CIO e il CSO agiscano davvero un po’ come un arbitro
in quel caso, perché quando si inizia a simulare lo scenario e si osserva, abbiamo avuto un ottimo partner che

ci ha aiutato con WWT e ci ha davvero aiutato a riflettere su tutto questo e ad affrontare
sia il processo tecnico, sia i

direi procedurali, perché alla fine ci si rende conto che ognuno ritiene
che la propria materia sia la più importante.

Quindi penso che la cosa più importante su cui il CIO e il CISO debbano concentrarsi sia come assumere
il ruolo di giudice e giuria, ma anche come assicurarsi di concentrarsi su, come hai menzionato,

alcune tecnologie davvero fondamentali e di base, come l’identità e la rete, giusto?

Senza quelle, nulla funziona.

Quindi si tratta anche di aiutare le persone a comprendere

quello pezzo del puzzle.

Ecco, secondo me il loro ruolo è proprio questo, giusto?

Mi piace molto.

A te la parola, Ha.

In tutto questo, tornando a quanto detto da Jay sul fatto che si tratti di un lavoro di squadra, hai incontrato qualche
difficoltà nel mettere a punto il business case mentre lo presentavi, probabilmente, al

, al team di gestione dei rischi e a quello di conformità?

E quali sono stati alcuni dei pregiudizi che si erano già insinuati in quei

settori aziendali e che hai dovuto sfatare prima di poter convincere i team a sostenere il caso d’uso relativo
alla “minima fattibilità”?

Nel riunire quei team, ovviamente, penso che l’approccio della “fattibilità minima” dovesse
essere diverso, giusto?

Doveva essere in termini aziendali e non nel gergo di Backup and Recovery, giusto?

Quindi, ad esempio, per la finanza si tratta, come sapete, di proteggere la continuità dei ricavi.

Per i team che si occupano di rischio, si tratta di limitare l’esposizione.

E poi, per i team operativi, si tratta di garantire l’integrità dei clienti.

E quindi penso che quando i team e le funzioni si riconoscono nella strategia della “minima
viabilità”, è allora che si crea l’allineamento.

E per quanto riguarda i malintesi, penso che il più grande sia quello di credere che la “minima
viabilità” equivalga a uno sforzo minimo.

Come se si trattasse di abbassare gli standard o di accettare un recupero parziale.

È un’ottima osservazione.

La realtà è che è esattamente il contrario, giusto?

Ehm… Si tratta davvero di disciplina e, ehm, di concentrarsi su ciò che realmente, ehm, favorisce la continuità e
la resilienza quando ogni minuto è fondamentale, giusto?

E poi penso che l’altro malinteso sia che si tratti di una questione puramente tecnologica, giusto?

Quindi i consigli di amministrazione e i CIO come noi si aspettano una lista di controllo o uno schema architettonico, ma in
realtà si tratta di una discussione sulla strategia aziendale, giusto?

Su come le aziende stabiliscano effettivamente le priorità in termini di valore sotto pressione, cosa decidano di proteggere e
perché.

Adoro quello slogan che hai appena citato, ovvero “come dare priorità al valore
aziendale sotto pressione”.

Probabilmente…

lo metterei in grassetto, lo evidenzierei e lo sottolineerei all’infinito, perché questa è la natura fondamentale della
definizione stessa di MVC.

Il che mi porta al punto successivo.

Abbiamo parlato di strategia.

Abbiamo parlato di come sia un lavoro di squadra.

Ma quali sono i KPI chiave?

Come si fa a quantificarli e misurarli?

Non si tratta certo delle classiche metriche tangibili, vero?

O mi sfugge qualcosa?

Sono l’RPO e l’RPTO i parametri su cui vi basate?

Quali sarebbero le unità di misura del successo basate sull’MVC?

Penso che, per quanto mi riguarda, inizierò forse concentrandomi meno sugli indicatori, per poi magari passare a quelli.

Ma per me è importante assicurarmi che il sistema non venga utilizzato solo in caso di crisi.

Penso che sia un errore comune sedersi lì e dire: “Faremo questa esercitazione e
avremo questo sistema”.

Da parte nostra, abbiamo trasferito

tutti i nostri backup and Recovery su Commvault perché volevamo che le persone utilizzassero questo sistema ogni
giorno.

Quindi volevamo assicurarci che sapessero come utilizzare il sistema, come farlo funzionare,
come gestirne tutti i dettagli perché, sai, stiamo parlando di situazioni sotto pressione,

giusto?

Non è proprio il momento giusto per provare qualcosa di nuovo.

Quindi questa è una delle cose.

E vorrei aggiungere qualcosa all’ultimo punto di cui stavi parlando, che riguardava ancora il DR,
giusto?

Penso che l’altro malinteso comune sia: “Abbiamo già il DR”.

A cosa mi serve questo?

Giusto?

Voglio dire, ce l’ho già.

E penso che

ancora una volta, se ci pensate bene, il DR sia in qualche modo un modo di pensare ormai superato, giusto?

Ha una mentalità, in mancanza di un termine migliore, un po’ come un buco nel terreno, giusto?

Se non ho questa cosa, cosa succede?

Beh, non credo che nessuno dei nostri mondi esista in meno di altre cinque cloud o in meno di altri
cinque mondi.

Quindi penso davvero che si tratti, in primo luogo, di cambiare la mentalità e, in secondo luogo, di modificare
le operazioni in modo da non limitarsi ad agire solo in caso di crisi.

Ecco come la vedo io.

Mi piace molto.

Sono totalmente d’accordo.

Sì, ovviamente, sai, guardiamo a metriche quantitative e qualitative, sai, indicatori.

E, sai, tecnicamente, tutti misurano RPO e RTO, giusto, e
la percentuale di, sai, dati di backup integri e cose del genere.

Ma penso che l’aspetto su cui mi concentro e che tengo sotto controllo sia la rapidità con cui riusciamo a prendere decisioni con sicurezza
sotto pressione, giusto?

Perché penso che la Readiness non riguardi solo la velocità con cui siamo in grado di recuperare o ripristinare, ma anche la
rapidità con cui possiamo fidarci dei dati e del sistema che stiamo ripristinando.

Quindi, in che misura tutto questo si riduce effettivamente all’effettività dei test?

A tutto.

Moltissimo.

Sì.

Voglio dire, è sempre così che va a finire, giusto?

Preparazione, pratica.

Senti, nel nostro mondo ci alleniamo tantissimo.

Ci alleniamo in tutto ciò che facciamo.

Perché vuoi assicurarti che, quando ne avrai davvero bisogno o quando sarai sotto pressione,
tu sia in grado di metterlo in pratica.

E penso che in questo caso non sia diverso.

Forse la buona notizia, o la cattiva notizia, è che ultimamente abbiamo avuto tutti molte occasioni per esercitarci in questo
, giusto?

Che si tratti di interruzioni del servizio cloud o di problemi causati dai provider, giusto?

Abbiamo avuto l’occasione di esercitarci in questo.

E l’altra cosa che vorrei dire è che bisogna cogliere queste opportunità per dire:
non abbiate paura di sfruttare il sistema che avete a disposizione, giusto?

Avete creato un sistema, usatelo.

Come posso utilizzarlo

per tornare operativi più rapidamente?

Come lo uso, che si tratti della Recovery di un particolare cloud o di un incidente in
corso, giusto?

Penso che si tratti di guardare avanti e utilizzarlo, senza metterlo da parte pensando: «Oh
, devo occuparmi del DR?

“Devo proprio farlo?”

Abbiamo tutti questa mentalità.

Non basta configurarlo e poi non pensarci più.

Giusto, esattamente.

Insomma, è lì, usatelo.

Sì, ed è sicuramente un aspetto su cui le organizzazioni devono lavorare.

Non è un

un'attività che si fa una volta sola.

È un processo in continua evoluzione che va costantemente migliorato.

E, diciamoci la verità, è anche in continua crescita, giusto?

I dati e tutto il resto non stanno rallentando.

Probabilmente, per quasi tutti, il prodotto che avete lanciato all’inizio era solo una frazione di quello che
avete ora.

Questo cambia davvero le carte in tavola, vero?

Esatto.

Il che mi porta alla domanda successiva, quella più cruciale, che era anche la più difficile.

È stata l’esecuzione tecnica o il cambiamento culturale?

Direi il cambiamento culturale, senza alcun dubbio.

Il lavoro tecnico è complesso, ma risolvibile.

È possibile automatizzare il processo e superarlo con una serie di test.

Ma la parte più difficile è il cambiamento di mentalità, dal considerare, credo, il Recovery come un compito dell’IT alla
consapevolezza che la resilienza è in realtà una

capacità aziendale condivisa.

Sì.

Sì.

Voglio dire, sono d’accordo.

Direi che la parte tecnica è facile perché ho un team tecnico straordinario e loro
fanno sembrare tutto davvero facile.

Ma penso davvero che la tecnologia sia una questione risolvibile, giusto?

Sono solo uno e zero e possiamo risolvere tutto.

Il problema è che questa discussione è sempre stata: «Ehi, IT, fate il vostro lavoro e fateci sapere quando
avete finito», giusto?

Ma ormai non è più così.

E questo, per me, è il cambiamento più grande: ora bisogna riunire tutti i leader aziendali in
una stanza e dire: “Ehi, dobbiamo parlare di Recovery”.

E non si tratta solo di: “Ehi, fateci sapere quando avete finito, IT”.

Ed è proprio questo il cambiamento culturale.

Sono pienamente d’accordo.

Penso che la consapevolezza di come la sostenibilità imponga conversazioni un po’ scomode sulla
definizione delle priorità, giusto?

Cosa deve davvero accadere nelle prime 24 ore rispetto a ciò che può aspettare.

Ed è qui che, secondo me,

stiamo chiedendo ai leader aziendali, in sostanza, di fare delle scelte in tempo reale, e quelle sono
le discussioni difficili.

Sì.

No, ha perfettamente senso.

E soprattutto, come hai sottolineato tu, se dovessi chiedere a ogni dirigente aziendale, ti
risponderebbe: «Il mio AppStack è importante».

Tutto è importante.

Io sono il più importante.

Sì, assolutamente.

Quindi, dopo aver vissuto

e l’esperienza di aver sviluppato il tuo MVC, e ovviamente, come abbiamo appena discusso, si
tratta di un processo in continua evoluzione.

Ma quali sono i punti chiave, le “cicatrici di guerra” che vorresti
assicurarti di condividere con i tuoi colleghi, in modo che non si imbattano nelle stesse sfide mentre stanno

sviluppano il proprio MVC?

Direi di esercitarsi nel Recovery, come se fosse il giorno della partita, giusto?

Perché non si può sviluppare la resilienza nel bel mezzo di una crisi.

Si costruisce con le ripetizioni che si fanno prima.

Perfetto.

Penso che per me, e tu ne hai parlato un paio di volte e non lo sottolineerò mai abbastanza,
sia il livello fondamentale di base.

Penso che tradizionalmente non ci venga in mente che potremmo non disporre di elementi fondamentali come
Active Directory, la rete e tutto il resto, che ora sono definiti dal software

rispetto a qualsiasi altro momento.

E penso che questo sia il cambiamento più grande da rispettare e da mettere davvero in pratica

e di comprendere: come si presenta la situazione quando devo ripristinare il mio sistema di autenticazione di base prima
che qualcuno del mio team possa svolgere qualsiasi attività?

Ed è proprio questo che dimentichiamo sempre.

Il personale IT non può svolgere alcun lavoro senza di essa.

E penso che questa sia la vera prova del fuoco.

E, francamente, penso che sia una delle cose che
Commvault fa meglio di chiunque altro: il Recovery a livello di foresta di Active Directory, che è fondamentale ed è stato uno dei

principali fattori di differenziazione che ci hanno spinto a scegliere questo prodotto.

Grazie.

Grazie per aver condiviso questa riflessione.

E prima di salutarvi, qual è la battuta finale, quella
davvero incisiva, con cui vorreste congedarvi?

Caspita, credo di averla appena detta.

Allenatevi per la Recovery come se fosse il giorno della partita.

Perfetto.

Mi piace tantissimo.

Per me è uno sport di squadra.

E non puoi semplicemente affidare tutto questo al tuo team IT e dire: «Ehi, fatemi sapere quando avete finito».

È uno sport di squadra in cui è necessario che tutti i presenti partecipino alla discussione.

Perfetto.

Grazie mille per essere stato con noi oggi e per aver condiviso le tue riflessioni.

Sono davvero preziose.

E a tutti i nostri spettatori che ci seguono virtualmente: se desiderate approfondire i concetti relativi
alla «minima fattibilità», date un’occhiata al nostro rapporto di analisi di Giga Om, che tratta

approfondisce il tema della “minima fattibilità”, disponibile su Commvault.com.

Grazie.