Die Unternehmens-IT in Abhängigkeit von den BAIT | IT-Projekte, Anwendungsentwicklung

Für die IT von Kredit- und Finanzdienstleistungsinstituten in Deutschland gelten regulatorische Vorgaben. In meiner Beitragsreihe „Die Unternehmens-IT in Abhängigkeit von den BAIT“ beleuchte ich die allgemein gehaltenen Formulierungen der "Bankaufsichtlichen Anforderungen an die IT" – und gebe Ihnen konkrete Handlungsempfehlungen für die Umsetzung mit auf den Weg. Im sechsten Teil der Beitragsreihe werfe ich einen Blick auf Kapitel 6 – IT-Projekte, Anwendungsentwicklung.

Projekte sind zeitlich, inhaltlich und budgetmäßig begrenzte Vorhaben, die von einem Projektteam bearbeitet werden und die Bereitstellung eines IT-Systems oder von IT-Services zum Ziel haben.

Auslöser für den Start von IT-Projekten können sein:

• Anforderungen von Fachabteilungen oder der Unternehmensleitung
• Probleme mit bestehenden IT-Anwendungen oder -Services
• Neue gesetzliche Auflagen, organisatorische Veränderungen oder technologische Erfordernisse
• Ergebnis der Priorisierung des Projektportfoliomanagements oder der langfristigen IT-Planung

Die Umsetzung dieser gewollten Veränderungen geschieht im Rahmen von IT-Projekten. Diese bringen neben Chancen aber auch Risiken mit sich. Ein Hauptziel der BAIT ist es, ein Risikobewusstsein zu entwickeln, im IT-Projekt die Risiken zu entdecken und entsprechend mit Maßnahmen zu belegen.

Dies wird in der BAIT-Anforderung 31 deutlich:

„Wesentliche Veränderungen in den IT-Systemen im Rahmen von IT-Projekten, deren Auswirkung auf die IT-Aufbau- und IT-Ablauforganisation sowie die dazugehörigen IT-Prozesse sind im Rahmen einer Auswirkungsanalyse zu bewerten (vgl. AT 8.2 Tz. 1 MaRisk). Im Hinblick auf den erstmaligen Einsatz sowie wesentliche Veränderungen von IT-Systemen sind die Anforderungen des AT 7.2 (insbesondere Tz. 3 und Tz. 5) MaRisk, AT 8.2 Tz. 1 MaRisk sowie AT 8.3 Tz. 1 MaRisk zu erfüllen.“

Bei der Auswirkungsanalyse geht es darum, bereits vor der Umsetzung von wesentlichen Veränderungen die daraus entstehenden Auswirkungen zu bewerten. Dabei wird geprüft, wie sich die Veränderung auf die Komponenten eines betroffenen Informationsverbunds (der aus Hardware, Software, Middleware, Anwendungen und Services bestehen kann) auswirken.

Auf diese Weise stehen auch Einschätzungen zu den Risiken zur Verfügung, so dass geeignete Maßnahmen zur Risikominimierung definiert werden können. Hierbei gilt immer der Grundsatz der „doppelten Proportionalität“, nach der das Risikoprofil des Kreditinstituts zu berücksichtigen ist. Entscheidend ist der Umfang der Geschäfte, das Geschäftsmodell und die Komplexität der Risiken.

Weiterhin wird im Rahmen der Auswirkungsanalyse untersucht, ob die vorhandenen Kontrollverfahren und die Kontrollintensität verändert werden müssen und ob die internen Kontrollsysteme (IKS) weiterhin funktionsfähig und ausreichend sind. Bei dieser Untersuchung müssen die Organisationseinheiten eingeschaltet werden, die später in die Arbeitsabläufe eingebunden sind (AT 8.2 Tz. 1 MaRisk).

Die BAIT-Anforderung 32 verlangt:

„Die organisatorischen Grundlagen von IT-Projekten (inkl. Qualitätssicherungsmaßnahmen) und die Kriterien für deren Anwendung sind zu regeln.“

Dies bezieht sich auf die organisatorische Einbettung von IT-Projekten in die Organisation. Die IT-Aufbauorganisation definiert die statische Struktur der IT eines Unternehmens und benennt die Stellen und Positionen in ihr, während die IT-Ablauforganisation dynamische Arbeitsprozesse beschreibt und sich auf die Aktivitäten und deren Reihenfolge konzentriert. Beides wird definiert und beschrieben.

