Neue Workflows - und ab geht die Post

Karin Quack arbeitet als freie Autorin und Editorial Consultant vor allem zu IT-strategische und Innovations-Themen. Zuvor war sie viele Jahre lang in leitender redaktioneller Position bei der COMPUTERWOCHE tätig.
Die IT-Unterstützung ihrer betrieblichen Workflows verwirklichte die Deutsche Post AG (DPAG) in zwei Stufen. Als das Standardsystem an seine Grenzen stieß, setzte sie die Architektur neu auf.

Kaputte Glühbirnen nachbestellen, Druckerpapier und anderes Büromaterial ordern, die Gebäudereinigung kontrollieren und Kassenfehlbestände nachverfolgen - das sind nur ein paar Beispiele für betriebliche Prozesse, wie sie im Alltag der meisten Unternehmen vorkommen. Gerade weil es sich oft um lästige Kleinigkeiten handelt, müssen solche Abläufe möglichst standardisiert und automatisiert ablaufen. Sie mit Hilfe von Telefon, Fax und handschriftlichen Zetteln nachzuverfolgen kostet Zeit und führt zu Fehlern.

"In der Dienstleistungsbranche herrscht ein hoher Qualitätsanspruch mit gleichzeitigem Kostendruck", erläutert Andreas Richter, Leiter der Abteilung Entwicklungssteuerung Managementsysteme Filialen im Bereich IT Brief Business Line Filialen: "Das erfordert eine schnelle und effiziente Abwicklung der internen betrieblichen Abläufe." Davon würden letztlich auch die Kunden der Deutschen Post profitieren.

Hauptkriterium Time to Market

Aus diesen Gründen beschloss der Fachbereich Filialservice der Deutschen Post AG vor etwa vier Jahren, ein elektronisches Workflow-Management-System für die rund 2000 eigenen und zirka 12 000 Partnerfilialen einzurichten. Mit einer solchen Applikation sollte die Vorgangsbearbeitung effizienter, schneller, flexibler und weniger fehleranfällig werden. Nebenbei wünschte sich das Filial-Management auch eine Anbindung an das Unternehmens-Data-Warehouse, um anhand der aufgelaufenen Daten beispielsweise die Performance einzelner Dienstleister auswerten zu können.

Bis dahin basierten die betrieblichen Abläufe auf Telefongesprächen, Faxen und E-Mails. Die Grundfrage lautete: Wie lassen sich die mehr als 200 größtenteils papiergestützen Workflows informationstechnisch abbilden? Unter der Führung der Fachabteilungen wurden alle Abläufe auf ihr Digitalisierungspotenzial untersucht - anhand der folgenden Fragen:

  • Mit welchen Prozessen lassen sich durch eine Digitalisierung die größten Vorteile erzielen?

  • Welche Prozesse kehren in derselben Form häufig wieder, erzeugen also eine große Verkehrsmenge?

  • Bei welchen Prozessen hält sich die Komplexität im Rahmen, so dass sie sich leicht digital abbilden lassen?

Am Ende der Untersuchung waren 50 Abläufe identifiziert, die informationstechnisch umgesetzt werden sollten.

Etwa gleichzeitig begann die Produktauswahl. In die engere Wahl kamen:

  • Microsoft mit Sharepoint,

  • IBM mit Lotus Workflow und

  • SAP mit einer ERP-basierenden Lösung.

Obwohl die Deutsche Post flächendeckend SAP-Software und auch Microsoft-Produkte, unter anderem den Sharepoint Server, einsetzt, machte die Lotus-Workflow-Lösung das Rennen. Ausschlaggebend waren "die schnelle Pilotierbarkeit und die günstigen Umsetzungskosten", so Karsten Preimeß, Projektleiter auf Seiten der DPAG IT Business Line Filialen: "Unser Hauptbeweggrund war, schnell am Markt zu sein und die Effizienzvorteile auszuschöpfen."

Tatsächlich ließ sich schon in der Entscheidungphase ein funktionsfähiger Pilot erstellen, der 2005 live ging: Ab April wurde eine begrenzte Anzahl von Workflows in ausgewählten Filialen abgebildet, im November begann der Echtbetrieb in der Fläche. Der CIO-Bereich IT Brief - in Gestalt von Preimeß und seinen Mitarbeitern - erhielt den Auftrag, das System zu betreiben.

