Prozessdigitalisierung in der Finanzindustrie

Wie Sie den richtigen digitalen Prozess finden

Dr. Jörg Ziemann

© Shutterstock / Rawpixel.com

In der Finanzindustrie machen das datenzentrierte Geschäftsmodell und der starke Wettbewerb hocheffiziente, digitalisierte Prozesse notwendig. In der Praxis ist es allerdings schwierig, Anforderungen so zu spezifizieren, dass sich daraus stringent auf das richtige Prozessdigitalisierungsmuster schließen lässt. Um weitreichende Architekturentscheidungen zu systematisieren, ist eine Taxonomie nützlich, die Anforderungen an die Prozessdigitalisierung zunächst objektiv klassifiziert.

Muster zur Prozessdigitalisierung existieren seit Jahrzehnten, beispielsweise Stapelverarbeitung, Case Management, Enterprise-Content-Management-basierte Workflows, oder – etwas jüngeren Datums – Serviceorchestrierung. Leider sind die Anwendungsfälle dieser Muster unscharf und dementsprechend auch die der korrespondierenden IT-Lösungen. Das gilt sowohl für kommerzielle Produkte als auch für Eigenentwicklungen. In beiden Fällen besteht die Gefahr, dass im Sinne von „Für den Besitzer eines Hammers sieht alles wie ein Nagel aus“ eine suboptimale Lösung gewählt wird. In Konzernen ist es beispielsweise nicht ungewöhnlich, dass unterschiedliche Abteilungen die verschiedenen IT-Lösungen betreuen. Bei einer neuen Anforderung zur Digitalisierung eines Kernprozesses können alle Abteilungen argumentieren, dass ihre Lösung die Anforderungen abbildet. Dies ist auch richtig, beantwortet aber nicht die Frage, welche Lösung die optimale ist. Wenn die Anwendungen nicht im Haus entwickelt worden sind, ergibt sich die gleiche Situation bei den Herstellermeinungen zu ihren Produkten.

Zur Problematik der unscharfen Beschreibung von Anforderung und Lösung kommt hinzu, dass die Anforderungen an Prozessdigitalisierungen häufig an sich unklar und beweglich sind. Es ist nicht einfach, zur Entwurfszeit den Automatisierungsgrad abzuschätzen, den ein IT-gestützter Prozess im Sollszenario erreichen kann. Ein Beispiel dafür ist ein Prozessverantwortlicher, der, inspiriert von simplen Straight-Through-Prozessen, seinen komplexen, primär manuellen Prozess entsprechend entschlacken will. Dies kann einerseits zu einer fachlichen Übersimplifizierung des Prozesses führen, andererseits zur Wahl eines IT-Lösungsmusters, das die fachliche Komplexität des Prozesses nicht abbilden kann. Darüber hinaus kann sich der Automatisierungsgrad eines Prozesses auch zur Lebenszeit der zugehörigen IT-Lösung ändern. Beispielsweise bei einem Prozess, der zunächst mit hohem manuellem Anteil implementiert und dann sukzessive automatisiert wird. So müssen nicht nur Anforderungen für den aktuellen Sollprozess berücksichtigt werden, sondern auch, in welche Richtung sich dieser wahrscheinlich ändern wird.

ziemann_bpm_1

Abb. 1: Klassifizierung von Anforderungen der Prozessdigitalisierung und typische Lösungen

Eine Taxonomie für Anforderungen der Prozessdigitalisierung

Ziel ist also, eine Taxonomie von Anforderungen für die Geschäftsprozessdigitalisierung, die sowohl die Anforderungserhebung als auch die Zuordnung zu passenden IT-Lösungsmustern unterstützt. Natürlich gibt es hierzu Ansätze in der Literatur, beispielsweise unterscheiden Frank Leymann und Dieter Roller [1] anhand einer Matrix aus Geschäftswert und Wiederholungsrate die Prozesstypen Production Workflow, Administrative, Collaboration und Ad hoc. Keith Swenson [2] unterscheidet auf einer Skala von designed bis emergent die Prozesstypen Straight-through, Structured, Dynamic, Case Management und Social Collaboration. Christian Weiss und Koautoren [3] nennen die drei Klassen Case Management, entscheidungsintensive Prozesse und Automatisierte Prozesse/Straight Through Processing.

