I. EINLEITUNG
Während sich in den vergangenen Jahrzehnten die Unternehmen mit der effizienten
Ausführung und lokalen Optimierung von einzelnen Funktionsbereichen beschäftigt
haben, trat dabei der Gesamtzusammenhang der betriebenen und in der IT abgebildeten
Systeme in den Hintergrund. Je stärker die Autonomie der Funktionsbereiche
wurde, je mehr Funktionalitäten in einzelne "Silo Applikationen"
einer Abteilung gepackt wurden, umso stärker stiegen der Aufwand und die
Kosten für Abstimmung und Koordination zwischen Abteilungen und IT Systemen.
Zur Überwindung dieses Dilemma begannen daher die Organisationen immer
mehr, explizit ihre Prozesse in den Mittelpunkt ihrer (Verbesserungs-) Projekte
zu stellen. Das Schlagwort Business Process Reenginee-ring (BPR) aus dem Jahr
1993 [1] ist dafür bester Beweis, auch wenn mittlerweile die teilweise
überzogenen Erwartungen von BPR einem gesunden Realismus beim Angehen von
Prozessverbesserungsprojekten gewi-chen sind.
Eine ähnliche Hinwendung zu Prozessen ist nicht nur in den funktionalen
Bereichen der Unternehmen, sondern auch in der IT festzustellen. War die IT
der 80er Jahre vorwiegend durch die Beschäftigung mit Data Management
(Stichworte: relationale Datenbanken, Unternehmensdatenmodelle) gekennzeichnet,
ohne im speziellen über die Automatisierung von (simplen) Aufgaben und
Aktivitäten hinaus auf Prozesse gesondert einzugehen, so standen die 90er
Jahre im Zeichen des Application Managements. Dabei wurden
erstmals durch die Einführung von ERP (Enterprise Resource Planning) Applikationen
großflächig Unternehmensprozesse in Applikationen abgebildet. Der
radikale Ansatz des Business Process Reengineerings [1] hat ebenfalls —
wenngleich auch mit geringem Implementierungserfolg — das Top Management
in der Frage nach der Prozessunterstützung gerade durch IT sensibilisiert.
In Zusammenhang mit einer oft schwach ausgeprägten (falls überhaupt
explizit vorhandenen) strategischen IT Architektur hat dies in vielen Fällen
zu einer heterogenen und verteilten n-tier Architektur geführt,
in der zahlreiche funktionale Applikationssilos Geschäftslogiken und Prozesssteuerung
teilweise in Code, teilweise in Konfigurationstabellen oder auch in externen
Integrationsplattformen (Stichwort: Enterprise Application Integration, EAI)
abbilden. Tatsächlich können in dieser Situation die IT und die Prozesse
nicht mehr voneinander getrennt werden: Sie sind zu einem einzigen praktisch
untrennbaren (und auch unentwirrbaren) Geflecht verwoben.
Obwohl die Unternehmen etwa 40% ihrer IT Kosten aufwenden, um bestehende Applikationen
weiter zu unterstützen bzw. neue Funktionalitäten einzuführen,
werden die Erwartungen der Fachanwender und des Ma-nagements typischerweise
von der IT enttäuscht: Änderungen der Prozesse führen sofort
und notwendigerweise zu Änderungen in den Applikationen — da letztere
aber nur fehleranfällig, langsam und auch teuer adaptiert werden können,
weitet sich der (ohnehin schon bestehende) Graben zwischen Fachabteilung / Geschäftsführung
und der IT Abteilung aus. Dazu kommt, dass in Zeiten der Globalisierung und
Digitalisierung die Komplexität, Konkurrenz und die Betonung des Shareholder
Values [2] zunehmen und von den Unternehmen die gleichzeitige Optimierung von
Flexibilität und Profitabilität gefordert wird: Ein Unterfangen, dass
in vielen Fällen von der Schwerfälligkeit der IT behindert, wenn nicht
gar verhindert wird.
II. VISION VON BPM
Vor diesem Hintergrund stellt Business Process Management (BPM) mit seinem
klaren und deutlichen Fokus auf die Geschäftsprozesse ein tragfähiges
Fundament für eine Vision dar, die tatsächlich in der Lage ist, den
Graben zwischen IT und Fachabteilung (den sogenannten „business-IT divide“)
zu überwinden. In letzter (visionärer) Konsequenz heißt BPM,
dass sich Organisation und Fachabteilungen selbst völlig ohne Mithilfe
der IT ihre Prozesse im Rahmen der Modellierung des BPMS zusammenstellen und
Aktivitäten steuernd und koordinierend anordnen (können). Das fertige
Prozessmodell wird dann einfach an eine entsprechende Process Engine zur Abarbeitung
und Ausführung übergeben. Eine eigentliche Programmierung und Applikationsentwicklung
findet dabei überhaupt nicht mehr statt!
In diesem Sinne kann die (radikale) Vision von BPM auch als: „Don’t
bridge the business-IT divide—obliterate it!“ formuliert werden
[3]. Zusammen mit der architektonischen Grundlagen einer service-orientierten
IT Architektur (SOA) beschränkt sich die applikationsorientierte Rolle
der IT Abteilung in diesem Zukunftsszenario auf die Aufgabe, Services zu implementieren.
Die gewohnte Anwendungsentwicklung im klassischen Sinne ist dann nicht mehr
notwendig und findet ergo dessen auch nicht mehr statt.
Auch wenn man zugesteht, dass eine derartige Vision nicht in einem Schritt
erreicht werden kann, sollen die in diesem White Paper angeführten Ausführungen
demonstrieren, welche konkreten ersten Schritte heute schon in der Lage sind,
die Unternehmen in diese (richtige) Richtung zu bringen.
III. BASISDEFINITIONEN
In diesem Abschnitt sollen die Definitionen der wichtigsten Begriffe im Umfeld
und Kontext von BPM bzw. BPMS eingeführt werden.
A. Prozesse
Ausgehend von zahlreichen zum Teil sehr unterschiedlichen Definitionen
von "Prozess" können jedoch die folgenden Gemeinsamkeiten festgehalten
werden (vgl. Abbildung 1 und [4]-[6]).
 |
 Klicken zum Vergrößern |
