 |
| Quelle: Wikipedia.org |
Heute sagt eine Mehrzahl von Firmen von sich, dass sie sogenannt "agil" Software entwickeln. In Bezug auf den kompletten Software-Entwicklungsprozess handelt es sich aber in aller Regel um eine Pseudo-Agilität. So geben den bei Umfragen auch immer mehr Firmen an, dass sie nicht so ganz genau wissen, nach welcher Methode sie entwickeln.
Diese Pseudo-Agilität äussert sich etwa darin, dass meist nur die Software-Entwickler selber agile arbeiten. Der Auftraggeber und die Fachvertreter in der Regel nicht oder nur ungenügend. Oder es gibt trotz agilem Vorgehen einen Endtermin mit klaren Abnahmekriterien.
Diese Pseudo-Agilität hat zwei Ursachen:
1] Meist kennen nur die Software-Entwickler selber das agile Vorgehen und können sich mit diesem auch identifizieren. Andere Stakeholder schätzen zwar die Flexibilität, wollen die Nachteile aber trotzdem nicht akzeptieren.
2] Das agile Manifest hat einzelne Prinzipien, die sich so in der Praxis meist nicht 1:1 so umsetzen lassen.
Die Prinzipien vom agilen Manifest:
1] Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software:
Sicher ein wichtiger Aspekt. Wobei es hier nicht nur einfach um die Zufriedenstellung geht. Es ist vor allem auch eine vertrauensbildende Massnahme.
2] Agile Prozesse nutzen Veränderungen (auch spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden:
Das wäre zwar schön, ist aber leider in der Realität ein Stück weit ein Feigenblatt des Manifests. Durch eine Änderung der Anforderung müsste allenfalls eine komplett andere Architektur der Software gewählt werden. Und alle bis dahin entwickelten Iterationen müssten gegeben falls nochmals entwickelt werden. Diese Zeit hat in der Praxis aber niemand - resp. will sich niemand nehmen und auch nicht bezahlen. Die Änderungen werden also in der Praxis mit den bereits vorhandenen Mitteln umgesetzt. Ob dies mittel- bis langfristig ein Wettbewerbsvorteil bringt, bleibt offen.
3] Lieferung von funktionierender Software in regelmässigen, kurzen Zeitspannen:
Ein guter Punkt, der zwei Aspekte abdeckt: Er dient auch der Stärkung des Vertrauens in die Entwicklung wie der Punkt 1. Weiter dient er auch der Motivation der Entwickler. Lauffähige Software motiviert mehr, auch wenn sie nur klein ist, als eine Menge Code wo man noch nicht weiss, ob er läuft.
4] Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes:
Ein guter Punkt - der leider in der Praxis längst nicht bei allen Projekten möglich ist. Gerade die echten wichtigen Fachexperten sind häufig im Tagesgeschäft. Dort werden sie gebraucht weil sie wichtig sind und deshalb sind sie auch Fachexperten. Ein Fachexperte der immer Zeit hat, ist wahrscheinlich kein echter Experte.
5] Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt werden:
Wichtiger Punkt. Gehört aber eher zu den allgemeinen Führungsaufgaben. Dies betrifft längst nicht nur die Software-Entwicklung oder ein agiles Vorgehen.
6] Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht:
Persönliche Kommunikation ist sehr wichtig und für grössere Projekte über eine längere Zeit nicht komplett ersetzbar. Dennoch bieten die neuen Technologien von Video-Telefonie/-Konferenzen und die Teilung von Inhalten hier effiziente Möglichkeiten.
7] Als wichtigstes Fortschrittsmass gilt die Funktionsfähigkeit der Software:
Das ist ein kleiner Trugschluss im agilen Manifest. Gerade zusammen mit Punkt 2] lässt sich der Fortschritt kaum messen. In der aktuellen Iteration hat man viele lauffähige Funktionen - und im nächsten Schritt muss man sie auf Grund von Veränderungen umschreiben und ergänzen. Damit lässt sich kaum ein Fortschritt messen. Es zeigt sich, dass gar nicht alle Prinzipien gleichermassen angewendet werden können.
8] Einhalten eines gleichmässigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung:
Das wünscht sich jeder Fabrik-Manager. Ist aber eine Illusion. Gerade Softwareware-Entwickler in der kreativen Phase haben ein unregelmässiges Arbeitstempo. Auch sind die Auftraggeber und Benutzer meist nicht zu 100 % für ein Projekt zur Verfügung. Entsprechend können auch sie in aller Regel kein gleichmässiges Arbeitstempo erbringen.
9] Ständiges Augenmerk auf technische Exzellenz und gutes Design:
Ein sehr guter Vorsatz. Wie in Punkt 2] schon erwähnt würde dies aber dazu führen, dass man häufiger wieder ganz von vorne beginnen müsste. Das macht niemand. Die technische Exzellenz und das gute Design werden daher in der Praxis bei notwendigen Änderungen schön gefärbt. Man versucht so viel wie möglich mit der bereits entwickelten Lösung/Architektur zu realisieren.
10] Einfachheit ist essenziell:
Das ist ein weites Prinzip mit viel Spielraum für Interpretation. So in der Form in der Praxis wenig hilfreich.
11] Selbstorganisation der Teams bei Planung und Umsetzung:
Wäre ein schöner Ansatz, der in der Praxis aber selten funktioniert. Häufig alleine aus dem Grund, dass nicht alle Stakeholder nur dem Team angehören. Über deren Ressourcen lässt sich dann nicht einfach so verfügen, auch nicht über die Fachverantwortlichen als Beispiel. Das Prinzip reduziert sich dabei in der Praxis meist auf die Software-Entwickler selber. Auch kann in der Realität häufig nicht selbstbestimmt über Test-Ressourcen etc. verfügt werden. Diese müssen ordentlich geplant und bestellt werden.
12] Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung:
Guter Ansatz, der natürlich nicht nur für Software-Entwicklung gelten sollte. Als Team ist es in der Praxis meist deshalb nicht ganz einfach umsetzbar, weil die Teams als ganzes von Projekt zu Projekt nicht so stabil sind. Die Teams werden je nach Anforderungen und Themen jeweils (teilweise) neu zusammen gesetzt. Auch hier gilt. dass sich das Prinzip in der Praxis meist nur auf die Software-Entwickler selber bezieht.
Zwischenfazit:
Das agile Manifest kommt von Software-Entwickler und betrifft in erster Linie auch nur Software-Entwickler. Es ist aber auch für diese kaum möglich, allen Prinzipien gleichermassen gerecht zu werden. Es gibt potentielle inhärente Zielkonflikte. An einer Software-Entwicklung sind jedoch verschiedene Parteien beteiligt. Das Vorhaben der Software-Entwicklung als Ganzes mit allen Beteiligten, lässt sich daher kaum rein agil wie proklamiert umsetzen.
Braucht es ein Meta-Manifest?
Die Welt da draussen ist komplexer als einfache Methoden. Wo Menschen sind, gibt es Meinungen, Standpunkte und persönliche Interessen. Häufig wird mit einem Software-Projekt nicht nur das Ziel der Software selber verfolgt. Und das ist auch richtig so. Software soll Mittel zum Zweck sein. Aber welcher Zweck soll erfüllt werden? Nicht selten spielen Business-Strategien und Taktiken eine wichtige Rolle. All diese Themen sind im agilen Manifest überhaupt nicht adressiert.
Es stellt sich daher die Frage: Brauchen wir ein Meta-Manifest? Ein Manifest, wo andere Stakeholder und Betroffene als Software-Entwickler auch angesprochen werden? Ein Manifest, dass den ganzen Prozess der Software-Entwicklung abdeckt? Ein Manifest das Hinweise gibt, wie mit Zielkonflikten innerhalb der Prinzipien umzugehen ist?
Die Anforderungen an die Banken-IT sind sehr vielfältig. Bei der Realisierung der Banken-IT von Morgen muss an sich entsprechend fokussieren. Bei allen Entscheidungen muss dieser Fokus im Vordergrund stehen.
Die grosse Frage ist, was muss eine Bank-IT von Morgen können? Aus meiner Sicht lassen sich die Anforderungen auf zwei grosse Themen reduzieren:
Wie kann die Bank-IT helfen, die Kosten zu reduzieren? Und wie kann die Bank-IT mir helfen, Produkte und Dienstleistungen zu verkaufen?
Die unten stehende Grafik veranschaulicht das.
Diesen beiden Fragen lässt sich praktisch alles unterordnen. Aber gehen wir der Reihe nach.
Bei der letzten grösseren Erneuerungsrunde von Banksystemen mit Beginn vor ca. 15 Jahren, stand (nicht nur, aber vor allem) die Datenerfassung im Vordergrund. Bei den alten Systemen war die Datenerfassung relativ limitiert und unflexible. Die Felder waren oft zu kurz und man konnte ganz allgemein sehr wenig Daten erfassen. Die Erfassung von Daten, hauptsächlich im Sinne von sog. Stammdaten, war somit eine zentrale Anforderung. Man wollte endlich alle Daten elektronisch erfassen können.
In der heutigen IT-Welt ist Datenerfassung selbstverständlich und kein Thema mehr. Datenerfassung ist leicht gemacht und Speicher gibt es ohnehin mehr als genug.
Deshalb stellt sich bei der Evaluation einer neuen Bankensoftware die Frage: Wie hilft mir das System, Produkte und Dienstleistungen zu verkaufen? Und fast im gleichen Atemzug kommt die Kostenfrage. So ein Bankensystem ist nicht günstig und darf auch etwas kosten. Aber wie hilft mir dieses System, dass ich (andere) Kosten reduzieren kann?
Schauen wir uns nun ein paar wenige aktuelle Themen, Schlagworte und Trends in diesem Kontext an:
Compliance
Compliance ist heute anspruchsvoller den je und wie die jüngsten Bussen von Banken zeigen, kann es nicht nur in der Theorie rasch ins Geld gehen. Dennoch ist aus Sicht Bank-IT Compliance ein Kostenfaktor und gehört zur Frage, wie kann mir das System helfen Kosten zu sparen. Das soll nicht despektierlich für Compliance klingen. Es geht darum, dass das System in der Lage ist, Compliance in vielen Prozessen selber durchzusetzen. Das heisst, dass Dinge, die nicht compliant sind gar nicht erst möglich sind. Oder dass unklare oder verdächtige Sachverhalte erkannt und in einem Workflow zur Kontrolle gegeben werden. Compliance kann man auch manuell machen. Man könnte jede Transaktion manuell von einem Spezialisten prüfen lassen - das kostet. Es stellt sich also die Frage, welche Compliance- (und IKS-) Tätigkeiten nimmt mir das System ab, bei welchen unterstützt es mich?
Mobile-Banking
Mobile-Banking ist, das wird heute leider noch zu wenig gesehen, nicht nur Chic sondern auch ein Verkaufskanal. Man kann darüber bspw. Börsenaufträge "verkaufen". Durch die Nutzung vom Smartphone als Auftrags-Tool für Börsenaufträge, lässt sich das Handelsvolumen in gewissen Kundensegmenten steigern - und damit die Erträge aus dem indifferenten Geschäft. Es gehört somit zur Frage, wie hilft das System, Produkte und Dienstleistungen zu verkaufen. Zudem hilft es als Zusatz zum Gesampaket einer Bank.
PFM (Personal Finance Manager)
Ein PFM kann verschiedene Sekundäre Vorteile haben. Es ist zum einen eine gute Kundenbindung. Ein Kunde, welcher viele Transaktionen klassiert und sein Budget und seine Sparziele erfasst hat, wechselt nicht so schnell - er möchte im neuen E-Banking nicht wieder alles erfassen müssen und er verliert die bereits klassierten Transaktionen. Weiter kann es dem Kunden helfen auf ein Ziel zu sparen. Dadurch weiss die Bank bspw. dass der Kunde bspw. ein Haus kaufen möchte. Bei (fast) erreichen des Sparzieles "Hauskauf" kann sie den Kunden direkt kontaktieren. Es gehört somit klar zur Frage, wie kann das System mir helfen, Produkte und Dienstleistungen zu verkaufen.
Self-Service
Self-Service heisst, dass der Kunde Sachen selber machen kann. Es ist eng verbunden mit dem Thema Customer-Survey, denn dazu braucht es Self-Service. Im Kontext unserer Fragen, gehört Self-Service zu beidem und ist deshalb in Zukunft sehr wichtig. Weshalb? Wie hilft mir Self-Service mir Produkte und Dienstleistungen zu verkaufen? Auf zwei Arten. Rein digital kann ich dem Kunden Angebote machen, welche er direkt online selber abschliessen kann. Analog-Digital kann es helfen, einen Abschluss zu erreichen. Das Beratungs- und Verkaufsgespräch beginnt vielleicht damit, dass der Kundenberater den Kunden anruft. Der Kunde möchte sich daher nicht sofort entscheiden und es sich überlegen. Das Angebot kann dem Kunde dann bspw. ins E-Banking gestellt werden. Das nächste Mal wenn er eine Zahlung machen muss sieht er den Event, erinnert sich an das Beratungsgespräch und kann direkt am Sonntag Abend um 22.30 Uhr abschliessen. Ohne diese Möglichkeit wäre der Kunde nicht zur Richtigen Zeit daran erinnert worden und er hätte auch nicht abgeschlossen. Somit hilft mir Self-Service, Produkte und Dienstleistungen zu verkaufen. Dadurch, dass der Kunde seine Adresse selber ändern, Kartenlimiten für die Ferien selber erhöhen und Kredite selber verlängern kann, spart die Bank Kosten in dem weniger manueller Personalaufwand besteht. Dadurch hilft mir Self-Service, Kosten zu sparen.
Customer Journey und Multi-Channel
Hauptsächlich Themen, mit welchem ein System helfen kann, Produkte und Dienstleistungen zu verkaufen. Der Kunde kann an mehreren Orten abgeholt werden. Und wie wir bereits beim Self-Service gesehen haben, hilft es Abschlüsse zu generieren. Kosten sparen ist vor allem im Zusammenhang mit Self-Service möglich, wenn der Kunde bspw. über das Smartphone notwendige Unterlagen direkt ditigal bei der Bank einreichen kann.
Big Data, Data-Analytics. Machine Learning
Den Kunden verstehen ist etwas vom Wichtigsten für eine Bank. Jeder Kunde wünscht excellenten Service und passende Produkte und Dienstleistungen. Alles natürlich möglichst kostenlos. Der Kundenberater als Mensch ist damit überfordert, weil ein (Retail-) Kundenberater unmöglich alle Kunden so gut kennen kann und auch nicht die Zeit hat, jedem Kunden regelmässig Vorschläge für Verbesserungen in den finanziellen Angelegenheiten zu machen. Hier kann die IT einen echten Mehrwert für beide Seiten schaffen. Mittels Datenanalyse inkl. Machine Learning kann ein System basierend auf dem Wissen von Kundenberatern zum einen den Kundenberater unterstützen und zum anderen direkt den Kunden unterstützen. Damit gehört das Thema ebenfalls zu beiden Fragen. Es hilft, Produkte und Dienstleistungen zu verkaufen. Es hilft aber auch Kosten zu sparen, indem ein Kundenberater mehr Kunden effizient betreuen kann.
Produkt-Innovation
Wie kann sich eine Bank von anderen abheben? Produkt-Innovation ist zwar auch wichtig. In Zukunft wird das Beratungs- und Betreuungs-Erlebnis aber noch wichtiger sein als die Produkte selber. Diese sind auch heute im Kern bei allen Banken gut vergleichbar. Es gehört zur Frage, wie ein System mir hilft Produkte und Dienstleistungen zu verkaufen, in dem ich bspw. Produkte individuell customizen kann. In der Regel zählt dann hier aber mehr das Kundenerlebnis, dass das möglich ist. Als dass sich das individuelle Kundenprodukt wirklich gross von anderen unterscheidet.
Banksteuerung
Banksteuerung ist schon länger ein Thema und das zu Recht. Es geht hier vor allem um Themen wie ALM (Asset and Liability Management), Kostenrechnung und Ressourcen-Allokation. Die jüngsten Halbjahresabschlüsse von ein paar Schweizer Banken haben gezeigt, dass man mit einem guten ALM im Zinsdifferenz-Geschäft auch in eigentlich schwierigen Zeiten einiges Herausholen kann. Die Kostenrechnung ist ganz wichtig, wenn es darum geht die Prozesse zu optimieren und zu digitalisieren. Wenn ich weiss, wo welche Kosten anfallen kann ich gezielter vorgehen und vor allem im Nachgang das Ergebnis der Einsparung auch effektiv messen. Das Thema Banksteuerung gehört diesbezüglich in die Fragestellung, wie hilft mir das System Kosten zu sparen. Wenn damit natürlich auch die Erträge optimiert/gesteigert werden sollen. Insofern kann man es teilweise bedingt zusätzlich zur modifizierten Frage zählen, wie hilft mir das System die ertragreichsten Produkte und Dienstleistungen zu verkaufen. Ob die Banksteuerung zu einem Kernbankensystem gehört oder nicht, ist eine andere Frage, da reicht hier der Platz nicht aus. Aber sicher ist es eine ganz wichtige Komponente im Gesamtpaket einer Banken-IT-Lösung.
Wo müssen entsprechend die Stärken einer künftigen Banken-IT liegen?
Prozess-Engine
Die Prozesse müssen künftig durchgängig, d.h. von der Kundenfront bis zur Abwicklung, definiert und technisch abgebildet werden können. Durch Customer-Journey/Self-Service ist künftig auch der Kunde direkt digital in den Prozess involviert. Dies stellt hohe Anforderungen an die Prozess-Modellierung und die Prozess-Engine. Es wird künftig auch wesentlich mehr ein Prozess sein, als heute wahrgenommen wird. Fast alles muss als Prozess definiert und abgebildet werden. Sei es eine Kunden-Order, eine Limitenerhöhung, eine Adressänderung oder die Neueröffnung oder Saldierung eines Kontos. Die Prozess-Engine soll zusammen mit den Kompetenzen auch die Abwicklung im Middle- und Back-Office beschleunigen. Ebenso das Thema Outsourcing drängt sich hier auf. Einzelne Prozessschritte sollen auch durch Dritte (spezialisierte Firmen) abgewickelt werden können.
Wizard-Engine
Als Wizard verstehe ich die geführte und Datenabhängige Datenerfassung. Je nach Eingaben kommen andere Erfassungsbilder und Fragen. Ein Wizard kann aus zwei oder 50 Schritten bestehen, das spielt keine Rolle. Es werden zwei Ziele erfolgt: Man muss nur jene Daten erfassen, wie wirklich nötig sind, die Erfassung soll schnell sein. Gleichzeitig soll die Datenqualität hoch sein. Sowohl interne Mitarbeiter, insb. Kundenberater, wie auch Kunden brauchen künftig vermehrt solche Wizards um intuitiv und qualitativ hochstehend Daten und Aufträge zu erfassen. Wizards müssen eng mit den Prozessen harmonieren. Verschiedene Prozess-Schritte haben wo sinnvoll entsprechende Wizards um den Schritt zu bearbeiten.
Client-Unabhängigkeit
Wir wissen heute nicht, was morgen und übermorgen für End-Geräte zum Einsatz kommen. Im Middle- und Back-Office wird es wohl noch länger klassische Monitore mit Tastatur und Maus geben. Aber ob der Kundenberater übermorgen auch noch hauptsächlich so arbeitet, ist ungewiss. Beim Kunden ist es gewiss, in der Schweiz sind bspw. bereits heute gut 40 % der Leute mit dem Tablet im Internet unterwegs. Wer weiss, ab wann es praktisch sein wird am TV ins Internet zu gehen um sich mit der Bank zu verbinden. Zwischen den zwei Lieblingsserien noch kurz am TV die fällige E-Rechnung freigeben? Durch die heutige Vielfalt und die Unbestimmtheit was in Zukunft gefragt sein wird ist es unabdingbar, dass man möglichst Client-Unabhängig ist. Das heisst, dass man mit wenig Aufwand neue End-Geräte bedienen kann. Die Web-Technologie bietet sich dafür sicher wie länger wie mehr an. Durch entsprechende Wrapper lassen sich bestehende Weblösungen für verschiedene Endgeräte komfortabel nutzen. Denn für jedes End-Gerät das Front-End native zu entwickeln und zu pflegen wird sich kaum eine Bank leisten können.
Berechtigungen & Kompetenzen
Da sich die Prozesse immer mehr auch zum Kunden verlagern, werden die Berechtigungen und vor allem auch die Kompetenzen immer wichtiger. Ein System muss flexibel Kompetenzen abbilden können. Nur so können die Prozesse wirklich digital automatisiert werden. Bspw. Kartenlimiten erhöhen: Ein Kundenberater kann für die Konstellation X die Kartenlimiten bis CHF 8'000 erhöhen. Ein Kunde kann temporär für eine Zeitspanne mit dem Grund Ferien seine Limite bei regelmässigem Lohneingang (Stichwort Datenanalyse) bis CHF 5'000 erhöhen. Andere Beispiele sind Kreditlimiten, Sonderangebote für Zinsen, oder Gebühren (Pricing) etc. Banken müssen die Kompetenzordnung so gestalten, dass möglichst viel vom System automatisch abgebildet werden kann. Dadurch kann die Kompetenzprüfung vom System vorgenommen werden und die Prozesse können automatisiert werden. Zurück zum Beispiel der Kartenlimiten: Erfasst ein Kunde im E-Banking eine neue Limite von CHF 7'000, so wird diese nicht direkt angewandt (Kompetenz CHF 5'000), der Workflow geht zu seinem Kundenberater, da dieser die Kompetenz bis CHF 8'000 hat. Der Kunde wird informiert, dass der Antrag zur Prüfung eingereicht wurde. Möchte er CHF 10'000 geht der Workflow zum Abteilungsleiter des Kundenberaters etc. Bei CHF 5'000 wird der Vorgang direkt abgeschlossen und der Kundenberater allenfalls darüber informiert.
Offene Schnittstellen
Offene Schnittstellen meint, dass auch ein Drittsystem mit den Prozessen der Bank-IT sprechen kann. Ein Prozess wird künftig vielleicht nicht nur von einem eigenen Client ausgelöst. Gut möglich, dass eine Bank ein Drittprodukt einsetzen möchte aus welchem ebenfalls ein Prozess (bspw. eine Order, oder Stammdatenmutation etc.) ausgelöst werden kann. Datenschnittstellen sind heute state of the art und obwohl aufwändig, meist ohne all zu grosse Hürden realisierbar. Die künftigen Prozess-Schnittstellen werden in Sachen Schnittstellen die künftige Herausforderung. Auch hier soll das Thema Outsourcing erwähnt sein. Gut möglich, dass sich eine spezialisierte Firma für einen Teil eines Prozesses mit einer eigenen optimierten Lösung für diese Schritte am Prozess beteiligen soll.
Daten-Analyse
Daten-Analyse braucht es für verschiedene Zwecke. Um den Kundenberater zu unterstützten, damit man Produkte und Dienstleistungen verkaufen kann. Aber auch um Kosten zu sparen, weil Verkaufsaktivitäten teilweise automatisiert werden können. Es gibt aber auch noch ein weiteres wichtiges Einsatzgebiet - und das ist die Prozessautomatisierung. An das wird heute leider auch noch zu wenig gedacht. Bei den Kompetenzen oben haben wir gesehen, dass eine Kompetenz an Kriterien geknüpft sein kann (in der Regel ist sie das). Ein Kriterium kann eben bspw. sein, "Regelmässiger Lohneingang". Daher dient die Daten-Analyse auch als Input für Kompetenzen und somit für den Prozess-Flow. Denn woher weiss das System, dass es einen regelmässigen Lohneingang gibt? Im weiteren Sinn kann auch die Banksteuerung zur Daten-Analyse gezählt werden. Denn letztlich geht es auch dabei zu einem grossen Teil darum, die Daten zu interpretieren und daraus Schlüsse zu ziehen.
Was soll der Front-Fokus sein?
Der Fokus für Front-Applikation geht weg von Stammdaten-Bildern hin zu Use Cases. Fast alle Tätigkeiten an der Front können zum Thema: "Was möchten Sie tun", gezählt werden. Die Use Cases sind dann bspw.:
- Konto eröffnen
- Konto saldieren
- Karte bestellen
- Kartenlimite ändern
- Adresse ändern
- Korrespondenz ändern
- Saldo abfragen
- Aufgelaufene Gebühren abfragen
- Buchungen ansehen/suchen
- Neue Vollmacht erfassen
- Etc.
Heute ist es oft so, das man bspw. um eine Kartenlimite zu ändern wissen muss, über welchen Weg man auf eine Kartenstamm-Maske gelangt. Und auf dieser Maske gibt es dann irgendwo einen Button, wo man eine Änderung machen kann. Hat man keine Berechtigung, muss man die Änderung per E-Mail oder interne Post an die zuständige Stelle senden und später nachschauen (wo war das gerade?) ob die Änderung nun erfolgt ist. Künftig soll man bequem den Use Case "Kartenlimite ändern" finden, indem diese gut gruppiert sind und es eine gute Suche gibt ("Karte Limite"). Dort kann man die gewünschte Karte suchen und die Änderung erfassen. Hat man die Berechtigung und die Kompetenz für die erfasste Limite, wird die Änderung ausgeführt. Wenn nicht, wird die Änderung an die zuständige stelle geben, der Erfasser wird entsprechend darüber informiert und informiert, wenn der Antrag bewilligt oder abgelehnt worden ist. In dieser neuen Denkweise stellt man bald fest, dass diese einfache Art der Geschäftsabwicklung, in welcher Prozesse und Wizards im Vordergrund stehen, sowohl für Front-Mitarbeiter wie auch für Kunden direkt, bspw. im E-Banking, sinnvoll einzusetzen sind (letzteres mit Stichwort Self-Service).
Auf der anderen Seite gibt es vor allem mit Fokus Vertrieb noch eine andere Sicht für den Kundenberater: Welche Aktivitäten habe ich zu machen? Da gibt es Kundenpendenzen welche bearbeitet werden müssen. Oder Verkaufsaktionen welche die Vertriebssteuerung in Auftrag geben haben. Oder wie wir gesehen haben, Freigaben für Aufträge die in der Kompetenz des Kundenberaters liegen die erteilt oder abgelehnt werden müssen. Es sind also die beiden Themen: "Ich will ..." und "Was habe ich zu tun ...?" Die im Vordergrund stehen.
Was soll der Middle- und Back-Office Fokus sein?
Das Middle- und Back-Office ist Abwicklungs- und Kontrollschritt getrieben. Im Hintergrund treffen die Aufgaben aus den Prozessen der Front und der Drittsystemen zusammen, wo es eine "manuelle" Bearbeitung braucht. Entsprechend ist die Frage hier: Was habe ich zu tun? Eigentlich ähnlich wie der zweite Teil an der Front, aber nicht auf eigene Kunden zugeschnitten, sondern mehr auf Prozesse und Prozessschritte zugeschnitten. Die Gruppierung erfolgt dann hier eher nach Prozessen/Use Cases, während die Gruppierung an der Front eher nach Kunde ist. Je nach Bank stehen hier natürlich auch die Möglichkeiten vom Outsourcing im Vordergrund. Es muss möglich sein, die Verarbeitung einfach durch Dritte erledigen zu lassen. Oder wo sinnvoll, soll sich eine spezialisierte Firma auch mit einem eigenen optimierten System am Prozess beteiligen können. In solchen Fällen ist es dann nicht notwendig, dass die ganze Verarbeitungslogik im Core-System implementiert werden muss. Das Prozess-Modell und die Prozess-Engine reichen dann.
