Pragmatisches Management von VAIT-Projekten

Banken und Versicherungen sind stark regulierte Branchen, die einer Vielzahl von Gesetzen, Verordnungen, Vorgaben und Richtlinien unterliegen. Deren Einhaltung wird durch unterschiedliche Aufsichtsorgane auf verschiedenen Ebenen – mehrfach und nicht immer untereinander widerspruchsfrei – geprüft. Die Finanzkrise im Jahr 2008 trug im Übrigen nicht unwesentlich dazu bei, dass die regulativen Vorgaben weiter verschärft wurden.

Ein jüngeres Beispiel für gesetzliche Vorgaben stellen die „Versicherungsaufsichtlichen Anforderungen an die IT“ (VAIT) der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) dar. Hier hat die BaFin ihre Erwartungen an die IT von Versicherungsunternehmen definiert. Nur am Rande: Ähnliche Vorgaben hat die BaFin bereits mit den „Bankaufsichtlichen Anforderungen an die IT“ (BAIT) innerhalb des Bankensektors gemacht.

Die drei Phasen regulatorischer Projekte

Wie ihr euch denken könnt, stehen in der Versicherungsbranche regulatorische IT-Projekte auf der Tagesordnung. Schließlich verändern sich die Anforderungen stetig und Anpassungen an die IT werden notwendig. Dabei haben diese Projekte genaue Zielvorgaben:

• Erfüllt die gestellten Anforderungen, aber nicht mehr.
• Liefert eine günstige Lösung, die in der Praxis möglichst wenig Zusatzaufwand bedeutet, die etablierte Arbeitsweisen weitgehend übernimmt und die nur das verändert, was verändert werden muss.
• Nutzt hierbei sinnvoll Spielräume und Interpretationsmöglichkeiten.

Meiner Erfahrung nach, laufen solche Projekte in drei Phasen ab, die alle durchlaufen werden müssen. Wer hier vorzeitig aussteigt, der verliert. Diesen dreiphasigen Ablauf, möchte ich euch näher vorstellen. Erlebt habe ich ihn unter anderem in einem Kundenprojekt am achten Kapitel der VAIT, das übrigens den etwas sperrigen Namen „Ausgliederungen von IT-Dienstleistungen und sonstige Dienstleistungsbeziehungen im Bereich IT-Dienstleistungen; isolierter Bezug von Hard- und/oder Software“ trägt.

Phase 1: Die leichte Schulter

Wenn ich zunächst so ein VAIT-Dokument lese, erscheint es oft etwas leichtgewichtig. Ich lese die Anforderungen und nicke bei jedem Punkt. Irgendwie ist das alles ziemlich selbstverständlich und gegebenenfalls geht es euch an dieser Stelle ähnlich. In dem Beispielprojekt sind vielleicht hin und wieder ein paar Themen aufgetaucht, die bisher nicht zu 100 Prozent VAIT-konform erfüllt wurden. Eventuell fehlte aber nur hier und da noch etwas Dokumentation und man würde das recht schnell hinbekommen.

Falls ihr nicht voll und ganz mit den einzelnen Formulierungen der VAIT vertraut seid, im achten Kapitel finden sich Sätze wie „Das Unternehmen hat … im Bereich der IT-Dienstleistungen … vorab eine Risikoanalyse durchzuführen“, „Die Erbringung der vom Dienstleister geschuldeten Leistung ist entsprechend der Risikoanalyse zu überwachen“ oder „Die aus der Risikoanalyse … abgeleiteten Maßnahmen sind angemessen in der Vertragsgestaltung zu berücksichtigen“.

Selbstverständlich hat sich der Kunde im Beispielprojekt Gedanken über die Risiken bei der Zusammenarbeit mit Dienstleistern gemacht, natürlich überwacht er die Leistung der Dienstleister und hat die entsprechenden Verträge ordentlich gestaltet. Was sollte hier noch verändert werden? Eigentlich könnte man nach ein paar Detailverbesserungen fast schon aussteigen, oder?

Phase 2: Der große Schreck

Leider kommt nach der ersten Euphorie recht schnell die Ernüchterung. Nachdem ich gemeinsam mit dem Kunden die Anforderungen noch einmal sehr sorgfältig gelesen habe, überlegte ich bei jedem Satz, was er genau bedeutet, wie man das Ganze auslegen und optimal umsetzen könnte und wie man die Umsetzung und die Einhaltung im Tagesbetrieb nachweisen kann. Dabei passierte folgendes: Das Projekt wurde vor dem geistigen Auge immer größer, die Änderungen immer umfangreicher und die notwendigen Eingriffe immer tiefgreifender. In einem solchen Kontext können sich dann Fragen ergeben wie beispielsweise:

• Welche Standards zu einer Risikoanalyse bei Dienstleistungen gibt es, die herangezogen werden können?
• Welche Aspekte müssen bewertet werden?
• Muss danach die Risikoanalyse ins operative Risikomanagement integriert werden?
• Ist das Ganze relevant nach Solvency II?
• Wie wird es dokumentiert?
• Wie handhabt man das für die ganze Fülle von Dienstleistungen und Lieferanten?

Erinnert ihr euch, anfangs war das Problem noch ganz klein, aber je länger darüber nachgedacht wird, desto größer wird es. Und große Probleme verlangen große Lösungen. In dem Projekt schwebten mir dann hochintegrierte, vollautomatisierte Lösungen vor, die in jede Richtung flexibel und für jede Eventualität und jeden Sonderfall gerüstet sind.

Phase 3: Der pragmatische Ansatz

Schließlich kommt die Phase der Konsolidierung. In dem angesprochenen Kundenprojekt kam schließlich die Frage auf, was überhaupt notwendig ist. Wurde zuvor zu viel in die einzelnen Formulierungen der VAIT hineininterpretiert und ist man über das eigentliche Ziel hinausgeschossen?

In der ersten Phase erschienen die Anforderungen einsichtig und sinnvoll - gesunder Menschenverstand wie man so schön sagt. Gleichzeitig arbeiten wir schon seit Jahren erfolgreich und häufig auch mit gesundem Menschenverstand. Die Diskrepanz sollte also eigentlich nicht allzu groß sein.

Nach dem Kopfzerbrechen innerhalb der zweiten Phase, sind pragmatische Ansätze gefragt. In diesem Rahmen solltet ihr folgende Fragen klären:

• Welche Punkte müssen unbedingt mustergültig und technisch unterstützt sowie realisiert werden?
• Wo kann man Anforderungen organisatorisch regeln – etwa durch Arbeitsanweisungen und Verfahren?
• Welche Sonderfälle gibt es, wie oft kommen sie vor und kann man diese auch außerhalb der Standardverfahren lösen?

Wenn ihr die Punkte unter diesen Aspekten analysiert, merkt ihr schnell, dass die Arbeitsweise weitgehend den Anforderungen der VAIT entspricht. Allerdings ist der Arbeitsablauf undokumentiert, die Risikoanalyse eher informell und die Ergebnisse nicht immer dokumentiert. Aber keine Sorge, hier kann man gut ansetzen. Im ITIL-Supplier-Management gibt es einen guten Standard, mit dem ihr Lieferanten und Dienstleistungen gruppiert und angemessen behandeln könnt.

Zurück zum Beispielsprojekt: Hier werden derzeit die Arbeitsweisen analog zu den Vorgaben dokumentiert und formalisiert. Die Arbeitsergebnisse werden nachvollziehbar erstellt und abgelegt und das bisherige System zur Vertragsverwaltung wird dahingehend modifiziert, dass es die Ergebnisse der Risikoanalyse verwalten kann. Bis es soweit ist, werden die Ergebnisse händisch erstellt und verwaltet.

Fazit

Ich habe diesen dreiteiligen Ablauf bereits in vielen regulatorischen Projekten so erlebt. Es ist wichtig, dass ihr euch in regulativen IT-Projekten dieser drei Phasen bewusst seid, denn das Schema wiederholt sich regelmäßig. Nur wenn euch dieser Verlauf bekannt ist, könnt ihr eine unvollständige oder zu umfangreiche Umsetzung vermeiden.

Ich habe eingangs gesagt „Wer hier vorzeitig aussteigt, der verliert“. Und das ist tatsächlich so, denn wenn ihr bereits in der ersten Phase aussteigt, werdet ihr die Anforderungen nicht erfüllen - ihr habt sie schließlich noch nicht vollständig verstanden. Steigt ihr direkt in die zweite Phase ein, werdet ihr bestimmt eine geeignete Lösung finden, aber diese ist möglicherweise vollkommen überfrachtet, wird wesentlich teurer sein und große Eingriffe ins Unternehmen notwendig machen.

So ergibt sich erst in der dritten Phase die optimale Balance aus vollständiger Erfüllung, akzeptablen Kosten und notwendigen Eingriffen.

Ihr möchtet erfahren, wie adesso euch im Rahmen der VAIT unterstützen kann? Dann werft auch einen Blick auf unsere Website.