Der Last nicht gewachsen

Nachdem die Lösung von den Mitarbeitern und vom Betriebsrat akzeptiert war, nahm die Anzahl der implementierten Prozesse schnell zu. Doch nach einigen Monaten zeigte sich, dass die mit Standard-Features von Lotus Workflow umgesetzte Applikation der steigenden Last wohl nicht gewachsen sein würde. "Im Herbst 2006 wurde das System immer langsamer, bis es beinahe stillstand", erinnert sich Preimeß.

Den entscheidenden Grund dafür nennt der selbständige Systemarchitekt Andreas Rhode, der vom Preimeß-Team ins Boot geholt worden war: "Eine Lotus-Datenbank kann nur eine begrenzte Anzahl von Dokumenten verwalten, denn die Indizierung wächst im Quadrat zu den Dokumenten." Bei mehr als 100 000 Dokumenten ging das System folglich mehr oder weniger zwangsläufig in die Knie.

Es bestand also akuter Handlungsbedarf. "Jetzt hieß es, schnell eine Lösung finden - und zwar ohne Funktionseinbußen", bestätigt Preimeß. Das gesamte System sollte neu aufgesetzt werden, um die im Standardsystem nicht intendierte Skalierbarkeit einzubauen, ohne dem Nutzer Unbequemlichkeiten aufzubürden: "Es ist ja nicht zumutbar, dass der User für jeden Workflow in eine neue Anwendung wechselt."

Ziele der neuen Architektur

  • Die Prozesse sollten auf verschiedene Anwendungsinstanzen in Lotus Workflow verteilt werden, um das System skalierbar zu machen.

  • Die Filialleiter sollten mit einer leicht zu handhabenden Anwendung von Routinearbeiten entlastet werden.

  • Der Zugang zu allen Filial-Management-Prozessen sollte konsistent und für den Anwender transparent sein.

  • Mehr Flexibilität, vor allem eine leichtere Erweiterbarkeit des Funktionsumfangs mit Hilfe von neuen Workflows, waren ebenfalls gefragt.

  • Höhere Zuverlässigkeit und eine bessere Wartbarkeit des Systems hießen die von der IT gewünschten Ziele.

Vielmehr sollten die Leiter der Außenstellen von Routinearbeiten entlastet werden. Gleichzeitig wollten sich auch die IT-Fachleute die Arbeit erleichtern. Das runderneuerte System sollte sich nicht nur problemlos durch neue Workflows erweitern, sondern auch noch einfach warten lassen. Und last, but not least forderten die Fachbereiche, so Preimeß, "eine hohe Verfügbarkeit und eine einfache, schnelle Umsetzung ihrer Anforderungen".

Mit der Neukonzeption der Workflow-Architektur beauftragte die Post das Unternehmen Mettenmeier Business Solutions (MBS) mit Sitz in Paderborn. Es setzte sich im Rahmen einer Ausschreibung gegen ein rundes Dutzend Konkurrenten durch - vor allem deshalb, weil es geballtes Lotus-Workflow-Know-how vozuweisen hatte.

Lego-Modell statt Monolith

Mettenmeier beschäftigt das Kernteam des im April 1999 von Lotus übernommenen Workflow-Spezialisten Onestone, Entwickler der heute als Lotus Workflow bekannten Vorgangsbearbeitungs-Software (damals unter dem Namen "Processware" vermarktet). Seine Fachkenntnisse konnte MBS eigenen Angaben zufolge auch schon bei Konzernen wie Infineon, Wintershall oder Eon unter Beweis stellen.

Die Paderborner hatten zudem ein überzeugendes Konzept in petto: Ihre - bei der DPAG erstmals umgesetzte - Lösung besteht darin, die monolithische Lotus-Datenbank zu zerlegen und den Workflows sowie dem Archiv jeweils eine eigene Datenbank zuzuordnen. Dirk Stelloh, Projektleiter auf der MBS-Seite, nennt dieses Konzept das "Lego-Modell".

Um den Workflow-Bauchladen handhabbar zu machen, entwickelte der Dienstleister auf der Basis von Lotus Domino ein Portal, das die unterschiedlichen Anwendungsinstanzen maskiert. Für den Anwender stellt sich das System als eine Einheit dar. Dass er über das Portal auf viele unterschiedliche Lotus-Workflow-Systeme zugreift, bleibt ihm verborgen. Auf diese Weise gelang es MBS, trotz der hohen Vorgangsvolumina gleichzeitig Skalierbarkeit, Performance und Benutzerkomfort sicherzustellen.

