Einleitung    Ziel    Vorgehen    Analyse    Übersicht 

Einleitung

Geschäftsprozessmanagement (BPM = Business Process Management) ist derzeit das Schlagwort schlechthin in Wirtschaftsunternehmen. BPM ist selbst ein neuer Wirtschaftszweig erfüllt von Beratern und Softwareherstellern unterstützt von eigenen Lehrstühlen. Der Prozessmanager ist ein eigenes Berufsbild. Geschäftsprozessmanagement beschäftigt sich mit Steuern, Herausfinden, Gestalten, Dokumentieren und Verbessern von Geschäftsprozessen.

Wer macht was wann wie

Bisher beschäftigt sich dieser Bereich mit der Planung und Modellierung von Geschäftsprozessen. In der Regel liegen den Prozessen auch Kennzahlen zugrunde, die dann wieder bei Auswertung zur Optimierung verwertet werden können.

Als gar nicht so weit entfernter neuer hype rast auch der Begriff SOA durch IT-unterstützte Unternehmen, was so ziemlich jedes Unternehmen ausmachen sollte. Serviceorientierte Architekturen sind Softwaresysteme, die aus wiederverwendbaren Bausteinen bestehen, welche jeweils einen bestimmten Dienst zur Verfügung stellen. Die Bausteine kommunizieren nach außen und untereinander über standardisierte Schnittstellen. Ein Service ist also ein bestimmte Funktionalität die im besten Fall genau einer Komponente eines Geschäftsprozesses entsprechen soll. Es ist also angestrebt, dass eine Infrastruktur entsteht, die an den vorhandenen bzw. gewünschten Geschäftsprozessen ausgerichtet ist.

Insgesamt ist die Anwendung von BPM und SOA weitreichend ausformuliert und technisch unterstützt.
Das Problem: Wer findet die richtigen Teilkomponenten eines Geschäftsprozesses, um diese mit wiederverwertbaren Kennzahlen zu versehen? Wie komponiere ich diese Komponenten, um einerseits den Ist-Zustand aber die Optimierung darzustellen? Wer definiert die Granularität der einzenlen Komponenten?
In der Regel wird dies vom Fachbereich selbst erwartet. Dieser arbeitet aber seit Jahren schon so selbstverständlich in seiner Welt, dass es ihm kaum möglich ist seine Funktionsweise so zu dokumentieren, dass ein Außenstehender dies nachvollziehen kann.

In der IT treffen wir auf ähnliche Probleme:Wer findet in bestehenden Systemen die Services, die dann wiederverwendbar sind und dabei Sinn machen? Für eine Objektorientierte Softwareentwicklung gibt es inzwischen Ansätze, wie man ein Problem in einzelne Klassen und deren Funktionsweise sinnvoll spliten kann. Bei der "SOSE" (Serviceorientierte Softwareentwicklung) sind die Ansätze bisher sehr beschaulich.

Neben den "lokalen" Problemen Geschäftsprozesskomponenten bzw. Services richtig zu entdecken, deren sinnvolle Komposition bzw. Orchestrierung zu vollziehen, existiert ein erst recht nicht zu verachtendes Kommunikationsproblem.
Da Fachbereiche die Geschäftsprozesse modellieren (und somit dokumentieren) und die IT die Services findet und umsetzt, stehen hier zwei - wie die Erfahrungen der Vergangeheit und Gegenwart zeigen - völlig unterschiedliche Sprachen sprechende Instanzen gegenüber.
Meist sind das sogar konkurrierende Instanzen, da z.B. der Fachbereich in der IT die Rationalisierungsgefahr sieht und die IT im Fachbereich den komplizierten Störer der Selbstbeschäftigung.

Ziel dieser Plattform wird es sein, Methoden zu finden und zu publizieren, die der BPM und der SOA die nötigen Ansätze schafft, um überhaupt angewendet werden zu können.
Ebenso wird es die Vereinbarung schaffen, die die Konkurrenz reguliert. Daher der Begriff Wissenkartell.
Die Kommunikation wird synchronisiert werden, d.h. die einzelnen Ergebnisse (fachlich und technisch) sollen durch den Fachbereich überprüfbar gekoppelt werden. Ein Paket aus Geschäftsprozesskomponenten entspricht einem Paket aus IT-Services.
Im besten Fall lässt sich daraus ein System entwickeln, in dem der Fachberiech selbst durch Design von Paketen die Konfiguration von Softwarepaketen durchführt.
Für die Langlebigkeit eines solchen Verfahrens kommt man auch nicht umhin regelmäßig eine Prozess- und Serviceinventur durchzuführen.
Dieses Ziel nennen wir Reale Programmierung