Ermittlung der minimalen Lebensfähigkeit – mit Constellation Energy

Die Mindestbetriebsfähigkeit bezieht sich auf die kleinste Menge an wesentlichen Fähigkeiten – Mitarbeiter, Prozesse und Technologie –, die erforderlich sind, um den Geschäftsbetrieb während einer größeren Störung aufrechtzuerhalten. 

Sie erfordert Führungsentscheidungen, funktionsübergreifende Abstimmung und die Priorisierung von Ergebnissen, was sie zu einer strategischen Unternehmensdisziplin und nicht zu einer rein technischen Aufgabe macht. 

Da Ausfälle oft Wochen andauern, bietet die Mindestfunktionsfähigkeit den schnellsten Weg, um wesentliche Betriebsabläufe wiederherzustellen und finanzielle sowie rufschädigende Auswirkungen zu minimieren. 

Durch eine funktionsübergreifende Analyse von Abhängigkeiten, Arbeitsabläufen und Identitätsdiensten, bei der oft kritische Systeme aufgedeckt werden, die zuvor übersehen wurden. 

Die Gewährleistung der minimalen Funktionsfähigkeit liegt in der gemeinsamen Verantwortung der Bereiche IT, Sicherheit, Betrieb, Risk, Finanzen und der Unternehmensleitung. 

Bitte sehen Sie sich hier das Video mit dem zeitgestempelten Transkript an

Hallo und herzlich willkommen zu dieser Folge des SHIFT-Podcasts.

Hier geht es darum, die minimale Funktionsfähigkeit zu etablieren und sie zum wertvollsten
Faktor für Ihr Unternehmen zu machen.

Hallo zusammen, ich bin Vidya Shankaran, Field CTO bei Commvault, und heute sind bei mir zu Gast Ha
Hoang, CIO bei Commvault Technologies, und Jay, CIO bei Constellation Energy.

Vielen Dank, dass ihr heute hier bei uns seid.

Vielen Dank für die Einladung.

Vielen Dank für die Einladung.

Selbstverständlich.

Wenn wir über die Mindestbetriebsfähigkeit sprechen, liegt die durchschnittliche Ausfallzeit, die branchenweit verzeichnet
wird, laut optimistischen Branchenstatistiken bei 24 Tagen.

Für die meisten Unternehmen ist das jedoch eine zu lange Dauer, als dass sie sie verkraften könnten.

Es geht nicht nur darum, sondern auch um die finanziellen Auswirkungen auf den Umsatz, die sich daraus für Unternehmen ergeben können –
ganz zu schweigen vom Reputationsschaden, den das Unternehmen während der 24 Tage der

Ausfallzeit erleidet.

Daher definiert die Branche heute die Mindestbetriebsfähigkeit als ein Mindestmaß an Fähigkeiten, das
die Mitarbeiter, die Prozesse und natürlich die Technologieumgebung umfasst, die zusammen ein

ein funktionsfähiges Unternehmen ausmachen.

Und das Erreichen dieser Mindestbetriebsfähigkeit wird zum entscheidenden Faktor dafür, ob das Unternehmen
nach einem Cyberangriff überleben und florieren kann.

Da die „Minimum Viability“ (MV) heute das Thema unserer Diskussion ist, freue ich mich, dass Ha.

und Jay bei uns sind.

Meine erste Frage an Ha lautet: Wie würdest du „Minimum Viability“
definieren, jenseits der in der Branche wahrscheinlich verbreiteten Fehlvorstellung, dass es sich dabei lediglich um eine IT-Checkliste handelt?

Wie lässt sich das mit einer Führungsmentalität umsetzen?

Für mich geht es bei der minimalen Funktionsfähigkeit weniger um den Tech-Stack als vielmehr um Klarheit bei den Entscheidungen.

Es geht also um die Frage: Was ist der kleinste Satz an Fähigkeiten, den wir benötigen, um das Geschäft
am Laufen zu halten, während alles andere ausfällt, richtig?

Es ist also eine Denkweise, die Disziplin erfordert – nämlich Ergebnisse und nicht nur
die Infrastruktur in den Vordergrund zu stellen, richtig?

