Eine interessante Verhaltensänderung, die ein Softwarehersteller wie NAVAX Software bei ihren Bestands- und Neukunden beobachten kann, seitdem die Themen Veränderungen im Kundenverhalten, Digitalisierung, Automatisierung, neue Technologien und zunehmende, wenn nicht überbordende Regulatorik den Geschäftsalltag bestimmen.
Aber eigentlich ist es der alte Streit: „IT follows Business“ vs. „Business follows IT“.
Während bei einem Systemwechsel der Finanzdienstleister „früher“ seinem Service Provider genau die kundenspezifischen Prozesse vorgab und darauf achtete, dass die Funktionalität der über viele Jahre erweiterten und „mit viel Schmuck am Nachthemd“ angepassten Alt-Anwendung (ob selbst entwickelt oder gekauft) möglichst unverändert „in neu“ nachgebildet wurde, ist nun oft ein anderes Verhalten zu beobachten.
Offen für Challenges: Bewährt, nur noch nicht bei mir
Viele Finanzdienstleister sind bereit, den einen oder anderen alten Zopf abzuschneiden. Sie lassen sich konfrontieren mit Prozessen, die sich bei anderen Kunden des Service Providers bewährt haben. Die Aussage „Das haben wir immer schon so gemacht“ lädt ein, es künftig in Frage zu stellen und in (fast) jedem Fall anders, moderner, schlanker, effizienter zu machen.
Die Unique Selling Proposition eines Finanzdienstleisters leitet sich weniger aus einer spezifischen IT-Funktionalität ab, sondern mehr aus der (persönlichen oder digitalen) Kommunikation mit dem Kunden, der Fähigkeit und dem Willen, Risiken einzugehen, der Komfortabilität der Customer Journey vom Angebot über die Vertragserstellung bis hin zur regulären Abwicklung – oder Berücksichtigung von Sonderfaktoren (vorzeitige Ablösungen, Stundungsoptionen u. ä.). Das Gesamtbild, das der Kunde von „seinem“ Finanzdienstleister hat, ist entscheidend für den „Match“, die Customer Experience und in der Folge seine Loyalität zu seinem Finanzdienstleister.
Ebenso ist es zwischen dem Finanzdienstleister und „seinem“ Service Provider. Neue Technologien, integrierte, weitgehend frei gestaltbare Workflows, eine moderne IT-Architektur, die ein „Open Finance“, die Nutzung von Drittanbieter-, z. B. FinTech-Lösungen über moderne Schnittstellen(technologien) erlaubt, unterschiedliche Betriebsoptionen („Cloud-Computing“), die die trotz neuer Angriffsszenarien die Sicherheit erhöhen, all dies gibt neue Freiräume – ganz unabhängig vom aktuellen Hype-Thema der Künstlichen Intelligenz.
Die Flexibilität eines modernen Produktstandards
Die „Standard-Software“ eines modernen Herstellers, sein „Produkt“, ist heute deutlich mächtiger und leistungsfähiger als noch vor Jahren. Im Sinne eines „No-Code-Ansatzes“ wird es den Nutzern ermöglicht, ihre spezifischen Anforderungen über eine Business Process Modeling Notation (BPMN) und eine ergänzende Entscheidungslogik (Decision Modeling Notation / DMN) abzubilden.
Der Gegensatz löst sich mehr und mehr auf. Individualisierung wird im Produkt-Standard möglich – und schafft eine Win-Win-(Win-)Situation zwischen Software Hersteller und Finanzdienstleister (Bank, Leasing- oder Factoringgesellschaft oder Captive) – und deren privaten und / oder gewerblichen Kunden.
Was bedeutet das nun für ein Projekt, in dem der Finanzdienstleister eine neue, für ihn passende Software sucht?
Kurze Time-to-Market bei reduzierten Risiken
Im Idealfall – und so erfolgt es bei NAVAX Software – kann dem Finanzdienstleister in kurzer Frist eine Referenzumgebung mit Standardeinstellungen vorkonfiguriert zur Verfügung gestellt werden. Dann erfolgt der Proof of Concept: in einer Scopingphase werden Anforderungen und bestehende Funktionalität abgeglichen. Es wird gemeinsam um das „Was“, das Ergebnis, und nicht das „Wie“, den Weg, gerungen. So mag es sein, dass sich Prozesse verändern oder wegfallen oder neue hinzukommen. Dies erfordert in der späteren Umsetzung nicht nur die Umstellung auf (das Handling) eine/r neue/n IT, sondern eine gegebenenfalls weitere Transformation: Mitarbeiter werden i. d. R. von Routineaufgaben entlastet, haben aber neue, eher qualitätssichernde, kontrollierende oder administrierende Aufgaben zu übernehmen, z. B. die Validierung und Kalibrierung der Risk Policy, die Abbildung von (neuen) Angeboten über die Product Engine und Calculation Services.
Ungewöhnlich wäre, wenn ein Standard-Produkt „alle“ Anforderungen abdecken kann. Der Anteil des individuellen Gap Closings reduziert sich aber, insbesondere wenn über einen Business Case der Nachweis der Vorteilhaftigkeit zu erbringen ist. Auf der anderen Seite wird der Software-Hersteller bemüht sein, die Lösung in seinen Produkt-Standard zu übernehmen – unmittelbar oder zum Schutz der Intellectual Property (IP) des Kunden zu einem angemessenen späteren Zeitpunkt. So ist das individuelle Gap Closing (mit notwendiger Individualentwicklung, z. B. Erweiterung des Datenmodells und seiner Fähigkeiten) bei attraktivem Business Case durchaus opportun.
In einem Implementierungsprojekt (Wechsel auf eine neue Software) sollte ein Change Control Board über die Wunschliste, die nur über ein nicht-standardfähiges Gap Closing zu befriedigen ist, mit strenger Hand wachen, sind es doch die Folgekosten, die den Business Case belasten: der Software-Hersteller hat die individuellen Lösungen (separat) zu warten und weiterzuentwickeln, der Finanzdienstleister muss die Funktionalität bei der Übernahmen neuer Releases gesondert in User Acceptance Tests und ggf. System Integration Tests testen u. a. m.
Oft werden für eine Migration des bestehenden Geschäfts eine Anzahl von Gaps für den Go Live der neuen Software bereitzustellen sein. Nicht unbedingt notwendige Gaps sollten aber erst zu einem späteren Zeitpunkt geschlossen werden (z. B. in einer „Wave 2“), nachdem die Basis-Funktionalität bereits eingeführt ist – und läuft.
Zurück zum Standard
Interessant zu beobachten ist, dass auch in bereits langjährig bestehenden Geschäftsbeziehungen die Finanzdienstleister ehemals gewünschte Individual-Entwicklungen in Frage stellen und zurück zum Standard drängen.
Grund liegt sicher in der steigenden Komplexität des Geschäfts und dem Wunsch, diese durch – ggf. nicht mehr zu rechtfertigende – Individualitäten – nach Möglichkeit zurückzubauen. Gründe können – wie oft – ein Kostenfaktor sein: individuelle Wartung und Pflege, zusätzliche Tests bei Releasewechseln, schnell wechselnde bzw. steigende Anforderungen der Regulatorik (DORA) etc.
Vielleicht aber hat sich auch die Standard-Software weiterentwickelt, deckt die – ehemals individuell entwickelte – Funktionalität ab oder bietet andere Wege, die nun beschritten werden können, aber nicht regelmäßig geprüft wurden.
„IT follows Business“ oder „Business follows IT“?
Das Prinzip „IT follows Business“ bleibt ein zentrales Paradigma im IT-Management. Es betont, dass IT-Infrastrukturen die Geschäftsanforderungen unterstützen sollten, statt diese zu diktieren. Die Herausforderungen liegen auf der Seite der Software-Hersteller, die sich mit einer modernen IT-Architektur modular und einem zukunftsfähigen IT-Stack so aufstellen sollten, dass sie im Sinne von Open Finance eine maximale Flexibilität und Interoperationalität erreichen.
Da Finanzdienstleister nur das umsetzen können, was ihre IT ermöglicht, behält die Sicht „Business follows IT“ ihre Wirkmacht. Entscheidend ist die Balance, wobei flexible Technologien, eine Workflow-Basierung und eine maximale Administrier- und Konfigurierbarkeit (im Produkt-Standard), Geschäftsprozesse effizient zu unterstützen und individuell anzupassen, die entscheidenden Faktoren sind.
Damit kann bei modernen Lösungen eines erreicht werden: Individualisierung trotz Stick to Standard.
Wie sieht es in Ihrem Unternehmen aus? Profitieren Sie bereits von allen Vorteilen, die moderne, individuell anpassbare Produktlösungen wie unsere CMS oder HENRI Ihnen bieten?
In unseren Market & Innovation Talks informieren wir Sie über neue Funktionalitäten, prüfen weitere Möglichkeiten der Digitalisierung und Automatisierung – und diskutieren mit Ihnen, wie wir Ihr Geschäft noch besser unterstützen können. Kontaktieren Sie uns gern auch hier
