Fest steht, daß der große Durchbruch für die bereits in den 80er Jahren eingeführte Technologie weitgehend ausgeblieben ist. Einen der Gründe dafür sieht Workflow-Spezialist Gerald Pitschek, Geschäftsführer des Klagenfurter Consulting-Unternehmens Intos, in einem verhängnisvollen Mißverständnis bei der Produktpositionierung. Workflow-Lösungen seien lange Zeit als homogene, branchenorientierte Applikationen angeboten worden. In vielen Fällen handelte es sich jedoch um eine von Business- und Anwendungslogik getrennte Infrastruktur, die in aufwendigen Projekten zu einer Fachanwendung geformt werden mußte. Workflow lasse sich ausschließlich zur Abarbeitung einer Prozeßlogik heranziehen, ein Anwendungsproblem sei damit noch nicht gelöst, so Pitschek.
Ulrich Kampffmeyer, Chef der Hamburger Project Consult, ergänzt: Workflow sei früher als ein "Verteilen von Arbeit" beziehungsweise "Informations-Routing" aufgefaßt worden. Heute gehe es dagegen um die "Bearbeitung" an sich sowie um ein "Erschließen von Informationen" - Trendtechniken wie Data-Warehousing und Data-Mining seien dafür gute Beispiele. Statt reinrassiger Workflow-, Dokumenten-Management- oder Archivprojekte, resümiert der Experte seine Erfahrungen mit Kunden, verlangten die Anwender immer häufiger eine Art Document-Warehouse, das von allem etwas bietet.
Traditionelle Workflow-Anbieter geraten deshalb zunehmend zwischen die Fronten. Besonders große Gefahr droht ihnen von Software, die mit einem integrierten Workflow auf den Markt kommt. Dazu zählen Standardpakete von SAP oder Baan, aber auch Productivity-Anwendungen wie Front-Office- und Helpdesk-Produkte.
Ein Beispiel für eine solche Lösung liefert die zum Hoechst-Verbund gehörende Firma Infraserv, die infrastrukturelle Dienstleistungen innerhalb des Konzerns übernimmt und zusammen mit der Coopers & Lybrand Unternehmensberatung einen "R/3-Business-Workflow" im Vertriebsmodul (SD) eingeführt hat. Der Prozeß beginnt bei den Infraserv-Kunden, die ihre Aufträge anhand eines Bestellkatalogs und der dort aufgeführten Materialnummern vergeben. Sie können aus dem kundeneigenen R/3-System als "Idoc" (EDI-konformes Dokument) über die SAP-Technik Application Link Enabling (ALE) an Infraserv verschickt werden. Die Business-Workflow-Applikation zerlegt die einzelnen Auftragspositionen in sogenannte "Workitems" und verteilt sie automatisch auf die R/3-Eingangskörbe der Sachbearbeiter. Von dort aus können sie bis an die entsprechende Werkbank weitergeleitet werden.
Der hier vereinfacht dargestellte Prozeß macht die derzeit noch wesentlichen Unterschiede des SAP-Systems zum Workflow von Drittanbietern deutlich. Während sich marktgängige Workflow-Produkte in einer heterogenen Anwendungslandschaft einsetzen lassen, ist Business Workflow auf R/3 beschränkt, öffnet sich aber über die BAPI-Technik zunehmend anderen Applikationen etwa im Office-Bereich. Außerdem muß R/3-Workflow derzeit eher noch als Infrastruktur denn als Applikation für die dokumentenbasierte Vorgangsbearbeitung betrachtet werden.
Hier sind jedoch Veränderungen zu erwarten - nicht umsonst beschäftigt SAP seit rund fünf Jahren eine eigene Abteilung mit den Themen Dokumenten-Management und Workflow. Die hier entwickelte Schnittstelle "Archivelink" erlaubt die Verknüpfung von Dokumenten mit SAP-Anwendungsobjekten. Außerdem soll eine Workflow-gesteuerte Bearbeitung dieser Dokumente quer durch das Unternehmen möglich werden.
Damit ist SAP auf dem besten Weg, außer den 20 Prozent strukturierten Unternehmensdaten, die von den Walldorfern ohnehin schon verwaltet werden, nun auch den Wust der übrigen Informationen in den Griff zu bekommen. Erklärtes Ziel ist es, so der Leiter der SAP-Abteilung Business Process Technology, Franz-Josef Fritz, stärker als bisher auch unstrukturierte Dokumente in R/3-Geschäftsprozesse einzubeziehen und sie mit einem Workflow zu versehen. Dabei werde auch an Funktionen für flexible Vorgangsabläufe gedacht.
Für die reinen Workflow-Anbieter bedeutet die Entwicklung SAPs verschärfte Konkurrenz. "Wo R/3 drin ist, haben Stand-alone-Produkte nur wenig Chancen", beschreibt Bernhard Zöller von der Frankfurter Unternehmensberatung Zöller & Partner die derzeitige Situation. Ausnahmen sind administrative Abläufe außerhalb von R/3. SAPs Business Workflow sei wie andere Produkte für strukturierte, geschäftskritische Abläufe nicht einfach zu implementieren und deshalb für Ad-hoc-Aufgaben eher ungeeignet.
Kampffmeyer ist ebenfalls der Meinung, daß SAP für die meiste Unruhe sorgen wird. Das Thema Workflow- und Dokumenten-Management sei bislang von allen Anbietern betriebswirtschaftlicher Standardsoftware vernachlässigt worden - SAP habe dies erkannt.
Mit Aufmerksamkeit verfolgt Kampffmeyer die Orientierung des Branchenriesen an den einschlägigen Standards, darunter die der Document Management Alliance (DMA) und der Workflow Management Coalition (WfMC). Interessant daran sei, daß DMA und das Open Document Management API (ODMA) eine neue Middleware neben Archivelink bedeuten. DMA ist zumindest offener als die R/3-Schnittstelle: Die Norm beschreibt eine unabhängige Server-Schicht, über die im Fall SAP ein R/3-GUI auf die Dokumenten-Repositories unterschiedlicher Hersteller zugreifen könnte. Archivelink wäre damit auf längere Sicht ersetzbar.
Allerdings ist DMA nicht ganz so "neutral", wie man vermuten möchte. Um den Standard schneller auf den Weg zu bringen, hat die Allianz Microsoft mit ins Boot geholt, so daß die DMA-Technik nun weitgehend auf COM und DCOM beruht. SAP wird sich damit einmal mehr zur Office-Welt von Windows bekennen.
Bedenken äußert Kampffmeyer auch hinsichtlich der WfMC. Das Hersteller- und Anwendergremium arbeitet an Schnittstellen zur Interoperabilität von Workflow-Systemen, kommt aber in der Entwicklung praxistauglicher Standards nur sehr träge voran. Sollte die Koalition scheitern, wird der Markt laut Kampffmeyer weiterhin von Insellösungen geprägt sein. Darin bestünde eine zusätzliche Gefahr, daß traditionelle Produkte ins Hintertreffen gegenüber kaufmännischen Anwendungen mit integriertem Workflow geraten. Das derzeit im Internet-Umfeld diskutierte Simple Workflow Access Protocol (SWAP) als einfache, auf dem Hypertext Transfer Protocol (HTTP) basierende Alternative soll nicht zuletzt einem solchen Szenario vorbeugen.
Unter Druck steht der Workflow-Markt allerdings nicht nur seitens der Häuser für Anwendungssoftware. Unterscheidet man Workflow in seine beiden extremen Spielarten "Production" für die meist einfache, aber stark strukturierte Vorgangsbearbeitung sowie "Ad-hoc" für flexible, teamorientierte Prozesse, so sind es gerade letztere, die sich auch mit Groupware-Add-ons gestalten lassen.
Das Anwenderinteresse für derartige Lösungen scheint groß. Intos-Chef Pitschek, in Österreich und im süddeutschen Raum aktiv, stellt inzwischen eine gewisse Hemmschwelle bei IT-Managern fest, sich auf starre Prozesse festzulegen. Obwohl dem Production-Workflow derzeit noch ein weltweites Marktwachstum von jährlich 20 Prozent zugebilligt wird, ist eine zumindest teilweise Abkehr von dieser Variante der Vorgangssteuerung deutlich zu beobachten. Selbst bei Versicherungen und Finanzdienstleistern, den Pionieranwendern von Production-Workflow, gruppieren sich um den strukturierten Kern eines Geschäftsprozesses (Antragsbearbeitung und Kontoführung) immer auch einige Bereiche mit kreativen Abläufen (Koordination, Abstimmung und Entscheidungsfindung).
Hinzu kommt, so Kampffmeyer, daß Workflow nicht selten hinter anderen Problemen zurücktritt: Die Praxis zeige, daß Anwenderunternehmen derzeit eher bemüht sind, ihre Bürokommunikations-Plattform mit den verschiedenen Office-, Dokumenten-Management-, Groupware- und Archivlösungen zu vereinheitlichen. Workflow spiele dabei zwar auch eine Rolle, die in dem Zusammenhang anfallenden, meist aufwendigen Prozeßdefinitionen möchte man aber möglichst vermeiden.
Ein sinnvolles Vorgehen sieht Pitschek in einer Geschäftsprozeßanalyse, in der die eindeutig als Production-Workflow erkennbaren Bereiche isoliert werden.
Für alle anderen Abläufe sollten zunächst Ad-hoc-fähige Workflow-Tools eingesetzt werden, um sie in eine erste, aber flexible Automatisierungsphase zu bringen. Innerhalb dieses Experimentierstadiums könne dann festgestellt werden, welche Prozesse geeignet sind, um sie ebenfalls in Zement zu gießen, und welche Vorgänge nur mit Hilfe einiger in der Ablauforganisation festgelegter Stützpunkte stabilisiert werden sollten.
Solche Vorhaben lassen sich auch mit anderen, auf Notes oder Exchange basierenden Produkten starten, wobei sich nach Meinung Pitscheks ein deutlicher Trend hin zur Microsoft-Welt abzeichnet. Nahezu euphorisch nutzen deshalb traditionelle Workflow-Anbieter die von Exchange bereitete Spur, um einen Fuß in die Tür des Anwenders zu stellen. Das Prinzip dabei: Native Workflow-Produkte werden abgespeckt und über COM und Scripting an Exchange angeflanscht.
Diese Strategie berge allerdings die Gefahr, so Pitschek, daß sich Workflow-Hersteller speziell im Ad-hoc-Umfeld ihren eigenen Markt wegrationalisieren. Microsoft selbst werde aller Voraussicht nach hinzugekauftes Workflow-Know-how in Windows NT oder in Exchange als Back-Office-Komponente integrieren, so daß sich die Rolle der Drittanbieter auf Modellierungs-Tools oder applikationsbezogene Zusatzfunktionen reduzieren könnte. Geplant sei ein "Workflow-Enabling" des Exchange-Front-ends "Outlook", das Microsoft als gesamtheitlichen "Info-Desktop" positionieren will. Es soll möglich werden, neben der Verwaltung von E-Mails, Terminen und anderen Aufgaben auch Workflow-Management innerhalb der Office-Umgebung zu betreiben.
Kampffmeyer vermutet ebenfalls, daß Microsoft mit einem Tool für den Ad-hoc-Workflow kommen wird - allein schon, um die Rückständigkeit von Exchange gegenüber Lotus Notes aufzuholen. Kurzfristig ließe sich Outlook verbessern, auf längere Sicht kämen Server-Module in Betracht. Prozeßorientierte Workflow-Lösungen seien damit allerdings nicht in Gefahr, da unternehmensweite Projekte nicht "Out-of-the-Box" betrieben werden können.
Ein Beispiel für Microsofts Strategie ist die bevorzugte Kooperation mit Eastman. Die ehemalige Wang- und jetzige Kodak-Tochter bietet außer High-end-Produkten aktuell auch flexible Windows-Anwendungen für Imaging, Workflow und Speicher-Management (Archive) an. Ein abgespecktes Programm des Imaging-Produkts ist schon jetzt integrierter Bestandteil von Windows 95, über ein ähnliches Vorgehen beim hierarchischen Speicher-Manager für NT 5.0 verhandeln beide Unternehmen derzeit. Davon allein wird man sicher nicht leben können, heißt es bei Eastman.
Angesichts dieser Entwicklung rechnen die Experten mit vier Gruppen, die sich künftig den Workflow-Markt teilen werden. Neben den Herstellern von Gesamtanwendungen mit integriertem Workflow wie SAP wird es die Plattformanbieter geben, allen voran Microsoft, die ohne Applikationsbezug ihre Infrastruktur mit Workflow-Mechanismen versehen. Eine dritte Gruppe bilden Konzerne wie SNI (Workparty) oder IBM (Flowmark und EDM-Suite), die sich als unternehmensweite Lösungsanbieter verstehen und ihre Workflow-Produkte im Rahmen eines gesamten IT-Konzepts vermarkten. Dazwischen müssen sich dedizierte Workflow-Entwicklungsumgebungen, also die der traditionellen Hersteller, behaupten.
Überlebenschancen räumt Pitschek letzteren nur in zwei Bereichen ein. Unentbehrlich sei zum Beispiel das Prozeßwissen um bestimmte Branchen, wo es noch reichlich Spielraum in den nicht von Standardsoftware-Anbietern besetzten Anwendungen gibt. Wer seine Lösung weiterhin als Alleskönner ohne einen Kontext zu den jeweils vorhandenen Geschäftsprozessen anbietet, der wird scheitern, so der Fachmann.
Als Beispiel für einen nischenorientierten Anbieter mag die Firma CSE gelten, die sich sehr früh mit den Abläufen der öffentlichen Verwaltung beschäftigt hat und nicht zuletzt aufgrund einer Kooperation mit SNI auch einige Erfolge im Behördenumfeld aufweisen kann. Ähnlich geht die Firma Documentum vor, die mit Speziallösungen für die Pharmaindustrie groß geworden ist.
Die andere Möglichkeit besteht laut Pitschek darin, daß ein Hersteller die Engine aus seinem Workflow-Produkt isoliert und sie im Rahmen eines Partnerkonzepts als Plattform für Lösungen von Drittanbietern zur Verfügung stellt. Dieses Konzept verfolgt beispielsweise Staffware. Das ursprünglich auf den Production-Workflow konzentrierte Unternehmen bietet mittlerweile eine Systemvariante für Exchange sowie die native Engine als Basis für Partnerapplikationen an.
Ein äußerst dankbarer Markt für Spezialanwendungen könnte nach Meinung des Klagenfurters der E-Commerce sein. Hier herrsche derzeit noch ein krasses Mißverhältnis zwischen Angebot und tatsächlich Benötigtem. Viele Hersteller zeigen bislang kaum mehr als einen digitalen Warenkatalog.
Das Customer-Front-end enthalte keine Verbindung zwischen einer Bestellung und dem von ihr angestoßenen Beschaffungsprozeß, der idealerweise auf Workflow-Regeln basieren sollte. Wenn hier nichts passiert, droht E-Commerce zu einer isolierten Anwendung und damit zu einem neuen digitalen Medienbruch zu werden. Dies könnte sich fatal auf die Akzeptanz und den Markterfolg des Web-Business auswirken, prognostiziert Pitschek.