Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.03.1999 - 

Groupware und Workflow/Viele Anwender sind schlecht vorbereitet

Die zehn Projekt-Gebote

Zahlreiche Workflow-Projekte scheitern in ihrer ursprünglich geplanten Form. Nicht selten wird verdrängt, daß derart tief in die Organisationsstruktur eingreifende Systeme eine sorgfältige Planung voraussetzten. Volker Halstenbach und Bernhard Zöller zählen die zehn markantesten Stolpersteine auf.

Mangelnde Problemidentifikation: Der folgende Projektansatz - der in der Praxis leider häufiger vorkommt - ist für Workflow- Projekte angesichts der derzeit herrschenden Konfusion am Markt garantiert zum Scheitern verurteilt: Statt vom Problem auszugehen und nach passenden Lösungen zu suchen, wird der umgekehrte Weg beschritten: die Auswahl eines Produkts, das dann auf Biegen und Brechen sämtliche Anforderungen erfüllen soll.

Selbst gute Produkte erweisen sich bei diesem falschen Ansatz als ungeeignet. Der Anforderungskatalog modifiziert sich sehr dynamisch, weil beide Seiten - Anbieter und Anwender - während des Projekts lernen und die Spezifikationen ändern: Der Anwender erkennt die Beschränkungen des Produkts und verlangt Nachbesserungen, der Anbieter versucht Lösungen zu schaffen, deren Funktionalität vorher eher unscharf definiert war. Solche Projekte sind in der Regel sehr langwierig, sehr teuer und selten vorzeigbar. Tip für die Anwender: Die zu lösenden Business- Probleme müssen vorab klar definiert sein.

Manche Workflow-Produkte sind keine: Für den Anwender ist es sehr schwierig, die Unterschiede zwischen einem kompletten Workflow- Standardprodukt und einem Projekt-Framework, das vermarktet wird wie ein Produkt, zu erkennen. Standardlösungen verfügen über fertige Funktionen für die Anwendung und die Systemverwaltung. Die Implementierung erfordert zwar Customizing, manchmal auch Programmierung, aber das nächste Release des Herstellers läßt sich aufspielen, ohne daß die Anwendung zur Hälfte neu geschrieben werden muß.

Dies ist in Workflow-Projekten nicht immer der Fall. Es besteht die Gefahr, daß das Produkt weit über ein normales Customizing hinaus angepaßt wird. Der Kunde erhält dann eigentlich ein eigenes Release, das sich der normalen Release-Pflege mehr oder weniger entzieht. Dies kann vor allem dann eintreten, wenn Großanwender mit Großprojekten locken und der Hersteller dafür bereit ist, Nachbesserungen am Produkt vorzunehmen.

Was vielleicht in der Startphase für einen jungen Anbieter reizvoll ist, gerät später für ihn und für den Kunden zum Alptraum: Draußen im Markt stehen dann verschiedene "Releases", und alle müssen gepflegt werden. Ein Teil der Ressourcen ist dann nicht mehr für die Weiterentwicklung des Produkts, sondern für die Pflege vorhandener Release-Stände aufzuwenden.

Natürlich kann ein Unternehmen bewußt entscheiden, der Sponsor eines neuen Produkts zu sein. Es ist sicher nicht ungewöhnlich, wenn sich Softwarehersteller mit Anwendern zusammentun, denen man großen Einfluß auf die Produktentwicklung zubilligt. Der Benutzer bekommt frühzeitig eine Lösung für seine Probleme, der Anbieter erhält zu einem sehr frühen Zeitpunkt wichtigen Input und direktes Feedback. Aber der Anwender sollte diese Entscheidung bewußt treffen können und nicht zufällig darauf stoßen. Tip an die Anwender: Es ist legitim, manche Produkte als erster zu testen. Trotz aller Verlockung sollten Referenzen über den Hersteller und Erfahrungen von Anwenderkollegen eingeholt werden.

Es gibt kein "One-Size-Fits-all"-Workflow: Ein universelles Workflow-Produkt, das alles kann, gibt es nicht. Zudem zirkuliert eine Vielzahl von Anwendungen, die irreführend von ihren Herstellern als Workflow-Produkte etikettiert werden. In dieser Kategorie finden sich dann Programme wie Lotus Notes, Paravisio Smartflow oder Eastman WFX, die auf Applikationen in einer Groupware- und Messaging Umgebung abzielen.

Unter Workflow firmieren aber auch Produkte wie Staffware Workflow, CSE Workflow, IBM Flowmark , die sich in ganz anderen Anwendungsbereichen mit strukturierten Abläufen oder eigenen Postkorbfunktionen bewegen. Und es gibt Workflow-Produkte, die nur in einer bestimmten Anwendungsumgebung Sinn machen, etwa SAPs Business Workflow für R/3, Filenets Workflo für elektronische Archive, Clarify Workflow für deren Front-Office-Lösung.