Anfang 2007 nahm MBS die Arbeit auf. Zu Spitzenzeiten waren acht MBS-Entwickler beziehungsweise -Berater vor Ort. Zunächst interviewten sie die Fachbereiche, um die Zielgrößen zu ermitteln. Wie viele Anwender sollen auf das System zugreifen? Mit welchen Verkehrsmengen ist zu rechnen? Auf diesen Informationen setzte die Planung des Workflow-Systems auf.

Im Juli 2007 war das neue System reif zur Auslieferung. Wie MBS beteuert, zählt es zu den weltweit umfangreichsten Lösungen auf Basis von Lotus Notes/Domino und Lotus Workflow. Insgesamt sind 2500 Benutzer registriert, davon 2000 in den Filialen und 500 im Filial-Management.

Eine Million Workflows pro Jahr Was Skalierung in diesem Zusammenhang bedeutet, verdeutlicht eine chronologische Aufstellung der Workflow-Lasten: 2005 lag die Zahl der Workflows bei 200 in der Woche, das sind rund 10 000 im Jahr; im Jahr darauf hatte sie sich schon verzehnfacht, betrug also etwa 100 000, davon 20 000 allein im Dezember. 2007 musste das System mehr als 400 000 Workflows verarbeiten. Derzeit werden monatlich 60 000 Vorgänge initiiert und abgearbeitet; Preimeß rechnet die Gesamtzahl für das laufende Jahr auf 700 000 hoch. Für 2009 erwartet er 1,1 Millionen.

Die rapide wachsende Vorgangsmenge und die große Zahl der gleichzeitig zugreifenden Benutzer waren die größten Hürden, die das System nehmen musste. Daneben war die keineswegs triviale Lastverteilung über mehrere Anwendungs-Server zu meistern. Außerdem sind die Standorte teilweise mit unterschiedlichen Bandbreiten ans Coporate Network angebunden.

Ständig kommen neue Abläufe hinzu

Diese Hindernisse sind überwunden. Wie Preimeß versichert, kann die Workflow-Lösung heute mühelos 500 Vorgänge in der Stunde initiieren. Sie sei in allen DPAG-eigenen Filialen installiert. Zehn Fachbereiche ließen ihre Workflows bereits darin implementieren. Die Partnerfilialen griffen via Call-Center auf ein "eingeschränktes Bouquet" des Funktionsumfangs zu.

Bislang sind 70 Prozesse realisiert. Ständig kommen neue hinzu, die entweder bislang papiergebundene Abläufe ersetzen oder auch neu entwickelt werden.

Projektsteckbrief

Branche: Dienstleister, Retail und Logistik.

Projektkategorie: Skalierbare Workflow-Lösung mit Anbindung von Reporting-Funktionen.

Kernprodukte: Lotus Domino 7.0.3 im Cluster, Lotus Workflow 7.0, Nortel ApplicationSwitch 2424, HTTP-Proxy "Squid 2.6", Schnittstellen-Engine "Lotus Enterprise Integrator" (zwischen Lotus und SAP).

Systemumgebung: Windows Server 2004, SQL Server 2000, MS Office 2002.

Aufwand: bislang etwa 18 Personenjahre (neun bis zum Go-Live des Prototypen, weitere neun danach).

Herausforderungen: Das Standardsystem erwies sich als nicht skalierbar; deshalb musste die Architektur noch einmal neu aufgesetzt werden.

Ergebnis: einfache, effiziente Abläufe für die Nutzer und flexible, einfach zu wartende und zu erweiternde Lösung für die IT.

Zeitrahmen: Inbetriebnahme des Piloten im Frühjahr 2005, Neuentwicklung der Architektur ab Anfang 2007, Go-live der skalierbaren Lösung Mitte 2007.

Dienstleister: Mettenmeier Business Solutions, Paderborn.

Ansprechpartner: Karsten Preimeß, Deutsche Post, IT Business Line Filialen, Darmstadt.

Veröffentlichen und recherchieren Sie aktuelle IT-Projekte unter: www.10projects.de.

Pro Jahr sind zwei bis drei Releases geplant. Sie sollen jeweils etwa ein Dutzend Workflows enthalten und einen Entwicklungsaufwand von 300 bis 500 Personentagen repräsentieren.