| Abb. 1: Definition von "Prozess" |
Ein Prozess ist eine strukturierte und gesteuerte Folge von
Aktivitäten (in der Regel von Menschen, aber auch von sonstigen Systemen),
die angibt, wie aus einem vorgegebenen Input ein bestimmtes
Ergebnis ("Output") erzeugt werden soll (Thomas Davenport hat das
einmal sehr prägnant eine Structure for Action genannt [6]). Darüber
hinaus in den meisten Fällen klar, dass Prozesse immer eine bestimmte Infrastruktur
benötigen, um ablaufen zu können (nicht nur IT Systeme, sondern bspw.
Fahrzeuge zum Transport von Personen oder Sachen, Maschinen zur Verarbeitung
von bestimmtem Input u.a.m.). Dieses "Wegabstrahieren" der Details
der inneren Struktur der Aktivitäten führt dann zu der nachfolgenden
Darstellung eines abstrakten "Prozesses" in Abbildung 2.
 |
| Klicken zum Vergrößern |
| Abb.2: Abstraktionsschritt von Struktur zum Prozess |
Es ist weiters deutlich, dass einerseits die Prozesse auf der abstrakten Ebene
von Aktivitätsflüssen einfach modelliert (bzw. graphisch dargestellt)
werden können, andererseits aber praktisch alle wichtigen Prozesse innerhalb
von Unternehmen die IT (bzw. geeignete Applikationen) zur Unterstützung
benötigen. Dieser oft komplexe Zusammenhang ist schematisch in der nachstehenden
Abbildung 3 wieder gegeben.
Das Herstellen dieser notwendigen Verbindungen von den Aktivitäten bis
hinunter zu den IT Systemen bleibt (bzw. ist) in vielen Fällen Aufgabe
der IT Abteilung. Dabei hat sich die Strukturierung der Analyse im Rahmen des
sogenannten process-driven Architecture (PDA) Modells
- Prozessintegration (einschließlich der Modellierung
und Digitalisierung der Prozesse)
- Informationsintegration (inklusive Methoden des Semantic
Webs)
- Service Integration (unter Berücksichtung von Konzepten
einer service-orientierten Architektur, SOA)
- Technologie Integration (für das "Anflanschen"
der bestehenden Systeme)
 |
| Klicken zum Vergrößern |
| Abb.3: Vom Prozess zu den IT-Systemen |
bewährt (siehe [7] für eine ausführlichere Einführung).
B. Geschäftsprozesse
Wenn man reale Unternehmen in Prozesse gliedern möchte, wird einsichtig,
dass es tendenziell sehr viele "Prozesse" im allgemeinen Sinne in
derartigen Organisationen geben wird. Daher wird man in der Regel seine Menge
an Prozessen in geeigneten Schemata kategorisieren. Typisch ist hier die Gliederung
in kleinere Prozesse ("Unterprozesse"), also entlang der Unterscheidung
"besteht aus": Hauptprozess – Prozess – Teilprozess –
Prozessfragment – Aktivitätskette bis hin zur (aus Prozesssicht)
nicht mehr weiter teilbaren Aktivität.
 |
| Klicken zum Vergrößern |
| Abb.4: Definition von Geschäftsprozess |
Die gröbste Kategorie wird dann typischerweise Geschäftsprozess
genannt. Dabei wird bei einem Geschäftsprozess oft der Kunde oder die Kundenbeziehung
in den Mittelpunkt gestellt, mitunter aber auch sonstige strategische (also
für das Unternehmen langfristig wichtige) Ziele. Die Summe der einzelnen
(kleineren) Prozesse, die alle der Erfüllung dieser Kundenanforderungen
oder der strategischen Anforderungen ausgeführt oder zusammen gefasst werden,
nennt man daher Geschäftsprozess (vgl. Abbildung 4 und [4]–[6]).
Innerhalb der Literatur (auch zwischen Akademikern und Praktikern) herrscht
Uneinigkeit, wie viele Geschäftsprozesse (im hier angegebenen Sinne) ein
"ordentliches" Unternehmen überhaupt haben kann. Die Angaben
schwanken hier von mindestens 3 bis maximal 15. In unserer Erfahrung wird man
sich hier oft bei der "magischen" Zahl 7 +/- 2 einpendeln. Als Beispiel
für eine vergleichsweise allgemeine Gliederung von Unternehmen in Geschäft