Anwender sollten sich vorab über die verschiedenen Workflow- Kategorien und deren Leistungsmerkmale sowie Limitierungen informieren, den notwendigen Konsens hierzu im Projektteam herstellen und dann die fachlichen Anforderungen definieren.

Workflow ist nicht Archivierung: Es gibt eine Reihe von elektronischen Archivsystemen, die über Workflow-Funktionalität verfügen. Dies reicht im einfachen Fall von der reinen Dokumenten- Weiterleitung (entweder das Dokument oder ein Pointer zum Dokument) bis hin zu Workflow-Systemen mit eigener Metadaten- Verwaltung für die Prozesse, die von den Dokumenten angestoßen werden.

Beispiele dafür sind die Lokation eines bestimmten Vorgangs (Wer hat momentan einen Antrag?), Priorität, Gesamtzahl und Liegedauer. Es wäre jedoch falsch, daraus zu schließen, daß sich diese im Archiv- und Dokumenten-Management-Bereich angesiedelten Workflow- Erweiterungen auch für Prozesse oder Vorgänge eignen, in denen Dokumente keine Rolle spielen.

Integration mit Archiven

Diese Workflow-Systeme sind in der Regel hierarchisch der Archiv- oder Dokumenten-Management-Anwendung untergeordnet. Ohne diese Anwendung macht ihr Einsatz keinen Sinn. Wer eine Workflow- Erweiterung für sein Archiv oder Dokumenten-Management benötigt, sollte Produkte auswählen, die eine solche Komponente bereits integriert haben oder sich mit externen Workflow-Produkten integrieren lassen. Der erste Fall ist zwar der weniger aufwendige Weg, aber kaum praktikabel, wenn die eingebaute Workflow- Komponente funktional nicht ausreicht. Wer die Workflow- Architektur auch außerhalb seiner Archivanwendungen einsetzen möchte, kommt nicht um ein Workflow-Produkt herum, das sich ohne eine eigene führende Anwendung integrieren läßt.

Support berücksichtigen: Vor allem im Bereich des Production Workflow stellen die Lösungen hohe Anforderungen, denen bei einer noch sehr jungen und kleinen Mannschaft nicht genügend Support- Ressourcen gegenüberstehen. Die Integration von Workflow-Systemen in andere Anwendungen schafft zusätzliche Komplexität, weil ein Release-Wechsel der zu integrierenden Anwendungen auch die Workflow-Lösung betrifft. Maskenänderungen der Host-Systeme, Änderungen der APIs oder anderer Schnittstellen, auf denen Workflow-Systeme aufsetzen, ziehen in der Regel entsprechende Support-Arbeiten seitens des Workflow-Anbieters nach sich. Je komplexer die eigene Umgebung, desto wichtiger ist die Kontinuität der Support-Mannschaft und daß eine feste (namentliche) Zuordnung der Mitarbeiter erfolgt.

Workflow ist keine Anwendung: Der Begriff Workflow wird von Systemanbietern für unterschiedliche Leistungen verwendet. Bei allen Workflow-Produkten handelt es sich jedoch eher um eine Infrastruktur, häufig auch um eine Integrationsplattform, aber niemals um eine eigenständige Lösung oder Anwendung: Die Applikation, die in der Sachbearbeitung genutzt wird, muß auf der Basis des Produkts erst noch geschaffen werden. Dies können einfache elektronische Formulare in einer Groupware-Lösung oder komplexe Postkorbfunktionen in Production-Workflow-Umgebungen sein.

Workflow ist Infrastruktur und nicht Anwendung

Scheinbar selbstverständliche Basisoberflächen wie der elektronische Postkorb, der in vielen Workflow-Anwendungen auftaucht, sind längst nicht in allen Produkten vorhanden: Dies spricht nicht grundsätzlich gegen das einzelne Produkt. Projektgruppen sollten jedoch wissen, welche Funktionen und Oberflächen im Produkt enthalten sind und welche Anwendungselemente im Rahmen der Projektarbeit fehlen.

Schnittstellen-Probleme nicht unterschätzen: Standard- Schnittstellen sind inzwischen weit verbreitet und erlauben eine relativ einfache Realisierung einer Systemverbindung. Production- Workflow-Anwendungen gelten als Integrationsplattform, in die sich Host-, ERP- und Office-Anwendungen sowie Groupware und elektronische Archive vollständig einbinden lassen: Alle Schnittstellen werden über das System verwaltet und automatisch bedient. Soweit die Theorie! In der Praxis weisen leider auch Standard-Schnittstellen einen natürlichen Lebenszyklus und eine sehr hohe Dynamik auf. Was gestern noch funktionierte, läuft heute schon nicht mehr, wenn auch nur eine einzige Komponente verändert wird - häufig reicht hierfür bereits der Release-Wechsel eines Teilsystems aus.

