Umdenken notwendig - SAP HANA im Zahlungsverkehr
Eines der aktuellsten Trendwörter in der SAP Landschaft ist HANA. HANA gilt als revolutionäre Suite zur effektiven Datenhaltung und –verarbeitung die auf schnellen Arbeitsspeichern basiert Die Suite verspricht, dass vieles besser wird. Aber schaut man sich die aktuellen HANA-Zahlen und Installationen näher an, so liegt die Vermutung nahe, dass diese Technologie aktuell vorwiegend für spezielle Individuallösungen oder BI Systeme genutzt wird. Der gewünschte Massenmarkt bleibt vorerst noch aus.
Warum ist das so? Zur Beantwortung dieser Frage muss man etwas ausholen und umdenken:
Der revolutionäre Ansatz der Datenhaltung: „ONE and in realtime“
Ursprünglich verfolgten Plattner & Zeier das Ziel, ein System zu etablieren, welches die transaktionale und analytische Welt wieder vereint. Und das somit die Daten auf der kleinsten granularen Ebene nur einmalig vorhält. Die Bearbeitung und Auswertung dieser Daten erfolgt in Echtzeit. Möglich machen das die mittlerweile schnellen Speicher und die schier unerschöpfliche Rechenkapazität von parallelen CPU-Kernen.
Hinzu kommt, dass die HANA Suite neben der fokussierten Datenhaltung mit einer vereinheitlichten Anwendungsarchitektur aufwartet, mit der die Logikschicht eines IT-Systems abgebildet werden kann.
Das Prinzip „ONE“ gilt also nicht nur für die Datenhaltung, sondern auch für die Systemumgebung. Denn HANA fokussiert wiederum sämtliche benötigte Dienste wieder auf eine Systeminstanz: Ein Datentopf, eine Laufzeitumgebung, eine Entwicklungsplattform, ein Webserver und vieles mehr.
Bei dieser Art des Systemaufbaus müssen die Prozesse und die dafür benötigen Informationen erst aufeinander abgestimmt und zentralisiert werden. Der Host ist hier ein guter, alter Bekannter. Aber der Fortschritt bei Leistung und Geschwindigkeit eröffnet einen neuen Horizont und damit Lösungsmöglichkeiten, die vorher nicht denkbar waren.
Und trotzdem bleibt der Massenmarkt bleibt vorerst aus. Wie kommts?
Die Berechnung der Wirtschaftlichkeit des Systems ist schwierig
Eines vorweg: Mit einer vereinfachten Systemlandschaft und einem aufgeräumten Datenhaushalt kann man grundsätzlich Geld sparen. Aber im Gegenzug fallen die Kosten für teure Hardware und die SAP-üblichen Lizenzkosten an. Betrachtet man also die Wirtschaftlichkeit von HANA, so müsste man die Systemkosten und die zu erwartenden Einsparungen gegenüber stellen. Und das ist gar nicht so einfach:
Denn die tatsächlichen Investitionskosten der aktuellen Systeme eines Unternehmens lassen sich nur schwer ermitteln. Gerade im In-/Exkasso-Bereich deutscher Versicherer wurden in den letzten Jahren hohe Investments für Systemkonsolidierungen getätigt. Diese werden aktuell abgeschrieben und müssen sprichwörtlich erst ihren „Return“ verdienen. Unter dem Strich ist eine rein monetäre Betrachtung für ein HANA System also nicht gerade günstig.
Umdenken ist angesagt: Ereignisorientierte Prozessgestaltung
Interessanter wird es, wenn man die Optionen zur Prozessgestaltung mit einrechnet, die eine hoch performante, parallelisierte Datenverarbeitung möglich machen.
Beispielsweise werden aktuell bei den Versicherern Zahlungsläufe in batchorientierten Prozessschritten aufbereitet. Für Brancheninsider ist es nicht neu, dass diese Batchläufe ihre Zeit und ein gewisses Maß an Administration benötigen. Eine Umstellung des Status Quo geht mit Sicherheit mit einer Beschleunigung der einzelnen „Batches“ einher. Der Aufwand und die Kosten für die Administration bleiben aber vorerst gleich. Ferner ist es fraglich, ob eine reine Verbesserung der Batchlaufzeit nicht auch durch günstigere Maßnahmen umgesetzt werden kann.
Eine zur SAP HANA wesentlich natürlichere Umstellung wäre es, wenn zukünftig eine Zahlung ereignisgesteuert prozessiert wird. Anstelle eines Batch oder einer Batchkette müsste ein Eventhandler konzipiert und umgesetzt werden. D.h. ein Stück Software, welches auf einen unterschiedlichen Status von Daten selbständig reagiert. Je nach Art des Events kann daraufhin ein gesamter Prozess abgearbeitet werden. Eine Zahlung wäre somit transaktional und die Administration für den Batch wird obsolet. SAP Hana würde genügend Leistung bieten, um mehrere Zahlungen eines Versicherers parallel vollständig durchzuführen.
Dabei ist zu bedenken, dass mehrere Zahlungsbearbeitungen als Event nicht unbedingt zeitgleich ausgelöst werden müssten. Ferner könnte man durch diese Konstruktion mit verschiedenen Variationen der Skalierung und der Lastverteilung dem Pool an Zahlungen relativ variabel abarbeiten.
Was macht diese Vorgehensweise so besonders?
- Die Programmierung fokussiert sich auf transaktionale Events.
- Die Administration für eine Batch wird obsolet.
- Eine variable Skalierung und Verteilung der Zahlung wird möglich.
Aus einer globaleren Sicht eröffnet eine transaktional orientierte Prozessarchitektur, die damit entsteht, durchgängige Zahlungen zwischen Partnern und Kunden per Knopfdruck. Gerade innerhalb eines Zahlungsverbundes können Zahlungen binnen eines halben Tages auf dem Konto des Partners verbucht sein. Noch schneller ginge es mit alternativen Zahlungsverfahren, wie etwa PayPal die im Prinzip schon auf einer transaktionalen Abwicklung basieren. So könnten Versicherer deutlich schneller mit Ihren Kunden interagieren. Aber auch Klärungen könnten nicht nur direkt verbucht, sondern auch direkt abgeschlossen werden. Das würde die Servicequalität deutlich erhöhen.
Muss sich die Prozesslandschaft für HANA ändern? Ja! Aber bitte nur Schritt für Schritt
So schön die Vorstellung einer transaktionalen Welt auf einem hoch performanten System auch ist: Die Umstellung einer bestehenden, batchorientierten Systemlandschaft in einem Schritt wäre zu komplex, um sie kontrolliert steuern zu können. Die Transformation der Systeme und Prozesse kann nur Schritt für Schritt erfolgen. Eine der SAP spezifischen Vorgehensweisen hierfür schaut wie folgt aus:
- HANA Ready
- Migration
- Funktionale Optimierung
- Prozessoptimierung
Während die ersten beiden Schritte dazu dienen, ein lauffähiges System zu etablieren, so versteht man unter einer funktionalen Optimierung die Ausnutzung spezifischer HANA Optionen, um die Leistung generell zu steigern. Doch erst mit einer Prozessoptimierung wäre ein oben beschriebener Wandel möglich. Und auch hierfür gilt: Eine Umstellung in einem Schritt wäre aufgrund der Komplexität nicht beherrschbar. Um aber in kleinen, evolutionären Schritten einen Wandel von einer batchorientierten Prozesslandschaft hin zu einer transaktionalen vollziehen zu können, benötigt man ein Leit- bzw. Zielbild.
Fazit
Mit den Optionen und Auswirkungen einer transaktionalen Prozesslandschaft muss sich jedes Unternehmen frühzeitig auseinander zu setzen. Die Performance einer SAP HANA bietet die Möglichkeit, Prozesse effektiv zu gestalten und neue Chancen bei der Kundeninteraktion zu ergreifen.
Um dieses Potenziale nutzen zu können, muss sich das Prozessdesign verändern. Die Abwicklung des Prozesses muss sich granular auf ein Firmenelement fokussieren. Und auf die Änderungen an diesem Element reagieren. Der Aufbau einer solchen Prozessarchitektur auf Basis von HANA ist komplex und in einem Schritt nicht durchführbar. Selbst die SAP überführt ihre Business Suite schrittweiseund und ist noch in der Orientierungsphase.
Der Funktionsumfang bleibt daher vorerst gleich. Um den kommenden Wandel mit gestalten zu können, ist es nötig, sich mit den neuen Chancen und Potenzialen von SAP HANA intensiv auseinander zu setzen.
