Definizione della fattibilità minima con Constellation Energy

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

Richiede decisioni da parte della dirigenza, coordinamento tra le diverse funzioni e definizione delle priorità in termini di risultati, il che la rende una disciplina aziendale strategica piuttosto che un semplice esercizio tecnico. 

Con interruzioni che spesso durano settimane, la “minima operatività” rappresenta il modo più rapido per contribuire 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à, spesso si individuano sistemi critici che in precedenza erano stati trascurati. 

La redditività minima è una responsabilità condivisa tra i reparti IT, sicurezza, operazioni, gestione dei rischi, finanza e la dirigenza. 

Per la trascrizione con l’indicazione dei tempi, guarda il videoqui

Salve e benvenuti a questa puntata del podcast SHIFT.

Il tema centrale è come stabilire la fattibilità minima, rendendola il fattore chiave
per il successo della 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 averci ospitato qui 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 sopportare.

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

inattività.

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

attività economicamente sostenibile.

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

Visto che la MV è l’argomento della nostra discussione di oggi, 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 checklist informatica?”

Come la gestiresti con una mentalità da leader?

A mio avviso, la “minima viabilità” riguarda meno lo stack tecnologico e più la chiarezza nel processo decisionale.

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

Si tratta quindi di una mentalità che richiede disciplina, ovvero dare priorità ai risultati e non solo
all’infrastruttura, giusto?

Ritengo quindi che, adottando questa prospettiva, la pianificazione del piano di Recovery diventi una questione da affrontare a livello dirigenziale
sui compromessi e non sia solo un esercizio tecnico, giusto?

E questo contribuisce anche a creare una responsabilità condivisa tra le unità aziendali, la gestione dei rischi e
, ehm, l’informatica.

Ha perfettamente senso.

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

I tempi di inattività non sono proprio un’opzione?

Beh, credo che probabilmente sarei un po’ d’accordo con quello di cui stavi parlando.

È lo sport di squadra per eccellenza.

Giusto?

Insomma, non è una questione che riguarda solo l’IT.

Non si tratta di una discussione con le singole unità aziendali.

Non si tratta di una discussione con il reparto sicurezza o con l’IT.

È davvero una discussione che riguarda tutti.

Perché, in fondo, ciò che si intende per “azienda che funzioni a malapena” è proprio questo, giusto?

Cosa significa per me continuare a mandare avanti la mia attività principale?

Giusto?

E come si traduce tutto questo nella pratica?

Quindi, secondo 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.

E devo chiederlo a entrambi.

Probabilmente darei la parola prima a Ha.

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

Sì, assolutamente.

Ce ne sono state alcune.

Alcuni dei sistemi o delle applicazioni fondamentali

che pensavamo fossero una sorta di “posta in gioco”, capisci, di certo non c’erano, 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 più che altro un ripensamento, fossero
in realtà piuttosto critici.

E a volte, ehm, ci concentriamo soprattutto 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 nel suo complesso ti riguarda.

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

Nessuno l’ha mai fatto prima, vero?

È la prima volta che abbiamo davvero iniziato a rifletterci sopra: ne abbiamo parlato per un’eternità di
prodotti che funzionano a malapena, ma non di aziende che funzionano a malapena.

Credo 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 selezionare le app con un elevato valore commerciale e il gioco è fatto.

Quello che abbiamo imparato è che molte di quelle app con scarso valore commerciale probabilmente servivano a
qualcosa che possa alimentare o fornire qualcosa all’app ad alto valore commerciale.

Quindi ragionare in termini che sembravano molto assoluti non funziona quando si parla di
“un’azienda che funzioni almeno un po’”, giusto?

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

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

E scommetto che lo sia stato anche per molte altre persone.

Credo che sia una

l’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 fondamentali e delle responsabilità relative alle decisioni relative al Recovery

decisioni relative al ripristino?

Sì, hai parlato delle risorse fondamentali, ma poi chi aiuta a

stabilire le priorità delle operazioni di Recovery?

Già.

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 il WWT e ci ha davvero aiutato a riflettere su tutto questo e ad affrontare
sia il processo tecnico, sia i

direi di natura procedurale, perché alla fine si scopre che ognuno ritiene
che la propria materia sia la più importante.

Quindi penso che l’aspetto più importante su cui il CIO e il CISO debbano concentrarsi sia come assumere
il ruolo di giudice e giurato, ma anche come fare in modo di concentrarsi su, come hai detto tu,

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

Senza quelle, non funziona nulla.

Quindi si tratta anche di aiutare le persone a capire

quel 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 quelle

settori aziendali e che hai dovuto sfatare prima di riuscire a convincere i team a sostenere il caso di studio sulla
“minima fattibilità”?

Nel riunire quei team, ovviamente, ritengo che l’approccio al concetto di “minima fattibilità” dovesse
È diverso, vero?

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

Quindi, ad esempio, nel settore finanziario si tratta, come sapete, di garantire 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à”, è in quel momento che si crea l’allineamento.

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

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

È un’ottima osservazione.

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

Ehm… Si tratta davvero di disciplina e di concentrarsi su ciò che favorisce realmente 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 checklist o uno schema architettonico, ma in
In realtà si tratta di una discussione sulla strategia aziendale, giusto?

