Prozessmodellierung für mobile Systeme

Den mobilen Bankkunden haben sich nicht die Finanzinstitute ausgedacht. Mobil wurden die Kunden im Wesentlichen aus eigenem Antrieb: Notebooks, Netbooks und inzwischen vor allem Smartphones und Tablets haben die Nutzungsgewohnheit des Publikums in nur wenigen Jahren grundlegend und nachhaltig verändert. Die Ressourcen des Internets stehen heute immer und (fast) überall zur Verfügung und die Nutzer haben sich auf dieses Angebot eingestellt und nutzen sie intensiv. Schon ist absehbar, dass mobile Systeme für die Mehrzahl den Standardzugang ins Web bilden werden.

Für die Banken entstand damit eine neue Herausforderung. Sie mussten innerhalb kurzer Zeit – der sich schnell entwickelnde Markt sorgte für Druck – neue Systeme aufbauen, die mit mobilen Endgeräten zusammenarbeiten konnten. In Windeseile wurden mehr oder weniger ausgereifte Browser-Anwendungen oder Apps entwickelt, die mobiles Banking unterstützten. Da für einen systematischen Ansatz meist die Zeit fehlte – Apps haben natürlich andere Entwicklungszyklen als herkömmliche Bankensoftware – entstand auf diese Weise eine weitere Systemlandschaft neben den bestehenden Systemen: Zu den weitgehend eigenständigen Plattformen etwa für Kontoführung, Wertpapierhandel und Kreditbearbeitung, sowie dem relativ neuen Online-Banking, kam nun das neue Silo für die Backendfunktionen im mobilen Banking dazu. Die Banken-IT hatte damit eine neue Stufe der strukturellen Komplexität erreicht.

Bankgeschäfte mobil erledigen

Dabei ist die Komplexität der Funktionen im Mobile Banking ohnehin hoch, deutlich höher als etwa bei mobilen Anwendungen für Versicherungen. Anfänglich begnügten sich die Institute damit, grundlegende Informationen anzubieten, etwa über den Kontostand oder den Weg zur nächsten Filiale. Das reicht längst nicht mehr. Wenn Smartphone und Tablet für viele Bankkunden den einzigen Weg ins Web darstellen, dann bedeutet das, dass eben auch alle Bankfunktionen auf diese Weise verfügbar gemacht werden müssen: Der Kunde erwartet auf seinem mobilen Gerät tendenziell den kompletten Leistungsumfang seiner Bank, also zum Beispiel auch Wertpapiergeschäfte, Kreditvergabe. Wenn das mobile Systems sein einziger Zugang ist, will (und muss) der Kunde auch komplexe Prozesse mobil erledigen können, beispielsweise die Regelung von Nachlassangelegenheiten. Eine Bank, die hier die Auskunft erteilen muss „Bitte nur persönlich in der Filiale“, hätte schlechte Karten, nicht zuletzt gegenüber den reinen Online-Instituten.

Noch komplexer wird die Sache, wenn man in Rechnung stellt, dass die Mehrzahl der Bankkunden nicht ausschließlich einen Kanal benutzen. Auch wer überwiegend mobil arbeitet, wird gelegentlich die Bankfiliale aufsuchen oder auf herkömmliche Weise ins Web gehen. Dabei erwartet er, dass angefangene Prozesse in einem anderen Kanal fortgeführt werden können. Wer eine Beispielrechnung für ein Darlehen im Web angefangen hat, möchte diese vielleicht mit einem Bankberater persönlich besprechen – ohne dass dieser alle Daten erneut erfassen muss. Wer seine Bank mit einem Wertpapiergeschäft beauftragt hat, möchte vielleicht von unterwegs nachschauen wie es ausgeführt wurde. Solche kanalübergreifenden Funktionen unter Einbeziehung des mobilen Kanals können heute die wenigsten Banken darstellen. Sie scheitern hier an der Komplexität der Systeme, sowohl am Frontend als auch bei den silo-artigen Backendsystemen.

Im Grunde sind diese Herausforderungen wie geschaffen für den Einsatz von Geschäftsprozessmanagement und -modellierung: Komplexe Prozesse strukturieren, ihre Zusammenhänge erkennen und so abbilden, dass sie die Beteiligten verstehen und jederzeit nachvollziehen können, schließlich auch Fehlerstellen, Schwachpunkte und Brüche aufdecken. Etablierte und bewährte Modellierungswerkzeuge wie Aris oder Adonis sind denn auch in der Lage nicht nur den Ist-Zustand einer solchen Prozessstruktur aufzunehmen und transparent zu machen, sondern dienen auch dazu einen Soll-Zustand zu definieren und darzustellen. So nützlich solche Werkzeuge für die Analyse sein können, das Ergebnis ist jedoch nicht mehr als eine Dokumentation. Das ist ohne Zweifel hilfreich und nützlich, beispielsweise für neue Mitarbeiter, Unternehmen brauchen aber mehr: lauffähige Applikationen, sowohl für die internen Prozesse als auch beispielsweise als Apps auf den Geräten der Kunden, die die Informationen aus allen Silos verarbeiten können. Doch sie haben weder Zeit noch Ressourcen solche Anwendungen neu aufzubauen.

Die Lücke zwischen modellierten Prozessen und realen Applikationen schließen modellgetriebene Lösungen wie zum Beispiel Pega BPM. In diesen Lösungen stellt das System eine prozessorientierte Oberfläche zur Verfügung, darunter werden die diversen internen Systeme zusammengekoppelt, vollständig transparent gegenüber dem Nutzer, der nur mit einem System arbeitet. Die Prozesslogik wird in einem Layer-Modell nur einmal modelliert und dann rollen- und gerätespezifisch auf den unterschiedlichen Endgeräten bereitgestellt. Die Differenzierung des Outputs für stationäre und für mobile Systeme, aber auch hinsichtlich unterschiedlicher Kanäle, erfolgt hier und nicht auf der Ebene der Prozess- und Geschäftslogik.
Auf diese Weise können Banken kurzfristig funktionell neue Anwendungen aufbauen, die auch die mobilen Systeme umfassen, ohne dass dafür komplett neue Architekturen geschaffen werden müssten. Die ersten Erfolge, die derart modellgetriebene Lösungen gerade im Bereich Finanzdienstleister aufweisen, zeigen, dass sich hier ein Ausweg aus der Komplexitätsproblematik öffnet.

Hintergrund:
Die Schicht macht's: Homogenität für den Gerätezoo

Die Differenzierung des Outputs für stationäre und mobile Systeme erfolgt bei Pega BPM nicht auf der Ebene der Geschäftslogik. Das System erkennt selbst, welche Endgeräte auf die Anwendung zugreifen; die Unterscheidung etwa hinsichtlich Betriebssystem, Bildschirmgröße oder Auflösung, wird auf einer separaten Ebene vorgenommen. Gemäß dem Responsive-Stream-Layout wird etwa anhand der Bildschirmgröße des Empfängers festgestellt, ob die darzustellenden Daten auf einen Bildschirm passen oder ob sie über mehrere verteilt werden müssen, zum Beispiel auf einem Smartphone. Auf dieser Schicht lassen sich zum Beispiel auch Mikrofon, Kamera oder GPS als Ansatzpunkte für Mehrwertdienste nutzen. So können Banken ohne großen Aufwand im gesamten „Gerätezoo“, der in der mobilen Welt mittlerweile entstanden ist, nicht nur identische Geschäftsprozesse ausführen, sondern auch für ein einheitliches Erscheinungsbild auf ganz unterschiedlichen Systemen sorgen.

Bildquelle: Herbert Walter/Pixelio.de