You are on page 1of 112

DSAG-Leitfaden

Business Process Management


Deutschsprachige SAP-Anwendergruppe e.V.
DSAG-Arbeitskreis bpm
Stand 30. August 2013
2

Leitfaden Business Process Management


DSAG-Arbeitskreis BPM

Version 1.0
Stand 30. August 2013

DSAG e. V.
Deutschsprachige SAP-Anwendergruppe
3

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Autoren

­> Joost Fastenrath, B.Braun Melsungen AG ­> Stefan Brauneis, HLP


­ Michael Goldschmidt, BASF SE
> Informationsmanagement GmbH
­ Holger Himmelmann, cbs Corporate Business
> ­> Mirko Heger, HLP
Solutions Unternehmensberatung GmbH Informationsmanagement GmbH
­> Christian Deist, CDI Concepts Development ­> Martin Nussbaumer, IB Solution
Integration AG ­> Ralf Wilhelm, MID GmbH
­> Harald Walter, CENIT AG ­> Christian Ofner, PricewaterhouseCoopers AG
­> Detlef Ohm, Comgroup GmbH ­> Corinne Reisert, SAP AG
­> Winfried Winterstein, CSC Deutschland ­> Joséphe Blondaut, Software AG
Solutions GmbH ­> Susanne Grohmann, Software AG
­> Gerhard Haupt, Heidelberger ­> Marc Vietor, Software AG
Druckmaschinen AG

© Copyright 2013 DSAG e.V.

HINWEIS:
Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit
nicht ausdrücklich anders gekennzeichnet, bei:

DEUTSCHSPRACHIGE SAP® ANWENDERGRUPPE E.V.


Altrottstraße 34 a
69190 Walldorf
Deutschland

Tel.: 06227 - 35809 58


Fax: 06227 - 35809 59
E-Mail: info@dsag.de
Internet: www.dsag.de

Jedwede unerlaubte Verwendung ist nicht gestattet. Dies gilt insbesondere für die Vervielfältigung,
Bearbeitung, Verbreitung, Übersetzung oder die Verwendung in elektronischen Systemen / digitalen
Medien.
4
Überblick
Der Leitfaden Business Process Management des DSAG-Arbeitskreises BPM ist eine Ergänzung
einschlägiger wissenschaftlicher und theoretischer Abhandlungen zum Thema BPM. Er entstand
aus dem Bedürfnis heraus, die Lücke zwischen Theorie und Praxis zu überbrücken und praktisch
nutzbare Hinweise für die Umsetzung eines BPM zu geben.

Erstellt von Praktikern für Praktiker beleuchtet er Aufgabenstellungen und bietet Vorschläge
zu Herangehensweisen und möglichen Umsetzungen. Ergänzend finden sich Tipps aus der
Erfahrungswelt der Autoren und sachdienliche Hinweise zu möglichen „Fallstricken“ vor dem
Hintergrund realisierter Projekte in unterschiedlichen Unternehmen.

1. Einleitung und Strategie


Was ist BPM und warum es sich lohnt, sich damit zu beschäftigen

2. Ziele, Organisation, Aufsetzen eines BPM im Unternehmen beleuchtet


Hintergründe und Beispiele von Z bis A

3. Vom Unternehmensziel zu Prozessdesign, Prozessmodellierung und Prozessmethodik


Welche Vorgehensweise passt zur Aufgabe

4. Prozessanalyse und Prozessoptimierung


Warum, wie, womit und wann

5. Prozesshierarchien und Testmanagement


Die verschiedenen Wege zum Erfolg

6. BPMS – Prozessautomatisierung
Prozesse fest im Griff

Dieser Leitfaden ist ein evolutionäres, lebendiges Werk, das in einer sich laufend ändernden
Geschäftswelt keinen Anspruch auf Vollständigkeit erhebt. Die Leser sind herzlich eingeladen
und aufgefordert, mit eigenen Erfahrungen und Beiträgen die Weiterentwicklung des Leitfadens
zu unterstützen. Anregungen und Ergänzungen sind jederzeit hochwillkommen.

DSAG-Arbeitskreis BPM
5
Inhaltsverzeichnis

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Überblick 4
1 Einleitung, Strategie 8
1.1 Einleitung 8
1.2 BPM-Lebenszyklus 8
1.2.1 Geschäftsziele, Geschäftsmodell, Geschäftserfolg 9
1.2.2 Prozess-Governance und Prozessverantwortung 10
1.2.3 Design und Modellierung 10
1.2.4 Implementierung 10
1.2.5 Ausführung und Monitoring 11
1.2.6 Analyse und Optimierung 11
1.2.7 Prozessanforderung 11
1.2.8 Organisation/Menschen/Technologie 11
1.3 Darstellung verschiedener Ausgangssituationen für BPM-Initiativen 12
1.4 Beschreibung der Perspektiven/Blickrichtungen auf BPM 13
1.5 Darstellung der verschiedenen Zielgruppen für BPM-Initiativen 16
1.5.1 BPM als Disziplin (BPMA) 16
1.5.2 Technisches BPM (BPMS) 17
1.6 BPM-Strategie 18
1.7 „Darstellung des Nutzens von BPM, um personelle und finanzielle
Ressourcen für den Aufbau im Unternehmen zu bekommen“ 19

2 Ziele, Organisation, Aufsetzen eines BPM im Unternehmen 22


2.1 Verbindung von BPM zu den Unternehmenszielen 22
2.2 Organisationsformen für eine BPM-Organisation im Unternehmen 23
2.2.1 Beispiele für BPM-Umsetzungen bei deutschen Unternehmen 25
2.2.1.1 Umsetzung Software-Hersteller (SAP AG) 25
2.2.1.2 Umsetzung Fashion-Unternehmen 26
2.2.1.3 Umsetzung weiteres DAX-Unternehmen 26
2.3 BPM-Reifegrade 27

3 Vom Unternehmensziel zum Prozessdesign 32


3.1 Einführung 32
3.2 Wie kommt man zu einem zielkonformen Prozess? 33
3.3 Wie werden Prozesse strukturiert? 37
3.4 Wie werden Prozesse dargestellt und welche Informationen beinhalten diese? 44
3.5 Prozessverwaltung: Wie und wo werden Prozesse verwaltet? 47
3.6 Exkurs: BPMA-Toolauswahl 51
6
Inhaltsverzeichnis
4 Prozessanalyse und Prozessoptimierung 54
4.1 Einführung 54
4.1.1 Motivation für Prozessanalyse 54
4.1.2 Anteil der Prozessanalyse und -optimierung an den verschiedenen
Phasen des Lebenszyklus 54
4.2 Messgrößen und Indikatoren 56
4.2.1 Performance-Indikatoren 57
4.2.2 Anwendung von betriebswirtschaftlichen Messindikatoren 59
4.2.3 Anwendung von technischen Messindikatoren 60
4.2.4 Anwendung von Messindikatoren für Stammdaten 61
4.3 Prozessanalyse 61
4.3.1 Einordnung der Prozessanalyse 62
4.3.2 Methode 63
4.3.3 Prozessanalyse bei suitebasierten Prozessen 63
4.3.4 Prozessanalytik bei SAP NetWeaver BPM-Prozessen 67
4.4 Prozessoptimierung 69
4.4.1 Reaktive Prozessoptimierung 69
4.4.2 Proaktive Prozessoptimierung 70
4.4.3 Internes Marketing von Prozessoptimierungsprojekten 70

5 Prozesshierarchien und Testmanagement 72


5.1 Einleitung 72
5.2 Testarten 73
5.3 Organisation des Testmanagements 74
5.4 Testdesign 75
5.5 Übergabe der Prozesse zum Test 81
5.6 Testausführung – Nutzung von Testsequenzen 81

6 BPMS – Prozessautomatisierung 84
6.1 Einleitung 84
6.2 Architektur und Aufbau von SAP NetWeaver Process Orchestration 86
6.2.1 SAP NetWeaver Development Studio (NWDS)
– Process Composer – Die Entwicklungsumgebung 87
6.2.2 SAP NetWeaver Business Process Management (BPM)
– Process Server: Die Workflow-Laufzeitumgebung 88
6.2.3 Optional: SAP NetWeaver Development Infrastructure (DI)
– Die Sourcecode-Verwaltung, Build- und Transport-Infrastruktur 88
7

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
6.2.4 SAP NetWeaver Portal 88
6.2.5 BPM Inbox oder Universal Worklist 88
6.2.6 Optional: Process Integration 88
6.2.7 Optional: Enterprise Services Repository 89
6.3 Installationsoptionen für SAP NetWeaver Process Orchestration 89
6.4 Einführungsansatz für eine Workflow-Anwendung auf Basis NetWeaver BPM 91
6.4.1 Mockups 92
6.4.2 Projektvorgehensweise 92
6.4.3 Verwendung von Geschäftsregeln durch den Einsatz eines
Business-Rules-Managementsystems (BRMS) 93
6.4.3.1 SAP-Portfolio 93
6.4.3.2 Anwendungsszenarien 94
6.5 Handlungsempfehlungen für die Implementierung 95
6.5.1 Prozesserhebung 95
6.5.2 Prozessmodellierung 95
6.5.3 User Interfaces 96
6.5.4 Integration von Geschäftsregeln 96
6.5.5 Bearbeiterfindung, Organisationsmanagement 97
6.5.6 Prozessübergreifende Funktionalitäten 97
6.5.7 Portal 98
6.5.8 Alternativen zum zentralen Arbeitsvorat (UWL) 100
6.5.8.1 BPM-Inbox 100
6.5.8.2 Entwicklung eigener Worklists 101
6.5.9 Testmanagement 101
6.5.10 Monitoring, Reporting 102

7 Anhang 104
7.1 Glossar 104
7.2 Quellen 109
7.3 Abbildungsverzeichnis 109
7.4 Autorenverzeichnis 110
8
1 einleitung, Strategie

1.1 Einleitung

„Beim Business Process Management (BPM) handelt es sich im Wesentlichen um eine bestimmte
Art von Unternehmensmanagement, bei der der Schwerpunkt darauf liegt, Geschäftsprozesse zu
definieren, detailliert zu beschreiben, mit entsprechenden Metriken zu überwachen und dann das
zusätzliche Wissen zu nutzen, um die Unternehmensleistung zu optimieren.“
(Quelle: BPM-Technologie im systematischen Überblick, White Paper, SAP und Accenture, März 2009)

Dabei handelt es sich jedoch nicht nur um eine reine „Zeichenkunst“, sondern um Methoden
und deren unterstützende Werkzeuge, die die Verwirklichung der Vision und Ziele einer
Organisation unterstützt. Die eigentliche Kunst besteht darin, die Felder zu identifizieren, in
denen mit Prozessmanagement der wirtschaftliche Erfolg des Unternehmens nachhaltig
unterstützt werden kann.

Die Risiken einer Fehlinvestition lauern häufig im Detail und können durch eine strukturierte
Herangehensweise minimiert werden. So kann durch eine gezielte Ausrichtung und frühzeitige
Klärung zentraler Fragen einer Fehlentwicklung vorgebeugt werden:

>> Was soll mit BPM erreicht werden?


>> Welcher Zweck wird damit verfolgt?
>> Auf welcher Ebene werden die Modelle benötigt?
>> Wer muss eingebunden werden?

Abhängig von der strategischen Zielsetzung werden sich die Ansätze unterscheiden. So erfordert
die Fragestellung einer Automatisierung von Abläufen einen anderen Ansatz als die Fragestellung
zur besseren Ausrichtung von Serviceprozessen. Unabhängig davon hängt der langfristige Erfolg
von einem durchdachten Gesamtkonzept ab.

Unter Berücksichtigung der Geschäftsziele, des Geschäftserfolgs und des Geschäftsmodells


müssen sowohl die Organisation als auch die darin eingerichteten Prozesse sich wirtschaftlich
positionieren. Im Zentrum steht immer die Organisation selbst, die Menschen, die in ihr tätig
sind, und die eingesetzte Technologie.

1.2 BPM-Lebenszyklus

Organisationen und die darin eingerichteten Prozesse sind auf die erfolgreiche Erreichung von
Geschäftszielen ausgerichtet. Dabei agieren die Organisationen in einem Spannungsfeld, das
durch Anforderungen des Gesetzgebers, des Marktes sowie der Mitarbeiter und Investoren
geprägt ist.Prozesse dienen dazu, diese Geschäftsziele in diesem Spannungsfeld umzusetzen.
Hieraus resultieren Anforderungen an die Prozesse. Diese müssen angemessen konzipiert,
modelliert und in der Organisation implementiert werden.

Durch sich verändernde externe Prämissen (Marktumfeld, regulatorisches Umfeld) als auch
interne Rahmenbedingungen (Technologie, Mitarbeiter etc.) ist eine regelmäßige Anpassung bzw.
Justierung der Prozesse erforderlich. Dies zeitnah zu erkennen, macht ein kontinuierliches
Monitoring sowie eine Analyse und Optimierung der Prozesse notwendig. BPM stellt die Werkzeuge
zur Verfügung, um Prozesse in ihrem Lebenszyklus kontinuierlich auf die Geschäftsziele auszu-
richten und zu verbessern, um damit den Geschäftserfolg zu steigern.
9

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Geschäftsziele

sgovernance
Prozes
Prozessanforderung

ng
ieru Des
ign
t im &
Op e
ss

M
&

od
e
se
oz

e ll
Pr
ly
bte

ieru
Ana

Organisation
gele

g n
Menschen
Ausfü

Technologien
hr u

l
odel
Gesc

ng
ng

ru
&

sm
on t
ie

en
häf

ito
rin lem ft
Imp
tse


g
sc
rfo

Ge
lg

Proz g
essverantwortun
(1) Prozesslebenszyklus
(Quelle: © SAP AG, 2012)

Daraus resultiert eine beständige Verbesserung in Form des obigen Kreislaufs. Es gibt in dieser
Darstellungsform kein Ende, da durch den Wandel von Menschen und Technologien davon
ausgegangen werden muss, dass immer nur ein temporäres Optimum zu erreichen ist. Das
Auslaufen (die endgültige Beendigung) von Prozessen ist nicht explizit dargestellt, sollte aber
dennoch als mögliches Szenario berücksichtigt werden.

Aufgrund der zentralen Bedeutung soll hier zunächst ein einheitliches Verständnis bzgl. der Inhalte
und Rahmenbedingungen dieses Kreislaufs hergestellt werden.

1.2.1 Geschäftsziele, Geschäftsmodell, Geschäftserfolg

Der Rahmen für ein BPM ergibt sich aus den Geschäftszielen, dem Geschäftsmodell sowie dem
angestrebten Geschäftserfolg.

Für ein erfolgreiches BPM müssen die Ziele des BPM auf die Ziele der Unternehmung ausgerichtet
sein. Das BPM sowie die Prozesse selbst sind dabei auf das Geschäftsmodell ausgerichtet. In
Letzterem wird beschrieben, wie die Ziele im Grunde erreicht werden sollen, was einen wesent-
lichen Aspekt für das BPM darstellt.

BPM soll dabei unterstützen, den Geschäftserfolg zu steigern. Abhängig von der Definition der
Geschäftsziele sowie des Geschäftserfolgs gilt es, die Ziele und Messgrößen für ein BPM
festzulegen.
10
1 einleitung, Strategie

1.2.2 Prozess-Governance und Prozessverantwortung

Unter Prozess-Governance werden die durch ein Unternehmen zu definierenden Rahmenbe-


dingungen verstanden, mit denen Prozesse im BPM bearbeitet werden. In der Governance
werden also die Regeln für die Anwendung im BPM definiert. Hierzu zählen u.a. die Definition
der Methoden und Werkzeuge, die Steuerungsinstrumente sowie die Detailtiefe der Darstellung
und der organisatorischen Struktur im BPM.

Über die Prozessverantwortung wird definiert, welche Organisation für eine an den Unter-
nehmenszielen ausgerichtete, optimale Prozessdurchführung verantwortlich ist.

1.2.3 Design und Modellierung

Die erste Phase im BPM-Lebenszyklus beschäftigt sich mit der Modellierung der Prozesse. In
der Regel gibt es in jedem Unternehmen eine Anzahl von Engpässen innerhalb der operativen
Abläufe. Genau an diesen Stellen setzt das BPM an. Es zeigt eine neue Perspektive auf, indem
der betroffene Prozess ganzheitlich betrachtet wird.

Es werden Lösungsansätze konzipiert und Kennzahlen definiert, die eine Überprüfung der Nach-
haltigkeit erlauben. Wie zuvor bereits erwähnt, ist es für das BPM von zentraler Bedeutung, stets
nachweisen zu können, wie sich der Beitrag zum Geschäftserfolg darstellt.

Auf Basis der Kennzahlen und der zu erwartenden Effekte werden dann jene BPM-Aktivitäten
ausgewählt, die implementiert werden sollen.

Ergebnis:
>> Soll-Prozessmodell
>> Betroffene Organisation
>> KPI/PPI definiert
>> Nutzen-/Kostenanalyse dokumentiert und Realisierung entschieden

1.2.4 Implementierung

Nachdem die relevanten Prozesse modelliert sind, geht es im nächsten Schritt darum, die
Implementierung vorzunehmen. Wichtig ist dabei, von Beginn an Messungen vorzusehen
(siehe auch Kapitel 4). Hierdurch wird eine sofortige Steuerung ermöglicht.

Die Einführung ist durch das Management zu begleiten. Die Mitarbeiter müssen informiert und
für Schulungen freigestellt werden. Ferner sind die neuen Prozesse bzw. die Prozessänderungen
intensiv zu testen, um negative Auswirkungen im operativen Umfeld zu vermeiden.

Ergebnis:
>> Prozessmodell publiziert
>> Realisierung freigegeben
>> Prozess implementiert
>> Kosten abgerechnet
11

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
1.2.5 Ausführung und Monitoring

Im operativen Geschäftsbetrieb gilt es, die Qualität und Nachhaltigkeit des Prozesses sicherzu-
stellen. Die hierfür eingerichteten Performance-Indikatoren (KPI und PPI) müssen beständig
ausgewertet werden und ermöglichen es, im Prozess auf Veränderungen zu reagieren.

Ergebnis:
>> Prozess in Nutzung
>> Prozess wird verantwortet
>> Prozess wird gemessen und gesteuert

1.2.6 Analyse und Optimierung

In der Analysephase werden die Prozesse anhand definierter Kennzahlen (KPI und PPI) bewertet
und Abweichungen untersucht. Dabei wird beurteilt, inwiefern die implementierten Prozesse an-
gemessen auf die Ziele ausgerichtet sind und wo Handlungsbedarf besteht. Treten Abweichungen
wiederholt auf, so ist zu untersuchen, ob Maßnahmen erforderlich sind, um diese Abweichungen
zu beheben. Die Überwachung der Prozesse ist die Basis für einen kontinuierlichen Verbesserungs-
prozess. Es ist stets darauf zu achten, dass die Prozesse den geforderten Beitrag zur Erreichung
der Unternehmensziele leisten. Hieraus sind Optimierungspotenziale abzuleiten, die in der
Design- und Modellierungsphase im Detail geprüft und konzipiert werden.

Ergebnis:
>> Ist-Prozessmodell
>> Prozessverantwortung
>> Prozessziele haben Messindikatoren
(KPI, Key Performance Indicator und PPI, Process Performance Indicator)
>> Kontinuierlicher Verbesserungsprozess

1.2.7 Prozessanforderung

Eine Änderung am existierenden Prozessmodell kann sich auch durch externe Einflussgrößen wie
Gesetzesänderungen, Änderung der Unternehmensziele oder durch ein verändertes Nachfrage-
verhalten der Kunden ergeben. Unternehmensübernahmen bzw. Unternehmensaufspaltungen
können ebenfalls Ausgangspunkte für neue Anforderungen sein. Jeder Prozess unterliegt somit
neben den prozessinhärenten Impulsen aus dem Monitoring und der Analyse zusätzlich Impulsen
von außen, die eine Veränderung bedingen.

1.2.8 Organisation/Menschen/Technologie

Prozesse bilden den Zweck der Organisation ab, hängen jedoch auch stark von der Organisation
des sie betreibenden Unternehmens ab. Dabei ist der Prozess sowie dessen Qualität sowohl von
den agierenden Personen als auch den eingesetzten Technologien abhängig. Der ständige Wandel
der Organisation, der Mitarbeiter oder der eingesetzten Technologie bedingt auch eine Weiterent-
wicklung der Prozesse sowie des BPM. Aus diesem Grund wird zu keinem Zeitpunkt ein dauer-
haftes Optimum erreicht. Die kontinuierliche Weiterentwicklung wird stets dafür sorgen, dass es
neue Optimierungspotenziale geben wird.
12
1 einleitung, Strategie

1.3 Darstellung verschiedener Ausgangssituationen


für BPM-Initiativen

Jedes Unternehmen und jede Person, die sich dem Thema BPM nähert, muss sich die Frage
stellen: Was möchte ich erreichen und warum bin ich der Meinung, dass uns ein BPM helfen kann?
Solange diese Frage nicht beantwortet werden kann, ist es sehr schwer, eine BPM-Initiative
erfolgreich zu etablieren. Da in jedem Unternehmen eine andere Ausgangslage zu finden sein wird,
muss jedes Unternehmen sich auch individuell dieser Fragestellung annehmen. Eine allgemein-
gültige Empfehlung gibt es nicht, jedoch sollen die folgenden Punkte helfen, eine Orientierung zu
finden.

Organisationen sind verschiedenen Einflüssen ausgesetzt. Sowohl ein sich veränderndes Markt-
umfeld als auch regulatorische Änderungen erfordern, dass sich das Unternehmen und auch die
Mitarbeiter schnell darauf einstellen. Trotz kürzerer Intervalle für erforderliche Veränderungen
sinkt tendenziell die Toleranz für Lücken in der Prozesskette sowie für Fehler im Prozess.
Beispiele, in denen die Kunden Prozessketten und Zielgrößen für den Prozess vorgeben, finden
sich bereits in einigen Branchen.

Nachfolgend sind Beispiele für verschiedene Ausgangssituationen und Beweggründe skizziert:

Reorganisation:
Das Unternehmen muss sich organisatorisch neu aufstellen. Im Zuge der Zusammenführung von
Unternehmensteilen und/oder Akquisitionen besteht der Bedarf, Prozesse zu harmonisieren, zu
verbessern und die Mitarbeiter hinsichtlich der neuen Strukturen zu schulen. Mittels eines
Prozessmanagements sollen die Grundlagen (Prozessmodelle) erstellt und weiterentwickelt
werden, die für die Prozessanalyse und -verbesserung als Ausgangsbasis dienen. Ergänzend
werden Prozesskennzahlen eingerichtet, an denen der Erfolg der Prozesse (Qualität, Zeit etc.)
gemessen und Handlungsfelder identifiziert werden.

Motivation für die Reorganisation durch die Geschäftsleitung ist häufig das Ziel, ein vorhandenes
Silo-Denken zu durchbrechen. Über die Jahre hinweg haben sich häufig die am Prozess beteiligten
Unternehmensbereiche in die Tiefe optimiert. Hierbei wurden Schnittstellen oft als gegeben
angenommen und nicht mit optimiert. Jedoch weisen gerade diese Schnittstellen oft erhebliche
Verbesserungspotenziale auf. Über einen ganzheitlichen Prozessansatz kann dieses Potenzial
transparent gemacht werden.

Compliance:
Es besteht die Anforderung, verschiedene Prozessdokumentationen zusammenzuführen, um
Mehrfachpflege zu vermeiden. Hierunter fallen beispielsweise Prozess- und Systemdokumentati-
onen der IT, Ablaufdiagramme der Organisationsabteilung sowie Prozessbeschreibungen der
kaufmännischen Abteilungen für das Bilanzrechtsmodernisierungsgesetzt (BilMOG) oder den
Sarbanes Oxley Act (SOX).

Effizienzsteigerung:
Unabhängig von einer erforderlichen Reorganisation besteht in Unternehmen der Bedarf, ein-
gerichtete Abläufe an neue Gegebenheiten anzupassen und die Effizienz in der Prozessbearbeitung
zu steigern. Dabei geht es primär darum, Kosten zu reduzieren bzw. bestehende Abläufe für die
13

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Bearbeitung einer größeren Anzahl an Vorfällen zu ertüchtigen. Dies wird meist über die Einrich-
tung von Prozessstandards und die Harmonisierung von Prozessen, ggf. in Verbindung mit der
Einführung/Harmonisierung von IT-Systemen, unterstützt. Die Grundlage für eine erfolgreiche
Umsetzung ist dabei ein transparentes Bild der Abläufe und Anforderungen.

Arbeitsplatzbezogener Bedarf:
Es finden sich auch Ansätze, die individuell auf Mitarbeiterebene umgesetzt werden. Der
Sachbearbeiter, der die Abläufe für seinen Arbeitsplatz kurz zusammenstellt, um diese neuen
Kollegen zu vermitteln. Der IT-affine Mitarbeiter, der einen Workflow in webbasierten Anwen-
dungen programmiert, um kleine Abläufe besser monitoren zu können.

Technische Möglichkeit:
Die Motivation für ein technisches BPM liegt häufig in der Ablösung papierbasierter, manueller
Abläufe durch elektronisch unterstützte Abläufe (Workflows). Hierdurch kann u.a. eine höhere
Prozessstabilität erreicht werden, da ein Workflow meist nicht so leicht geändert oder umgangen
werden kann.

1.4 Beschreibung der Perspektiven/Blickrichtungen


auf BPM

Abhängig vom Verständnis und der Zielsetzung einer Organisation für BPM kann sich dessen
Ausprägung unterscheiden. Es ist somit zunächst die Frage zu klären, aus welcher Perspektive das
Thema BPM betrachtet wird. Ein Prozess besitzt unterschiedliche Hierarchieebenen, wobei jede
Ebene einen unterschiedlichen Detaillierungsgrad darstellt. Abhängig von der Detaillierungsebene
kann es unterschiedliche Verantwortlichkeiten geben, die in einer Hierarchie von Prozessverant-
wortlichkeiten für den Prozess münden.

Beispiel einer Prozess-Hierarchie:


L1
Prozess-Bereich

L2
e2e-Prozesse

L3
Prozess

L4
Prozessvariante

L5
Prozessschritt

L6
Aufgabenbeschreibung/Dokumentation

(2) Prozesspyramide (Quelle: B.Braun Melsungen AG, 2011)


14
1 einleitung, Strategie

Neben der Detaillierungstiefe kann es noch zu verschiedenen Blickrichtungen auf das Prozess-
management bzw. die Prozesse – abhängig von der damit verbundenen Zielsetzung – kommen.

Folgende Gruppen haben typischerweise eine eigene Perspektive auf das Thema BPM:
>> Geschäftsleitung/Business-Unit-Leitung (Geschäftssteuerung)
>> Lieferketten (Warenstromoptimierung)
>> Mitarbeiter (Schulung, Kultur)
>> IT (System/Verfahrensbeschreibung, Testgrundlage, Zusammenarbeit Fachbereich,
Automatisierung und Support)
>> Qualitätssicherung/Compliance (Dokumentation, Nachweisführung, KVP)
>> Kunde (intern oder extern)/Ergebnisempfänger

Dabei kommt es zwangsläufig zu unterschiedlichen Ansätzen, wie ein Prozessmanagement


aufgesetzt, organisatorisch angesiedelt und gesteuert wird.

Am Anfang sollte deshalb eine Standortbestimmung stattfinden. Es ist zu klären, mit welcher
Zielsetzung ein Prozessmanagement eingerichtet werden soll und aus welcher Perspektive und
somit auch auf welcher Ebene das Thema BPM aktuell betrachtet wird. Beispielsweise hat die
Geschäftsleitung in der Regel einen anderen Blickwinkel auf das Thema als die IT-Abteilung.
Es wird in jedem Unternehmen Aktivitäten geben, die eine Top-down-Perspektive haben, und
andere, die einen Bottom-up-Blickwinkel besitzen. Diese beiden Sichtweisen haben
erhebliche Auswirkungen auf den BPM-Ansatz (siehe Kapitel 1.5).

Hier sei angemerkt, dass ein ganzheitlicher technischer Einsatz von BPM nur möglich ist, wenn
es auf den Grundlagen eines BPM als Disziplin aufbauen kann. Es besteht hier also eine direkte,
einseitige Abhängigkeit. Nur ein vollständig beschriebener Prozess lässt sich auch mit technischer
Hilfe umsetzen. Hingegen kann BPM als Disziplin durchaus ohne technische Abbildung von
Prozessschritten genutzt werden.

Geschäftsleitung:
Die Geschäftsleitung oder Bereichsleitung sieht in BPM oftmals ein Werkzeug, um einen Überblick
über die Abläufe zu erhalten. Der Gesamtzusammenhang soll dargestellt und gesteuert werden
können. Ferner können so die relevanten Funktionen und Verantwortlichkeiten bestimmt werden.
Dabei geht es insbesondere darum, die richtigen Anreize und Strukturen aufzubauen, um über die
Prozesse die Ziele der Organisation umzusetzen. Die Prozessdarstellung liegt hierfür schwer-
punktmäßig auf den Ebenen 1 und 2 aus obiger Darstellung. Diese gehen einher mit organisato-
rischen Strukturen, einem Monitoring der Umsetzung bzw. Zielerreichung sowie einem darauf
ausgerichteten Anreizsystem.

Lieferketten:
In verschiedenen Branchen mit großer Vernetzung über die Lieferketten hinweg, erhalten Tier-
1-Lieferanten häufig stringente Vorgaben hinsichtlich der Ziele und Gestaltung von einzelnen
Prozessen. Diese werden z.T. über Lieferanten-Audits, Vorgaben spezifischer Zertifizierungen etc.
überprüft. Ein analoges Vorgehen lässt sich auch in Unternehmen mit hoher Fertigungstiefe
finden.
15

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Bei der Gestaltung der Prozesse in den vorgelagerten Stufen der Lieferkette kommt ein BPM
als Disziplin zum Einsatz. Oft kommt in diesen Anwendungsfällen aber auch eine technische
Anbindung hinzu, bei der Planungsdaten, Bestandsinformationen und Auftragsdaten elektronisch
übermittelt werden. Somit wird hier BPM als Disziplin durch ein technisches BPM unterstützt.

Mitarbeiter:
In der Regel nähert sich ein Mitarbeiter dem Thema BPM über ein konkretes Problem. In seinem
Aufgabenbereich funktioniert ein Ablauf nicht wie gewünscht oder verursacht einen erheblichen
Mehraufwand.

Hierdurch hat der Mitarbeiter aus der Problemlösungsperspektive eine Motivation, sich intensiver
mit den dahinterliegenden Abläufen zu beschäftigen. Für die Einführung von BPM gilt es dabei, die
Fragen zu klären, wie viel Information benötigt der Mitarbeiter (Schulung, Verständnis) und wie viel
Information ist durch den Mitarbeiter dauerhaft zu pflegen (z.B. Aktualisierung von Dokumenten).

IT-Abteilung:
Bei der IT laufen oftmals die Anforderungen bzgl. elektronischer Abbildungen von Prozessen
zusammen. Insofern steht die IT in der Regel als erste Instanz im Unternehmen vor der Heraus-
forderung, Standards bzgl. der technischen Darstellung zu etablieren.

Oftmals sind die eingesetzten ERP-Systeme, etwa SAP ECC, historisch gewachsen. Nach und nach
wurden neue Prozesse und neue Standorte integriert. Die Komplexität stieg zunehmend. Diese
schleichende Komplexitätssteigerung stellt für die IT-Abteilung ein immer größeres Problem dar.
Welche Auswirkung hat eine Änderung? Oftmals wird personenbezogenes Spezialwissen benötigt,
um diese Frage zu beantworten. Ein globales Prozessmodell erscheint hier als Lösungsansatz.
Hierdurch soll definiert werden, welche Prozesse zu unterstützen sind, welche Abhängigkeiten es
gibt und wer welche Verantwortung trägt.

Ab einem gewissen Grad übersteigt der manuelle Aufwand zur Beherrschung dieser Komplexität
den Aufwand zur Einführung eines BPM. Wann genau dieser Punkt erreicht ist, lässt sich nicht
allgemein bestimmen. Hierfür gibt es zu viele Einflüsse innerhalb einer jeden Organisation. Somit
muss sich jede Organisation die Frage stellen, was kostet mich die Administration heute und
welches Risiko gehe ich dabei ein.

Die IT-Abteilung ist in der Regel für den Betrieb von BPM-Lösungen und insbesondere für die
Realisierung von Workflows verantwortlich. In den seltensten Fällen ist davon auszugehen, dass
von Beginn an eine durchgehende Strategie für die Implementierung von Workflows existiert. Dies
führt häufig dazu, dass unterschiedliche Tools (BPMA und BPMS) eingesetzt werden und diverse
Mechanismen genutzt werden. Somit ist auch an dieser Stelle die Komplexität oftmals so hoch,
dass Standards benötigt werden, um einen Support der Anwendungen sicherstellen zu können. Es
ist dann zunächst eine einheitliche Strategie zu definieren. Somit wird de facto zunächst ein BPM
im Sinne einer Disziplin benötigt, um einen Rahmen für die technische Implementierung zu geben.
Dieser Punkt wird insofern zunehmend zu einer Herausforderung, da es immer mehr Angebote
von Workflow-Lösungen gibt, die als Cloud-Lösung angeboten werden und sich ohne Unterstüt-
zung der hauseigenen IT nutzen lassen.
16
1 einleitung, Strategie

