Direkt zum Hauptbereich

IT-Notfallvorsorge agil bearbeiten

Das Absichern von Geschäftsprozessen gegen Ausfälle ist eine wichtige Vorbereitung. Früher haben wir dazu die Prozesse erhoben. Dann haben wir die Auswirkungen untersucht und uns eine Reihe von absichernden und vorbereitenden Maßnahmen überlegt. Das hat eine ganze Weile gedauert. Geht das nicht auch agil? Und wenn ja, wie macht man das genau?

Was ist Notfallvorsorge? 

Bei der Vorsorge stellen wir uns - hoffentlich bevor der erste Notfall passiert - Fragen: Was tun wir, wenn bestimmte IT-Systeme nicht zur Verfügung stehen? Wie sind wir möglichst schnell wieder arbeitsfähig? Im Rahmen solcher Projekte werden Notfallhandbücher erstellt, Ersatzsysteme und Ersatzzugänge eingerichtet. Wir schauen uns die Datensicherung an und schulen Mitarbeiter für den Fall der Fälle. (Der Fachbegriff dafür lautet übrigens business continuity management. Beim BSI gibt es einen Online-Kurs Notfallmanagement.)

Foto von Mick Haupt auf Unsplash

Woran scheitern solche Projekte?

Solche Projekte fühlen sich oft zäh an. Natürlich weiß jeder, dass Vorsorge besser ist als das Nachsehen zu haben. Bisher ist es ja auch immer gut gegangen usw.. Aber in der Praxis haben Mitarbeiter selten dafür Zeit. Als Projektleiter muss man den Kollegen hinterherlaufen. Der o. g. Notfallmanagementkurs beschreibt ein Projekt eher klassisch. Es wird viel analysiert und konzipiert. Natürlich müssen wir Dinge analysieren und konzipieren. Aber auf solch einem Weg verlieren wir die wichtige Unterstützung der Anwender und wir bekommen spät Feedback. Wir wissen also gar nicht, ob unser Konzept überhaupt funktioniert.

Je schneller wir solche Projekte bearbeiten, desto eher gibt es überhaupt ein Ergebnis. Hier kann uns eine agile Arbeitsweise helfen.

Produktziel und Product Backlog

Warum machen wir das Projekt? Wir möchten alle Geschäftsprozesse gegen unvorhergesehene Ausfälle absichern. Wir könnten uns zum Beispiel vornehmen, dass wir nach einem Ausfall innerhalb einer festen Zeit wieder arbeitsfähig sind. 

Die Wiederherstellzeit kann je Geschäftsprozess variieren. Dazu könnten wir Klassen definieren:

  • Klasse 1: Es gibt keine Ausfälle, egal, was passiert. (Das ist aufwendig. Aufwand und Nutzen müssen zueinanderpassen.)
  • Klasse 2: Der Geschäftsprozess ist am selben Tag wieder hergestellt.
  • Klasse 3: Der Geschäftsprozess ist innerhalb weniger Tage wieder verfügbar.
  • Klasse 4: Die Wiederherstellzeit für den Geschäftsprozess ist länger.

Solch eine Liste könnte zur Vorlage für das Produktziel werden.

Im Product Backlog stehen die Geschäftsprozesse der verschiedenen Abteilungen:

  • Registrierte Kunden können Bestellungen aufgeben. Bestellungen werden automatisch verarbeitet.
  • Bürger können einen Antrag für Leistung X stellen. Der Antrag wird innerhalb von X Stunden bearbeitet.
  • Registrierte Anwender können auf 50 % der angebotenen Serien und Filme zugreifen und abspielen.

Zu jedem Prozess können Akzeptanzkriterien definiert werden. Z. B. können wichtige betroffene Systeme oder einzuhaltende Standards ergänzt werden.

Das Backlog ist nach Wichtigkeit der Prozesse sortiert.

Die Geschäftsprozesse sind gut geeignet, weil sie zu wiederholbaren Umsetzungsbausteinen werden.

Vorbereitung und Refinement

Vor dem ersten Sprint hilft eine grobe Übersicht:

  • Welche Abteilungen gibt es? Wer sind die Ansprechpartner? Wer aus den Abteilungen kann operativ im Projekt mithelfen?
  • Was sind ihre wichtigen Geschäftsprozesse? Welche Systeme sind beteiligt?
  • Welche typischen Ausfälle hatten wir schon einmal? Mit welchen Ausfällen ist zu rechnen? Gibt es Informationen zu Ausfällen von vergleichbaren Organisationen?