Ich denke also, wenn man diese Sichtweise einnimmt, wird die Recovery-Planung zu einem Führungsgespräch
über Kompromisse und ist nicht nur eine technische Übung, oder?

Und das trägt auch dazu bei, eine gemeinsame Verantwortung über die Geschäftsbereiche, das Risk-Management und
, ähm, die IT hinweg aufzubauen.

Das leuchtet vollkommen ein.

Nun, da wir das Vergnügen haben, dass Sie heute hier bei uns sind, Jay: Was bedeutet „Minimum
Viability“ für ein Unternehmen mit kritischer Infrastruktur wie Constellation Energy, bei dem

Ausfallzeiten definitiv keine Option sind?

Nun, ich denke, ich würde mich da wohl ein wenig dem anschließen, worüber Sie gesprochen haben.

Es ist der ultimative Mannschaftssport.

Stimmt’s?

Ich meine, es ist keine Diskussion, die nur die IT betrifft.

Es ist keine Diskussion mit einzelnen Geschäftsbereichen.

Es ist keine Diskussion mit der Sicherheitsabteilung oder der IT-Abteilung.

Es ist wirklich eine Diskussion mit allen.

Denn genau das bedeutet „Minimal Viable Company“ doch eigentlich, oder?

Was bedeutet es für mich, mein Kerngeschäft weiterzuführen?

Stimmt’s?

Und wie sieht das aus?

Für mich ist die wichtigste Botschaft daher, dass es sich um eine Teamleistung handelt, denn es ist keine individuelle

Keine einzelne Gruppe kann das alleine schaffen.

Das finde ich toll.

Und diese Frage muss ich euch beiden stellen.

Ich würde wohl zuerst Ha das Wort erteilen.

Gab es irgendwelche Fallstricke oder Überraschungen, die euch bei der Erstellung der
Liste der minimal notwendigen kritischen Ressourcen unvorbereitet getroffen haben?

Ja, auf jeden Fall.

Es gab einige.

Einige der grundlegenden Systeme oder Anwendungen,

die wir für eine Art Grundvoraussetzung hielten, waren definitiv nicht vorhanden, oder?

Oder sie haben es nicht auf unsere Liste geschafft.

Und dann denke ich, dass gerade Systeme wie die Identitätsverwaltung, die meiner Meinung nach eher nachträglich berücksichtigt wurden
, dabei eine entscheidende Rolle spielen.

Und manchmal, ähm, konzentrieren wir uns hauptsächlich auf das, was der Kunde sieht, nämlich die
Anwendungen, oder?

Aber wenn man darüber nachdenkt, ob es sich um einen Jump-Service handelt, ob es um Identitätsmanagement geht oder ob
es einfach nur grundlegende, miteinander verknüpfte Systeme sind,

dann sind das meiner Meinung nach die entscheidenden Punkte.

Das finde ich toll.

Ich möchte noch hinzufügen, dass das Ganze einen voll und ganz in seinen Bann zieht.

Und wenn dir jemand sagt, dass das nicht so ist, dann erfindet er das einfach.

Das hat doch noch niemand zuvor gemacht, oder?

Es ist das erste Mal, dass wir wirklich darüber nachgedacht haben – wir haben zwar schon ewig über „Minimal
Viable Products“ gesprochen, aber nicht über „Minimal Viable Company“.

Ich denke, das Wichtigste für mich ist, dass wir eine sehr traditionelle Sicht auf die Welt hatten, bei der es Apps mit hohem, mittlerem und niedrigem Geschäftswert gab
.

Und wir sagten: „Na ja, das ist einfach.

Wir werden einfach die Apps mit hohem geschäftlichem Wert wiederherstellen und fertig.“

Was wir gelernt haben, war, dass eine ganze Reihe dieser Apps mit geringem geschäftlichem Wert wahrscheinlich dazu beigetragen hat
, die App mit hohem geschäftlichem Wert zu unterstützen oder ihr etwas zu liefern.