Quality Management/Compliance:
Standards bekommen eine immer größere Bedeutung in Unternehmen. Dem gesellschaftlichen
Trend folgend, investieren Unternehmen zunehmend in Transparenz und klare Verhaltensregeln.
Auch die internen Qualitätsmanagement-Abteilungen haben das Ziel, standardisierte Abläufe zu
etablieren. Hierdurch soll eine gleichbleibende Qualität der Produkte und Dienstleistungen erreicht
und regulatorische Anforderungen von Prüfungsbehörden abgedeckt werden. Dies ist insbesonde-
re für Unternehmen im regulatorischen Umfeld (Pharma, aktive Medizinprodukte, Lebensmittel
etc.) von großer Bedeutung.

Kunde:
Alles Handeln einer Organisation ist auf den Kundennutzen auszurichten. Dies gilt selbstverständ-
lich auch für das BPM. Jede BPM-Aktivität muss das Ziel haben, einen Beitrag für den Kundennut-
zen zu leisten. Somit kann auch verhindert werden, dass BPM zu einer administrativen Selbstver-
waltung führt.

Zusammenfassend:
In Abhängigkeit von der Aufgabe im Unternehmen gibt es prinzipiell eine unendliche Anzahl von
Ausgangssituationen und Blickrichtungen. Das Ziel der Blickrichtung wird jedoch entweder die
Beherrschung von Komplexität auf Basis klar beschriebener Tätigkeiten sein (BPM als Disziplin)
oder die Reduktion von manuellen Tätigkeitsschritten durch Automatisierung (BPM zur Prozess-
automatisierung). Insbesondere in administrativen Unternehmensteilen wird dies über
elektronische Workflows gesteuert.

1.5 Darstellung der verschiedenen Zielgruppen für


BPM-Initiativen
Im Wesentlichen unterscheiden sich die Zielgruppen nicht von den unter 1.4 genannten Personen-
kreisen. Zu differenzieren ist jedoch, dass es in 1.4 darum ging, eine eigene Standortbestimmung
durchzuführen.

Genauso wichtig ist es, sich bewusst zu machen, an wen sich eine BPM-Initiative richtet und wer
überzeugt werden muss, eine solche Initiative zu starten.

1.5.1 BPM als Disziplin (BPMA)

Bei einem Bottom-up-Ansatz muss es dem Mitarbeiter gelingen, einen Sponsor im Top-Manage-
ment zu finden, der auch bereit ist, das Vorhaben zu finanzieren. Hierfür bedarf es einer ausge-
reiften und konsistenten Argumentationskette. Welche Argumente diese enthalten muss, orientiert
sich maßgeblich an dem Führungsstil des Managers.

Jedoch genügt es in der Regel nicht, einfach nur einen Projektsponsor zu finden. Soll eine
BPM-Initiative im Sinne eines BPM als Disziplin gestartet werden, betrifft dies maßgeblich die
Unternehmensorganisation. Eine prozessorientierte Sichtweise ist in der Regel nicht etabliert.
17

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Diese herbeizuführen ist die Motivation eines BPM. Somit ist es vorprogrammiert, dass es zu
einer Spannung zwischen einer Linienverantwortung und einer Prozessverantwortung kommt.
Etablierte „Fürstentümer“ stellen dabei ein großes Risiko für eine BPM-Initiative dar und bedürfen
der besonderen Aufmerksamkeit des Projektteams und des Projektsponsors.
Das Unternehmen muss dazu bereit sein, aufkommende Konflikte bzgl. Verantwortungen und
Kompetenzen zu lösen. Diese Bereitschaft ist von Beginn an einzufordern. Es muss sichergestellt
werden, dass es sich dabei nicht um Lippenbekenntnisse handelt.

Zu Beginn einer BPM-Initiative ist daher zu definieren, welche Rolle durch wen eingenommen wird
und welche Kompetenz diese Rolle hat. Hierbei ist es wichtig, sich tiefergehende Gedanken zu den
Konsequenzen zu machen. Wird die Rolle mit zu wenig Kompetenzen ausgestattet, kann die
Person ggf. nichts umsetzen.

Erhält die Rolle zu weitreichende Berechtigungen, kann dies zu Kompetenzüberschneidungen


führen, die geklärt werden müssen. Insbesondere im letzten Fall besteht das Risiko, dass
Entscheidungen über Umwege ausgehebelt werden und damit die gesamte BPM-Initiative in
Frage gestellt wird.

Eine Person, die eine BPM-Initiative in einem Unternehmen anstoßen möchte, egal auf welcher
hierarchischen Position sie verankert ist, muss sich zu drei Fragen im Klaren sein:
>> Warum will ich eine BPM-Initiative?
>> Welche Ziele verfolge ich?
>> Wen benötige ich für eine Umsetzung?

Die dritte Frage beantwortet dann auch die Frage, wer die Zielgruppen sind. Sobald diese bekannt
sind, muss im nächsten Schritt jeder Zielgruppe individuell erläutert werden, warum die BPM-
Initiative notwendig ist. Hierbei empfiehlt es sich, Prioritäten zu bilden und zunächst nur ausge-
wählte Zielgruppen anzusprechen.

Erfahrungsgemäß sind zwei Aspekte wichtig. Zum einem ist die Unterstützung des Top-Manage-
ments notwendig. Zum anderem werden ein paar Fürsprecher benötigt, die den Vorschlag
unterstützen und fördern.

1.5.2 Technisches BPM (BPMS)

Bei einem technischen BPM sind in der Regel wesentliche Entscheidungen schon getroffen. Für
gewöhnlich geht es um einen konkreten Anwendungsfall, der abgebildet werden soll. Es gibt also
schon einen Projektsponsor und der Rahmen ist ebenfalls bekannt.

Teilnehmende eines technischen BPM sind für gewöhnlich die IT-Abteilung, die für die Realisie-
rung verantwortlich ist, und der oder die betroffenen Fachbereiche. In den Fachbereichen werden
die Projekte in der Regel initialisiert, um einen bestimmten Prozess elektronisch abzubilden.
Geht die Einführung elektronischer Workflows über einzelne konkrete Anwendungsfälle hinaus, so
bedarf es einer übergreifenden Steuerung und Überwachung des Prozessdesigns – also eines BPM
als Disziplin. Hiermit kann die schnell aufkommende Komplexität beherrscht werden. Die genaue
Grenze zu finden, ist wiederum individuell durch jedes Unternehmen festzulegen. Einen festen
Grenzwert gibt es nicht.
18
1 einleitung, Strategie

Unabhängig davon empfiehlt es sich jedoch, einzelne lokale/abteilungsspezifische BPM-Initiativen


in eine BPM-Gesamtstrategie sowie IT-Governance einzubetten, um Administrationskosten
angemessen zu halten und eine ggf. spätere Zusammenführung zu erleichtern. Sobald die
Insellösungen durch die betreuende Abteilung nicht mehr einfach administriert werden können,
bedarf es der Unterstützung durch ein BPM als Disziplin. Der administrative Anteil darf ein
Mindestmaß nicht überschreiten, da dieser Teil nicht wertschöpfend ist.

1.6 BPM-Strategie

Eine erfolgreiche Prozessmanagementstrategie hängt sehr von der übergeordneten Strategie


des Unternehmens und der Unterstützung durch die Geschäftsleitung ab.

Grundsätzlich sind nachfolgende Kernbestandteile sicherzustellen:


>> Verständnis über die Zielsetzung von BPM im Unternehmen
>> Verankerung im Unternehmen und Einbettung in die Managementstruktur
>> Verzahnung mit den fachlichen und technischen Einheiten

Die Umsetzung kann, abhängig vom erwarteten Nutzen, in Form eines Re-Engineering, als
Big Bang oder aber auch in einer schrittweisen kontinuierlichen Implementierung erfolgen.
Für die im BPM-Ansatz implizite Prozessorientierung und die damit im Zusammenhang stehenden
Steuerungsinstrumente ist in vielen Organisationen eine veränderte Denk- und Arbeitsweise
erforderlich. Die daraus resultierenden Veränderungsprozesse lassen sich in einer kontinuier-
lichen, jedoch konsequenten Umsetzung häufig harmonischer in der Organisation verankern.
Die Einführung kann dabei mittels eines Reifegradmodells unterstützt werden.

Business Process Reengineering (BPR) vs. kontinuierlicher


Verbesserungsprozess (KVP durch BPM)

Merkmale BPR Merkmale KVP

> Radikaler Umbruch und Umbau von > Kontinuierliche, inkrementelle und
Abläufen im Unternehmen zeitnahe Anpassungen der Prozesse
> Quantensprünge in der Prozessqualität im Unternehmen
auf Basis aufwendiger as-is-Analysen > Fokus auf kleineren Anpassungen im
erhofft Prozess, damit zahlreiche Reduktion
> Durchführung in der Regel als Projekt des as-is/to-be/fit-gap-Zyklus
> Komplexität führt zu hohem > Durchführung als permanente
Ressourcen- und Koordinationsaufwand Aufgabe im Rahmen eines formal-
sowie Risiken isierten Change-Request-Prozesses
> Geringeres Risiko bei überschau-
barem Budget

Nur der Ansatz des KVP sichert eine nachhaltige


Prozessverbesserung im Rahmen des BPM.

(3) Gegenüberstellung Process Reengineering – Kontinuierliche Prozessverbesserung


(Quelle: PwC, 2011)
19

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
In der Strategie gilt es vor allem, sich im Unternehmen ein einheitliches Bild davon zu verschaffen,
welche Zielsetzung mit BPM verfolgt wird. Nur damit lässt sich die richtige organisatorische
Einbettung, Steuerung, Detailtiefe und ggf. Tool-Unterstützung gewährleisten.

Um mit BPM die Zielsetzung für das Gesamtunternehmen zu unterstützen, bedarf es neben einem
einheitlichen Bild auch einer konsequenten Steuerung bei der Einrichtung in den einzelnen Organi-
sationseinheiten. Sowohl Methoden, Steuerungsparameter als auch Tools müssen dabei auf-
einander und auf die Zielsetzung abgestimmt sein. Des Weiteren sind sie in Kernelementen
einheitlich aufzubauen. Die hierfür einzurichtende Governance muss diese Aspekte adressieren
und muss organisatorisch gut positioniert sein.

Eine erfolgreiche BPM-Umsetzung orientiert sich an den fachlichen Anforderungen und den Zielen.
Diese sind optimal durch die IT zu unterstützten. Dabei kann und soll die IT durchaus als initiativer
Treiber agieren.

1.7 „Darstellung des Nutzens von BPM, um personelle


und finanzielle Ressourcen für den Aufbau im
Unternehmen zu bekommen“

Wie alle Aktivitäten in einem Wirtschaftsunternehmen muss auch eine BPM-Initiative nachweisen,
dass sie einen Nutzen für die Unternehmung stiftet. Bei einer konkreten softwaregestützten
Prozessimplementierung kann der Return of Investment (ROI) über zusätzliche Kontrollmechanis-
men (Risikominimierung), Ablösung von papierbasierten Prozessen oder kürzeren Durchlaufzeiten
noch relativ einfach ermittelt werden.

Bei einer BPM als Disziplin-Initiative ist es deutlich schwerer, den Nutzen in belastbaren Zahlen
zu quantifizieren. In vielen Fällen sind zu Beginn einer Initiative die entstehenden Kosten nicht
vollständig berechenbar. Einsparpotenziale liegen häufig in den Abläufen, lassen sich monetär
aber nur schwer vorab belastbar ermitteln.

Es hat sich bewährt, kleine Erfolge nachzuweisen. Ansätze des BPM sind in Verbesserungs-
oder Umstrukturierungsprojekten mit anzuwenden. Hierdurch können die Projektverantwortlichen
nachweisen, welche Vorteile eine prozessorientierte Arbeitsweise hat. Anhand des konkreten
Beispiels lassen sich auch belastbare Zahlen ableiten.

Dies kann eine Basis darstellen, um weitere Ressourcen für ein BPM vom Management zu erhalten.

In den wenigsten Fällen wird das Management entscheiden, eine BPM-Initiative nach dem
„Greenfield Approach“ zu starten. Der Regelfall wird eine evolutionäre Vorgehensweise sein,
bei dem über Pilotprojekte Erfolge nachgewiesen werden müssen.
20
1 einleitung, Strategie

Für eine Abschätzung einer ersten Kosten-/Nutzenschätzung können nachfolgende Frage-


stellungen helfen:
>> Prozessbezogener Nutzen:
> Kosten-/Qualitätsbewertung im betrachteten Prozess?
> Transparenz im Prozess als Grundlage einer höheren Dynamik zur Verbesserung im Prozess?
>> Organisationsbezogener Nutzen:
> Können weitere prozessbezogene Strukturen kombiniert werden
(Compliance, Risikomanagement, Internes Kontrollsystem (IKS), ISO-Zertifizierung)?
> Motivation von Mitarbeiter durch Prozessverantwortlichkeiten und Entscheidungsspielräume
bei Verbesserungen?
>> Projektbezogener Nutzen:
> Sind Organisations-/Systemprojekte geplant, die auf BPM-Unterlagen aufbauen können
(IST-Analyse, Testunterlagen etc.)?

BPM als Disziplin stellt immer eine Änderung der Organisation dar. Hierbei wird es bei dem
Übergang einer funktional geführten Unternehmung hin zu einer prozessorientierten Unterneh-
mung auch immer zu einer Erhöhung der initialen administrativen Aufwendungen (u.a. für das
Change Management) führen. Dies ist von Beginn an zu berücksichtigen. Ansonsten werden
BPM-Initiativen zwangsläufig scheitern.

Ist ein BPM erfolgreich in einer Unternehmung etabliert, so sind Mechanismen zu definieren, die
den dauerhaften Nutzen eines BPM sicherstellen. Es besteht sonst die Gefahr, dass sich das BPM
zu einem Selbstzweck entwickelt und Aufgaben für die Organisation ableitet, die nicht mehr
wertschöpfend sind.

Das BPM steht hier im Wettbewerb zu anderen Organisationsformen und darf sich auf einmal
Erreichtem nicht ausruhen.
Abschließend ist noch anzumerken, dass BPM nicht alle Erwartungen erfüllen kann, die
eine Organisation an es richten kann. Daher ist von Beginn an ein Schwerpunkt zu definieren.
Die BPM-Initiative ist dann auf diesen auszurichten. Ansonsten droht die Initiative zu scheitern.
In diesem Kontext soll dieses Kapitel mit folgendem Zitat abschließen:

Manchmal klingt es, als würden BPM-Befürworter empfehlen, jede Aktivität eines Unternehmens
mithilfe formaler Geschäftsprozessmodelle zu beschreiben oder zu automatisieren. Aber selbst die
eifrigsten Verfechter sind nicht der Meinung, dass BPM in einem solchen Umfang eingeführt
werden sollte. Vielmehr zielt das BPM auf die Prozesse ab, die für die Wertschöpfung am
wichtigsten sind, auf die Prozesse, die nach ihrer Optimierung enorme Vorteile ermöglichen und
sich am dringendsten schnell verändern und entwickeln müssen, um wettbewerbsfähig zu bleiben.

(Quelle: BPM-Technologie im systematischen Überblick, White Paper, SAP und Accenture, März 2009)
DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
21
22
2 Ziele, Organisation, Aufsetzen
eines BPM im Unternehmen
Im folgenden Kapitel werden der operationale Aufbau und das Aufsetzen eines Business Process
Management (BPM) im Unternehmen dargestellt.

>> Wie erfolgt die Verbindung von Geschäftszielen, Geschäftsmodell und Geschäftserfolg mit
den Prozessen?
>> Wer ist für die Prozesssteuerung (Prozess-Governance) verantwortlich und wo
liegt die Prozessverantwortung?
>> Welche Rollen und damit verbundene Aufgaben gibt es und wie könnte eine
BPM-Organisation im Unternehmen aussehen?
>> Wie werden die Reifegrade der Prozesse einheitlich gemessen und somit die
Prozessverbesserungen vergleichbar und transparent?

2.1 Verbindung von BPM zu den Unternehmenszielen

Wie in Kapitel 1 bereits ausgeführt, sind das BPM und die Ziele eines Unternehmens eng
miteinander verbunden. Über das BPM soll erreicht werden, dass der Geschäftserfolg gesteigert
wird, indem man sich auf die Verbesserung derjenigen Prozesse konzentriert, die maßgeblich
für den Unternehmenserfolg sind. Das BPM unterstützt ebenfalls dabei, die Abhängigkeiten von
Geschäftsprozessen darzustellen und so neben den offensichtlichen Kernprozessen auch die
maßgeblichen unterstützenden Prozesse zu identifizieren. Außerdem muss sichergestellt werden,
dass die Unternehmensziele auf die einzelnen Prozesse heruntergebrochen werden und diese
somit die Zielerreichung des gesamten Unternehmens unterstützen.

Gleichzeitig dient BPM auch als Basis für die Messung von Prozessverbesserungen und damit
zusammenhängend für die Messung der Erreichung von Unternehmenszielen. Nur ein eindeutig
beschriebener Prozess mit klar definiertem Start- und Endpunkt und modellierten Prozess-
schritten lässt sich auch messen.

Um BPM als wirkungsvolles Werkzeug zu etablieren, den Geschäftserfolg zu steigern und die
Unternehmensziele zu erreichen, müssen folgende Fragen gestellt (und beantwortet werden):
>> Was sind die Ziele des Unternehmens?
>> Welche Geschäftsprozesse tragen maßgeblich zur Erreichung der Unternehmensziele bei?
>> Typische Kriterien hierbei sind z.B. Anzahl der Anwender eines Prozesses, erzeugter Geldwert
eines Prozesses (z.B. Umsatz), Anzahl adressierter Kunden. Diese begrenzte Anzahl von
Hauptprozessen wird typischerweise auf der Prozesslandkarte des Unternehmens
dargestellt. Weitergehende Informationen zur Prozessmodellierung siehe Kapitel 3.
>> Auf welche Art und Weise müssen Geschäftsprozesse verändert werden, um die
Unternehmensziele zu erreichen?

Beispiele für eine Veränderung sind Verkürzung der Durchlaufzeit, höherer Output, geringere
Anzahl von Prozessschritten, höherer Automatisierungsgrad. Pro Geschäftsprozess sollte
dieses Veränderungsziel ganz konkret in einem Jahresplan festgehalten werden.
23

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
2.2 Organisationsformen für eine BPM-Organisation
im Unternehmen

Abhängig von der Größe und der Aufbauorganisation des Unternehmens kommen verschiedene
Anwendungsfälle für das BPM in Frage: Konzern versus kleinere, einfachere Organisation, Ein-
oder Mehr-Gesellschaftsstruktur, funktions- oder prozessorientiert aufgebautes BPM, ein oder
mehrere Standorte, Shared Service Center (SSC) im Einsatz usw.

Der Anspruch und der Aufwand, die beim Aufbau einer Prozesslandkarte, des Prozessmanage-
ments und der Prozessverantwortung erforderlich sind, hängen größtenteils von der Komplexität der
Unternehmensstruktur ab. Grundsätzlich kann man zwischen einfachen und komplexen Unterneh-
mensstrukturen unterscheiden. Bei einer einfachen Unternehmensorganisation (z.B. Ein-Gesell-
schaftsstruktur oder alle Unternehmen in einer Branche) wird es in der Regel einfacher sein, einen
klar erkennbaren Prozessverantwortlichen zu benennen, der maßgeblich entscheidet, was sein
Prozess beinhaltet. Auch die Verknüpfung zu vor- und nachgelagerten Prozessverantwortlichkeiten
kann einfach strukturiert und umgesetzt werden. Aber auch hier ist Voraussetzung, dass eine
BPM-Philosophie in einem Handbuch beschrieben wurde, an die sich alle Teilnehmer halten
müssen.

Bei einer komplexen Unternehmensorganisation (z.B. Mehr-Gesellschaftsstruktur oder global


agierenden Konzernen) ist die Erstellung eines global gültigen Prozessmodells entsprechend
aufwendig. Neben den Festlegungen, wie etwas wo und wann modelliert wird, ist es immens
wichtig klarzustellen, was das Prozessmodell darstellen soll. Hier empfiehlt es sich zu definieren,
dass das Prozessmodell die Sicht einer „Modellgesellschaft“ abbildet, in der alle Prozesse bzw.
Prozessvarianten aller Gesellschaften enthalten sind. Einen End-to-End-Prozess zu modellieren,
der auch die Prozessverbindungen zwischen den Gesellschaften darstellt, ist mit genormten
Modellierungssprachen nicht mehr verständlich abbildbar. Hier eignen sich Mal- oder Präsentati-
onswerkzeuge besser, deren Sachinhalte man, z.B. über Verlinkungen, an definierten Stellen des
Prozessmodells zur Anzeige bringen kann.

Die Abbildung mit IT-Sicht auf eine „Modellgesellschaft“ bringt zudem den Vorteil, dass man
alle Prozessvarianten aller zum Konzern gehörigen Gesellschaften nebeneinander sieht und im
Hinblick auf Standardisierung und Harmonisierung von Prozessen Vergleichsmöglichkeiten hat.
Den Prozessvarianten selbst kann man über Attribute die Information mitgeben, in welcher
Gesellschaft die Prozessvariante gelebt wird. Diese Art der Darstellung bedarf aber auch einer
BPM-Organisation, die eine BPM-Hierarchie in allen Gesellschaften des gesamten Konzerns
zentral organisiert hat.

Über die Verwendung einer Prozess-Governance (Prozesssteuerung) ist eine eindeutige Festlegung
der Rahmenbedingungen, Regeln und Prinzipien, die für das gesamte Unternehmen gelten, und
vor allem die Festlegung der Prozessverantwortung möglich, d.h. die Definition der Organisationen,
die für die tatsächliche Durchführung der Prozesse und deren Ergebnisse verantwortlich sind.
24
2 Ziele, Organisation, Aufsetzen
eines BPM im Unternehmen
Prozess-Governance:
Um eine einheitliche Prozess-Governance für das gesamte Unternehmen zu gewährleisten, ist
diese Aufgabe typischerweise einem zentralen Bereich zugeordnet. Ganz egal, ob es sich dabei um
eine eigenständige BPM-Organisation handelt oder um ein Projektteam innerhalb einer bestehenden
Organisation. Wichtig ist der klare Auftrag der Unternehmensleitung und damit verbunden die
komplette Durchdringung des Unternehmens.

Typische Aufgaben:
>> Definition und Kommunikation von Prozessmodellierungsregeln und Prozessstandards
>> Zentrale Verwaltung der Prozesslandkarte
>> Training und Ausbildung zur Methodik
>> Vorgabe von allgemeinen Vorlagen (z.B. zur Prozessdokumentation)
>> Definition der Prozessreifegrade und entsprechende Messung (siehe Kapitel 2.3)
>> Bereitstellung von Beratungsdiensten zur Prozessverbesserung und Prozessoptimierung

Typische Rollen:
>> BPM-Sponsor (Chief Process Officer)
> Vertretung des Themas BPM auf Management-Ebene
> Schaffung von geeigneten Rahmenbedingungen
> Unterstützung bei der Durchsetzung von BPM und Bereitstellung benötigter Ressourcen
>> BPM-Manager
> Erfolgreiche Umsetzung und Betrieb des BPM
> BPM-Koordination, -Planung und -Steuerung
>> BPM-Methodenverantwortlicher
> Durchgängiger Einsatz und Verbesserung der BPM-Methode

Prozessverantwortung:
Die operative Prozessverantwortung liegt normalerweise in den Fachabteilungen. Diese haben
das entsprechende Expertenwissen zu den jeweiligen Prozessen und sind für die Zielerreichung
verantwortlich.

Typische Aufgaben:
>> Prozessmodellierung und Prozessdokumentation
>> Kontinuierliche Verbesserung des Prozesses

Typische Rollen:
>> Prozessverantwortlicher/Prozesseigner
> Erfolgreicher BPM-Betrieb innerhalb seines Prozessbereichs
> Kontinuierliche Verbesserung der Prozesse
25

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
2.2.1 Beispiele für BPM-Umsetzungen bei deutschen Unternehmen

2.2.1.1 Umsetzung Software-Hersteller (SAP AG)

Der Chief Process Officer und seine Organisation sind für die unternehmensweite Prozess-Gover-
nance zuständig. Die Prozessverantwortung liegt in den Fachabteilungen und ist aufgeteilt auf den

> Business Owner:


Verantwortlich für das WAS: Festlegung der Geschäftsziele und der Strategie des Prozesses,
koordiniert die involvierten Geschäftsbereiche und Process Manager.

> Process Manager:


Verantwortlich für das WIE: Prozessdefinition, Ausführung und die Verbesserung des Prozesses.

Je Vorstandsbereich gibt es ein „Board Area Process Office“, das die Process Manager und
Business Owner sowohl koordiniert als auch unterstützt.

In regelmäßigen Meetings gibt es Updates zu den Prozessmanagement-Standards,-Methoden


und -Werkzeugen (siehe Abbildung).

... Board Area

... Board Area

... Board Area

Chief Process Officer

Board Area Process Office Alignment Meeting Board


Area
Board Process
Area Office
Board Process
Standards, Board Area Office
CPO Process Methods, Area Process
Management Tools Process Office
Office

(4) Updates im BPM (Quelle: SAP AG, 2012)


26
2 Ziele, Organisation, Aufsetzen
eines BPM im Unternehmen
2.2.1.2 Umsetzung Fashion-Unternehmen

Folgende Abbildung zeigt ein Beispiel für die Verteilung von zentralen, regionalen und lokalen
Rollen eines großen deutschen Fashion-Unternehmens.
e.g. BPM
BPM Sponsor strategy,
roadmap, project
Definition

planning,
(central)

Head of International BPM methodology

International BPM Expert trainings and


communication
e.g. process-KPI e.g. feedback
definition and cycle, creation of
Regional Head of BPM measurement, reusable
Compliance
(regional)

e.g. analysis and BSC-cockpit, knowledge, roles


e.g. implementa- planning process,
design for process & responsibili-
tion and review of PPM process
Regional BPM Expert improvement, process warehouse
ties, reporting
process-, lines
improvement
structure- and measures,
organization- install/adjust
change
Process Owner required IT
systems and
other process
enabler, trainings
Regional Process Owner and communica-
tion
Execution
(local)

Process Integrator

Modeler

Administrator

(5) Software AG, 2013

2.2.1.3 Umsetzung weiteres DAX-Unternehmen

Focus Rolle Inhalt CP Zentrale Regional IT

Definiert die Bedingungen und Regeln für das PM


Strategisch Prozess-Governance und legt die Prozess-/Qualitätsziele fest

Leitet Prozess-Strategie auf Basis der Unterneh-


Prozess-Stratege mensstrategie ab
Unterrollen

Verantwortlich für die Pflege u. Entwicklung des


Prozess-Architekt Prozessmodells und der übergreifenden Prozesse

Definition von Kennzahlen, Konsolidierung der Kennzah-


Kennzahlen Mng. lenreports, Erstellung von Prozess-/ Qualitätsreports

Unterstützt die Prozess-Manager bei der Entwicklung


Prozess-Coach der Prozesse, bringt Methoden ein u. unterstützt die QS

Operativ Prozess-Manager
Trägt die Verantwortung für einen zentralen Prozess,
(zentral/regional) dessen Prozessleistung und Messung

Trägt die Verantwortung für einen zentralen


Teilprozess-Manager Teilprozess

Verantwortlich für operatives Prozessmanagement


Leiter QP Regional der Prozesse in den Regionen

Unterstützt die Prozessmanager bei der Modellierung


Modellierer der Prozesse und der IT im BPA-Tool

Technisch Administriert die BPA-Tool-Datenbank und vergibt


Tool-Administrator Rollen und Berechtigungen

Der Betriebsverantwortliche pflegt und entwickelt die


BPA Applikations Mng. Infastruktur und betreut Anwendersupport

(6) Telekommunikationsunternehmen (Software AG, 2013)


27

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
2.3 BPM-Reifegrade

Ein wesentlicher Bestandteil von BPM ist die kontinuierliche Prozessverbesserung und die „Reife“
eines Prozesses in Bezug auf die BPM-Methodik. Um dies unternehmensweit einheitlich messen
zu können, werden unterschiedliche Reifegradmodelle benutzt.

Die Definition eines Standard-Modells, das in allen Unternehmen verwendet werden kann, ist nicht
möglich, da für die verschiedenen Unternehmen unterschiedliche Anforderungen/Messkriterien
erforderlich sind. Deshalb kann eine Anpassung der existierenden Modelle an die entsprechenden
Prozessanforderungen notwendig sein.

Aus diesem Grund ist auch keine Empfehlung für ein spezielles Modell möglich. Wichtig ist, dass
überhaupt ein Reifegradmodell zur Prozessbewertung verwendet wird.

Beispiele für BPM-Reifegradmodelle:

EDEN-Reifegradmodell:
Ein in Deutschland immer populäreres Reifegradmodell ist das EDEN-Reifegradmodell (Erfolg-
reich – Durchgängig – Effizient – Nachhaltig). Der BPM-Club-Arbeitskreis „Business Process
Excellence“, dem eine Reihe von Prozessmanagern und Prozessmanagementexperten aus
namhaften Firmen angehören, kam bei seiner Arbeit zu der Erkenntnis, dass bestehende
Reifegradmodelle hinsichtlich der unternehmensweiten Prozessorientierung nicht umfassend
genug waren. Aus diesem Grund hat sich der Arbeitskreis sehr intensiv mit diesem Thema
beschäftigt und letztlich ein eigenes Reifegradmodell entwickelt, das Modell EDEN. Grundlage
hierfür waren vorhandene Modelle in einigen der beteiligten Unternehmen, die bereits im
praktischen Einsatz waren, sowie die vielfältigen Erfahrungen der Teilnehmer. Die Entwicklung
des Modells EDEN lag somit nicht in der Hand von Beratern, sondern von Anwendern.

Die Gründungsmitglieder sind: BASF SE, Fraunhofer Gesellschaft, Nordenia International AG,
Goals International GmbH, BPM&O GmbH, Prof. Dr. Thomas Allweyer, Dr. Peter Telgheder, Stefan
Knickel, Dr. Klaus Riehl, Michael Maiss, Frank Thiele. Hinzugekommen sind Entwicklungspartner
wie z.B. Lufthansa, Alstom Power, VW Financial Services, Dunlop, T-Mobile u.v.m. Beim EDEN-
Reifegradmodell wird sowohl der Reifegrad eines Unternehmens als auch der Reifegrad von
Prozessen analysiert und bewertet. Dabei kann jegliches Prozessmodell hinterlegt sein.
Eingesetzt wird es u.a.,
>> wenn man den Status der Prozessorientierung einer Organisation ermitteln will.
>> wenn man ein Gutachten über den Reifegrad der Prozessorientierung einer Organisation
haben möchte.
>> wenn man ein einheitliches Verständnis von Prozessmanagement in einer Organisation
schaffen will.
>> wenn man zum Thema Prozessmanagement mit dem Management ins Gespräch
kommen will.
>> wenn man die Handlungsfelder bei der kurz-, mittel- und langfristigen Entwicklung von
Prozessmanagement definieren will.
>> wenn man die richtige Implementierungsstrategie für das Prozessmanagement in der
Organisation erarbeiten will.
>> wenn man wissen will, wo die kurzfristigen Verbesserungspotenziale sind.
28
2 Ziele, Organisation, Aufsetzen
eines BPM im Unternehmen
Etwa 150 Bewertungskriterien über neun Dimensionen bieten ein extrem breites, differenziertes
Analysespektrum. Eine sinnvolle Bewertung erfolgt vor dem Hintergrund des gewünschten
Soll-Zustands. Es ist daher erforderlich, die Ziel-Situation bzgl. des Prozessmanagements zu
definieren und die Ist-Situation systematisch mit diesem angestrebten Zustand zu vergleichen.
Hieraus ergibt sich, in welchen Bereichen der Handlungsbedarf wie groß ist.

Stufe 1 Stufe 2 Stufe 3 Stufe 4 Stufe 5 Stufe 6


„Chaotisch“ „Ansatzweise“ „Fort- „Durchgängig“ „Gesteuert“ „Nachhaltig“
geschritten“
Durchführung Initiale Akti- Das Prozess- Das Prozess- Die Prozesskul-
und Ergebnisse vitäten zum Umfangreiche modell ist im modell wird tur ist Bestand-
des Prozess- Aufbau eines Aktivitäten zum ganzen zielorientiert teil der Unter-
managements Prozessma- Aufbau eines Unternehmen und effizient im nehmenskultur.
sind unvoll- nagements sind unternehmens- etabliert. Unternehmen
ständig und durchgeführt. weiten Prozess- angewandt.
zufällig. modells sind
durchgeführt.

(7) Reifegradmodell EDEN (Quelle: © BPM Maturity Model EDEN e.V., Januar 2010)

Der Text zum EDEN-Reifegradmodell ist der offiziellen Homepage der BPM Maturity Model EDEN
e.V. entnommen. Mehr Informationen siehe www.bpm-maturitymodel.com.
29

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
BPM Maturity Model der Software AG:

Das Reifegradmodell beinhaltet 5 Level:

Level 1 „Initial stage“ Keine strukturierten Aktivitäten im Fachbereich vorhanden.

Level 2 „Awareness“ Ein Prozessbewusstsein existiert, erste planende Aktivitäten wurden


aufgenommen.

Level 3 „Defined“ Der Prozess wurde definiert. Die Implementierung ist gerade am Laufen
oder noch nicht erfolgt.

Level 4 „Managed“ Der Prozess ist implementiert. (Die Rollen sind zugeordnet, notwendige
Kommunikationen sind erfolgt. Schulungen wurden durchgeführt etc.)

Level 5 „Excellence“ Prozess ist unternehmensweit implementiert. Ein kontinuierlicher


Prüf- und Verbesserungsprozess ist implementiert.

Zudem gibt es im BPM Maturity Model Fragenkatalog zu den verschiedenen Projektphasen.

(8) Auszug Fragenkatalog für BPM-Strategiephase (Quelle: Software AG)


30
2 Ziele, Organisation, Aufsetzen
eines BPM im Unternehmen
Maturity Model der SAP AG:
Abgeleitet aus dem Process Enterprise Maturity Model (PEMM) von Michael Hammer und dem
Capability Maturity Model Integration (CMMI).

Es gibt vier Stufen 0 bis 3:


>> 0: Prozess ist weder transparent noch verwaltet (unzureichend und nicht reif)
>> 1: Prozess ist transparent (minimal)
>> 2: Prozess wird verwaltet (Standard)
>> 3: Prozess ist auf einem hohen Optimierungsniveau und wird kontinuierlich verbessert
(hervorragend)

Process Performance Management


SAP Process Maturity Model – Pragmatic and Simple

Maturity Level 3: > Process vision available


Process continuously > Annual improvement rate defined
improved > Real life SLAs available
(excellence) > Application of SAP standard systems without modification
> Online transparency of data available
> Single tasking of employees guaranteed
> E2E output performance accountability

Maturity Level 2: > Process Performance Indicators (PPI) focused on process input,
Process managed process operation and process output in place
(standard) > Monitoring tool is in place (e.g. BPMON)
> Process Improvement Levels are defined
> Established Process Cockpit
> Risk Assessment performed
> Customer satisfaction

> Accountable Business Owner/Process Manager


Maturity Level 1:
> Dokument process
Process transparent
> Process standardization is transparent
(minimum)
> Referenced to workflow and Process Map
> Knowledge transfer available
> Scope for external auditing clarified

(9) Reifegradmodell der SAP (Quelle: SAP AG, 2012)


DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
31
32
3 Vom Unternehmensziel zum
Prozessdesign
3.1 Einführung

BPM verknüpft die Strategie mit der operativen Prozessausführung und der unterstützenden
IT-Lösung. Es liefert einen integrierten Ansatz vom Design zur Ausführung und zum Controlling
durch die Nutzung von Prozessmodellen. Einmal modelliert und in einem Repository abgelegt,
stellen sie einen echten Mehrwert dar. Die Effizienz und Effektivität von Prozessmodellen wird
durch deren Modellierung, ggf. anhand von Referenzmodellen und der passenden Modellierungs-
software, erreicht.

In diesem Kapitel wird über die Designphase des BPM-Lifecycles inklusive konkreter Planung
und Umsetzung der Prozessmodellierung diskutiert und es werden konkrete Ansätze angeboten.

Es gibt dabei KEINE allgemeingültige Lösung, sondern bestimmte Fragestellungen, die sich ein
Unternehmen beim BPM-Projekt stellen soll. Es hängt vieles von der Zielsetzung des Projekts,
der Unternehmensgröße und der Organisationsform ab, wie diese BPM-Themen im eigenen
Unternehmen umgesetzt und gelebt werden.

Bevor Sie mit der Prozessmodellierung anfangen, sollten Sie die fünf W-Fragen der Prozess-
modellierung beantworten:

>> Was modellieren Sie?


Wollen Sie eine Prozesslandschaft aufbauen? Modellieren Sie spezifische Prozesse?
Handelt es sich um bereichsbezogene oder End-to-End-Prozesse?
>> Warum modellieren Sie?
Handelt es sich um einen Prozessoptimierungsprojekt oder um eine
IT- / SAP-Implementierung?
Um welche Anwendungsfälle handelt es sich denn genau?
>> Für wen sind die Modelle gedacht?
Gibt es eine oder mehrere Zielgruppen für die Prozesse?
Verstehen diese das Gleiche unter einem Prozess? Soll es einen oder mehrere Prozesse mit
unterschiedlichen Inhalten geben?
Oder verschiedene Sichten auf die Prozesse?
>> Wann sind die modellierten Prozesse relevant?
Was ist die Aufgabenstellung für Prozessmodelle?
Für welche Art Projekte sollen sie zum Einsatz kommen?
Antworten, die ein Projektauftrag des Managements zur Erstellung eines Prozessmodells
beinhalten muss.
>> Wie und wo werden die Modelle benutzt?
Werden die modellierten Geschäftsprozesse zur Dokumentation und als Grundlage für
Optimierungen benutzt (BPMA) oder sind diese für eine Automatisierung gedacht (BPMS)?
Werden diese ausschließlich in einem Prozessmodellierungstool oder auch in einem
Prozessportal oder zu anderen Tools (z.B. SAP NetWeaver BPM) zur Automatisierung
übertragen?
33

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Wenn Sie ein BPM-Projekt im SAP-Umfeld starten, werden Sie sich wie in allen anderen
BPM-Projekten Standard-BPM-Fragen und -Herausforderungen stellen müssen.

Diese sind im Einzelnen:

>> Wie kommen wir zu einem (guten) Prozess?


Das heißt im Einzelnen: Aus welchen Anwendungsfällen heraus werden die Prozesse modelliert
bzw. re-dokumentiert? Und des Weiteren sollen Referenzmodelle benutzt werden
(für nicht differenzierende Prozesse) oder soll auf der grünen Wiese angefangen werden?
>> Im zweiten Schritt ist es notwendig, sich zu fragen, wie diese Prozesse strukturiert werden.
Dabei spielen Überblicksmodelle, Prozesslandkarten sowie die Anzahl an Ebenen eine große
Rolle. Wichtig ist auch, die verschiedenen Zielgruppen der Prozessmodelle in der Prozess-
strukturierung zu berücksichtigen.
>> Steht die Struktur und das Grundgerüst, müssen die „Details“ bestimmt werden.
Wie sieht die Prozessdarstellung aus und welche Informationen sind beinhaltet? Hier geht es
um die Themen Modellierungssprache und Artefakte in der Modellierung.
>> Anschließend muss die Frage nach der Prozessverwaltung durchgegangen werden.
Wie werden diese Prozesse verwaltet (in welchem Tool), gehalten und ggf. verteilt?

3.2 Wie kommt man zu einem zielkonformen Prozess?

Indem man sich vorab Gedanken macht …

Prozesse sind der Kern eines jeden Unternehmens und Geschäfts. Anhand von Prozessen erfolgt
die Transformation (Geschäftsänderung). Diese Prozesse sollten der Ausgangspunkt für alle
Veränderungen, sowohl organisatorische als auch technische, im Unternehmen sein.

Anforderungen und Umsetzungen sollten daher aus Prozesssicht bewertet werden und in einen
organisatorischen Lifecycle (siehe auch Kapitel 2 BPM-Organisation) eingebunden sein. Somit
wird das Prozessmodel zur gemeinsamen Sprache zwischen Business und IT.

Projekt- und Unternehmensziele sind der Maßstab und die


Tipp Nr. 1
Grundlage einer erfolgreichen Prozessmodellierung!

Grundsätzlich soll BPM die erfolgreiche Umsetzung der Unternehmensziele unterstützen. Dazu
muss klar sein, welche wertschöpfenden Prozesse die Erreichung der Unternehmensziele am
besten und stärksten unterstützen. Diese Prozesse sollten vorrangig vollständig ausgeprägt sein.
Das hat auch den Nebeneffekt, einen Musterprozess aufzubauen, der zur Abbildung von weiteren
Prozessen, als Beispiel für andere Zuständigkeiten, genutzt werden kann.
34
3 Vom Unternehmensziel zum
Prozessdesign
Unternehmensgröße und Organisationsform sind wichtige Grundlagen
Tipp Nr. 2
für das BPM-Prozessmodell!

Abhängig von der Größe und Aufbauorganisation des Unternehmens kommen verschiedene
Anwendungsfälle für Prozessmodelle in Frage. Konzern vs. kleinere einfachere Organisation,
funktions- oder prozessorientiert aufgebaut, ein Standort oder mehrere Standorte, Shared Service
Center im Einsatz usw., bilden Rahmenbedingungen, die die Komplexität zur Erstellung eines
BPM-Prozessmodells entscheidend beeinflussen. Siehe hierzu auch Kapitel 2.2. Am Beispiel
einer komplexen Unternehmensgruppe können folgende Überlegungen im Vorfeld spätere
Probleme verhindern:

>> Wer ist mein Pilotprojekt?


Eine Abteilung, ein Unternehmensbereich, eine Gesellschaft der Gruppe? Bei Ausweitung des
BPM im Unternehmen müssen die Prozesse immer noch zueinander passen. Wenn jeder sein
Prozessmodell so aufbauen darf, wie er es für richtig hält, wird eine End-to-End-Sicht eines
Prozesses über mehrere Abteilungen oder Bereiche nicht möglich sein.
>> Wie bilde ich das Zusammenspiel meiner Firmen untereinander ab (Intercompany)?
Bei einer getrennten Darstellung eines Prozessmodells ist eine Analyse im Sinne einer
Prozessstandardisierung nur schwer möglich, weil man nicht die Prozesse unter- oder
nebeneinanderlegen und auswerten kann. Besser alle Prozesse aller Firmen in ein Prozess-
modell und betriebswirtschaftlich strukturieren.
>> Möchte ich meine Prozesse prozessorientiert und abteilungsübergreifend auswerten?
In einer funktionsorientierten Organisation können nur sehr schwer Zuständigkeiten für
prozessorientiert dargestellte Prozesse zugeordnet werden. Auch die IT-Abteilung hat
Probleme, die funktionsorientierten SAP-Software-Module zuzuordnen und eindeutig zu
selektieren. Prozessvarianten lassen die Zuordnung zu gleichen SAP-Funktionen zu, obwohl
man betriebswirtschaftlich gesehen eigentlich unterscheiden möchte. Eine zusätzliche
funktionsorientierte Sicht mag hierfür Abhilfe schaffen. Mehr dazu später im Kapitel.

Sammeln Sie, untersuchen Sie und strukturieren Sie Ihre Anwendungsfälle,


Tipp Nr. 3
bevor Sie loslegen!

Je nachdem, um welche Anwendungsfälle es sich in Ihrem Fall handelt, werden Sie zum einen
anders an den Prozess herangehen und zum anderen haben Sie dabei unterschiedliche
Anforderungen.

Der Aufbau einer Prozessstruktur ist abhängig davon, was man in einer letzten Stufe der Nutzung
und Zielerreichung damit machen möchte.

>> Soll die Prozesslandkarte nur zur Dokumentation von Prozessen dienen?
>> Will man eine Wissensdatenbank für alle Arten von Anwendern aufbauen?
>> Will man sie als Vorgabe für SAP-Prozesstests nutzen?
35

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
>> Will man sie als Schnittstelle zur IT nutzen, um Betriebswirtschaft und Technik zu verbinden?
>> Will man Prozessmessungen damit verknüpfen, um Ursachen- / Wirkungsanalysen durch-
zuführen, oder Vergleichsmessungen von Unternehmenseinheiten darstellen?
>> Will man nur SAP- bzw. IT-gestützte Prozesse darstellen oder auch das Zusammenspiel
mit manuellen Prozessen oder Aktivitäten?
>> Will man eine Standardisierung und Harmonisierung von IT-Prozessen steuern?
>> Will man sein Unternehmen / seine Prozesse prozessorientiert steuern?
>> Will man Gesellschaften integrieren (im Rahmen von Post Merger Integration oder SAP-System
Integration) oder ausgliedern?
>> Soll das unternehmensweite Qualitätsmanagement (Audits, GRC …) integriert werden?

Im SAP-Umfeld lassen sich Standard-Anwendungsfälle definieren, z. B.:

>> Neueinführung SAP oder SAP-Modul


>> Template- und / Global Rollout-Projekt
>> Prozessoptimierungsprojekt
>> Anforderungsumsetzung
>> Dokumentation bzw. Re-Dokumentations-Projekt (z.B. QS / SOX / ISO usw.)

Achtung Falle!
Da man nur mit größtem Aufwand alle Anforderungen gleichzeitig aufbauen
kann, muss beim Aufbau der Prozessstruktur die geplante Nutzung klar sein.
Ist es das nicht, wird man sie im schlimmsten Fall zwischendurch umbauen
müssen. Neben einem hohen Arbeitsaufwand muss dann auch ein neues
Verständnis den Anwendern klargemacht werden (Change Management).

Machen Sie sich Gedanken, ob und welche Referenzprozesse und Best



Tipp Nr. 4 Practices Sie in Ihrem Projekt mit einfließen lassen wollen!

Prozessreferenzmodelle sind generische konzeptuelle Modelle, die Best Practices in einem


speziellen Bereich darstellen und (als Vorlage) wiederverwendet werden können. Prozessmodelle
können unterschiedlich benutzt werden, z.B. für das Design oder die Optimierung von bestehenden
Prozessen, aber auch für die Best-Practice-Analyse und Benchmarking (z.B. APQC) oder des
Weitern bei Software-Auswahlprojekten. Dies hat einige Vorteile, u. a. Zeitgewinn (Startpunkt und
Beschleuniger des Projektes) und Profitieren vom Wissen anderer. Referenzmodelle und Best
Practices können also von großem Nutzen bei der Geschäftsprozessmodellierung sein, sind aber
keine zwingende Thematik.
36
3 Vom Unternehmensziel zum
Prozessdesign
Achtung Falle!
Für den Aufbau einer Prozessstruktur gibt es am Markt relativ viele Musterstrukturen,
z.B. SCOR, APQC, CMMI etc. Die Referenz- und Vorgehensmodelle (AP QC, ToGAF,
Archimate, SCRO, Industry.Performance READY , ITIL etc.) haben unterschiedliche
Schwerpunkte (Branche, Vorgehen, Thema…) und haben eines gemeinsam – sie bilden
kein unternehmensindividuelles Verständnis der eigenen Prozesse ab. Insofern sind
sie als Beispiele oder Muster empfohlen. Eine Anpassung ist letztendlich erforderlich,
damit die Nutzer der Prozessstruktur ihre Prozesse mit deren unternehmens-
individuellen Bezeichnungen wiedererkennen.

Aus IT-Sicht macht es Sinn, die Prozessstruktur der SAP Business Process
Repository (SAP BPR) zu nutzen, die mit dem SAP Solution Manager zur Verfügung
gestellt wird. Das hat den Vorteil, dass bereits die SAP-Objekte mit den Prozessen
verknüpft sind, z.B. Transaktionen.

Machen Sie sich Gedanken, ob Sie „Bottom-up“ oder „Top-down“



Tipp Nr. 5 bei der Prozessmodellierung vorgehen wollen!

Je nachdem, was man für Leistungen von einer Prozessstruktur anfordert, kann man sie mit
dem Top-down-Verfahren (von Ebene 1 bis zur untersten Ebene) oder im Bottom-up-Verfahren
(von der untersten Ebene bis Ebene 1) erarbeiten.

Die Betriebswirtschaft neigt zum Top-down-Verfahren. Wenn dann die IT-gestützten Prozesse zu-
geordnet werden, kann es passieren, dass sich die IT nicht mehr richtig wiederfindet bzw.
Probleme bekommt, ihre Sicht auf Prozesse abzubilden, und diese letztendlich nicht akzeptiert.
Ein Top-down-Verfahren birgt einen hohen Vorlaufaufwand, bevor man das Ergebnis nutzbringend
(value-driven) anwenden kann. Deshalb wird empfohlen, auch die IT bei der Erarbeitung der
Prozessstruktur einzubinden.

Eine Möglichkeit, schnellen Nutzen zu erreichen, ist das Bottom-up-Verfahren, wenn es sich auf
IT-Prozesse stützt. Für die SAP-Software gibt es Werkzeuge, die verwendeten SAP-Prozesse mit ihren
genutzten operativen Funktionen zu analysieren und darzustellen. In der Regel sind diese Prozesse
auf einer operativen Ebene und sollten die unterste Ebene einer Prozessstruktur darstellen. Bei der
Erarbeitung der oberen Prozessebenen muss man dann besonders darauf achten, was und wer die
Struktur nutzen soll. Eine Strukturierung aus reiner IT-Sicht kann zu Akzeptanzproblemen bei den
Fachbereichen führen. Eine spätere Zuordnung von nicht IT-gestützten Aktivitäten kann Einfluss auf
die Prozessstruktur haben und nachträgliche Änderungen verursachen.

Für den Aufbau einer Prozessstruktur ist es auch wichtig festzulegen, wer denn die Verantwortung für
die Prozesse übernehmen wird. Aus IT-Sicht mag die Verantwortung entlang der IT-Zuständigkeiten
(Einführung neuer Prozesse, Änderung bestehender Prozesse) richtig sein, die in der Regel so
37

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
organisiert ist, dass man bei SAP auch entsprechende Zuständigkeiten identifizieren kann.
Betriebswirtschaftliche Prozessvarianten können hier eher als störend angesehen werden. Eine
betriebswirtschaftliche Sicht ist im modernsten Fall End-to-End orientiert, z.B. von der Kunden-
auftragserfassung bis zur Zahlung des Kunden oder von der Bestellanforderung (oder sogar
Planung) bis zur Zahlung an Lieferanten. Die betriebswirtschaftlichen Strukturanforderungen
werden sich anhand der Aufbauorganisation definieren. Ein besonderer Aspekt hierbei ist, das
Ziel von einem funktionalen zu einem prozessorientierten Unternehmen zu migrieren, wenn es
denn dem Zweck der Erreichung von Unternehmenszielen dient.

Hierbei mag es kein Entweder-oder geben. Ein Top-down-Ansatz bildet die Grundstruktur und
sollte das Verständnis des Managements für die Prozessstruktur unterstützen. Der Bottom-up-
Ansatz betrachtet die Realität und erlaubt, operative Prozesse in den unteren Ebenen darzustellen.
Damit beide Strukturphilosophien nicht kollidieren, bietet es sich an, eine Ebene dazwischenzu-
ziehen, die die Varianten der operativen Prozesse aufnehmen kann, aber auch zu den oberen Ebenen
eindeutig zuordenbar ist.

Ein anderes Vorgehen ist die Pain-Point-Methode, die im Rahmen einer Prozessänderung erlaubt,
den Prozess ganzheitlich zu dokumentieren. So kommt man Stück für Stück auch zu seinem ganz-
heitlich beschriebenen Prozessmodell, ohne sich erst mal nur mit Dokumentation zu beschäftigen.
Ein derartig ganzheitlich dargestellter Prozess lässt bereits bei der Anforderungsdefinition durch
die Facheinheit erkennen, welche Prozessvarianten, vorgelagerten und nachgelagerten Prozesse
betroffen sind. Das erlaubt in einem späteren Schritt der IT, den Umfang der davon betroffenen
IT-Objekte zu identifizieren. Mit der gemeinsamen Darstellung manueller und IT- gestützter
Aktivitäten kann die IT ihrerseits proaktiv dazu beitragen, durch Nutzungsvorschläge den Auto-
matisierungsgrad von Prozessen zu erhöhen.

3.3 Wie werden Prozesse strukturiert?

Im zweiten Schritt ist es notwendig, sich zu fragen, wie diese Prozesse strukturiert werden.
Dabei spielen Überblicksmodelle, Prozesslandkarten sowie die Anzahl an Ebenen eine große Rolle.
Wichtig ist auch, die verschiedenen Zielgruppen der Prozessmodelle in der Prozess-
strukturierung zu berücksichtigen.

Geben Sie auf Ihre Überblicksmodelle und Prozesslandkarten acht!


Tipp Nr. 6

Prozesslandkarten und Überblicksmodelle stellen zum einen die Basis der Prozessstrukturierung
dar und sind zum anderen meist der erste Kontaktpunkt für Prozessinteressierte. Deshalb sollten
Sie sich gründlich Gedanken machen, wie diese aufgebaut sind und aber auch wie ansprechend
diese sind. Sie umfassen das komplette Unternehmen und gliedern alle relevanten Prozesse in
strategische, Kern- und unterstützende Prozesse.
38
3 Vom Unternehmensziel zum
Prozessdesign

Level 1 Prozesslandkarte

Führungsprozesse
Strategie Steuerung

Kernprozesse
Kunde Kunde

Produktbereit-
Einkauf

stellung
Anforderung Vertrieb Logistik Begeisterung
Produkt

Unterstützende Prozesse
Kunden- IT Personal Qualität Finanzen Marketing Recht Facility
Service Kommuni- Mngmt.
kation

(10) Level 1 Prozesslandkarte (Quelle: Comgroup / Wuerth Gruppe)

(11) Zusammenarbeit im BPA-Umfeld (Software AG, 2013)


39

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Definieren Sie von vornherein, wie viele Ebenen für die Modellierung
Tipp Nr. 7 benötigt werden und was die Ebenen beinhalten!

Beispiel mit möglicher Vorgehensweise:

Musterprozessstrukturen teilen auf einer Ebene 0 die Prozesse in Management-, Kern- und
Serviceprozesse ein. Ob man so eine grobe Einteilung abbilden will, hängt davon ab, inwieweit man
die Wichtigkeit von Prozessoptimierungen definieren will. Als Kernprozesse werden im Allgemeinen
die Prozesse angesehen, die die größte Wertschöpfung zum Unternehmensergebnis bzw. zur
Zielerreichung beitragen.

Ob man ein 3-, 4- oder 5-stufiges Prozessmodell benötigt, ist individuell festlegbar. Je weniger
Stufen, desto klarer das Verständnis, ist hierbei nicht gültig. Folgende Punkte sollten bei der
Strukturierung einer prozessorientierten Struktur beachtet werden:

Welche Prozessmessungen sind im Einsatz und welche Bereiche / Teile von Prozessen messen sie,
z.B. Auftragsbearbeitungszeit = von der Auftragserfassung bis zum Warenausgang. Wenn so ein
Messpunkt zur Unterstützung der Erreichung von Unternehmenszielen wichtig ist, sollte er einer
hohen Prozessebene zugeordnet werden können. Damit ist klar, dass alle Hauptprozessgruppen
auf dieser Ebene zu finden sein müssen – auch der Warenausgang.

Aus welchen Teilen besteht ein End-to-End-Prozess. Sind z. B. die Teilprozesse Transportplanung
und Transportdurchführung wichtig zur Messung der Prozessqualität, sind sie hier zu integrieren.
Als weiteres Beispiel können hier die Qualitätsprüfprozesse angeführt werden. Ansonsten können
sie auch als eigenständige End-to-End-Serviceprozesse abgebildet werden.

Will man nur IT-relevante Prozesse darstellen (20 % aller Prozesse) oder eine komplette Prozessdar-
stellung inklusive der manuellen Prozesse (80 % aller Prozesse) (Quelle: SAP AG, 2009). Wenn
z. B. der Warenausgang zum Kundenauftrag IT-gestützt durchgeführt wird und auch Bestandteil eines
Messindikators ist, sieht er über 4 Ebenen sehr seltsam in der Prozessdarstellung aus. Man hat
immer nur ein Element in den Prozessen auf allen Ebenen. Angereichert mit manuellen Aktivitäten
kann ein hochkomplexer Prozess mit mehreren Varianten auf der operativen Ebene entstehen.

Wer darüber hinaus auch seine Prozessvarianten bereits auf hoher Prozessebene darstellen möchte,
kann mit definierten Prozessvarianten eine Zusammenstellung der von der Variante genutzten
Hauptprozessteile getrennt und prozessorientiert darstellen.
40
3 Vom Unternehmensziel zum
Prozessdesign
Inhaltsbeispiel Verkaufsprozess (Order-to-Cash OTC):
Die Darstellung eines End-to-End-OTC-Prozesses beinhaltet auch die Prozessteile, die nur in
bestimmten Varianten vorkommen. Es würde das Prozessverständnis auf hoher Ebene erschwe-
ren. Varianten sind z.B. Kundenkonsignationsabwicklung, Streckengeschäft, Agentengeschäft,
Lieferplanabwicklung, Verkauf vom Lager, Kundeneinzelauftragsproduktion. Während die IT hier
nur die technischen Objekte Kundenauftrag, Lieferung, Faktura sieht, möchte die Betriebswirt-
schaft die Leistungsfähigkeit dieser Prozessvarianten messen, um ggf. strategische Entschei-
dungen zu treffen. Alternativ könnten Prozessvarianten auch in einer eigenen Ebene dargestellt
werden, was aber bei der Darstellung der Ebene darunter problematisch werden könnte, weil sich
damit das Prozessmodell immer größer auffächert.

Bei einer funktionalen Prozessdarstellung, in der die verantwortlichen Fachbereiche die jeweiligen
Grenzen / Schnittstellen für die Prozessdarstellung begrenzen, sollten auch Messindikatoren
als führende Rahmen genutzt werden. Messindikatoren, die über verschiedene Prozessbereiche
messen, sind jedoch schwer zuzuordnen, da sie eine Verantwortung haben müssen (in letzter
Konsequenz immer der CPO) und die in die Messung einfließenden Teilbereiche auf gleicher
Prozessebene zu finden sein müssen. Eine standardisierte Modellierungsphilosophie ist hierbei
unabdingbar. Ob eine rein funktionale Prozessstruktur die Anforderungen der Prozesssicht von
IT und Betriebswirtschaft erfüllen kann, muss individuell betrachtet werden.

Je nachdem, was man für Ziele und Funktionen mit einer Prozessstruktur abbilden will, wird man
unweigerlich an den Punkt kommen, sich mit der Frage zu befassen, ob die betriebswirtschaft-
lichen Anforderungen und die Anforderungen der IT in einer gemeinsamen Prozessstruktur
überhaupt abbildbar sind. Eine Lösung des Themas kann sein, sowohl eine prozessorientierte
Struktur (End-to-End) als auch eine funktionale Struktur (IT-/SAP-bezogen) aufzubauen. Damit
sichergestellt ist, dass man nicht nebeneinander her arbeitet, muss die unterste Prozessebene
gemeinsam genutzt werden. Die auf unterster, operativer Ebene abgebildeten Prozesse sind
grundsätzlich klar und bedürfen zwingend eines gemeinsamen Verständnisses von beiden Seiten.
Diese Ebene dient somit als Transmitter zwischen Betriebswirtschaft und IT. Der Aufbau der
oberen Strukturen kann dann die jeweiligen Anforderungen erfüllen.

Aufbauend auf Punkt 3.2 ist es erforderlich, die Bedeutung und Namenskonvention der benötigten
Ebenen festzulegen. Es wird empfohlen, auf der operativen Ebene eine SAP-gestützte Aktivität auf
Basis der genutzten Transaktion zu definieren. Tiefergehendes Wissen kann auch in Form von
Anwenderhandbüchern angehängt werden. Anwenderhandbücher können sicherlich mit Hilfe von
MS-Office erstellt werden. Empfehlenswert ist aber auch ein Autorentool, z.B. SAP Productivity Pak
(Ancile uPerform) oder SAP Workforce Performance Builder (Datango), mit deren Unterstützung
man weiteren Nutzen, aber auch eine Vereinfachung der Pflege (Aktualität) der Infos weniger auf-
wendig und professionell nutzen kann. Zu diesen IT-gestützten Aktivitäten können die manuellen
Aktivitäten jederzeit modelliert werden.

Wie viele Ebenen man über der operativen Ebene benötigt, hängt von der Anzahl der Varianten,
der Messpunkte und des Verständnispotenzials der Anwender ab.
41

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Ein Strukturbeispiel für ein prozessorientiertes Prozessmodell könnte so aussehen:

0. Managementprozesse

1. Marketing 1. Recht 1. Strategie 1. BPM 1. ........

0. Kernprozesse

1. Verkauf bis Zahlung

2. Angebot erstellen 2. Kundenauftrag erfassen 2. Lieferung erstellen 2. ........

3. Auftrag vom Lager 3. Lieferung Inland


3. Auftrag für Produktion 3. Lieferung EU27
3. Auftrag für Strecke 3. Lieferung Europa
3. Auftrag für Retoure 3. Lieferung Übersee
3. ........ 3. ........

1. Bestellung bis Zahlung

1. ........

0. Servieprozesse

1. Instandhaltung 1. Bestandsverwaltung 1. Stammdatenmanagement 1. ........

(12) Strukturbeispiel Prozessmodell (Quelle: DSAG AK BPM, 2013)

Verbinden Sie die Modelle untereinander und schaffen Sie unterschiedliche


Tipp Nr. 8
Sichten auf die Prozesse, z.B. eine End-to-End-Sicht!

Ein End-to-End-Prozess sollte durchgängig vom Anfang bis zum Ende auf jeder Prozessmodell-
ebene durchlaufbar sein. Durch die starke Vereinfachung der Prozesse auf den Ebenen 1 und 2 kann
auf eine sichtbare Verbindung verzichtet werden, da hier der Prozess auf einem „Blatt“ (Bildschirm)
darstellbar sein sollte. Lediglich die Anordnung der Symbole zeigt einen ungefähren Ablauf.

Spätestens ab Ebene 3, die die Prozesse der Ebene 4 beinhaltet, sollte die Darstellung mit einer
normierten Modellierungssprache erfolgen. Die Wahl der Modellierungssprache weist die
Möglichkeiten von Verbindungen auf. Trotzdem sollte man sich überlegen, wie in einem komplexen
Prozessmodell die Verknüpfung einfach lesbar dargestellt werden kann.
42
3 Vom Unternehmensziel zum
Prozessdesign
Basierend auf der Entscheidung zur Nutzung von Prozessmodellen, bieten sich funktionale und
prozessorientierte Strukturen an. Funktionale Strukturen sind sinnvoll, um eine Schnittstelle zur
IT zu knüpfen. Dabei sind mit IT alle relevanten Objekte gemeint, die die IT nutzt, um den Prozess
oder die Aktivität im SAP-System auszuführen. Im SAP Solution Manager hat man bereits die
Möglichkeit, eine technische Dokumentation aufzubauen. Aber auch die Zuordnung von Prozesszu-
ständigkeiten ist im Sinne eines funktionsorientiert aufgebauten Unternehmens sehr gut möglich.
Prozessorientierte Prozessmodelle (End-to-End-Prozesse) bieten eine gute Basis für die Prozess-
messung, wenn man Korrelationen von Messergebnissen analysieren will, und für die Strukturierung
von SAP-Systemtestfällen, bei denen in der Regel ein ganzheitlicher Prozess getestet wird
(Integrationstest).

Aber auch die Zuordnung von abhängigen vor- und nachgelagerten Prozessen hilft, bei Prozess-
änderungen eine Zuordnung der betroffenen Funktionen einfach zu ermöglichen und im Rahmen
der Realisierung gemeinsam umzusetzen (Freigaben, Tests, weitere notwendige Änderungen).
Neben einer Prozesslandkarte für das komplette Unternehmen können Sichten für organisatorische
Einheiten angeboten werden, z.B. Zentraleinheiten, Abteilungen.

Der Zugriff auf diese Sichten kann über Objektattribute an Prozess, Prozessgruppe oder Aktivität
umgesetzt werden.

Schauen Sie sich Ihre Prozesszielgruppen genau an und definieren


Tipp Nr. 9
Sie Ihre Anforderungen, Interessen und Zugriffsarten!

Im Unternehmen gibt es unterschiedliche Zielgruppen für modellierte Geschäftsprozesse. Diese


unterscheiden sich sowohl fachlich als auch in der Hierarchieebene.

Je höher in der Hierarchie, also Richtung Managementebene, desto mehr Überblicksinformationen


sind gefragt. Für das Management sind eher Prozesscockpits und -landkarten relevant, die mit
Verbindung zu den unteren Ebenen grafisch sehr anspruchsvoll ausgestaltet werden können.

Je tiefer man in der Hierarchie geht, umso wichtiger werden Details. Das bedeutet, dass in Ihrem
BPMA-Tool die Möglichkeit vorhanden sein soll, unterschiedliche Modellebenen und Sichten
anzubieten.

Die wichtigsten Aspekte für die Präsentation von Prozessmodellen sind:

>> Schneller Zugriff und Antwortzeiten


>> Ausschließlich aktueller Inhalt
>> Verständliches Design
>> Einfache Bedienbarkeit
43

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
(13) ERPOne Project (Quelle : Deutsche Telekom AG)

Bei der Auswahl der Präsentationsoberfläche sollten die späteren Nutzergruppen bereits ein-
bezogen werden. Dazu gehört auch die IT-Abteilung, die die Anwendung später technisch betreuen
soll. Die Anwendung muss in die IT-Landschaft einfach integrierbar sein.

Es wäre eine Katastrophe, wenn man viel Zeit und Mühe in die Modellierung der Prozesse steckt,
und keiner will sie nutzen.