Bevor das Scrum Team einen bestimmen Geschäftsprozess bearbeiten kann, brauchen wir ein paar Informationen:

  • Was macht der Prozess? Wer ist verantwortlich?
  • Welche Systeme sind betroffen?
  • Wie lange kann dieser Prozess offline oder gestört sein, bevor es richtig unangenehm wird? Hier reichen schon ungefähre Informationen.
Der Product Owner sorgt dafür, dass diese Informationen jeweils vor der Planung des Sprints vorliegen, in dem die Prozesse bearbeitet werden sollen.

Scrum Team

Der Product Owner ist für ein gutes Notfallmanagement verantwortlich. Dafür sollte eine Person ausgewählt werden, die operativ mitarbeiten kann und einen guten Draht zu allen Abteilungen in der Organisation hat. Der Product Owner bekommt einen klaren Auftrag von der Unternehmensleitung. Budget und Entscheidungsbefugnisse sind geklärt.

Bei den Umsetzern brauchen wir alle Kompetenzen, um einen Geschäftsprozess inhaltlich und technisch sicherzumachen. Dafür brauchen wir Prozessexperten aus den Fachbereichen, denn die müssen dafür sorgen, dass Abläufe im eigenen Bereich etwas angepasst werden. Wir brauchen auch IT-Experten, die die Systeme absichern können.

Die Rolle Scrum Master sollten wir mit einer Person besetzen, die den Umsetzern kritische Fragen stellen kann, ohne dass die Umsetzer eingeschnappt sind. Der Scrum Master soll den Umsetzern dabei helfen, ihre Lieferprozesse zu verbessern.

Inkrement und Definition of Done

Häufig werden solche Projekte sehr dokumentenlastig bearbeitet. Es besteht die Gefahr, dass die Dokumentation veraltet. Die Frage ist: Was kann das Scrum Team von Sprint zu Sprint zeigen, um Feedback zur Absicherung zu bekommen? Vielleicht ist es ein Notfallhandbuch mit Anlagen. Vielleicht sind es konkrete Pläne und Tools. Vielleicht sind es Rückmeldungen aus den Fachbereichen.

Zum Inkrement bei Scrum gehört eine Definition of Done. Diese Checkliste soll uns helfen, unabhängig vom bearbeiteten Prozess eine gute Qualität abzugeben. Die DoD ist von der Art des Inkrements abhängig. Wir könnten mit folgenden Punkten starten:

  • Der Geschäftsprozess ist gemäß unserer Vorgaben dokumentiert und freigegeben.
  • Der Prozess ist einer Schadensklasse zugeordnet. Es gibt eine Vorgabe für die Wiederherstellzeit.
  • Es gibt eine Liste von absichernden Maßnahmen mit Terminen, die diesen Prozess gegen Ausfälle absichern sollen.
  • Es gibt eine Liste von Aktivitäten, die im Falle eines Falles ausgelöst werden. Es gibt Termine mit Anwendern, an denen diese Maßnahmen besprochen und ggf. geübt werden.
  • Die Notfalldokumentation ist aktuell.
  • Die nötigen Freigaben liegen vor.

Grundsätzlich gilt: auch wenn noch nicht alle Prozesse in die Notfallvorsorge aufgenommen wurden, ist das Notfallpaket immer aktuell. Für die IT-Dokumentation finde ich noch immer das Buch von Manuela und Georg Reiss gut.

(Die DevOps-Community empfiehlt an dieser Stelle sicherlich, ganz viele Dinge auch für die Dokumentation zu automatisieren, z. B. Infrastructure as code. Alles, was sich selbst dokumentieren und aus einer potenziellen Schadenszone beamen kann, reduziert den Aufwand. Vielleicht wissen einige Leser, dass Netflix extra Skripte programmiert hat, die absichtlich etwas kaputt machen (Chaos Engineering). Damit wollen die Betreiber wissen, ob ihre Infrastruktur ausfallsicher ist.)

Rhythmus und Releaseplanung

