Die Business Impact Analyse für den Fachbereich IT

Geht man mit der Business Impact Analyse durch die Fachbereiche im Unternehmen landet man früher oder später bei der IT. Dieses “früher oder später” wird zentrales Thema dieses Beitrags sein. Die IT stellt mit den IT-Services wesentliche geschäftskritische Ressourcen für die Geschäftsprozesse zur Erbringung der Produkte und Services. des Unternehmens Auf der anderen Seite ist der Fachbereich IT auch eine Organisationseinheit mit Prozessen und Ressourcen.

Zu den Prozessen der IT gehören beispielsweise

  • der Betrieb der IT-Anwendungen und -systeme
  • die (Weiter-) Entwicklung der Anwendungen
  • die Endkundenbetreuung (Bsp. User Help Desk)
  • die Sicherstellung der Informationssicherheit
  • die Steuerung der Auslagerungen an externe Dienstleister.

Viele IT-Bereiche haben ihre Prozesse nach ITIL (IT Infrastructure Library), einem Best-Practice-Ansatz für das IT-Servicemanagement, aufgebaut.

Zur Bereitstellung der IT-Services benötigt die IT Ressourcen. Hierzu gehören

  • Personal (interne und häufig in großem Maße externe Mitarbeiter)
  • IT-Anwendungen (Bsp. Anwendungen zur Entwicklung, Betrieb und Administration der IT-Anwendungen, Middleware, Schnittstellenprogramme, Testsysteme etc.)
  • Gebäude und Arbeitsplätze (Bsp. Rechenzentren, Datenräume, Entwicklerarbeitspätze, Büroäume)
  • Hardware (Bsp. IT- und Telekommunikationssysteme, Netzwerkkomponenten, Verkabelung)
  • Dienstleister (Bsp. RZ-Betreiber).

Bei der Durchführung der Business Impact Analyse in der IT stößt man dann ganz schnell auf die Fragestellung nach den kritischen Geschäftsprozessen und Ressourcen. Ausgangspunkt für die Ableitung der Kritikalität der Prozesse und Ressourcen ist der Impact, also die finanziellen und nicht-finanziellen Auswirkungen einer Unterbrechung des Geschäftsprozesses auf die Erbringung der kritischen Produkte und Services des Unternehmens. Da die IT unterstützende Prozesse für die eigentlich wertschöpfenden Geschäftsprozesse des Unternehmens bereitstellt, ist die Kritikalität aus den Anforderungen der wertschöpfenden Prozesse abzuleiten. Die IT wird in der BIA demnach häufig argumentieren, die Fachbereiche müssten festlegen, welche IT-Prozesse wie kritisch sind. Die Fachbereiche bewerten in ihrer BIA die Kritikalität von IT-Services. Über die IT-Prozesse, die zur Erbringung dieser IT-Services direkt und indirekt notwendig sind, haben die Fachbereiche jedoch keine Kenntnis. Eine direkte Ableitung der Kritikalitäten der IT-Prozesse und Ressourcen aus den BIAs der Fachbereiche gelingt somit nicht. Service Level Agreements über die Bereitstellung der IT-Services zwischen der IT und den Fachbereichen können diese Lücke schließen. Vorausgesetzt, die SLA´s sind vorhanden und die Verfügbarkeiten der IT-Services sind darin definiert. Hieran mangelt es aber oftmals. Wie kann dieses “Henne-Ei-Problem” gelöst werden? Ein möglicher Ansatz soll in diesem Beitrag vor- und zur Diskussion gestellt werden.

Jetzt kommt die Eingangsfrage “früher oder später” zum Zuge. Zunächst wird die BIA in den Fachbereichen mit den wertschöpfenden Prozessen durchgeführt. Basis für die Anforderungen an die IT ist der IT-Servicekatalog. Sind die BIA´s der wertschöpfenden Prozesse abgeschlossen, findet die Abstimmung der Soll-Anforderungen an die IT-Services mit der IT statt. Den Soll-Anforderungen (Soll-RTO) werden die bestehenden Verfügbarkeiten (Ist-RTO) je IT-Service gegenübergestellt und GAP´s identifiziert. Die GAP´s können durch workarounds in den Geschäftsprozessen oder Anpassung des Ist-RTO der IT-Services geschlossen werden. Nach der GAP-Analyse liegen die finalen Anforderungen der Fachbereiche an die IT-Services vor. Auf Basis dieser Anforderungen kann die IT in ihrer BIA ableiten, welche Prozesse und Ressourcen in der IT erforderlich sind, um diese Anforderungen abzubilden. Ein erster Schritt ist getan, dies ist jedoch für die vollständige BIA in der IT nicht ausreichend, denn nicht alle notfallrelevanten Prozesse und Ressourcen werden hiermit erfasst. In einer Notfallsituation erhöht sich beispielsweise der Bedarf an die Leistungen des User Help Desks. Paßworte werden in der Hektik falsch eingegeben, eine hohe Zahl an Berechtigungen muß geändert werden, Leitungen müssen umgeroutet werden, VPN-Zugriffe freigeschaltet und externe Dienstleister angewiesen werden. Die IT muss antizipieren, welche IT-Services, Prozesse und Ressourcen in einer Notfallsituation mit welchen Kapazitäten bereitgestellt werden müssen. Während die Prozesse der Anwendungsentwicklung – bis auf Fehlerbehebung – ausgesetzt werden können, sind für die kundenbezogenen Prozesse erhöhte Anforderungen im Notfall zu berücksichtigen. Die Erfahrungen aus vergangenen Störungen und Notfällen geben hierbei wichtige Hinweise. Ergebnis ist eine vollständige Betrachtung aller IT-Prozesse und deren Ressourcen. Das IT Service Continuity Management (ITSCM) kann jetzt auf diesen Anforderungen aufsetzen und die Verfügbarkeit der IT-Anwendungen, Systeme, Prozesse, Personal und Dienstleister entsprechend ausrichten und testen.

Eine analoge Vorgehensweise bietet sich auch für unterstützende Fachbereiche wie das Facility Management an. Sind die Anforderungen an die Verfügbarkeit der Gebäude und Infrastruktur aus der BIA bekannt, kann das Facility Management analog der IT die eigenen Prozesse angemessen ausrichten. Dies gilt insbesondere auch für die Prozesse zu Safety und Security, die durch das Facility Management auch im Notfall angemessen sichergestellt werden müssen.

Die Reihenfolge in der Abarbeitung der BIA von den wertschöpfenden Fachbereichen zu den unterstützenden Fachbereichen ist der Schlüssel, um die kritischen Prozesse vollständig betrachten zu können.

Ihnen hat der Beitrag gefallen, Sie haben Kommentare oder kritische Anmerkungen? Nur her damit! Nutzen ie die Kommentarfunktion zu diesem Beitrag oder senden Sie mir Ihre Anmerkungen persönlich zu.

Sie möchten gerne Ihre eigene Erfahrungen in den BCM-News darstellen oder zur Diskussion stellen? Gastbeiträge sind immer willkommen. Wir veröffentlichen selbstverständlich unter Ihrem Namen.

Be prepared

Matthias Hämmerle MBCI

0 Responses

Schreibe einen Kommentar