Im Gegensatz zu den bereits genannten liegt der Fokus der hier vorgeschlagenen Taxonomie auf Prozessklassen mit höherem Automatisierungsgrad, sie ist etwas feingranularer und an IT-Lösungsmustern orientiert, die in der Finanzindustrie zur Digitalisierung von Kernprozessen dominieren. Und sie unterscheidet explizit zwischen Anforderungsklassen und Lösungsmustern (Abb. 1). Als Klassifizierungskriterium dient der Automatisierungsgrad sowie dazu komplementär die Prozessflexibilität und -komplexität. Im Kontinuum von komplett manuell bis vollautomatisiert lassen sich noch weitere Anforderungsklassen identifizieren. Aber zumindest als Oberklassen sind die sechs abgebildeten Klassen sinnvoll und erlauben eine grobe Zuordnung zu typischen IT-Lösungsmustern. Auf einer detaillierten Ebene kann es auch innerhalb einer Anforderungsklasse verschiedene Lösungskandidaten geben. Um hier den besten zu wählen, müssen weitere Eigenschaften betrachtet werden, beispielsweise Änderungshäufigkeit, Anzahl und Art beteiligter Systeme und periodische versus laufende Verarbeitung.

Mit den Anforderungsklassen korrelierte Eigenschaften

Bevor eine Lösung zur Prozessdigitalisierung konzipiert wird, sollten darüber hinaus alle in Abbildung 2 dargestellten Prozesseigenschaften bekannt sein. Die ersten vier Eigenschaften sind die bereits genannten Klassifizierungskriterien. Die weiteren vier sind eng mit diesen verbunden.

Der Automatisierungsgrad eines Prozesses unterteilt sich in die Automatisierung der im Prozess enthaltenen Aktivitäten und Aufgabenträger, die diese Aktivitäten ausführen, und die Automatisierung der Steuerung. Bezüglich der Aktivitätenautomatisierung gibt es ein Kontinuum von durchgängig manueller Sachbearbeitung bis zur komplett automatisierten Aktivitätenbearbeitung. Damit eng verbunden ist die Automatisierung der Prozessteuerung. Plastisch ausgedrückt: Beim Case Management steuert der Mitarbeiter den Prozess. Es gibt im Extremfall keinerlei Automatisierung der Prozesssteuerung. Bei automatischen Workflows steuert der Prozess den Mitarbeiter oder die aufgerufenen Automaten. Die Prozesssteuerung ist hier engmaschig und vollautomatisiert. Je größer der manuelle Anteil im Prozess, desto höher ist auch die Laufzeitflexibilität des Prozesses. So lassen sich beim Case Management die Aktivitäten, die Akteure und die Prozesssequenz zur Prozesslaufzeit beliebig auswählen. Bei hochautomatisierten Prozessen dagegen ist der Prozessverlauf inklusive der enthaltenen Aufgabenträger zur Entwurfszeit detailliert beschrieben, sodass es zur Laufzeit wenig Flexibilität gibt oder nur genau so viel, wie im Prozessmodell fixiert ist. Dieser Umstand führt zu folgendem, nicht unbedingt intuitiven Zusammenhang: Je größer die Laufzeitflexibilität, desto größer auch die reale Prozesskomplexität. Komplexität resultiert aus der Anzahl der im Prozess enthaltenen Elemente und deren Beziehungen. Und je umfangreicher oder komplexer ein Prozessmodell ist, desto mehr Prozessverläufe können generell zur Laufzeit ausgeprägt werden. Allerdings würde ein Prozessmodell, das alle erlaubten Prozessverläufe abbildet, ab einem gewissen Prozesstyp – nämlich dem Case Management – so groß, dass man es nicht mehr mit verhältnismäßigem Aufwand erstellen kann. Dazu steht scheinbar im Widerspruch, dass die Design-Time-Modelle dieser hochkomplexen Prozesse simpel aussehen. Das liegt daran, dass diese nicht den exakten Prozessverlauf abbilden, sondern nur die Prozessziele oder andere Parameter, die den möglichen Prozessverlauf grob einschränken.