Die Geschäftsleitung definiert die Unternehmens- und die IT-Strategie. Beide werden im Rahmen eines Projektportfoliomanagements und einer Projektmanagementorganisation anhand eines Projektmanagement Frameworks (Vorgehensmodells) umgesetzt.

Das Framework definiert, wann welche Teile daraus - abhängig vom Projekttyp, von der Projektgröße und von den Projektrisiken - daraus angewendet werden und enthält auch Regelungen zum Qualitätsmanagement.

BAIT-Anforderung 33 stellt auf die Steuerung von Projekten ab: „IT-Projekte sind angemessen zu steuern, insbesondere unter Berücksichtigung der Risiken im Hinblick auf die Dauer, den Ressourcenverbrauch und die Qualität von IT-Projekten. Hierfür sind Vorgehensmodelle festzulegen, deren Einhaltung zu überwachen ist.“

Damit eine strukturierte, geordnete und nachvollziehbare Arbeitsweise bei IT-Projekten gewährleistet ist, wird ein Vorgehensmodell zum Projekt-, Qualitäts- und Changemanagement definiert und eingesetzt. Das Vorgehensmodell kann ein klassisches Modell sein (Wasserfallmodell), ein agiles Modell oder eine Mischung aus beiden (Hybridmodell).

Das Vorgehensmodell ist in Arbeitsanweisungen und den dazugehörenden Arbeitshilfen (Templates) beschrieben. Weiterhin werden die Organisationsstruktur, sowie die Berichts- und Eskalationsverfahren dargestellt. Eine Organisationseinheit - oft im Stab angesiedelt - überwacht im Unternehmen die Einhaltung der Regelungen des Vorgehensmodells.

Das Projektmanagement beschreibt die Phasen eines IT-Projekts, die Ergebnisse, die beteiligten Rollen, die Kontrollmechanismen und enthält Regelungen zum Risikomanagement. Im Risikomanagement ist ein Template zur Risikoanalyse definiert und es ist beschrieben, wie Risiken zu finden und zu beschreiben sind. Weiterhin wird geregelt, wie Maßnahmen zur Risikoreduktion oder -übertragung zu definieren sind und wie die Wirksamkeit dieser Maßnahmen überprüft wird.

Die Grundlage für die Projektsteuerung sind die freigegebenen Projektpläne. Wenn Arbeitspakete umgesetzt werden, dann werden Ist-Daten wie Ist-Anfang, Ist-Aufwand, Ist-Kosten, Ist-Qualität erfasst und im Projektcontrolling festgehalten.

Der Projektstatus wird festgestellt, in dem die Ist-Daten mit den Plandaten verglichen werden. Bei Abweichungen sind dann Projektsteuerungsmaßnahmen erforderlich. Weiterhin wird die Entwicklung der Risiken betrachtet und es werden ggf. weitere Maßnahmen eingeleitet.

Gemäß der Anforderung 33 sind IT-Projekte angemessen zu steuern. Es ist daher nicht immer erforderlich, jede Veränderung mit maximalem Einsatz von Projektmanagement zu begleiten, sondern mit einem dafür angemessenen Aufwand. Hierzu wird die Größe des Projekts, die Projektart, die Bedeutung und das Risiko des IT-Projekts beurteilt und die erforderliche und sinnvolle Tiefe des Projektmanagement-Einsatzes definiert.

Die Angemessenheit lässt sich auch an der Klassifizierung der Daten festmachen, die durch das Projekt verändert werden. Die Daten werden hierbei über den Schutzbedarf klassifiziert, der die Aspekte Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität betrachtet.

Angemessene Steuerung des Projektportfolios dank eines gezielten Projektportfoliomanagements

Die BAIT-Anforderung 34 verlangt:

„Das Portfolio der IT-Projekte ist angemessen zu überwachen und zu steuern. Dabei ist zu berücksichtigen, dass auch aus Abhängigkeiten verschiedener Projekte voneinander Risiken resultieren können.“

und

„Die Portfoliosicht ermöglicht einen Überblick über die IT-Projekte mit den entsprechenden Projektdaten, Ressourcen, Risiken und Abhängigkeiten.“

