Wie läuft das eigentlich ab?

Der Auslöser ist immer der gleiche: Alle Systeme melden in der Überwachung "grün", und im Geschäftsprozess des Kunden kann keiner arbeiten, die Eskalation ist auf oberster Ebene angelangt.

Die Massnahmen der IT gipfeln in einer "Task Force", es werden die Experten zu allen involvierten Systemen zusammengerufen - da nicht klar ist, welche Systeme welche Rolle spielen für die ausgefallenen Funktionen, sind die Chefs gleich mit dabei.

Und dann kommt irgendwann die Frage: "Wie läuft das eigentlich ab?" In anderen Worten: Über welche Kette, die irgendwo unterbrochen ist, wird die nichtverfügbare Leistung transportiert?" Und sobald das Whiteboard voll ist - mit der Zeit in immer kleinerer Schrift - dann ist das betroffene System eingegrenzt.

Jetzt müsste man nur schnell nachschlagen, wie dieses System im Fehlerfall zu behandeln ist: Ein klarer Fall für eine Wiederherstellungsprozedur - wenn's denn eine gibt...

Lesen statt diskutieren

Angenommen, man wollte diese archetypische Situation grundsätzlich vereinfachen, dann schlägt ITIL vor: "Alle Informationen über Details und wechselseitige Abhängigkeiten zwischen CIs sollten an einer Stelle zusammengeführt werden...", und weiter: "dieser zentrale Speicher ist...ein wichtiges Instrument zur Gewährleistung von Konsistenz zwischen den Prozessen" (Begleitband zu ITSM 2.1)

Das führt zu einigen interessanten Fragen:

1. -Welche Objekte sind CIs?
   

2. -Wie werden die organisatorischen Verantwortungen zugeordnet?
   

3. -Wie prüft man Vollständigkeit der Beschreibungen?
   

4. -Wie bekommt man die Beziehung zu den End-to-End-Funktionen hin?
   

5. -Und wie sieht ein konkretes Dokumentationskonzept aus,
   

6. das die enorme Menge an Daten handhabbar macht?
   

Unser Ansatz basiert auf einer Beschreibung in einem Repository. Genutzt werden klassische Beschreibungstypen wie Funktionsbäume und Prozessketten, z.b. für die Betriebsaktivitäten nach ITIL. Und in der gleichen Datenbank ein objektorientiertes Verfahren, um die Produkte, die Systeme und die Lieferketten End-to-End zu beschreiben.

Dies erlaubt es somit, an einer Stelle in solchen Task Force-Situationen "lesen" zu können, statt zu diskutieren.

Möglichkeiten

Und es bietet die Möglichkeit, den kompletten Aufbruch nach unten (Wie?) und nach oben (Warum) nachzuvollziehen, beispielsweise in der Kette:

1. -"Strategie" (ist auch ein CI!), liefert
   

2. -"Leistungen", haben
   

3. -"SLA", werden erbracht durch
   

4. -"Prozesse" sind gebaut aus
   

5. -"Funktionen", werden ermöglicht von
   

6. -"Systemen", werden wiederhergestellt mit
   

7. -"Betriebsprozedur", und sind aus
   

8. -"Produkten" gebaut, zu überwachen mit
   

9. -"Kennzahlen", geplant in
   

10. -"Prozessen", und sind eingestellt mit
    

11. -"Konfigurationsdaten"
    

Nachstehende Folien zeigen Ansatz und Vorgehen, um ein solches Repository als CMDB mit Systemen UND Prozessen aufzubauen.