Su come le aziende stabiliscano effettivamente le priorità in termini di valore quando si trovano 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
la definizione stessa di MVC.

Il che mi porta al punto successivo.

Abbiamo parlato di strategia.

Abbiamo parlato di come si tratti di 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?

Mi sfugge forse qualcosa?

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

Quali sarebbero le unità di misura del successo basate sul modello MVC?

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

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

Credo che sia un malinteso comune stare lì seduti a dire: “Faremo questa esercitazione e
“avremo questa cosa”.

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 trovarsi sotto pressione,

giusto?

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

Quindi questa è una delle cose.

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

Credo che l’altro malinteso comune sia: «Abbiamo già il DR».

A cosa mi serve?

Giusto?

Insomma, ce l’ho già.

E penso che

Ancora una volta, se si pensa al DR, si tratta in un certo senso di una mentalità del passato, giusto?

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

Se non ho questa cosa, cosa succede?

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

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

Ecco come la vedo io.

Mi piace molto.

Sono pienamente d’accordo.

Sì, ovviamente, sai, analizziamo metriche quantitative e qualitative, insomma, gli indicatori.

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

Ma credo 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, vero?

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

Quindi, in che misura tutto ciò si traduce effettivamente nell’effettiva applicazione dei test?

Tutto.

Moltissimo.

Sì.

Insomma, finisce sempre così, no?

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,
che tu riesca a 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 modo di fare pratica in questo.

E l’altra cosa che vorrei dire è che bisogna cogliere queste occasioni 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 da un determinato cloud o di un incidente in
corso, giusto?

Credo che si tratti di guardare avanti e di 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, eccola lì, usatela.

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

Non è una

un esercizio che si fa una volta sola.

Si tratta di un processo in continua evoluzione che va costantemente migliorato.

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

I dati e tutto il resto non accennano a rallentare.

Probabilmente, per quasi tutti, il prodotto che avete lanciato all’inizio era solo una piccola parte di quello che
avete oggi.

Questo cambia davvero le carte in tavola, vero?

Esatto.

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

È stata la realizzazione tecnica o il cambiamento culturale?

Direi il cambiamento culturale, senza alcun dubbio.

Il lavoro tecnico è complesso, ma risolvibile.

È possibile automatizzare e testare ogni fase del processo.

Ma la parte più difficile è il cambiamento di mentalità, ovvero passare dall’idea che il Recovery sia un compito dell’IT a
che la resilienza sia in realtà una

capacità aziendale condivisa.

Sì.

Sì.

Insomma, sono d’accordo.

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

Ma penso davvero che il problema della tecnologia sia risolvibile, no?

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 più semplicemente di: «Ehi, fateci sapere quando avete finito, IT».

Ed è proprio questo il cambiamento culturale.

Sono pienamente d’accordo.

Credo che la consapevolezza della necessità di agire richieda conversazioni un po’ scomode sul
definizione delle priorità, giusto?

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

Ed è proprio qui che, secondo me,

In sostanza, stiamo chiedendo ai dirigenti aziendali di prendere decisioni in tempo reale, e queste sono
le conversazioni difficili.

Sì.

No, ha perfettamente senso.

E soprattutto, come hai sottolineato tu, se dovessi chiedere a ogni dirigente aziendale, ti
risponderebbero che il proprio AppStack è importante.

Tutto è importante.

Io sono il più importante.

Sì, assolutamente.

Quindi, dopo aver vissuto

e l’esperienza di sviluppo del tuo MVC – e, naturalmente, come abbiamo appena visto, si
Si tratta di un processo in continua evoluzione.

Ma quali sono i punti chiave, le “cicatrici di guerra” che vorresti
assicurati di condividerlo con i tuoi colleghi, in modo che non si trovino ad affrontare le stesse difficoltà mentre stanno

sviluppano il proprio MVC?

Direi di allenarsi per il Recovery come se fosse il giorno della partita, giusto?

Perché non è possibile sviluppare la resilienza in una situazione di crisi.

Si costruisce sulla base delle ripetizioni fatte in precedenza.

Perfetto.

Credo che per me, e tu l’hai accennato un paio di volte e non lo sottolineerò mai abbastanza,
sia il livello fondamentale di base.

Credo che, di solito, 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

più di quanto non lo sia mai stato.

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

e di capire: qual è la situazione quando devo ripristinare la mia autenticazione di base prima
che i miei collaboratori possano svolgere qualsiasi attività?

Ed è proprio questo che ci 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 è imbattibile: il Recovery a livello di foresta di Active Directory, che è fondamentale ed è stato uno dei

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

Grazie.

Grazie per aver condiviso questa riflessione.

E prima di lasciarvi andare, qual è la battuta finale, quella
davvero incisiva, con cui vorreste salutarci?

Caspita, mi sembra di averlo appena detto.

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

Perfetto.

Mi piace tantissimo.

Per me è uno sport di squadra.

E non puoi semplicemente lasciare tutto questo al tuo team IT e dire: «Ehi, fatemi sapere quando è pronto».

È 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 di
prodotto minimo funzionante (MVP), date un’occhiata al nostro rapporto di analisi di Giga Om, che tratta

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

Grazie.