Die Balanced Scorecard (BSC) teilt eine Organisation traditionell in vier Perspektiven ein: Finanzperspektive, Kundenperspektive, interne Prozessperspektive und Lern- und Wachstumsperspektive (Kaplan und Norton, 1997).
Lawrence (2002) weist darauf hin, dass die BSC in jeder ihrer Perspektiven Antworten auf vier relevante Fragen gibt:
Wer die IT-Aufsicht im Versicherungssektor verstehen will, kommt an einem Kürzel nicht vorbei: VAIT – die versicherungsaufsichtlichen Anforderungen an die IT. Hinter dem Begriff verbirgt sich kein reines Technikpapier, sondern eine klare Erwartungshaltung der Aufsicht an Governance, Organisation und Betrieb der IT bei Versicherungsunternehmen. VAIT macht deutlich: IT ist nicht Hilfsdisziplin, sondern Kern der Wertschöpfung – vom Antrag bis zur Leistung, vom Aktuariat bis zur Kapitalanlage, vom Vermittlerportal bis zum Schadenworkflow. Dieser Beitrag ordnet VAIT ein, erklärt die gemeinsame Logik hinter den Kapiteln und zeigt, welche Schritte Versicherer jetzt konkret gehen sollten, damit „VAIT-konform“ nicht auf dem Papier endet, sondern im Alltag wirkt.
Versicherung ist Informationsverarbeitung: Tarifierung, Bestandsführung, Leistungsprüfung, Meldewesen – alles beruht auf Daten, Anwendungen und vernetzten Prozessen. Störungen sind daher nicht nur IT-Probleme, sondern Geschäftsrisiken. Genau hier setzt VAIT an. Das Rundschreiben übersetzt die bekannten Grundsätze guter Geschäftsorganisation in die IT-Wirklichkeit des Versicherers: verantwortliche Leitung, risikobasierte Steuerung, nachweisbare Wirksamkeit. Die Ausrichtung ist prinzipienorientiert und proportional: Es gibt Ziele und Mindeststandards, aber keine Einheitscheckliste. Tiefe und Taktung richten sich nach Geschäftsmodell, Komplexität und Kritikalität.
Scrum ist eine Teilmenge von Agile und repräsentiert ein Rahmenwerk für agile Entwicklungsprozesse, das sich durch seine Leichtgewichtigkeit und Anpassungsfähigkeit in der komplexen Produkt- und Softwareentwicklung als besonders effektiv erwiesen hat. Es hat sich aufgrund seiner Praxisnähe und Effizienz als das führende Prozess-Framework etabliert.
Unter einem "Prozess-Framework" versteht man eine Sammlung von Praktiken und Richtlinien, die, wenn sie eingehalten werden, sicherstellen, dass der Entwicklungsprozess im Einklang mit dem zugrunde liegenden Framework steht. Scrum zeichnet sich durch seine iterativen Entwicklungszyklen, bekannt als Sprints, aus, während andere Frameworks wie Extreme Programming (XP) eigene spezifische Praktiken wie Pair Programming vorschreiben.
Die Phase Service Strategy beschäftigt sich primär mit dem Verständnis der Unternehmensstrategie sowie der Synchronisation mit einer wettbewerbsfähigen IT und daraus abgeleiteten Kundenvorteilen. Die Herausforderung stellt die Integration der Informationstechnologie in die Geschäftsprozesse dar. Die IT wird nicht mehr nur Mittel zum Zweck, sondern als ein integraler Bestandteil zur Erreichung der Unternehmensziele gesehen. Ein zentraler Kerngedanke in dieser Phase ist die Wertschöpfung von IT-Services für das Business, die sich im Servicemanagement in die Begriffe "Utility" und "Warranty" aufteilen. Utility steht für die grundsätzliche Brauchbarkeit und Nützlichkeit von Services. Die Warranty zielt zusätzlich auf Gewährleistung, Verfügbarkeit und Zuverlässigkeit von IT-Dienstleistungen.
In diesem Zusammenhang wird in der Literatur der Service Lifecycle genannt, der in ITIL den Kerngedanken darstellt. Die Informationstechnologie darf die bereitgestellten Services nicht als einzelne und für sich abgeschlossene Prozesse verstehen, sondern muss einen fließenden Übergang von der Planung, der Inbetriebnahme bis zu den Änderungen der Komponenten und abschließend der Stilllegung sehen. Alte und nicht mehr benötigte Services dürfen nicht länger in Betrieb sein, sondern müssen aus ökonomischer Sichtweise außer Betrieb genommen werden. "Phasing out of services is part of Service Transition. This is to ensure that all commitments made to customers are duly fulfilled and service assets are released from contracts. [...] This is necessary because such services may cost a lot more to support and may disrupt economies of scale and scope."
Wer zum ersten Mal mit den MaRisk in Berührung kommt – den Mindestanforderungen an das Risikomanagement der BaFin – hat meist zwei spontane Reaktionen: Respekt vor dem Umfang und den Verweisen, und Skepsis, ob das wirklich mehr ist als eine Dokumentationspflicht für Prüfer. Genau hier lohnt sich der zweite Blick. MaRisk ist kein Selbstzweck und keine reine Compliance-Schablone. Hinter den Passagen verbirgt sich ein Betriebssystem für Banken, das darüber entscheidet, ob ein Institut gesteuert wird oder sich steuern lässt. Es beschreibt die Logik, nach der Entscheidungen nachvollziehbar getroffen, Risiken bewusst eingegangen und Überraschungen reduziert werden.
In diesem Artikel geht es darum, MaRisk wirklich zu verstehen – nicht aus der Perspektive der Paragraphen, sondern aus der Praxis: Wozu gibt es das Rundschreiben, wie ist es aufgebaut, wo liegt der Nutzen, wie lässt es sich wirksam leben? Dabei kommen wir ohne juristischen Zierat aus und übersetzen die Kerngedanken in Alltagssprache – mit Beispielen, knappen Strukturelementen und einem klaren Ziel: MaRisk als Hebel zu begreifen, nicht als Last.
