Das Dilemma scheint unauflösbar: Einerseits wollen sich die Unternehmen im digitalen Wettstreit voneinander unterscheiden. "Banking ohne Unsinn", verspricht eine bekannte Smartphone-Bank aus Berlin, die in den letzten Jahren rasend schnell neue Kunden gewonnen hat. Das bedeutet andererseits aber auch, viel von der eingesetzten Software selbst zu entwickeln, damit sich das Angebot auch gefühlt von dem anderer Banken unterscheidet.
Geldhäuser müssten sich sogar in Softwareunternehmen verwandeln, sagen einige. Großbanken wie ING oder Goldman Sachs verstehen sich als Tech-Firmen mit Banklizenz. Alles selbst zu machen, zahlt sich aber nicht immer und überall aus.
Mehr Macht den Anwendern
In Bereichen, in denen immer dasselbe passiert, lohnt sich selbstentwickelte Software nicht. Das gilt beispielsweise für Buchhaltung und Finanzen, vielfach auch für das Personalwesen. Weil Kunden davon ohnehin kaum etwas merken, wäre eine individuell gefertigte Software zu teuer. Frameworks bieten hier einen vermeintlich sicheren Ausweg, weil sie vorgefertigte Module für wiederkehrende Aufgaben mitbringen und darüber hinaus erlauben, einzelne Dienste passend auszuprägen. Doch das erfordert viele manuelle Handgriffe. Daraus entsteht das Risiko, eine kaum noch Release-fähige IT-Lösung zu bauen, die bei jedem Update des Frameworks neue Probleme schafft.
Ideal wäre deshalb eine Standardsoftware, die Kunden erlaubt, selbst Abläufe festzulegen. Die Idee: eine in die Software integrierte Workflow-Engine (WFE), die sich über eine Skriptsprache steuern lässt (siehe Abbildung). Die Skriptsprache unterscheidet zwischen Status und Qualitätsabfragen. Jeder Status gibt vor, was als nächstes passieren soll, und jede Qualitätsabfrage prüft, ob zuvor festgelegte Bedingungen vorliegen oder nicht.
Davon hängt ab, ob und wie sich ein einzelner Status ändert. Ist der Workflow vollständig beschrieben, kompiliert die Engine den Code. Innerhalb der Software wiederum erzeugt die WFE Aufgaben (Tasks), die anschließend von einer Task-Engine abgearbeitet werden. Über die Skriptsprache formulierte Änderungen lassen sich so ohne Release-Wechsel einspielen.
Foto: PPI
Intern arbeitet die Software ausschließlich mit Tasks, nach außen öffnet sie sich über die Workflow-Engine und die mitgelieferte Skriptsprache. Ein großer Teil der Softwareentwicklung rückt dadurch aus der Sphäre des Herstellers in die Sphäre desjenigen, der die Software einführt. Das kann entweder direkt durch die eigenen IT- und Fachbereiche geschehen oder durch ein Unternehmen, das sich mit dem jeweiligen Sachverhalt auskennt. Die Technik ist praktisch von der Fachlichkeit getrennt. Am Quellcode selbst brauchen die späteren Anwender, anders als bei vielen Frameworks, deshalb keine Änderungen vorzunehmen. Eine der größten Gefahren, an denen viele solcher Projekte scheitern, ist damit gebannt.
Individualität trotz Uniform
Besonders gut eignet sich diese Architektur für Geschäftsvorfälle, die sich in einzelne Teilaufgaben zerlegen und in einer vom Anwender gewünschten Reihenfolge abarbeiten lassen. In Banken stellt der Zahlungsverkehr einen typischen Anwendungsfall dar. Wenn Geld überwiesen werden soll, müssen die Institute beispielsweise prüfen, ob das Konto des Auftraggebers gedeckt ist und ob die IBAN des Empfängers stimmt.
Doch das ist längst nicht alles. Banken müssen auch checken, ob ein Verdacht auf Geldwäsche vorliegt - gerade bei Zahlungen ins Ausland -, und ob der Empfänger auf einer Embargo- oder Sanktionsliste steht. Obwohl diese Aufgaben sich von Bank zu Bank kaum unterscheiden, sind die Reihenfolge, die Bedingungen und die verwendeten Schnittstellen zu anderen IT-Systemen sehr verschieden.
Wir zeigen im folgenden Listing, wie sich eine von uns entwickelte Software für Zahlungsverkehr bei einer eingehenden Zahlung verhalten soll, wenn es um eventuell anfallende Gebühren geht:
Im abgebildeten Fall nimmt das System eine Zahlung von einer anderen Bank an und prüft, ob die Gebühren von der die Zahlung auslösenden Bank getragen werden - im Fachjargon heißt diese Regel OUR-Charges. Wenn das so ist, soll das System kontrollieren, ob zusätzlich zum überwiesenen Betrag diese Gebühren der Überweisung beiliegen. Falls ja, erzeugt das System einen neuen Status, damit der Gebührenbetrag geprüft und einbehalten wird. Falls nein, fragt das System, ob die Gebühren von der Bank, von der die Zahlung kommt, direkt eingezogen werden dürfen. Davon hängt ab, welcher Status erzeugt wird und ob das System sich die Gebühren direkt holt oder ob eine Zahlungsaufforderung erstellt wird. Je nach Mandant lassen sich nahezu beliebige Regeln abbilden.
Das ist vor allem im Individualzahlungsverkehr wichtig. Große Konzerne suchen sich üblicherweise in jeder Weltregion eine Bank, die sämtliche Zahlungen zentral abwickelt. Dafür machen sie bestimmte Vorgaben, die das Institut darstellen können muss, um den Zuschlag zu erhalten. Folglich muss die betreffende Bank - beziehungsweise die eingesetzte Software - plötzlich aus einem vermeintlichen Standardprodukt wie dem Zahlungsverkehr ein individuelles Angebot schneidern, bei dem viele Details zu beachten sind. Die Konzerne schreiben häufig vor, über welche Banken das Geld zu leiten und zu welchen Tageszeiten zu buchen ist. Anders als etwa die SEPA-Zahlung im Euroraum ist der Auslandszahlungsverkehr kein einfaches Massengeschäft.
Viele Banken entscheiden sich vor diesem Hintergrund, ob sie Zahlungsverkehr überhaupt als ein strategisches Geschäftsfeld begreifen wollen oder nicht. Einige Banken geben das komplexe Geschäft an ein großes Institut ab oder lagern den Zahlungsverkehr gleich ganz aus, weil sie sich so des Problems entledigen, auf einer möglicherweise selbst entwickelten Plattform permanent gesetzlich vorgeschriebene Anpassungen vornehmen zu müssen. Innovation kommt dann zu kurz, was gerade kleineren Instituten zu schaffen macht, wie eine Untersuchung des europäischen Bankenverbands EBA zeigt.
Eine Software, die sich flexibel anpassen lässt und dessen Hersteller den Anwendern trotzdem alle lästigen Aufgaben abnimmt, zahlt sich deshalb besonders aus. Das mag nicht nur für Banken gelten, die Gelder von einem Land ins andere überweisen, sondern auch für andere Branchen, in denen der Gesetzgeber strenge Vorgaben macht, wie Energie, Logistik oder Außenhandel. Unternehmen, die am internationalen Warenverkehr beteiligt sind, müssen etwa über eine Schnittstelle auf Filterlisten des Zolls zugreifen, die über verbotene Güter oder illegitime Absender informieren. Geht dabei etwas schief, riskieren sie ihren Status als "Zuverlässiger Versender", was erhebliche Nachteile mit sich bringt. Hinzu kommen IT-Systeme, um Preise zu berechnen, eigene schwarze Listen zu führen und interne Compliance-Vorschriften einzuhalten, ähnlich wie bei einer Bank.
Fazit
Immer dann, wenn sich ein Unternehmen in einem bestimmten Geschäftsfeld vom Wettbewerb unterscheiden möchte, fällt der Blick im digitalen Zeitalter nahezu automatisch auf die eingesetzte Software - und darauf, ob sie selbst entwickelt worden ist oder eingekauft. Gekaufte Software steht dabei im Verdacht, die gewünschte Abgrenzung unmöglich zu machen, weil sich die Entwicklung häufig erst dadurch rechnet, dass viele Kunden auf ein- und derselben Plattform möglichst viele gleichartige Geschäftsvorfälle ausführen. Die Fachlichkeit ist also gleichsam mit genormt. Wem es gelingt, die Fachlichkeit von der Technik zu trennen, löst dieses Grundproblem auf. Kunden können sich dann trotz Standardsoftware ausreichend differenzieren und brauchen sich um die technische Weiterentwicklung nicht mehr zu kümmern - die kommt mit dem nächsten Release.