Ein Projektportfolio ist die Zusammenfassung aller geplanten, genehmigten und laufenden Projekte eines Unternehmens. Ein Projektportfolio ist zeitlich nicht befristet und ist daher eine Linienaufgabe.

Projektportfoliomanagement (PPM) ist die permanente Planung, Priorisierung, projektüber-greifende Steuerung und Überwachung aller Projekte einer Organisation.

Ziel des PPMs ist es, die richtigen Projekte zur rechten Zeit mit den richtigen Ressourcen durch-zuführen. Es sollen die Projekte durchgeführt werden, die zwingend durchzuführen sind (z.B. zur Umsetzung von regulatorischen Vorgaben) oder die die Unternehmensstrategie unterstützen. Dazu wird eine gesamtheitliche Sicht auf die Projekte eingenommen.

Die Hauptaufgaben des PPMs sind:

• Projektideen bewerten
• Projekte priorisieren und in das Projektportfolio aufnehmen
• Abhängigkeiten zwischen Projekten erkennen und verwalten
• Projektportfolio überwachen und steuern
• Risiken im Projektportfolio bewerten und steuern
• Projekte unterbrechen oder beenden
• Projektübergreifendes Ressourcenmanagement

Die im PPM betrachteten Projektideen und Projekte müssen eine Mindest-Planungsqualität aufweisen, damit man ihre Zielerreichungs- und Risikobeiträge in vergleichbarer Weise bewerten kann. Daher sind zwingend klare Projektaufträge mit eindeutig formulierten Projektzielen sowie standardisierte Projektstatusberichte erforderlich.

Das PPM zielt auf die Optimierung aller aktiven Projekte im Projektportfolio. Es soll der maximale Nutzen des Projektportfolios erreicht werden, wobei finanzielle und ressourcenmäßige Restriktionen beachtet werden müssen.

Die strategische Portfoliosteuerung hat die Aufgabe, in regelmäßigen Abständen sicherzustellen, dass die richtigen Projekte ausgewählt und durchgeführt werden und ob der durch die Projekte entstehende Nutzen noch vorhanden ist („rollierende Portfolioplanung“).

Bei der operativen Portfoliosteuerung werden in regelmäßigen Abständen die Projektstatusberichte und die darin enthaltenen Kennzahlen der Projekte konsolidiert und analysiert. Dabei werden vorhandene Abhängigkeiten und Zielkonflikte - insbesondere zu Ressourcen - zwischen Projekten beachtet und gelöst.

Damit Entscheidungen zur Aufnahme von Projekten in das Projektportfolio sinnvoll und nachvollziehbar getroffen werden können, werden die Projekte, die gestartet werden können, mittels Priorisierung in eine Projektrangliste gebracht.

Auf Portfolioebene muss ein transparenter Status zu den einzelnen Projekten vorliegen. Dazu werden monatlich die Projektstatusberichte aller laufenden Projekte gesammelt und die darin enthaltenen Kennzahlen zu beispielsweise Terminen, Kosten, Risiken und Ressourcen in ein PPM-Cockpit übertragen. Dadurch werden Abweichungen sichtbar.

Die Priorisierung der Projekte kann wie folgt geschehen:
 

Diese Abhängigkeiten zwischen Projekten müssen erkannt werden und fließen in die Priorisierung der Projekte ein, die gestartet werden können. Aus den Abhängigkeiten heraus entstehen Risiken, die sich nicht auf ein einzelnes Projekt beziehen, sondern auf das Projektportfolio als Ganzes.

Dabei können sich Risiken aus Einzelprojekten summieren und ein größeres Risiko im Projektportfolio erzeugen. Benötigt z.B. ein Projekt Ergebnisse aus einem anderen Projekt und diese Ergebnisse werden nicht geliefert, dann gerät das abhängige Projekt in Verzug und das Risiko der Nicht-Planeinhaltung für dieses Projekt steigt signifikant.

Generell wirkt sich das Verkleinern von Risiken auf die Investitionen bzw. den Aufwand aus, denn die Verminderung der Eintrittswahrscheinlichkeit oder des maximalen Schadens kostet Ressourcen. Reduziert man in anbahnenden IT-Projekten die Risiken durch Maßnahmen auf ein vom Kreditinstitut akzeptiertes Maß, können die Projekte dadurch ggf. unwirtschaftlich werden.