Insofern gilt generell: Je komplexer der Prozess, desto geringer der Anteil vormodellierter Prozesselemente. Wenn für einen Dokumenten-orientierten Prozess beispielsweise primär spezifiziert ist, wie das Dokument oder dessen Inhalte aussehen, die am Ende des Prozesses stehen müssen, lässt das einen größeren Handlungsspielraum für die Akteure zu, als wenn jede erlaubte Aktivitäten-Abfolge vorgegeben ist. Je größer Prozesskomplexität und manueller Anteil, desto höher sind im Allgemeinen auch die variablen Kosten pro Prozessinstanz. Der Grund: Die manuelle Aktivitätenbearbeitung und Prozesssteuerung der Knowledge-Worker im Case Management ist teurer als die eines Automaten, der beispielsweise einige Schreib- und Leseoperationen ausführt. So einen Aufwand betreibt man hoffentlich nur, wenn der Ertrag auch entsprechend hoch ist. Also eher, wenn es um den Abschluss eines Großkredits als um die Eröffnung eines Girokontos geht. Die manuellen Anteile und der Prozesswert sind auch der Grund dafür, dass die Prozesslaufzeit auf der linken Seite der Skala tendenziell zunimmt. Hochautomatisierte Prozesse laufen eher in Minuten, Case-Management-Prozesse eher über Monate. Natürlich gibt es auch hier Ausnahmen, beispielsweise hochautomatisierte Batch-Läufe, die termingesteuert über mehrere Monate laufen. Die Anzahl der Prozessinstanzen ist im Allgemeinen negativ mit Prozesslaufzeit und Prozesswertigkeit korreliert und nimmt so im linken Teil der Skala ab.

ziemann_bpm_2

Abb. 2: Mit den Anforderungsklassen korrelierte Eigenschaften

Einzelne Anforderungsklassen und typische IT-Lösungsmuster

Manuelle, dynamische Prozesse haben einen hohen Unternehmenswert und werden mit Case-Management-Lösungen adressiert. Der Großteil der Prozesselemente, insbesondere die Sequenz, ist zur Entwurfszeit unspezifiziert und wird erst zur Laufzeit von Sachbearbeitern festgelegt. Das bewirkt eine hohe Flexibilität. Bei der herkömmlichen, funktionsorientierten Nutzung mehrerer Fachanwendungen innerhalb eines Prozesses ist der Prozesszusammenhang ex post nicht mehr sichtbar. Case-Management-Lösungen hingegen bieten eine explizite fachliche Prozesssicht, beispielsweise in Form einer elektronischen Akte. Weitere Kernkomponenten sind Aufgabenverwaltung und -zuweisung, Postkorbsysteme sowie GUIs für häufig im Prozess vorkommende Aufgaben. Ausführliche Beschreibungen von Case-Management-Lösungen finden sich beispielsweise bei Swenson [2]. Obwohl es auch für Case Management generische, kommerzielle Lösungen gibt, werden solche häufig noch individuell erstellt, um genau auf die Fach- und Unternehmensspezifika dieser hochwertigen Prozesse eingehen zu können.

ziemann_bpm_3

Abb. 3: Antragsprozess für Industrieversicherung als manueller, schwachstrukturierter Prozess

Manuelle, schwachstrukturierte Prozesse haben primär menschliche Aufgabenträger und eine semiautomatische Prozesssteuerung. Sachbearbeiter können in die Prozesssteuerung eingreifen, indem sie Aufgaben weiterleiten oder zuweisen, Parallelinstanzen erzeugen oder auch den kompletten Prozess beenden. Die hohe Laufzeitflexibilität führt zu einer hohen Prozesskomplexität. Im Gegensatz zum Case Management lässt sich der Prozessablauf aber zur Entwurfszeit noch spezifizieren, wobei die Prozessspezifikation eher eine Einschränkung erlaubter Prozessverläufe als detaillierte Wegbeschreibung ist. Deswegen lassen sich Prozesse dieser Anforderungsklasse auch besser mit status- als mit aktivitätsorientierten Prozessmodellen darstellen. Und selbst dann gerät die grafische Darstellung bei komplexeren Exemplaren dieser Gattung an ihre Grenzen.

Weil der Fokus in dieser Klasse eher auf Dokumenten als auf feingranularer Prozessabfolge liegt, werden die Prozesse typischerweise mit ECM-basierten Lösungen implementiert. Die Lösungen unterstützen auch sachbearbeiterzentrische Funktionen wie das Erzeugen von GUIs je Prozessaktivität sowie zugehörige Möglichkeiten zum weiteren Workflowrouting. Wie beim Case Management spielen hier Postkörbe eine zentrale Rolle, über die Aufgaben an Personen oder Teams geleitet werden können (Abb. 3).