Dieses Denken in scheinbar sehr absoluten Kategorien funktioniert also nicht, wenn es um
ein „Minimal Viable Company“ geht, oder?

Denn man spricht von einem System, nicht von einzelnen Anwendungen.

Und das war für uns der größte Durchbruch.

Und ich würde wetten, dass das für viele Leute gilt.

Ich finde, das ist eine fantastische

Formulierung, die er da gerade verwendet hat: Es geht nicht um ein „Minimum Viable Product“, sondern um ein „Minimum
Viable Business“ oder ein „Minimum Viable Company“.

Das bringt mich zum nächsten Punkt.

Inwieweit hast du bei all diesen Maßnahmen eine partnerschaftliche Zusammenarbeit mit deinem CISO genossen,
insbesondere bei der Festlegung einiger dieser kritischen Vermögenswerte und der Frage, wer für die Entscheidungen zur Recovery zuständig ist

Entscheidungen?

Ja, du hast die kritischen Ressourcen angesprochen, aber wer hilft dann dabei?

bei der Priorisierung der Recovery-Maßnahmen?

Ja.

Mann, wie ich schon sagte, es ist zwar ein Mannschaftssport, aber man braucht auch einen Schiedsrichter.

Ich denke also, in vielerlei Hinsicht agieren der CIO und der CSO in diesem Fall tatsächlich ein bisschen wie ein Schiedsrichter
, denn als wir mit den Tabletop-Übungen begannen – wir hatten einen großartigen Partner, der

uns bei WWT unterstützt und uns wirklich dabei geholfen hat, das Ganze zu
durchdenken und sowohl den technischen Prozess als auch die

ich würde sagen, die verfahrenstechnischen Abläufe durchzugehen, denn am Ende hat man gelernt, dass jeder das Gefühl hat
, sein Bereich sei der wichtigste.

Ich denke also, das Wichtigste, worauf sich der CIO und der CISO konzentrieren müssen, ist, wie man
diese Rolle als Richter und Geschworener einnimmt, aber auch, wie man sicherstellt, dass man – wie du erwähnt hast –

einige wirklich zentrale Basistechnologien – Identität, Netzwerk – im Blick zu behalten, richtig?

Ohne diese funktioniert nichts.

Es geht also auch darum, den Menschen zu helfen,

dieses Puzzleteil zu verstehen.

So stelle ich mir ihre Rolle vor, oder?

Das finde ich toll.

Zurück zu dir, Ha.

Um noch einmal auf Jays Punkt zurückzukommen, dass es sich hierbei um eine Teamleistung handelt: Bist du bei der Erstellung des Business Case auf irgendwelche
Herausforderungen gestoßen, als du ihn wahrscheinlich dem Finanzteam

, dem Risk-Team und dem Compliance-Team vorgelegt hast?

Und was waren einige der Vorurteile, die in diesen

Geschäftsbereichen bereits festgesetzt hatten und die du ausräumen musstest, bevor du den Anwendungsfall rund
um die minimale Machbarkeit verkaufen konntest?

Um diese Teams an einen Tisch zu bringen, musste
die Darstellung des Konzepts der minimalen Machbarkeit natürlich anders aussehen, oder?

Sie musste in geschäftlichen Begriffen erfolgen und nicht in der Fachsprache von Backup and Recovery, oder?

Im Finanzbereich geht es beispielsweise darum, die Kontinuität der Einnahmen zu sichern.

Für die Risikomanagement-Teams geht es darum, das Risiko zu begrenzen.

Und für die Betriebsteams geht es vor allem darum, die Kunden zu schützen.

Und ich denke, wenn sich die Teams und die Funktionsbereiche in der Strategie der „Minimum
Viability“ wiedererkennen, entsteht erst echte Abstimmung.

Was Missverständnisse angeht, ist meiner Meinung nach das größte Missverständnis, dass „Minimum
Viability“ gleichbedeutend mit minimalem Aufwand ist.

Als ob es darum ginge, Standards zu senken oder sich mit einer teilweisen Recovery zufrieden zu geben.

Das ist ein guter Punkt.

In Wirklichkeit ist es genau das Gegenteil, oder?

