Der Begeisterung über Business Re-Engineering Anfang der neunziger Jahre folgte bald die Ernüchterung darüber, daß die technische Unterstützung der reorganisierten Geschäftsabläufe nur sehr langsam vorankam. Heute zeichnet sich ein neuer Schub für die Ablaufsteuerung von Prozessen und damit für Workflow ab. Dies rührt daher, daß Workflow in Bereiche expandiert, die früher nicht angegangen wurden. Der heutige Fokus liegt auf der Integration von Applikationen: Als "Business Integration" bezeichnet, soll sie das ganze Unternehmen erfassen - man spricht in diesem Zusammenhang auch von "Pervasive Workflow". Die Konsequenz daraus: Unterschiedliche Workflow-Systeme müssen miteinander verbunden und Intranet sowie Internet in Geschäftsabläufe eingebunden werden. Außerdem erfordern die "Application-to-Application Process Flows" völlig neue Funktionen, da diese Workflows ohne Personen auskommen.
Integrierte Lösungen nur schwer übertragbar
Die Problemanalyse bei der Workflow-Einführung zeigt zwei sehr unterschiedliche Ausprägungen - abhängig davon, ob die Implementierung das erste Mal erfolgt oder bestehende Systeme erweitert und den heutigen Anforderungen angepaßt werden sollen. Eine Erweiterung hat meist zum Ziel, Workflow über das ganze Unternehmen auszubreiten oder externe Teilnehmer wie Kunden und Lieferanten an interne Prozesse anzubinden.
Die meisten Probleme hier erklären sich aus der Historie. Zum einen ist Workflow in vielen Anwendungen enthalten. Falls nun die eingebetteten Prozesse verändert werden sollen, muß unter Umständen die gesamte Anwendung geändert werden. Zum anderen entstanden Workflow-Produkte als integraler Bestandteil von Dokumenten- und Image-Verwaltungs-Systemen. Diese Lösungen wurden entwickelt, um Abläufe wie das Scannen, Archivieren, Wiederfinden und Bearbeiten von Dokumenten zu automatisieren.
Die Schwierigkeit besteht also darin, daß die notwendigen Workflow-Funktionen integraler Bestandteil bereits existierender Anwendungen und Systeme sind und diese in den meisten Fällen nicht für andere Workflow-Aufgaben verwendet werden können. Für den unternehmensweiten Einsatz reichen sowohl die in Anwendungen eingebetteten als auch die in dokumentenorientierten Systemen verwendeten Workflows nicht aus, da sie keine Funktionen für Business Integration enthalten. Statt dessen werden typische Hub- und Middleware-Features benötigt sowie Interface-Definitionen, die es erlauben, Anwendungen unabhängig von Programmierungs-Paradigmen zu integrieren.
Eine andere Hürde ergibt sich daraus, daß viele Workflow-Anwendungen dezentral eingesetzt werden, weil sie auf Abteilungs- oder Bereichsebene vorangetrieben wurden.
Fairerweise muß man hier anmerken, daß bis vor kurzem übergreifende Workflow-Strategien in den Unternehmen ohnehin nicht existierten. Dies führte in vielen Fällen zu heterogenen Hard- und Software-Umgebungen, die nun untereinander sowie mit anderen Systemen verknüpft werden müssen. Dabei handelt es sich um ein meist unüberwindliches Hindernis, da die bestehenden Workflow-Produkte nur von einem Teil der möglichen Hardware- und Softwareplattformen unterstützt werden. Die einzige Möglichkeit besteht oft darin, die alten Workflow-Anwendungen neu zu implementieren - was mit immensen Kosten verbunden sein kann.
Obwohl man annehmen könnte, daß diese Probleme bei einer Neueinführung von Workflow nicht auftreten, entstehen hier ganz ähnliche Effekte. Auch hier werden die Produkte einseitig im Hinblick auf die Lösung aktueller Probleme ausgesucht. In vielen Fällen wird nicht an die Erweiterbarkeit gedacht, was zur Folge hat, daß der Ausbau eines ersten, erfolgreich installierten Systems ins Stocken gerät, weil die notwendigen Integrationsfähigkeiten und Schnittstellen nicht gegeben sind.
Neben den technischen Schwierigkeiten sind oft auch organisatorische Probleme zu beobachten. Da Workflow-Prozesse in der Regel bereichs- oder firmenübergreifend sind, kommt es nicht selten zu Kollisionen bei der Zusammenarbeit, Arbeitsteilung oder Kompetenzabgrenzung. Erfahrungsgemäß ist diese Herausforderung um so prägnanter, je größer die Workflow-Projekte sind. Der Widerspruch liegt darin, daß Workflow und seine Auswirkungen einerseits auf das Unternehmen in seiner Gesamtheit zu beziehen sind, zum anderen sollen die Lösungen Schritt für Schritt eingeführt werden. Abhilfe versprechen organisatorische Maßnahmen wie transparente Aufgabenverteilungen, Schulungen oder gar Umorganisation.
Wie sehen also die Erfolgsfaktoren auf dem Weg zu einem expandierenden Workflow aus? Natürlich liegt ein erster Schritt in der Auswahl des richtigen Produkts. Selbst bei kleinen, isolierten Projekten sollte das Augenmerk der zukunftsweisenden Bedeutung gelten, denn sehr oft handelt es sich nur um den Anfang eines wesentlich größeren Workflow-Einsatzes. Als Kriterium gilt zum Beispiel die Unterstützung der gängigsten Hardware- und Softwareplattformen. Sogar wenn sich ein Unternehmen strategisch für ein Betriebssystem entschieden hat, kann sich daran erfahrungsgemäß noch etwas ändern.
Ferner sollten für die Applikationserweiterungen State-of-the-art-Integrationstechniken wie Java, Javabeans und Active X zur Verfügung stehen. Unternehmen mit Host-Anwendungen (zum Beispiel Cics oder IMS) haben besonders auf die Funktionen für einen Application-to-Application-Workflow achten, um die existierenden Transaktionen in Workflow-Transaktionen einbinden zu können. Erst damit wird es möglich, den personenbezogenen Workflow so zu erweitern, daß sich Backend-Anwendungen, die in der Regel ohne Personen auskommen, einbinden lassen. In der Praxis existieren beide Workflow-Formen nebeneinander und sogar in gemischter Form.
Ein weiterer Aspekt besteht in der zunehmenden Entwicklung von Workflow zu einer Infrastruktur-Komponente des Unternehmens. Das ausgewählte Produkt muß typische Funktionen einer Middleware, wie sie Produkte auf der Basis von Message-Brokern bieten, übernehmen können. Nur eine garantierte Delivery-Funktionalität in einem internen oder externen Netz ist geeignet, die Recover-Fähigkeit zu gewährleisten, die für ein Produktions-Workflow-System notwendig ist.
Ein absolutes Muß sind auch Funktionen zur Unterstützung von Intranet und Internet. Hier sollten für die Thin-Client-Einbindung HTML-, XML- und Java-Funktionen zur Verfügung stehen.
Was die speziellen Workflow-Standards anbetrifft, haben sich alle namhaften Hersteller dieses Segments in der Workflow Management Coalition (WfMC) zusammengeschlossen, um allgemein anerkannte Definitionen zu erarbeiten. Ziel ist, daß die verschiedenen Produkte via Schnittstellen miteinander kommunizieren können. Der Support der WfMC-Standards ist somit ein wichtiges Auswahlkriterium. Daneben wird von der Object Management Group (OMG) ein Corba-Standard für Workflow mit der Bezeichnung "Jointflow" spezifiziert. Er dient der Integration von Business-Objekten und Workflow und stellt die Verbindung eines Produkts mit der objektorientierten Corba-Welt her.
Erste Projekte oft zu groß angesetzt
Schließlich noch einige Bemerkungen zu Problemen, die häufig zu Beginn der Projektphase auftreten. Die meisten Schwierigkeiten entstehen dadurch, daß die ersten Workflow-Projekte zu groß angesetzt werden. Daraus ergibt sich automatisch eine Unübersichtlichkeit der Prozesse. Oft kommen unzureichende Projektplanung oder mangelhaftes Projekt-Management dazu. Besonders die Unkontrollierbarkeit aufgrund der Komplexität, die Unterschätzung des Anpassungsbedarfs von neuen und alten Anwendungen sowie des Testbedarfs des Gesamtsystems führen zu Einführungsfrustrationen.
Dem läßt sich entgegenwirken, indem man erst mit kleineren Workflow-Projekten als Piloten beginnt und dabei Erfahrungen sowohl bei der Installation und Einführung als auch bei der Benutzung sammelt - immer unter der Voraussetzung, daß bei der Auswahl des Produkts der Endausbau der Anwendung im Auge bleibt. Zu empfehlen ist auch, sich eines Partners mit Workflow-Erfahrung zu bedienen.
Daneben ergeben sich durch die Einführung von Workflow-Systemen auch Verschiebungen von Verantwortungs-, Macht- und Kommunikationsstrukturen. Besonderen Wert sollte man auf Konsens bei der Definition und teilweisen Neugestaltung von Prozeßabläufen legen. Der Unternehmensführung ist deshalb zu empfehlen, die Entscheidung für Workflow nicht zu unterschätzen.
*Günther Werner arbeitet bei der IBM Deutschland Entwicklung GmbH im Bereich Software-Entwicklung für Workflow (gwernerqde.ibm.com).