Von der Betriebsfeier zur ganzheitlichen Prozessoptimierung

Wie leitet man ausführbare Prozessmodelle ab? „Wir modellieren das mal schnell und verfeinern, wo es für die Ausführung nötig ist“ – dieser Ansatz ist weit verbreitet … und scheitert fast immer. Die Ableitung technischer Prozessmodelle braucht daher Methode. Modelle zunehmend zu detaillieren, hilft nicht. Dieser Beitrag zeigt, wie ein Modellierer zunächst zu einem ausführbaren und anschließend zu einem optimierten BPMN-Prozessmodell kommt. Und es geht auch um Nina und die Weihnachtsfeier, auf der sich Tim und Nina kennenlernten.

„Hey! Wir kennen uns noch gar nicht, ich bin Nina. Ich arbeite hier im Vertrieb und betreue unser Portalgeschäft. Wie heißt Du?“, fragt sie. „Ich arbeite … ähm, ich meine: Ich bin Tim“, suchte Tim etwas verlegen nach Worten und sagte schließlich: „Schön, Dich kennenzulernen. Darf ich Dir ein Glas Wein holen?“ „Klar, gerne. Ich warte hier.“ Wenige Momente später ist Tim zurück. „Bitte sehr.“ Tim überreicht das Glas. „Wo waren wir stehen geblieben?“ Nina lächelte und sagte: „Dass Du Tim bist.“ „Oh … ja … Genau, also ich arbeite hier als Workflow-Analyst und betreue die Prozess-Applikationen.“ So in der Art trug es sich wohl zu.

Erste Zeichen

Transparenz in die Abläufe einer Organisation zu bringen, erschien schon immer vorteilhaft, um Durchführende besser anzuleiten und den Verantwortlichen die Steuerung der Prozesse zu erleichtern. So ergab sich diese Transparenz historisch häufig aus Prosa-Beschreibungen, Prozess-Visualisierungen und letztlich aus Modellen. Zur Modellierung gibt es Modellierungssprachen wie die BPMN, die klare Symbolbedeutungen und Verwendungsregeln (Syntax) vorgibt. Mit der 2011 veröffentlichten Version 2.0 sind außerdem noch Ausführungssemantiken dazugekommen. Mit ihnen wurden erstellte Modelle im Kontext einer Prozessautomatisierung ausführbar. Seitdem ist der Erfolg der BPMN ungebrochen.

BPMN ist heute die Lingua franca der Prozessmodellierung.

Eine Ebene tiefer

Häufig wird versucht, Prozessmodelle von ‚grob und abstrakt‘ (strategisch) zu ‚detailliert und konkret‘ (operativ) zu sortieren. Dabei werden immer wieder konzeptionell verschiedene Ebenen kreiert, wobei die oberste Ebene strategische Sichten auf Prozesse beinhaltet; untere Ebenen werden immer weiter verfeinert und detaillierter. Verfällt man dieser Idee, liegt der Gedanke nahe, dass ein ausführbares Modell eine weitere Form der Detaillierung sei – ein Trugschluss.

Ebenen existieren nicht in der Prozessbetrachtung

Macht man sich bewusst, dass IT-Systeme entweder Aktivitäten unterstützen oder einzelne Aufgaben ausführen, ist eigentlich nicht zu erklären, warum diese dafür eine Verfeinerung des Prozessmodells benötigen. Wird der Anwender unterstützt, bietet ein System beispielsweise auf der Bedienungsoberfläche Entscheidungsinformationen, Berechnungsergebnisse oder Ähnliches an. Wird eine Aktivität durch das System durchgeführt, ist die Detaillierung der manuell ausgeführten Aufgabe entsprechend. Mit anderen Worten: Das System macht genau das Gleiche. Warum dann eine Detaillierung? Die Ableitung eines technischen Modells braucht also eine andere Vorgehensweise.

Das eine Ziel

Erst Business IT Alignment …

Um technische, potenziell ausführbare Modelle zu erstellen, stellen wir im Folgenden einen methodischen Ansatz vor, der das Business IT Alignment sicherstellt, also die gemeinsame Ausrichtung fachlicher und technischer Prozesse auf ein gemeinsames Ziel oder Ergebnis.