Ähm, es geht wirklich um Disziplin und darum, sich auf das zu konzentrieren, was wirklich – ähm – Kontinuität und
Widerstandsfähigkeit fördert, wenn jede Minute zählt, oder?

Und dann ist meiner Meinung nach das andere Missverständnis, dass es sich um eine reine Technologieangelegenheit handelt, oder?

Vorstände und CIOs wie wir erwarten also eine Checkliste oder ein Architekturdiagramm, aber in
Wirklichkeit geht es um eine Diskussion über Geschäftsstrategie, oder?

Darüber, wie Unternehmen unter Druck tatsächlich Werte priorisieren, was sie schützen wollen und
warum.

Mir gefällt dieser Slogan, den du gerade genannt hast: „Wie man unter Druck geschäftlichen Wert
priorisiert“.

Ich würde das wahrscheinlich…

fett schreiben, hervorheben und bis zum Überdruss betonen, denn genau darin liegt der entscheidende Kern der
MVC-Definition.

Das bringt mich zum nächsten Punkt.

Wir haben über Strategie gesprochen.

Wir haben darüber gesprochen, dass es sich um eine Teamleistung handelt.

Aber was sind die wichtigsten KPIs?

Wie lässt sich das überhaupt quantifizieren und messen?

Das sind doch nicht gerade die typischen, greifbaren Kennzahlen, oder?

Oder übersehe ich da etwas?

Sind es der RPO und der RPTO, an denen man sich orientiert?

Was wären die Maßeinheiten für den Erfolg auf Basis von MVC?

Ich denke, ich werde vielleicht zunächst weniger auf die Kennzahlen eingehen, und dann kommen wir vielleicht zu den Kennzahlen.

Aber für mich geht es darum, sicherzustellen, dass man das System nicht nur in einer Krise nutzt.

Ich glaube, es ist ein weit verbreiteter Irrtum, einfach nur dazusitzen und zu sagen: „Wir üben das und
wir werden das hier haben.“

Wir haben

unsere gesamten Backups and Recoverys auf Commvault umgestellt, weil wir wollten, dass die Mitarbeiter das System täglich
nutzen.

Wir wollten also sicherstellen, dass sie wussten, wie man das System nutzt, wie es funktioniert und
wie man alle Details beherrscht, denn, wissen Sie, wir sprechen ja davon, unter Druck zu stehen,

oder?

Das ist nicht der richtige Zeitpunkt, um etwas Neues auszuprobieren.

Das ist also einer der Punkte.

Und ich möchte noch auf den letzten Punkt eingehen, über den du gesprochen hast – es ging wieder um DR,
richtig?

Ich glaube, ein weiteres weit verbreitetes Missverständnis ist, dass wir bereits über DR verfügen.

Wozu brauche ich das?

Stimmt’s?

Ich meine, ich habe es doch schon.

Und ich denke,

wenn man noch einmal über DR nachdenkt, ist das doch irgendwie eine veraltete Denkweise, oder?

Es hat, mangels eines besseren Begriffs, so eine Art „Loch-im-Boden“-Denkweise, oder?

Was passiert, wenn mir diese eine Sache fehlt?

Nun, ich glaube nicht, dass irgendeine unserer Welten in weniger als fünf anderen Clouds oder fünf anderen
Welten existiert.

Deshalb glaube ich wirklich, dass es erstens darum geht, die Denkweise zu ändern, und zweitens darum, die Abläufe so anzupassen
, dass man nicht erst in einer Krise handelt.

So sehe ich das jedenfalls.

Das finde ich toll.

Da stimme ich voll und ganz zu.

Ja, natürlich betrachten wir quantitative und qualitative Kennzahlen,
also Indikatoren.

Und technisch gesehen misst ja jeder RPO und RTO sowie
den Prozentsatz der fehlerfreien Backup-Daten und so weiter.

Aber ich denke, worauf ich mich ebenfalls konzentriere und was ich im Auge behalte, ist, wie schnell wir unter Druck fundierte
Entscheidungen treffen können, oder?