Sicherlich möchte man sehr viele Informationen in ein Prozessmodell stecken (siehe auch
Attribute der Prozessmodelle bzw. Artefakte eines Modells), um den Prozess als Informationsmit-
telpunkt im Unternehmen positionieren zu können. Wenn man eine Präsentationsoberfläche
einsetzt, in der die gewünschten Informationen vom Anwender informationsbedarfsgerecht
selektiert werden können, kann man damit sehr viel Komplexität reduzieren.

Tatsächlich ist es auch ein Thema, ob man ein Prozessmodell vertikal oder horizontal angezeigt
bekommt. Im besten Fall gibt es auf der Präsentationsoberfläche eine Funktion, mit der der Nutzer
die Anzeigerichtung beliebig umschalten kann.

Auch das Vergrößern oder Verkleinern von Prozessmodellen ist eine beliebte Anforderung. Manche
Präsentationsoberflächen benutzen auch ein kleines Orientierungsfenster. Nur sollte das Fenster
dann keine Inhalte verdecken.

Die Akzeptanz der Inhalte einer Prozesspräsentationsoberfläche steht und fällt mit deren
Bedienbarkeit. Legen Sie viel Wert auf diese Funktion.
44
3 Vom Unternehmensziel zum
Prozessdesign
Etablieren Sie eine BPM-Organisation,
Tipp Nr. 10
um die BPM-Ziele zu erreichen!

Je nach Unternehmensgröße besteht der Bedarf, die Verantwortung für exzellente Prozesse und
deren Durchführung sicherzustellen, zu definieren und in einer zentralen eigenständigen
BPM-Organisation umzusetzen. Vor dem Hintergrund, dass der Anteil der IT-gestützten Prozesse
eines Unternehmens nach Aussage von SAP durchschnittlich 20 % aller Prozesse abdeckt, ist zu
entscheiden, inwieweit die betriebswirtschaftliche und die IT-Verantwortung gemeinsam oder
getrennt etabliert werden. Entscheidend dafür ist die Zielsetzung für das BPM.

Grundsätzlich soll die operative Verantwortung für optimale Prozessdurchführungen immer in den
Fachabteilungen liegen. Hier liegt auch die Verantwortung für die Ziele, die mit den Prozessen
erreicht werden sollen. Je komplexer eine Unternehmensgruppe mit einer zentralen IT strukturiert
ist, desto mehr Verantwortungshierarchien sind einzubeziehen.

Beispiel: Standort, Gesellschaft, Region, Global. Dazu macht es Sinn, die Prozesse nach globalen,
regionalen oder lokalen Bedeutungen, bezogen auf Standardisierung und Harmonisierung,
einzuordnen, um die Verantwortungsstrukturen so zu verteilen, wie es für den Unternehmenserfolg
am meisten Sinn macht. Damit definieren sich die am höchsten priorisierten Kernprozesse
darüber, inwieweit sie für das gesamte Unternehmen und seinen Erfolg bedeutsam sind.

Weiterführende Informationen im Kapitel 2.

3.4 Wie werden Prozesse dargestellt und welche


Informationen beinhalten diese?
Es ist wichtig, von vornherein auf eine durchgängige Modellierungsmethodik zu achten, sodass die
modellierten Geschäftsprozesse sich auch im Sinne einer Unternehmensstrategie wiederfinden
und verlinken lassen. Darüber ist eine gemeinsame Sprache die Grundlage eines gemeinsamen
„Corporate-Verständnisses“.

Hierbei spielen Notationen und Standards eine wichtige Rolle, denn diese reduzieren den Aufwand
(z.B. Training) und ermöglichen den Austausch mit weiteren Tools.
45

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Erstellen Sie ein Konventionen-Handbuch. Es ist das Fundament
Tipp Nr. 11
Ihrer Business-Process-Modellierung!

Konventionen, Methodik und Standards sind die Grundlage für die Projektarbeit und stellen sicher,
dass jeder im Projekt die gleiche Prozesssprache spricht. Die Festlegung der Konventionen und die
Erstellung des Handbuchs erfolgten am Anfang der BPM-Initiative in Abhängigkeit von den Zielen
und daraus resultierenden Erwartungen der Nutzergruppen.

Beispiel einer groben Strukturierung des Inhalts eines BPM-Konventionen-Handbuchs:


>> Ziele
>> Prozess-Governance
>> BPM-Rollen, Zuständigkeiten und Verantwortungen
>> Versionierung
>> Statuskonzept
>> Prozessverantwortung
>> Betriebswirtschaftliche / IT-technische Verantwortung der Prozess-Excellence
>> Prozessstruktur (Ebenenkonzept)
>> Modellierungsvorgaben
>> Modellierungssprache und ihre Ausprägung / Nutzung
>> Prozessnavigation
>> Prozessstammdaten (Attribute)
>> Und vieles mehr …

Beispiele für solche Prozessstammdaten / Attribute sind:


>> RACI-Daten, z.B. Geschäftsfunktionen, Fachabteilungen, BPM-Rollen, IT-Rollen
>> SAP-IT-Objekte, z.B. Systeme, Transaktionen, Reports
>> SAP-Input-/-Output-Daten, z.B. Nachrichten, Datenobjekte, Partnerrollen
>> Gültigkeit der Anwendung, z.B. Gesellschaften, Unternehmensbereiche, zentrale
Fachabteilungen
>> GRC-Regeln
>> Links zu Anwenderhandbüchern und Trainingsmaterialien
>> Messdaten KPI, PPI

Attribute können auch aus den SAP-Tabellen ermittelt werden, z.B. Transaktionen, Dokumente,
Tabellen. Diese können ins BPMA-System zur weiteren Nutzung importiert werden. Bei der Er-
hebung der individuell genutzten SAP-Funktionen kann die Reverse Business Process Documentation
des SAP Solution Managers (siehe auch SAP Solution Manager Leitfaden, Kapitel 3.16) oder
entsprechende Werkzeuge von externen Anbietern unterstützen.
46
3 Vom Unternehmensziel zum
Prozessdesign
Entscheiden Sie sich für eine Notation,
Tipp Nr. 12
Ihren Zielen entsprechend!

Die Festlegung auf eine Notation zur Prozessmodellierung darf keine Frage des Geschmacks und
Verständnisses sein. Gerade hier gilt es, die aufwendig erarbeiteten Inhalte zu schützen, auch
gegen zukünftige mögliche Werkzeugänderungen. Dabei gilt, dass nicht das Werkzeug (BPMA-Tool)
die Hauptkosten verursacht, sondern der vom Nutzer erarbeitete Inhalt. Die Wahl einer proprie-
tären Modellierungssprache bedeutet, für immer und ewig mit dem anbietenden Werkzeugher-
steller verheiratet zu sein. Oder darauf zu warten, dass andere Hersteller Migrationswerkzeuge
anbieten oder individuell zur Verfügung stellen.

Je nach Situation kann es auch notwendig sein, mehrere Notationen gleichzeitig in einem BPM-Werk-
zeug parallel laufen zu lassen. So können z.B. BPMN 2.0 und EPK (Ergebnisgesteuerte Prozessketten)
ihre gleichzeitige Daseinsberechtigung haben. Hierbei ist es wichtig, darauf zu achten, dass die
Modelle nicht doppelt gepflegt werden müssen, sondern automatisch „transformiert“ werden.

In den letzten Jahren hat sich weltweit die Modellierungssprache BPMN den Weg geebnet, eine
globale Standardsprache für eine Prozessmodellierung zu sein. Mit dem Versprechen, die einmal
in BPMN erstellten Prozessmodelle zwischen unterschiedlichen Systemen portieren zu können,
wird dem Nutzer eine große Flexibilität geöffnet. Wer erst einmal mit einem preiswerten Werkzeug
erste Schritte im BPMA machen möchte, würde zukünftig seine Inhalte in ein anderes mächtigeres
Werkzeug übertragen können. Das bedeutet Investitionsschutz. Mit BPMN 2.0 wurde eine Version
zur Verfügung gestellt, auf deren Basis die BPMA Hersteller genormte Schnittstellen zur Ver-
fügung stellen können. Dies ist vor allem in Hinsicht auf Austausch mit weiteren Systemen, z.B.
SAP NetWeaver BPM, wichtig, denn nur so können auch alle Daten im Zielsystem richtig und voll-
ständig ankommen.

Achtung Falle!
Jedoch wird BPMN oft als eine Sprache dargestellt, die zu technisch bzw. IT-lastig
ist. Sie würde vom Business nicht wirklich verstanden werden (oder nur mit einer
intensiven Ausbildung). Sicherlich bietet BPMN durch die Verfügbarkeit von vielen
Modellierungsobjekten die Möglichkeit, Prozesse derart technisch darzustellen, dass
sie als Vorgabe für eine IT-Realisierung dienen können. Für betriebswirtschaftliche
Prozessmodelle sollte deshalb nur eine begrenzte Anzahl von Objekten genutzt
werden. Empfohlen wird, hierbei nicht mehr als 10 verschiedene Artefakte zu nutzen,
z.B. Start, Ende, Prozess, IT-Aktivität, manuelle Aktivität, Verzweigung.

Die EPK-Notation des Produkts ARIS ist eine in Deutschland sehr verbreitete
Modellierungsmethode. Die integrativen Schnittstellen in den SAP Solution Manager
versprechen einen schnellen und hohen Mehrwert für ein ganzheitliches BPM
unter dem Gesichtspunkt der Integration von Business und IT.
47

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Ein Prozessmodell soll grundsätzlich einfach zu verstehen und in der Anzeige auf
dem Bildschirm nachvollziehbar sein. Die Prozessmodelltapeten der 90er-Jahre sind
unbedingt zu vermeiden. Eine Möglichkeit, das zu erreichen, kann über zusätzliche
Informationen als Attribute an Prozessen und Aktivitäten umgesetzt werden. Der-
artige Attribute können als BPM-Stammdaten in einer Stammdatenbibliothek
hinterlegt werden und an alle BPM-Objekte angehängt werden, wo sie vorkommen.
Das vermeidet eine Explosion von individuellen Zusatzinformationen und unterstützt
die Änderung und Austauschbarkeit. Dazu wird das Objekt einmal als Stammdatum
geändert und erscheint derart geändert in allen Prozessmodellen, wo es angehängt ist.

Ein Prozessmodell auf der untersten Ebene sollte nicht mehr als 15 Modellierungs-
objekte beinhalten, um die Übersichtlichkeit des Prozessmodells zu gewährleisten.
Hat man dennoch Anforderungen an eine größere Detailtiefe, kann hier auch mit Sub-
prozessen gearbeitet werden. Subprozesse beschreiben genau eine Aktivität. Sie be-
ginnen und enden im Rahmen der beschriebenen Aktivität. Bei komplexen Trans-
aktionen, deren Datenerfassung betriebswirtschaftliche Varianten darstellt, bietet sich
der Subprozess an, ohne damit grundsätzlich das Prozessmodell um weitere Ebenen
zu ergänzen, z.B. bei der Transaktion VA01 „Kundenauftrag anlegen“. Um eine aus-
ufernde Kaskade von Subprozessen zu beschränken (heimliche Erweiterung der
Hierarchieebenen), sollte man die Anzahl von Subprozessebenen im Modellierungs-
handbuch begrenzen, wenn möglich auch BPMA-systemtechnisch.

Machen Sie sich nicht nur über Modellierungssprachen, sondern



Tipp Nr. 13 auch über „echte“ Sprachen Gedanken!

In welchen Sprachen wollen bzw. müssen Sie die Prozessmodelle anbieten, damit jeder diese auch
versteht und akzeptiert?

Insgesamt ist es wichtig, für die Akzeptanz der Prozesse bei den Endusern die Landessprache zu
verwenden, es gibt aber Ausnahmen (z.B. SAP, wo sich Englisch durchgesetzt hat!) und hängt von
der Strategie des Unternehmens ab.

3.5 Prozessverwaltung: Wie und wo werden Prozesse


verwaltet?

Es ist grundsätzlich zu empfehlen, die für die Prozessdarstellung notwendigen Objekte in einer
Datenbank zu verwalten, um die Wiederverwendung sicherzustellen. Die Benutzung eines „nur
Zeichentools“ sollte vermieden werden, da die Verwaltung der Prozesse und Objekte hier nach
kurzer Zeit nicht mehr effektiv möglich ist.
48
3 Vom Unternehmensziel zum
Prozessdesign
Untersuchen Sie Ihre Prozesslandschaft und definieren Sie, welche

Tipp Nr. 14
BPM-Systeme an Prozessen interessiert sind!

Mit Prozessverwaltung und / oder -management können sich mehrere Systeme in einem Unterneh-
men beschäftigen. Zum Beispiel sind häufig Systeme für das BPM, Change Request Management,
Governance, Risk and Compliance Management, Projektportfoliomanagement, GITP/GMP/FDA
Management, Knowledge Management, Business Workflow etc. zu finden. Ziel sollte es sein, immer
die gleiche Prozessstruktur zu verwenden.

Die Fachprozesse sollten in einem BPMA-Tool führend modelliert und verwaltet werden. Dabei ist
es wichtig, die Implementierungs- / Durchführungsebene zu betrachten, z.B. in der SAP Suite oder
über SAP NetWeaver BPM oder auch über Non-SAP-Lösungen.

Definieren Sie, wie Sie Ihre Prozessstruktur im SAP Solution Manager


Tipp Nr. 15
abbilden und / oder synchronisieren können!

Je nachdem, welche Ziele mit dem Prozessmodell verknüpft werden, mag die Funktionalität des
SAP Solution Managers mit seinen 3 Modellebenen ausreichend sein. Der Solution Manager
verfügt bereits heute über eine grafische BPMN-Modellierungsoberfläche (BPB = Business Process
Blueprinting), die auf Basis der im SAP Solution Manager vorhandenen Daten eine nutzerfreund-
liche Darstellung der Prozesse zulässt. Diese Modelle stellen eine zentrale Ablage von allen
Dokumentationen von der Prozessanforderung bis hin zur Konfiguration dar, mit der Möglichkeit
der Verknüpfung zu SAP-Prozess- und -Funktionstestverwaltung, Change Request Verfahren,
Incident Management, Verknüpfung mit Wissensdatenbanken bis hin zur Abwicklung ganzer SAP-
Projekte. Werkzeuge wie der Solution Document Assistant bieten Unterstützung bei der Gestaltung
einer SAP-bezogenen, funktional individualisierten (genutzte Prozesse und Funktionen / Transaktionen)
Prozesshierarchie. Der SAP Solution Manager ist somit auch direkte Schnittstelle zu den realen
Systemen der IT, und ergänzt um das Business Process Monitoring steht hier auch eine Funktion
zur Verfügung, mit der man die Qualität der Prozessdurchführung anhand von Geschäftsvorfall-
daten in der SAP Suite messen kann. Um diese hohe Integration nutzbringend zu verwenden, ist es
sinnvoll, eine Kombination aus SAP-bezogener Prozesshierarchie und End-to-End-Szenarien zu
benutzen. Um darüber hinaus ein ganzheitliches Bild des Geschäftsprozesses zu erhalten, ist eine
Integration in ein BPMA-Tool (Business Process Modelling and Analysis) sinnvoll. In diesem können
zusätzlich zur IT-Sicht z.B. manuelle Tätigkeiten in der Sprache des Business modelliert werden.
Um Redundanzen zu vermeiden, sollte man sich klar werden, welche Modellebene die Schnittstelle
darstellt, die in beiden Strukturen gleich abgebildet sein muss. Das unterstützt die Zuordnung von
IT zur Betriebswirtschaft. Es bietet sich an, Ihre Prozessstruktur im BPMA-Tool zu nummerieren.
Somit haben Sie auch die Möglichkeit, diese Struktur in den SAP Solution Manager zu übertragen.

Eine weitere Verfeinerung kann über Kundenattribute (Keywords) vorgenommen werden (SAP
Solution Manager Leitfaden Absatz 3.7.4.). Eine Übertragung von Attributen aus dem BPMA-Tool
in den SAP Solution Manager ist sinnvoll, aber von der technischen Möglichkeit des eingesetzten
BPMA-Tools abhängig.
49

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Unterscheiden Sie technische und betriebswirtschaftliche Prozesse.
Tipp Nr. 16
Definieren Sie, wo und wie Sie diese verwalten wollen!

Mittlerweile bietet SAP verschiedenste Werkzeuge zur Abbildung, Verwaltung und Realisierung
von BPM-Anforderungen an. Der Schwerpunkt dieser Werkzeuge liegt dabei vorrangig auf der
Schnittstelle zur IT oder sie dienen als reines IT-Werkzeug.

Entscheidet man sich für die Philosophie, dass alles, was die IT betrifft, nicht in betriebswirtschaft-
lichen Prozessmodellen abgebildet wird, so findet man mit den SAP-Werkzeugen grundsätzlich
umfassende und ausreichende Lösungen. Hier können betriebswirtschaftliche Prozesse im BPMA-
Tool abgebildet werden. Eine Überführung in den SAP Solution Manager ermöglicht die Nutzung
des SAP-Solution-Manager-Projektmanagements und -Change-Request-Managements sowie
eine erste Darstellung der relevanten technischen Objekte in den Transaktionen. Insbesondere
ist das Thema Testen funktions- und / oder prozessabhängig (Funktionstest, Integrationstest).
Um nicht zwei verschiedene Testfälle aufbauen zu müssen, ist die Entscheidung, wie man testet,
maßgeblich dafür, mit welcher Philosophie Prozesse im SAP Solution Manager abgebildet
werden, siehe Kapitel 5 (siehe auch DSAG SAP Solution Managerleitfaden, Kapitel 3.9,
www.dsag.de/go/SolMan1.1).

Über eine standardisierte Schnittstelle BPMN 2.0 können Prozesse, die als Workflow realisiert
werden sollen, in das BPM-System (BPMS) SAP NetWeaver BPM übertragen werden (Anmerkung:
Import funktioniert für Drittanbieter-Tools, die den Standard unterstützen, sowie für die SAP-Tools,
z.B. SAP Sybase PowerDesigner und das Collaborative-Process-Modelling-Werkzeug in SAP
Streamworks). SAP NetWeaver BPM ist ein BPM-System und dient zur Modellierung, Ausführung
und zum Betrieb von Composite-Applikationen und Prozessautomatisierungen (Workflows). Das
Werkzeug hat eine Modellierungskomponente, den Process Composer, der in der Fülle an
BPMN-Modellierungsobjekten seinen Einsatz findet. Vor dem Hintergrund, Prozesse möglichst ein-
fach darzustellen und dass die Anforderung vom Business kommt, kann man sich vorstellen, auch
im BPMA ein einfaches Prozessmodell als Anforderungsunterstützung zu modellieren, es ins BPMS
SAP NetWeaver BPM zu überführen und als Vorlage zur IT-technischen Ergänzung zu nutzen. Siehe
hierzu auch Kapitel 6.

Bleibt die Frage, ob es Sinn macht, in einem BPMA-System ein prozessorientiertes End-to-End-
Prozessmodell und ein funktionsorientiertes Prozessmodell abzubilden, um im SAP Solution
Manager noch einmal ein funktionsorientiertes Prozessmodell aufzubauen. Die Antwort ist unter-
nehmensindividuell und abhängig davon, wofür das Business das funktionsorientierte Prozess-
modell benötigt, z.B. zur Übersetzung der Begriffe des Business in SAP-Begrifflichkeiten, zur
Nutzung für GRC-Audits, zum Management von Prozessänderungen auf Seite des Business, zur
ganzheitlichen Abbildung einer Messpunktstruktur mit der Möglichkeit von Ursachenanalysen
durch logische Verknüpfung der Messpunkte über alle Prozessmodellebenen hinweg.
50
3 Vom Unternehmensziel zum
Prozessdesign
Entscheiden Sie, wie Sie Ihre dokumentierten

Tipp Nr. 17
Prozesse aktuell halten!

Prozessmodelle müssen verteilt und aktuell gehalten werden. Die Anpassung des Prozessmodells
ist eine grundlegende Anforderung bei organisatorischen und IT-Prozessänderungen.

Etablieren Sie eine Prozess-Governance! Diese stellt Konsistenz und Aktualität der Prozess-
modelle sicher. Dabei sollten folgende Beispiele als Rahmenbedingungen definiert werden:

>> Einheitlicher Standard zur Prozessmodellierung und Prozessdokumentation


(wie sieht eine Prozessdokumentation aus, was beinhaltet sie)
>> Einheitliches System zur Dokumentation der Prozesse und einheitliche Nutzung der
Modellierungssprache
>> Prozessmodelle werden in regelmäßigen, vorher bekannten Zyklen aktualisiert
(z.B. einmal im Quartal, nach Produktivstart der Funktion oder des Prozesses)
>> Änderungen an Prozessmodellen auf den Ebenen, die nicht die operativen Prozesse
abbilden und die das gesamte Unternehmen betreffen, sind nur nach Rücksprache und
Genehmigung mit einem „Prozesskomitee“ möglich.
>> Legen Sie einen Prozess-Lifecycle fest.
>> „Projektportfoliomanagement“ = welche Projekte betreffen welche Prozesse?
Welche Änderungen und Verbesserungen werden erwartet?
>> Prozessänderungen sollten im Change-Request-Prozess berücksichtigt werden, z.B. in Form
von Prozessmodelländerungen, Anpassungen bei Prozess- / Aktivitätsartefakten (zusätzliche
Informationen als Text oder BPM-Bauelement im Rahmen der Modellierungsstammdaten). Im
besten Fall geht keine IT-Änderung produktiv, die nicht vorher abschließend im Prozessmodell
modelliert und freigegeben wurde. Nur so ist es strukturiert möglich, den Aufwand zur Aktua-
lisierung eines Prozessmodells gering zu halten, diese zeitnah umzusetzen und eine gewisse
Art Investitionsschutz zu bewahren. In der Regel fordert dazu das Business auch ein Vorgehens-
modell für Prozessänderungen an, das über den Prozessmodellstatus, der entlang des Prozess-
lebenszyklus definiert ist, abgebildet werden kann. Zum Beispiel Prozessänderung im Entwurf,
als betriebswirtschaftliche Anforderung, als genehmigte betriebswirtschaftliche Anforderung,
an IT übergeben, in Entwicklung, im Test, Schulungsunterlagen erstellt und ergänzt, produktiv.
Da die meisten Change-Request-Unterstützungswerkzeuge erst bei der Übergabe einer
Anforderung an die IT anfangen, wird heute nicht der gesamte Prozess über alle Prozessbetei-
ligten unterstützt. Ein BPMA-Werkzeug bietet sich an, um den betriebswirtschaftlichen Teil
abbilden zu können.
>> Im Rahmen von Change Requests, die Prozesse verändern, wird empfohlen, die Prozessände-
rung bereits im Prozessmodell darzustellen. Damit so ein To-Be-Modell nicht gleich in die
Anzeige für Nutzer kommt, ist das Arbeiten mit Versionen und Status erforderlich. Der Status
des Entwicklungsgrads eines Prozessmodells bis hin zur Integration der unterstützenden
SAP-Funktionen kann beliebig, je nach Ablauforganisation, für einen Change Request definiert
werden. Jedoch sollte ein Status definiert werden, der das Prozessmodell zur Publikation
bringt und somit die vorherige Version gegen diese neueste Version austauscht. Dadurch könnte
der betriebswirtschaftliche Teil einer Prozessänderung dokumentiert werden. Wird die
Änderung aus anderen Gründen nicht realisiert, hat man letztlich eine Entwurfsversion, die später
dazu genutzt werden könnte, ähnliche Änderungsanforderungen kurzfristig auf Machbarkeit hin
bewerten zu können, ohne die IT wieder einzubinden.
51

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
3.6 Exkurs: BPMA-Toolauswahl

Die BPM-Toolauswahl eines BPMA-Systems stellt insofern eine Herausforderung dar, weil man im
besten Fall bereits zu diesem Zeitpunkt wissen sollte, was man mit dem BPMA in der Endausbau-
stufe machen möchte. Wenn das zu diesem Zeitpunkt noch nicht klar ist, hat man zwei Optionen:

Nur Anbieter in die Evaluierung nehmen, die einen modularen Ausbau des BPMA-Systems erlauben,
womit die Kosten jeweils auf den Zeitpunkt gelegt werden können, wenn man das neue Modul benötigt.

Nur Anbieter in die Evaluierung nehmen, die die Prozessmodellierung mit einer Modellierungs-
sprache erlauben, die zwischen unterschiedlichen Systemen migriert werden kann. Derzeit soll
dies nur mit der Modellierungssprache BPMN funktionieren. Die Hersteller von BPMA-Systemen
haben das bereits mehr oder weniger erfolgreich umgesetzt. Der Gedankenansatz baut auf der
Tatsache auf, dass die Erstellung des Inhalts einer BPMA, also das Prozessmodell, eine höhere
Investition darstellt, als die Anschaffung eines IT-Werkzeugs. Um die Migrationsfähigkeit der
Prozessmodelle zu garantieren, darf man als Nutzer nicht in die technische Beschreibung der Modell-
ierungsobjekte eingreifen. Die zeichnerische Darstellung soll nicht dazu gehören. Ein migriertes
Objekt soll im neuen System so dargestellt werden, wie es dort grafisch definiert wurde. Leider
finden sich noch keine Aussagen zu allen anderen Daten, die z. B. als Attribute an den Prozessmo-
dellobjekten hängen, z.B. Input/Output, RACI, IT-System, Transaktion etc. Die Nutzung der
proprietären Modellierungssprache EPK ist auch populär. Hierbei sollte man beachten, dass diese
Prozessmodelle nur über eine Transformation in BPMN in andere BPM-Tools übernommen
werden können.

Zusätzlich zur Beschreibung funktionaler Anforderungen muss die IT ihre IT-Spezifikationen dar-
stellen, damit so ein neues System in die bestehende Systemlandschaft integriert werden kann.
Anforderungen an Schnittstellen zu SAP Solution Manager, Autorentool, Intranet-Umgebung, ggf.
HR-System / Active Directory sollten daher Eingang in die Anforderungsbeschreibung finden. Im
besten Fall kann man auch schon definieren, welche Art von Daten die Schnittstellen abdecken
sollen und was mit ihnen geschehen soll. Da kann dann auch so manche externe Schnittstelle zum
SAP Solution Manager nicht mehr den Anforderungen genügen.

Mit SAP-Produkten können heute folgende BPMA-Funktionen unterstützt werden:


>> SAP Solution Manager (siehe auch DSAG-Solution-Manager-Leitfaden)
> Prozessstruktur = Abbildung hierarchische textuelle Prozessstruktur, inklusive. vieler
technischer Daten
> Business Process Monitoring (BPMon) = unterstützt zum einen die technische Stabilität
von Geschäftsprozessen (z.B. Überwachung von Schnittstellen und Hintergrundjobs) und
zum anderen ermöglicht BPMon die Sicherstellung eines „guten“ Status quo, der ggf.
durch Verbesserungsaktivitäten mit Business Process Analytics erreicht wurde
> Business Process Analytics = erlaubt die Ursachenforschung von Prozessschwachstellen,
die auf IT- und/oder Fachabteilungsseite liegen können, z.B. Fehlkonfigurationen eines
SAP-Systems, schlechte Stammdatenqualität, falsche Nutzung des SAP-Systems, unvoll
ständiges Prozessdesign innerhalb des SAP-Systems, betriebswirtschaftliche Ausnahmen,
die zu einer Liefer- / Fakturasperre führen
52
3 Vom Unternehmensziel zum
Prozessdesign
> Reverse Business Process Documentation – Solution Document Assistent = Analyse der
genutzten SAP-Prozesse und Funktionen
> Business Process Change Analyzer = Analyse der technischen Objekte, die von
Transaktionen genutzt werden
> Business Process Blueprint = BPMN-Modellierungstool für den SAP Solution Manager
> SAP ChaRM (in Teilen, die eine Änderung der Prozessstruktur beinhalten) = SAP Change
Request Management
> SAP Test Workbench (in Teilen, die die Integration von Funktionen und Business-
Szenarien beinhalten) = Testen von SAP-Prozessen bei Neueinführung und Änderung
> SAP RBE Plus Supplementaries = erweiterte Nutzungsanalysen
> SAP Process Observer = prozessorientierte Analyse / Messung von Process Performance
> SAP Sybase Power Designer (vorrangig für Enterprise Architecture Management, wird
weiter für die Betriebswirtschaft ausgebaut und hat eine Schnittstelle zum SAP Solution
Manager)

Weitere BPMA-Werkzeuge und Anbieter werden z. B. von folgenden Quellen aufgeführt:

Das führende Research-Institut Gartner gibt jedes Jahr einen neuen Magic Quadrant for Business
Process Analysis Tools heraus. Des Weiteren bietet das Fraunhofer-Institut für Arbeitswissenschaft
und Organisation (IAO) in Stuttgart Studien zu dem Thema an:

Marktstudie mit Werkzeugbegutachtung: „Business Process Modeling 2010„


http://www.iao.fraunhofer.de/lang-de/geschaeftsfelder/informations-und-
kommunikationstechnik/557-business-process-modeling.html,

Werkzeugübersicht „Business Process Management Tools 2011„


https://shop.iao.fraunhofer.de/details.php?id=489

Übersicht: Die Standardisierungsorganisation Object Management Group (OMG) für BPMN listet
unter http://www.bpmn.org/ – „Implementers“ Werkzeuganbieter auf, die BPMN unterstützen.
DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
53
54
4 Prozessanalyse und
Prozessoptimierung
4.1 Einführung

Ein Prozessmodell folgt der Philosophie, wie man es überwachen möchte. Will man keine Analytik
anhand von Prozessmodellen durchführen, macht es Sinn, darüber nachzudenken, wie komplex
und tiefgehend das Prozessmodell sein muss. Für eine reine Dokumentation reicht ein einfaches
Prozessmodell aus, an dem man relevante Informationen und Beschreibungen, z.B. in Form von
Dateien, anhängen kann. Die Nutzung eines BPMA Werkzeugs darf für eine ausschließliche Doku-
mentation in Frage gestellt werden, weil eigentlich zu aufwendig und zu teuer. Wer sich die Analytik
optional für eine spätere Nutzung bewahren will, muss darauf achten, dass die Prozessmodelle
entsprechend der hierfür notwendigen Anforderungen angelegt werden, weil man die Anforderungen
einer Analytik von vornherein nicht beachtet hatte. Die Gefahr eines dann hohen Änderungsaufwands
ist möglich und kann die Motivation dafür einschränken.

4.1.1 Motivation für Prozessanalyse

>> Iteratives Verbessern von Prozessen durch Kontrollieren und Optimieren.


>> Bei der Optimierung von Prozessen kann in der Praxis grundsätzlich zwischen zwei verschiedenen
Verfahren unterschieden werden. Zum einen das „Business Process Reengineering”, das die
radikale Neugestaltung von Prozessen von Grund auf betrachtet, und zum anderen der Ansatz
der „Kontinuierlichen Verbesserungsprozesse“, die sich von der japanischen Qualitätsmanage-
mentmethode „Kaizen“ ableitet.
>> Grundlage des in diesem Leitfaden betrachteten Lifecycle ist der Ansatz der kontinuierlichen
(iterativen) Verbesserung von Prozessen.
>> Für die Analyse gilt, nicht nur ein Problem in einem Prozess zu erkennen, sondern auch die
Ursache für ein Problem finden zu können. Durch die hohe Integration von End-to-End-
Prozessen mag ein Problem, z.B. in der Kundenfaktura, seine Ursache bereits bei der Kunden-
auftragserfassung haben. Der Anspruch an die Analytik sollte somit für betriebswirtschaftliche
Analysen von der Fachabteilung definiert werden, um auch falsch implementierte und falsch
gelebte Prozesse identifizieren zu können. Technische Zwischenschritte, z.B. IDOC-Verarbeitung,
Batch-Input, müssen von der IT vorgegeben werden.
>> Das Prozessmodell muss den real implementierten Prozess abbilden und nicht einen Wunsch-
prozess. Wird ein Prozessproblem erkannt, das zur Änderung eines Prozesses führt, wird erst
nach Umsetzung das neue Prozessmodell veröffentlicht und ggf. mit neuen Messpunkten
wiederum kontrolliert.

4.1.2 Anteil der Prozessanalyse und -optimierung an den verschiedenen Phasen


des Lebenszyklus

Im Folgenden werden die verschiedenen Tätigkeiten und Schritte, die zur Prozessanalyse
und -optimierung durchgeführt werden, anhand des Lifecycle zugeordnet.
55

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
PPI-Struktur

Messpunkte identifizieren für


Prozessleistungsmessung Ziel PPIs
Messpunkte und Zielwerte definieren
Prozessziele für Prozessleistungsmessung
Gewünschtes Prozess-
Reporting definieren
Geschäftsziele
As-is-PPIs Resultate für To-be-
sgovernance Alternativen abschätzen
Prozes
Prozessanforderung
Daten der
n g
Prozessleistungs- ieru Des
ign
tim &
messung Op e
ss
analysieren M
&

od
e
se
oz

e ll
Pr
ly
bte

ieru
Ana

Organisation
gele

g n

Menschen
Ausfü

Technologien
To-be-PPIs
hr u

l
odel
Gesc

ng
ng

ru

Alternative A
&

