Wenig Aufwand – große Wirkung

Feature | 31. Oktober 2005 von admin 0

Der Wechsel zum taskbasierten Workflow hat so allmählich stattgefunden, dass viele SAP-Kunden diese Entwicklung noch nicht bemerkt haben. Doch auch bereits im Einsatz befindliche SAP-Software lässt sich ohne Release-Upgrade anpassen. Kunden können nun im bisherigen System angelegte Tasks einfacher und besser darstellen – und dabei stets auf das neueste Entwicklungswerkzeug von SAP NetWeaver zurückgreifen.

Tasks geben den Ton an

In der Client-Server-Welt, in der SAP R/3 und ähnliche Programmiermodelle die Norm darstellten und Umgebungen von einer einzigen Anwendung bestimmt waren, ließen sich Aktionen als synchrone Ketten modellieren. Es war ganz einfach, verschiedene Prozesse oder Aufgaben parallel zu Benutzerinteraktionen ablaufen zu lassen, und es bestand kein Bedarf, das herkömmliche Workflow-Modell zu erweitern. Dann trat ein Paradigmenwechsel ein. Das Web, verteilte Systeme und Web-Services kamen ins Spiel und brachten neue Herausforderungen mit sich. Jetzt musste man auch beim Workflow umdenken. Das Konzept der Task als eigenständiger Einheit entstand. Im Portal sammelt nun ein Arbeitsvorrat, die so genannte Universal Worklist, zentral alle zu erledigenden Aufgaben in einer Liste. Zwar ist die Task nicht völlig unabhängig von den Prozessen, die auf sie zurückgreifen, ganz sicher ist sie jedoch unabhängig von der Software geworden, die diese Prozesse lenkt, sie kann sogar mit einer separaten Software-Engine gesteuert werden.
Damit ist die enge Verknüpfung der Tasks mit den Prozessen, die sie auslösen, hinfällig.
In einer zentralen Organisationsstruktur lässt sich eine Task verschiedenen Benutzern zuordnen, etwa als Gruppe von Attributen für eine bestimmte Position oder in Form von Rollen, die den einzelnen Prozessschritten zugewiesen sind. Einen Anwender, der ein Budgetblatt freigeben kann, wird man zum Beispiel über die Organisationsstruktur ermitteln, einen Benutzer, der für eine Bestellanforderung zuständig ist, dagegen eher über die Customizing-Tabellen, die zu einer Genehmigungsrolle gehören. Die Workflow-Funktionalität von SAP NetWeaver unterstützt beide Ansätze unabhängig von der Zuordnung und gewährleistet, dass die Tasks selbst konsistent bleiben.

Task und Worklist als treibende Kräfte

Kunden, die das taskbasierte Paradigma auf ihren eigenen Workflow anwenden wollen, empfiehlt SAP, in fünf Schritten vorzugehen:

  1. Ein Prozess sollte so angelegt sein, dass er eine Abfolge von Tasks und die überall gültigen Daten, auf die die Tasks zugreifen, definiert. Lokal gültige Daten, die für eine Task benötigt werden, müssen für den Prozess nicht transparent sein.
  2. Während seiner Ausführung stellt der Workflow abzuarbeitende Aufgaben, so genannte Workitems, in der Universal Worklist, dem Arbeitsvorrat, zentral zusammen. Der Workflow bereitet diese Aufgaben für die Benutzer auf, damit sie sie ausführen können.
  3. Wählt der Benutzer eine Aufgabe aus, löst die Worklist eine entsprechende Task aus. An diesem Punkt wird der Workflow inaktiv, die Worklist wird zur treibenden Kraft.
  4. Nun fragt eine Instanz der Task die Instanz des Prozesses nach Daten zum Kontext ab – und das ist neu. Die Daten werden also nicht mehr per Push übermittelt, sondern per Pull von der Task angefordert; treibende Kraft ist jetzt die Task.
  5. Ist die Task abgeschlossen, sendet sie diese Information an den Workflow zurück, der dann die entsprechende Aufgabe aus der Worklist entfernt.