Denn meiner Meinung nach geht es bei der Readiness nicht nur darum, wie schnell wir Daten wiederherstellen können, sondern auch darum
, wie schnell wir den Daten und dem System, das wir wiederherstellen, vertrauen können.

Inwieweit läuft das also letztendlich auf die Operationalisierung von Tests hinaus?

Alles.

Eine ganze Menge.

Ja.

Ich meine, darauf läuft es doch immer hinaus, oder?

Vorbereitung, Übung.

Schau mal, in unserer Welt üben wir viel.

Wir üben alles, was wir tun.

Denn man will sichergehen, dass man es dann, wenn man es wirklich braucht oder unter Druck steht,
auch umsetzen kann.

Und ich denke, hier ist es nicht anders.

Vielleicht ist die gute Nachricht – oder auch die schlechte –, dass wir alle in letzter Zeit viele Gelegenheiten hatten, das
zu üben, oder?

Ob es nun Cloud-Ausfälle waren oder Anbieter, die so etwas tun, oder?

Wir hatten Gelegenheiten, das zu üben.

Und das ist der andere Punkt, den ich ansprechen möchte: Man muss diese Gelegenheiten nutzen und sich sagen:
Hab keine Angst davor, ein System einzusetzen, das du hast, oder?

Man hat ein System aufgebaut, also nutzt man dieses System.

Wie nutze ich es

, um schneller wieder einsatzfähig zu sein?

Wie nutze ich es für die Recovery einer bestimmten Cloud oder bei einem aktuellen
Vorfall, richtig?

Ich denke, es geht darum, vorausschauend zu handeln und das System zu nutzen, anstatt es beiseite zu schieben und zu denken:
„Oh, muss ich mich jetzt um die Notfallwiederherstellung kümmern?

So nach dem Motto: „Muss ich das wirklich tun?“

Diese Denkweise haben wir alle.

Man darf es nicht einfach einrichten und dann vergessen.

Genau, genau.

Es ist einfach da – nutzt es.

Ja, und das ist definitiv etwas, woran Organisationen weiterarbeiten müssen.

Das ist keine

einmalige Übung, die man einfach abhaken kann.

Es ist ein dynamischer Prozess, den man kontinuierlich verbessern muss.

Und seien wir ehrlich: Es wächst auch ständig weiter, oder?

Die Datenmenge und alles andere nehmen nicht ab.

Wahrscheinlich ist das Produkt, das man eingeführt hat – und das gilt wohl für jeden –, nur ein Bruchteil dessen
, was man heute hat.

Das verändert die Spielregeln, oder?

Genau.

Das bringt mich zur nächsten entscheidenden Frage, die schwieriger war.

War es die technische Umsetzung oder der kulturelle Wandel?

Ich würde sagen, der kulturelle Wandel und die kulturelle Veränderung, ohne Frage.

Die technische Arbeit ist komplex, aber lösbar.

Man kann sie automatisieren und sich durch Tests hindurcharbeiten.

Am schwierigsten ist jedoch der Umdenkprozess – weg von der Vorstellung, dass Recovery eine Aufgabe der IT ist, hin
zur Erkenntnis, dass Resilienz tatsächlich eine gemeinsame

Unternehmenskompetenz ist.

Ja.

Ja.

Da stimme ich zu.

Ich würde sagen, der technische Teil ist einfach, weil ich ein großartiges technisches Team habe, das
es einfach wirklich einfach aussehen lässt.

Aber ich glaube schon, dass sich die technischen Probleme lösen lassen, oder?

Es sind Einsen und Nullen, und wir können das alles herausfinden.

Das Problem ist, dass diese Diskussion immer so ablief: „Hey, IT, macht euer Ding und sagt uns Bescheid, wenn
ihr fertig seid“, oder?

So läuft das Gespräch heute nicht mehr.

Und das ist für mich die größte Veränderung: Man muss jetzt alle Führungskräfte des Unternehmens in
einem Raum versammeln und sagen: „Hey, wir müssen ein Gespräch über Recovery führen.“

Und es geht nicht mehr nur darum: „Hey, sagt uns Bescheid, wenn ihr fertig seid, IT.“