Die Folgen können fatal sein: Die nicht mehr funktionsfähige, automatisierte Schnittstelle kann einen kompletten Workflow - und damit die Sachbearbeitung - zum Stillstand bringen. Deshalb ist unbedingt darauf zu achten, sämtliche avisierten Schnittstellen in all ihren Abhängigkeiten langfristig zu planen. Eine bewußte Beschränkung der Schnittstellen gewährleistet eine höhere Betriebssicherheit der Anwendung und die Fähigkeit des Unternehmens, auf Veränderungen zu reagieren. Zudem werden die Risiken und Laufzeiten des Projekts verkürzt, die Workflow- Anwendung kommt schneller zum Einsatz.

Idealbesetzung für Projektteams

Projektteams sind unzureichend vorbereitet: Das für ein Projekt gebildete Team sollte sich immer erst intern abstimmen, um erfolgreich mit Externen wie Anbietern zusammenarbeiten zu können. Die Idealbesetzung besteht aus Mitarbeitern der Sachbearbeitung, der Betriebsorganisation und der IT- Betreuung. Über Medien wie Internet, Fachzeitschriften und Kongresse erhalten die Beteiligten eine Vorstellung von der Thematik - ein Gruppenkonsens existiert jedoch nur in den seltensten Fällen. Die einheitliche Formulierung der Anforderungen gegenüber Dritten (Systemanbieter, Berater, Integratoren) gestaltet sich entsprechend schwierig.

Auf der anderen Seite erscheinen Oberflächen von Produkten sehr greifbar und konsensfähig, eine Produktauswahl könnte übereilt fallen. Man sollte deshalb so lange mit den Herstellerpräsentationen warten, bis innerhalb der Projektgruppe ein einheitliches Verständnis der Inhalte existiert.

In einigen Projekten läßt sich sogar beobachten, daß die Budget- und Terminplanung auf einem in reinen Vertriebsgesprächen erworbenen Kenntnisstand basiert. Auch hier sei ein möglichst hohes Einvernehmen der Projektgruppe vor der Kontaktaufnahme zu Systemanbietern empfohlen.

Kurzanalyse der Risiken in früher Projektphase

Zu optimistische Zeit- und Aufwandschätzungen: Es ist sehr schwer, den tatsächlichen Projektaufwand und die Projektrisiken abzuschätzen. Teams, die ohne genaue Kenntnis ihrer Anforderungen erste Einblicke in Workflow-Systeme gewonnen haben, erhalten häufig ein zu einfaches Bild von Workflow-Projekten. Man sollte deshalb in Vertriebsgesprächen klären, welche Funktionen im Lieferumfang des Systems enthalten sind und welche für die Präsentation hinzugefügt (programmiert) wurden. Wichtig ist auch die Demonstra- tion von Ad-hoc-Änderungen (Hinzufügen von Benutzern, Ändern von Regeln, Modifizieren von Rechten etc.). Bereits vor Vertragsabschluß sollte es möglich sein, daß der Systemanbieter einen Projektleiter fest zuordnen kann und dieser eine Kurzanalyse mit Aufwand- und Terminschätzung vorlegt. Somit erhält man bereits in dieser Phase einen wertvollen Einblick in das Know-how und die Vorgehensweise der Projektbetreuung.

Zu komplexe Workflows: Gerade in Workflow-Projekten ist die goldene 80-zu-20-Faustregel zu beachten. Die Gestaltung von Anwendungen sollte in klar trennbaren Teilschritten erfolgen. Sinnvoll ist es, jedem Teilschritt eine Beratung der Projektgruppe darüber folgen zu lassen, welche zusätzlichen Workflow-Funktionen und Integrationen den Anwendern spürbare Arbeitserleichterungen bringen können. Die erwarteten Effekte müssen grob quantifiziert und den definierten Projektzielen, den Randbedingungen und dem Budget gegenübergestellt werden. Ziel von Workflow-Anwendungen muß nicht sein, 100 Prozent aller denkbaren Aktivitäten zu automatisieren.

Angeklickt

Die Einführung von Workflow ist durchaus mit dem vor wenigen Jahren aktuellen Business Pro- cess Re-Engineering (BPR) vergleichbar. Relativ aufwendig ist die detaillierte Analyse von Prozessen beziehungsweise Vorgängen oder Arbeitsabläufen. Ähnlich wirken die Fehler, unter denen offensichtlich die meisten Großprojekte leiden: zu oberflächlich vorbereitete Projektdefinitionen, überfrachtete Erwartungen, mangelnde Produktkenntnis und immer wieder unerwartete Schnittstellen- Probleme bei der Integration.

Volker Halstenbach und Bernhard Zöller sind Berater bei der Zöller & Partner GmbH, einer Consulting-Firma in Frankfurt am Main.