Workflow-based Integration

6 Workflow-Projekte (S. 127-128)

6.1 Einleitung
Dieses Kapitel beschreibt eine Vorgehensweise für ein Integrationsprojekt in Verbindung mit einem Workflow (Workflow-Projekt) und die dafür benötigten Rollen der Projektbeteiligten. Es wird darauf hingewiesen, dass es sich hierbei um eine ideale Darstellung handelt und diese für den Praxisgebrauch an das jeweilige Unternehmen und Umfeld angepasst werden muss. Entscheidenden Einfluss auf den Umfang eines Projektes hat die Unternehmensgröße und die vorhandene ITInfrastruktur des Unternehmens. Sind Applikationen und/oder Produkte bereits strategisch gesetzt, so beeinflussen diese Randbedingungen den Aufwand für das Projekt erheblich. Außerdem haben solche zuvor getroffenen Entscheidungen einen wichtigen Einfluss auf eventuelle Evaluierungen von weiteren Teillösungen für die technische Unterstützung von Geschäftsprozessen. Es wird in diesem Kapitel aber nicht auf grundlegende Aspekte von IT-Projekten wie z.B. eine Risikoanalyse oder Fallback-Strategien eingegangen, da eine detaillierte Beschreibung derselben den Rahmen dieses Buches sprengen würde. Allerdings werden diese wichtigen Projektbestandteile häufig nicht ausreichend berücksichtigt. Dies zeigt sich in vielen IT-Projekten, in denen z.B. Risikoanalysen zu selten durchgeführt werden. Dadurch kommt es zu unvorhergesehenen Problemen, die vermieden oder zumindest verringert werden könnten.

6.2 Projektablauf/Vorgehensmodell
In den vorangegangenen Kapiteln wurden die unterschiedlichen Ausgangssituationen für ein Workflow-Projekt erwähnt. Es gilt nun, diese auf die im Unternehmen tatsächlich vorhandenen Strukturen abzubilden. Durch solch eine „Standortbestimmung" kann die Firmenleitung bzw. der Abteilungsleiter den fachlich richtigen Projektstart bestimmen und so die ersten Schritte für das Projekt definieren. Das Ergebnis einer solchen Standortbestimmung kann sein, dass erst die Geschäftsprozesse global dokumentiert und darauf folgend (Teil-)Geschäftsprozesse modelliert und realisiert werden. In dem folgenden Kapitel wird eine Vorgehensweise vorgestellt, deren Struktur es ermöglicht, ein Workflow-Projekt effektiv durchzuführen. Zu Beginn muss jedoch definiert werden, was unter der Projektlaufzeit verstanden wird. Nach der Meinung des Autors wird in bzw. vor einem Projekt die globale Sichtweise eines Projektes zu wenig berücksichtigt.

Es kommt immer wieder vor, dass verzögerte Projekte gestoppt werden und das Ergebnis einer Prüfung (Review) dann zeigt, dass die Ursache für den schlechten Zustand des Projektes die begrenzte Sicht auf das Projektumfeld war. Ein Resultat eines solchen Reviews ist oft, dass kein Informationsaustausch und/oder keine Abstimmungen mit laufenden „Nachbarprojekten" stattgefunden hat. Es ist daher wichtig, dass das eigene Projekt fest in die bestehende System- und Projektlandschaft integriert wird. Workflow-Projekte haben hier einen entscheidenden Vorteil. Sie werden in der Regel von einer Fachabteilung ins Leben gerufen, so dass zumindest bei den fachlichen Anforderungen von einer Absprache innerhalb der Abteilung ausgegangen werden kann6. Somit muss man sich hauptsächlich bezüglich der technischen Realisierung mit anderen Projekten absprechen.

Eine Ausnahme bilden hier die Prozesse in den IT-Abteilungen. Fachabteilungen positionieren und starten ein Workflow-Projekt. Eine Fachabteilung ist somit der Auftraggeber und muss die Randbedingungen wie Budget und Anforderungen festlegen. Der Auftraggeber muss sich im Klaren darüber sein, was die Projektlaufzeit für ihn darstellt und welche Aufgaben auf ihn und die Projektbeteiligten zukommen. Die Projektlaufzeit beginnt mit einem fertig formulierten Projektauftrag und endet – im Falle eines Workflow-Projektes –, wenn der Prozess oder die eingeführte Lösung nicht mehr verwendet wird.

Demnach gehört zur Projektlaufzeit auch der Betrieb und die sich daraus ergebende Wartung eines Prozesses und der unterstützenden Systeme. Ist die Realisierung des Prozesses abgeschlossen und die ITLösung in Betrieb genommen worden, so wird das Projekt aus der Projektorganisation in die Linienorganisation überführt und die Wartung des Prozesses wird in der Abteilung durchgeführt, der der Prozessverantwortliche bzw. Auftraggeber zugeordnet ist. Dies schließt nicht aus, dass bei Erweiterungen wieder andere Abteilungen, insbesondere der IT-Bereich, involviert werden.