Das nachfolgende Szenario beschreibt, wie von einem Konzern ein Portalzugang für einen Kunden eingerichtet wird. Hierbei geht es um die Anlage, Legitimation der Person und das Setzen von Berechtigungen.

In einem Gespräch mit den Führungskräften erfährt der oben erwähnte Workflow-Analyst Tim Folgendes: Ein Vertriebsmitarbeiter erkennt den Bedarf für einen Portalzugang für einen Mitarbeiter seines Kunden. Er fordert daraufhin einen Account beim Support an. Hier wird der Account zunächst angelegt; hierfür ist jedoch noch eine Legitimation nötig, auf Basis derer anschließend die benötigten Berechtigungen für bestimmte Funktionen gewährt werden können. Zum Schluss versendet der Vertrieb die Zugangsdaten für das Portal an den Mitarbeiter seines Kunden. Mithilfe des nachfolgenden Modells beschreibt Tim den Prozess zunächst in einer abstrakten Sicht zum Überblick.[/vc_column_text][vc_single_image image=“5287″ img_size=“medium“ add_caption=“yes“ onclick=“link_image“ el_id=“abb1″][vc_column_text]Wir sprechen bewusst von einer Sicht und nicht von einer Ebene, da dieser Ebenen-Begriff übergeordnete und untergeordnete Ebenen suggeriert. Wenn wir von einer Sicht sprechen, dann verstehen wir dies eher wie eine Sicht auf einen Datenwürfel (so wie man es von OLAP-Technologien bei Datenbanken kennt). Sichten auf einen Datenwürfel weisen ebenfalls für den jeweiligen Betrachter die relevanten Informationen (Datenattribute) aus. Genauso ist auch das in der Abbildung 1 gezeigten Prozess-Sicht gemeint. Für den Betrachter, der nur einen Überblick braucht, sind auch nur die dafür relevanten Informationen dargestellt. Diese sind im Wesentlichen Antworten auf die Frage: Wer macht was und was ist das Ergebnis?

Tim ist sich völlig klar darüber, dass ein Prozessausführender – also jemand, der sich mit den Details das Tagesgeschäfts auseinandersetzt – keinen oder kaum Nutzen aus dieser Prozess-Sicht ziehen kann. Um für den Prozessausführenden einen Nutzen zu stiften, ist diese Darstellung schlicht zu wenig konkret. Es benötigt daher eine andere Sicht auf den gleichen Prozess, denn der Prozessausführende hat andere Informationsbedürfnisse, die üblicherweise auch Sonderfälle, Ausnahmen, Kommunikation und andere Details bei der Prozessdurchführung umfassen.

Für unterschiedliche Interessenlagen braucht es unterschiedliche Sichten auf den Prozess – und somit unterschiedliche Modelle.

