Die Eröffnung des Berliner Flughafens wurde seit 2010 zum wiederholten Male verschoben. Neben den Problemen bezüglich der Brandschutzanlage wird auch von Bestechung und anderen Widrigkeiten gesprochen. Erneut müssen zusätzliche Finanzspritzen in Milliardenhöhe gegeben werden. Kann etwas Vergleichbares in der IT nicht passieren?
Die Mehrzahl der Verantwortlichen von IT-Einheiten, insbesondere die der kleineren und mittleren Unternehmen (KMU), gehen mit den Risiken in der IT, speziell der Sicherheit, häufig sehr sorglos um. Sie sind der Meinung: “So etwas kann bei uns nicht passieren“. Die aktuelle Situation beschrieb ein Autor bei silicon.de mit: “in den letzten Jahren sind die Themen Risk-Management […] etwas aus dem Blickfeld der IT-Manager gerückt“. Dies kann darauf zurückgeführt werden, dass Risiken ein “schlechtes Gefühl” hervorrufen und mit “Mängeln in der IT-Organisation“ oder mit “Unfähigkeit“ und “Versagen“ gleichgesetzt werden. Ein weiterer Aspekt ist, dass die gemeldeten IT-Risikopotenziale verschwindend gering sind gegenüber den anderen Risiken im Finanz- und Versicherungssektor.
Beispiele aus der Praxis
Ein mit dem Berliner Flughafen vergleichbares Beispiel ist der Flughafen von Denver. Dieser sollte 1993 in Betrieb gehen, allerdings gab es Verzögerungen bei der Software für die Gepäckabfertigung. Man spricht von 500 Millionen Dollar Schaden und “es fehlte ein Risiko-Management“. Beim Kuala Lumpur International Airport fiel kurz nach der Eröffnung das zentrale Netzwerk aus. FoxMeyer Corp., ein 5 Milliarden-Dollar-Medikamenten-Großhandel in Amerika, musste nach Problemen beim Umstieg auf ein neues Softwaresystem Konkurs anmelden.
Diese Beispiele zeigen, dass die IT einen wichtigen Beitrag zur Erreichung der Geschäftsziele liefert. Dass die IT hierbei vor Risiken – gemäß dem Grundsatz “keine Wirtschaftlichkeit ohne Risiken“ – nicht gefeit ist, die sogar Auswirkungen auf das Geschäftsmodell nach sich ziehen können, ist jedem Verantwortlichen einsichtig. Er sollte in diesem Zusammenhang an die Statements angesehener Autoren wie Murphy oder Tom DeMarco denken: “If anything can go wrong, it will“ oder “no risk, no fun“.
Risiken sind ein Bestandteil der Geschäftstätigkeit und werden durch diese geschaffen. Risiken zu vermeiden, bedeutet, Geschäft aufzugeben. Risiken begleiten die Auslagerungen, die Projekte, die Verträge, die Beteiligungen oder werden durch Mitarbeiter verursacht. Nachrichten wie “ein Programmierfehler hat 30 Millionen EC-und Kreditkarten in Deutschland außer Gefecht gesetzt“, “schon wieder Datenschutzverstöße bei xxx“, “ein langjähriger Mitarbeiter von xxx ist verhaftet worden, nachdem er sämtliche Administrationspasswörter […] geändert hatte“ sind Beispiele für Letzteres.
Dass sich hinter Risiken nicht nur Mängel bei Menschen oder IT-Systemen verbergen, zeigt das folgende Beispiel: “als Folge eines Schiffunglücks sank auch eine Festplatte auf den Grund des Meeres“. Neben diesem externen Ereignis eines sogenannten “operationellen Risikos“ gibt es aber noch viele weitere Risiken wie Marktrisiken (zum Beispiel Marktveränderungen, Insolvenzen, Personalknappheit), neue Anforderungen seitens Benutzern oder Aufsichtsämtern, Risiken aus Verträgen sowie Rechtsrisiken, Reputationsrisiken durch verstärkte öffentliche Kommunikation, Risiken im Hinblick auf die anvisierten Geschäftsziele, Strategien und geschäftspolitischen Entscheidungen beziehungsweise die sogenannten Opportunitätsschäden.
Obwohl einige Risiken mit hohen Schadenpotenzialen bis in Milliardenhöhe belegt sind (zum Beispiel bei Schadensersatzforderungen, Patent- oder Urheberrechtsverletzungen), treten gerade im Umfeld der Informationstechnologie Risiken auf, die weniger mit Euro beziffert werden können. Teilweise sind sie verborgen in den IT-unterstützten Geschäftsprozessen (-> Business Continuity Management), in Ressourcenerhöhungen, in Terminverzögerungen, in der Bindung des IT-Personals mit unvorhergesehenen Aufgaben oder lassen sich bei Wechseln im IT-Management zurückverfolgen. Auch weisen zahlreiche Nachrichtenmeldungen – hier ist silicon.de eine wunderbare Quelle – auf versteckte IT-Schäden hin (“Jeder verlorene Datensatz verursacht Schäden in Höhe von 157 €“; “Milliardenschäden durch falsche SW-Lizenzierung erwartet“; “Projekt gab xxx Euro aus und wurde nun eingestellt“). Ein Vorstand brachte dies – im Zusammenhang mit den Risiken der letzten Jahre – wie folgt zum Ausdruck: “Ich hätte mir auch nicht träumen lassen, dass es einmal so weit kommt“.
Risiko-Identifikation
Der erste und wichtigste Schritt eines Risikomanagement-Prozesses ist die Risiko-Identifikation. Nur die Risiken, die erkannt wurden, können überhaupt einer Kontrolle und Steuerung unterworfen werden. Der unbedarfte Betrachter wird zuerst einmal nur Standard-Risiken wie Terminverfehlung oder Ressourcenerhöhung auf seine Merkliste schreiben. Doch sind dies “alle“ Risiken und insbesondere sind es die für eine Institution bzw. das Top-Management “wesentlichen“ Risiken? Wie kann eine weitgehende “Vollständigkeit“ herbeigeführt werden? Hier helfen einige Quellen weiter.
a) Zurückführend auf wirtschaftliche Probleme und Insolvenzen haben schon Ende der 90er Jahre (aufsichts-)rechtliche Instanzen die fehlende Bereitschaft mit dem Umgang von Risiken und deren Akzeptanz erkannt. Im Rahmen der Corporate Governance wurden daher zahlreiche Bestimmungen erlassen, wie mit Risiken zu verfahren ist, wer verantwortlich hierfür ist und welche Risiken auf jeden Fall zu den “wesentlichen“ Risiken gezählt werden müssen. Die (aufsichts-)rechtlichen Bestimmungen sind daher eine erste wichtige Quelle.
b) Die Auswertung von Schadensdatenbanken erweist sich leider meist als schwierig, da diese vertraulich sind und der Zugriff nur einem beschränkten Teilnehmerkreis ermöglicht wird. Hier können als Alternative die Meldungen aus der täglichen Presse – als sehr wichtiges Beispiel sei der silicon.de-Nachrichtendienst genannt – verwendet werden.
c) In Ergänzung zu den externen Nachrichten hilft auch häufig ein Kommunikationsaustausch mit befreundeten Partnerunternehmen oder Kollegen anderer Firmen, eine Unterstützung durch übergeordnete Verbände (und auch Handwerkskammern) sowie Konzernzentralen oder eventuell ein Blick in die Informationsbestände konkurrierender Institutionen. Auch eine Analyse der Risikolisten von externen Dienstleistern (im Rahmen eines Outsourcing), von Töchtern eines Konzerns oder von Kunden können dem Risiko-Verantwortlichen weiterhelfen.
d) Wer nicht auf externe Unterstützung verzichten möchte, kann auf externe Berater zurückgreifen. Diese sind darauf spezialisierte Unternehmen oder Einzel-Berater mit Background IT-Risikomanagement. Hierbei sollten Wirtschaftsprüfer, Aufsichtsämter oder Revisoren nicht ausgespart werden, da diese im Umfeld IT-Risikoidentifizierung große Erfahrung aufzuweisen haben und gern gesehene Lieferanten für Hinweise sein können. Teilweise bieten auch Unternehmen Seminare oder Tagungen an, mit Inhalten bezüglich Risiken in Projekten, in Verträgen oder bei Auslagerungen.
e) Last but not least sollten individuelle Risiken immer aktuell und auf die einzelne Institution zugeschnitten sein. Man wird daher nicht darum herum kommen, im Rahmen von internen Workshops (-> brain storming, Analyse der Geschäfts- und IT-Ziele sowie derer Strategien) spezifische IT-Risiken, die sich an der Institution wie auch am fokussierten IT-Risiko-Objekt auszurichten haben, erarbeiten zu müssen. Das Top-Management muss hierbei unabdingbar einbezogen werden. Interne Schadensdatenbanken, interne Projektabschlussdokumentationen, interne Meldearchive und “alte, erfahrene“ Mitarbeiter können im Laufe der Zeit für eine Vollständigkeit der wesentlichen Risiken sorgen.
Fazit
Nicht die (aufsichts-)rechtlichen Vorgaben sind Anlass für ein Risikomanagement. Risiken sind ein Bestandteil der alltäglichen Arbeit und sollten dementsprechend im Rahmen einer Corporate Governance selbständig einer Kontrolle und Steuerung unterworfen werden. Die Risikoidentifikation ist hierbei der wichtigste erste Schritt. Revisoren, Wirtschaftsprüfer und Aufsichtsämter prüfen nur die korrekte Umsetzung und Aktualisierung der Risikoprozesse in größeren Institutionen.
Risiken zu identifizieren ist kein “Ein-Mann-Job“. Nicht DER Projektleiter oder DER CIO legen die Risiken fest. Risikoidentifizierung ist Aufgabe einer Gruppe. Es macht Sinn, die für ein Unternehmen “wesentlichen“ und “aktuellen“ Risiken – abhängig von den Geschäftszielen und Geschäftsstrategien – zentral bestimmen zu lassen und im Rahmen einer Risikotabelle den Mitarbeitern an die Hand zu geben. Hierdurch wird der zentralen Verantwortung durch das Top-Management Sorge getragen und eine Einheitlichkeit innerhalb der Institution sichergestellt.
Da die zu identifizierenden Einzel-Risiken am individuellen Risiko-Objekt ausgerichtet und möglichst vollständig erfasst werden müssen, bedarf es der weiteren Ausformulierung und Anpassung durch die entsprechenden Objekt-Verantwortlichen. Auf die “wesentlichen“ Risiko-Objekte wird in einer der nächsten Beiträge eingegangen.