Die Bedeutung der Schritte drei und vier wurde erst kürzlich erkannt. Die Worklist ist für die Instanziierung einer Task zuständig, und die Task führt ein Eigenleben. Ob der Workflow nun über eine Windows-, Web- oder Java-Oberfäche dargestellt wird – er wird unabhängig von der Oberflächentechnologie und einfacher portierbar.

Von der Theorie zur Praxis

Damit die Task bei ihrer Instanziierung durch die Worklist weiß, wie sie den Workflow adressieren kann, etwa über RFC, oder auf welchen Prozessschritt, das heißt auf welche Aufgabe in der Worklist, sie sich bezieht, müssen die Workflow-Entwickler geringfügige Anpassungen im Code vornehmen. Dabei lässt sich der Task zugleich auch der Mechanismus kommunizieren, der die Ergebnisse ihrer Anfragen an den betreffenden Prozess zurückleitet.
Die Vorteile dieses Modell: Die Benutzeroberfläche lässt sich auf einem anderen Softwaresystem entwickeln als der Workflow. Die Worklist ist systemunabhängig: es handelt sich um eine einzige Liste abzuarbeitender Aufgaben für verschiedene Workflow-Systeme oder Lösungen verschiedener Release-Stände, beispielsweise für Workflows in SAP R/3 und in mySAP CRM. So können Benutzer eine Task, die per Internet Transaction Server oder Windows-Oberflächentransaktion modelliert wurde, zum Beispiel durch eine aktuelle Web-Dynpro-Anwendung ersetzen. Dies lässt sich mit Hilfe von interaktiven Adobe-Formularen erreichen, die die Daten für die Benutzer aufbereiten. Der Workflow muss nicht geändert werden und kann im ursprünglichen System weiterlaufen, selbst wenn dieses veraltet sein sollte. Kunden können die Workflow-Definition beibehalten und die Benutzeroberfläche verbessern, ohne in den Backend-Prozess einzugreifen.

Erfrischend wenige Neuinvestitionen

Buch: Workflow- Management

Buch: Workflow- Management

Auch wenn ein Unternehmen seine Prozesse ständig optimiert und neuen Geschäftsanforderungen angepasst hat, mag es in seinem Interesse sein, die Benutzungsoberfläche zu verbessern, ohne Grundlagen anrühren zu müssen. Mit taskbasierten Workflows bleiben Administration und Monitoring ebenso unberührt von Veränderungen wie das Berichtswesen. Obwohl ein Prozess in einem völlig neuen Gewand daherkommen mag und beispielsweise zu jeder Task zusätzlichen Business-Kontext aufbereitet, fallen kaum Investitionskosten für diese Änderung an. Die Kunden müssen dazu lediglich neuen Code für die Task-Oberfläche schreiben – ein Kinderspiel in einer modernen Entwicklungsumgebung wie dem SAP Web Application Server. Anschließend wählen sie die Benutzungsoberfläche aus, die ihnen für ihre Benutzer am besten geeignet erscheint: Adobe-Formulare, Java Web Dynpro oder auch die Oberflächenvorlagen Enterprise Service Interface (ESI) – ganz nach Belieben. Außerdem muss der Aufruf der Aufgabendaten über Workflow Application Programming Interface (WAPI) programmiert werden, da die ID-Nummer der abzuarbeitenden Aufgabe als Parameter an die Task übergeben wird. Das erfolgt in der Regel über XML, so dass es keine Einschränkungen hinsichtlich der Datentypen (Listen, Zeichenfolgen oder Strukturen) gibt. Die Definition des Workflows muss selbst bei der Konfiguration der Worklist nicht geändert werden.
Das taskbasierte Modell verhilft den Kunden zu höherer Produktivität, besserer Administrierbarkeit und größerer Benutzerzufriedenheit – spektakuläre Ergebnisse mit minimalem Aufwand.

Quelle: SAP Insider

Alan Rickayzen

Alan Rickayzen

Tags:

Leave a Reply