Und genau das ist der kulturelle Wandel.

Da stimme ich voll und ganz zu.

Ich denke, die Frage nach der Zukunftsfähigkeit zwingt uns zu unangenehmen Gesprächen über
Prioritäten, oder?

Was muss wirklich in den ersten 24 Stunden geschehen und was kann warten?

Und genau da, denke ich,

verlangen wir im Wesentlichen von Führungskräften: in Echtzeit Kompromisse einzugehen, und das sind
die schwierigen Gespräche.

Ja.

Nein, das leuchtet vollkommen ein.

Und gerade zu Ihrem Punkt: Wenn man jeden Unternehmensleiter fragen würde, würde er
antworten: „Mein AppStack ist wichtig.“

Alles ist wichtig.

Ich bin am wichtigsten.

Ja, absolut.

Nachdem wir also

den Prozess des Aufbaus Ihres MVC miterlebt und durchlaufen haben – und natürlich ist es
, wie wir gerade besprochen haben, ein fortlaufender Prozess.

Aber was sind die wichtigsten Erkenntnisse, die „Erfahrungen“, die du unbedingt mit deinen Kollegen teilen möchtest
, damit sie nicht auf dieselben Herausforderungen stoßen, wenn sie

beim Aufbau ihres MVC?

Ich würde sagen: Übe die Recovery, als wäre es Spieltag, oder?

Denn in einer Krise kann man keine Widerstandsfähigkeit aufbauen.

Sie entsteht durch die Übungen, die man vorher macht.

Perfekt.

Ich denke, für mich – und du hast es schon ein paar Mal erwähnt, und ich kann es gar nicht oft genug betonen –
ist die grundlegende Kernschicht entscheidend.

Ich glaube, traditionell denken wir einfach nicht daran, dass grundlegende Dinge wie
Active Directory, das Netzwerk und all diese Dinge mittlerweile stärker

als je zuvor.

Und ich denke, das ist die größte Veränderung, die man wirklich berücksichtigen und umsetzen muss

und verstehen muss: Wie sieht es aus, wenn ich meine zentrale Authentifizierung wiederherstellen muss, bevor
meine Mitarbeiter überhaupt mit der Arbeit beginnen können?

Und genau das vergessen wir immer.

Ohne das können die IT-Mitarbeiter keine Arbeit erledigen.

Und ich denke, das ist die ultimative „Kampfnarbe“.

Und ehrlich gesagt glaube ich, dass dies eines der Dinge ist, die Commvault besser kann als alle anderen – nämlich
diese Recovery-Prozesse auf Active Directory-Forest-Ebene, die so entscheidend sind und eines der

wichtigsten Unterscheidungsmerkmale für uns bei der Produktauswahl sind.

Ich danke Ihnen.

Danke, dass Sie uns diesen Einblick gewährt haben.

Und bevor ich euch beide gehen lasse: Was sind die kurzen, aber wirkungsvollen Schlussworte
, die ihr uns mit auf den Weg geben würdet?

Meine Güte, ich glaube, das habe ich gerade schon gesagt.

Trainiert die Recovery so, als wäre es Spieltag.

Perfekt.

Das gefällt mir.

Für mich ist es ein Mannschaftssport.

Und man kann das nicht einfach dem IT-Team überlassen und sagen: „Hey, sagt mir Bescheid, wenn es fertig ist.“

Das ist ein Mannschaftssport, bei dem alle Anwesenden in die Diskussion einbezogen werden müssen.

Perfekt.

Vielen Dank, dass Sie heute bei uns sind und Ihre Erkenntnisse mit uns teilen.

Das war sehr wertvoll.

Und an alle unsere Zuschauer, die virtuell dabei sind: Wenn Sie sich eingehender mit
dem Konzept der „Minimum Viability“ befassen möchten, werfen Sie bitte einen Blick auf unseren GigaOm-Analystenbericht, der

ausführlicher auf das Konzept der minimalen Lebensfähigkeit eingeht und auf Commvault.com verfügbar ist.

Ich danke Ihnen.