sm

on t
ie

en
häf

ito
lem
ft

rin
Prozessqualität Imp
tse

g Alternative B
sc
rfo

berichten
Ge
lg

Proz g
essverantwortun

Prozessleistungsmessung
und Prozess-Reporting
implementieren
Prozess messen und
Erreichte PPIs überwachen

(14) Tätigkeiten und Schritte zur Prozessanalyse und -optimierung (Quelle: © SAP AG, 2012)

>> Startpunkt / Eintritt in den Lebenszyklus


> Entgegen der Darstellung im Lebenszyklusdiagramm ist der Startpunkt nicht immer der
Eintritt in einen neuen Prozess. In vielen Fällen ist der Prozess bereits vorhanden und
wird gelebt. Meistens soll dieser manuelle Prozess einer IT-gestützten Ausführung
zugeführt werden.
>> Design und Modellierung (erste Iteration)
> In der ersten Iteration des Prozesslebenszyklus werden in der Design-Phase die Schritte
der Prozesserhebung und des Prozessdesigns durchgeführt. Im Anschluss an das
Prozessdesign geht es um die Definition von Kennzahlen und Indikatoren, anhand derer
während und nach der Durchführung von Prozessinstanzen ermittelt werden kann,
inwieweit der Prozess den betriebswirtschaftlichen Nutzen erbringt, für den er aufge-
nommen wurde.
56
4 Prozessanalyse und
Prozessoptimierung
>> Implementierung
> In der Implementierungsphase geht es darum, die Messpunkte für die zu erfassenden
Indikatoren im Prozessmodell entsprechend zu realisieren.
>> Ausführung / Monitoring
> In der Ausführung / Monitoring-Phase geht es darum, die Messwerte an den vorab
definierten Messpunkten entsprechend aufzunehmen.
> Bei der Messung kann unterschieden werden zwischen einer Messung zu einem
bestimmten Zeitpunkt oder in einem bestimmten Zeitraum (Historie).
>> Analyse und Optimierung
> In der Analysephase geht es um die Bewertung eines Prozesses anhand von Kennzahlen.
> Ergebnisse der Analysephase fließen in die Prozessoptimierung ein.

>> Bei den Analyseverfahren kann unterschieden werden zwischen IT-gestützter Analyse
(automatische Erhebung von Kennzahlen) und nicht IT-gestützter Analyse (durch Workshops,
Interviews, Fragebogen oder Laufzettel). In vorliegendem Leitfaden stehen die IT-gestützten
Analyseverfahren im Mittelpunkt.
>> In der Analysephase des Lebenszyklus geht es um das Auswerten von Kennzahlen und das
Ziehen der richtigen Schlüsse aus den Ergebnissen. Diese Ergebnisse sind Grundlage für die
Prozessoptimierung in der nachfolgenden Phase.

Sobald der Lebenszyklus einmal durchlaufen wurde, beginnt die Phase der Prozessoptimierung. In
der Designphase werden, abhängig von der Iteration, in welcher der Kreislauf durchlaufen wird, die
folgenden Aufgaben durchgeführt:

>> Design und Modellierung (zweite und nachfolgende Iteration).


> Sobald der Lebenszyklus einmal durchlaufen wurde, kann, auf Basis der definierten
Kennzahlen und der zur Laufzeit erhobenen Messwerte, der Schritt Prozessoptimierung
durchgeführt werden.
> Neben dem zutage getretenen Optimierungspotenzial der einzelnen Prozessschritte muss
immer auch eine Nutzenanalyse durchgeführt werden, in der die Sinnhaftigkeit und Wirt-
schaftlichkeit der durchzuführenden Optimierung betrachtet werden muss.
> Die Designphase in der zweiten Iteration dient auch zur Dokumentation der
Veränderungen am Prozessmodell.

4.2 MessgröSSen und Indikatoren

Die Messergebnisse liefern Fakten, wo eine Prozessoptimierung sinnvoll notwendig ist und ob eine
Investition einen Nutzen bringt. Sie stellen aber auch dar, ob eine Realisierung den Nutzen erfüllt
oder ob zusätzliche Maßnahmen zur richtigen Nutzung und damit zum Schutz der Investition
benötigt werden. Aber auch für die Entscheidung, ob die Nutzung des SAP-Standards möglich ist
oder eine Eigenprogrammierung sinnvoller ist, sind Messergebnisse, die ungenutzte Potenziale
aufweisen, eine große Unterstützung.

Wie im Einleitungskapitel bereits ersichtlich wurde, spielen Indikatoren eine zentrale Rolle bei der
Analyse und Optimierung von Prozessen.

Nur anhand von messbaren Indikatoren können verlässliche Ergebnisse gewonnen werden, um
Prozesse in einem iterativen Vorgehen zu optimieren, um somit den Nutzen für das Unternehmen
(Business Benefit) zu erhöhen.
57

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
4.2.1 Performance-Indikatoren

In der Literatur und in der Praxis können die folgenden Indikatoren und deren Abhängigkeiten
unterschieden werden:
>> Kritische Erfolgsfaktoren (Critical Success Factors – CSF)
>> Leistungskennzahlen (Key Performance Indicators – KPI)
>> Prozess-Leistungskennzahlen (Process Performance Indicators – PPI)
Non Fin

Relation of PQI to management levels


Relation of KPI to management levels

KPI
Kosten
Fin
Non Fin

PPI
Qualität Zeit

(15) Performance-Indikatoren (Quelle: SAP AG ©, 2008)

Die Unterscheidung von Messkennzahlen in KPI (Key Performance Indicator) und PPI (Process
Performance Indicator) stellt keine getrennte oder andere Art der Messung dar. Während KPIs so
definiert werden, dass man mit einer überschaubaren Zahl von Messindikatoren einen ganzheitlichen
Blick über seine Geschäftsprozesse bezogen auf die Unternehmensziele bekommt, spezifizieren
sich PPIs als zu- und untergeordnete Messpunkte zum KPI, die zum Ziel haben, möglichst genau an
einer Stelle der vom KPI betroffenen Prozesse ein Problem oder sogar eine Ursache zu erkennen.
Setzt man PPIs entlang der Prozesshierarchie ein, werden sie automatisch mit den KPIs auf dem
oder den oberen Prozessmodellebenen sachlich verknüpft. Damit ist eine Ursachenanalyse möglich.

Ein PPI stellt dar, mit wie viel Aufwand ein KPI erfüllt werden kann

KPI

PCI PTI
Kosten Zeit

PQI

Qualität
(16) Zusammenhang PPI und KPI (Quelle: SAP AG ©, 2008)
58
4 Prozessanalyse und
Prozessoptimierung
Kritische Erfolgsfaktoren (Critical Success Factors – CSF)
In den administrativen Fachabteilungen eines Unternehmens ist die Definition von kosten- und
zeitgeprägten Indikatoren eine Herausforderung. Nicht jede Erfassung z.B. eines Kundenauftrags
(Inland – Lkw bis Übersee – Linienschiff) mag die gleiche Zeit in Anspruch nehmen. Welche
Aktivitäten muss man rund um die reine Erfassung in SAP zeitlich darüber hinaus berücksichtigen?

Welcher Kostensatz wird für die Arbeit eines Mitarbeiters für die Berechnung herangezogen?
Gibt es eine Mischkalkulation?

PPI können mit KPI in einer N:N-Verbindung stehen. Ist ein KPI über die Optimierung eines
PPI zu verbessern, kann es zu Problemen mit einem anderen KPI kommen.

Leistungskennzahlen (Key Performance Indicator – KPI)


KPIs sind die Maßeinheit, anhand derer Erfolgsfaktoren quantifiziert und gemessen werden
können. KPIs sind langfristig orientiert. Die Definition eines spezifischen KPI und was durch diesen
KPI ausgedrückt bzw. gemessen wird, ändert sich selten, da ansonsten auch die Aussagekraft in
Bezug auf vorangegangene Messungen verloren geht.

Die Ziele einer Organisation, die durch KPIs quantifiziert und gemessen werden, können sich je
nach Strategie der Organisation ändern.

KPIs repräsentieren Unternehmensziele, die auf einem strategischen Level erreicht werden sollen.
Sie sind qualitative (Effizienz, Effektivität) oder quantitative (EBIT) Bestandsaufnahmen der
Unternehmensleistung bezüglich der Unternehmensziele.

Strategische KPIs: Messungen zur Kontrolle strategischer Unternehmensziele. Diese Messpunkte


basieren grundsätzlich auf Daten des Jahresberichts, z.B. Umsatz, Gewinn, Personalstand,
Liquidität, Forderungen, Verbindlichkeiten.

Operative KPIs: Messungen betriebswirtschaftlicher Kennzahlen aus dem operativen Geschäft,


differenziert nach
>> Leistungsqualität, z.B. Lieferfähigkeit, Lieferzuverlässigkeit, Produktfehlergrad
>> Kosten, z.B. Logistikkosten, Frachtkosten, Lagerhaltungskosten, Gemeinkosten,
Produktionskosten
>> Kapital, z.B. Kapitalbindung (Bestände), Kapitalrückflusszeit, Umschlaghäufigkeit

Prozessleistungskennzahlen (Process Performance Indicator – PPI)


PPIs repräsentieren operative Prozessziele, die ein Unternehmen auf der Prozessebene erreichen
will. Sie quantifizieren die Leistung entlang eines Prozesses mit den Dimensionen Zeit, Kosten und
Qualität. PPIs sind direkt messbar durch Daten, die im Prozess auf der Aktivitätenebene erhoben
wurden.
59

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Sie werden von Prozesseignern oder BPM-Rollen, z.B. dem Prozessauditor genutzt, um die
Prozesse kontinuierlich zu prüfen und bei Bedarf Optimierungen einzuleiten.

PPIs werden KPIs zugeordnet, die auf Basis von Prozesseffizienz- und -effektivitätsmessungen
definiert sind.
>> Prozessqualität = PPQ, z.B. zu früh gezahlte Rechnungen, zu spät gebuchte Warenausgänge,
Anzahl Änderungen, offene Geschäftsvorfälle
>> Prozess-Compliance, z.B. wie viele Bestellungen werden mit / ohne Bezug zu geplanten
Bestellanforderungen angelegt, inwieweit werden in der Fertigung geplante Mengen
und Daten eingehalten
>> Prozessdurchlaufzeit = PPT, z.B. Auftragsdurchlaufzeit, Auftragsbearbeitungszeit,
Bestelldurchlaufzeit, Wiederbeschaffungszeit, Lagerungszeit
>> Prozesskosten = PPC, z.B. Herstellkosten, Auftragsbearbeitungskosten
>> Kosten sind jedoch nur insoweit messbar, wie eine Aktivität oder ein Prozess eindeutig den
Kosten zugeordnet werden kann.
>> Prozessautomatisierung, z.B. wie viele Bestellanforderungen werden manuell vs. automatisch
angelegt

4.2.2 Anwendung von betriebswirtschaftlichen Messindikatoren

Der Nutzen (Benefit), mit Messindikatoren zu arbeiten, liegt nicht nur allein darin, welche zu
haben, sondern auch darin, Ursachen zu finden. Je gröber ein Messpunkt definiert ist, desto mehr
Aufwand macht es, die Fehlerquelle bzw. den Grund der Nichterreichung eines vorgegebenen
Messwerts zu identifizieren. Idealerweise kann man die Ursache gleich aus der Ergebnisliste der
jeweiligen Kennzahl direkt ablesen. So ist es bei ausgewählten Kennzahlen im BP Analytics &
BPMon im SAP Solution Manager bereits der Fall, z.B. warum können Lieferungen oder Fakturen
nicht erstellt werden? Warum werden Fakturen nicht an die Buchhaltung übergeben?

Um eine sachliche Verbindung von Messwerten herzustellen, ist die Beschreibung jedes einzelnen
Messwerts hilfreich. Dazu können Parameter beitragen, wie z. B.:

>> Eindeutiger Name des Messpunktes, ggf. wird durch eine Nummer die Zuordnung
zur Prozessebene sichtbar gemacht.
>> Betriebswirtschaftliche Beschreibung mit Ziel und Sinn.
>> Interpretierende Hinweise, auf welche Probleme der Messpunkt hinweisen kann.
>> Formel des Messpunktes mit SAP-Tabellen, -Felder, -Feldwerte, Richtig- / Falsch-Definition
>> Maßeinheit des Ergebnisses, z.B. Stunden, Anzahl, Stück, Währungswert
>> Relevanz (Gültigkeit) bezogen auf die Organisationsstruktur des Unternehmens. Bei
diversifizierten Unternehmen mag nicht jeder Messpunkt für alle Gesellschaften oder
Unternehmensbereiche gelten.
60
4 Prozessanalyse und
Prozessoptimierung
Wurden die Messpunkte auf den verschiedenen Ebenen der Prozessstruktur verteilt, läuft eine
mögliche Ursachenanalyse wie folgt ab:

Ebene 1 Operativer Einkauf

Ebene 2 Bestellanforderungen für die Produktion

Ebene 3 Bestellanforderungen, Variante automatisch generiert

Ebene 4 Aktivität „Bestellanforderung absagen“


Messpunkt: offene Bestellanforderung mit Löschvormerkung
Schwellwert: 1.000 Stück im Jahr
Messwert: 30.000 Stück im Jahr

Mögliche Ursachen: Falsche Planung, hoher Grad an Produktionsneuplanung wegen Kundenbe-


stellverhalten, Produktionsanlagenausfall.

>> Systemgestützte Datenanalyse für Identifizierung, in welcher Organisationseinheit das Problem


vorkommt (unter Nutzung der SAP-Organisationsstruktur).
>> Maßnahme: Analysegespräch mit betroffener Organisationseinheit unter Nutzung der
Messzahlen.
>> Ergebnis: In diesem Fall war es ein Fehler in der Schnittstelle zwischen SAP APO und SAP ERP,
wo bei APO-Neuplanungen die an ERP weitergegebenen Bestellanforderungen nur mit einer
Löschvormerkung versehen wurden, aber nicht wirklich gelöscht wurden (wie man es vom
MRP-Lauf im ERP gewohnt ist).

Hinweis:
>> Die Festlegung und Definition der Unternehmensvision, der zu deren Erreichung notwendigen
(kritischen) Erfolgsfaktoren und der sich daraus abzuleitenden KPIs ist ein sehr komplexer und
vielschichtiger Prozess, der in diesem Leitfaden nicht weiter betrachtet wird.
>> In diesem Leitfaden wird betrachtet, wie KPI und PPI in den Prozessen realisiert und deren
Werte erhoben werden können.

4.2.3 Anwendung von technischen Messindikatoren

Neben betriebswirtschaftlichen Messpunkten sind technisch basierte Messpunkte bei SAP-gestützten


Prozessen auch ein wichtiger Maßstab für die Prozessqualität. Um Mitarbeiter bei gleichen, immer
wiederkehrenden Aktivitäten durch Systemautomatismen zu entlasten, müssen mit zunehmendem
Maße jene auch überwacht werden. Letztendlich übernimmt kein SAP-System die Verantwortung
für einen optimal laufenden Prozess. Es ist immer der Anforderer (der Mensch, die Fachabteilung)
für eine fehlerfreie, systemgestützte Bearbeitung verantwortlich. Hat die IT einen Prozess technisch
einwandfrei implementiert, können trotzdem Datenfehler zu technischen Abbrüchen in der Ver-
arbeitung führen. Rein technische Fehler können dann nur bei Änderungen oder Ausfall des
technischen Umfelds vorkommen.
61

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
IT-technische Effizienz- und Effektivitätsmessungen vervollkommnen die Überwachung von
datenbasierten Prozessschritten, z.B. IDOC-Verarbeitungsfehler, Batchlauf-Abbrüche, Dumps.
Eine Fehleranalyse muss immer mit der Fachabteilung zusammen durchgeführt werden, um die
Ursache, wenn nicht rein technischer Natur, zu identifizieren.

Aber auch allgemeine, technisch basierte Messindikatoren können helfen, Kosten zu reduzieren.
Aktive bzw. inaktive Anwender wirken sich auf die Lizenzkosten aus. Nicht genutzte Eigenentwick-
lungen (Y-, Z-Programme und Reports) müssen zu der Überlegung führen, ob die Anwendung
zwischenzeitlich vergessen wurde oder sie nicht mehr zur aktuellen Prozessunterstützung beiträgt.
Da bei Systemänderungen, z.B. Einspielung von SAP EHP (SAP Enhancement Packages),
Aktivierung zusätzlicher Lösungen, Systemintegrationen, der vorhandene Inhalt auf fehlerfreie
Lauffähigkeit geprüft und getestet werden muss, erhöhen ungenutzte Inhalte den Aufwand und die
Kosten dafür. Auch das Wissen um vorhandene Lösungen in seinen SAP-Systemen hilft, so manche
Anforderung mit SAP-Standardprozessen und -funktionen zu lösen, anstatt zu programmieren.

4.2.4 Anwendung von Messindikatoren für Stammdaten

Gut und richtig gepflegte Stammdaten sind das Geheimnis einfacher Prozesse. Alles, was man nur
einmal in Stammdaten definieren muss, wird automatisch den Prozessen zur Nutzung gegeben
und muss nicht bei jedem Geschäftsvorfall erneut erfasst werden. Grund genug, die Qualität seiner
Stammdaten in SAP ständig zu überwachen. SAP bietet hierzu insbesondere für globale Stammdaten,
also Stammdaten, die eine Vielzahl von Prozessen bedienen, z.B. Materialstamm, Kundenstamm,
Lieferentenstamm, Bankendaten, Personalstamm, eine Reihe von Überwachungscockpits an,
deren regelmäßige Anwendung zu einer wirkungsvollen Aufrechterhaltung der Stammdatenquali-
tät führen. So können unlogische Dateninhalte im Materialstamm, z.B. Beschaffungstyp ist Fremd-
beschaffung, aber eine Fertigungsversion ist gepflegt, identifiziert und behoben werden. Auch die
Dublettenprüfung in den Partnerdaten gehört dazu. Hier aber Vorsicht – so manch eine Prozess-
nutzung benötigt Dubletten, z.B. Lieferantenstamm für Einkauf und Lieferantenstamm für Um-
lagerung muss getrennt sein, auch wenn es derselbe Partner ist.

Letztendlich will man ja auch mal Stammdaten archivieren, wenn alle Belege archiviert sind. Sitzt
wirklich überall die Löschvormerkung?

4.3 Prozessanalyse

Die Prozessanalyse, mit der möglichen Prozessoptimierung als Ergebnis, ist eine der nutzenbrin-
gendsten Funktionen einer Prozessstruktur. Allein durch die Positionierung der Messpunkte in der
Prozessstruktur bekommt man automatisch eine logische Verknüpfung der Messpunkte in der
Prozesshierarchie. Ursache-Wirkungsanalysen sollten damit Top-down oder Bottom-up einfach
möglich sein. Das kann besonders dann ohne Probleme realisiert werden, wenn sich die Messpunkte
auf den jeweiligen Prozessebenen im Rahmen ihres Prozessmessbereichs, z.B. von der Auftrags-
erfassung bis zum Warenausgang, wiederfinden.
62
4 Prozessanalyse und
Prozessoptimierung
Da sich Messpunkte an den Unternehmenszielen ausrichten, bekommt man Ziel und Nutzen eines
BPM in das operative Bewusstsein. Genauso wie es eine Zielpyramide gibt (strategische, operative
und prozessuale Ziele), sollte die Prozessstruktur mit ihrer Messpunktpyramide die jeweilige Ziel-
erreichung messen. Mit Änderung der Unternehmensziele sollte immer eine Prüfung der Mess-
punkte einhergehen, inwieweit diese die Erreichung der Ziele noch abbilden. Auf operativer
Prozessebene bedeutet das, dass eine Prozessänderung auch eine Prüfung der vorhandenen Mess-
punkte beinhaltet und bei Bedarf neue Messpunkte entstehen, entfallen oder sich ändern. Diese
Aktivität integriert man am besten in den Prozesslebenszyklus im Rahmen der Konzeption und
auch der begleitenden Prozessmodellierung. Dabei spielt es keine Rolle, ob der Prozess in der SAP
Business Suite oder als Workflow im SAP NetWeaver BPM implementiert ist.

4.3.1 Einordnung der Prozessanalyse

Grundlage für die Prozessanalyse sind die zur Laufzeit (Monitoring) der Prozessinstanzen
erhobenen Messwerte (KPIs und PPIs) und auch historische Messwerte (Reporting) sowie durch
Trendanalysen (Prediction) gewonnene Messwerte.

Reporting Monitoring Prediction

Prozessanalyse

(17) Prozessanalyse und ihre Eingangsgrößen (Quelle: CDI Concepts Development Integration AG, 2012)

Monitoring:
>> Unter Monitoring wird die systematische Erfassung von KPI und PPI zur Laufzeit der Prozessin-
stanzen (Real Time) verstanden (Phase Ausführung / Monitoring im Lifecycle-Diagramm).
>> Zur transparenten und verdichteten Darstellung der KPI und PPI auf Managementebene
können Dashboards verwendet werden.
>> Dashboards sollten so gestaltet sein, dass ein schneller Wechsel der Dimension der dargestell-
ten Informationen wie auch ein Drill-down in bestimmte Bereiche ermöglicht wird.
>> Die in der Phase Monitoring (Lifecycle-Diagramm) aufgenommenen bzw. gewonnenen Daten und
Messwerte können sowohl für Reporting als auch für Prozessanalysetätigkeiten verwendet werden.
63

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Reporting:
>> Beim Reporting werden entscheidungsrelevante Informationen (in der Regel mehrdimensional)
über einen bestimmten Zeitraum hin betrachtet, verdichtet und hinsichtlich bestimmter
Aspekte hin ausgewertet, um Rückschlüsse und Maßnahmen daraus abzuleiten.
Trend (Prediction):
>> Die Disziplin Prediction versucht auf Basis von historischen und Echtzeitdaten, Vorhersagen
(Trends) und Entscheidungen zu treffen, um schon zur Laufzeit der Prozessinstanz die
Ausführung des Prozesses zu optimieren.
Prozessanalyse:
>> Die Prozessanalyse bietet, im Gegensatz zum Reporting, die Möglichkeit, den Grund für das
Erreichen oder Verfehlen eines bestimmten PPI zu analysieren (durch Drill-down bis auf
Task-Ebene einer bestimmten Prozessinstanz). Hierdurch ist es möglich, Schwachstellen
(Bottle Necks) im Prozessablauf zu identifizieren.

4.3.2 Methode

Eine Prozessanalytik auf Basis einer Messpunkthierarchie ist insofern nur sinnvoll einsetzbar, wie
sie die ggf. individualisierten Prozesse des Unternehmens messen kann. Damit einerseits nicht
ständig eine Änderung der Messstruktur vorgenommen wird, aber andererseits auch Problempunkte
im Prozess identifiziert werden können, muss strategisch entschieden werden, wann ein neuer
Prozessmesspunkt aufgenommen oder ein bestehender angepasst werden darf. Grundsätzlich macht
es auch Sinn, einen Prozess oder Prozessschritt identifizieren zu können, ohne direkt abzulesen,
was das genaue Problem ist. Allein das Ergebnis, einen Hinweis auf ein Problem zu haben, kann für
ein tiefergehendes und nicht zu ersetzendes Analysegespräch in einer betroffenen Abteilung der Aus-
gangspunkt sein. Auch bei der Definition von Messpunkten sollte der Kosten-Nutzen-Ansatz
beachtet werden.

4.3.3 Prozessanalyse bei Suite-basierten Prozessen

Durch eine sich ausweitende Nutzung der SAP-Systeme zur optimalen Unterstützung der Prozesse
wird sich ein Prozessmodell auch in unterschiedlichen SAP- und Non-SAP-Systemen wiederfinden.
Durch geeignete Attribute an Prozessen und Aktivitäten kann man leicht das unterstützende System
zuordnen, z.B. ERP, APO, CRM, GTS u.v.m. Mit der Zuordnung eines Messpunktes ist damit auch
klar, wo er realisiert werden muss und seine Daten selektiert. Ein zentrales, systemübergreifendes
IT-Werkzeug, wie der SAP Solution Manager mit seinem Business Process Monitoring, sammelt
die Daten aus allen Systemen und kann sie in Bezug zum Prozess darstellen, auch mit Nutzung
des Business Warehouse (Business Process Analytics). Hierfür werden bereits vordefinierte
Messkennzahlen von SAP mitgeliefert.

Da alle Systeme auch ausgewählte Daten direkt ins Business Warehouse (BW) abspeichern können,
könnte man alternativ den SAP Solution Manager umgehen und sich Messpunkte aus eigenen
Datenauswertungen dort installieren. Vorteil ist, dass diese Daten für einen längeren Zeitraum zur
Verfügung stehen und die Daten in den jeweiligen SAP-Systemen zeitnah archiviert werden können.
Dieser Vorteil macht sich insbesondere für zeitgestützte Prozessqualitätsvergleiche bemerkbar,
wenn sie denn über einen Zeitraum mehrerer Jahre sinnvoll sind. Aufgrund der Tatsache, dass solche
Entwicklungen im Business Warehouse aufwendig sind, sollte man diese Methode nur bei Bedarf
für eine übersichtliche Anzahl von KPIs wählen. Für die Abbildung von PPIs, deren Anzahl oft
64
4 Prozessanalyse und
Prozessoptimierung
vierstellig werden kann, ist der Aufwand häufig zu groß. Der Nutzen einer reinen Verwendung des
Business Warehouse (BW) ist heutzutage vor dem Hintergrund der Bereitstellung von Business
Process Analytics im Solution Manager mit seinem integrierten BW zu prüfen. Jedoch ist insbe-
sondere die Ursachenanalyse in einem reinen BW-Szenario aufwendig. Das BW erlaubt im Gegen-
satz zu BP Analytics keine Vorwärtsnavigation in den einzelnen problematischen Beleg. Um die
oben beschriebenen Kennzahlen, die eine direkte Ursachenanalyse erlauben, im BW nachzubauen,
müssten technische Protokollbelege ins BW repliziert werden und dort aufwendig mit betriebswirt-
schaftlichen Daten abgemischt werden. Dies ist ein nicht zu vertretender Aufwand, wenn Analytics
den Content out-of-the-box und ohne zusätzliche Lizenzkosten anbietet.

Grundsätzlich ist zu bewerten, wie flexibel man mit den Messkennzahlen umgehen muss. Eine
häufige Änderung bringt neben den oben bereits beschriebenen Problemen auch hohe Umsetzungs-
kosten und ein zeitbasierter Vergleich von Messkennzahlen wird schwierig. Eine Idee dazu ist, die
regelmäßige Messung von Prozessen mit Hilfe eines stabilen Messsystems zu unterstützen,
während die Messung für neu implementierte Prozesse und Funktionen, die darauf abzielt, ob das
Neue erfolgreich umgesetzt wurde (Stichwort: Investitionsschutz), in einem anderen Umfeld erfolgt.
Eine spätere Festlegung, zur Aufnahme solcher temporärer Messindikatoren in die allgemeine
Messlandschaft kann bei Bedarf in Form von Versionen umgesetzt werden.

SAP bietet verschiedene Werkzeuge, um eine Prozessanalyse durchzuführen:

SAP Solution Manager:


>> Der SAP Solution Manager bietet mit seinem Business Process Analytics und Business Process
Monitoring sowohl eine technische als auch betriebswirtschaftliche Vor-Definition von
Messindikatoren (über 800 vordefiniert verfügbar) für einen schnellen Einstieg. Individuelle
Messpunkte können zusätzlich programmiert werden.
>> Die Messungen sind objektorientiert und können nicht über eine End-to-End-Prozesshierarchie
kumuliert betrachtet werden. Probleme mit Prozessobjekten können einfach identifiziert
werden. Eine Ursachenanalyse über hierarchisch verbundene Messpunkte, auf Basis von
Instanzen, ist nicht möglich.
>> Die Messungen lesen über die gesamte Datenbank. Auswertungen längerer Zeiträume
dauern entsprechend lange. Um einen Abbruch zu vermeiden, können sie als Hintergrundjob
eingeplant werden. Als eine Ad-hoc-Nutzung zur Messung möglicher Schwachstellen, die im
Betrieb aufgefallen sind, ist das Business Process Monitoring gut geeignet.

Business Process Analytics:


>> Um unterschiedliche Organisationseinheiten oder Prozessvarianten miteinander zu vergleichen,
kann das Business Process Analytics genutzt werden. Dabei werden Datensammler im
angeschlossenen SAP Business Suite System ausgeführt. Die Ergebnislisten werden lokal
gespeichert (d.h., es werden nicht wie im SAP BW transaktionale Daten repliziert) und der SAP
Solution Manager empfängt lediglich die aggregierten Ergebnisse, entsprechend der vorher
definierten Merkmalskombinationen.
>> Neben der Funktionalität des Benchmarkings (also des visuellen Vergleichs von Organisations-
einheiten oder Prozessvarianten) bietet das Business Process Analytics auch zwei zeitbasierte
Auswertungen. Zum einen kann über die Age „Analysis“ eine Altersstrukturanalyse der
gefundenen Belege durchgeführt werden, d.h., wie viele der Ergebnisbelege beziehen sich auf
das Jahr 2013, 2012,...,1999!? Hiermit können alte Belege von operativ relevanten Belegen
65

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
getrennt werden. Zum anderen ermöglicht dann die Trendanalyse einen Ergebnis-verlauf der
letzten Monate, d.h., inwieweit verändert sich die Situation positiv/negativ!?
>> Über gesonderte Abfragen im BW kann eine Verbindung verschiedener Kennzahlen zu
prozessorientierten Auswertungen führen.
>> Die Daten, die für das Business Process Analytics gesammelt wurden, können auch für das
Business Process Monitoring genutzt werden. Somit sind keine redundanten Datensammlungen
notwendig. Dieser Mechanismus ist im Übrigen auch für Kunden interessant, die ausschließlich
am Monitoring interessiert sind. Sollen z.B. 10 (von 50) unterschiedlichen Werken überwacht
werden, dann müsste BPMon 10-mal konfiguriert werden und es würden 10 Datensammlungen
auf dem SAP ERP System stattfinden. Stattdessen könnte man mit Business Process Analytics
lediglich einmal Daten für alle 50 Werke sammeln und das BPMon würden dann 10-mal Daten
aus dem Analytics Info Cube abfragen.

>> Hinweis: Für die Nutzung von Business Process Analytics ist SAP Enterprise Support notwendig.
Business Process Monitoring kann auch im SAP Standard Support genutzt werden.

Process Observer:
>> Dieses Tool basiert auf der Philosophie, über Messungen Prozesse sichtbar zu machen.
Sichtbar werden Prozesse, indem man sie ausführt.
>> Der Process Observer ist ein Prozessanalyse Werkzeug, das direkt in den SAP-Business-Suite-
Systemen installiert ist. Über die SAP-Standardwartung ist die Nutzung abgedeckt. Prozesse
werden über bereits in den Transaktionen eingebauten Ereignissen gemessen. Es stehen ca.
7.000 Ereignisse zur Verfügung, die aktiviert werden können. Bei Ausführung einer Transaktion
werden die in den Ereignissen vordefinierten Daten verarbeitet und in die Tabellen des Process
Observers geschrieben. Anwendungen und Prozesse können um eigene Ereignisse erweitert
werden. Zur Analyse können die Tabelleninhalte auch ins BW geladen und dort nach zusätzlichen
Dimensionen, z.B. Organisationsstrukturelementen (Werk, Verkaufsorganisation), ausgewertet
werden. Auch im Process Analyzer des Solution Managers und Operational Process Intelligence
(OPInt) können die Daten verwenden werden und so stehen deren Analysemöglichkeiten zur
Verfügung.
>> Der Process Observer arbeitet entlang der realen operativen Nutzung in den SAP Business
Suite Systemen. Der Fachabteilung bleibt der kritische Erfolgsfaktor, zu definieren, wie sie
ihren Prozess „sehen“ will und welche Anforderungen sie an die KPI / PPI hat.
>> Über Side Panels (im SAP NetWeaver Business Client) und im Prozess-Monitor ist es möglich,
eine grafische Darstellung des Prozesses anzuzeigen. Zumindest wird hier grafisch
angezeigt, wo der Geschäftsvorfall im Prozess gerade steht. Wer sich zur Erreichung seiner
Ziele nicht mit einer aufwendigen Prozessmodellierung auseinandersetzen muss und die
Analytik in den Vordergrund stellt, bzw. dort den größten Nutzen sieht, mag mit diesem
Werkzeug über eine ausreichende Funktionalität verfügen, wenn es nur um das ERP-System
der Business Suite geht.

Operative Szenarien in SAP Business Objects:


>> Mit der Integration von SAP Business Objects in das SAP Business Warehouse werden auch
operative Messindikatoren, z.B. für das Supply Chain Management, vordefiniert mitgeliefert.
Hierzu wurde das SCOR-Modell als Grundlage genommen und die Messkennzahlen der Ebenen
1 bis 3 hierarchisch abgebildet. Etwa 400 Messkennzahlen stehen zur Verfügung, die Effektivität
der SCM-Prozesse zu analysieren.
66
4 Prozessanalyse und
Prozessoptimierung
SAP Operational Process Intelligence powered by HANA:
>> Seit HANA als technische Lösung für eine neue Datenbanktechnik in der SAP-Software integriert
ist, bieten sich auch für die Prozessanalytik neue Techniken an. SAP Operational Process
Intelligence misst Geschäftsprozesse über die gesamte Business Suite, SAP Business Workflow,
SAP NetWeaver BPM und SAP NetWeaver Process Integration instanzengesteuert. Damit ist
es auch möglich, Prozessanalysen über Korrelationen einzelner Instanzen durchzuführen, die mit
Fremdsystemen und Non-SAP-operationalen Daten integriert sind. Dank der HANA-Technik
sind auch große Datenmengen in kürzester Zeit auswertbar. Damit werden die Laufzeiten der
Analyseprogramme dramatisch verkürzt, sodass auch eine Betrachtung der Prozessdaten
über einen längeren Zeitraum keine Systemprobleme verursachen sollte. Die Lösung richtet sich
an Mitarbeiter der Fachabteilung und Prozessverantwortliche, die auf Instanzebene Prozesse in
Phasen und Milestones, auf der Basis von kontextspezifischen Kennzahlen und Indikatoren in
Echtzeit beobachten wollen, um auf der Grundlage von Benachrichtigungen in laufende Prozesse
eingreifen zu können. Dazu verfügt das System über die Rules-und-Task-Management-Funktionalität.

(18) SAP Operational Process Intelligence (Quelle: SAP AG, 2013)

Externe Werkzeuge, z.B. ARIS PPM, RBE Plus:


>> Am Markt wird eine Vielzahl an Analysewerkzeugen angeboten, die jeweils eine gute Unterstüt-
zung bewirken, wenn sie denn auf die Messphilosophie des Unternehmens passen.
>> Wer als BPMA-Werkzeug die ARIS-Produktfamilie ausgewählt hat, wird die hohe Integration
des ARIS PPM zu schätzen wissen. Eine prozessbezogene bidirektionale Integration zum SAP
Solution Manager ist realisiert.
>> Das RBE Plus untersucht die SAP-Tabellen zeitpunktgesteuert. Zu einem gewünschten
67

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Zeitpunkt kann man einen Zeitraum definieren, um zu ermitteln, welchen Zustand Geschäfts-
vorfälle haben. Anhand von Beispielbelegen aus den SAP-Tabellen können Probleme darge-
stellt werden. Auch hier werden über eine Prozesshierarchie die Reifegrade dargestellt und
eine Ursachenanalyse ist möglich. Eine Anbindung zum BW komplettiert das zeit- und
organisationsbasierte Benchmarking. Durch die enge Zusammenarbeit des Anbieters IBIS Prof.
Thome AG mit der SAP AG sind bereits einige Funktionen in den SAP Solution Manager
aufgenommen worden. Weitere Inhalte werden optional zur Integration in den SAP Solution
Manager angeboten.

Letztendlich hängt die Nutzung eines Werkzeugs davon ab, was man wie messen will und wie es
zur BPM-Philosophie des Unternehmens passt. Auch hier gilt es bereits am Anfang der Einführung
zu überlegen, was man zukünftig noch an Anforderungen für Messungen realisieren will.

4.3.4 Prozessanalytik bei SAP NetWeaver BPM-Prozessen

Zur Prozessanalyse von SAP NetWeaver BPM-gestützten Prozessen kann das technifizierte
BPMN-Prozessmodell herangezogen werden. So können die definierten KPIs jeweils in den
vorhandenen Prozessmodellen operationalisiert und damit die PPI eindeutig an die Stellen im
Workflow zugeordnet werden. Diese identifizierten Messpunkte werden nun im Workflow-Modell
implementiert und die zusätzlich benötigten Kontextdaten zum jeweiligen Zeitpunkt herangezogen.
Falls zusätzliche fachliche Daten benötigt werden, können diese durch einen Serviceaufruf im
Vorfeld in den Prozesskontext geladen werden.

Die folgenden Daten können übermittelt werden:

>> Standarddaten (Lifecycle-Daten):


> Siehe hierzu auch „Extracting Data to SAP NetWeaver Business Warehouse“
(http://help.sap.com/saphelp_nwce72/helpdata/en/a3/92f601cc1d49c292527841a9ca76a8/content.htm)

>> Personalisierte Daten (Kontextdaten): Reporting Aktivity:


> Durch die Verwendung von Reporting-Activities und aus dem Prozesskontext verfügbare
Daten können durch grafisches Mapping aktuelle Messwerte übermittelt werden.
> Als Speicherort kann auf definierte und veröffentlichte Datenquellen im Business Warehouse
(BW) zugegriffen werden.
> Die Verwendung des folgenden Namensschemas hat sich als sinnvoll erwiesen:
<reportingDataSourcename>_<timestamp> im Format “yyMMddHHmmssSSS”
68
4 Prozessanalyse und
Prozessoptimierung
Wenn die Daten an eine spezifische Serviceschnittstelle übermittelt werden sollen (z.B. Daten-
bank außerhalb der NetWeaver BW DB), kann stattdessen auch eine Automated Activity (Tasktyp
für die systemgestützte Ausführung) verwendet werden. Dabei ist zu beachten, dass die Aktivität
selbst stets in einem zusätzlichen „unkritischen Workflow-Pfad“ eingebettet werden sollte, damit
im Falle eines technischen Fehlers der eigentliche Prozessablauf nicht beeinträchtigt wird.

Darstellung der Ergebnisse (Monitoring):

Visual Composer
Die grafische Aufbereitung der übermittelten Kennzahlenwerte (via Dashboards) kann z.B. mittels
Visual Composer realisiert werden.
BPM Analytics Dashboard

(19) Process Monitoring (Quelle: SAP AG 2010)


69

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Seit SAP NW 7.31 SP6 kann auch das standardmäßig integrierte „BPM Analytics Dashboard“
verwendet werden. Dieses kann entweder über den NWA aufgerufen oder aber über die Public
API und Custom Coding bereitgestellt und visualisiert werden.

Für weitergehende Informationen siehe:

(20) BPM Analytics Dashboard (Quelle: SAP AG 2013)

(http://help.sap.com/saphelp_nw73ehp1/helpdata/en/b3/6a34500b4942218f79b39beb3234e0/
content.htm?frameset=/en/62/3380e96b7c4472ad61d3fca50ecc47/frameset.htm)

4.4 Prozessoptimierung

Im Rahmen der Prozessoptimierung kann man grundsätzlich zwei Vorgehensweisen aus Sicht
des verantwortlichen Entscheiders, z.B. Prozess-Owner, Prozessexperte, für eine Änderung
unterscheiden.

4.4.1 Reaktive Prozessoptimierung

Die reaktive Prozessoptimierung baut darauf, dass von den operativen Organisationseinheiten
Vorschläge, Wünsche oder gesetzliche Auflagen als Änderungsanforderungen an die zuständigen
Stellen, z.B. Prozessexperten, übermittelt werden. In der Regel wird hierzu ein Change-Request-
Verfahren benutzt. Hierbei ist die Nutzung von Messergebnissen für eine Benefit-Analyse äußerst
sinnvoll, um die IT-Prozess-Änderungsanforderung den Realisierungskosten gegenüberzustellen
und diese zu bewerten.
70
4 Prozessanalyse und
Prozessoptimierung
4.4.2 Proaktive Prozessoptimierung

Die proaktive Prozessoptimierung kommt von den Prozessexperten oder der IT, die aufgrund von
Messergebnissen Optimierungspotenziale aufdecken. Diese werden zusammen mit dem
identifizierten Fachbereich besprochen und bei Bedarf ein Lösungsszenario abgestimmt. Das kann
sich zwischen Nachschulung von Anwendern bis hin zur Neugestaltung eines Prozesses erstre-
cken. Auch hierbei werden Prozessänderungen, die die IT betreffen, über ein Change-Request-
Verfahren umgesetzt. Versorgt mit derartigen Fakten können tiefergehende Analysen, systemgestützt
oder per Analysegespräch, Prozessoptimierungsprojekte einleiten. Die Nutzung weiterer Mess-
ergebnisse, wie Nutzungstiefe und -breite einer Funktion / Transaktion, kann Basis für Kosten-
Nutzen-Berechnungen sein, die wiederum Grundlage für eine Investitionsentscheidung sind. Durch
die Zuordnung der Messpunkte zur Prozessstruktur und Vernetzung der Prozesse untereinander
kann man den Umfang der Änderung auf alle betroffenen Prozesse definieren und die Änderungs-
anforderung ganzheitlich bewerten. Insbesondere bei gesetzlichen Änderungen oder aufgrund
unternehmensinterner Compliance-Richtlinien ist es erforderlich, alle betroffenen Prozesse und
Prozessmesspunkte identifizieren zu können.

Bei der proaktiven Prozessoptimierung können folgende Fragestellungen Inhalt von Analysen sein:

>> Helfen die aktiven Prozesse die Unternehmensziele zu erreichen?


>> Können gesetzliche Anforderungen mit den Prozessen abgedeckt werden?
>> Ist unsere Organisation fähig, mit den vorhandenen Prozessen zu arbeiten?
>> Wo sind die Kostentreiber?
>> Benötigen wir so viele Prozessschritte?
>> Benötigen wir so viele SAP-Transaktionsschritte?
>> Werden unsere aktiven Prozesse wie geplant bzw. konzipiert gelebt?
>> Sind die Anwender genügend geschult, um mit den Prozessen effizient zu arbeiten?
>> Sind die Stammdaten in einer so guten Qualität, dass sie unsere Prozesse aufwands-
minimierend unterstützen?
>> Sind die IT-Berechtigungen ausreichend, damit Anwender ihre Arbeit vorgabenkonform
erledigen können?

4.4.3 Internes Marketing von Prozessoptimierungsprojekten

Wo Prozessoptimierungsprojekte mit gemessenen Kennzahlen arbeiten, ist es zwingend erforderlich,


über die Messungen in den Organisationsbereichen zu informieren. Gründe sind:
>> Mitspracherecht des Betriebsrats, auch wenn nur dargestellt wird, dass keine personenbezo-
gene Leistungsmessung durchgeführt wird.
>> Mitarbeit der betroffenen Fachabteilungen bei der Definition von Messpunkten und deren
Struktur bzw. Prozesszuordnung zur Motivation, damit zu arbeiten.
>> Nutzung von Messergebnissen als Parameter zur Erfüllung von Zielen, an deren Erreichung
variable Gehaltsanteile gebunden sind.
>> Gemeinsame Festlegung von Messschwellwerten zur Festlegung, wann an einem Messpunkt
Meldungen (z.B. „gelbe bzw. rote Lampe“) erzeugt werden.
71

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Prozessoptimierungsprojekte werden in der Regel von der operativen Einheit initiiert. Eine Unter-
stützung der Initiative ist mit Hilfe von Messkennzahlen sinnvoll und kann auch Problemfelder
(Pain Points) darstellen, die der operativen Fachabteilung noch gar nicht bewusst sind. Dabei ist
der Ausgangspunkt nicht nur ein überschrittener Schwellwert. Auch internes Benchmarking
zwischen gleichartigen Gesellschaften, Unternehmensbereichen oder zeitbezogenes Benchmarking
durch Zeitpunktvergleiche der Messwerte können Initiativen für ein Prozessoptimierungsprojekt sein.

Der Zwang, etwas tun zu müssen, geht immer vom Prozesseigner (Process Owner) aus. Dieser
kann jedoch in der IT definiert sein, insbesondere wenn es sich um IT-Prozesse handelt. In diesem
Fall, wo die IT damit einen intensiven Beitrag zur Wertschöpfung des Unternehmens leisten kann,
muss definiert werden, wie ein Projektauftrag einzuleiten ist. Die IT kann den Fachabteilungen
Prozessoptimierungen als Service anbieten oder im Rahmen ihres Auftrags direkt einleiten. Der
Unterschied liegt darin, wer die Kosten der Maßnahme trägt. Beide Wege werden nicht von Erfolg
gekrönt sein, wenn das Unternehmensmanagement nicht eingebunden ist und gemeinsame Ziele
definiert hat. Hier wird lebensnah deutlich, wie notwendig es ist, eine in die Unternehmenshierarchie
integrierte BPM-Organisation einzusetzen. Siehe hierzu auch Kapitel 2.
72
5 Prozesshierarchien und
Testmanagement
5.1 Einleitung

Dieses Kapitel beschreibt, wie in BPM-Tools dokumentierte Geschäftsprozesse im Testmanagement


wiederverwendet werden können. Darüber hinaus werden Aspekte wie die Testorganisation,
-anforderungen, -design und die -ausführung beschrieben.

Im Rahmen von SAP-Projekten und im laufenden Betrieb werden sowohl die Prozesse an sich als
auch die SAP-Software selbst angepasst und verändert.

Geschäftsziele

sgovernance
Prozes
Prozessanforderung

n g
ieru Des
ign
tim &
Op e
ss
M
&

od
e
se
oz

e ll
Pr
ly
bte

ieru
Ana

Organisation
gele

g n

Menschen
Ausfü

Technologien
hr u

l
odel
Gesc

ng
ng

ru
&

sm

on t
ie

en
häf

ito
lem
ft

rin
Imp
tse

g
sc
rfo

Ge
lg

Proz g
essverantwortun (21) Prozesslebenszyklus
(Quelle: © SAP AG, 2012)

Im Prozesslebenszyklus wird das Testen in der Phase der Implementierung durchgeführt. Dies
geschieht sowohl während der Implementierung (eher technische Tests – siehe Abschnitt
Testarten in Kapitel 5.2) als auch zum Abschluss der Implementierungsphase (technische und
fachliche Tests). Das fachlich prozessorientierte Testdesign sollte bereits in der Designphase
beginnen (siehe Abschnitt Testdesign in Kapitel 5.4).

Aus Sicht des Geschäftsprozessmanagements interessieren die Fragestellungen:


>> Welche Tests sind aus fachlicher Prozesssicht durchzuführen (Testdesign)?
>> Wie wird eine optimale Testabdeckung erreicht, gemessen und dokumentiert?

Das Vorgehen zur technischen Durchführung der Tests sowie die Transformation der aus Prozess-
sicht definierten Testfälle, ergänzt um die aus (Software-)technischer Sicht durchzuführenden
Tests, steht hier nicht im Vordergrund. Dies wird im Leitfaden SAP Solution Manager der
DSAG-Arbeitsgruppe Projektmethodik bzw. im angegliederten Leitfaden der Arbeitsgruppe
Testmanagement ausführlich beschrieben (www.dsag.de/go/leitfaeden).
73

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
In der Praxis wird aufgrund von Projektlaufzeiten und Projektkosten bzw. der im Lebenszyklus
späten Testphase oft auf das Testen verzichtet oder nur ein rudimentäres, technisch orientiertes
Testen durchgeführt. Historisch betrachtet führt dies jedoch fast zwangsläufig zu höheren Kosten,
spätestens bei auftretenden Fehlern im Betrieb.

Ein Grund hierfür ist oft das aufwendige, rein manuelle Design der fachlichen Testfälle am Ende
der Implementierungsphase. Die Empfehlung lautet daher, frühzeitig das Testmanagement und
das Design der fachlichen Tests, wie nachfolgend beschrieben, aus Prozesssicht unter Nutzung
der modellierten Prozesse konsequent durchzuführen. Auch gegen mögliche Widerstände
idealerweise zu Beginn und daher bereits in der Modellierungsphase.

5.2 Testarten

Die Beschreibung der Testarten soll einen kurzen Überblick geben und dient der genaueren
Abgrenzung des betrachteten Umfelds. Sie basiert auf Zusammenfassungen aus unterschiedlichen
Quellen (z.B. ISTQB, Wikipedia).

Da in SAP-zentrischen Landschaften Geschäfts- und IT-Strategien miteinander verknüpft sind,


beeinflussen Prozessänderungen und SAP-Anpassungen häufig auch Non-SAP-Systeme und
manuelle Tätigkeiten.

Prinzipiell kann zwischen fachlichen und technischen Tests unterschieden werden. Die Tests
können manuell von Anwendern durchgeführt oder automatisiert werden (eine genauere
Beschreibung zur Testautomatisierung und technischen Durchführung findet sich im Leitfaden
SAP Solution Manager der DSAG-Arbeitsgruppe Projektmethodik bzw. im angegliederten Leitfaden
der Arbeitsgruppe Testmanagement (www.dsag.de/go/leitfaeden)).

Technische Tests stehen im Rahmen der Entwicklung bzw. Realisierung von Anpassungen im
Vordergrund und beziehen sich entweder auf einzelne technische Anpassungen wie Unit- / Modul-
tests, Schnittstellentests oder auf größere Szenarien, wie z. B. Integrationstests.
Bei den fachlichen Tests stehen Acceptance- / Usability-Tests oder Abläufe / Prozesstests im
Vordergrund (wie einleitend aufgeführt, steht das Management dieser aus Prozesssicht erforder-
lichen Tests in diesem Leitfaden im Fokus).

Wichtig für den späteren reibungslosen Betrieb sind insbesondere auch Last- / Performance- und
Massentests.

Da im Rahmen eines Projektes oder im Rahmen des Lebenszyklus SAP-zentrischer Landschaften


häufiger Änderungen durchgeführt werden, müssen die unterschiedlichen Tests in Abhängigkeit
der Änderung wiederholt durchlaufen werden (Regressionstests).
74
5 Prozesshierarchien und
Testmanagement
Im Folgenden werden die unterschiedlichen Testarten vorgestellt:

>> Smoke-Test: Ein erster grundlegender Probelauf, der einfache Probleme offenlegen soll. Es
wird nur eine oberflächliche Überprüfung der Programmfunktionen durchgeführt
(z. B.: Anmelden möglich).
>> Funktions- / Modul- / Unittest: Einzelne Module oder Einheiten werden unabhängig voneinander
getestet. Dies geschieht häufig direkt durch den Programmierer. Daher handelt es sich oft um
kurze einfache Tests, die häufig wiederholt werden. (Bei technischen Geräten oft automatisiert).
Fehler aufgrund anderer Komponenten oder aufgrund der Verknüpfung mit anderen Komponenten
werden nicht erkannt (zur Erkennung dieser Fehler dienen Integrationstests).
>> Schnittstellentest: Hier wird die Schnittstelle zwischen unterschiedlichen Komponenten, die
Daten miteinander austauschen, getestet. Hierunter fallen auch Schnittstellentests zur
Überprüfen von Grenzwerten zur Vermeidung von Korrelationsfehlern (z.B. inkompatible
Datenwerte, inkompatible Maßeinheiten oder Wert aus Komponente A zu groß für Verarbeitung
in Komponente B).
>> Integrationstest: Die realisierte Lösung wird in Kombination (im Zusammenspiel) mit allen
beteiligten Komponenten (integriert) getestet.
>> Acceptance- / Usability-Test: Test aus Sicht der Endbenutzer, inwieweit die realisierten Funk-
tionen aus fachlicher und aus Anwendersicht sowie von der Bedienbarkeit ausreichend sind.
>> Prozesstest: Durchführung fachlicher Tests aus Prozesssicht. Es werden komplette Prozess-
durchläufe (komponenten- / funktionsübergreifend) getestet. Hierbei können aus den fachlichen
Prozessabläufen alle möglichen Prozessdurchläufe ermittelt, nach Relevanz gefiltert und
getestet werden (Testpfade). Im Gegensatz zu manuell erstellten Testfällen kann hierbei ein
Vollständigkeitsgrad bezüglich der Testabdeckung mit Bezug auf die Prozesse angegeben
werden (siehe auch Testdesign).
>> Workflowtest: Die Workflowtests stellen eine Untermenge der Prozesstests für vorgegebene
automatisierte Abläufe (Workflows) im System dar.
>> Last- / Performance- oder Massentest: Die isolierte Durchführung von Tests zeigt zwar die
fachliche, funktionale, Usability-konforme Korrektheit des Systems, nicht aber das Verhalten
bei gleichzeitigem Zugriff vieler Anwender, der Verarbeitung großer oder sich schnell
ändernder Datenmengen. Im Last- / Performance- oder Massentest werden große Datenmen-
gen oder viele gleichzeitige Anwender meist mittels entsprechender Software simuliert bzw.
Daten generiert. Die Durchführung dieser Tests erfolgt technisch entweder auf der Zielplatt-
form (oder einer analog aufgebauten Testplattform) oder wird bei der Auswertung entspre-
chend der Zielplattform hochgerechnet.
>> Regressionstest: Dient der wiederholten Testausführung im Rahmen des Lebenszyklus der
Softwareentwicklung / Systemanpassung. Aufgrund der eventuell hohen Wiederholungszahl
dieser Tests werden diese häufig als automatisch ablaufende Testfälle realisiert.

5.3 Organisation des Testmanagements

Um sicherzustellen, dass die geänderten Prozesse getestet werden können, sind die aufgeführten
Rollen mit den unterschiedlichen Verantwortlichkeiten zu definieren und zu besetzen.

Der Testmanager ist verantwortlich für die Planung und Steuerung der Tests. Bei SAP-Implemen-
tierungen wird diese Aufgabe oft vom Projektmanager übernommen. In sehr großen Projekten
kann es aber sinnvoll sein, diese Position separat zu besetzen.
75

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Die Besetzung der Rolle des Testmanagers darf nicht unterschätzt werden, da der Testmanager
direkt für den Testerfolg, die Qualität und eventuelle Auswirkungen ausschlaggebend ist.

Die Rolle des Testdesigners ist im engen Zusammenhang mit den zu installierenden Prozessen zu
sehen. Deshalb kann es sehr sinnvoll sein, dass diese Aufgabe von den Personen durchgeführt
wird, die für die Installation der entsprechenden Prozesse verantwortlich sind. Ggf. können hier
auch automatisierte Tests konfiguriert werden (die technische Umsetzung der Erstellung von
Testautomatisierungsskripts erfolgt in Zusammenarbeit mit der Rolle des Testautomatisierers).
Dafür ist das entsprechende Wissen an dieser Stelle bereitzustellen bzw. durch andere Personen
zu ergänzen.

Der Testadministrator ist für die Einrichtung der Testumgebung verantwortlich. Diese sollte alle
für den operativen, durchgängigen Betrieb notwendigen Komponenten enthalten bzw. simulieren
können.

Für die Tester sollten verschiedene Testschwerpunkte definiert werden, und für folgende Fokusse
sollten Tester definiert werden:

Entwicklung Funktionalität Prozesse

Die Tester im Entwicklungsbereich stellen die Funktionsfähigkeit einzelner Komponenten nach


Neuentwicklung bzw. Änderungen sicher. Diese Tests werden auf einer sehr technischen Ebene
und prozessunabhängig durchgeführt und bieten sich gerade bei Änderungen für Testautomati-
sierungen an.

Die Tester auf Funktionsebene sind Personen, die sich auf Anwendungsbereichsebene bewegen.
Oft wird dies von den verantwortlichen Beratern in Zusammenarbeit mit den Key-Usern für eine
Installation durchgeführt.

Durchgängige Arbeitsprozesse sollten von den Prozessverantwortlichen / Key-Usern in Zusammen-


arbeit mit deren Kollegen / End-Usern durchgeführt werden, um den gesamten Arbeitsablauf
sicherzustellen und die Akzeptanz dafür zu erhalten.

5.4 Testdesign

Unter Testdesign wird hier vereinfachend die inhaltliche Erstellung der Testfälle und der Ablauf-
folge der durchzuführenden Tests verstanden. Technische Aspekte, die insbesondere bei der
Testautomatisierung eine Rolle spielen (z.B. große Testdatenbasen) werden nicht betrachtet
(Details hierzu finden sich im Leitfaden SAP Solution Manager der DSAG-Arbeitsgruppe Projekt-
methodik bzw. im angegliederten Leitfaden der Arbeitsgruppe Testmanagement).

Bei ausschließlicher Verwendung des SAP Solution Managers für das Testmanagement erfolgt das
Design der Testfälle manuell.

Der Testdesigner (Anwender) definiert in der Projektstruktur des SAP Solution Managers seine
Testfälle. Transaktionen ergeben sich aufgrund der Verwendung von SAP Best-Practice-Prozessen
oder werden ebenfalls manuell verwaltet.
76
5 Prozesshierarchien und
Testmanagement
Die so angelegten Testfälle und Transaktionen können dann über die Test-Workbench als Testplan
verwendet werden. Im Standard wird aus allen Testfällen und Transaktionen der Projektkonfiguration
manuell ausgewählt und aufgrund dieser Auswahl ein Testplan generiert.

Bei Nutzung des Business Process Change Analyzer im Work Center Testmanagement können bei
korrekt konfigurierter Business Process Hierarchy die von einer Änderung betroffenen Geschäfts-
prozesse ermittelt und hierauf basierend reduzierte / spezialisierte Testpläne generiert werden. Die
erzeugten Testpläne können angezeigt, manuell angepasst, kopiert, gelöscht oder nach Testpa-
keten strukturiert werden.

Testpakete und Testfälle können dedizierten Testern (auch mehreren und unterschiedlichen)
zugewiesen und die Abarbeitung in Testsequenzen sortiert werden.

Zur Kontrolle der Testabarbeitung kann ein Statusschema (z.B. Testfall „unbearbeitet“, „bearbei-
tet“, „fehlerhaft“) definiert und mit entsprechenden Workflows (z.B. automatische Information
definierter Rollen bei Statuswechsel) hinterlegt werden.

Der Tester erhält einen Arbeitsvorrat seiner durchzuführenden Tests mit Beschreibung der
Durchführung, der erwartenden Ergebnisse und möglichen Beurteilungen, welche er dann
manuell als Ergebnis dokumentiert.

SAP stellt flexible Auswertungsmechanismen zur Verfügung, die den aktuellen Abarbeitungsstand
nach unterschiedlichsten Kriterien anzeigen können (auch grafisch, z.B. durch das im SAP Solution
Manager integrierte SAP BW).

Vorteile:
>> Die manuelle Erstellung von Testfalldefinitionen ermöglicht den Anwendern eine eigene
Priorisierung dieser Tests und ermöglicht ihnen, diese im Zusammenhang mit nicht system-
unterstützten Aktionen zu betrachten.
>> Dies versetzt den User in die Lage, sich hier selbst einzubringen, und erhöht damit die
Akzeptanz der Testergebnisse.

Nachteile:
>> Aufgrund der manuellen Testfalldefinition ist die Systematik stark vom jeweiligen Testdesigner
abhängig.
>> Es fehlt die Nachvollziehbarkeit der Systematik, der Methodik und der Auswahlkriterien.
>> Innerhalb der manuell erstellten Dokumentation kann die Information bezüglich Relevanz, des
Zusammenhangs und der Testpriorität der einzelnen Testfälle verloren gehen.
>> Insbesondere fehlt ein klares Maß für die erreichte Test-, Risiko- und Anforderungsabdeckung
in Bezug zu den Prozessen.

Über unterschiedliche, im SAP Solution Manager integrierte Produkte bestehen Möglichkeiten,


verschiedene Abdeckungen zu definieren, zu hinterfragen und zu analysieren – siehe Leitfaden SAP
Solution Manager der DSAG-Arbeitsgruppe Projektmethodik bzw. angegliederter Leitfaden
der Arbeitsgruppe Testmanagement.
77

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Der herkömmliche Testprozess weist Lücken auf, ist textbasiert
und produziert Papier
Anforderungen Testidee Testfall Testausführung

?
?
?
Requirement-Tool Manuell Testmanagement-Tool Testautomatisierungs-Tool

Testidee durch: > Erfahrung > Systematik


> Intuition > Zufall
> Fehlerhistorie > Anforderungen

(22) Überblick Ablauf manuelles Testfalldesign und Nachteile (Quelle: MID GmbH / sepp.med GmbH)

Die Verwendung eines BPMA-Werkzeugs (wie z. B. ARIS oder MID Innovator – siehe auch Kapitel
3.6 Exkurs - BPM-Toolauswahl) ermöglicht die Erzeugung von Testfällen aus Sicht der fachlichen
Prozesse.

Die fachlichen Prozessmodelle sind die Grundlage zur Erstellung von Testfällen. Im fachlichen
Prozessmodell oder in ergänzenden Testmodellen werden alle relevanten Testinformationen (wie
z. B. Testfallbeschreibung, erwartetes Ergebnis, Sollwerte, Ein- / Ausgangsbedingungen, Risiko,
Priorität, Kosten …) hinterlegt. Einzelne Aktivitäten oder Ablaufkanten werden in den Modellen als
Testschritte oder Überprüfungspunkte gekennzeichnet.

Mit Hilfe eines Testfallgenerators werden aus den Prozessmodellen heraus alle möglichen
Testfälle generiert. Hierbei können, je nach gewünschter Zielsetzung, unterschiedliche Strategien
verwendet werden: Testabdeckung nach Durchlaufen aller möglichen Ablaufwege oder Berück-
sichtigungsgrad der Aktivitäten (z.B. „alle Aktivitäten müssen mindestens einmal ausgeführt
werden“, Knoten- / Kanten- / Pfadabdeckung) oder Erreichen eines maximalen Testkostendeckels
oder Risikopotenzials.

Auf diese Weise kann das prinzipielle Ziel der Testfallerzeugung in minimaler, aber ausreichender
Anzahl, unter vorgegebenen Rahmenbedingungen systematisiert und nachweisbar erreicht
werden.
78
5 Prozesshierarchien und
Testmanagement
Vorteile:
>> Durch die Darstellung der Testfälle in Modellen und an den fachlichen Prozessen orientiert,
ergibt sich ein einfacherer Zugang zu den Testfällen, sodass diese leichter und schneller
abgestimmt werden können.
>> Die Testfälle können systematisch aus den Modellen abgeleitet und automatisch erzeugt
werden (sowohl für manuelle als auch automatisierte Tests).
>> Die Testfallbeschreibung wird vereinheitlicht und systematisiert.
>> Die Wartbarkeit der Testfälle wird verbessert und ist an die Prozessmodellierung gekoppelt.
>> Die Wiederverwendung (auch für manuelle Tests) von Testfällen wird vereinfacht.
>> Automatisierte Erzeugung der Testfalldokumentation mit Darstellung des Prozess- und
Anforderungsbezugs.

Prozessbasiertes/Modellzentriertes Testen ermöglicht Durchgängigkeit


des Testprozesses
BPMA-Werkzeug systematische und automatische
> Testprofil UML/BPMN
Ableitung der Testfälle aus Diagrammen
> Beschränkung auf testrelevante Elemente
Testgenerator
> Verständlich für Fachtester

Anforderungen Testidee Testfall Testausführung

vollständig
eindeutig
übersichtlich
nachvollziehbar
kommunizierbar
pflegbar

(23) Überblick Ablauf prozessorientiertes Testfalldesign sowie Vor- und Nachteile


(Quelle: MID GmbH / sepp.med GmbH)

Nachteile:
>> Die oft auch durchaus subjektiven Betrachtungsweisen der User zu den zu testenden
Prozessen bleiben außen vor. Diese sind aber oft von Bedeutung für die Beurteilung der
Ergebnisse durch die Anwender.
>> Das Vertrauen in nur automatisch erstellte Ergebnisse zur Beurteilung der Qualität der
eigenen Arbeitsprozesse hält sich bei den Anwendern meist in Grenzen.
79

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Eine gemischte Verwendung von automatisch bzw. manuell erstellten Testfällen kann hier sicher
das beste Ergebnis liefern. Die Durchführung von automatisch erstellten Testfällen liefert das
Ergebnis der generellen technischen Funktionsfähigkeit, wobei die zusätzliche Durchführung von
manuell festgelegten Testfällen die Akzeptanz beim Anwender herstellen bzw. erhöhen kann.

Abhängigkeiten von Prozessebenen für den Test

Modellierte Geschäftsprozesse sollten die Grundlage für die Erstellung von Testprozessen
bilden. Basierend auf ihnen werden die Testpfade und daraus abgeleitet die Testfälle definiert.
Zur Unterstützung unterschiedlicher Testarten können aus den modellierten Prozessebenen
Informationen gewonnen werden.

Funktionale Prozesslandkarte
Hier sind die Prozesse nach Unternehmensfunktionen unterteilt, z.B. Controlling, Vertrieb,
Einkauf. Die Prozesslandkarte wird für die Definition von Funktionstests herangezogen.

(24) Ebene 1: Prozesslandkarte (Quelle: Software AG)


80
5 Prozesshierarchien und
Testmanagement
End-to-End-Sicht
In der End-to-End-Sicht werden die Prozesse in End-to-End-Szenarien, wie z.B. „Order-to-Cash“
oder „Procure-to-Pay“, aufgeteilt. In dieser Sicht werden die Schnittstellen zwischen verschie-
denen Unternehmensbereichen (und damit auch SAP- und Non-SAP-Modulen) deutlich. Deshalb
ist diese Sicht sehr gut als Basis für die Definition der Integrationstests geeignet.

(25) Ebene 1: End-to-End-Sicht (Quelle: Software AG)

Bei der Prozessmodellierung wird generell zwischen Prozessschritten, die im (SAP-)System


durchgeführt werden, und manuellen Prozessschritten unterschieden. Für das Testen im SAP
Solution Manager werden oft nur die SAP-Prozessschritte berücksichtigt. Aber auch Non-SAP-
Schritte sollten in den Test einbezogen werden.
81

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
5.5 Übergabe der Prozesse zum Test

Eine ausführliche Handlungsempfehlung zur Übergabe der Prozesse zum Test auf technischer
Ebene findet sich im Leitfaden SAP Solution Manager der DSAG-Arbeitsgruppe Projektmethodik
bzw. im angegliederten Leitfaden der Arbeitsgruppe Testmanagement. Hier wird eine verein-
fachende Sicht für diesen notwendigen Schritt dargestellt.

Innerhalb eines Projektes sollten die Testabläufe, die den generellen Funktionsbetrieb sicherstel-
len, vorhanden sein. Sie resultieren entweder aus der Bereitstellung aus einem Template heraus
oder sind bei der Konfiguration des Prozessmodells zu konfigurieren bzw. festzulegen. Bei
SAP-Installationen kann dies durch die Test-Workbench des SAP Solution Managers unterstützt
werden.

Entsprechend der Projekt- und Prozessstruktur zugeordnete Testfälle können in der Test-Work-
bench des SAP Solution Managers überwacht werden. Dabei müssen die Testergebnisse ent-
sprechend der festgelegten Risikoklassen beurteilt werden.

In der Test-Workbench der Prozessstruktur zugeordnete Testfallbeschreibungen erläutern den


durchzuführenden Test, die dafür notwendigen Eingangsvoraussetzungen und die daraus
resultierenden zu erwartenden Ergebnisse (weitere Varianten siehe Leitfaden SAP Solution
Manager der DSAG-Arbeitsgruppe Projektmethodik bzw. angegliederter Leitfaden der Arbeits-
gruppe Testmanagement).

Sollte es sich um einen SAP-Rollout handeln, der auf einem festgelegten Template basiert,
sollten alle Testfälle schon im Template der Prozessstruktur zugeordnet sein. Im Projekt sind
alle notwendigen Änderungen des Templates auch in den Testfällen nachzubilden.

Alle Prozesse, die innerhalb eines Projektes als nicht änderbar gekennzeichnet sind, können als
automatisierte Tests (eCATTS) festgelegt werden. Dadurch sind später umfangreiche durchgängige
Testabläufe in kürzeren Zeitabschnitten durchführbar.

5.6 Testausführung – Nutzung von Testsequenzen

Eine Herausforderung bei der Testausführung stellt die Steuerung der Tester dar. Bei großen
Testläufen, die bspw. in verschiedenen Ländern stattfinden, kommt es häufig zu Abstimmungs-
schwierigkeiten und Missverständnissen zwischen den einzelnen Testern, was am Ende zu
Ineffizienzen und Qualitätsverlusten führt.

Diesem Problem kann im SAP Solution Manager durch Erstellung von Testsequenzen begegnet
werden. Dabei werden einzelne Testfälle zu Testsequenzen zusammengestellt. Jedem Testfall
wird dann ein Tester zugewiesen. Mit der Aktivierung der Workflow-Funktionalität werden die
Tester automatisch informiert, sobald der vorangegangene Testfall erfolgreich getestet wurde
(per E-Mail).
82
5 Prozesshierarchien und
Testmanagement
Der Tester kann über die Testerarbeitsliste (Worklist) im SAP Solution Manager mit der Bearbei-
tung der Testfälle starten (alternativ direkt über Links in der Benachrichtigungs-E-Mail, wobei
es sich hierbei nicht um eine Standardfunktionalität handelt) und z.B. Testdokumente lesen,
testrelevante Transaktionen starten oder eCATT-Testkonfigurationen (Extended Computer Aided
Test Tool für automatisierte Tests) ausführen.

Ein weiterer Nutzen ist, dass im Fehlerfall die direkte Eingabe von Incidents in Form von Service-
Desk-Meldungen möglich ist. Dies wird über eine Einbindung des SAP Solution Manager Service
Desk in die Test-Workbench erreicht. Damit eröffnet sich zusätzlich die Möglichkeit der Analyse
der Testergebnisse auf Funktions- und Prozessebene (Statusmonitoring, Beurteilung der
Ergebnisse (Funktion, UI, Handling, Risiko …)).

Mit der Funktion STWB_INFO (Status-Infosystem) kann der Fortschritt eines oder mehrerer
Testpläne überwacht werden:

>> Indem Testpläne über im Vorfeld definierte Suchkriterien (beispielsweise Testreihe, Erstel-
lungsdatum oder Verantwortlicher) selektiert werden können.
>> Gesamtergebnisse von Testplänen grafisch oder tabellarisch angezeigt werden können.
>> Statusanalysen von einzelnen Testplänen angezeigt und in Office-Anwendungen exportierbar
oder ausdruckbar sind.
>> Meldungen zu Testplänen angezeigt und ausgewertet werden können.

Darüber hinaus stehen die Auswertungsmöglichkeiten des integrierten SAP-BW-Reportings zur


Verfügung.

HPQC-Integration
Neben dem Testdesign und der Testausführung im SAP Solution Manager kann dafür auch das HP
Quality Center (HPQC) genutzt werden.

Das HPQC bietet eine Schnittstelle, über die im SAP Solution Manager abgebildete Geschäftspro-
zesse in das Quality Center übertragen werden können. Dort werden die Geschäftsprozesse zur
Erstellung von Testplänen herangezogen. Des Weiteren können Testskripte für einzelne Testläufe
generiert werden.

Weiterhin bietet der SAP Solution Manager die Möglichkeit, Status zu den einzelnen Testfällen zu
pflegen und somit die Transparenz des Abarbeitungsfortschritts zu erhöhen.

Die Verwendung von reinen Testprojekten wird im Zuge des ALM-Konzeptes durch die DSAG-
Arbeitsgruppe Projektmethodik nicht empfohlen.

Weitere Details finden sich im Leitfaden SAP Solution Manager der DSAG-Arbeitsgruppe
Projektmethodik bzw. im angegliederten Leitfaden der Arbeitsgruppe Testmanagement.
DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
83
84
6 BPMS - Prozessautomatisierung

6.1 Einleitung

Im folgenden Kapitel geht es um die technische Umsetzung des BPMs durch die Implementierung
einzelner Geschäftsprozesse mittels elektronischer Workflows auf Basis des BPMS (Business
Process Management Systems) – SAP NetWeaver BPM.

Dieses Kapitel richtet sich an IT-Architekten, Projektleiter und Projektmitarbeiter, die vor oder in
der technischen Implementierung von Prozessen in Form von automatisierten Workflows mit der
SAP Workflow Engine „SAP NetWeaver BPM (Business Process Management) – Teilkomponente
von SAP NetWeaver PO (Process Orchestration)“ stehen.

Der Leser erhält einen Überblick über die notwendigen SAP-Komponenten und Handlungsempfeh-
lungen für eine erfolgreiche Projektumsetzung und -implementierung.

Zur Einordnung der folgenden Ausführungen in den BPM-Lebenszyklus geht es in diesem Kapitel
im Wesentlichen um das technische Design und die Modellierung von ausführbaren Prozessen
sowie um die Implementierung von Prozessen in Form von benutzerzentrierten Workflows.

Geschäftsziele

sgovernance
Prozes
Prozessanforderung

n g
ieru Des
ign
t im &
Op e
ss
M
&

od
e
se
oz

e ll
Pr
ly
bte

ieru
Ana

Organisation
gele

g n

Menschen
Ausfü

Technologien
hr u

l
odel
Gesc

ng
ng

ru
&

sm

on t
ie

en
häf

ito
lem
ft

rin
Imp
tse

g
sc
rfo

Ge
lg

Proz g
essverantwortun
(26) Prozesslebenszyklus
(Quelle: © SAP AG, 2012)
85

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Nachdem ein Prozess organisatorisch definiert (Design) und wie in Kapitel 3 beschrieben in Form
von Prozessmodellen dokumentiert ist, stellt sich nun die Frage, wie und ob der Prozess IT-ge-
stützt implementiert wird. Bei einer IT-Implementierung mit SAP-Software entscheidet man sich in
der Regel zwischen dem Einsatz von
>> Standardprozessen und deren individueller Anpassung durch Customizing
(auch oft als „SAP-Business-Suite-Prozesse“ bezeichnet, z.B. die Auftragsabwicklung im
SAP ERP Modul SD Anfrage Angebot Auftrag) oder
>> der individuellen Entwicklung einer (workflowbasierten) Anwendung.

Im zweiten Fall steht den SAP-Kunden von SAP NetWeaver PO (Process Orchestration) mit SAP
NetWeaver BPM (Business Process Management) eine systemübergreifende Workflow-Engine zur
Verfügung, die es in der Prozessumsetzung erlaubt, Daten und Funktionen aus unterschiedlichsten
Backend-Systemen (SAP und Non-SAP) zu integrieren.

Wenn folgende Annahmen zutreffen, ist eine Implementierung des Geschäftsprozesses mit SAP
NetWeaver BPM sinnvoll:

1. Der Geschäftsprozess ist individuell und kann nicht durch eine einfache Anpassung von
Standardsoftware, z.B. in der SAP Business Suite (ERP, CRM, SRM, SCM) in Form von
Customizing umgesetzt werden.

2. Der Geschäftsprozess erstreckt sich über Systemgrenzen hinweg (heterogene System-


landschaft) und benötigt Daten und Funktionen aus verschiedenen, bestehenden internen
und externen Systemen.

3. Die Benutzer des Prozesses wünschen sich eine neue, einfach zu bedienende
Benutzeroberfläche.

4. Allen Beteiligten ist bewusst, dass es sich bei dem Projekt um ein Software-
Entwicklungsprojekt handelt.

5. Im Projektteam ist neben dem „klassischen“ ABAP-Know-how auch Java und


BPMN-Know-how vorhanden.

Ein häufig anzutreffendes Szenario für solche Workflows ist die Umsetzung von Stammdaten-
und Genehmigungsprozessen.

Hinweis:
Wollen Sie mehr über die Implementierung von Prozessen mit der Komponente „Process
Integration“ (PI) erfahren, so besuchen Sie den DSAG-Arbeitskreis „Application Integration“
(www.dsag.de/AK/AI)
86
6 BPMS - Prozessautomatisierung

6.2 Architektur und Aufbau von SAP NetWeaver Process


Orchestration

In 2012 hat SAP die vormals getrennt positionierten Produkte


>> SAP NetWeaver Process Integration („PI“ vormals „Exchange Infrastructure“) – Abbildung von
Prozessen zwischen Systemen / Anwendungen)
>> SAP NetWeaver Composition Environment („CE“) (modellgetriebene Softwareentwicklung von
SOA-basierten Anwendungen)
>> SAP NetWeaver Business Process Management („BPM”) (Abbildung von Prozessen durch
Workflows mit menschlicher Interaktion)
>> SAP NetWeaver Business Rules Management („BRM”) (Abbildung von Geschäftsregeln)