Je kürzer der Rhythmus ist, desto eher wird das Projekt überhaupt zum Ergebnis kommen. Es hängt jetzt ein wenig davon ab, wie fokussiert das Scrum Team arbeiten kann.

  • Idealerweise arbeiten alle Vollzeit nur an diesem Projekt. Sprintlänge ist eine Woche oder noch kürzer.
  • Wenn das nicht möglich ist, sollte das Scrum Team feste Blöcke verhandeln, z. B. einen festen Tag pro Woche oder feste Arbeitsblöcke mit mehreren Tagen pro Monat.

Je schneller das Projekt beendet ist, desto eher haben die Beteiligten wieder Zeit für andere Projekte. Das gleichzeitige Bearbeiten von mehreren Projekten verzögert das Liefern von Ergebnissen für alle um ein Vielfaches. Es frustriert die Beteiligten und führt oft dazu, dass Projekt verhungern. Wer als Führungskraft schnelle Ergebnisse will, sollte dem Scrum Team helfen, fokussiert arbeiten zu können. Bitte lasst das Scrum Team fokussiert arbeiten.

Wir erinnern uns noch einmal, warum Scrum für solche Projekt gut geeignet ist:

  • Wir können uns nicht sicher sein, ob wir den Prozess im Hinblick auf Vorsorge gut verstanden haben.
  • Wir kennen nicht alle Einzelheiten zur Technologie, zu den Tools, zu den Standards oder sonstigen Dingen, mit denen wir Prozesse absichern wollen.
  • Wenn wir mit unterschiedlichen Abteilungen intern und mit unterschiedlichen Lieferanten extern arbeiten, wissen wir nicht, ob wir uns wirklich richtig verstanden haben.

Aus diesen Gründen können wir nicht vorab alles planen. Es ist besser, nach vernünftiger Vorbereitung mit den ersten Prozessen anzufangen. Wir machen regelmäßig Reviews mit Stakeholdern (spätestens alle 1-2 Monate). Dort holen wir uns Feedback, ob die Prozesse nun sicher und zumindest sicherer geworden sind. Mit jedem Review lernen wir dazu.

Zu Beginn der Arbeit würde ich mit ein paar Prozessen starten, an denen das Scrum Team lernen kann. Das sollten nicht die kritischsten Prozesse, aber auch nicht die unwichtigsten sein. Mit diesen Prozessen bauen wir die erste Version des Notfallpaketes auf. Wenn wir gutes Feedback bekommen haben, nehmen wir uns die kritischen Prozesse vor und dann folgen wir den Schadens- oder Wiederherstellklassen.

Irgendwann müssen wir sicherlich größere Reviews einplanen, weil wir zum Beispiel die Freigabe von Wirtschaftsprüfern brauchen. Wir sollten auch Übungen einplanen. Bei manchen Prozessen müssen wir vielleicht sogar mehrfach üben. Das kann man dann über Sprint- oder Releaseziele steuern.

Sie wollen mehr über Digitalisierung lernen? Dazu gibt es eine Überblicksseite, die wichtige Artikel aus diesem Blog in eine Reihenfolge bringt. 

 

Kommentare

Beliebte Posts aus diesem Blog

Optimieren wir uns zu Tode?

Als jemand, der mehr als fünfzehn Jahre in der Welt des IT-Service-Management-Prozessmanagements verbracht hat, musste ich das Buch von Guther Dueck aus dem Jahr 2020 Heute schon einen Prozess optimiert? Das Management frisst seine Mitarbeiter lesen/1/. Typisch für ihn bietet Dueck uns einen provokanten, teils vernichtenden, jedoch humorvoll geschriebener Weckruf. Er behauptet, dass das moderne Management von “Pacesetters” und “Controllers” dominiert wird. Sie sind so sehr auf Optimierung und Profit fokussiert, dass sie den Willen zu Innovation und Unternehmertum abtöten. Jedoch ohne mehr Kreativität und Tatkraft werden wir die Herausforderungen der Digitalisierung, des Klimawandels etc. nicht bewältigen. Ein agiles Mindset kann helfen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Eine einfache Anleitung zum Führen eines Notizbuchs im Business

Professionelle Arbeit ist dokumentiert und reproduzierbar. Die Basis für eine gute Dokumentation ist das persönliche Aufschreiben von Dingen. Es gibt im Netz sehr viele Anleitungen für unterschiedliche Einsatzbereiche. Ich habe nach einem integrierten Ansatz gesucht.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.