Weil die Prozesse Monate, eventuell auch Jahre laufen können, muss die IT-Lösung mit langlaufenden Prozessinstanzen umgehen können. Auch der Bedarf für Änderungen an Prozessschablonen bereits gestarteter Instanzen muss adressiert werden. Im Gegensatz zu den stärker automatisierten Prozesstypen, dient eine Prozess-Engine hier nur der Ablaufsteuerung und nicht der Erledigung der Aktivitäten selbst. Deswegen werden hier auch keine elaborierten Mechanismen zur automatisierten Bearbeitung komplexer Geschäftsobjekte benötigt.

Semimanuelle, strukturierte Prozesse haben teils manuelle, teils automatisierte Aufgabenträger. Die Prozesssteuerung ist vollautomatisch. Wegen der hohen Nähe zur manuellen Bearbeitung können Sachbearbeiter aber auch direkt in die Prozesssteuerung eingreifen und beispielsweise Instanzen terminieren. Im Vergleich zum Case Management sind diese Prozesse generell zeitlich kürzer, weniger flexibel und weniger komplex. Deshalb können sie auch einfacher zur Designzeit abgebildet werden, beispielsweise mit BPMN. Diese Klasse liegt zwischen der hellen und der dunklen Welt, was sie IT-seitig interessant macht. Einerseits müssen helle Anforderungen wie langlaufende Instanzen, Laufzeitflexibilität, Postkorblösungen und hochwertige GUIs adressiert werden. Andererseits müssen dunkle Anforderungen wie Wiederstartbarkeit von Prozessinstanzen, automatische Fehlerbehandlung, automatische Bearbeitung sowie – zumindest temporäre – Persistenz von Geschäftsobjekten in der Prozess-Engine bei Aufrechterhaltung der unternehmensweiten Datenintegrität beachtet werden. Entsprechend kann die Klasse entweder mit einer ECM- oder einer serviceorientierten Engine adressiert werden; oder, wie in der Praxis auch anzufinden, durch selbstentwickelte Lösungen.

ziemann_bpm_5

Abb. 4: Antragsprozess Privat-Haftpflichtversicherung als kurzlaufender, hochautomatisierter Prozess

Kurzlaufende hochautomatisierte Prozesse werden im Idealfall komplett automatisch durchgeführt (Abb. 4). Nur im Ausnahmefall einer automatisch nicht zu lösenden, fachlichen Fehlersituation wird zum Sachbearbeiter ausgesteuert. Die Prozesssteuerung ist vollautomatisch und feingranular. Weil die Prozesse kurz laufen – typischerweise Minuten bis Tage – müssen Sachbearbeiter sie normalerweise auch nicht administrieren oder einsehen. Im Vergleich zu semimanuellen Prozessen sind diese Prozesse zeitlich kürzer, weniger flexibel, weniger komplex und werden typischerweise als Serviceorchestrierung umgesetzt. Dieser Prozesstyp wird auch Sachbearbeitersimulation genannt. Dies deutet bereits an, dass die Prozess-Engine hier nicht nur die Aufgabe hat, Arbeitsaufträge an verschiedene Automaten zu verteilen, sondern auch, deren Antworten entgegenzunehmen und zu bearbeiten. Entsprechend muss die Engine in der Lage sein, mit komplexen (XML-)Geschäftsobjekten umzugehen sowie automatische Fehlerbehandlung und eine performante, transaktionale Datenhaltung zu unterstützen. Bei hochautomatisierten Prozessen sind im Prozessmodell nicht nur grobgranulare fachliche Informationen, sondern auch feingranulare technische Elemente enthalten. Diese Eigenschaften sind für helle, menschenzentrierte Engines nicht selbstverständlich, da diese nicht mit so großen Datenmengen hantieren müssen. Um eine fachliche Prozesssicht zu ermöglichen, werden die relevanten Ereignisse üblicherweise in eine elektronische Akte exportiert. Während die fachlichen Prozessverläufe aus dem Case Management Jahrzehnte als auditrelevante Daten gespeichert werden müssen, haben die Prozessläufe der Serviceorchestrierung eher den transienten Charakter technischer Daten.