unter der Bezeichnung „SAP NetWeaver Process Orchestration” (PO) zusammengefasst. Die
„Zusammenfassung“ bedeutet, dass es hierzu ein Lizenzmodell gibt und die Server- und Lauf-
zeitkomponenten ab der NetWeaver Version 7.3.1 in einem logischen System (eine SID) auf dem
SAP NetWeaver Application Server Java (AS Java) installiert und betrieben werden können. Die
Anwendungsentwicklung erfolgt für alle Komponenten im SAP NetWeaver Development Studio
(NWDS).

Vereinfacht stellt sich ein typischer SAP-Systemverbund für die Entwicklung und Ausführung von
Workflows mit SAP NetWeaver BPM wie folgt dar:

Portal incl. UWL Userfrontend

Developer Studio AS Java incl.


Laufzeitumgebung
(NWDS) CE, PI,
des Workflows
BPM, BRM
Entwicklungs-
Umgebung (Desktop)
Development Schnittstellen
Infastructure (WebServices oder RFCs)
(NWDI)

Versionierung,
Transport

non-SAP-System SAP ERP SAP SRM SAP System xy

!!!ACHTUNG: Non-SAP-System, SAP-System und inkl.!!!

(27) Vereinfachte Architektur eines Systemverbundes für NetWeaver BPM-basierte


Workflows (Quelle: HLP Informationsmanagement GmbH, 2013)
87

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Um einen Prozess in Form eines elektronischen Workflows mit SAP NetWeaver BPM entwickeln
und verwenden zu können, sind die im Folgenden beschriebenen Komponenten notwendig.

6.2.1 SAP NetWeaver Development Studio (NWDS) – Process Composer:


Die Entwicklungsumgebung

Die Entwicklungsumgebung „SAP NetWeaver Development Studio“ (NWDS) für Java-basierte


Anwendungsentwicklung wird auf den lokalen PCs der Entwickler bereitgestellt. Im NWDS erfolgt
die Modellierung des Prozesses in Form eines BPMN-Modells im „Process Composer“.

(28) Process Composer im SAP NetWeaver Developer Studio


(Quelle: Demosystem – HLP Informationsmanagement GmbH, 2013)

Das in BPMN modellierte Prozessmodell kann über eine Schnittstelle mit dem SAP Solution
Manager zu Dokumentationszwecken synchronisiert werden. Für die Entwicklung der Benutzero-
ber-flächen kann sich der Entwickler zwischen WebDynpro4Java (der am häufigsten eingesetzten
UI-Technologie in Projekten mit SAP NetWeaver BPM), WebDynpro4Abap, Visual Composer, Adobe
Interactive Forms oder dem SAP Development Toolkit for HTML5 entscheiden. Neben diesen von
SAP entwickelten UI-Technologien steht dem Entwickler eine API zur Verfügung, um beliebige
andere UI-Technologien zu verwenden.

SAP-Backendsysteme werden in der Regel über RFC-Bausteine oder Web-Services integriert.


88
6 BPMS - Prozessautomatisierung

6.2.2 SAP NetWeaver Business Process Management (BPM) – Process Server:


Die Workflow-Laufzeitumgebung

Ist der Prozess entwickelt und soll ausgeführt werden, wird die Anwendung erstellt und im Process
Server ausgeführt. Der Process Server – die Workflow-Laufzeitumgebung – wird vom SAP
Application Server Java bereitgestellt.

6.2.3 Optional: SAP NetWeaver Development Infrastructure (DI):


Die Sourcecode-Verwaltung, Build- und Transport-Infrastruktur

Arbeiten mehrere Entwickler an einem Projekt, empfiehlt sich der Einsatz der SAP NetWeaver
Development Infrastructure (NWDI), um zum einen die Sourcecode-Verwaltung und -Versionierung
sicherzustellen und zum anderen die Transporte zwischen den verschieden Systemen zu steuern.
Die NWDI kann als Komponenten auf einem Application Server Java installiert und bereitgestellt
werden.

6.2.4 SAP NetWeaver Portal

Um dem Endnutzer den Zugriff auf die neue Workflow-Anwendung zu ermöglichen, wird in den
meisten Fällen eine Integration mit dem SAP NetWeaver Portal Server vorgenommen. Dem
Endbenutzer steht dann eine Portalanwendung zur Verfügung, mit der der Prozess in Form eines
Eingabeformulars bzw. einer komplexen Bildschirmmaske gestartet wird. Alternativ können
Prozesse auch über eine API aus anderen Systemen (z.B. SAP ERP) gestartet werden.

6.2.5 BPM Inbox oder Universal Worklist

Einzelne Arbeitsschritte im Prozess werden dem Benutzer in Form von Aufgaben in einer
Aufgabenliste angezeigt. Hierzu kann die Universal Worklist (UWL) des SAP NetWeaver Portal
Servers oder die mitgelieferte SAPUI5-basierte BPM Inbox von SAP NetWeaver BPM
(ab Version 7.3.1 verfügbar) verwendet werden.

6.2.6 Optional: Process Integration

Für die Integration unterschiedlichster Backend-Systeme mit unterschiedlichsten Schnittstellen-


formaten bietet sich die Nutzung der SAP NetWeaver PI an. SAP NetWeaver PI ist eine bei vielen
SAP-Kunden etablierte Umgebung zur Verteilung von Daten zwischen Systemen.

Die Kommunikation zwischen SAP NetWeaver BPM und PI basiert auf dem Proxy-Protokoll. Sowohl
beim Design als auch beim Monitoring ist dabei zu beachten, dass es sich hierbei um eine lose
Kopplung handelt, d.h., aus Sicht von PI stellt die BPM Engine ein Sender- oder Empfangskompo-
nente dar, die Nachrichten empfängt, verarbeitet und versendet. Wie eingangs erwähnt, kann die
PI ab der Version 7.3.1. mit dem BPM-Process Server auf einem System (SID) betrieben werden.
89

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Hinweis:
Die zukünftige Weiterentwicklung von SAP NetWeaver PI wird sich auf die Java-basierte Lösung
(Advanced Adapter Engine Extended = AEX) konzentrieren. Die bisherige Architektur auf Basis des
Double Stacks von Java und ABAP wird aktuell weiterhin unterstützt, mittel- und langfristig ist
jedoch von einer erforderlichen Migration auf die rein Java-basierte AEX auszugehen.

Das bisherige ABAP-basierte cross-component BPM (ccBPM) zur Orchestrierung von systemzent-
rischen Prozessen wird bei SAP NetWeaver PO durch NetWeaver BPM abgelöst. Grundlegender
Unterschied neben der unterschiedlichen Laufzeit ist die Notation. Während ccBPM auf der SAP
Workflow Engine aufsetzt und auf BPEL basiert, nutzt SAP NetWeaver BPM den BPMN-Standard
für die Modellierung und das Monitoring von Prozessen. Durch die unterschiedlichen Standards
ergibt sich ein grundlegend unterschiedliches technisches Design der Prozesse, wodurch eine
automatisierte Migration von ccBPM nach NetWeaver BPM von SAP nicht angeboten wird und
wenig sinnvoll ist.

6.2.7 Optional: Enterprise Services Repository

Das Enterprise Services Repository (ESR) dient zur Ablage von Service Interfaces, Message-Typen,
Datenstrukturen und Mappings etc.

Um eine möglichst hohe unternehmensweite Wiederverwendbarkeit und zentrale Übersicht über


die ESR-Objekte zu erreichen, sollte im Falle von zusätzlichen NetWeaver BPM-Instanzen das
zentrale ESR der PO-Umgebung genutzt werden.

Dabei ist zu beachten, dass die PO-Installation pro Systemebene (Entwicklung, Test, Produktion)
ihr jeweils lokales ESR nutzt und die ESR- und BPM-Entwicklungen entsprechend aufeinander
abgestimmt zu transportieren sind.

6.3 Installationsoptionen für SAP NetWeaver


Process Orchestration

Bei der Installation der zentralen Instanz ist grundsätzlich zu empfehlen, statt AEX direkt den
Usage Type Process Orchestration (PO) zu wählen, da aktuell eine nachträgliche Änderung des
Usage Types offiziell von SAP nicht unterstützt wird.

Sofern ein Unternehmen den Einsatz von SAP NetWeaver BPM sowohl für systemzentrische als
auch für benutzerbasierte Prozesse im größeren Umfang geplant, ist ein Aufbau von getrennten
Instanzen in Erwägung zu ziehen.
90
6 BPMS - Prozessautomatisierung

Gegenüberstellung BPM Engine auf zentraler PO-Instanz oder getrennt:

Architekturansatz Pro Kontra

Gemeinsame Verringerung Komplexität Systemland- Abhängigkeiten bzgl.


Instanz BPM schaft und Monitoring Verfügbarkeit, Sizing
und PI
In Summe geringere Hardware-Anforde-
rungen durch gemeinsame Java-Instanz

Vereinfachte, engere Verzahnung der


verschiedenen Prozesstypen

Getrennte Entkopplung Performance-Abhängig- Erforderliche PI-zu-PI-Kom-


Instanzen keiten insbesondere bei hohem munikation bei Zugriff von
Datenvolumen benutzerzentrischen BPMs auf
vorhandene EAI-Schnittstellen

Abgrenzungslogik, wann
BPM systemzentrisch oder
benutzerbasiert ist

Neben diesen beiden Varianten besteht, beim Fokus auf benutzerbasierte Prozesse, die weitere
Alternative, SAP NetWeaver BPM auf der gleichen Instanz wie SAP NetWeaver Portal zu betreiben.

Gegenüberstellung BPM Engine auf NetWeaver Portal oder getrennt:

Architekturansatz Pro Kontra

Gemeinsame Verringerung Komplexität Systemland- Abhängigkeiten bzgl. Ver-


Instanz BPM schaft und Monitoring fügbarkeit, Release- / Patch-
und Portal Level, Sizing
In Summe geringere Hardware-Anforde-
rungen durch gemeinsame Java-Instanz

Getrennte Entkopplung Performance-Abhängig- Höhere Netzwerk-Verzögerung


Instanzen keiten insbesondere bei hohen durch Kommunikation
Benutzerzahlen zwischen Portal- und BPM-
Instanz bei großen Benutzer-
zahlen und enger Kopplung
der beiden Komponenten
91

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
6.4 Einführungsansatz für eine Workflow-Anwendung
auf Basis NetWeaver BPM

Wenn ein spezifischer Prozess, wie z.B. die Bestellfreigabe, identifiziert ist, gilt es, den Prozess bis zu
einem Level zu modellieren, dass dieser auf der NetWeaver BPM Engine ausgeführt werden kann.

Geschäftsprozesse können für dieses Ziel in drei Ebenen modelliert werden:


>> beschreibend
>> analytisch
>> ausführbar

Die beschreibende Ebene stellt die Prozesse sehr abstrakt dar. Das Ziel eines beschreibenden
Modells ist die Möglichkeit, mit diesem unternehmensweit zu kommunizieren. Dieses Modell ist
nicht vollständig und modelliert nur den Gut-Fall (Happy-Path). Solche Modelle werden in der
Regel in einem BPMA-System (siehe Kapitel 3) modelliert und abgelegt.

Beim analytischen Modell werden auch alle fachlichen Ausnahmen und Varianten modelliert, dies
dient als Basis für die Implementierung des Prozesses. Für die ausführbare Ebene werden dann
alle Implementierungsdetails dem Modell hinzugefügt.

Hierzu gehört z. B. das Abfangen von technischen Fehlern (Exception Handling), die im analytischen
Modell noch nicht vorhanden sind. Die einzelnen Prozessschritte müssen bis ins Detail modelliert
werden: Welcher Service aufgerufen wird oder welche UI für welchen Benutzer zugeordnet wird.
Zudem müssen die Ereignisse (Events) spezifiziert werden, um auch prozessübergreifende
Kommunikation zu ermöglichen. Das ausführbare BPMN-2.0-basierte Modell für SAP NetWeaver
BPM wird im NetWeaver Developer Studio erstellt und enthält viele technische Schritte, die im
beschreibenden Modell nicht benötigt und vorhanden sind.

Um einen ausführbaren Prozess zu definieren, kann man nach drei Ansätzen vorgehen:

Zentrales vs. verteiltes Vorgehen


Beim zentralen Vorgehen werden die Fachexperten zusammen in Meetings einberufen und
erarbeiten zusammen den Sollprozess.

Beim verteilten Vorgehen werden die Fachexperten einzeln befragt und der Prozess-Analyst fügt
die Prozessfragmente dann zusammen.

Top-down- vs. Bottom-up-Vorgehen


Der gängige Weg ist das Top-down-Vorgehen, bei dem der Analyst mit einem grob-granularen
Prozess startet und dieser Prozess anschließend bis ins Detail weiterentwickelt wird.

Beim Bottom-up-Vorgehen werden zuerst die einzelnen Details eines Prozesses modelliert und
diese anschließend zu einer Prozesshierarchie zusammengeführt.
92
6 BPMS - Prozessautomatisierung

Strukturiertes vs. unstrukturiertes Vorgehen


Beim strukturierten Vorgehen werden die Informationen nach einer definierten Art, wie z. B. einem
Fragebogen, ermittelt.

Beim unstrukturierten Vorgehen berichten die Fachexperten frei und der Prozess-Analyst hat die
Aufgabe, die Informationen zu strukturieren.

>> Die drei Ansätze können auch kombiniert werden, da sie sich nicht gegenseitig ausschließen.

6.4.1 Mockups

Um einen Prozess und die neuen Benutzeroberflächen bereits vor der eigentlichen Implemen-
tierung mit den Endanwendern zu konzipieren, empfiehlt sich der Einsatz von „Mockups“ (auch
„Wireframes“ genannt). Es hat sich in der Praxis gezeigt, dass ein reines BPMN-Prozessmodell
nicht ausreicht, um die für die Implementierung notwendigen Informationen mit den späteren
Anwendern zu besprechen. „Mockups“ für die neuen Benutzeroberflächen werden meist vom
Product-Owner (bei der Verwendung der Scrum-Methodik im Projekt) erstellt.

Auf Basis der Mockups erfolgt die Implementierung in der ausgewählten UI-Technologie
(z.B. WebDynpro4Java oder SAP Development Toolkit for HTML5), wobei die Mockups lediglich
richtungsweisend, jedoch nicht verbindlich sind.

Es kann generell zwischen statischen und dynamischen Mockups unterschieden werden. Bei
statischen Mockups handelt es sich um grafische Werkzeuge, die eine Visualisierung von
einzelnen, unabhängigen Oberflächen unterstützen – etwa mit einem Baukasten von UI-Bau-
steinen. Damit lassen sich schnell ansehnliche UIs erstellen. Manche Tools stellen die UI-
Elemente in einer Art Handzeichnung dar, um den Interimscharakter dazustellen.

Für einige Produkte gibt es mittlerweile auch Communities, die weitere UI-Elemente bereitstellen,
etwa für iOS-Elemente. Zudem bieten manche Anbieter cloudbasierte Tools an, sodass keine lokale
Installation und Datenhaltung mehr notwendig ist und darüber hinaus auch Collaboration-Szenari-
en unterstützt werden. Dynamische Mockup-Tools ermöglichen die Erstellung von HTML-Proto-
typen, die sich schon fast wie eine fertige Oberfläche bzw. Anwendung anfühlen. So ist eine
Navigation zwischen Screens möglich, Werte aus einem Screen werden in einen anderen
übernommen (etwa bei einer Warenkorbfunktion) etc.

6.4.2 Projektvorgehensweise

In der Praxis hat sich gezeigt, dass bei der Umsetzung von BPM-Prozessen, agile Vorgehenswei-
sen, gegenüber einem komplett auf dem Wasserfallmodell aufbauenden Projektansatz, Vorteile
haben. Die Prozesse werden hierbei in mehreren Phasen implementiert. Zuerst erfolgt die
Modellierung des Happy-Path. In weiteren Iterationen werden dann weitere Prozessschritte
oder Ausnahmebehandlungen modelliert. Auf diese Weise kann zum einen sehr viel schneller
(und öfter) auf Nutzerfeedback reagiert werden und die Prozessmodelle erreichen in kürzerer
Zeit eine bessere Qualität.
93

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Als Ergänzung zur beschriebenen Vorgehensweise hat sich insbesondere bei sehr lang laufenden
und komplexen Prozessinstanzen gezeigt, dass die inkrementelle Implementierung und Ausliefe-
rung von Prozessen von Vorteil sein kann. Bei dieser Vorgehensweise muss der Gesamtprozess mit
seinen einzelnen Subprozessen feststehen und implementiert werden. Die Ausimplementierung
der einzelnen Subprozesse erfolgt allerdings erst in späteren Iterationen. Die Idee ist, dass auch
Prozesse, die produktiv im ersten Inkrement bzw. in der ersten Version starten, von (Subprozess-)
Implementierungen aus weiteren Inkrementen „profitieren“.

Hierzu ist der Einsatz von Haltepunkt- und Restart-Prozessen notwendig. Unter einem Restart-
Prozess versteht man in diesem Kontext einen Subprozess, der erst einmal anstatt des fertig
implementierten Prozesses aufgerufen wird. Er bietet per User Task dann die Möglichkeit, neu
gestartet zu werden, um später den fertig implementierten Subprozess zu betreten. Dabei muss
beachtet werden, dass sich die Schnittstelle zum Aufruf des Subprozesses zwischen Restart-Pro-
zess und richtiger Implementierung nicht unterscheiden darf.

6.4.3 Verwendung von Geschäftsregeln durch den Einsatz eines Business-


Rules-Managementsystems (BRMS)

Ein BRMS erlaubt die Implementierung, Ausführung und das zentrale Management von Geschäfts-
regeln. Durch die Verwendung eines BRMS kann die Transparenz und Flexibilität innerhalb von
Anwendungen erhöht werden. Ein BRMS erlaubt die Definition komplexer Zusammenhänge in
businessverständlicher Form. Durch Pflegeanwendungen können Regeln durch Fachbereichsmit-
arbeiter selbstständig geändert werden, wodurch die IT-Abteilung entlastet wird.

6.4.3.1 SAP-Portfolio

SAP bietet mehrere BRMS-Lösungen an, die im Zusammenspiel mit SAP NetWeaver BPM
verwendet werden können.

SAP NetWeaver Business Rules Management (SAP NW BRM)


SAP NetWeaver BRM ist für die Ausführung auf dem Java Stack des SAP NetWeaver Servers
optimiert. Das in die NWDI integrierte Rule Repository ist für die versionierte Ablage von Regeln
zuständig. Für die Implementierung, Validierung und den Test von Regeln ist der Rule Composer
zuständig. Fachbereichsmitarbeiter können Regeländerungen „on-the-fly“ über den webbasierten
Rules Manager durchführen. Die Rule Engine ist für die Ausführung von Regeln zuständig. Die
Administration und das Monitoring erfolgt über den SAP NetWeaver Administrator (NWA). Regeln
können sowohl als Session Beans wie auch als Webservices ausgeführt werden.

SAP NetWeaver Decision Management Service (SAP NW DMS)


SAP NW DMS (ehemals BRF plus) ist für die Ausführung und Verwaltung von Regeln in der SAP
Business Suite optimiert. Der Fachbereich kann die im zentralen Repository abgelegten Decision
Services selbstständig modellieren und ändern, wohingegen die IT-Abteilung für die technische
Anreicherung sowie für deren Versionierung und das Reporting der Decision Services zuständig ist.
Der Distribution Layer erlaubt sowohl die lokale Ausführung von Decision Services in SAP-Syste-
men als auch über Web Services.
94
6 BPMS - Prozessautomatisierung

Hinweis:
SAP NW DMS ist separat zu lizenzieren und nicht im Umfang der Lizenz für SAP NetWeaver
Process Orchestration enthalten.

>> SAP HANA Rule Engine


Speziell für die HANA-Laufzeitumgebung ist die SAP HANA Rule Engine optimiert. Regeln
basieren hierbei auf HANA-Modellen. Der Funktionsumfang beschränkt sich noch auf reine
Entscheidungstabellen, in Zukunft sollen aber noch weitere Funktionalitäten hinzukommen.
Die SAP HANA Rule Engine spielt für diesen Leitfaden nur eine untergeordnete Rolle und wird
daher nicht weiter betrachtet.

6.4.3.2 Anwendungsszenarien

Die beiden BRMS SAP NW DMS und SAP NW BRM erlauben durch die Verwendung von Web
Services die beliebige Mischung der beiden Technologie-Stacks (ABAP / Java). Auf diese Weise kann
jeweils auf Basis der konkreten Anforderungen die passende Rule Engine verwendet werden. Die
folgende Gegenüberstellung gibt Hinweise und Empfehlungen für die Verwendung der jeweiligen
Technologie der Rule Engine.

>> ABAP – SAP NW DSM


> Business-Regel für Applikationen der SAP Business Suite (z.B. ERP SD Auftragserfassung,
SAP MDG)
> Die Ausführungsschicht der Applikation und die Ablage der Regeln basieren vollständig auf
dem ABAP-Stack
> Nahtlose Integration (z.B. in das ABAP Data Dictionary), gute Performance
> Kann auch von SAP Business Workflows als Rules Engine verwendet werden

>> JAVA – SAP NW BRM


> Bei der Verwendung von SAP NetWeaver BPM Workflows erfolgt ein nativer Zugriff auf
die Regeln in Form von Java Session Beans oder Web Services
> Nahtlose Integration in den Java-Stack
> Verwendung von Regeln zur Entscheidungsfindung (Gateways); z.B. durch die Verwendung
von Entscheidungstabellen kann die Modellierung komplexer Entscheidungsbäume mit
Gateways vermieden werden

>> ABAP – SAP NW BRM


> Wenn Suite-Applikationen spezielle NW BRM Features benötigen, z.B. Rete Rules
> Applikationen, die mit anderen Non-SAP-Systemen arbeiten (Heterogene Systemumgebung)
> Nutzung kann über Web Services oder über speziellen Connector Expression Type erfolgen

>> JAVA – SAP NW DSM


> Composite Applikationen und NW BPM Workflows greifen auf Rules im Business-
Suite-Kern zu
> Rules sind im BRFplus gepflegt, der Zugriff erfolgt über Web Services
95

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
6.5 Handlungsempfehlungen für die Implementierung

Dieses Kapitel stellt eine Reihe von grundlegenden Designparametern dar, die für den nachhal-
tigen und wartbaren Einsatz einer SAP NetWeaver BPM-Lösung essentiell sind. In den Empfeh-
lungen zur Prozesserhebung und Prozessmodellierung ist zu berücksichtigen, dass jede
Empfehlung immer im Kontext des aktuellen Projektvorhabens betrachtet werden muss. Für das
Verständnis des Kapitels sind Grundkenntnisse in der Entwicklung von SAP NetWeaver BPM-
basierten Prozessen notwendig.