Schnittstelle zum Data Warehouse

Technisch betrachtet, setzt sich das System aus mehreren Schichten zusammen. Der Netzverkehr ist über intelligente Proxy-Server davon entkoppelt, der Datenverkehr wird zwischengepuffert. Laut Systemarchitekt Rhode geschieht die Lastverteilung mittels eines Failover-Systems, das im kommenden Jahr durch ein Full-Balancing-System ersetzt werden soll.

Im Mai dieses Jahres wurde eine Near-Realtime-Schnittstelle zum SAP-Modul "Real Estate" in Betrieb genommen. Ein Interface zum ebenfalls auf SAP-Software basierenden Data Warehouse ermöglicht dem Filial-Management Auswertungen über die Workflow-Daten, die jede Nacht überspielt und im Warehouse kumuliert werden.

Die Vorteile des Systems

Fachliche Vorteile:

  • Viele wichtige betriebliche Fillialprozesse lassen sich nun systemunterstützt, also schnell und effektiv erledigen.

  • Für das Management stellt das System mittlerweile ein wichtiges Instrument zur Provider-Steuerung dar.

  • Über die Schnittstelle zum konzerneigenen Data Warehouse sind vielfältige und individuelle Management-Reports erstellbar.

  • Dank der skalierbaren Plattform können mit relativ geringem Aufwand weitere Prozesse im Konzern automatisiert werden.

Technische Vorteile:

  • Die fachlichen Anforderungen lassen sich auf verschiedene Applikations-Datenbanken aufspalten. Das ist beispielsweise im Hinblick auf die Versionierung sinnvoll.

  • Gleichzeitig fördert das die Wartbarkeit, weil kein Prozess einen anderen berührt. Das heißt auch, dass sich weniger Betroffene miteinander abstimmen müssen.

  • Dadurch, dass die Datenbanken über ein Portal zu einer einheitlichen Oberfläche zusammengefasst sind, können die Benutzer transparent darauf zugreifen.

Bis zur Erstinbetriebnahme am 1. November 2005 hatte die Systementwicklung neun Personenjahre gekostet. Die Weiterentwicklung erforderte einen ähnlichen Aufwand. Dem gegenüber stehen zahlreiche Vorteile fachlicher wie technischer Art (siehe dazu den Kasten "Die Vorteile des Systems). Aus der täglichen Arbeit der Filialleiter lässt sich das System kaum noch wegdenken. Oder wie Abteilungsleiter Richter es formuliert: "Die Deutsche Post arbeitet kontinuierlich daran, ihre internen Prozesse zu verbessern. Das Workflow-Management ist mittlerweile die Lebensader des Filialbetriebs."

Best Practices

  • Man muss den kompletten Lifecycle planen. Die Praxis sieht hinsichtlich Skalierbarkeit, Verkehrsmengen, Konfigurierbarkeit und Ausfallsicherheit oft anders aus als der Pilot.

  • Die Organisationsdaten nicht zu starr in den Prozessen festschreiben! Sonst führt das zu unnötigen Change Requests.

  • Besser mehrere einfache Abläufe als einen komplexen Workflow implementieren, der sich dann nicht mehr handhaben lässt und im Wartungsfall schlimmstenfalls andere Systembereiche blockiert.

  • IT und Fachbereiche sollten zusammenarbeiten - und zwar von Anfang an. Sonst bleiben Fragen der Softwareentwicklung ungestellt.

  • Zeit darf nicht vor Qualität gehen. Rapid Prototyping hat Vor- und Nachteile. Es ist gut, wenn man schnell etwas vorzeigen kann. Aber man sollte auch ein paar Gedanken an die Architektur verschwenden.

  • Die IT sollte den Fachbereich beratend unterstützen - schon ganz am Anfang, wenn die Ablösung der papierbasie-renden Prozesse geplant wird. Auf diese Weise werden die Abläufe auch in systemtechnischer Hinsicht möglichst effizient umgesetzt.

  • Es ist in diesem Zusammenhang sinnvoll, dedizierte Berater für die Fachbereiche auszubilden, die bei der Optimierung der Prozesse helfen.

  • Wer wirklich sparen will, muss erst einmal investieren. Oder anders ausgedrückt: Das meiste Geld wird bei der Konzeption gespart.