Ausgangslage
Die Umsetzung neuer oder geänderter regulatorischer Anforderungen wird zunehmend komplexer. Weshalb ist das so? Dafür gibt es mehrere Gründe:
Einer davon ist sicher, dass die Anforderungen zunehmend mehr Themen verknüpfen. Ein Beispiel ist die Einlagensicherung. Zu Beginn musste die Bank einfach in der Lage sein, die entsprechenden Zahlen (Beträge pro Person) innert nützlicher Frist zu liefern. Dazu war vielleicht der eine oder andere manuelle Schritt notwendig (bspw. die Berücksichtigung der Nummernkunden, oder bei den Vorsorgegeldern etc.). Nun muss mind. ein Teil dieser Information auch im LCR verwendet werden. Das bedeutet, dass auch der umgesetzte Mechanismus der Einlagensicherung ggf. angepasst werden muss, was wiederum ein Testing etc. Bedarf. Oder die Information des wirtschaftich Berechtigten nach VSB wird nun auch für die Steuerthemen relevant. Die Steuerdaten werden aber vielleicht in einem separaten System gepflegt, wodurch es eine neue Schnittstelle braucht. Die Liste könnte weiter fortgeführt werden.
Ein weiterer Grund basiert teilweise auf dem ersten: Die Systeme werden immer komplexer. Es braucht immer mehr Schnittstellen, weil immer mehr Daten und Funktionen geteilt werden müssen. Zugleich kann man je nach System aus zeitlichen Gründen nicht immer alles architektonisch perfekt lösen. Damit schafft man sich Restanzen (Architektur-Defects), mit denen man sich dann früher oder später wieder herumschlagen muss.
Schliesslich werden die Anforderungen nicht weniger, zumal auch die Umsetzungsdauer mind. teilweise länger wird. Dadurch muss parallel an verschieden Anforderungen gearbeitet werden, was automatisch zu mehr Komplexität führt (dies vor allem auch im IT-Betrieb und der Organisation).
Zusätzliche Problemstellungen
Mit all dem würde eine gute Softwareentwicklung (mit einem guten IT-Betrieb) in aller Regel noch gut zurecht kommen. Wären da nicht auch noch die oft hausgemachten Probleme.
Und davon gibt es gleich drei:
1) Oftmals und immer mehr, gerade als kleinere Bank, hat man verchiedene Umsetzungsvarianten. Man kann es vollständig umsetzen, man darf unter gewissen Umständen gewisse Anforderungen weglassen, oder man kann sich durch Verzicht (bspw. auf ein Geschäft, ein Produkt oder eine Kundengruppe) fast ganz aus der Affähre ziehen. Diese Entscheidung liegt aber beim Management. Und das Problem entsteht dann, wenn die Verantworltichen nicht oder sehr spät entscheiden. Nämlich dann, wenn man mit der Umsetzung bereits beginnen musste.
2) Das kennen alle: Verändernde Anforderungen bedeuteten schon vielen Projekten den zeitlichen oder finanziellen Tod. Die Fachverantwortlichen können sich ebenfalls nicht entscheiden oder befassten sich eingangs zu wenig mit der Materie und stellen dann später fest, dass es so nicht wie gewünscht funktioniert.
3) Es wird nicht unterschieden zwischen Use-Cases die oft vorkommen (die Regel) und solchen die (sehr) selten vorkommen (die Ausnahme). Die Regel muss technisch elegant sein und den Benutzer maximal unterstützten. Die Ausnahme wird nicht selten von einem Fachspezialisten behandelt und darf technisch ruhig etwas weniger elegant sein. Oftmals definieren aber die betroffenen Fachspezialisten die Anforderungen und die sehen natürlich nur die Ausnahmen, mit denen sie dann später zu tun haben werden.
Lösungswege
Die Lösung habe ich natürlich auch nicht. Sonst würde ich kaum diesen Blog schreiben (sondern mich in der Sonne bräunen). Die nachfolgende Grafik dient den auch mehr als Denkanstoss wie es sein könnte.
Sie können das Bild hier grösser herunterladen.
Es sind alle Beteiligten gefordert. Wenn das Management zu Beginn (1) rechzeitig die wichtigen Entscheidungen fällt, die IT-Entwicklung (2) vorausschauend definiert wie die Architektur ausschauen soll und man sich bei der konkreten Umsetzung (3) mit den Fachabteilungen rasch darauf einigt, was die Regel und was die Ausnahme ist, dann können auch immer komplexere regulatorische Anforderungen in angemessener Zeit, der richtigen Qualität und zu vernünftigen Kosten umgesetzt werden.
Versuchen Sie doch beim nächsten Umsetzungsprojekt, alle Beteiligten bei Projektbeginn für die Wichtigkeit dieser drei Elemente zu sensibilisieren.
Keine Kommentare:
Kommentar veröffentlichen