6.5.1 Prozesserhebung

Es wird empfohlen, die ausführbaren BPMN-basierten Prozessmodelle schlank zu halten. Damit


kann ein höheres Abstraktionsvermögen erreicht und auch der Grad der Wiederverwendung von
Prozessteilen erhöht werden.

>> Die Anzahl der Aktivitäten in einem Prozess sollte maximal zwischen 25 und 50 liegen
(Mihaylova, 2011).
>> Verwendung von Subprozessen: Inhaltlich zusammenhängende Prozessschritte können in
Subprozesse ausgelagert werden. Der Hauptprozess bleibt dadurch schlanker und übersicht-
licher, zudem kann es sinnvoll sein, die Subprozesse wiederverwendbar zu halten. Ein
typisches Beispiel hierfür ist ein Subprozess zur Datenverteilung. Hinter einem Prozessschritt
„Datenverteilung“ im Hauptprozess stecken zahlreiche Einzelschritte wie die Übergabe einer
Nachricht an einen Message Broker / ein Anwendungssystem, das Warten auf eine Rückmel-
dung bei asynchroner Verbuchung bis hin zu einem Fehlerhandling.
>> Steuerung komplexer Datenverteilungen über einen Message Broker (z. B. SAP PI): Oftmals
müssen Daten in mehrere Backendsysteme verteilt werden, wobei häufig auch Abhängigkeiten
der Systeme untereinander bestehen. Es besteht z. B. häufig die Abhängigkeit, dass die
Verbuchung in einem System erst erfolgreich abgeschlossen sein muss, damit die dort
generierte Nummer an nachgelagerte Systeme weitergegeben werden kann. Es wird empfoh-
len, für solche Szenarien einen Message Broker einzusetzen, anstatt diese Abhängigkeiten im
eigentlichen Anwendungsprozess zu modellieren.

6.5.2 Prozessmodellierung

>> Es wird empfohlen, bei komplexen Datenstrukturen NICHT die vollständigen Datenobjekte in
den Prozesskontext zu legen.
>> Stattdessen sollte der Prozesskontext auf Schlüsselfelder für die Identifikation der Datenob-
jekte bzw. diejenigen Attribute, die für die Prozesssteuerung relevant sind, beschränkt werden.
>> Die eigentlichen Datenobjekte sollten in einer persistenten Datenhaltung abgelegt werden
– dies können entweder Anwendungstabellen einer Standardapplikation sein oder auch
eigenentwickelte Datenstrukturen.
>> Zur Strukturierung eines Prozessmodells sollten Subprozesse verwendet werden. Dies kann
auch genutzt werden, um Serviceaufrufe (automatisierte Aktivitäten) zu kapseln und das
übergeordnete Prozessmodell möglichst frei von technischen Details zu halten
(Quelle: siehe 7.2.4).
96
6 BPMS - Prozessautomatisierung

6.5.3 User Interfaces

>> Ein erheblicher Teil der Implementierungsaufwände in BPM-Projekten fällt üblicherweise für
die Entwicklung der Benutzeroberflächen an, insbesondere wenn keine geeigneten Standard-
benutzeroberflächen vorhanden sind.
>> Zudem besteht typischerweise eine Tendenz zur Individualisierung der Benutzeroberflächen,
d. h. abhängig beispielsweise von Prozessschritt und Organisationseinheit sowie Rolle des
Anwenders werden nur die jeweils relevanten Felder und Funktionen angeboten oder Pflicht-
felder entsprechend gesteuert. Dies ist insbesondere aus Wartungsgesichtspunkten eine
Herausforderung, da die Benutzeroberfläche auch ständigen Änderungen unterliegt, die dann
potenziell mehrere Stellen betreffen.
>> Es wird daher unbedingt empfohlen, hier frühzeitig ein Konzept zur Erstellung von Benutzer-
oberflächen zu entwickeln.
>> SAP NetWeaver bietet auch die Möglichkeit der automatischen Generierung von Web Dynpro for
Java oder Visual Composer UIs aus dem Prozesskontext heraus. In der Praxis hat sich aber
gezeigt, dass die nachträgliche Erweiterung dieser generierten UIs eher aufwendig ist, sodass
die Zeitersparnis gegenüber einer Eigenentwicklung eher gering ist.
>> Gerade bei umfassenden Implementierungen kann es sinnvoll sein, ein Generierungs-Frame-
work für Benutzeroberflächen einzusetzen. Für SAP NetWeaver BPM existieren hier bereits
mehrere Beratungslösungen (auf diese wird in diesem Leitfaden nicht näher eingegangen), die
in Projekten genutzt werden können. Häufig beinhalten diese Generierungs-Frameworks auch
eine Persistenz zur Ablage der Datenobjekte, d.h., wenn keine geeigneten Standardanwendungs-
tabellen zur Verfügung stehen, können über das Framework die Datenstrukturen für die
Anwendungsobjekte sowie basierend auf den Strukturen dann die Benutzeroberflächen
generiert werden.
>> Neben prozessspezifischen UIs (Worklist, Task UIs und ggf. UIs zum Starten von Prozessen)
werden in der Regel noch weitere UIs benötigt:
> Applikationsspezifische Administration (Steuerung, Inhalte etc.)
> Übersichten zu den Prozessen bzw. den dort verarbeiteten Daten usw.
>> Ab der Verwendung von SAP NetWeaver BPM 7.3.1 ist für die Entwicklung von webbasierten
Benutzeroberflächen für einzelne Tasks, die auch auf Tablets oder Smartphones zur Verfügung
stehen sollen, der Einsatz des SAP Development Toolkit for HTML5 (aka SAPUI5) sinnvoll.

6.5.4 Integration von Geschäftsregeln

Bei der Integration von Geschäftsregeln sind verschieden Szenarien denkbar:


>> Geschäftsregeln sind dem Business-Prozess vorgelagert, d.h. erst, wenn durch das implemen-
tierte Regelwerk keine Entscheidung getroffen werden kann, z.B. weil der beantragte
Kreditrahmen eine manuelle Freigabe der verantwortlichen Stellen erfordert, wird ein
Business-Prozess nachgelagert.
>> Ebenso können durch einen vorgelagerten Business-Prozess notwendige Informationen erfasst
und an ein nachgelagertes Regelwerk übergeben werden.
>> In Prozessmodellen können umfangreiche Gateway-Strukturen zur Abbildung komplexer
Entscheidungsbäume durch die Anwendung von Geschäftsregeln (z.B. Entscheidungstabellen)
vermieden werden. Dadurch erhöht sich sowohl die Wartbarkeit als auch die Lesbarkeit von
Prozessmodellen.
97

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
>> In der Praxis hat es sich als vorteilhaft erwiesen, wenn der Aufruf von Geschäftsregeln durch
eine Facade gekapselt wird. Auf diese Weise kann ohne Einfluss auf die Implementierung des
Geschäftsprozesses die verwendete Technologie (BRM, BRF Plus, Plain Java …) ausgetauscht
werden.
>> Je nach Umfang der implementierten Geschäftsregeln macht die Etablierung eines zentralen
Repositories zur zentralen Dokumentation und Verwaltung von Geschäftsregeln Sinn.
>> Der von SAP bereitgestellte Rules Manager erlaubt die einfache und schnelle Anpassung von
Geschäftsregeln durch Fachbereichsmitarbeiter. Dieses Tool ist sehr mächtig und ermöglicht
tiefgreifende Änderungen am implementierten Regelwerk. Im Vorfeld sollte daher ein ge-
eigneter Change-Prozess zur Änderung von Geschäftsregeln konzipiert und implementiert
werden.

6.5.5 Bearbeiterfindung, Organisationsmanagement

Es wird nicht empfohlen, die Verantwortlichkeiten für Tasks in den Prozessen bereits zur
Design-Zeit festzulegen. Ggf. reicht eine mit der UME (User Management Engine, Teil des AS Java)
umgesetzte, rollenbasierte Verwaltung der Verantwortlichkeiten aus.

Dieses System stößt jedoch schnell an seine Grenzen:


>> bei Vertreterregelungen
>> bei Ausnahmen, wenn z.B. ein User nicht mehr existiert (weil der Mitarbeiter beispielsweise
das Unternehmen verlassen hat)
>> bei umfangreicher Ermittlung der Verantwortlichkeiten, die über eine rollenbasierte Definition
der Zuständigkeiten hinausgeht. In der Praxis kommen sehr oft viele weitere Kriterien hinzu.

Anhand der genannten Gründe empfehlen wir, die Zuständigkeiten erst zur Laufzeit festzulegen.
Dies ist z. B. mit Hilfe von EJB-Funktionen oder Web-Services möglich, die hierfür als Funktionen
in der Prozessschicht verwendet werden können. Im Falle der Verwendung von Webservices kann
auch das bestehenden SAP ERP HCM-Organisationsmanagement in den
Prozess integriert und genutzt werden.

6.5.6 Prozessübergreifende Funktionalitäten

In umfangreicheren BPM-Projekten finden sich erfahrungsgemäß auch immer wieder Funktionali-


täten, die prozessübergreifend sind bzw. in verschiedensten Prozessen verwendet werden. Es wird
empfohlen, diese Komponenten zu standardisieren bzw. soweit möglich in übergreifende zentrale
Module auszulagern. Dadurch ergibt sich eine vereinfachte Wartung der Anwendung, da Anpas-
sungen nur an einer Stelle vorgenommen werden müssen. Viel wichtiger aus Sicht des Anwenders
ist aber die Vereinheitlichung in der Benutzerführung bzw. bei der Handhabung der Anwendung.
98
6 BPMS - Prozessautomatisierung

Dies betrifft u.a. die nachfolgenden Komponenten / Funktionalitäten:


>> Aufbau der Benutzeroberflächen
>> Einheitliche Benennung wiederkehrender Drucktasten
>> Notifikationen / vereinheitlichter Aufbau von E-Mail-Benachrichtigungen
>> Vereinheitlichter Aufbau der Workitem-Texte
>> Einheitliches Fehler-Handling
>> Einheitliche BPMN-Modellierung: Gleiche Sachverhalte mit den gleichen Notationselementen
abbilden (innerhalb des Entwicklerteams abstimmen, dass bestimmte Teilaspekte, z.B.
Eskalation von Tasks, stets gleichartig modelliert werden, um die Lesbarkeit der BPM-Modelle
zu erhöhen)

Darüber hinaus wird empfohlen, sich frühzeitig mit den nachfolgenden Fragestellungen auseinan-
derzusetzen. Hier ist insbesondere zu bewerten, ob die Funktionalitäten im SAP-Standard
ausreichend sind oder ob zusätzliche organisatorische Maßnahmen bzw. Zusatzentwicklungen
vorzusehen sind:
>> (Fachliches) Monitoring der Prozesse
>> Handling von Attachments in den Prozessen
>> Reporting über Prozesslaufzeiten

6.5.7 Portal

Das SAP NetWeaver Portal kann als zentraler Einstieg zum Starten von SAP NetWeaver BPM-
Prozessen genutzt werden. Durch das Portal ist es dann möglich, eine Startapplikation für einen
Prozess rollenbasiert an die Endanwender auszuliefern.

(29) Zusammenspiel von SAP NetWeaver Portal und SAP NetWeaver BPM (Quelle: SAP AG)
99

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Der zentrale Arbeitsvorrat (Universal Worklist, UWL) des SAP NetWeaver Portals ist mit der SAP
NetWeaver BPM Prozess-Engine verbunden. Dadurch können die Benutzer in der UWL direkt auf
ihre Aufgaben zugreifen und diese von dort aus zentral bearbeiten.

(30) SAP Universal Worklist innerhalb des SAP NetWeaver Portals (Quelle: Demosystem HLP
Informationsmanagement GmbH)

Für die Anbindung des SAP NetWeaver BPM an die UWL existiert ein Standard-UWL-Connector im
SAP NetWeaver Portal (BPEMUWLConnector). Dieser UWL-Connector wird während der Installati-
on automatisch konfiguriert, wenn ein SAP NetWeaver BPM-System auf der gleichen SAP JEE
Engine installiert ist. Im Fall, dass das SAP NetWeaver BPM-System auf einer anderen SAP JEE
Engine installiert ist, kann diese Verbindung nachträglich konfiguriert werden.

Eine weitere Standardkomponente von SAP NetWeaver BPM ist der Process List Viewer. Der
Process List Viewer gibt den Anwendern eine Übersicht über die aktuell laufenden Prozesse und
bereits abgeschlossene Prozesse, an denen sie beteiligt waren, und bietet so den Nutzern die
Möglichkeit, den Status eines Prozesses aktiv einzusehen.
100
6 BPMS - Prozessautomatisierung

(31) Process List Viewer von SAP NetWeaver BPM 7.3 EhP1 (Quelle: Demosystem HLP
Informationsmanagement GmbH)

6.5.8 Alternativen zum zentralen Arbeitsvorat (UWL)

6.5.8.1 BPM Inbox

Mit der Version SAP NetWeaver BPM 7.3.1 liefert SAP eine neue BPM Inbox aus. Diese erfüllt im
Prinzip die Funktionalität der UWL, allerdings stellt sie nur Tasks aus dem der lokalen Installation
des SAP NetWeaver BPM-Systems dar. Es handelt sich also nicht um einen kompletten Ersatz der
UWL, da es hier ja möglich ist, auch weitere Workflow-Systeme anzubinden.

Die BPM Inbox basiert auf dem UI Framework SAPUI5, das auf dem HTML5-Standard aufsetzt und
dadurch auch für die Darstellung in mobilen Endgeräten geeignet ist.

(32) Task Inbox von SAP NetWeaver BPM 7.3. EhP1 (Quelle: SAP AG)
101

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
Weitere Vorteile der BPM Inbox sind, dass der Endbenutzer hier weitreichende Filtermöglichkeiten
hat und auch direkt Aktionen ausführen kann, um beispielsweise eine Genehmigung durchzuführen.

6.5.8.2 Entwicklung eigener Worklists

Es kann durchaus sinnvoll sein, die Entwicklung einer eigenen Worklist durchzuführen, um diese
dann gemäß den projektspezifischen Anforderungen zu gestalten. So ist es hilfreich, wenn pro
Prozess eine eigene Worklist zur Verfügung stehen soll oder um in einer E-Mail-Notification auf
eine gefilterte Worklist zu verlinken, die nur das entsprechende Workitem zeigt. Außerdem kann
man zusätzliche Informationen in die Worklist aufnehmen, Workitems gruppieren etc. Sinnvoll
kann beispielsweise auch die Verlinkung aus der Worklist auf weitere Dokumente, Webseiten usw.
sein. Technisch umgesetzt wird die applikationsspezifische Worklist mit der BPM API, die seit SAP
NetWeaver BPM 7.3 verfügbar ist.

6.5.9 Testmanagement

Zum Testen von Prozessen, die mit SAP NetWeaver BPM implementiert wurden, existieren diverse
Ansätze. Eine Integration in das Testmanagements und die Tools des SAP Solution Managers
existiert derzeit nicht. Ein Ansatz ist neben dem (strukturierten) manuellen Test auch der Einsatz
eines UI-Testframeworks auf Basis von Drittanbieter oder Open-Source-Produkten.

Dabei wird das Framework so konfiguriert, dass es einen User, der vor dem Browser sitzt, per
JavaScript simuliert. Dies stellte sich allerdings als sehr umständlich und insbesondere bei agilen
Projekten als enormer Aufwandstreiber heraus, sodass man genau abwägen sollte, ob der Einsatz
eines solchen UI-Testframeworks sinnvoll ist. Auch Tests auf semantische Korrektheit können so
schlecht durchgeführt werden. Dazu kommen technische Probleme wie z.B. die mangelnde
Verträglichkeit des UI-Testframeworks mit WebDynpro.

Der Einsatz eines eigenen Testframeworks macht durchaus Sinn, um die manuellen Tests
wenigstens teilweise zu automatisieren. So kann man beispielsweise automatisch die notwendige
Datenbasis erzeugen, um einen beliebigen Subprozess im Gesamtprozess auf dieser wohldefi-
nierten Basis zu testen. Damit man sich die Workitems der eigentlichen Verantwortlichen nicht
jedes Mal manuell über den SAP NetWeaver Administrator (NWA) zuweisen muss, könnte man
beispielsweise eine Brücke einbauen, die in Testfällen den Tester zusätzlich als Verantwortlichen
in allen Workitems aufnimmt. Das kann man beliebig weiterführen, sodass solche Tests über eine
eigene UI durchgeführt werden. Dort wählt man das Testszenario (Datenbasis), den entsprechenden
Subprozess usw. und führt den Test durch.
102
6 BPMS - Prozessautomatisierung

6.5.10 Monitoring, Reporting

Im Process Repository sind alle bereitgestellten Prozesse aufgelistet. Zu jedem sind Informationen
wie das Prozessschaubild und die User Tasks verfügbar.

Im Process Manager findet man operative Daten zu laufenden Prozessinstanzen. Zu jeder Instanz
werden Statusinformationen angezeigt, ob eine Prozessinstanz ausgeführt wird, abgebrochen
wurde oder aufgrund eines Fehlers terminierte. Des Weiteren ist der Inhalt des Prozesskontextes,
ein Logging etc. verfügbar.

Die Prozessvisualisierung macht eine Prozessinstanz im BPMN-Modell des zugehörigen Prozesses


sichtbar. Dabei kann man sehen, was alles schon erledigt wurde und worauf gerade gewartet wird.
Zu sehen sind bei User Tasks u.a. Deadlines und bei abgeschlossenen Tasks der ausführende User
und das Bearbeitungsdatum.

Reporting Tasks können beim Modellieren / Entwickeln von Prozessen dazu verwendet werden, um
„Prozess-Rohdaten“ in eine SAP Business Intelligence DataSource zu schreiben.
Mit NetWeaver 7.3 Enhancement Package 1 liefert SAP ein vorkonfiguriertes Dashboard zur
Auswertung von Prozessen aus (siehe http://help.sap.com/saphelp_nw73ehp1/helpdata/en/9c/50d
05c9d7e45988181ee90249dedb6/frameset.htm).

Hinweis:
Als neue Komponente zur Auswertung von SAP NetWeaver BPM-basierten Prozessen steht SAP-
Kunden das neue, zusätzlich zu lizenzierende Tool „SAP Operational Process Intelligence 1.0
(Opint)“ auf Basis von HANA zur Verfügung (https://help.sap.com/hana-opint).
DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
103
104
7 Anhang

7.1 Glossar

Begriff Erklärung

AEX Advanced Adapter Engine Extended (Bestandteil von SAP NetWeaver Process
Integration)

ALM Application Lifecycle Management

API Application Programming Interface

APO SAP Advanced Planner and Optimizer

APQC American Productivity and Quality Center

Audit Bezeichnet Untersuchungsverfahren, die dazu dienen, Prozesse hinsichtlich


der Erfüllung von Anforderungen und Richtlinien zu bewerten

Benchmar- Vergleichende Analyse von Ergebnissen oder Prozessen mit einem festgelegten
king Bezugswert oder Vergleichsprozess

Best Bewährte, optimale bzw. vorbildliche Methoden, Praktiken oder Vorgehenswei-


Practices sen

BilMOG Bilanzrechtsmodernisierungsgesetz

Bottom-up Vom Konkreten, Speziellen schrittweise hin zum Abstrakten, Allgemeinen,


Übergeordneten

BPA Business Process Automation

BPB Business Process Blueprinting

BPEL Business Process Execution Language

BPM Business Process Management

BPMA Business Process Modeling and Analysis

BPMS Business Process Management System

BPR Business Process Reengineering

BPR SAP Business Process Repository

BRF+ Business Rules Framework plus

BRM Business Rules Management

Business Verantwortlich für das WAS (Festlegung von Geschäftszielen, Strategie des
Owner Prozesses, Koordination involvierter Geschäftsbereiche und Process Manager)

BW Business Warehouse

ccBPM Cross-component Business Process Management ist die Workflowkomponente


innerhalb von SAP NetWeaver Process Integration (PI)

CCO Chief Compliance Officer


105

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
CE Composition Environment

ChaRM SAP Change Request Management

Cloud-Com- Ein Ansatz, abstrahierte IT-Infrastrukturen (z.B. Rechenkapazität, Datenspei-


puting cher, Netzwerkkapazitäten oder auch fertige Software) dynamisch an den
Bedarf angepasst über ein Netzwerk zur Verfügung zu stellen

CMMI Capability Maturity Model Integration

CPO Chief Process Officer

CRM Customer Relationship Management

CSF Critical Success Factors

DoDAF Department of Defense Architecture Framework

DSAG Deutschsprachige SAP-Anwendergruppe e.V. – weltweit einer der größten


unabhängigen Interessenverbände von SAP-Anwendern

Dump Bezeichnet in der Datenverarbeitung eine Kopie oder einen Auszug eines
Speicherinhalts

EBIT Betriebswirtschaftliche Kennzahl für das operative Ergebnis (earnings before


interest and taxes)

eCATTS Extended Computer Aided Test Tool

ECC SAP ERP Central Component

EDEN Reifegradmodell der BPM Maturity Model eden e.V

EHP Optionale Erweiterungspakete ab dem SAP Release ECC 6.0 (Enhancement


Package)

EJB Enterprise JavaBeans

End-to-End- Vollständige Betrachtung eines Geschäftsprozesses von dessen Beginn bis zu


Sicht seinem Ende, auch über Bereichsgrenzen hinweg

Enterprise Entity Beans modellieren die dauerhaften (persistenten) Daten des Systems
Beans

EPK Ereignisgesteuerte Prozesskette

ERP Enterprise Resource Planning

ESR Enterprise Services Repository

Facade Abstrakte Schnittstelle zu einer Menge von Schnittstellen eines Subsystems

FDY Food and Drug Administration

GITP Good Information Technology Practice

GMP Good Manufacturing Practice


106
7 Anhang

Governance Governance ist begrifflich den Sozialwissenschaften, insbesondere der


Politikwissenschaft entlehnt und entzieht sich als Konzept einer knappen
Definition. Die Governance-Forschung beobachtet Handlungen wie Regieren,
Steuern und Koordinieren innerhalb staatlicher, gesellschaftlicher und
wirtschaftlicher Akteure in netzwerkartigen Strukturen. Das bislang dominie-
rende Konzept ‚Steuerung’ wird mit diesem Begriff in einer umfassenderen
Perspektive verortet. Diese umgreift das Konstellationsgefüge, in dem sich die
beteiligten Akteure bewegen, ihre intentionalen (Steuerungs-)Aktivitäten
mitsamt ihren Potenzialen und Beschränkungen sowie die institutionellen
Regelungsstrukturen und die mit ihnen verknüpften Veränderungsprozesse
und Wirkungen

GRC Governance, Risk and Compliance

Greenfield Eine Planungsart, bei der von Grund auf ohne belastende Voraussetzung und
Approach Rahmenbedingungen geplant werden kann

GTS SAP Global Trade Services

HCM Human Capital Management

HPQC HP Quality Center

IDOC Intermediate Document

IKS Internes Kontrollsystem

Incident engl. Vorfall, Ereignis, Störung

ISO International Organization for Standardization

ISTQB International Software Testing Qualifications Board (belgische Non-profit-


Organisation)

IT Informationstechnik

ITIL IT Infrastructure Library

KPI Key Performance Indicator

KVP Kontinuierlicher Verbesserungsprozess

Lifecycle Ein in sich geschlossener Prozess von Entstehung, Veränderung hin zur
Beendigung

MDG Master Data Governance

Mockup Modell, Nachbildung – bezeichnet beispielsweise eine schematische


Darstellung einer Bildschirmmaske eines IT-Systems

MoDAF British Ministry of Defence Architecture Framework

monitoren Status überwachen, Verlauf beobachten, Ablauf verfolgen

NAF NATO Architecture Framework

NWA NetWeaver Administrator

NWDI NetWeaver Development Infratructure


107

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
NWDS NetWeaver Development Studio

OPInt Operational Process Intelligence

OTC Order-to-Cash

PCF Process Classification Framework

PEMM Process Enterprise Maturity Model von Michael Hammer

PI Process Integration

PO Process Orchestration

Post Merger Integrationsphase nach einer rechtlichen Zusammenlegung mindestens zweier


Integration Unternehmen, bei der Prozesse und Strukturen vereinheitlicht und Geschäfts-
bereiche auch organisatorisch zusammengelegt werden

PPC Process Performance Cost

PPI Process Performance Indicator

PPQ Process Performance Quality

PPT Process Performance Time

PQI Practice Quality Improvement

Process Verantwortlich für das WIE (Prozessdefinition, Ausführung und Verbesserung


Manager des Prozesses)

PwC PricewaterhouseCoopers Aktiengesellschaft Wirtschaftprüfungsgesellschaft

QS Qualitätssicherung

RACI Wird als eine Technik zur Analyse und Darstellung von Verantwortlichkeiten
bezeichnet. Der Name leitet sich aus den Anfangsbuchstaben der englischen
Begriffe Responsible, Accountable, Consulted und Informed ab

RBE SAP Reverse Business Engineer

Re-Doku- Übertragung von Systeminformationen in Prozessmodelle, z.B. Erstellung


mentation einer aktuellen Übersicht verwendeter SAP-Prozesse sowie Transaktionen

RFC Remote Function Call

ROI Return of Investment

Rollout Begriff, der so viel wie Einführung oder Markteinführung bedeutet

SAP Systeme, Anwendungen und Produkte (in der Datenverarbeitung)

SAP NW SAP NetWeaver Decision Management Service


DMS

SAP SCM SAP Supply Chain Management

SAP SD SAP Sales and Distribution Modul

SAP SRM SAP Supplier Relationship Management

SCC Supply Chain Council (unabhängige US-amerikanische Non-profit-Organisation)


108
7 Anhang

SCOR Supply Chain Operations Reference-Modell zur Beschreibung aller unter-


nehmensinternen und unternehmensübergreifenden Geschäftsprozesse

Scrum- Vorgehensmodell der Softwaretechnik. Der Ansatz von Scrum ist empirisch,
Methodik inkrementell und iterativ

Session Session Beans dienen dazu, serverseitige Geschäftsprozesse zu realisieren


Beans

SID SAP-System-ID

SOX Sarbanes Oxley Act

Sponsor Förderer, Geldgeber eines Vorhabens

SSC Shared Service Center

ToGAF Ansatz für Entwurf, Planung, Implementierung und Wartung von Unter-
nehmensarchitekturen (The Open Group Architecture Framework)

Top-down Vom Abstrakten, Allgemeinen, Übergeordneten schrittweise hin zum


Konkreten, Speziellen

Top-Ma- Bezeichnung für den Tätigkeitsbereich der obersten Ebene in der


nagement hierarchischen Organisationsstruktur einer Unternehmung

Tranfor- Umwandlung
mation

UI User Interface

UME User Management Engine

UWL Universal Worklist

Verlinkung Verknüpfung oder Vernetzung von Objekten

Wireframe z.B. Prototyp zur Veranschaulichung von Konzepten

Workflow Unter einem Workflow versteht man die Abbildung eines in der realen Welt
existierenden Geschäftsprozesses oder eines Teiles davon in ein computer-
gestütztes System
109

DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
7.2 Quellen

>> Workflow (Kapitel 6.1.2)


Kapitel Böhm, M.: Entwicklung von Workflow Typen. 1. Auflage, Springer, Berlin, 2000.
>> Workflow – Literaturverweis (Kapitel 6.1.2)
zur Mühlen, M.: von Uthmann, C.: Ein Framework zur Identifikation des Workflow-Potenzials
von Prozessen . In: HMD – Praxis Wirtschaftsinformatik, Heft 213, Juni 2000, S. 67–79.
>> Verwendung von Geschäftsregeln durch den Einsatz eines Business Rules Management
Systems – BRMS
Carsten Ziegler, Thomas Albrecht: „BRFplus-Business Rule Management for ABAP
Applications“, SAP Press, ISBN 978-1-59229-293-6
>> Prozessmodellierung
Volker Stiehl: „Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN: Wie
flexible Anwendungsarchitekturen wirklich erreicht werden können“, dpunkt.verlag, ISBN
978-3-86490-007-5
>> Prozesslebenszyklus (Kapitel 1, 1.7)
(Quelle: BPM-Technologie im systematischen Überblick, White Paper, SAP und Accenture, März
2009, http://www.sap-cio.de/wp-content/uploads/2012/09/BPM-Technologie-im1.pdf)

7.3 Abbildungsverzeichnis

(1) Prozesslebenszyklus (Quelle: © SAP AG, 2012) 9


(2) Prozesspyramide (Quelle: B.Braun Melsungen AG, 2011) 13
(3) Gegenüberstellung Process Reengineering – Kontinuierliche Prozessverbesserung
(Quelle: PwC 2011) 18
(4) Updates im BPM (Quelle SAP AG 2012) 25
(5) Software AG, 2013 26
(6) Telekommunikationsunternehmen (Quelle: Software AG, 2013) 26
(7) Reifegradmodell EDEN Januar 2010 (Quelle: © BPM Maturity Model EDEN e.V.) 28
(8) Auszug Fragenkatalog für BPM-Strategiephase (Quelle: Software AG) 29
(9) Reifegradmodell der SAP (Quelle: © SAP AG 2012) 30
(10) Level 1 Prozesslandkarte (Quelle: Comgroup / Wuerth Gruppe) 38
(11) Zusammenarbeit im BPA-Umfeld (Quelle: Software AG, 2013) 38
(12) Strukturbeispiel Prozessmodell (Quelle: DSAG AK BPM, 2013) 41
(13) ERPOne Project (Quelle: Deutsche Telekom AG) 43
(14) Tätigkeiten und Schritte zur Prozessanalyse und -optimierung (Quelle: © SAP AG, 2012) 55
(15) Performance Indikatoren (Quelle: © SAP AG, 2008) 57
(16) Zusammenhang PPI und KPI (Quelle: SAP AG ©, 2008) 57
(17) Prozessanalyse und ihre Eingangsgrößen
(Quelle: CDI Concepts Development Integration AG, 2012) 62
(18) SAP Operational Process Intelligence (Quelle: © SAP AG, 2013) 66
(19) Prozess Monitoring (Quelle: © SAP AG, 2010) 68
(20) BPM Analytics Dashboard (Quelle: © SAP AG, 2013) 69
110
7 Anhang

7.3 Abbildungsverzeichnis

(21) Prozesslebenszyklus (Quelle: © SAP AG, 2012) 66


(22) Überblick Ablauf manuelles Testfalldesign und Nachteile
(Quelle: MID GmbH / sepp.med GmbH) 77
(23) Überblick Ablauf prozessorientiertes Testfalldesign und Vorteile Nachteile
(Quelle: MID GmbH / sepp.med GmbH) 78
(24) Ebene 1 Prozesslandkarte (Quelle: Software AG) 79
(25) Ebene 1 End-to-End-Sicht (Quelle: Software AG) 80
(26) Prozesslebenszyklus (Quelle: © SAP AG, 2012) 84
(27) Vereinfachte Architektur eines Systemverbundes für NetWeaver BPM-basierte
Workflows (Quelle: HLP Informationsmanagement GmbH, 2013) 86
(28) Process Composer im SAP NetWeaver Developer Studio
(Quelle: Demosystem – HLP Informationsmanagement GmbH, 2013) 87
(29) Zusammenspiel von SAP NetWeaver Portal und SAP NetWeaver BPM (Quelle: SAP AG) 98
(30) SAP Universal Worklist innerhalb des SAP NetWeaver Portals
(Quelle: Demosystem HLP Informationsmanagement GmbH) 99
(31) Process List Viewer von SAP NetWeaver BPM 7.3 EhP1
(Quelle: Demosystem HLP Informationsmanagement GmbH) 100
(32) Task-Inbox von SAP NetWeaver BPM 7.3. EhP1 (Quelle: SAP AG) 100

7.4 Autorenverzeichnis

>> Fastenrath, Joost B.Braun Melsungen AG


>> Goldschmidt, Michael BASF SE
>> Himmelmann, Holger cbs Corporate Business Solutions Unternehmensberatung GmbH
>> Deist, Christian CDI Concepts Development Integration AG
>> Walter, Harald CENIT AG
>> Ohm, Detlef Comgroup GmbH
>> Winterstein, Winfried CSC Deutschland Solutions GmbH
>> Haupt, Gerhard Heidelberger Druckmaschinen AG
>> Brauneis, Stefan HLP Informationsmanagement GmbH
>> Heger, Mirko HLP Informationsmanagement GmbH
>> Nussbaumer, Martin IB Solution
>> Wilhelm, Ralf MID GmbH
>> Ofner, Christian PricewaterhouseCoopers AG
>> Reisert, Corinne SAP AG
>> Blondaut, Joséphe Software AG
>> Grohmann, Susanne Software AG
>> Vietor, Marc Software AG
DSAG Leitfaden Version 1.0 Business Process Management, 30. August 2013, © DSAG e. V.
111
DSAG – Deutschsprachige SAP ® Anwendergruppe e. V.
Altrottstraße 34a © DSAG e. V.
69190 Walldorf
Deutschland
Fon: +49 (0) 6227 – 358 09 58
Fax: +49 (0) 6227 – 358 09 59
www.dsag.de I info@dsag.de