Langlaufende hochautomatisierte Prozesse haben zunächst die gleichen Eigenschaften wie die kurzlaufenden, dauern aber Monate bis Jahre, weil externe Ereignisse (Kundenrückmeldung) oder Termine („Prüfe in drei Monaten, ob eine Antwort eingegangen ist“) im Prozess enthalten sind. Diese Laufzeit hat Auswirkungen auf die anderen nicht funktionalen Anforderungen. Die Prozesse müssen Sachbearbeiter jetzt einsehen und administrieren können. Beispielsweise müssen diese in der Lage sein, Instanzen zu beenden. Auch die Anforderung, bereits laufende Instanzen inhaltlich anzupassen, wird jetzt kritisch. Damit fachliche und technische Releasezyklen nicht auseinanderlaufen, sollten Prozesse nur bis zu einer gewissen Laufzeit – Richtwert: sechs Monate – als eine Serviceorchestrierung und danach als Kette technisch entkoppelter Prozesse implementiert werden. Dabei sind die Teilprozesse nicht permanent aktiv, sondern werden nur bei Bedarf durch Geschäftsereignisse oder Termine zum Leben erweckt. Diese Verkettung von Services und Serviceorchestrierungen wird auch Servicechoreografie genannt. Weil hier der übergreifende Geschäftsprozess nur implizit abgebildet ist, muss die fachliche Nachvollziehbarkeit wieder über eine dedizierte fachliche Prozesssicht geschehen (Abb. 5). Ein alternatives Lösungsmuster wäre eine zentrale Orchestrierung mehrerer Teilprozesse. Im Unterschied zum Muster den gesamten Prozess in einer Serviceorchestrierung zu implementieren, sollte der Hauptprozess hier grobgranularer, und damit weniger änderungsanfällig sowie leichter zu persistieren sein.

ziemann_bpm_4

Abb. 5: Produktwechselangebote (Retail) als langlaufender, hochautomatisierter Prozess

Vollautomatisierte Massenprozesse bestehen aus kurzen, robusten Prozessketten mit sehr niedriger Komplexität und Laufzeitflexibilität (Abb. 6). Sie werden in hohen Volumina durchgeführt und haben pro Instanz niedrige Kosten und Erträge. Aufgabenträger und Prozesssteuerung sind vollautomatisiert. Häufig ist der Bedarf für diesen Prozesstyp stichtagsbezogen, sodass beispielsweise immer am Quartalsende hohe Volumina eines Prozesses schnell und zuverlässig verarbeitet werden. Dabei kommt es weniger auf die feingranulare Steuerung und Beobachtung einzelner Instanzen an, sondern darauf, ob ein Lauf insgesamt erfolgreich war oder Instanzen noch nachbearbeitet werden müssen. Das korrespondierende IT-Muster ist die Stapelverarbeitung, bei der große Stapel von Prozessinstanzen in Form von Dateien zwischen einigen wenigen Arbeitsstationen transportiert werden. Funktionen wie Bearbeitung komplexer Geschäftsobjekte durch die Prozessteuerung oder feingranulares Monitoring auf Instanzenbasis werden hier nicht verwendet und würden nur die benötigte Performanz beeinträchtigen. Wenn eine fachliche Nachverfolgbarkeit auf Instanzenbasis, beispielsweise über erfolgreiches Drucken von Kundenanschreiben, erforderlich ist, muss diese hier zusätzlich implementiert werden.

ziemann_bpm_6

Abb. 6: Jährliche Rechnungsschreibung für Privathaftpflicht als vollautomatisierter Massenprozess

Fazit

Natürlich wird diese Lösungserstellung immer ein kreativer, kontextabhängiger Vorgang sein. Aber um die Möglichkeit einer suboptimalen Designentscheidung zu minimieren, sollte man die Lösungsfindung systematisieren. Die dargestellte Anforderungstaxonomie bildet dafür eine Basis, die bei Bedarf ausgebaut und verfeinert werden kann. Eine interessante Frage ist, wie viele Anforderungsklassen eine Prozessanwendung abdecken soll. Hier muss jeweils im Kontext entschieden werden, ob ein Generalist die durchaus heterogenen Anforderungen abdecken kann oder ob verbundene Spezialisten besser sind. Mit einem Bild aus der Logistik: Ob ein integriertes Amphibienfahrzeug oder eine integrierte Transportkette aus Auto und Boot sinnvoller ist.

Aufmacherbild: finance bar graph via Shutterstock / Urheberrecht: Rawpixel.com

Verwandte Themen:

Geschrieben von
Dr. Jörg Ziemann

Dr. Jörg Ziemann ist seit fünf Jahren in der Talanx Systeme AG als IT-Architekt für die Themen Prozessdigitalisierung und Service-Integration verantwortlich. Davor hat er im DFKI am Institut von Prof. August-Wilhelm Scheer internationale Projekte im Bereich unternehmensübergreifende Geschäftsprozessautomatisierung geleitet. In dem Themenbereich hat er mehr als 30 Fachartikel und das Buch „Architecture of Interoperable Information Systems“ verfasst.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: