Vorgehensweise von der Modellbildung zur Digitalisierung

Zusammenfassung

In den vorangegangenen Kapiteln haben wir gezeigt, dass das Geschehen in Organisationen (Unternehmen, Verwaltungen etc.) auf Modellen aus unterschiedlichsten Disziplinen basiert. Geschäftsmodelle, Unternehmensarchitekturen mit Modellen für Leistungen (Produkte und Services), Aufbauorganisation , Prozesse, Daten und IT-Infrastruktur beschreiben, in welchem Bereich ein Unternehmen tätig ist, wie es dies bewerkstelligt, in welchen Austauschbeziehungen mit Partnern es steht, von welcher technischen Infrastruktur es unterstützt wird usw.

4.1 Einordnung in den Gesamtzusammenhang

In den vorangegangenen Kapiteln haben wir gezeigt, dass das Geschehen in Organisationen (Unternehmen, Verwaltungen etc.) auf Modellen aus unterschiedlichsten Disziplinen basiert. Geschäftsmodelle, Unternehmensarchitekturen mit Modellen für Leistungen (Produkte und Services), Aufbauorganisation , Prozesse, Daten und IT-Infrastruktur beschreiben, in welchem Bereich ein Unternehmen tätig ist, wie es dies bewerkstelligt, in welchen Austauschbeziehungen mit Partnern es steht, von welcher technischen Infrastruktur es unterstützt wird usw.

Bei den Modellierungssprachen haben wir uns auf Ansätze und Notationen für die Spezifikation von Geschäftsprozessen und damit die fachliche Gestaltung betrieblicher Vorgänge konzentriert. Im Zuge der Digitalisierung sind diese Vorgänge soweit möglich und wirtschaftlich sinnvoll mit Informations- und Kommunikationstechnik abzubilden. Sowohl den dafür geeigneten inkrementellen Verbesserungen bestehender Prozesse als auch grundlegenden Prozessinnovationen liegen kreative Gestaltungsleistungen zugrunde, die von den fachlichen Modellen zu ausführbaren Systemen führen sollen. Deshalb beschäftigen wir uns im folgenden Kapitel zunächst mit den typischen Aktivitäten des Geschäftsprozessmanagements. Mit dem Ansatz des Design Thinking beleuchten wir dann einen methodischen Ansatz, um kreativ Neuartiges hervorzubringen und komplexe Probleme zu lösen, ehe wir beide Konzepte miteinander in Beziehung setzen.

4.2 Aktivitätsbündel im Geschäftsprozessmanagement

4.2.1 Überblick

In Abschn. 1.8 haben wir bereits angesprochen, dass die Gestaltung von Geschäftsprozessen bis hin zu ihrer Ausführung als Instanzen bei der Abwicklung konkreter Geschäftsvorfälle („operatives Geschäft“) selbst einen Prozess darstellt. Dieser wird häufig als Geschäftsprozessmanagementzyklus mit Phasen wie Strategie , Entwurf, Implementierung und Controlling verstanden [1].

In der Praxis sind die Teilaktivitäten aber oft nicht klar voneinander abzugrenzen. Wir sehen diese deshalb weniger als Kreis mit sequenzieller Abfolge, sondern eher miteinander vernetzt und verwoben, wie es die Wabenstruktur in Abb. 4.1 andeuten soll. Die Darstellung zeigt außerdem, dass wir die Aufgaben etwas stärker differenzieren und als Aktivitätsbündel Analyse und Modellierung, Validierung , Optimierung, organisatorische Implementierung , IT-Implementierung sowie Betrieb und Monitoring unterscheiden.

Abb. 4.1

Aktivitätsbündel im Geschäftsprozessmanagement

Obwohl die übliche Darstellung als Zyklus suggeriert, dass bei Prozessmanagementvorhaben alle Aktivitätsbündel als Sequenz durchlaufen werden, hängen deren Auswahl und Reihenfolge von der konkreten Situation, z. B. vom Reifegrad eines Prozesses ab. Abschn. 4.2.2 bis 4.2.7 erläutern die Aktivitäten anhand eines Beispielprozesses. Dabei werden die Schritte zunächst komplett und auch in der angegebenen Reihenfolge durchlaufen. Ein solches Szenario ist etwa bei der erstmaligen Gestaltung oder einer kompletten Reorganisation eines Prozesses realistisch. Anschließend diskutieren wir in Abschn. 4.2.8 mehrere Szenarien für Verbesserungen, die sich aus den Erfahrungen im dem laufenden Betrieb der ursprünglich gestalteten Prozessumgebung ableiten lassen. Sie verdeutlichen die situativ unterschiedlichen Pfade durch die Aktivitätsbündel bei der Weiterentwicklung des Prozesses.

4.2.2 Analyse und Modellierung

Die Analyse dient der Erhebung von Informationen , warum ein Prozess existiert bzw. implementiert werden soll, welche Ziele eine Organisation mit diesem im Rahmen ihrer Strategie verfolgt, und wie in diesem aktuell gearbeitet wird. Ziele sind die Dokumentation und die Gewinnung von Anhaltspunkten für Verbesserungen . Die Modellierung verwendet u. a. die Ergebnisse der Analyse und befasst sich mit der Gestaltung der zukünftigen Arbeitsweise, also mit Prozessveränderungen und -innovationen. Wenn dazu weitere Informationen nötig sind, wechseln die Beteiligten wieder in den Analysemodus, um diese zu erheben, und agieren danach wieder gestaltend. Analyse und Modellierung lassen sich deshalb nicht scharf voneinander abgrenzen. Auch Validierung und Optimierung finden in der Regel bereits hier statt, wenn die Beteiligten das Modell iterativ nach besten Wissen und Gewissen und unter Berücksichtigung von in der Analyse erkannten Schwachstellen entwickeln und dabei Lösungsmöglichkeiten probieren und diskutieren.

Neben der Betrachtung von Rahmenbedingungen wie strategischer Bedeutung, Zielen und Risiken geht es bei Analyse und Modellierung im Wesentlichen darum zu analysieren bzw. zu spezifizieren (vgl. Abschn. 1.3),

• welche Handelnden (z. B. Menschen, Maschinen),

• welche Aktivitäten,

• nach welchen Geschäftsregeln (Business Rules),

• an welchen Geschäftsobjekten (z. B. an bestimmte Träger gebundene Informationen, physische Gegenstände)

• mit welchen Hilfsmitteln (z. B. IT-Systeme) ausführen und

• in welcher Weise sie dabei interagieren, um die gewünschten Prozessziele und -ergebnisse zu erreichen.

Zur Entwicklung von Prozessmodellen auf Basis dieser Erkenntnisse bedient man sich der in Kap. 3 vorgestellten Modellierungssprachen mit den dazugehörigen grafischen Notationen .

Bei der Analyse und Modellierung wird meist auch bereits eine wesentliche Voraussetzung für das operative Prozesscontrolling in der Betriebsphase geschaffen. Neben den bereits genannten Prozessattributen werden dafür Leistungsparameter (Kennzahlen ), insbesondere Process Performance Indicators (PPIs ), definiert, in einem Messgrößensystem systematisiert und mit Zielwerten versehen [2]. Typische Beispiele für PPIs sind Durchlaufzeit , Ausbringungsmenge pro Zeiteinheit, Fehlerrate, Kundenzufriedenheit o. Ä. Die PPIs und die dafür geplanten Soll-Werte bilden die Basis für das Geschäftsprozessmonitoring , also die operative Prozesskontrolle während der Ausführung (vgl. Abschn. 4.2.7 und 6.3.3).

Analyse und Modellierung im Fallbeispiel

Als Fallbeispiel verwenden wir den stark vereinfacht dargestellten Vorgang der Kreditantragsbearbeitung bei einer Bank. Dort gehen Anträge von Interessenten auf Gewährung eines Immobiliendarlehens ein. Vor der Erstellung eines Angebots prüfen Sachbearbeiter die Bonität des jeweiligen Kunden und die Werthaltigkeit der zu beleihenden Immobilie. Ist das Ergebnis beider Prüfungen positiv, fertigt der Sachbearbeiter ein Angebot an mit Daten wie Darlehenssumme, Zins- und Tilgungssatz und Laufzeit. Beträgt der Darlehensbetrag unter 200.000 € unterschreibt er das Angebot und schickt es dem Kunden. Im anderen Fall muss er erst noch die Zustimmung seiner Abteilungsleitung und bei mehr als 500.000 € die des Vorstands einholen. Ergeben sich aus der Bonitätsprüfung oder der Objektprüfung Anhaltspunkte für Risiken, nimmt ein Sachbearbeiter Kontakt mit dem Interessenten auf, um die weitere Vorgehensweise, z. B. eine Verminderung der Darlehenssumme, zu abzustimmen. Im Rahmen einer Analyse des Prozesses wurden diese Informationen erhoben und strukturiert (vgl. Tab. 4.1).

Tab. 4.1 Merkmale des Beispielprozesses und dafür ermittelte Information

Im vorliegenden Fall verwenden wir die in Kap. 3 beschriebene Modellierungssprache S-BPM zur Darstellung des Prozesses, da dieser in einer stark interaktionsorientierten Beschreibung vorliegt. Grundsätzlich wäre die Abbildung mit jeder anderen Modellierungssprache, die die Abbildung von Verantwortlichkeiten erlaubt (etwa eEPK oder BPMN) ebenso möglich.

Zusammen mit weiteren Informationen dienten diese Angaben als Basis für die Modellierung des Vorgangs. Die folgenden Bilder zeigen einen Auszug des zugehörigen Prozessmodells unter Verwendung der Modellierungssprache S-BPM (vgl. Abschn. 3.6). Abb. 4.2 stellt die involvierten Subjekte (Handelnde ) und die im Prozessablauf ausgetauschten Nachrichten dar.Die Kommunikationsstruktur (Subject Interaction Diagramm, SID) enthält noch keine Reihenfolgen, in denen die jeweiligen Nachtrichten ausgetauscht werden. Diese werden im Verhalten der Subjekte beschrieben. Abb. 4.3 und 4.4 zeigen das Verhalten des Subjekts „Interessent“ und auszugsweise das Verhalten des Subjekts „Sachbearbeitung Immobilienkredit“.

Abb. 4.2

Kommunikationsstruktur der Handelnden im Prozess Kreditanfrage

Abb. 4.3

Verhalten des Subjekts „Interessent“

Abb. 4.4

Verhalten des Subjekts „Sachbearbeitung Immobilienkredit“

Die nicht abgebildeten Verhaltensspezifikationen der Subjekte „Abteilungsleitung Immobilienkredit“ und „Vorstand“ sind analog zu beschreiben. Diese Subjekte würden in den Prozess involviert werden, wenn die gewünschte Kreditsumme 200.000 bzw. 500.000 Euro übersteigt. Diese Fälle sind in Abb. 4.4 nicht ausmodelliert – sie wären zusätzliche Zweige nach dem Zustand „Freigabe notwendig“.

4.2.3 Validierung

Unter Validierung verstehen wir im BPM-Kontext die Überprüfung, ob der gestaltete Prozess den vom (externen) Kunden und Prozesseigner erwarteten Output beispielsweise in Form eines Service oder Produkts erzeugt. Diese Frage nach der Effektivität bezieht sich auch schon auf die Ergebnisse von Teilschritten, also Prozessbeteiligte der eigenen Organisation als Kunden. So gilt es beispielsweise zu evaluieren, ob ein vorgelagerter Prozessschritt alle Informationen liefert, die ein Bearbeiter bei seiner Teilaufgabe für eine Entscheidung (z. B. Genehmigung) benötigt. Wir haben bereits angesprochen, dass ein Modell schon während seiner schrittweisen Entwicklung immer wieder in Teilen der Validierung unterzogen wird. Objekt der Validierung ist darüber hinaus das komplett fertiggestellte Prozessmodell, dessen Effektivität sichergestellt sein sollte, ehe es informationstechnisch umgesetzt wird (vgl. Abschn. 4.2.6). Sonst werden Fehler erst spät entdeckt und verursachen entsprechend hohe Kosten für ihre Beseitigung.

Validierung im Fallbeispiel

Das Prozessmodell für den Beispielvorgang wurde während seiner Entwicklung sowie abschließend validiert. Dabei wurde zum Beispiel zunächst festgestellt, dass im ursprünglichen Kreditantrag kein Feld für das Beschäftigungsverhältnis des Antragstellers vorgesehen war und somit eine wichtige Angabe zur Risikobeurteilung fehlt. Dies führte zur Erweiterung des Geschäftsobjektes und zu einem positiven Validierungsergebnis bei der entsprechenden Iteration .

4.2.4 Optimierung

Während die Validierung die Sicherstellung der Effektivität von Geschäftsprozessen zum Ziel hat, geht es bei der Optimierung um die Effizienz . Prozesseffizienz lässt sich über Prozessattribute zur Ressourcenbeanspruchung wie Dauer und Kosten fassen. Optimierung bedeutet, eine im Hinblick auf solche Prozessparameter optimale Gestaltung eines Prozesses zu finden. Wesentliche Ansatzpunkte sind Verbesserungen der ablauforganisatorischen und aufbauorganisatorischen Gestaltung sowie der IT-Unterstützung. Die Optimierung ist demnach streng genommen kein eigenständiges Aktivitätsbündel, sondern bedient sich der Modellierung, der organisatorischen Implementierung und der IT-Implementierung (vgl. Abschn. 4.2.2, 4.2.5 und 4.2.6).

Eine bekannte Methode für den Vergleich von Alternativen im Ablauf oder beim Ressourceneinsatz ist die Simulation . Mit ihrer Hilfe lassen sich für eine größere Menge von Prozessinstanzen (Aufträge, Fertigungsstücke etc.) quantitative Aussagen über die Entwicklung von Prozessparametern gewinnen. Die Simulation ermöglicht die Bewertung eines Prozessmodells mit einer bestimmten Kombination von Parametern. Dies können deterministische oder auch stochastische, durch Wahrscheinlichkeitsverteilungen beschriebene Größen sein. Durch Parameteränderungen und alternative Prozessgestaltungen können verschiedene Gestaltungsoptionen in ihrem Verhalten analysiert werden. Damit lassen sich Erkenntnisse über Engpässe bzw. Ineffizienzen und die Sensitivität von Parametern gewinnen. Der Aufwand für die Erweiterung eines Prozessmodells und für die Beschaffung notwendiger Informationen, um Simulationen durchführen zu können, kann beträchtlich sein.Eine Schwierigkeit bei der Optimierung besteht darin, dass die relevanten Attribute oft interdependent und in ihrer Veränderung einander gegenläufig sind. So kann es sein, dass eine Prozessalternative relativ zu einer anderen zwar eine geringere Durchlaufzeit, dafür aber höhere Kosten aufweist. Die Entscheidung für eine Alternative hängt damit auch von der Priorität der Prozessziele ab.

Optimierung im Fallbeispiel

Das Modell konnte bereits bei seiner Entstehung optimiert werden, und zwar durch die Parallelisierung der zunächst sequenziell geplanten Schritte zur Prüfung der Kundenbonität und der Werthaltigkeit der Immobilie.

4.2.5 Organisatorische Implementierung

Validierte Prozesse müssen für den Produktivbetrieb in die bestehende und gegebenenfalls neu zu gestaltende organisatorische Umgebung eingebettet werden. Dies erfordert i. d. R. eine Anpassung der sie umgebenden Ablauf- und Aufbauorganisation .Ein einzelner Prozess ist meist Teil einer gesamten Wertschöpfungsumgebung (Wertschöpfungskette , Wertschöpfungsnetz ), in die er sich nahtlos einfügen muss. Im Hinblick auf die ablauforganisatorische Integration in die Prozesslandkarte sind deshalb insbesondere die Schnittstellen mit anderen Prozessen zu betrachten. Dies kann dazu führen, dass an Schnittstellen eines vor- oder nachgelagerten Prozesses Änderungen durchzuführen sind. Solche Sachverhalte sind im Regelfall bereits in den vorgelagerten Aktivitätsbündeln berücksichtigt. Bei der Implementierung darf es deshalb letztlich nur noch um die zeitliche Synchronisation der Produktivsetzung gehen. Damit ist gemeint, dass Prozesse, die über Schnittstellen verbunden sind, gleichzeitig erneut produktiv gesetzt werden müssen, wenn sich an einer Schnittstelle eine Veränderung ergeben hat, die auch beim Partnerprozess Modifikationen nötig gemacht hat.

Die aufbauorganisatorische Einbettung umfasst die Zuordnung von konkreten Handlungsträgern , also letztlich Menschen als Stellen- oder Rolleninhaber, zu den im Modell abstrakt spezifizierten Akteuren. Herausforderung ist dabei u. a. die Berücksichtigung des organisatorischen Kontexts beim Einsatz von Workflow Engines . Diese müssen etwa zur Laufzeit dynamische Vertreterregelungen ebenso auflösen können wie die Tatsache, dass Personen im selben Prozess verschiedene Rollen bekleiden können. Beispielsweise kann eine vorgesetzte Person im Urlaubsantragsprozess der Genehmiger von Urlaubsanträgen der eigenen Mitarbeiterinnen und Mitarbeiter sein, selbst aber auch Antragsteller für den eigenen Urlaub sein, den wiederum der eigene Vorgesetzte genehmigen muss. Für die korrekte Steuerung einer Instanz durch die Bearbeitungsstellen und – schritte muss die Software also Organisationswissen besitzen.Bei der organisatorischen Einbettung sind weitere qualitative und quantitative Aspekte zu berücksichtigen. So ist darauf zu achten, dass die Mitarbeiterinnen und Mitarbeiter die für die Ausführung des modellierten Verhaltens nötigen Qualifikationen (Skills) besitzen oder durch Schulungen erwerben können. Adäquate Qualifikation ist nicht nur Voraussetzung für eine erfolgreiche Arbeit im aktuell gültigen Prozess, sondern fördert auch Impulse für Verbesserungen seitens der Prozessbeteiligten.

Die Anzahl der Personen, die den abstrakten Akteuren im Modell zugeordnet werden, beeinflusst die Kapazität für die Bearbeitung von Prozessinstanzen und wirkt sich damit auf Parameter wie die Durchlaufzeit aus.

Organisatorische Implementierung im Fallbeispiel

Den identifizierten und modellierten Rollen wurde die in Spalte 2 in Tab. 4.2 aufgeführte Zahl von Mitarbeiterinnen und Mitarbeitern zugeordnet, welche die Rolle aufgrund ihrer Qualifikation prinzipiell besetzen können. Die dritte Spalte enthält die tatsächliche eingesetzte Kapazität (kurzfristige Ausfälle z. B. wegen Krankheit sind nicht berücksichtigt). Die Abteilungsleitungen für Immobilien- und Konsumentenkredite vertreten sich gegenseitig sowohl in disziplinarischen als auch in fachlichen Angelegenheiten. Dies gilt analog für die Vorstände.

Tab. 4.2 Potenzielle und konkrete Besetzung von Rollen

4.2.6 IT-Implementierung

Die meisten Prozesse sind ohne IT-Unterstützung nicht wirtschaftlich auszuführen. Insbesondere wenn ein hoher Automatisierungsgrad eines Ablaufes angestrebt wird, erlangt die Qualität der Abbildung in der IT hohe Bedeutung. Aber auch oder gerade an Stellen, wo der menschliche Bearbeiter involviert ist (z. B. Eingaben tätigen, Entscheidungen treffen), muss viel Wert auf die bedarfsgerechte Gestaltung der IT-Systeme gelegt werden.

Die IT-bezogene Implementierung eines Prozesses bedeutet, ihn als IT-gestützten Workflow unter Integration einer geeigneten Benutzeroberfläche, der Ablauflogik und der beteiligten IT-Systeme abzubilden. Dazu gilt es zunächst, die mehr oder weniger formale Modellbeschreibung (vgl. Kap. 3) in eine von einer Workflow Engine interpretierbare Sprache, d. h. ein ablauffähiges Programm zu überführen. Damit kann die Engine die Abarbeitung einer Prozessinstanz zur Laufzeit gemäß dem Modell steuern. Für die Erledigung einzelner Teilaufgaben bei der Abarbeitung sind meist eine ganze Reihe von Softwareapplikationen und – Services in den Ablauf zu integrieren. Typische Beispiele sind ERP-Transaktionen und Dokumenten- und Content-Management-Systeme. Ausgiebige Tests der implementierten Lösungen müssen die Qualität der Prozessunterstützung durch IT sichern.

IT-Implementierung im Fallbeispiel

Tab. 4.3 zeigt die wesentlichen Elemente der IT-Umgebung, welche zur Unterstützung des Prozesses und seiner Teilschritte aufgebaut wurde, zusammen mit ihren wichtigsten prozessrelevanten Funktionen .

Tab. 4.3 Realisierte IT-Umgebung des Prozesses

4.2.7 Betrieb und Monitoring

Implementierte Prozesse gehen nach der Abnahme in den Echtbetrieb (Going Live). Dies bedeutet, dass die Prozessbeteiligten sie in der aufgebauten organisatorischen und informationstechnischen Umgebung im Tagesgeschäft in Form von Instanzen ausführen.

Für die Gewinnung von Information für das bewusste Management der Prozesse ist die Beobachtung ihres Verhaltens im laufenden Betrieb nötig. Dieses Monitoring nimmt Messdaten auf und berechnet daraus Ist-Werte für die bei der Analyse und Modellierung definierten Process Performance Indicators . Ein sofortiger Vergleich mit definierten Soll-Größen führt bei Abweichungen zu Eskalationen entlang der Managementhierarchie und gegebenenfalls zu kurzfristigen Maßnahmen. Mittel- und längerfristige Auswertungen lassen strukturelle Verbesserungsmöglichkeiten erkennen. Die Analyse des Prozessverhaltens und möglicher Abweichungen lässt Rückschlüsse auf Ursachen zu und löst Rückkopplungen in andere Aktivitätsbündel aus.

Betrieb und Monitoring im Fallbeispiel

Seit Freigabe des Prozesses arbeitet die Bank Kreditanträge der Interessenten in der beschriebenen Form und Umgebung ab. Das Monitoring für das vergangene Quartal ergab folgende durchschnittliche Zahlen:

• Interessenten haben 50 Anträge pro Woche gestellt

• Die Bank hat 20% davon abgelehnt, die Hälfte davon wegen mangelnder Bonität

• Zu den restlichen Anträgen erhielt der Interessent ein Angebot innerhalb von 4 Tagen

• In 30% der Fälle hat der Interessent das Angebot angenommen und einen Vertrag abgeschlossen

Da Mitbewerber mit sehr kurzen Bearbeitungszeiten werben, nimmt die Bank an, dass die Dauer von 4 Tagen bis zum Erhalt eines Angebots bei sonst vergleichbaren Konditionen einer der Gründe ist, warum Kunden keinen Vertrag abschließen. Sie weicht auch signifikant vom vorab formulierten Ziel von 3 Tagen ab.

4.2.8 Verbesserungsszenarien

Die folgenden Szenarien zeigen, wie mit weiterführenden Analysen der Monitoring-Ergebnisse nach Ursachen für die lange Durchlaufzeit geforscht, und für Verbesserungsmaßnahmen (Optimierung ) in passende Aktivitätsbündel verzweigt werden kann. Davon hängt im Einzelfall der weitere Pfad durch die Aktivitätsbündel ab, also welche Tätigkeiten anschließend nötig sind, ehe der umgestaltete Prozess produktiv gesetzt werden kann. Die Ausführungen beschränken sich zur Vereinfachung jeweils auf eine Maßnahme. In der Realität wird man meist mehrere Optimierungsmöglichkeiten parallel verfolgen.

4.2.8.1 Verbesserungsszenario 1

Die Betrachtung der Häufigkeitsverteilung für den Anfall der Kreditanträge hat ergeben, dass montags 25, dienstags 15, mittwochs 6 und donnerstags und freitags je 2 Anträge vorliegen. Dies könnte daran liegen, dass Interessenten am Wochenende vermehrt Immobilien besichtigen, Kaufentscheidungen treffen und die Finanzierung angehen. Die Auswertung der Liegezeit bis zur Bearbeitung durch die Sachbearbeitung Immobilienkredit zeigt, dass dort zu Wochenbeginn wegen des hohen Aufkommens ein Engpass vorliegt. Bei der derzeit vorgehaltenen Kapazität von 5 Sachbearbeitern in Vollzeit beträgt die durchschnittliche Liegezeit 2 Tage. Um diese und damit die Durchlaufzeit zu verringern, könnte im Rahmen der organisatorischen Implementierung an den Montagen und Dienstagen zusätzliche Sachbearbeitungskapazität, etwa in Form verfügbarer Halbtageskräfte eingesetzt werden. In diesem Fall ändert sich der Prozess nicht, es sind keine weiteren Aktivitäten nötig.

4.2.8.2 Verbesserungsszenario 2

Eine genauere Analyse hat ergeben, dass die hohe durchschnittliche Durchlaufzeit von den Anträgen mit Beträgen zwischen 200.000 € und 500.000 Mio. € verursacht wird, weil die Liegezeit bis zur Genehmigung durch die Abteilungsleitung relativ zu den anderen Anteilen der Gesamtdauer sehr hoch ist. Dies liegt daran, dass Abteilungsleitung und Stellvertretung z. B. wegen häufigen Dienstreisen nicht regelmäßig für Genehmigungen zur Verfügung stehen.Der interne Prozessberater der Bank schlägt eine Änderung der Geschäftsregel zur Genehmigung vor. Zukünftig soll es den Sachbearbeitern erlaubt sein, für Beträge bis 500.000 € Angebote selbst zu unterschreiben und zu verschicken. Diese Reorganisation berührt mehrere Aktivitätsbündel . Zunächst erfordert sie eine Änderung des Modells, da die Genehmigungsschleife über die Abteilungsleitung entfällt. Die Modelländerung bedarf der anschließenden Validierung, um sicherzustellen, dass der geänderte Ablauf (immer noch) zum gewünschten Ergebnis führt. Im Rahmen der IT-Implementierung muss die Modifikation des Modells auch in die Workflow-Software überführt und getestet werden.Durch den Wegfall der Genehmigungen ändert sich der Aufgabenzuschnitt bei der Abteilungsleitung. Bei der Sachbearbeitung bleiben die Aufgaben zwar gleich, jedoch erhöhen sich Kompetenz und Verantwortung. Diesen Änderungen ist in der organisatorischen Implementierung Rechnung zu tragen, etwa durch aktualisierte Aufgabenbeschreibungen und möglicherweise durch Qualifikation der Sachbearbeiter mithilfe von Schulungen z. B. zur umfangreicheren Risikoabschätzung. Dieses Szenario greift im Vergleich zum Fall 1 massiv in die Art ein, wie im Prozess gearbeitet wird, und erfordert deshalb wesentlich umfangreichere Aktivitäten.

4.2.8.3 Verbesserungsszenario 3

Die Bank holt Bonitätsdaten über die Antragsteller bei der Schutzgemeinschaft für allgemeine Kreditsicherung (SCHUFA) ein. Hierzu übertragen die Sachbearbeiter Immobilienkredit die nötigen Kundendaten aus dem Kreditantrag in das Web-Formular der SCHUFA und die von dort gelieferten Abfrageergebnisse in das Bank-System zur weiteren Verarbeitung im bankeigenen Scoring. Die Sachbearbeiter berichten vom zeitraubenden Umkopieren der Daten durch Copy & Paste, den Fehlern die dabei entstehen, und den dadurch verursachten Nacharbeiten.

Um die Digitalisierung weiter voranzutreiben entscheidet die Bank ohne weitere Analysen, zukünftig anstatt der Internetauskunft der SCHUFA deren Web-Service zu nutzen. Dieser kann in den Workflow so integriert werden, dass die Process Engine ihn auf Knopfdruck des Sachbearbeiters aufruft und ihm die Kundendaten als Parameter übergibt. Der Service liefert das Ergebnis automatisch zurück an die Process Engine, die es in das Banksystem überträgt.Zu behandelnde Aktivitätsbündel beschränken sich in diesem Fall auf die IT-Implementierung, in deren Rahmen die entsprechenden Softwareanpassungen mit anschließenden Tests durchzuführen sind, ehe die Produktivsetzung erfolgt. Die Arbeitsweise der Beteiligten ändert sich nur geringfügig, es sind keine Qualifizierungsmaßnahmen nötig. Der Wegfall der manuellen Datenübertragung entlastet sie von stupiden, zeit- und damit kostenintensiven und fehleranfälligen Routinetätigkeiten. Der intensivere IT-Einsatz spart Bearbeitungs- und Durchlaufzeit sowie Kosten und erhöht die Kundenzufriedenheit.

4.2.8.4 Verbesserungsszenario 4

In Abschn. 4.2.4 haben wir beschrieben, dass bei der Modellierung die Kundenbonitätsprüfung und die Objektprüfung bewusst parallelisiert wurden, um Durchlaufzeit zu sparen. Die Analyse hat gezeigt, dass die Bank pro Woche fünf Anträge aus Bonitätsgründen ablehnt. In diesen Fällen haben aber Sachbearbeiter bereits Aufwand für die parallele Wertprüfung der betreffenden Immobilien betrieben. Diesen einzusparen könnte zunächst wieder dafür sprechen zuerst die Bonität zu prüfen und nur bei positivem Ergebnis die Wertprüfung durchzuführen. Nötig wäre eine Modelländerung mit Validierung und Anpassung der Workflow-Anwendung.

Die Rückführung der arbeitsteiligen Prüfung würde aber wieder die Durchlaufzeit erhöhen und zu einem Zielkonflikt führen. Deshalb gilt es weiter zu überlegen, ob sich der Aufwand für die Wertprüfung durch Automatisierung vermindern lässt, sodass eine unnötige Prüfung nicht mehr ins Gewicht fällt. Denkbar ist z. B., dass das Banksystem um Funktionen zur Bewertung erweitert wird. Es könnte dann nach automatischer Übernahme von Parametern aus dem Kreditantrag (Art, Größe, Baujahr, Adresse etc.) und angereichert mit Vergleichsinformationen (bankeigene Erfahrungswerte und Richtwerttabellen) und Geoinformationen (Infrastruktur mit Schulen, Einkaufsmöglichkeiten, Verkehrsanbindung etc.) einen Wertindex errechnen. Dieser beschleunigt die vom Sachbearbeiter vorgenommene finale Werteinschätzung. Bei dieser Möglichkeit könnte die parallele Ausführung der Schritte bestehen bleiben.

Anstelle einer Modelländerung wären die Zusatzfunktionalität in der IT-Implementierung zu realisieren und zu testen sowie die Sachbearbeiter im Umgang mit der Softwareerweiterung zu schulen.

4.3 Einführung in Design Thinking

4.3.1 Wesen

Design Thinking (DT) ist ein methodischer Ansatz, kreativ und gestalterisch tätig zu werden, um Neuartiges hervorzubringen und komplexe Probleme zu lösen. Es zeichnet sich durch Beschreiten neuartiger Wege zur lösungsorientierten Gestaltung aus. Problemstellungen können besser gelöst werden, indem bei fortlaufenden Iterationen und dem „Begreifbarmachen“ durch Prototypen die Bedürfnisse der (potenziellen) Nutzer in den Vordergrund gestellt werden. Über dieses grundlegende Verständnis von Design Thinking herrscht Einigkeit in Praxis und Wissenschaft¹. Das Spektrum, das der Ansatz abdeckt, wird dagegen nicht einheitlich gesehen.

Es gibt beispielsweise Interpretationen als Denkweise, Prozess und Werkzeugkasten [4]. Eine empirische Untersuchung belegt die Wahrnehmung im Kontinuum zwischen den beiden Polen Werkzeugkasten und Mindset (vgl. Abb. 4.5) [5].

Abb. 4.5

Verständnis von Design Thinking

Dies ist einerseits auf die unterschiedlichen Wurzeln zurückzuführen, andererseits aber auch eine Folge der dem Konzept inhärenten, stetigen, erfahrungsgeleiteten Weiterentwicklung und Anpassung in unterschiedlichen Kontexten. „Die ständige Weiterentwicklung ist ein wichtiger Teil von Design Thinking“ [6]. konstatiert Larry Leifer, einer der Protagonisten des Ansatzes an der d.school in Stanford, und betont: „Wenn Design Thinking eines Tages ein festgeschriebenes Manifest herausgeben sollte, würde es sich damit selber unkenntlich machen“ [6, S. 9].

Der Ansatz geht auf David Kelley von der Design-Agentur IDEO und die Professoren Larry Leifer und Terry Winograd von der Universität Stanford zurück. Insbesondere letztere stellten bei der Ingenieursausbildung fest, dass bei der Entwicklung marktfähiger Produkt weniger die rein technischen, sondern vielmehr nutzerbezogene Aspekte im Mittelpunkt stehen sollten. Diese Erkenntnis führte etwa ab den 1980er-Jahren zur Entwicklung des DT-Konzepts und manifestiert sich bis heute im Stanford-Kurs zum Mechanical Engineering 310 – Design Innovation (me310.stanford.edu). Zur weiteren Verbreitung in Forschung, akademischer Lehre und betrieblicher Praxis trug maßgeblich Hasso Plattner mit seiner Unterstützung der nach ihm benannten Einrichtungen des d.school Institute of Design an der Universität Stanford und der School of Design Thinking an der Universität Potsdam (HPI D-School) bei.

Aufgrund der Herkunft war DT ursprünglich vorwiegend auf die Entwicklung von physischen Produkten bezogen. Es findet aber mittlerweile vielfältige Anwendung in unterschiedlichen Gebieten wie bei der Entwicklung von Services oder ganzer Geschäftsmodelle, und gewinnt auch vermehrt in der Organisationsgestaltung und im Geschäftsprozessmanagement an Bedeutung.

4.3.2 Kernelemente

Kernelemente sind eine Mischung aus Mindset, Vorgehensweisen und konkreten Einrichtungen wie Arbeitsräumen. Dies spiegelt sich in der groben Einteilung in die drei „Ps“ wider, nämlich in die Bereiche People (Menschen ), Process (Prozess) und Place (Arbeitsumgebung).

Design Thinking beginnt mit der Schaffung tiefer Empathie für die Betroffenen. Es identifiziert die optimale Lösung im Überlappungsbereich von Wünschen der Menschen (menschlich-psychologischer Aspekt), der Machbarkeit (technologischer Aspekt) und Wirtschaftlichkeit (geschäftlicher Aspekt) [7]. Die zu entwickelnde Innovation soll etwas sein, das

• die Menschen wirklich mögen (desirability),

• aus technologischer und prozessualer Sicht machbar ist (feasibility) und

• aus wirtschaftlicher Sicht erfolgreich ist (viability).

Um dies zu erreichen durchläuft ein interdisziplinäres Team (People) in variablen, Kreativität fördernden Räumlichkeiten (Place) einen Prozess (Process) mit vielen Iterationen, wobei eine Vielzahl von Methoden zum Einsatz kommen kann.

4.3.2.1 People

Die Fokussierung auf den Menschen erfolgt in zweierlei Hinsicht:

Zum einen stehen Vertreter der Zielgruppe der Innovation , d. h. Kunden oder Anwender, mit ihren Bedürfnissen im Vordergrund. Empathie für sie zu entwickeln, sich in ihre Lage im betrachteten Kontext zu versetzen und somit ein tiefes Problemverständnis zu erlangen, ist der Grundstein für erfolgreiche Innovation und nimmt breiten Raum in dem im Abschn. 4.3.2.2 beschriebenen Prozess ein.

Zum zweiten stellt Design Thinking stark auf die am Projekt beteiligten Menschen als Einzelpersonen und als Team ab. Es sieht vor, die Diversität in interdisziplinären Teams für die Erhöhung der Ergebnisqualität zu nutzen. Teammitglieder sollen „T-Shaped “, d. h. sowohl Experten als auch Generalisten sein. Als Experten sind sie tief verwurzelt in ihrem Fachgebiet und bringen die entsprechende Expertise ein (senkrechter Strich des T). Damit kann auch die fachliche Vertretung einer Interessengruppe (Stakeholder) einhergehen (z. B. Vertrieb, Produktion, IT). Der Blick aus unterschiedlichen Perspektiven auf eine Problemstellung und die Synthese von Know-how und Erfahrungen aus verschiedenen Domänen hilft oft, neuartige Lösungsansätze zu entwickeln.

Die Eigenschaft als Generalisten ist Voraussetzung dafür, von der eigenen Perspektive in die von anderen Beteiligten zu wechseln und offen zu sein für die Zusammenarbeit an den (fachlichen) Schnittstellen (waagrechter Strich des T, „Wir“-Denken ) [8, S. 122 ff.]. Lewrick et al. plädieren deshalb für interdisziplinäre versus multidisziplinäre Teams, weil erstere wirklich kollektiv Ideen hervorbringen und hinter diesen stehen, wogegen die Mitglieder multidisziplinärer Teams bei der Lösungsfindung oft die eigene Perspektive überbewerten. Letzteres führt eher zu Kompromisslösungen, die nicht von allen hundertprozentig mitgetragen werden [8]. Ein interdisziplinäres Team ist idealerweise heterogen zusammengesetzt, nicht nur aus Vertretern möglichst vieler Fachgebiete, sondern auch unterschiedlicher Altersgruppen, Nationalitäten und Geschlechter.

Der Erfolg eines Design-Thinking-Projektes wird maßgeblich durch die individuellen Eigenschaften der Mitglieder dieses Teams und der daraus erwachsenden gemeinschaftlichen Arbeitskultur und Denkweise bestimmt. Im Zentrum steht dabei, dem Menschen als Ausgangspunkt aller Aktivitäten hohe Wertschätzung und Empathie entgegenzubringen, sowohl den Kolleginnen und Kollegen im Team als auch den Benutzern bzw. Kunden. Dazu sollen Eigenschaften kommen wie Kooperationsfähigkeit, Neugier, Experimentierfreude, integratives Denken und Optimismus der Teammitglieder. Ein weiterer Erfolgsfaktor ist die Begleitung des Teams durch eine mit dem Prozess und dem Methodeneinsatz erfahrene Person als Facilitator . Diese gibt Orientierung über das jeweilige Stadium im Prozess und welche Instrumente dort am besten zu verwenden sind, ohne jedoch inhaltlich zu intervenieren.

4.3.2.2 Process

Design Thinking folgt einem Vorgehensmodell mit einer Reihe von Schritten. Zwar haben sich mit der Zeit leicht unterschiedliche Varianten des sogenannten Mikrozyklus mit alternativen Bezeichnungen der Phasen herausgebildet, welche aber inhaltlich letztlich kaum voneinander abweichen. Wir orientieren uns an dem Modell der d.school in Stanford, das dem Design-Thinking-Prozess fünf auch als Arbeitsmodi bezeichnete Phasen zugrunde legt (vgl. Abb. 4.6).

Abb. 4.6

Design-Thinking-Prozess nach Stanford d.school

Gekennzeichnet sind alle Modelle vom Wechsel zwischen divergentem und konvergentem Betrachten, Denken und Agieren, sowohl beim Verstehen des Problemraums und Gestalten des Lösungsraums. Der Übergang zwischen der Ausweitung des kreativen Rahmens mit stetig zunehmender Informationsmenge und dem Fokussieren durch Eingrenzung wird als Groan Zone bezeichnet, also als eine Stelle wie ein „knarzendes“ Scharnier [8, S. 28 f.]. Auch die bewusste Iteration ist ein grundlegendes Element im DT-Prozess, das sich in dem Motto „fail early, fail often“ bzw. „fail forward“ in einer offenen Fehlerkultur äußert. Es beschreibt die Vorstellung, dass ideale Lösungen nur durch mehrfaches frühzeitiges Experimentieren, Testen und Berücksichtigen des Feedbacks der Zielgruppe gefunden werden können, was zu mehr oder weniger umfangreichen neuen Durchläufen früherer Modi führen kann. Die mehrfachen Iterationen sollen als sogenannter Makrozyklus vom Problemverständnis zur Konkretisierung einer Lösungsvision führen und in einem Umsetzungsplan münden [8, S. 37 f.].

In allen Prozessphasen gilt das Prinzip „Be visual & show“, was bedeutet, dass Gedanken, Ideen, Ergebnisse visuell und plastisch dokumentiert und vorgeführt werden sollen, etwa durch Post-its mit Stichworten und Zeichnungen, Mindmaps, Process Maps, greifbare Prototypen etc. Aufgrund dieses Prinzips wird manchmal auch vorgeschlagen, besser von Design Doing anstatt von Design Thinking zu sprechen.

Für die erfolgreiche Arbeit eines Teams entlang des Prozesses hat sich eine Reihe von Regeln und Tipps (Rules of Engagement ) als hilfreich erwiesen, von denen einige auch generell bei Gruppenarbeiten zu beachten sind. Sie sollten zu Beginn eines Projekts kommuniziert und im weiteren Verlauf vom Facilitator bei Bedarf in Erinnerung gerufen werden:

• Nutzerorientierte Denk- und Arbeitsweise (Entwicklung vom Empathie)

• Keine Vorgabe oder Beschränkung von Denkweisen, Lösungswegen oder Lösungen (Offenheit, Autonomie; „Go for quantity“)

• Konzentration auf das Thema (Fokussiertheit), daher auch keine Ablenkung durch Handys, Computer, iPads, Smart Watches etc., es sei denn sie sollen bewusst z. B. für Recherchen oder zur Prototyperstellung eingesetzt werden

• Aktive Teilnahme jedes Teammitglieds (eigene Artikulation, diszipliniertes Zuhören („One conversation at a time“) und Aufbauen auf Ideen anderer)

• Förderung der Entwicklung unterschiedlicher Perspektiven und wilder Ideen („Encourage wild ideas“)

• Keine Wertungen bei der Ideengenerierung („Defer judgement“, „No killer phrases“)

• Zeitlimitierung („Time Boxing“), um Verliebtheit in eine bestimmte Idee zu vermeiden

Die folgenden Abschnitte beschreiben jede Phase kurz zusammen mit einer tabellarischen Auswahl an Methoden und Werkzeugen, welche dort zum Einsatz kommen. Ausführlichere Erläuterungen dazu finden sich beispielsweise im Bootcamp Bootleg der d.school [9] und bei [8, S. 36 ff.].

Empathize (Empathie aufbauen)

Empathie ist das Herzstück eines menschen-zentrierten Designprozesses. Sie zu entwickeln heißt, ein tiefes Verständnis für die Mitglieder der Zielgruppe aufzubauen im Hinblick auf die Problemstellung und deren Kontext. Ziel ist es zu verstehen, warum und wie die Menschen Dinge tun, wie sie über die Welt denken und was ihnen wichtig ist und sinnvoll erscheint, sowie etwas über ihre körperlichen und emotionalen Bedürfnisse zu erfahren. Dies bedeutet die Nutzer zu beobachten, ihnen zuzuhören, mit ihnen zu interagieren, sich in ihre Situation einzudenken und einzufühlen und damit in ihre bewusste und unbewusste Welt von Gefühlen, Werten und Bedürfnissen einzutauchen (engage, observe, immerse). Dies ist die Grundvoraussetzung, um Innovationen in die richtige Richtung zu lenken.

Ein wesentliches Instrument zur Dokumentation des Verständnisses für die Zielgruppe sind die sogenannten Personas . Sie stellen fiktive Kunden oder Benutzer dar und verkörpern deren unterschiedliche Ziele, Verhaltensweisen, Bedürfnisse und Eigenschaften mit Relevanz für die zu entwickelnde Lösung.

Im Modell des Hasso-Plattner-Instituts umfasst „Empathize“ die Phasen „Verstehen“ und „Beobachten“. Tab. 4.4 zeigt gängige Instrumente für die in der Phase enthaltenen Aktivitäten.

Tab. 4.4 Methoden und Werkzeuge für die Phase „Empathize“

Define (Problemstellung definieren)

In diesem Modus geht es darum, auf den Erkenntnissen aus dem Modus „Empathize“ aufzubauen, sie zu teilen und zusammenzuführen, zu strukturieren, zu gewichten und zu interpretieren. Diese Synthese dient dazu, die Personas für idealtypische Nutzer zu prüfen und weiterzuentwickeln und gegebenenfalls die Perspektiven verschiedener Stakeholder einzunehmen. Ergebnisse sind ein weiter vertieftes Verständnis für die Benutzer und den Problemraum sowie eine konkretisierte, aussagekräftige Problemstellung (Design Challenge). Letztere schlägt sich in einem einzigen Satz nieder, welcher als sogenannter Point of View (POV ) die Frage für die anschließende Phase der Ideengewinnung bildet [8, S. 73]. In der Praxis werden unterschiedliche POV-Fragen verwendet. Eine typische Formulierung ist die „How might we?“-Frage, also beispielsweise „Wie könnten wir [User, Kunde] helfen, [ein bestimmtes Ziel] zu erreichen?“ [8, S. 74].

Im Modell des Hasso-Plattner-Instituts entspricht „Define“ der Phase „Standpunkt definieren“. In der folgenden Tab. 4.5 sind übliche Hilfsmittel für die in der Phase enthaltenen Aktivitäten aufgeführt.

Tab. 4.5 Methoden und Werkzeuge für die Phase „Define“

Ideate (Ideen gewinnen)

Das Ziel der Ideengewinnung ist es einen breiten Lösungsraum zu erarbeiten, also möglichst viele und auch möglichst unterschiedliche Ideen zu entwickeln und zu visualisieren. Ausgangspunkt ist die Point-of-View-Frage, jedoch gehen sämtliche bisher erarbeiteten Erkenntnisse in diese Phase ein, also beispielsweise auch User Profile Canvas, Empathy Map und Customer/User Experience Journey . Grundlegendes Instrument ist das Brainstorming , das durch Kreativitätstechniken und gezielte Aufgaben (z. B. Ideengenerierung zu bestimmten Funktionen) weiter und mehrfach stimuliert werden kann. Auch die Gestaltung erster „Low-Fidelity“-Prototypen und deren Test können weitere Denkanstöße für Lösungen liefern und Iterationen auslösen.

Der Methodeneinsatz in diesem Modus soll dazu befähigen, über offensichtliche Lösungen hinauszugehen und damit das Innovationspotenzial erhöhen, indem die kollektiven Perspektiven und Stärken des Teams genutzt werden. Unerwartete Lösungsrichtungen sollen aufkommen können und zur Menge und Unterschiedlichkeit der Ideen beitragen. So entsteht eine Vielzahl von Ideen, welche sortiert, verdichtet und bewertet werden. Beim gesamten Vorgehen sollte streng zwischen der Generierung und der Bewertung der Ideen getrennt werden, um nicht früh den kreativen Flow zu einzuschränken.

Im Modell des Hasso-Plattner-Instituts entspricht „Ideate“ der Phase „Ideen finden“. Gängige Instrumente für die in diesem Modus enthaltenen Aktivitäten sind Tab. 4.6 zu entnehmen.

Tab. 4.6 Methoden und Werkzeuge für die Phase „Ideate“

Prototype (Prototypen erstellen)

Das Prototyping greift die am höchsten bewerteten Ideen aus der Ideenentwicklung auf und bearbeitet sie weiter. Dabei wird der Grundsatz des Design Thinking umgesetzt, Sachverhalte, Produkte und Ergebnisse möglichst früh zu visualisieren und anhand greifbarer Modelle mit potenziellen Nutzern zu testen, zu diskutieren und mit dem erhaltenen Feedback weiterzuentwickeln. Prototypen werden also erzeugt, um zu lernen, offene Fragen und Unstimmigkeiten zu klären, eine Konversation bzw. einen Diskurs zu beginnen und schnell und noch günstig Sackgassen zu erkennen. Neben der Veränderung kann das Feedback auch zum kompletten Verwerfen und damit zu einer grundlegenden Iteration in weiter zurückliegenden Phasen führen. Dieses Vorgehen wird auch mit dem Slogan „Love it, change it or leave it“ umschrieben.

Prototyping transferiert Ideen aus dem Kopf in die physische Welt. Ein Prototyp kann demnach alles sein, was eine physische Form annimmt und der Maxime „don’t tell me, show me!“ folgt: eine Wand mit Post-it-Notizen, ein Rollenspiel , ein Raum, ein Objekt, ein Storyboard oder auch beliebige Kombinationen verschiedener Ausdrucksmittel.

Die Granularität des Prototyps sollte dem Projektfortschritt entsprechen. In den frühen Stadien eines Projektes sollten Prototypen entstehen, die schnell anzufertigen und kostengünstig sind (Low Fidelity, Quick & Dirty), aber schon nützliches Feedback von Benutzern und Kollegen hervorrufen. In späteren Stadien sollten die Prototypen verfeinert werden und bestimmte Fragestellungen eingehend untersuchen lassen. Sie dienen dazu, Empathie zu vertiefen, zu testen, weitere Ideen und Inspiration zu gewinnen.

Im Modell des Hasso-Plattner-Instituts entspricht „Prototype“ der Phase „Prototyp entwickeln“. Die folgende Tab. 4.7 zeigt gängige Instrumente für die in dieser Phase enthaltenen Aktivitäten.

Tab. 4.7 Methoden und Werkzeuge für die Phase „Prototype“

Test (Prototypen testen)

Wie im vorherigen Abschnitt bereits ausgeführt, ist Testen eng mit Prototyping verknüpft. Die Empfehlung „Prototype as if you know you’re right, but test as if you know you’re wrong.“ beschreibt eine Denkhaltung, welche diesen Zusammenhang verdeutlicht. Testen bietet die Chance, qualitatives Feedback zu den prototypischen Lösungen zu erhalten, sie besser zu machen, weiter über die Nutzer zu lernen und damit die Empathie für sie zu vertiefen. Der Testmodus ist ein iterativer Lernmodus, in dem die Prototypen in den Kontext des potenziellen Benutzers gestellt und von diesem benutzt und bewertet werden. Wichtige Prinzipien dabei sind: Zeigen und nicht reden, Erlebnisse schaffen und dem Benutzer Vergleiche ermöglichen.

Das Feedback bei den Tests kann nicht nur zu Veränderungen, sondern auch zum kompletten Verwerfen und damit zu einer grundlegenden Iteration über weiter zurückliegende Phasen führen. Dieses Vorgehen wird auch mit dem Slogan „Love it, change it, or leave it“ umschrieben [8, S. 34]. Prinzipiell ist bei jeder Iterationsschleife unabhängig von deren Umfang zu reflektieren, welche vorherigen Ergebnisse (z. B. Personas, User/Customer Experience Journey) aufgrund des Feedbacks angepasst werden müssen.

Im Modell des Hasso-Plattner-Instituts entspricht „Test“ der Phase „Testen“. Tab. 4.8 enthält Instrumente für die in der Phase ausgeführten Aktivitäten.

Tab. 4.8 Methoden und Werkzeuge für die Phase „Test“

4.3.2.3 Place

Für die Arbeit der interdisziplinären Teams in den beschriebenen Modi gilt es eine Kreativität fördernde Umgebung, sogenannte Make oder Creative Spaces, zu schaffen. Dies bezieht sich insbesondere auf die Verfügbarkeit, Größe und Einrichtung von Räumlichkeiten als auch auf Hilfsmittel und Materialien für Visualisierung und Prototypengestaltung. Es geht vor allem darum, den Teams, frei und dauerhaft verfügbare Arbeits-, Interaktions-, Entspannungs- und Lagerbereiche, flexible Möbel mit Rollen, beschreib- und abwischbare Flächen (Wände, Tische, Tafeln), sowie gute und schnelle Zugänge zu Informationen (Internet, Bibliotheken etc.), Werkzeugen, Arbeitsmaterialien und Verpflegung bereitzustellen [7, S. 216 ff.]. Auch Beleuchtung, Belüftung und Klimatisierung sind wichtige Rahmenbedingungen.

In der Praxis räumt man vor allem bei länger andauernden Projekten den Teams mitunter auch die Möglichkeit ein, die Umgebung selbst zu gestalten (z. B. Möbel selbst bauen). Doorley und Witthoft haben Anleitungen und Erfahrungen u. a. bei der Gestaltung von Kreativitätsumgebungen für die d.school publiziert [10].

4.4 Verbindung der Konzepte

4.4.1 Überblick

Wie gezeigt zielt Design Thinking auf die Innovation von Produkten und Services , Geschäftsmodellen und -prozessen ab. Im Mittelpunkt stehen Benutzerzentriertheit , Kreativität und Agilität in einem experimentellen, iterativen Prozess, den interdisziplinäre Teams durchlaufen.

Das Prozessmanagement verfolgt mit der agilen und kreativen Prozessneu- oder -umgestaltung unter Berücksichtigung von Kundenbedürfnissen eine vergleichbare Zielsetzung. Im Folgenden stellen wir Bezüge zwischen den Konzepten her und diskutieren die Erfolg versprechende Nutzung von Design-Thinking-Elementen für das Prozessmanagement.

Wir legen dabei besonderes Augenmerk auf die Digitalisierung von Prozessen, das heißt auf den sinnvollen Einsatz von Informations- und Kommunikationstechnik für die Prozessverbesserung und -innovation. Prototypen und endgültige Lösungen sind damit immer Workflow-Anwendungen unterschiedlichen Automatisierungsgrades.

4.4.2 Benutzerzentriertheit

Traditionelle BPM-Ansätze beziehen zwar bei der Prozessanalyse in der Regel die Beteiligten mit Interviews und Workshops ein. Im Vordergrund der aktivitäts- und ablaufbezogenen Interviewfragen, Kartenabfragen oder Beobachtungen stehen dabei jedoch die „harten“ Fakten der Arbeit im Prozess mit den in Abschn. 4.2.2 aufgeführten Merkmalen. Aspekte wie das Verstehen von Motivation, Denkweisen und Werten der Benutzer, die für die Entwicklung von Empathie im Design Thinking ausdrücklich betont werden, bleiben hier weitgehend unberücksichtigt. Daran haben auch neuere Konzepte wie Social BPM bisher wenig geändert.

Eine interessante Brücke kann der Ansatz des Subjektorientierten Business Process Management (S-BPM) schlagen, das bereits zu Beginn dieses Kapitels im Fallbeispiel verwendet wurde. Er stellt die Subjekte als Handelnde im Prozess in den Mittelpunkt der Betrachtung. Mit der dazugehörigen Methodik und Sprache (vgl. Abschn. 3.6) sowie geeigneten Werkzeugumgebungen können Vertreter von am Prozess beteiligten Subjekten nicht nur als Befragte oder Beobachtete, sondern als aktive Designer an der iterativen Lösungsentwicklung mitwirken. Sie spezifizieren dabei nicht nur explizit das Verhalten des von ihnen repräsentierten Subjekts und dessen Interaktionen mit anderen Beteiligten, sondern können durch die Ausführung des resultierenden Modells sofort das Ergebnis ihrer Gestaltung erproben und verändern. Bei all dem können sie implizit auch die oben angesprochenen „weichen“ Faktoren einbringen.

4.4.3 Agiler Prozess mit Iterationen

Umfangreichere Prozessmanagementvorhaben werden in der Praxis häufig nach wie vor mit traditionellen Projektmanagementmethoden in klar definierten Phasen mit Meilensteinen durchgeführt, vergleichbar dem Wasserfallmodell bei der Softwareentwicklung.

Dies bedeutet, dass der Weg von der Analyse über die Gestaltung des fachlichen Modells und dessen organisatorische und informationstechnische Umsetzung bis zu einer lauffähigen Workflow-Anwendung viel Zeit in Anspruch nimmt. Außerdem steigt damit die Wahrscheinlichkeit, dass die IT-Lösung von den sich weiterentwickelnden Bedürfnissen und Wünschen der Benutzer abweicht.

Insbesondere für die Prozessdigitalisierung ist es deshalb von Vorteil den agilen, iterativen Prozess des Design Thinking zu adaptieren. Dies eröffnet die Möglichkeit der steigenden Dynamik hinsichtlich der Entstehung neuer Prozesse und der Veränderungen bestehender Vorgänge, etwa aufgrund neuer oder geänderter Geschäftsmodelle wie Servitization , gerecht zu werden. Für die weiteren Überlegungen stellen wir die Modi des Design Thinking den Aktivitätsbündeln im Prozessmanagement gegenüber (vgl. Abb. 4.7).

Abb. 4.7

Zuordnung von Design-Thinking-Modi und BPM-Aktivitätsbündeln

In Verbindung mit den Ausführungen in Abschn. 4.2.2 und 4.3.2.2 zeigt die Abbildung, dass DT stärker zwischen Problemverständnis und Lösungsgestaltung trennt. Letztere beginnt erst mit Ideate. Davor wird ausgiebig die Ist-Situation beleuchtet und beispielsweise auf dem Weg über Personas in der Customer/User Experience Journey dokumentiert und visualisiert, ehe mit der Point-of-View-Fragestellung der Ausgangspunkt für die Ideengenerierung formuliert wird.

Beim Prozessmanagement ist die Problemstellung dagegen in der Regel bereits zu Beginn klar formuliert. Bei der Erneuerung bestehender Prozesse leitet sie sich meist aus dem Wunsch nach verbesserter Prozess-performance ab (z. B. Durchlaufzeitverkürzung). In der Praxis werden deshalb meist nur diesbezügliche Schwachstellen des Ist-Zustands dokumentiert und Analyseinformation genutzt, um, wie auch bei einem neuen Prozess, gleich ein neues Soll-Modell zu entwickeln und zu visualisieren. Der kreative, gestalterische Teil beginnt damit früher als beim Design Thinking und ist tendenziell mit weniger Information als Ausgangsbasis unterfüttert. Er ist stärker analytisch (z. B. durch Performance Indicators ) getrieben als durch die im Rahmen der Empathieentwicklung im Design Thinking identifizierten „weichen“ Faktoren. Unabhängig von der etwas unterschiedlichen konkreten Ausgestaltung lässt sich das Aktivitätsbündel Analyse & Modellierung den DT-Modi Empathize, Define und Ideate zuordnen.

Für eine umfassendere Erfassung des Problemkontextes und die dadurch erzielbare Ausweitung des Lösungsspektrums für die Prozessinnovation bietet sich der Einsatz bewährter DT-Instrumente an. Insbesondere bei der Entwicklung eines neuen Prozesses können die Teammitglieder z. B. mit einem Brain Dump zum Problemumfeld und der Diskussion der Ergebnisse ihren Betrachtungshorizont erweitern und ein gemeinsames Verständnis entwickeln.

Mithilfe von Personas für die Prozessbeteiligten in ihren jeweiligen Rollen sowie mit Interviews und Beobachtungen lassen sich Customer/User Experience Journeys beschreiben.

Sind Mitwirkende am Prozess selbst Teammitglieder können diese selbst ihre Erfahrungen ebenfalls als Journey visualisieren. Damit erweitert sich die Informationsbasis über die klassischen, objektiven Prozesscharakteristika hinaus um die Perspektive der Nutzer. Dieses breitere Fundament für das Entwickeln von Lösungsideen sollte den höheren Aufwand rechtfertigen.

In Abschn. 4.2.2 haben wir dargelegt, dass bereits bei der Analyse und Modellierung von Prozessen Überlegungen zur Effektivität und Effizienz zumindest von Modellteilen angestellt werden. Dies gilt insbesondere, wenn die späteren Anwender dies wie bei der Subjektorientierung selbst tun. Deshalb sind die Aktivitätsbündel Validierung und Optimierung dem DT-Modus Test zugeordnet, erstrecken sich aber auch über Empathize, Define und Ideate.

Mit dem Fokus auf Prozessdigitalisierung entspricht dem Modus Prototype beim Prozessmanagement das Aktivitätsbündel der IT-Implementierung . Das Prototyping im Design Thinking erhebt den Anspruch schnell und mit einfachen Mitteln, mithin kostengünstig, einen vorführbaren Prototyp zu erzeugen, um rasch Feedback vom Benutzer einzuholen (Modus Test) und dieses zu verwerten. Mit der Übertragung dieses „fail early, fail often“-Prinzips auf das Prozessmanagement muss das Team in die Lage versetzt werden, das Modell mit geringem Aufwand ausführbar zu machen. Im Vordergrund steht also die Erzeugung eines funktionalen Prototyps in Form von Software, der die Anwender erfahren und erleben lässt, wie ihre Arbeit mit der IT-Lösung aussehen würde.

Die Zuordnung zur IT-Implementierung sollte aber für den Prototyp nicht Programmierung bedeuten. Vielmehr muss es im Sinne der schnellen Iterationen möglich sein, den Prototyp aus dem Modell automatisch zu generieren und im Aktivitätsbündel Validierung die Nutzer erproben zu lassen. Anschließende Modelländerungen aufgrund des Feedbacks führen auf demselben Weg zu einem neuen Prototyp, so lange, bis eine Version gefunden ist, welche die Anwender zufriedenstellt. Solch kostengünstiges und frühzeitiges Prototyping verhindert möglicherweise aufwendigere Nacharbeiten bei der späteren Realisierung der echten Laufzeitumgebung. Mit einer vergleichbaren Vorgehensweise kann das Design der Benutzungsschnittstelle nach den Prinzipien des User Experience Design erfolgen.

Da das jeweilige Prozessmodell ja nicht nur die Basis für Prototypen, sondern in seiner letztlich verabschiedeten Version auch für die angestrebte Workflow-Anwendung ist, umfasst das Aktivitätsbündel IT-Implementierung auch deren Realisierung in der in Abschn. 4.2.6 beschriebenen Weise. Wenn dafür über die modellbasierte Workflow-Steuerung hinausgehende Software entwickelt werden muss, bietet sich im Sinne der benutzerzentrierten, agilen Vorgehensweise SCRUM als Software-Entwicklungsmethode an.

Im Zusammenhang mit der IT-Implementierung gilt es auch zu entscheiden, inwieweit man die von Software-Start-ups oft verwendete Strategie der Minimum Viable Products verfolgen möchte. Dies würde bedeuten, Software mit minimaler Funktion den Kunden bzw. Anwendern nicht nur prototypisch, sondern auch produktiv zur Verfügung zu stellen, um deren Feedback für die Weiterentwicklung einzuholen. Bei IT-Lösungen für geschäftskritische Prozesse könnte dies riskant sein, anderseits kann es durch frühe Gewöhnung von Kunden an Features möglicherweise einen Vorsprung gegenüber Mitbewerbern eröffnen.

Wie in Abschn. 4.2.5 und 4.2.7 erläutert, ist das Modell auch in die Organisation einzubetten (Organisatorische Implementierung), ehe der Prozess produktiv gesetzt werden kann (Betrieb & Monitoring).

Im Design Thinking folgen vergleichbare Schritte für die Implementierung z. B. eines Produkts auf Basis eines akzeptierten Prototyps, sowie für die Nutzung, die jedoch nicht mehr zu den Modi im engeren Sinn zählen (gepunktete Formen in Abb. 4.7).

Fazit

Um den Anforderungen der Digitalisierung von Prozessen gerecht zu werden sollte ein Prozessmanagementvorgehen Design-Thinking- und Prozessmanagementkonzepte kombinieren.

Es muss geeignet sein, Prozesse und deren Änderungen rasch sowohl fachlich als auch in der IT abzubilden und dabei in kurzen Iterationszyklen die Anwender adäquat einzubinden, um die entstehende Lösung deren Vorstellungen anzunähern.

Neben den für die Design-Thinking-Modi Empathize, Define und Ideate nutzbaren Instrumente sind dafür insbesondere einfach handhabbare Methoden und Werkzeuge nötig, mit denen das Team und/oder die Prozessbeteiligten selbst

• 1. individuell unterschiedliche mentale Modelle der Arbeit artikulieren können

• 2. diese verschiedenen mentalen Modelle harmonisieren können

• 3. daraus Lösungsideen und konkrete Lösungsvorschläge in Form von Modellen entwickeln können

• 4. diese Modelle automatisch in ausführbare Prototypen überführen und testen können

• 5. freigegebene Modelle mit begrenztem Aufwand in Workflow-Anwendungen für den Live-Betrieb überführen können

Ein Beispiel für ein Konzept zur Unterstützung von 1) und 2) ist Compare/WP (vgl. Abschn. 5.1.2). Die Anforderungen 3), 4) und 5) werden beispielsweise vom S-BPM-Ansatz und darauf basierenden BPM-Tools abgedeckt [11, 12].

4.4.4 Interdisziplinäres Team

Die Bedeutung der Interdisziplinarität des von einem Facilitator begleiteten Teams beim Design Thinking haben wir im Abschn. 4.3.2.1 ausgeführt.

Auch BPM-Projekte werden üblicherweise von Teams durchgeführt. Wir unterscheiden dabei vier Rollen :

Governors (Treiber und Verantwortliche) setzen die Rahmenbedingungen. Diese umfassen im Wesentlichen den Betrachtungsbereich (Scope), also die Abgrenzung des im Projekt bearbeiteten Prozesssystems sowie, konkret auf die Analyse und Modellierung bezogen, die Methodik und die Werkzeuge.

Actors (Arbeitshandelnde) sind die gegenwärtigen oder zukünftigen Akteure, welche die im zu verändernden oder zu entwickelnden Prozess zur Laufzeit die Aktionen in den Instanzen ausführen. Sie sind demnach die Träger konkreten ausführungsbezogenen Prozesswissens für ihren Anteil an der Erstellung des Prozessergebnisses, wissen also welche Teilschritte sie in welcher Reihenfolge erledigen, welche Informationen und Hilfsmittel sie dazu benötigen und mit wem sie dafür interagieren.

Experts (Spezialisten) unterstützen die anderen Rollen mit methodischem und fachlichem Wissen. Es sind beispielsweise Domänenexperten, die im betreffenden Fachgebiet über Expertise verfügen und einbringen können, welche über die der Actors hinausgeht. Methodenexperten helfen den Beteiligten, insbesondere den Actors, bei der Artikulation und Harmonisierung ihrer mentalen Modelle sowie bei der Umsetzung mit einer der in Kap. 3 vorgestellten Modellierungssprachen. Für die technische Implementierung der fachlichen Modelle werden schließlich IT-Experten hinzugezogen. Experten in den unterschiedlichen Feldern werden bei Bedarf auch von außerhalb der eigenen Organisation als externe Berater involviert.

Facilitators (Entwicklungsbegleiter) moderieren und koordinieren das Vorgehen und die Zusammenarbeit der Beteiligten. Sie sorgen beispielsweise dafür, dass Actors die Schnittstellen zwischen ihren Arbeitsschritten abstimmen und identifizieren für besondere Problemstellungen bei Bedarf geeignete Experten und binden sie ein. Bei alldem motivieren und überprüfen die Facilitators die Einhaltung der von den Governors gesetzten Rahmenbedingungen.

Beim traditionellen phasenorientierten Vorgehen im BPM wirken bei Analyse, Modellierung, Validierung und Optimierung unter der Projektleitung als Facilitator zunächst meist Actors und Experts als fachliche Inputgeber und Methodenexperten zusammen. Die Implementierung der verabschiedeten fachlichen Modelle übernehmen dann IT-Experten. Als Nachteile dieses Vorgehens haben wir bereits in Abschn. 4.4.3 die mitunter lange Dauer und dadurch bedingte Abweichung von den Bedürfnissen der Stakeholder identifiziert.

Seit einiger Zeit verbreitet sich deshalb der BizDevOps -Ansatz, der den im Zuge der Digitalisierung steigenden Agilitätsanforderungen Rechnung tragen will. Er strebt eine vergleichsweise engere Verzahnung von Fachabteilung (Business, Biz), IT-Entwicklung (Development) und IT-Betrieb (IT Operations) an². Dem agilen Team gehören von Beginn an Vertreter aller Bereiche in den beschriebenen Rollen an, welche die Prozesslösung gemeinsam gestalten. Das Konzept kann damit sowohl das Business-IT-Alignment verbessern als auch das Enabling durch IT fördern. Ersteres bedeutet, dass der Abdeckungsgrad der Bedürfnisse der Fachabteilungen durch passende IT-Services steigt. Beim Enabling gibt die IT Impulse für die Nutzung von Informations- und Kommunikationstechnik für Geschäftsmodell- und Geschäftsprozessinnovationen.

Wie das Design Thinking sieht der BizDevOps-Ansatz also ein interdisziplinäres Team vor. Herausforderung ist es in solchen Teams, das „Wir“-Denken unter „T-shaped “ Personen zu etablieren. Dies liegt daran, dass Linieneinheiten, denen die Beteiligten entstammen (verschiedene am Prozess beteiligte Fachabteilungen, IT-Entwicklung, IT-Betrieb), unterschiedliche Ziele verfolgen und diesen oft tendenziell höhere Priorität einräumen als einem gemeinschaftlich zu erreichenden Ziel (innovative oder verbesserte Prozesslösung). Hinzu kommt, dass die Kreativität möglicherweise durch Involvierung der fachlichen Domänenexperten behindert wird.

Einerseits kennen Prozessbeteiligte oft Schwachstellen existierender Prozesse und Lösungsvorschläge dafür. Andererseits sind sie eventuell „betriebsblind“ und in der Betrachtung des Problem- und insbesondere des Lösungsraums zu eingeschränkt. Bei der Rekrutierung sollten demnach nicht nur Diversitätsaspekte wie Geschlecht, Alter und kultureller Hintergrund eine Rolle spielen. Vielmehr ist auf eine sinnvolle Balance zwischen Domänenexperten und Teammitgliedern zu achten, die themenfremde fachliche Hintergründe aufweisen und kein ausgeprägtes Eigeninteresse am Aussehen einer Lösung haben.

Die Schwerpunktverschiebung kann man davon abhängig machen, ob das Ziel eher eine Prozessverbesserung ist, bei der Erfahrungen und Inputs der mit dem bestehenden Prozess vertrauten Personen hilfreich sein können. Steht dagegen eine radikalere Prozessinnovation im Vordergrund, könnten diese möglicherweise eher limitierend wirken. Selbstverständlich sollten auch bei der ursprünglichen Zielsetzung der Verbesserung Ideen für eine fundamentale Innovation des betrachteten Prozesses nicht außer Acht gelassen werden.