Überschrift

04.09.2008
Von 
Karin Quack arbeitet als freie Autorin und Editorial Consultant vor allem zu IT-strategischen und Innovations-Themen. Zuvor war sie viele Jahre lang in leitender redaktioneller Position bei der COMPUTERWOCHE tätig.

Karsten Preimeß, Projektleiter Post,

Dirk Strelloh, Projektleiter Mettenmeier

Andreas Rhode, selbständiger Systemarchitekt

Abteilungsleiter RICHTER WILL AUCH NOCH ZITIERT WERDEN

1. Was war/ist das Ziel des Projekts?

Workflow-Management der Filialen erneuern - ablösen einer papiergebundenen Vorgehensweise.

Was bedeutet Filial-Management im Detail? Es geht um die betrieblichen Prozesse, Bargeldbestellung, Instandhaltung, Kassenfehlbestände, Einkauf von Büromaterial, Fulfilment (quasi Backend-Prozesse), wenn irgendwas kaputt ist oder nachbestellt werden muss

- Steigerung der Effizienz in der Vorgangsbearbeitung mit Hilfe eines konsistenten Zugangs zu allen Filial-Management-Prozessen - für den Anwender transparent

-

- Vereinheitlichung und Vereinfachung der Abläufe durch Workflow-Mechanismen. Der Filialleiter muss eine einfache Anwendungen haben, weil er eh genug um die Ohren hat (Strelloh)

-

- Steigerung der Skalierbarkeit durch Verteilung der Prozesse auf verschiedene Anwendungsinstanzen in Lotus Workflow.

-

- Mehr Flexibilität durch eine neue Architektur. Leichtere Erweiterung des Funktionsumfangs durch neue Workflows

-

- Gesteigerte Zuverlässigkeit und Wartbarkeit des Systems (s.o.)

-

- Neue, schnellere und bessere Auswertungs- und Reporting-Möglichkeiten (war vom Management gefordert) ; es geht um die Ansteuerung von Dienstleistern, da liegt es nahe, deren Performance zu überwachen.

- Anwender haben weniger Interpretationsspielraum. Das geht schneller und beugt Fehlern vor, wie sie beispielsweise durch das Lesen von Handschriften entstehen)

2. Umfang des Projekts

Für alle Filialen der Deutschen Post direkt oder indirekt über ein Callcenter. Die DPAG betreibt 14 000 Filialen, davon 12 000 Partnerfilialen. In den eigenen Filialen stehen Filialleiter-PCs mit Zugriff auf die Workflow-Lösungen. Die Partnerfilialen nutzen ein eingeschränktes Bouquet (Preimeß) - und zwar via Call-Center.

Was bedeutet: Zentrale Organisationseinheiten stellen "Massen-Workflows" für eine qualifizierte Anzahl von Filialen zur Bearbeitung ein?

Insgesamt sind 2500 Benutzer registriert, davon 2000 in den Filialen. Die restlichen User sind dem Fillial-Management zuzuordnen (Preimeß).

Zurzeit werden monatlich zirka 60 000 Vorgänge initiiert und abgearbeitet - mit steigender Tendenz. Für 2008 rechnet Preimeß mit 700 000 Vorgängen, für 2009 mit 1,1 Millionen.

3. Branche: Dienstleistungen, Retail und Logistik

Hier herrscht, so Preimeß ein hoher Qualitätsanspruch mit gleichzeitigem Kostendruck. Das erfordere eine schnelle und effiziente Abwicklung der internen betrieblichen Abläufe.

4. Welche Herausforderungen galt es im Rahmen des Projekts zu meistern?

Eine Herausforderung ist die sehr hohe Anzahl der Vorgänge sowie der gleichzeitig zugreifenden User via Web. Probleme verursachte die beschränkte Anzahl der Dokumente in einer Lotus-Notes-Datenbank (zirka 100 000). Ferner war die Lastverteilung über mehrere Anwendungs-Server zu meistern. Zudem gibt es im Coporate Network heterogene Bandbreiten. Die User fordern eine hohe Verfügbarkeit und eine einfache, schnelle Umsetzung ihrer Anforderungen.

4. Zeitrahmen

Die ersten Gedanken stammern aus dem Jahr 2004: Wie können wir die papiergestützen Workflows elektrifizieren? Bis dahin hatte die DPAG nur Telefon, Fax, e-Mail im Einsatz.

Unter der Führung der Fachabteilungen wurden ab Ende 2004 die mehr als 200 betrieblichen Prozesse untersucht - hinsichtlich folgende Fragen:

- Mit welchen Prozessen erzielen wir durch eine Elektrifizierung den meisten Benefit?

- Welche Prozesse sind wiederkehrend (erzeugen also eine große Verkehrsmenge)?

- Welche Prozesse sind nicht zu komplex, um sie zu elektrifizieren.

Es zeichneten sich 50 Prozesse ab, die umgesetzt werden sollten.

Etwa um dieselbe Zeit begann die Produktauswahl (ebenfalls unter der Ägide der Fachabteilungen).In der Auswahl waren

- Microsoft (Sharepoint)

- IBM (Lotus Workflow)

- und SAP

Das Rennen machte die Lotus-Lösung, obwohl die DPAG flächendeckend SAP einsetzt. Entscheidend waren die schnelle Pilotierbarkeit und die günstigen Umsetzungskosten. "Unser Hauptbeweggrund war, schnell am Markt zu sein und die Effizienzvorteile auszuschöpfen." (Preimeß)

Schon in der Entscheidungphase einen Piloten erstellt, der Mitte 2005 live ging. Die Fachabteilung übergab Preimeß und seinen Mitarbeiters das System, um es zu betreiben. Im November 2005 starte der Echtbetrieb - zumindest auf dem Papier.

De facto hatte der Betriebsrat zunächst offenbar gravierende Bedenken gegen das neue System und legte ein Veto ein. Diese "Abstimmungsprobleme mit dem Sozialpartner" (Preimeß) zogen sich ein dreiviertel Jahr hin, so dass das System nicht vor Mitte 2006 wirklich in der Praxis genutzt wurde. Dabei wurde plötzlich offenbar, dass die Standard-Features von Notes Workflow augenscheinlich nicht für derartige Volumina ausgelegt sind.

Das liegt laut Rhode an der begrenzten Anzahl von Dokumenten, die eine Lotus-Datenbank verwalten kann: "Die Indizierung wächst im Quadrat zu den Datensätzen." Deshalb ist die Zahl der Dokumente auf rund 100 000 begrenzt. Und das heißt: Ab einer gewissen Verkehrsmenge verursacht die Standardlösung Probleme. "Im Herbst 2006 wurde das System immer langsamer, bis es beinahe stillstand", erinnert sich Preimeß.

Zudem waren die Prozesse nicht optimal implementiert, ergänzt Strelloh. IBM hatte sich als Bodyleaser positioniert und alles implementiert, wie es gefordert wurde. So entsteht die Tendenz, den Papierprozess eins zu eins ins System zu übersetzen: "Aber das kann nur der erste Schritt sein, denn so entsteht keine Ersparnis".

Es gab also Handlungsbedarf. "Jetzt hieß es: schnell eine Lösung finden - und zwar ohne Funktionseinbußen." (Preimeß) Das gesamte System sollte - diesmal zusammen mit der IT - neu aufgesetzt werden. Ziel war er, 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", so Preimeß.

Was Skalierung bedeutet, verdeutlicht eine Aufstellung der Workflow-Last

2005: 200 Workflows in der Woche, also rund 4000 im Jahr

2006: 100 000 Workflows im Jahr, allein 20 000 im Dezember

2008: hochgerechnet 700 000

2009: erwartete 1,1 Millionen

Mit der Neukonzeption beauftragte die Post das Unternehmen Mettenmeier Business Solutions (MBS) mit Sitz in Paderborn. Es setzte sich in der Ausschreibung durch, weil es geballtes Lotus-Workflow-Knowhow vozuweisen hatte. Dort fanden viele Entwickler eine neue Aufgabe, die bei Onestone am Workflow-System "Processware" gebastelt hatten, bevor IBM die Software kaufte und als Lotus Workflow auf den Markt brachte.

MBS konnte ein überzeugendes Konzept vorlegen. Die Lösung der Paderborner besteht darin, die monolithische Lotus-Datenbank zu zerlegen, indem jeder Workflow eine eigene Datenbank erhält (Lego-Modell, so nennt es Strelloh). Für den Anwenderkomfort entwickelte MBS ein Portal, das über alle Workflows gelegt wurde, so dass die User transparent auf die unterschiedlichen Applikationen zugreifen können.

Anfang 2007 nahm MBS die Arbeit auf.

Zunächst wurden die Fachbereiche interviewt, um die Zielgrößen zu definieren: wieviele User, welche Verkehrsmengen etc.

Im Juli war die neue Architektur reif zu Auslieferung.

4. Was ist der Stand des Projekts heute?

Heute kann das System mühelos 1000 Vorgänge am Tag initiieren.

Das System ist in sieben Ländern eingeführt.

Es gibt für jeden Workflow eine Notes-Anwendung sowie eine fürs Archiv.

Das System ist nach oben offen: Es besteht aus mehreren Schichten, der Netzwerkverkehr ist davon entkoppelt, der Datenverkehr wird zwischengepuffert. Hardware und Software sind voll skalierbar, so Rhode. Es gibt Pärchen von Proxies. Die Lastverteilung funktioniert über ein Fail-over-System, das im kommenden Jahr durch ein Full-Balancing-System ersetzt werden soll.

Zehn Fachgebiete sind bereits beteiligt.

Bislang sind 70 Prozesse realisiert, und für Prozess gibt es einen (!) Owner.

Es kommen immer wieder neue Prozesse hinzu, die die papiergebundenen ersetzen oder neu entwickelt werden.

Wenn sich ein Fachbereich einen neuen Workflow wünscht, muss er einen Business-Case mitliefern.

Über die Umsetzung entscheidet das Sachgebiet Sicherheit/Workflow-Management auf Basis der Informationen von der IT-Seite.

Im Mai dieses Jahres wurde auch eine Near-Realtime-Schnittstelle zu SAP Real Estate in Betrieb genommen.

Es gibt zwei bis drei Releases im Jahr, die jeweils etwas ein Dutzend Workflows enthalten und 300 bis 500 Personentage erfordern.

Eine Schnittstelle zum SAP-basierenden Datawarehouse "ISIS" ermöglicht dem Filial-Management Auswertungen über die aufgelaufenen Daten (Oneway). Diese werden jede Nacht überspielt und im Warehouse kumuliert.

MBS hat das auch zum ersten Mal gemacht. Stelloh: "Lotus Workflow ist nicht einfach so skalierbar. Unsere Kernindee war, die Limitationen von Lotus Domino zu umgehen und das System auf weiteres Wachstum anzulegen." Das Portal hat MBS auf der Grundlage von Lotus Domino individuell für die Post entwickelt.

7. Können Sie Angaben zum finanziellen Aufwand machen?

Bis zur Erstinbetriebnahme am 1. November 2005 kostete das System neun Personenjahre, in den Weiterentwicklungsprojekten noch einmal soviel.

8. Worin bestehen die mit der neuen Lösung erzielten Vorteile?

Fachlich:

- Eine Vielzahl von wichtigen betrieblichen Fillialprozessen kann nun systemunterstützt schnell und effektiv erledigt werden

- Was bedeutet: Massenprozesse lassen sich top down genauso über das WFM (= Workflow-Management) initiieren wie individuelle Vorgänge buttom up?

- Für das Management ist das System mittlerweile ein wichtiges Instrument zur Provider-Steuerung.

- Dank der Schnittstelle zum konzerneigenen Data-Warehouse lassen sich jetzt vielfältige und individuelle Management-Reports erstellen.

- Mit relativ geringem Aufwand lassen sich nun weitere Prozesse im Konzern automatisieren - dank der skalierbaren Plattform.

Technisch:

- Aufspaltung der fachlichen Anforderungen auf verschiedene Applikations-Datenbanken. Das ist auch sinnvoll im Hinblick auf die Versionierung. Außerdem fördert es die Wartbarkeit, weil kein Prozess einen anderen berührt und an den Abstimmungen weniger Betroffene teilnehmen müssen.

- Zusammenfassung der Datenbank über ein Portal zu einer einheitlichen Oberfläche für die Benutzer mit transparentem Zugriff.

- Fail-Over-Lösung über Lotus-Notes-Cluster.

- Otpmierung der Auslieferung statistischer Daten durch einen vorgeschalteten http-Proxy (Squid 2.6).

9. Aus welchen Produkten setzt sich die technische Basis zusammen?

- Betriebssystem: Microsoft Windows Server 2004

- Applikations-Server: IBM Lotus Domino 7.0.3 im Cluster

- Schnittstellenplattform: IBM Lotus Workflow 7.0

- Relationale Datenbanksoftware: Mirosoft SQL-Server 2000

- Office-Suite: Microsoft Office 2002

- Loadbalancer: Nortel Application-Switch 2424

- HTTP-Proxy: Squid 2.6, Open-Source

- Browser: Internet Explorer

- Lotus Enterprise Integrator (Schnittstelle-Engine, in diesem Fall genutzt zwischen Lotus Notes und SAP)

- SAP-Connector,

- ODBC

Wie kommt die "universelle Aktivitätenliste” (Portal-Backend) zustande, wo wird sie erfasst, wie zur Verfügung gestellt?

Was bedeutet: Beliebige Verteilung der Anwendungsdatenbanken in Bezug auf die Anwendungsarchitektur?

Und was: Beliebige Verteilung auf Systemressourcen optional?

9. Wer hat das Projekt umgesetzt?

Mettenmeier Business Solutions setzte sich im Request for Information und Request for Proposals durch.

Daneben waren die IT Brief und der Fachbereich Sicherheit/Workflow-Management der Post an der Realisierung beteiligt.

11. Welche Besonderheiten lagen vor?

- Integration bestehender Anwendungen wie SQL Server und SAP

- Anlieferung der Daten über unterschiedliche Kanäle (Mail, SQL Server etc.)

- Große Zugriffsmengen auf ein und dieselben Prozesse

- Häufige Organisationswechsel im Fachbereich (erst Retail GmbH, jetzt Teil von DPAG Brief)

- Hohe Anforderungen an die Konfigurierbarkeit (was bedeutet das?)

12. Was war der Anlass für das Projekt?

Die Prozesse zur Unterstützung des Betriebs der Filialen waren mit ihrer papierbasierten Verfahrensweise zu langsam und zu unflexibel.

Das installierte Lotus-Domino- und Lotus-Workflow-System war nicht skalierbar.

15. Was steht in Ihrem Haus als nächstes Projekt an?

Ab nächstes Jahr Langzeitarchivierung in bearbeitbaren Paketen (sowohl nach Workflows als auch zeitlich - je nach Aufkommen)

Architektur wird vom Fail-over-Prinzip zu echtem Load-Balancing wechseln, siehe Grafik ( CN = Corporate Network)

Die Menüsteuerung und das GUI sollen überarbeitet werden.

Projektsteckbrief

Projektart: Aufbau einer skalierbaren Workflow-Lösung mit Anbindung von Reporting-Funktionen.

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

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

Branche: Dienstleister, Retail und Logistik.

Umfang: für alle Filialen der Deutschen Post direkt oder indirekt über ein Callcenter, insgesamt 2500 Benutzer.

Zeitrahmen: Vorüberlegungen 2004, Inbetriebnahme des Piloten Mitte 2005, Neuentwicklung der Architektur ab Anfang 2007, Go-live der skalierbaren Lösung Mitte 2007.

Produkte: Windows Server 2004, Lotus Domino 7.0.3 im Cluster, Lotus Workflow 7.0, SQL Server 2000, MS Office 2002, Nortel Application-Switch 2424, HTTP-Proxy "Squid 2.6, Schnittstellen-Engine "Lotus Enterprise Integrator" (zwischen Lotus und SAP).

Dienstleister: Mettenmeier Business Solution, Paderborn.

Herausforderungen: Das Standardsystem war nicht skalierbar; deshalb musste die Architektur neu aufgesetzt werden.

Nächste Schritte: Wechsel vom Failover zum echten Load-Balancing; Langzeitarchivierung der Workflows; Überarbeitung der Benutzeroberfläche und Menüsteuerung.

Best Practices

  • Man muss den kompletten Lifecycle planen. Die Praxis sieht oft anders aus als der Pilot (hinsichtlich Anwenderzahlen, Archivierung, Komplexität).

  • Die Organisationsdaten der dürfen in den Prozessen nicht zu starr implementiert werden, sonst führt das zu unnötigen Change Requests.

  • Lieber mehrere einfache Workflows als ein Mammutsystem implementiern, das man nicht mehr selbst handhaben kann und das im Wartungsfall andere Teile blockiert.

  • IT und Fachbereiche sollten von Anfang an zusammenarbeiten. Sonst bleiben Fragen der Softwareentwicklung nicht gestellt.

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

  • Die papierbasierenden Prozesse dürfen nicht eins zu eins in Software gegossen werden.

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

  • Man muss am Anfang investieren, um nachher zu sparen.