Die für den Prozessausführenden relevanten Details modelliert Tim mithilfe sogenannter Kollaborationsdiagramme der BPMN, da diese insbesondere den Kommunikationsaspekt und andere Formen der Prozesskopplung beinhalten. Die fehlenden Informationen sammelt er bei den Prozessausführenden.[/vc_column_text][vc_single_image image=“5289″ img_size=“medium“ add_caption=“yes“ onclick=“link_image“ el_class=“abb2″][vc_column_text]In Abbildung 2 sind nun Details erkennbar, die für das Tagesgeschäft der Prozessausführenden relevant sind. Es ist nun ersichtlich, welche Ausführungsvarianten existieren, wann er wen informieren muss etc. Hier wird auch deutlich, dass dieser Prozess in der strategischen Sicht (siehe Abbildung 1) in nur einem (!) Pool dargestellt wurde. Dies war möglich, weil viele für den Informationsempfänger irrelevante Informationen abstrahiert wurden. In Abbildung 2 finden die Prozessbeteiligten nun die für sie relevanten Informationen.[

Modelle und Sichten müssen einen Nutzwert für den Empfängerkreis bieten.

Dieses Mehr an Informationen entspricht jedoch nicht einer weiteren Detaillierung, sondern visualisiert manche Informationen, die in Abbildung 1 nicht visualisiert wurden. Dies lässt sich leicht nachvollziehen, wenn man in ‚Navigation‘ denkt. Häufig wird versucht, vom Groben ins Detail zu navigieren im Sinne eines Hyperlinks. Würde es sich hier um eine Detaillierung handeln, was wäre die Absprungstelle und was die Zielstelle? Hier wird das brüchige Ebenen-Konzept deutlich.

Ein konsistentes Ebenen-Konzept lässt sich nicht sinnvoll umsetzen, wenn die Details wichtig sind.

Diese operative, in Abbildung 2 dargestellte Sicht auf den Prozess kann Tim nun als Grundlage für ein technisch ausführbares Prozessmodell nutzen. In unserem Sinne ist ein ausführbares Modell ebenfalls eine Sicht, die nämlich die Dinge darstellt, die technisch im Prozess ablaufen sollen bzw. relevant für das technische System sind.

Zu diesem Zweck ergänzen wir einen zusätzlichen Pool für das technische System und fügen für jede beteiligte Rolle eine Lane zur Aufgabenzuweisung ein. Die Details dieses Pools lassen sich ableiten:

• Wir wissen aus der Beschreibung heraus, dass der Vertrieb den Portalzugang beantragt. Er startet somit den Prozess, so dass wir also ein Startereignis benötigen.
• Aus der Kollaboration wissen wir, dass als Nächstes der 1st Level Support einen Account anlegen soll. Damit dies geschieht, muss das technische System diese Aufgabe zuweisen. Dies erfolgt in der BPMN mithilfe eines UserTasks „Account anlegen“. UserTasks zeichnen sich dadurch aus, dass sie Oberflächen zur Aufgabenbearbeitung ausliefern. Der Anwender aus dem 1st Level Support dokumentiert jetzt in dieser Oberfläche, ob er entweder den User bereits im UserDirectory gefunden hat oder ob er zur Anlage eines neuen Accounts eine Legitimation anfordern will und dies anschließend im UserDirectory auch tut (ohne zunächst auf eine Legitimierung zu warten). Das Abschließen der Aufgabe resultiert nun in die Berechtigungsvergabe. Wäre eine Legitimation nötig, müsste diese zuerst abgeschlossen sein, bevor die Berechtigungen gesetzt werden.
• Wurde eine Legitimation angefordert, erhält das BackOffice eine Aufgabe, die wiederum über einen UserTask mit dem Auftrag „Legitimierung anfordern“ zugewiesen werden kann. Dieser führt dazu, dass die Unterlagenanforderung gestartet wird. Liegen alle Unterlagen vor, bestätigt das BackOffice den Abschluss des UserTasks über die zugehörige Oberfläche.
• Liegt die Legitimierung vor, kann mittels UserTask dem Berechtigungssupport eine Aufgabe zugewiesen werden: „Berechtigungen vergeben“ lautet der Arbeitsauftrag, der mittels Oberfläche ebenfalls quittiert bzw. bestätigt wird.
• Zuletzt muss der Vertrieb wissen, dass intern nun alle Arbeiten abgeschlossen sind und er nun den Kunden mit den Zugangsdaten informieren kann. Auch hierzu erhält er einen UserTask „Zugangsinformationen senden“, über dessen Oberfläche der Vertrieb das Senden als fertig melden kann.

Wie hier dargestellt, ergibt sich das technische Modell daher als Ableitung der fachlichen Sicht. Wurde die Kollaboration (wie in Abbildung 2) vollständig beschrieben, finden sich darin die Details zur Ableitung des ausführbaren Prozessmodells. So kann ein Business IT Alignment sichergestellt werden. Eine Änderung der fachlichen Prozesse hat nicht stattgefunden.

Im Business IT Alignment gilt: Nicht das System definiert den Prozess, sondern der Prozess definiert die systemische Unterstützung.

In dieser nun abgeleiteten technischen Sicht (eingefärbter Pool in Abbildung 3) werden nun die ersten implementierungsrelevanten Details des Prozesses dargestellt (also die Details, die für eine WorkflowEngine oder eine IT-Applikationen relevant sind). Es wurde nur die Workflow-Steuerung abgeleitet. In der Praxis wird man nun noch mit weitere Aufgabentypen die Systemintegration einbinden können bzw. vielleicht sogar einzelne Benutzeraufgaben durch Schnittstellenintegrationen (Service Tasks) ersetzen können.

Auch hier gilt: Das technische Modell ist keine Verfeinerung oder Detaillierung (und somit keine Detailebene), sondern eine andere Sicht, denn es werden Dinge eingeblendet, die vorher nicht gezeigt wurden.

Technische Modelle beschreiben demnach die Implementierungsdetails, damit eine Mensch-Maschine-Interaktion stattfinden kann. Diese Implementierungsdetails ergeben sich jedoch nicht durch Detaillierung. In der Praxis müssen noch weitere Details hinterlegt werden. Sachverhalte wie fachliche Fehler, Abbrüche, TimeOuts etc. müssen in dieser Sicht noch integriert werden. Dem bereits schon erheblichen Umfang dieses Beitrags geschuldet, kürzen wir an dieser Stelle ab, da es hier um die methodische Vorgehensweise und nicht um die Implementierungsreife geht.

Das Business IT Alignment hat es nun ermöglicht, ein technisch ausführbares BPMN-Modell abzuleiten.

Implementierungsdetails ergeben sich jedoch nicht durch Detaillierung.

Es dann auf ein höheres Niveau bringen

Zunächst ein kleines Szenario (welches offiziell so nie stattgefunden hat):
Wir stellen uns vor, dass auf Basis dieses Prozesses eine entsprechende IT-Lösung umgesetzt wurde und sich das Rollout zum Jahresende bereits zum zweiten Mal jährt. Auf der Weihnachtsfeier erfährt der Workflow-Analyst Tim dann bei einem informellen, intensiven Vier-Augen-Gespräch, dass die Vertriebsmitarbeiterin Nina sehr, sehr unzufrieden mit der Lösung ist. Es dauere einfach alles zu lange und die ständigen Rückfragen der Kollegen verursachen enorme interne Aufwände und verhageln die Kalkulation der Portallösung.

Einige Ansprachen des Managements und einige Gläser Wein später verlassen Nina und Tim die Feier. Die Weihnachtsparty war – wie immer – ein großer Erfolg für das kollegiale Miteinander (am nächsten Morgen leicht zu erkennen an den müden Augen der Teilnehmenden).

Am übernächsten Tag schaffte es auch Tim wieder ins Büro und nach einem ersten starken Kaffee (völlig ohne Milch) erinnert er sich an die sympathische Kollegin aus dem Vertrieb und das gemeinsame Gespräch über die Portalfreischaltung. Nach einem kurzen Telefonat mit Nina ist die Auftragsklärung abgeschlossen: Die Prozesslaufzeit muss verkürzt und die Kosten gesenkt werden. Die beiden verabreden sich zur Zusammenarbeit. Tim freut sich darüber, dass er es ins Büro geschafft hat.

Am nächsten Tag – und diesmal bei Softdrinks – treffen sich die beiden mit dem Softwareentwickler und werfen einen gemeinsamen Blick auf das Prozessmodell, das derzeit im IT-System umgesetzt abläuft:

Bei der Betrachtung des ausgeführten Modells kommen Zweifel auf, ob die hier (in Abbildung 6) dargestellten Informationen ausreichend sind, um eine Prozessbeschleunigung zu konzipieren. Zu viele Informationen, nämlich derjenigen, die die einzelnen Aufgaben ausführen, fehlen an dieser Stelle. Sie entschließen sich, in den Projektunterlagen zu suchen, ob die Beschreibung der fachlichen Prozesse noch auffindbar sind. Sie sind es. Das Modell mit der strategischen Sicht in Abbildung 2 verwerfen sie sofort als Konzeptionsgrundlage. Das damals erstellte Kollaborationsdiagramm ist aber noch vorhanden (siehe Abbildung 4).

Strategische Sichten eignen sich für tiefergehende Prozessanalysen nicht.

Die in Abbildung 4 dargestellte Kollaboration von menschlich ausgeführten und technisch orchestrierten Prozessen erlaubt nun eine übergreifende Prozesstransparenz. Eine erneute Betrachtung macht die Verhältnisse klarer. „Jetzt verstehe ich, warum es manchmal so lange dauert“, grummelt Nina, „das BackOffice ist ja nicht immer besetzt, so dass sowohl das Versenden der Anschreiben sowie die Bearbeitung der eingehenden Unterlagen nicht immer sofort stattfindet.“ Tim ergänzt: „Und auch beim Berechtigungssupport sehe ich Schwierigkeiten. Diese sollen sich ja fehlende Freigaben bei ihrer Führungskraft holen. Meines Wissens ist diese Stelle derzeit aber nur kommissarisch von der Leiterin einer anderen Abteilung besetzt. Ich kann mir schon vorstellen, dass diese Freigabe-E-Mails für sie wahrscheinlich nicht immer die höchste Priorität haben.“

Eine übergreifende Sicht auf fachliche und technische Prozesse bildet die Grundlage für konzeptionelle Optimierungsüberlegungen.

So beginnt ein kleines Brainstorming. Wäre man dabei, könnte man Fragen hören à la: „Warum braucht es eigentlich diese Freigabe der Führungskraft?“ „Warum muss denn der Berechtigungssupport die Berechtigungen eigentlich setzen?“ „Warum verschickt das BackOffice eigentlich postalische Anschreiben?“ „Welche Daten braucht der 1st Level-Support eigentlich, um einen Account anzulegen?“ …

Nach 2 Stunden legt das Brainstorming-Team eine Kaffeepause ein. Auf dem Weg zur Kaffeeküche beschließen sie, die Beteiligten zusammenzurufen und gemeinsam Antworten auf die zahlreichen gesammelten Fragen zu finden. Außerdem formulieren Sie ein Optimierungsziel: „Der legitimierte User soll spätestens binnen 15 Minuten seine Zugangsdaten erhalten, ohne falsche Berechtigungen erhalten zu haben.“ An diesem Ziel wollen sie den Erfolg ihres Workshops messen lassen.

Eine ganzheitliche Optimierung, die sowohl menschlich ausgeführte Prozesse als auch technisch ausgeführte Prozesse umfasst, kann aufgrund der Darstellung in Abbildung 3 und auf Basis des formulierten Optimierungsziels gelingen.

Noch für die gleiche Woche stimmen alle Beteiligten einem gemeinsamen Termin am Freitag zu. Nach ein paar einleitenden Worten zur Problemlage und zum formulierten Optimierungsziel stellen sie das Kollaborationsmodell (Abbildung 3) vor und erläutern die Zusammenhänge. Alle bestätigen, dass dies nach wie vor die derzeitige Vorgehensweise beschreibt.

Und so wird entlang des Modells diskutiert:

Das bessere Modell

„Können wir die Anlage des Users im Benutzerverzeichnis nicht automatisieren?“ „Ja, das System bietet eine entsprechende Schnittstelle.“
„Das Anfordern der Unterlagen muss nicht postalisch erfolgen. Dies ginge auch elektronisch. „Dann können wir sie ja per E-Mail anfordern.“ „Schon, aber die eingehenden Dokumente müssen weiterhin manuell geprüft werden.“
„Was muss für die Berechtigungsfreigabe eigentlich geprüft werden?“ „Wir prüfen nur, ob der Kunde in der EU ansässig ist, da hier rechtliche Erleichterungen möglich sind. Kunden außerhalb der EU bekommen daher keinen Portalzugang.“ „Dann können wir diese Regel ja automatisch prüfen.“
„Wie erteilt die Führungskraft eigentlich die Freigabe?“ „Auf Basis der ihrer aktuellen Kenntnislage in Bezug auf die Verlässlichkeit des Kunden bestätigt sie uns die Freigabe per E-Mail.“ „Diese könnte man ja dann ins System einbinden, dann fällt zumindest die lästige E-Mail weg und wir könnten regelmäßig die Erledigung anmahnen.“

„Welche Berechtigungen setzt ihr eigentlich? Was passiert im Detail?“ „Nun, wir schauen uns an, welche Portalfunktionen der Kunde bestellt hat, und geben dann die dafür benötigten Funktionalitäten über die Nutzerverwaltung frei. Dafür muss natürlich erst der Account durch den 1st Level-Support angelegt sein.“ „Heißt das, dass für jede bestellte Portalfunktion immer die gleichen Berechtigungen zu setzen sind?“ „Ja, in der Tat. Könnte man eigentlich auch automatisch setzen.“

Während diskutiert wird, verschiebt Tim Symbole, ergänzt neue und überarbeitet die Kollaboration. Nach einiger Zeit wirft er diese per Beamer an die Wand.

Prozessoptimierung geht im Team am besten, wenn alle das gleiche Bild im Kopf haben.

Das Modell findet nach einer kurzen Erklärung durch Tim sofort Zustimmung. Vorbehaltlich der technischen Umsetzungsmöglichkeiten bestätigen alle, dass dieser Prozess besser wäre als der derzeitige. Nur Nina ist noch nicht überzeugt. Sie grübelt. Einige Minuten später platzt sie heraus: „Das hat Spaß gemacht. Ich bin begeistert, wie wir das Modell genutzt haben, um Verbesserungen zu entwickeln. Ich glaube, dass wir hier die Bearbeitungsaufwände deutlich reduziert haben. Zahlreiche Aufgaben können so automatisch umgesetzt werden. Dies wird sich sicher in der Kalkulation deutlich niederschlagen.“ Die Teilnehmer des Workshops freuen sich. Der erste klappt bereits sein Notizbuch zu. Dann ergänzt Tim, ohne dass es hierzu einer Absprache zwischen ihm und Nina gab: „Wir haben hier jedoch noch ein Problem. Unsere Änderungen haben sicher dazu geführt, dass die Bearbeitungskosten reduziert wurden. Eine Beschleunigung des Prozesses haben wir aber noch nicht in ausreichendem Maße erreichen können. Hier müssen wir nochmal ran!“

Mittlerweile ist es spät geworden. Tim erklärt den Workshop für beendet und verabschiedet alle ins Wochenende. Alle packen zusammen und verlassen den Workshop-Raum, um nach Hause zu ihren Liebsten zu eilen. Nur Nina bleibt sitzen. „Danke. Ich habe gerade meine Bedenken bezüglich des neuen Prozessdesigns nicht so recht in Worte fassen können, aber Du hast sie dann ausgesprochen. Das war super! Hast Du schon eine Idee, wie wir das Zeitproblem noch lösen können?“ „Nein, aber da fällt mir übers Wochenende bestimmt noch etwas ein. Wollen wir noch ein Glas Wein trinken gehen?“ „Gern.“ Und so beginnt das Wochenende.

Nochmal von vorne beginnen

Es ist doch wieder spät geworden. Leicht verkatert sitzt Tim nun samstagfrüh am Frühstückstisch. „So geht es nicht weiter“, murmelt er vor sich hin. Dann überlegt wer, wie sie das Ziel der Prozessdurchlaufzeit von unter 15 Minuten erreichen können. Denn mit der inkrementellen Weiterentwicklung des aktuellen Prozessablaufs, so vermutet er, werden sie nicht weiterkommen. „Wir brauchen einen neuen Ansatz, einen radikaleren, der uns löst von den alten Mustern.“ Bei diesem Gedanken fällt ihm das Stichwort ‚Process Re-Engineering‘ aus seinem Studium wieder ein. Eine kleine Recherche bringt ihn wieder auf die Spur. Das Ablegen herkömmlicher Denkmuster und das Einschlagen neuer Wege sowie eine Neugestaltung und Neueinordnung des Prozesses ist gefragt.

Tim überlegt nun, wie er es anstellen kann. Es braucht eine Weile, dann hat eine Idee. Er ruft Nina an und erzählt ihr davon.

In der nächsten Woche trifft sich das Workshop-Team erneut. Vor aller Augen schreibt Tim auf das Whiteboard: Der legitimierte User soll spätestens binnen 15 Minuten seine Zugangsdaten erhalten, ohne falsche Berechtigungen erhalten zu haben.

Diesmal leitet Tim dem Workshop anders ein. Er redet anfangs gar nicht von Prozessen, sondern von Ereignissen und davon, wie diese am Customer Touch Point ausgelöst werden. So weckt er ein Verständnis dafür, dass im Kundenlebenszyklus der Kunde einen ersten Vertrag abschließt und über diverse Cross-Selling-Aktivitäten des Vertriebs dann in der Regel Folgeverträge abschließt. Für das Portal heißt es, dass der Kunde immer mehr Funktionen nutzt und im Ergebnis demnach auch immer mehr Berechtigungen benötigt.

Folgende Events hat das Team für das betrachtete Szenario identifiziert:

• Erstvertrag wurde abgeschlossen: gemeint ist hier der Beginn der Geschäftsbeziehung
• (Folge-)Vertrag wurde abgeschlossen: gemeint ist hier der Abschluss weiterer Verträge
• Account wurde (technisch) angelegt: gemeint ist hier, dass für einen Mitarbeiter des Kunden ein persönlicher Account angelegt wurde. Dies kann im Lebenszyklus der Geschäftsbeziehung mehrfach vorkommen.

In Tims Kopf formt sich bereits die Idee eines Prozesses für den Erstvertrag, eine weitere für Folgeverträge sowie für die Legitimation neuer Anwender. Doch bevor er das Modellieren anfängt, will Tim erst nochmal seine Prämissen prüfen. Daher gehen sie auch nochmal die bereits gesammelten Fragen durch. Daraus entsteht wieder eine Reihe von Erkenntnissen:

• Die erwähnte Legitimations-Datenbank stellt sich als Komponente des Portals heraus. Daher entsteht die Idee, dass der Kunde sich im Portal eventuell auch selbst legitimieren könnte.
• Der 1st Level-Support könnte auch einfache Berechtigungen selbst setzen. Es entsteht daher die Idee, dass standardmäßig jeder User die Berechtigung „Legitimation durchführen“ bekommen könnte. Wenn diese abgeschlossen ist, könnten weitere Berechtigungen gesetzt werden.
• Der Berechtigungssupport berichtet, dass das Setzen der Berechtigungen nur deshalb eine Freigabe der Führungskraft benötigt, weil diese eventuell Informationen zur aktuellen Geschäftsbeziehung hat. Da im Fall eines Vertragsabschlusses seitens des Vertriebs eine Bonitätsprüfung erfolgt, ist diese Freigabe eigentlich unnötig und in 99,9% der Fälle erfolgt sowieso eine Freigabe.
• Bei Bekanntwerden von Zahlungsschwierigkeiten ist es viel einfacher, im Sales-System diese Information zu hinterlegen, so dass erst gar keine weitere Bearbeitung erfolgt beziehungsweise dass technisch eine Kundensperre geprüft werden kann.

Basierend auf Kundeninteraktionen und Ereignissen lassen sich passende Prozesszuschnitte finden.

Zu guter Letzt entbrannte eine größere Diskussion über die Arbeit des Vertriebs. Denn Nina erklärte, dass im Verlauf des Kundenlebenszyklus das Portal mit dem Kunden zur Sprache kommt. Und die Vertriebsmitarbeiter dann individuelle Entscheidungen treffen, ob der Kunde einen Portalzugang erhält. Recht schnell wurde hinterfragt, was hierzu die Kriterien seien. Diese konnte Nina nicht klar formulieren. Also wurde vorgeschlagen, jedem Kunden einen Portalzugang gleich zu Beginn der Geschäftsbeziehung zur Verfügung zu stellen. Nina war anfänglich nicht angetan, doch es entstand folgende Idee: Wenn der User früh einen Zugang bekommt, dann kann der Vertrieb später nur noch über Berechtigungen steuern, auf welche Funktionen er zugreifen darf. Zu diesem Zeitpunkt ist der Account aber bereits angelegt und die Legitimation bereits erfolgt. Die Gewährung des Zugriffs kann dann kurzfristig (gegebenenfalls in Abhängigkeit vom Vertrag mit dem Kunden und daher automatisiert) erfolgen.

Tim schaut Nina an, um eine Reaktion zu erkennen … erfolglos. Und so lädt er die Teilnehmer ein, die Leistung des Prozesses anhand des Modells abzuschätzen. Er stellt die Frage: „Erreichen wir mit diesem Modell das Ziel ‚Der legitimierte User soll spätestens binnen 15 Minuten seine Zugangsdaten erhalten, ohne falsche Berechtigungen erhalten zu haben‘?“

Nina beginnt zu lächeln. „Ja, das tun wir! Und mehr noch: Wir binden unseren Kunden ein. Wir verlagern einige Tätigkeiten zu ihnen, sodass sie bei uns wegfallen.“ Mit diesen Worten beendet sie mehr oder weniger das Meeting.

Erkenntnisse

Eine zentrale Erkenntnis ist, dass Betriebsfeiern wichtig sind, um in vertraulichen Gesprächen Verbesserungspotenziale zu besprechen. Die hier vorgestellte IT-Lösung war bereits zwei Jahre im Betrieb, aber die existierenden Unzulänglichkeiten waren Tim unbekannt bis zu dem Abend, an dem Nina davon berichtete. In vino veritas! Die informellen Strukturen und Kommunikationskanäle sind daher nicht zu unterschätzen und sollten daher gepflegt und gefördert werden.

Ferner ist diesem Beispiel zu entnehmen, dass die reine Digitalisierung noch keine Verbesserung bedeutet. Wie Abbildung 3 zeigt, haben sich durch den Einsatz eines technischen Systems noch keine Änderungen an den Abläufen und den damit verbundenen Aufwänden ergeben. Erst die übergreifende Betrachtung von technischen und fachlichen Prozessen schafft nun das Potenzial, wirkliche Verbesserungen umsetzen zu können. Der große Vorteil, der hier durch die BPMN entsteht, ist die sich ergebende Transparenz. Techniker wie Nicht-Techniker haben hier eine gemeinsame Sprache und somit eine gemeinsame Grundlage. Diese Grundlagen kann nun genutzt werden, um im Team über Prozessverbesserungen nachzudenken. Grundsätzlich ist auf dieser Basis eine sukzessive Prozessverbesserung leicht zu bewerkstelligen.

Ferner wurde im aufgezeigten Beispiel deutlich, dass eine hohe Qualität von Stammdaten kritisch ist. Wenn der Vertrieb saubere Daten im SalesSystem vorhält, können darauf basierend automatische Entscheidungen und Auswertungen getroffen werden. Sprießen hier Kraut und Rüben, sind weitere Automatisierungen auf Stammdatenbasis unmöglich.

Die vorgestellte Vorgehensweise des Business IT Alignment stellt sicher, dass man sich primär mit den geschäftlichen, prozessualen Vorgaben beschäftigt. Diese zu verstehen, sind notwendige Voraussetzung für jedes Vorgehen.
Wenn das avisierte Ziel über diese Vorgehensweise nicht zu erreichen ist, sind radikalere Ansätze nötig. Process Re-Engineering, also das Neudenken von Prozessen unter Berücksichtigung von Events und Customer Touch Points, ermöglicht neue Lösungsansätze.

Bemerkenswert ist außerdem, welche Veränderung in der Wahrnehmung stattfindet, denn es ergibt sich eine andere Rolle der IT. Sie wurde im Laufe der Zusammenarbeit durch Nina nicht mehr als CostCenter wahrgenommen. Durch gemeinsames Arbeiten im Team – zusammen mit den Software-Entwicklern – können Technologien in der Ablauforganisation berücksichtigt werden. IT hat hier nicht mehr die Rolle eines Erfüllungsgehilfen, sondern agierte als Arbeitsmitgestalter. In der Wahrnehmung verändert sich IT vom CostCenter zum ProfitCenter (wenn man die Ersparnisse monetarisieren würde).

Es stellt sich sicher auch die Frage: Hätte man gleich mit dem Re-Engineering anfangen können? Es mag den Eindruck erwecken, aber: Nein, man braucht die Details. Die Vorgehensweise über die Ableitung der Workflows aus den fachlichen Prozessen und der nachfolgenden übergreifenden Optimierung hat die Details der inhaltlichen Arbeit offengelegt.

Bezüglich Ninas Aussage „Es dauere einfach alles zu lange und die ständigen Rückfragen der Kollegen verursachen enorme interne Aufwände und verhageln die Kalkulation der Portallösung” lässt sich noch folgende Erkenntnis formulieren: Frauen haben fast immer Recht!