Workflow-Management mit SAP

Alan Rickayzen , Jocelyn Dart, Carsten Brennecke, Markus Schneider

Workflow-Management mit SAP

Effektive Geschäftsprozesse mit SAPs WebFlow Engine

Workflow-Administration 159

6 Workflow-Administration

Der Administrator spielt eine wichtige Rolle für den Erfolg des Workflows, sowohl in technischer Sicht, als auch bezüglich der Akzeptanz, die der Workflow bei den Beteiligten besitzt. Wenngleich diese Pflichten nur einen geringen Zeitaufwand erfordern, sind sie von großer Bedeutung und müssen ernst genommen werden: Sollten Probleme auftreten, muss der Administrator sie schnell und überzeugend lösen.

6.1 EinführungIntegration mit mySAP.com

Rückmeldungen von Benutzergruppen bestätigen immer wieder, dass dieAdministration von WebFlow Engine weitaus weniger zeitaufwändig ist,als die Administration von Software anderer Anbieter, die eine Integrationmit den mySAP-Komponenten versucht. Dies wirkt sich nicht nur auf denlaufenden Betrieb, sondern auch auf die Vereinfachung von Upgrades unddie Gesamtstabilität des Systems aus. Der Grund dafür ist zweifelsohne,dass sich SAPs WebFlow Engine im Zentrum des Systems befindet, undnicht von außen darauf einwirkt. Gleichzeitig stimmt der Release-Zyklusder mySAP-Komponenten exakt mit dem der Engine überein. Die Ent-wicklung von Engine, Geschäftsanwendungen und Workflow-Musternerfolgt also im Gleichtakt, sodass sie während des Upgrades im Betrieb desKunden nicht mühsam aneinander angepasst werden müssen.

Um die folgende einfache Grundregel kommt jedoch niemand herum:Wenn Sie mit einem System arbeiten, benötigen Sie einen Systemadmi-nistrator. Wenn Sie mit einem Workflow arbeiten, benötigen Sie einenWorkflow-Administrator.

TippIst der Workflow Schuld?

Die Erfahrung zeigt, dass wenn es nach der Aktivierung eines Workflowszu Problemen mit beliebigen Teilen des Geschäftsprozesses kommt, inder Regel dem Workflow die Schuld gegeben wird, wobei es keine Rollespielt, ob dies gerechtfertigt ist. Dies ist eine sehr natürliche Reaktion sei-tens der Mitarbeiter, die an dem Geschäftsprozess beteiligt sind, denn:

Für Workflows, die mit Web-Funktionalität arbeiten, kann auch eineUnterstützung durch den Webserver- bzw. den ITS-Administrator erfor-derlich sein, um Fehler zu beheben und die Performance zu überwachen.


� Der Workflow steuert ihre Sicht des Geschäftsprozesses.

� Der Workflow steuert ihren Zugriff auf den Geschäftsprozess.

� Der Workflow steuert den Fluss des Geschäftsprozesses zwischenihnen und anderen Benutzern.

� Der Workflow führt Teile des Geschäftsprozesses automatisch aus, diedie Mitarbeiter nicht manuell ausführen können oder von denen sienicht erwarten, dass sie diese manuell ausführen müssen.

Entwicklung undAusführung von

Reports

Wenn ein unternehmenswichtiger, grundlegender oder sehr umfangrei-cher Prozess erfolgreich ist, kann das große Vorteile mit sich bringen. AlsWorkflow-Administrator liegt eine Ihrer Aufgaben aus folgenden Grün-den gegebenenfalls in der Entwicklung und Ausführung von Reports

� um zu belegen, dass Vorteile erzielt wurden

� um Implementierung und Supportkosten des Workflows zu rechtfer-tigen

� um den Geschäftsfall zum Ändern des Geschäftsprozesses und/oderdes Workflow-Designs zu belegen

� um darzulegen, dass Änderungen am Workflow die gewünschten Aus-wirkungen hatten

� um aufzuzeigen, dass die Benutzer Aufgaben effizient und umgehendausführen

6.2 Reporting zu Workflows

Mit Workflow werden standardmäßig zahlreiche Reports bereitgestellt.Mithilfe von Werkzeugen wie dem Workflow-Informationssystem (WIS)oder dem Business Information Warehouse (BW) können Sie viele weitereReports erstellen. Wenn das System keinen Standardreport zur Verfügungstellt, können Sie einen eigenen Report erstellen. Weitere Informationenzur Erstellung benutzerdefinierter Reports finden Sie in Kapitel 13, Benut-zerdefinierte Programme. Die hier angegebenen Reports dienen als nütz-licher Ausgangspunkt. Sie können jedoch auch nach anderen Reportssuchen. Wenn standardmäßige Workflow-Muster für bestimmte Transak-tionen oder Daten erstellt wurden, gibt es für diese häufig spezielle Work-flow-Reports.

Standardreports Alle Standardreports bieten einen Zugriff auf die Workitem-Anzeige, aufdas Workflow-Protokoll mithilfe der Option und auf allgemeine Re-portfunktionen, wie z.B. Sortieren, Filtern, Ändern des Layouts usw. BeiAuswahl einer Workflow-Instanz zeigen die meisten Reports die wichtigs-

Reporting zu Workflows 161

ten bislang ausgeführten Schritte und deren Bearbeiter sowie die wesent-lichen bisher verwendeten Objektinstanzen. In den meisten Standard-reports können Auswahlkriterien angegeben werden, um die Liste aufeine bestimmte Aufgabe, Aufgabengruppe, Komponente bzw. einen be-stimmten Auswahlzeitraum (heute, letzte Woche, letzten Monat, letztesJahr, alle) oder auf aktive und/oder abgeschlossene Instanzen zu beschrän-ken.

Workflow- und Workitem-Status-zustände

Bei der Bewertung von Workflows ist es sinnvoll zu wissen, was die ver-schiedenen Workflow- und Workitem-Statuszustände bedeuten. Einevollständige Liste finden Sie in Kapitel 13, Benutzerdefinierte Programme.Hier sind die Statuszustände angegeben, die am häufigsten angezeigtwerden:

6.2.1 Reporting zum Workflow-Fortschritt

Reports zum Workflow-Status

Üblicherweise lautet die interessante Frage aller Beteiligten an einemGeschäftsprozess, in welchem Status sich der Workflows zurzeit befindet.Nützliche Reports zum Beantworten dieser Frage sind u.a.:

� Workflows zu ObjektWählen Sie Laufzeitwerkzeuge • Workflows zu Objekt (TransaktionSWI6). Dieser Report zeigt alle Workflow-Instanzen, die mit einerbestimmten Objektinstanz verknüpft sind. In Releases vor 6.10 musszur Verwendung dieses Reports für das Business-Objekt die Schnitt-stelle IFFIND implementiert sein.

Technischer Status

Bedeutung

Bereit Gilt in der Regel für Workitems. Das Workitem wurde erstellt und aktiviert, bislang jedoch noch nicht ausgeführt. Es befindet sich bei-spielsweise im Eingang eines Benutzers, ohne bisher geöffnet wor-den zu sein.

Angenommen Wird in der Workitem-Anzeige als In Bearbeitung angezeigt. Gilt in der Regel für Workitems. Das Workitem wurde von einem Benutzer geöffnet oder angenommen, ohne bislang ausgeführt worden zu sein.

Ausgeführt Wird in der Workitem-Anzeige als Ausgeführt angezeigt. Gilt in der Regel für Workitems. Das Workitem wurde ausgeführt, wartet jedoch darauf, dass der Benutzer das Beenden der Bearbeitung (z.B. über die Option Erledigt setzen) manuell bestätigt.

Beendet Der Workflow bzw. das Workitem ist abgeschlossen. Nach Abschluss sind keine weitere Änderungen mehr möglich.

Tabelle 6.1 Die wichtigsten Workitem-Status


Tipp

� Workflows zu ObjekttypWählen Sie Laufzeitwerkzeuge • Workflows zu Objekttyp (Transak-tion SWI14). Dieser Report zeigt alle Workitems und Workflow-Instan-zen für alle Objektinstanzen eines Business-Objekttyps.

6.2.2 Reporting zur Workflow-Performance

Workitems undWorkflow-Instan-

zen untersuchen

Beim Erstellen von Reports zur Workflow-Performance müssen Sie sowohldie Häufigkeit der Workitems bzw. Workflow-Instanzen sowie den Zeit-raum untersuchen, der für eine realistische Bewertung des Workflow-Ver-haltens benötigt wird. Alle Workflow-Instanzen und Workitems zeichnenden Zeitpunkt des Anlegens, des Starts (Zeitpunkt, an dem das Workitemerstmals geöffnet wurde) und des Endes (Zeitpunkt, an dem das Workitemabgeschlossen wurde) auf. Wird mit Terminüberwachung gearbeitet,zeichnet das Workitem auch die relevanten Terminzeitpunkte auf.

Tipp

Der beste Standardreport zum Abrufen einer entsprechenden zusam-menfassenden Sicht ist Workitems nach Bearbeitungsdauer (TransaktionSWI2_DURA). Dies ist jedoch ein Bereich, in dem das Schreiben eigenerbenutzerdefinierter Reports mithilfe von WIS, BW oder eines eigenenProgramms (falls die beiden Komponenten nicht vorhanden sind) sehrnützlich ist.

Warte- und Bear-beitungszeiten

berücksichtigen

Beim Bewerten der Performance-Zeit ist es wichtig, nicht nur die insge-samt verstrichene Zeit, sondern auch die Warte- und Bearbeitungszeitenzu berücksichtigen. Beispiel: der Workflow hat von Anfang bis Ende fünfTage gedauert. Dabei wurden jedoch vier Tage nur für das Warten aufeine Aktion des ersten Bearbeiters aufgewendet. Wenn Sie den Prozessweiter beschleunigen müssen, sollten Sie ermitteln, ob Sie den Schwer-punkt Ihrer Anstrengungen auf das Verbessern des Workflow-Designs

Dies ist nicht nur für den Administrator einer der sinnvollsten Reportsfür die allgemeine Überwachung, sondern auch für alle anderenBenutzer des Workflows.

Um die Namen der Bearbeiter auszublenden, z.B. aufgrund rechtlicheroder auch gewerkschaftlicher Bestimmungen, legen Sie in der Transak-tion SWPA (Customizing Workflow-Laufzeitsystem) den Customizing-Parameter fest.


oder des Benutzerverhaltens setzen sollten. Wartezeiten können dieFolge verschiedener Faktoren sein.

BeispieleHier einige Beispiele:

� Der Bearbeiter war krank, hat an einer Schulung oder Besprechungteilgenommen, oder war in Urlaub, ohne einen Vertreter zu pflegen.

� Der Bearbeiter hat das Workitem nicht beachtet (d.h. versäumt, seinenEingang regelmäßig zu überprüfen).

� Der Bearbeiter war sich nicht sicher, wie das Workitem ausgeführtwerden sollte.

� Der Bearbeiter musste sich mit anderen besprechen, bevor er das Wor-kitem beenden konnte.

Sie sollten nie davon ausgehen, dass eine lange Wartezeit ein Fehlverhal-ten des Benutzers bedeutet, sondern stets die Ursache der Verzögerunguntersuchen.

Weitere empfehlenswerte Standardreports

Wenn Sie Termine für Ihre Workitems festgelegt haben, können detaillier-tere Analysen durchgeführt werden, z.B. mithilfe des Standardreports Wor-kitems mit Terminüberschreitung (Transaktion SWI2_DEAD). Wenn Sie dieAnzahl der pro Zeitraum bearbeiteten Workitems erfahren möchten, ver-wenden Sie den Report Workitems pro Aufgabe (Transaktion SWI2_FREQ).

6.2.3 Workitems nach Bearbeitungsdauer

Wählen Sie Reporting • Workitem-Analyse • Workitems nach Bearbei-tungsdauer (Transaktion SWI2_DURA). Dieser Report liefert, nach Aufga-ben sortiert, Informationen zur Bearbeitungsdauer der Workitems desangegebenen Typs bzw. zu angegebenen Aufgaben, die in dem Zeitraumbeendet wurden. Vorausgesetzt, es gibt entsprechende Workitems, wirdder aktuelle Zeitraum mit einem vorherigen Zeitraum gleicher Länge ver-glichen. Die Abweichungen und Unterschiede werden angezeigt.

Interpretation der Schwellenwerte

Die Bearbeitungsdauer aller Workitems für eine Aufgabe wird als Stan-dardwert mit drei Schwellwerten angezeigt (Schwellwerte bei 10 %, 50 %und 90 %). Die Schwellwerte müssen wie folgt interpretiert werden: dieBearbeitungsdauer des Schwellwertes x % bedeutet, dass x % aller Wor-kitems für diese Aufgabe innerhalb dieses oder eines kürzeren Zeitraumsbearbeitet wurden. Sie können den Modus ändern, um die Liegezeit (d.h.die nicht genutzte Zeit), die Arbeitszeit und die Gesamtzeit anzuzeigen,was häufig sinnvollere Informationen als die drei Schwellwerte liefert.


Sie können bestimmte Workitems genauer untersuchen. Wenn z.B. diemeisten Workitems in Sekunden ausgeführt wurden, einige andere jedochmehrere Tage dauerten, können Sie diese Workitems eingehender prü-fen, die Bearbeiter ermitteln und diese befragen, warum sie so langegebraucht haben.

6.2.4 Workitems mit Terminüberschreitung

Wählen Sie Reporting • Workitem-Analyse • Workitems mit Termin-überschreitung (Transaktion SWI2_DEAD). Dieser Report zeigt Work-items, die der Terminüberwachung unterliegen. Dieser Report ist beson-ders zweckmäßig, um zu bestimmen, ob Termine eingehalten oderüberschritten wurden, da alle überschrittenen Termine unabhängig davonangezeigt werden, ob das Workitem mittlerweile abgeschlossen ist odernicht. Bei jeder Terminüberschreitung wird der aktuelle Status des Work-items angezeigt.

Da Terminüberschreitungen nach Aufgabe gruppiert angezeigt werden,können Sie rasch erkennen, ob bestimmte Aufgaben wiederholt Schwie-rigkeiten bereiten. Dies kann bedeuten, dass der gesetzte Termin unrea-listisch ist oder eine weitere Schulung, Online-Hilfe o.ä. erforderlich ist.

6.2.5 Workitems pro Aufgabe

Wählen Sie Reporting • Workitem-Analyse • Workitems pro Aufgabe(Transaktion SWI2_FREQ). Dieser Report zeigt die Anzahl der Workitems,die im angegebenen Zeitraum erstellt wurden. Die Liste ist nach Aufga-ben sortiert.

6.2.6 Reporting zum Bearbeiterverhalten

Prüfung desWorkloads

Neben der Überwachung der Geschwindigkeit, mit der Bearbeiter ihreWorkitems bearbeiten, lohnt sich auch die Prüfung des Workloads derBearbeiter. Dies gilt insbesondere, wenn sich die Bearbeiter beklagen,dass sie zu viele Workitems empfangen.

Sie können sowohl den bisherigen Workload (d.h. die Anzahl der Work-items, die der Bearbeiter in einem bestimmten Zeitraum ausgeführt hat)und den künftigen Workload (d.h. die noch nicht bearbeiteten Work-items im Eingang) einer Analyse unterziehen. Um die Workload-Analyseaufzurufen, wählen Sie Reporting • Workload-Analyse (TransaktionSWI5).


Workload-Analyse für vergangene Arbeitsbelastung

Der Report Workload-Analyse für vergangene Arbeitsbelastung ist beson-ders nützlich für das Bewerten des Workloads über bestimmte Zeiträumewie beispielsweise ein Monat oder ein Geschäftsjahr. Um den bisherigenWorkload zu bestimmen, wählen Sie in der Workload-Analyse die OptionErledigt seit. Der Report führt Workitems auf, die vor dem angegebenenDatum beendet wurden. Nur abgeschlossene Workitems werden ange-zeigt. Die Workitems müssen zudem einen tatsächlichen Bearbeiterhaben, bei dem es sich um einen Benutzer handelt, der direkt oder indi-rekt dem Organisationsobjekt zugeordnet ist, das in den Auswahlkriterienangegeben ist.

Sie können sich darüber hinaus die folgenden Statistiken zur Anzahl derWorkitems anzeigen lassen, die von Mitarbeitern abgeschlossen wurden,die mit einer Organisationseinheit, einem Bearbeiter, einer Aufgabe odereinem Enddatum verknüpft sind.

Workload-Analyse für zukünftige Arbeitsbelastung

Der Report Workload-Analyse für zukünftige Arbeitsbelastung ist beson-ders nützlich für das Reporting zu Typ und Häufigkeit von Aufgaben, dieeinem Bearbeiter gesendet werden. Um den künftigen Workload zubestimmen, wählen Sie die Option Zu bearbeiten bis. Die Auswahl erzeugteine Liste mit Workitems, die von den Mitgliedern des Organisationsob-jekts bis zum eingegebenen Datum bearbeitet sein müssen. Wenn Siekein Datum angeben, wird die Workload-Analyse für alle aktiven Work-items durchgeführt.

Die Liste der Workitems ist nach den tatsächlichen Bearbeitern und Auf-gaben sortiert. Am Ende der Liste werden die Workitems und Aufgaben,für die kein tatsächlicher Benutzer vorhanden ist, unter der ÜberschriftVon keinem Bearbeiter angenommen angezeigt.

Tipp

6.2.7 Bestimmen und Begründen potenzieller Verbesserungen

Betrachten Sie nicht nur den Workflow, sondern auch den Prozess alsGanzes. Zwar kann ein veränderter Workflow primär für eine Verbesse-rung des Geschäftsprozesses sorgen, dennoch können auch einfachePunkte dazu beitragen, den Prozess zu optimieren, ohne dass der Work-flow selbst geändert werden muss. Hierzu gehören Punkte wie das Über-

Wenn kein Datum angegeben ist, entspricht der Workload des Benut-zers dem Inhalt seines Workflow-Eingangs. Fehlerhafte Workitemswerden nicht angezeigt.


prüfen, ob alle Bearbeiter an einer Workflow-Schulung teilgenommenhaben, oder das Senden von E-Mail-Benachrichtigungen an Bearbeiterüber ausstehende Workitems oder eine Liste mit häufig gestellten Fragenim Intranet. Die nützlichsten Werkzeuge zum Begründen potenziellerVerbesserungen sind die Fehlerübersicht und Performance-Reports.

Fehlerübersicht In der Fehlerübersicht wird gezeigt, welche Fehler wiederholt auftreten.Häufige Fehler beim Bestimmen von Bearbeitern können insbesondere zustrikteren Regeln bei der Bearbeiterermittlung oder zum Straffen von Pro-zeduren bei der Bearbeiterpflege durch die Personalabteilung und dasSicherheitspersonal führen.

Workflow-Perfor-mance-Reports

Workflow-Performance-Reports zeigen Aufgaben mit langen Warte- undBearbeitungszeiten. Dies kann zu Änderungen am Prozess führen, wiez.B.:

� Verbessern der Online-Hilfe

� Hervorheben der wichtigsten Details für die Entscheidung beim Anzei-gen und Ausführen des Workitems

� Verbessern der Schulung und Sicherstellen, dass alle Bearbeitergeschult wurden

� Senden von E-Mail-Benachrichtigungen über ausstehende Workitemsan den Bearbeiter

� Einrichten von Vertretern

� Verbessern des Eskalationsprozesses durch Benachrichtigen eines Mit-arbeiters, wenn ein Bearbeiter eine Aufgabe nicht rechtzeitig erledigthat, oder durch automatisches Umleiten von Workitems zu einemneuen Bearbeiter, wenn ein Termin überschritten wurde

Webbasierter»Vorschlagkasten«

Es empfiehlt sich, den Bearbeitern und anderen Personen, die am Prozessbeteiligt oder von diesem betroffen sind, die Möglichkeit zu bieten, Vor-schläge zur Verbesserung des Workflows zu machen, z.B. über einenwebbasierten »Vorschlagkasten«. Wenn genügend Bearbeiter ähnlicheVerbesserungen vorschlagen, kann dies schon eine ausreichende Begrün-dung für eine Änderung des Workflows sein.

6.3 Fehlerbehebung

Wenn ein unternehmenswichtiger, grundlegender oder sehr umfangrei-cher Prozess misslingt, hat das große Nachteile für das Unternehmen.Eine rasche Fehlerbehebung ist von großer Bedeutung, wenn das Ver-trauen sowohl in den Geschäftsprozess als auch in den Workflow erhalten

Fehlerbehebung 167

bleiben soll. Halten Sie sich an folgende Maxime: »Bei unzureichenderPlanung sind Ausfälle vorprogrammiert«. Den schlimmsten Fehler, denSie als Workflow-Administrator begehen können, ist es, das Einplanenvon Ausfällen zu unterlassen.

Der wahrscheinlichste Zeitraum für Ausfälle ist der Zeitraum unmittelbarnach der Aktivierung des Workflows bzw. nach Änderungen am Work-flow. Dies ist zudem der wichtigste Zeitraum, um Vertrauen in den Work-flow und den Geschäftsprozess aufzubauen. Sie müssen sicherstellen,dass Sie als Workflow-Administrator wissen, wie wichtig der Prozess ist,wer von dem Ausfall betroffen ist (damit Sie den Betroffenen benachrich-tigen können, dass das Problem bald behoben sein wird), welche Schrittezu unternehmen sind und an wen Sie sich wenden müssen, damit alleFehler schnell und überzeugend beseitigt werden. Dies gilt insbesonderefür den allerersten Workflow, der in Ihrer Organisation aktiviert wird!

Drei Schritte zur Fehlerbehebung

Der Prozess der Fehlerbehebung besteht aus drei Schritten:

1. Erkennen des Problems (per Diagnose)

2. Beseitigen des Problems

3. Verhindern, dass das Problem nochmals auftritt

Werkzeuge zur Fehlerdiagnose

Für die Fehlerdiagnose stehen zahlreiche Werkzeuge zur Verfügung.Diese Werkzeuge reichen von einfachen Reports über detaillierte techni-sche Ablaufverfolgungen bis hin zu komplexen grafischen Anzeigen.Diese Fehlerdiagnose-Werkzeuge werden besonders von Workflow-Ent-wicklern zum Testen ihrer Workflows und bei Bedarf von Workflow-Administratoren zur Fehlerdiagnose verwendet. Aufgrund der großenAnzahl und Vielfalt der Werkzeuge ist die Diagnose ein eigenes Thema,das in Kapitel 14, Erweiterte Diagnose, behandelt wird. Wenn die Work-flow-Administration für Sie Neuland ist, können Sie die Workflow-Ent-wickler um Unterstützung bei der Fehlerdiagnose bitten.

Das Beobachten eines Workflow-Entwicklers bei der Lösung eines Work-flow-Problems ist eine sehr effektive Möglichkeit, sich mit der Diagnosevon Workflow-Fehlern vertraut zu machen. Wenn jedoch ein Workflow-Entwickler eine Problemdiagnose durchführt, beendet er in der Regellediglich die fehlgeschlagene Workflow-Instanz, nimmt einige Änderun-gen vor und startet eine neue Workflow-Instanz. In einer Produktivumge-bung können Sie sich normalerweise nicht den Luxus leisten, fehlgeschla-gene Workflow-Instanzen zu ignorieren. Ihre Aufgabe ist es, das Problemzu beheben. Der weitere Schwerpunkt in diesem Kapitel soll deshalb auf


der Behebung eines Fehlers (nach erfolgter Diagnose), und der Vermei-dung eines nochmaligen Auftretens dieses Fehlers liegen.

Kategorisierungvon Problemen

Die möglichen Probleme zur Laufzeit können in folgende Kategorien ein-gestuft werden:

� Fehler bei der BearbeiterermittlungFür das Dialog-Workitem wurde der falsche oder kein Bearbeiterermittelt.

� PufferfehlerDiese treten üblicherweise auf, wenn der Zugriff auf Workitems fehl-schlägt, obwohl die Pflege der Bearbeiterermittlung und Berechti-gungseinstellungen auf dem aktuellen Stand ist.

� Workitem-FehlerDiese werden in der Regel durch einen falsch modellierten Workflowoder übereilten Transport verursacht. Beispiel: der Workflow berück-sichtigt keine unvollständigen Daten, die aus älteren Systemen extra-hiert wurden, oder Ausnahmen in Objektmethoden werden nichtabgefangen.

� EreigniskopplungsfehlerDiese werden üblicherweise durch Änderungen beim Anwendungs-Customizing oder falsch modellierte Workflows verursacht. Symptomedafür sind, dass der Workflow nicht gestartet wurde, da das auslö-sende Ereignis nicht eingetreten ist oder den Workflow nicht gestartethat, oder der Workflow mitten im Prozess hängenbleibt, da er auf einbeendendes Ereignis wartet, das nie erfolgt.

Mit unerwartetenFehlern rechnen

Wie Sie sehen, kann die Mehrzahl möglicher Fehler durch ein überlegtesWorkflow-Design und sorgfältiges Testen (werden z.B. die Ausnahmenabgefangen?) vermieden werden. Doch trotz der größtmöglichenAnstrengungen der Entwickler kann es aufgrund von Zeitdruck, Unerfah-renheit oder Änderungen durch Mitarbeiter, die mit den entsprechendenAuswirkungen auf den Workflow nicht vertraut sind, immer zu unerwar-teten Fehlern kommen, wenn auch meist nur in der ersten Zeit nach demÜbergang in die Produktivumgebung.

Probleme müssengemeldet werden

Sorgen Sie dafür, dass die am Geschäftsprozess beteiligten Personen wis-sen, dass Probleme sofort gemeldet werden müssen. Einzelberichte da-rüber, dass ein Prozess ausgefallen ist, können häufig nur sehr schwerdem verursachenden Workitem zugeordnet werden. Weisen Sie die Mit-arbeiter deshalb an, Folgendes anzugeben:

Allgemeine Techniken zum Beheben von Laufzeitfehlern 169

� Objektschlüssel (z.B. ob das Workitem auf einem Finanzdokumentbasierte sowie den Unternehmenscode, die Dokumentnummer und/oder das Geschäftsjahr des Dokuments)

� Datumsangaben zum Prozessstart

� Den Zeitpunkt des erstmaligen Auftretens des Problems

Wie zuvor erwähnt, sind Prozesse, die in Workflows integriert wurden,nahezu immer unternehmenskritisch, grundlegend oder höchst umfang-reich. Sollte also ein Fehler auftreten, müssen Sie sofort reagieren unddiesen schnellstmöglich beheben!

6.4 Allgemeine Techniken zum Beheben von Laufzeitfehlern

Lesetipp

In diesem Abschnitt erhalten Sie Informationen zu den Grundeinstellun-gen zur Unterstützung der Fehlerüberwachung sowie zu einigen allge-meinen Techniken zum Ermitteln und Untersuchen von Workitems undfehlerhaften Workflows.

Erforderliche Kenntnisse

Viele der spezifischeren Techniken setzen voraus, dass Sie mit diesenGrundtechniken vertraut sind. Insbesondere benötigen Sie folgendeKenntnisse:

� Zugriff auf ein Workflow-Protokoll und anschließendes Lesen

� Zugriff auf ein Workitem sowie anschließendes Lesen und Ändern

6.4.1 Grundeinstellungen für die Fehlerüberwachung

Es gibt einige Einstellungen für die Workflow-Laufzeitumgebung, die fürdie Fehlerüberwachung zur Laufzeit besonders wichtig sind. Die meistenwerden in Kapitel 3, Konfigurieren des Systems, erwähnt. Weitere Infor-mationen finden Sie jedoch auch im Einführungsleitfaden (IMG). Die

Obgleich die Informationen in diesem Kapitel für Workflow-Adminis-tratoren von entscheidender Bedeutung sind, kann Ihnen der Lesestoffein wenig trocken vorkommen, wenn Sie noch nicht in der Phase sind,in der Sie »echte« Workflows in der Produktivumgebung auslösen.Weiterhin werden Sie feststellen, dass einige Fehleranalysen Kennt-nisse voraussetzen, die erst in späteren Kapiteln vermittelt werden.Aus diesem Grund können Sie nach Wunsch zu Abschnitt 6.8 überge-hen und erst später zu Abschnitt 6.4 zurückkehren, wenn Sie weitereEinzelheiten erfahren möchten.


wichtigste Konfigurationseinstellung legt den Workflow-Administratorfest, sodass fehlerhafte Workitems proaktiv in den Eingang des Administ-rators geleitet werden. Als Workflow-Administrator müssen Sie Ihren Ein-gang regelmäßig überprüfen.

6.4.2 Suchen und Korrigieren von Workitems

Report »Worki-tem-Selektion«

Der beste Report für die Überprüfung des Workflow-Status ist der ReportWorkitem-Selektion (Transaktion SWI1 oder Hilfsmittel � Workitem-Selektion). Dieser ermöglicht die Auswahl und Anzeige von Workitemsaller Typen anhand verschiedener Kriterien. Diese Funktion ist besondersnützlich, um nach »verloren gegangenen« Workitems zu suchen, dieweder im erwarteten noch überhaupt in irgendeinem Workflow-Eingangangezeigt werden. Nachdem Sie das gesuchte Workitem gefundenhaben, bietet dieser Report zudem eine Vielzahl von Optionen zumReparieren des betreffenden Workitems. Der Report ist außerdem beson-ders zweckmäßig, wenn Sie sich einen schnellen Überblick überbestimmte Typen von Workitems verschaffen möchten, z.B. über alleHintergrund-Workitems (geben Sie den Workitem-Typ B ein), um zu prü-fen, ob diese umgehend abgeschlossen werden.

Sie können Workitems mithilfe von Kriterien wie Typ, Status, Kennung derAufgabe/Aufgabengruppe und Erzeugungszeitpunkt auswählen.

Tipp

Zeiträumeangeben

Das Auswahlkriterium ist standardmäßig so festgelegt, dass alle Work-items angezeigt werden, die in der letzten Stunde aktiviert wurden. Stel-len Sie beim Angeben von Zeiträumen sicher, dass der erste Eintrag zeit-lich vor dem zweiten liegt. Beispiel: verwenden Sie keine Zeiträume wie»von 13:05:00 bis 00:00:00«, sondern »von 13:05:00 bis 23:59:59«. Siekönnen auch ein einzelnes Workitem über dessen Kennung auswählen.

Tipp

Durch Setzen des Kennzeichens Ausgabeoptionen können zusätzlich weitereSpalten angezeigt werden. In der sich ergebenden Workitem-Liste könnenSie zur Workitem-Anzeige oder zum Workflow-Protokoll wechseln.

Die Aufgabenkennung muss dem ausgewählten Workitem-Typ entspre-chen. Der Workitem-Typ W steht für Aufgaben (Kennung TSxxxxxxxx).Der Workitem-Typ F steht für Workflows (Kennung WSxxxxxxxx).

Wenn Sie eine Kennung als Auswahlkriterium eingeben, ignoriert dasSystem alle anderen Auswahlkriterien.


Fehlerhafte Work-items korrigieren

Um fehlerhafte Workitems zu korrigieren, stehen unter Bearbeiten • Work-item oder in den Reports zur Administration, die im Administrationsmenüverfügbar sind, zahlreiche Optionen zur Verfügung. Dazu zählen u.a.:

� Restart nach Fehler/Ausführen ohne CheckMit diesen Optionen können Sie ein Workitem ausführen. Ist das Work-item fehlerhaft, verwenden Sie Restart nach Fehler. Wenn das Workitemkeinen gültigen Bearbeiter hat und Sie es dennoch ausführen müssen,wählen Sie Ausführen ohne Check. Mithilfe dieser Option können SieWorkitems ohne entsprechende Berechtigungen ausführen. Deshalbdarf die Berechtigung zum Verwenden dieser Option nur dem Work-flow-Administrator in einer Produktivumgebung erteilt werden.

� Manuell beendenMit diesen Optionen können Sie ein Workitem abschließen, ohne eserneut auszuführen.

� Manuell zurücklegenWenn ein Workitem von einem bestimmten Bearbeiter angenommenwurde, können Sie mit dieser Option die Reservierung aufheben,damit das Workitem in den Eingängen aller Empfänger angezeigt wird.

Tipp

6.4.3 Arbeiten mit der Workitem-Anzeige

Sie können aus den meisten Workflow-Reports, einschließlich der Work-item-Selektion, in die Workitem-Anzeige verzweigen. Die Workitem-Anzeige zeigt detaillierte Informationen zum Workitem und ermöglichtaußerdem das Beheben bestimmter Probleme.

StandardsichtDie Standardsicht (siehe Abbildung 6.1) ermöglicht folgende Vorgänge:

� WeiterleitenD.h. das Senden des Workitems zu einem anderen Bearbeiter

Wenn Sie ein Workitem nach einem Fehler erneut starten, sorgen Siedafür, dass der Neustart mithilfe des Administrationsreports Restartnach Fehler (Transaktion SWPR) erfolgt, um sicherzustellen, dass sowohldas Workitem als auch der Workflow der obersten Ebene neu gestartetwerden. Sie müssen stets prüfen, ob der Neustart des Workflows ord-nungsgemäß ausgeführt wurde, falls ein Fehler auftreten sollte (beidem es sich auch um einen neuen Fehler handeln kann), bevor derWorkflow fortgesetzt werden kann.


� Zurücklegen von Workitems, die von einem ausgewählten Bearbeiterangenommen wurden, damit andere Empfänger sich diese in ihrenEingängen anzeigen lassen können

� Zurückweisen des WorkitemsD.h., der Workflow befolgt den Zurückweisungsweg, der im WorkflowBuilder definiert wurde.

� Ändern von Terminen

� Hinzufügen von AnlagenSie können z.B. erläutern, warum es erforderlich war, ein Workitemohne Bearbeiterprüfung auszuführen. Anlagen erleichtern ein späteresNachverfolgen der Vorgänge.

Zwischen Sichtenwechseln

Sie können zwischen einer Standard- und einer technischen Workitem-Sicht wählen. Die Standardsicht ist hauptsächlich für Endbenutzergedacht. Die technische Sicht bietet verschiedene Zusatzoptionen fürEntwickler und Administratoren. In Ihren persönlichen Workflow-Einstel-lungen können Sie die zu verwendende Sicht voreinstellen. Über dieMenüoption Springen • Technische Workitem-Anzeige können Sie vonder Standard- zur technischen Sicht wechseln.

Abbildung 6.1 Workitem-Anzeige: Standardsicht


StandardsichtDie Workitem-Standardsicht (siehe Abbildung 6.1) dient hauptsächlichder übersichtlichen Anzeige der Informationen zu Dialog-Workitems. Sieenthält Details zu Terminen, Statuszuständen, Bearbeitern, Anlagen undverknüpften Objekten eines Workitems. Bei fehlgeschlagener Ausführungeines Workitems zeigt die Funktion Nachricht die Fehlermeldung oderRückgabecodes für ausgeführte Workitems an. Es ist ratsam, sich mit allenverfügbaren Features in der Workitem-Anzeige vertraut zu machen.

Liste der verfüg-baren Objekte

Alle Objekte mit einer Beziehung zum Workitem, so auch die formalenProzessobjekte und Ad-hoc-Anlagen, werden auf der Registerkarte Verfüg-bare Objekte in der Liste der verfügbaren Objekte angezeigt. Von beson-derem Interesse sind folgende Objekte:

� Das gegenwärtig bearbeitete Objekt (Containerelement _WI_Object_ID des Aufgabencontainers)

� Das zu Gruppierungszwecken hinzugefügte Objekt (Containerelement_WI_Group_ID des Aufgabencontainers)

Sie können sich jedes Objekt, das im Workitem-Container referenziertwird, anhand seines Defaultattributs anzeigen lassen. Wurde kein Default-attribut für den Objekttyp definiert, werden die Schlüsselfelder desObjekts angezeigt. Die Defaultmethode jedes Objekts kann auf Anforde-rung ausgeführt werden.

Tipp

Sie können die Liste der Objekte erweitern und bearbeiten, d.h. Objekteanlegen, anzeigen und entfernen. Der Hauptzweck dafür ist das Bereit-stellen zusätzlicher Informationen für Bearbeiter der Folgeschritte imWorkflow, damit der Bearbeiter z.B. Gründe für das Weiterleiten einesbestimmten Workitems angeben kann.

Bearbeiterkatego-rien angezeigen lassen

Wenn Sie versuchen, Probleme bei der Bearbeiterermittlung zu beheben,oder herausfinden möchten, wer über ein bestimmtes Workitem verfügt,ist Springen • Bearbeiter • ... die nützlichste Workitem-Funktion. Hierwerden die verschiedenen Bearbeiterkategorien angezeigt. Mit einemIcon werden die Benutzer markiert, in deren Eingängen sich das Work-item befindet.

Bei den meisten Objekten ist die Methode Display als Defaultme-thode festgelegt. Wenn Sie also die Details des Objekts, z.B. zurUnterstützung der Fehlerdiagnose, prüfen möchten, müssen Sie sichim Allgemeinen nicht die Mühe machen, die zur Anzeige benötigteTransaktion zu suchen.


Technische Sicht Die technische Workitem-Anzeige enthält alle Informationen zum ange-zeigten Workitem. Diese Sicht ist hauptsächlich für Workflow-Adminis-tratoren gedacht. Abhängig vom Workitem-Typ werden folgenden Datenangezeigt:

� Workitem-Kennung und -Typ

� Workitem-Status

� Tatsächlicher Bearbeiter eines Dialog-Workitems (nach dessen Ausfüh-rung)

Darüber hinaus werden für das Workitem Anhänge und Mails angezeigt.Wenn bei der Ausführung der Methode eine Fehlermeldung erzeugtwurde, können Sie sich diese anzeigen lassen, indem Sie Nachrichtoder Zusätze • Anzeige Rückgabewert wählen. Angezeigt werden dieaktuellen Datums- und Zeitangaben sowie die vom Laufzeitsystem über-wachten Termine (Vorlagetermin und spätester Starttermin sowiegewünschter Endetermin und Frist). Tabelle 6.2 Workitem-Zeitpunktezeigt die verschiedenen Workitem-Zeitpunkte.

Übersicht: Work-item-Zeitpunkte

Ein markierter überwachter Termin zeigt, dass dieser übeschritten wurde.Wenn das Symbol ebenfalls angezeigt wird, wurde vom Hintergrund-job des Termins eine Eskalationsaktion ausgelöst.

Zusatzfunktionenin der techni-

schen Sicht

Neben den Funktionen, die in der Standardsicht der Workitem-Anzeigeverfügbar sind, stehen in der technischen Sicht (Springen • TechnischeWorkitem-Anzeige) darüber hinaus die folgenden Zusatzfunktionen zurVerfügung:

Zeitpunkt Bedeutung

Erzeugungstermin Datum, an dem das Workitem von der WebFlow Engine erzeugt wurde, mit dem Status »Bereit« oder »Wartend« (falls ein Vorlagetermin angegeben wurde).

Startzeitpunkt Datum und Uhrzeit, zu der sich der Status des Workitems erst-mals von »Bereit« in »Angenommen« oder »In Arbeit« ändert, z.B. wenn ein Empfänger das Workitem ausführt.

Endzeitpunkt Datum und Uhrzeit, zu der sich der Status des Workitems in »Beendet« oder »Logisch gelöscht« ändert.

Vorlagetermin Datum, an dem die WebFlow Engine den Status des Workitems von »Wartend« in »Bereit« ändert (falls ein Vorlagetermin ange-geben wurde).

Tabelle 6.2 Workitem-Zeitpunkte


� Bei diesen Workitem-Typen können Sie sich weitere Details anzeigenlassen, indem Sie Springen • Typspezifische Daten wählen:

� Arbeitsvorrats-WorkitemsHier werden die Objekte und Aufgaben im Arbeitsvorrat aufgeführt

� Warteschritt-WorkitemsHier gibt das System die Anzahl der erwarteten und eingetretenenEreignisse an

� Über Zusätze • Instanzkopplungen gelangen Sie zur Definition derInstanzkopplung für beendende Ereignisse oder Warteschritt-Work-items. Dort können Sie bestimmen, welches Ereignis (identifiziertdurch einen Objekttyp und eine Ereignisbezeichnung) von welchemObjekt (identifiziert durch eine Objektreferenz) erwartet wird. Dies istnützlich, wenn das Workitem ausgeführt wurde, jedoch auf ein been-dendes Ereignis wartet, da Sie mithilfe dieser Funktion genau ermittelnkönnen, welches beendende Ereignis und welche Ereigniswerte erwar-tet werden.

� Wählen Sie Zusätze • Container, um den Inhalt des Workitem-Contai-ners anzuzeigen.

� Über die Option Bearbeiten • Ändern können Sie Folgendes ausfüh-ren:

� Ändern des Workitem-Containers, wenn z.B. durch Datenflussfeh-ler falsche oder unvollständige Daten übermittelt wurden

� Logisches Löschen des Workitems, indem es als nicht mehr benötigtmarkiert wird

� Manuelles Beenden des Workitems, ohne es erneut auszuführen

� Sperren/Entsperren des Workitems, um dessen Ausführung zu ver-hindern bzw. den Zugriff darauf zu gestatten

6.4.4 Arbeiten mit der Anzeige des Workitem-Containers

Der Inhalt des Containers des entsprechenden Workitems wird in einerGesamtsicht angezeigt. Die Anzeige enthält die aktuellen, laufzeitspezifi-schen Daten zu diesem Workitem. Wenn Sie sich ein Dialog- oder Hinter-grund-Workitem anzeigen lassen, gehört der Container nur zu diesemWorkitem. Wenn Sie ein Workflow-Workitem anzeigen lassen, gehört derContainer zur gesamten Workflow-Instanz.


Inhalt desContainers

Der Container enthält Folgendes:

� Workflowrelevante Systemfelder

� Auf dem ABAP Dictionary basierende Containerelemente

� Auf Containerelementen basierende Objekte, d.h. Objektreferenzen

Vor Objektreferenzen wird stets die logische Systemkennung angegeben.Auf diese folgt die Kennung des Objekttyps und der zusammengesetzteSchlüssel des Objekts. Wenn Sie eine Objektreferenz ändern müssen, ver-wenden Sie stets die Eingabehilfe im Objektreferenzfeld. Die Eingabehilfeermöglicht die richtige Eingabe des Objektschlüssels, bestimmt die ent-sprechenden System-/Mandantenreferenzen für Sie und prüft, ob dasObjekt vorhanden ist.

6.4.5 Arbeiten mit dem Workflow-Protokoll

Beschränkungender Workitem-

Anzeige

Zur Laufzeit verfügt ein Workflow über ein eigenes Workitem (Typ F), dasdie Workflow-Instanz repräsentiert. Mithilfe der Workitem-Selektion undähnlicher Reports können Sie das Workflow-Workitem Ihres Workflowsermitteln. Die Workitem-Anzeige gibt jedoch nur eingeschränkt Informa-tionen zur Workflow-Instanz. Die beste Möglichkeit der Untersuchungder Workflow-Instanz bietet das Workflow-Protokoll. Das Workflow-Pro-tokoll fasst an zentraler Stelle alle Informationen zusammen, die währendder Ausführung des Geschäftsprozesses (d.h. der Workflow-Instanz)erstellt oder erfasst wurden (siehe auch Kapitel 4, Verteilung von Work-items�.

Mögliche Sichten Die Standardsicht (siehe Abbildung 6.2) ist für Bearbeiter und Prozessbe-sitzer gedacht, die sich einen Überblick über die bislang bearbeitetenSchritte verschaffen möchten. Die technische Sicht ist für Entwickler undWorkflow-Administratoren vorgesehen.

Standardsicht In der Standardsicht werden nur Daten für die wichtigsten Schritttypengezeigt. In der Workflow-Definition können Sie bei Bedarf Schritte mitden obigen Schritttypen von der Anzeige im Workflow-Protokoll aus-schließen. Wenn Sie sich das vollständige Protokoll anzeigen lassenmöchten, wechseln Sie zur technischen Sicht des Protokolls.( ).


Das Workflow-Protokoll enthält die folgenden Registerkarten:

� Workflow-Chronik (Was wurde wann bearbeitet?)Die Registerkarte Workflow-Chronik zeigt eine hierarchische Sicht allerSchritte im Workflow, die bislang bearbeitet wurden oder gegenwärtigbearbeitet werden können. Wenn der Workflow eine Subworkflow-Struktur besitzt, werden die Subworkflows ebenfalls angezeigt. DieFunktion Details (Symbol ) listet im unteren Teil des Bildschirms diefolgenden Informationen zu jedem Schritt auf:

� Die Personen, die bestimmte detaillierten Aktionen für diese Worki-tems ausgeführt haben, und die entsprechenden Ergebnisse

� Den Zeitpunkt der Ausführung dieser Aktionen

� Die beteiligten Objekte

Die Funktion Bearbeiter (Symbol ) zeigt die ausgewählten/mögli-chen/ausgeschlossenen Bearbeiter eines Schritts.

� Workflow-Bearbeiter (Wer hat was bearbeitet?)Die Registerkarte WorkflowBearbeiter (Abbildung 6.3) zeigt die Bear-beiter, die bisher am Workflow beteiligt waren. Für jeden Bearbeiterwerden die folgenden Informationen angezeigt:

Abbildung 6.2 Workflow-Protokoll: Standardsicht


� Die in den verschiedenen Schritten ausgeführten Aktionen

� Der Zeitpunkt der Ausführung dieser Aktionen

� Die beteiligten Objekte

� Workflow-Objekte (Was wurde bearbeitet?)Die Registerkarte Workflow-Objekte enthält die Objekte, die mit demWorkflow verknüpft sind oder bis jetzt in die Ausführung des Work-flows einbezogen wurden. Diese Sicht zeigt, welche Objekte in welcherWeise erstellt und bearbeitet wurden. Zu den Objekten zählen u.a.:

� Das Hauptobjekt des Workflows

� Alle Anlagen und Objekte, die in den einzelnen Schritten des Work-flows hinzugefügt wurden

Für jedes Objekt werden die folgenden Informationen angezeigt:

� Die Personen, die detaillierte Aktionen für die entsprechenden Auf-gaben ausgeführt haben

� Der Zeitpunkt der Ausführung dieser Aktionen

Grafisches Work-flow-Protokoll

Darüber hinaus können Sie in das grafische Workflow-Protokoll verzwei-gen, das die bereits bearbeiteten Schritte ( ) in einer grafischen Dar-stellung der Workflow-Definition zeigt (siehe Abbildung 6.4). Der Haupt-vorteil des grafischen Workflow-Protokolls ist, dass Sie auf einen Blickerkennen können, welchen Weg eine Workflow-Instanz gewählt hat und

Abbildung 6.3 Bearbeiterprotokoll


welche Aktivitäten parallel zu Ihren eigenen innerhalb eines Geschäfts-prozesses erfolgen. Im Gegensatz zur Textversion des Workflow-Proto-kolls zeigt das grafische Workflow-Protokoll darüber hinaus den weiterenWeg der Workflow-Instanz.

Technische SichtDie technische Sicht (siehe Abbildung 6.5) zeigt die technischen Steue-rungsinformationen und ist deshalb hauptsächlich für Workflow-Admi-nistratoren gedacht. Bei einem fehlerhaften Workflow ermöglicht sie aufeinen Blick das Erfassen der Fehlerstelle und aller Meldungen (einschließ-lich Warnmeldungen), die vom Workflow erzeugt wurden. Darüber hin-aus eignet sich diese Anzeige zur Ermittlung des detaillierten Workflow-Ablaufs. Das Workflow-Protokoll wird als hierarchische Liste mit zweiEbenen angezeigt. Mithilfe von Layouts können Sie das Erscheinungsbildder Liste Ihren Anforderungen entsprechend anpassen.

Tipp

Abbildung 6.4 Grafisches Workflow-Protokoll

Wenn Sie die Konfiguration mit dem SAP List Viewer (ALV) als Aus-gangskonfiguration speichern, wird diese Sicht bei jedem Anzeigen destechnischen Protokolls eingeblendet. Es empfiehlt sich, die Ausgangs-konfiguration des Administrators anzupassen, sodass diese neben denStandardspalten stets die Aufgabenkennungen der Workitems anzeigt.


Abbildung 6.5 Workflow-Protokoll – Technische Sicht

Workflow-Chronik In der Sicht Workflow-Chronik zeigt die technische Sicht technische Kno-ten und Steuerstrukturen an und stellt weitere Daten zur Verfügung, wiez.B. Containerelemente ( ), Bearbeiterdaten ( ) und Workflow-Daten ( ). Der Status der einzelnen Workitems wird ebenfalls ange-zeigt.

� Wenn der Workflow den Status »Fehlerhaft« hat, kann das Workflow-Protokoll eine hierarchische Liste zugrunde liegender WebFlowEngine-Funktionsbausteine enthalten, welche die genaue Fehlerstelleangeben. Dadurch können besonders schwer zu ermittelnde Fehlergefunden werden.

� Wenn Sie Sichten • Weitere Sichten • Sicht mit Fehlerkennzeichenwählen, können Sie die Anzeige von Subworkflows und deren Strukturaktivieren.

� Abhängig von Ihrer Personalisierung müssen Sie Sichten • WeitereSichten • Sicht mit Subworkflow-Struktur wählen, um die Fehleranzuzeigen, die im Protokoll mit dem Symbol markiert sind. DieStandardkennzeichnung für fehlerfreie Workitems ist . Dies istsehr nützlich, um fehlerhafte Workitems auf einen Blick zu bestimmen,insbesondere in komplexeren Workflows, bei denen zahlreiche Work-items im Protokoll angezeigt werden.

Beheben von Fehlern bei der Bearbeiterermittlung 181

Tipp

Wie bei der Standardsicht können Sie sich auch in der technischen Sichteine Chronik-, Bearbeiter- oder Objektsicht anzeigen lassen.

6.5 Beheben von Fehlern bei der Bearbeiter-ermittlung

Ein Workflow-Problem, das in einer Produktivumgebung am wahrschein-lichsten auftritt, ist das Problem der Bearbeiterermittlung. Hier geht esdarum, dass ein Workitem an die falschen Bearbeiter oder überhaupt kei-nen Bearbeiter gesendet wurde.

Tipp

Verzögerungen haben schnell Auswirkungen

Nachdem ein Workflow entwickelt und in die Produktivumgebung trans-portiert wurde, kann dieser für eine gewisse Zeit unverändert eingesetztwerden. Doch auch Änderungen können eingeplant werden. Mithilfeeines überlegten Designs und sorgfältiger Tests können Sie die meistenWorkflow-Probleme vermeiden. Die Bearbeiterermittlung basiert jedochauf Daten, die in der Regel direkt in der Produktivumgebung gepflegtwerden und gegebenenfalls kurzfristig geändert werden müssen. Selbsteine relativ kurze Verzögerung bei der Aktualisierung der Bearbeiterer-mittlungsregeln oder -berechtigungen kann sich sofort negativ auf einenWorkflow auswirken.

Häufige Fehler-ursache

Der häufigste Grund für Fehler bei der Bearbeiterermittlung ist eine unzu-längliche Pflege der Bearbeiterermittlungsregeln bzw. der den Bearbei-tern erteilten Berechtigungen. Durch Sicherstellen einer rechtzeitigenPflege der Bearbeiterermittlungsregeln und Workflow-Berechtigungenkann die Mehrzahl der Fehler bei der Bearbeiterermittlung vermiedenwerden. Probleme können auch auftreten, wenn ein Bearbeiter dasUnternehmen verlassen hat oder aus einem anderen Grund fehlt, keinen

Durch Klicken auf das Fehlersymbol, das dem übergeordneten Work-flow-Workitem (ganz oben in der Liste) zugeordnet ist, wird eine voll-ständige Fehleranalyse des Workflows eingeblendet, welche die wahr-scheinliche Ursache des Problems angibt.

Sie erhalten keine Warnung durch die WebFlow Engine, wenn der fal-sche Bearbeiter ein Workitem empfängt (falls z.B. die Bearbeiterer-mittlungsdaten veraltet sind). In diesem Fall erweist sich eine guteWorkitem-Beschreibung als sehr hilfreich.


Vertreter hat oder ein Workitem angenommen hat, sodass keiner deranderen Bearbeiter darauf Zugriff hat.

Fehlervermeidungdurch einfache

Strategien

Sie können allerdings durch das Implementieren einfacher Strategien, wiez.B. Vertretungen oder Standardbearbeiter, die Probleme bei der Bearbei-terermittlung erheblich reduzieren. Weitere Informationen zu diesen undanderen Strategien finden Sie in Kapitel 5, Bearbeiter.

6.5.1 Fehlerbehebung bei Workitems ohne Bearbeiter oder mit falschen Bearbeitern

Als Workflow-Administrator sind Sie üblicherweise dafür zuständig, Work-items umzuleiten, die zum falschen Bearbeiter gesendet wurden oder kei-nen Bearbeiter haben. Sie müssen wahrscheinlich auch ermitteln, warumdas Problem aufgetreten ist, und mit dem entsprechenden Personal Pro-blemen bei der Datenpflege nachgehen. Andernfalls kann das Problem beikünftigen Workitems immer wieder auftreten.

Bearbeiterangabeüberprüfen

Bevor Sie ein Workitem mit einem Bearbeiterproblem berichtigen, müs-sen Sie stets prüfen, ob Sie den korrekten Bearbeiter angegeben haben.Sprechen Sie sich hierzu mit dem Process Owner ab. Verlassen Sie sichnicht auf das Wort eines Bearbeiters, der behauptet, der zuständige Bear-beiter zu sein, da Sie dadurch unabsichtlich eine Sicherheitsverletzungverursachen können.

Ein weiterer Punkt, der beim Korrigieren von Workitems mit falschemBearbeiter beachtet werden muss, ist, dass Sie ein Workitem nicht zueinem neuen Bearbeiter senden können, wenn dieses bereits abgeschlos-sen ist. Wenn also der falsche Bearbeiter das Workitem schon beendethat, können Sie lediglich verhindern, dass das Problem erneut auftritt,und die Situation mit den beteiligten Bearbeitern und Process Ownersbesprechen. Es wird empfohlen, zum Nutzen der Auditoren ein Verlaufs-protokoll zu speichern und/oder eine Anlage an den Workflow anzufü-gen, in der erklärt wird, warum der falsche Bearbeiter das Workitem aus-geführt hat.

Die Diagnose, warum die Bearbeiterermittlung misslang, ist ein eigen-ständiges Thema. In Kapitel 14, Erweiterte Diagnose, wird ein Einsatzplanfür die Diagnose von Problemen bei der Bearbeiterermittlung durchlau-fen. Nur wenn Sie die Ursache kennen, können Sie das Problem beheben.

Problem: fehlendeBerechtigung

� Der Bearbeiter verfügt nicht über die Berechtigung zum Ausführen desWorkitems, d.h. der gewünschte Bearbeiter ist kein möglicher Bear-beiter des Workitems.

Beheben von Fehlern bei der Bearbeiterermittlung 183

Folgende Lösungen sind möglich:

� Leiten Sie das Workitem nach Korrektur der Bearbeiterberechtigungan den gewünschten Bearbeiter weiter.

� Wenn der Bearbeiter über die richtige Berechtigung verfügt, er dasWorkitem aber dennoch nicht ausführen kann, besteht möglicher-weise ein Pufferungsproblem (siehe Abschnitt 6.6).

� Wenn das Workitem ausgeführt werden muss, bevor die Berechti-gung berichtigt werden kann, so sollten Sie die Daten mit demgewünschten Bearbeiter besprechen und Ausführen ohne Bearbei-terprüfung verwenden, um das Workitem auszuführen und zu been-den.

Problem: Fehler in der Bearbeiterer-mittlungsregel

� Es wurde der falsche oder kein Bearbeiter gefunden, obgleich dergewünschte Bearbeiter über ausreichende Berechtigungen verfügt.Dies bedeutet, dass die Bearbeiterermittlungsregel fehlgeschlagen ist.

Die mögliche Lösung sieht folgendermaßen aus: Wenn der Bearbeiterbereits ein möglicher Bearbeiter ist, jedoch weder ausgeschlossennoch ausgewählt wurde, leiten Sie das Workitem an den gewünschtenBearbeiter weiter.

Problem: gewünschter Bearbeiter ist aus-geschlossen

� Der gewünschte Bearbeiter kann das Workitem nicht ausführen, da erein ausgeschlossener Bearbeiter ist. Das heißt, er wurde spezifisch vomAusführen des Workitems ausgeschlossen.


� Ein ausgeschlossener Bearbeiter kann das Workitem nicht ausfüh-ren, weshalb Sie das Workitem an einen anderen Bearbeiter weiter-leiten müssen. Der Process Owner kann Ihnen einen geeignetenBearbeiter nennen. Stellen Sie vor dem Weiterleiten des Workitemssicher, dass der neue Bearbeiter ein möglicher Bearbeiter der Auf-gabe und kein ausgeschlossener Bearbeiter ist.

� Sie können auch die Daten mit dem geeigneten Bearbeiter bespre-chen, und anschließend das Workitem über Ausführen ohne Bearbei-terprüfung ausführen und beenden.

Problem: kein Zugriff auf das Workitem

� Auf das Workitem kann aus keinem Eingang aus zugegriffen werden.


� Wenn ein abwesender Bearbeiter das Workitem angenommen hat,andere Empfänger jedoch zur Verfügung stehen, legen Sie das Wor-kitem zurück. Dadurch wird anderen Bearbeitern die Anzeige desWorkitems ermöglicht. Gleiches gilt für Workitems in der Wieder-vorlagemappe eines Bearbeiters.


� Wenn ein abwesender Bearbeiter das Workitem angenommen hatund die Bearbeiter an das Arbeiten mit der Workflow-Vertretunggewöhnt sind, so legen Sie für den abwesenden Bearbeiter einenVertreter an. Der vertretende Bearbeiter kann anschließend dasWorkitem ausführen. Beachten Sie, dass der Vertreter dazu über dieerforderlichen Berechtigungen verfügen muss.

� Wenn in der gewählten Bearbeiterliste keine alternativen Bearbeitervorhanden sind und Sie nicht mit der Vertretung arbeiten möchten,so sollten Sie das Workitem an den entsprechenden (möglichen)Bearbeiter weiterleiten, der vom Process Owner vorgeschlagenwird.

6.5.2 Vermeiden des nochmaligen Auftretens von Problemen bei der Bearbeiterermittlung

Möglichkeitenzur Problem-vermeidung

Nachdem Sie das unmittelbare Problem gelöst haben, müssen Sie dafürsorgen, dass es nicht wieder auftreten kann. Dies kann Folgendes bedeu-ten:

� Sicherstellen, dass die Berechtigungsverwaltung und Regelfestlegungumgehend erfolgt. Wenn Ihnen dies nicht möglich ist, wenden Sie sichgegebenenfalls an den Process Owner und die entsprechenden Vorge-setzten, damit diese für eine Verbesserung sorgen.

� Sicherstellen, dass Mitarbeiter, die workflowrelevanten Einstellungenändern können, sich über die Auswirkungen auf den Workflow im Kla-ren sind. Sie benötigen u.U. die Unterstützung des Process Owners,um die Situation zu verbessern.

� Ändern des Designs des Workflows oder der Regelfestlegung. WennSie beispielsweise eine Zuständigkeitsregel verwenden, können Sie diesekundären Prioritäten aktivieren, damit ein Standardbearbeiter fest-gelegt wird, wenn ein bestimmter Bearbeiter nicht ermittlet werdenkann.

� Einrichten der Workflow-Vertretung für entsprechende Bearbeiter.

6.5.3 Unterstützende Werkzeuge für Problemen bei der Bearbeiterermittlung

Bedingungen fürWorkitems prüfen

� Administration • Workflow-Laufzeit • Bedingungen für Workitemsprüfen (Transaktion SWI1_COND). Mithilfe dieser Funktion können Sie die Empfänger eines Workitemserneut festlegen. Wurde eine Regel zur Bearbeiterermittlung verwen-det, wird diese Regel erneut ausgeführt.

Beheben von Pufferfehlern 185

Workitems ohne Bearbeiter

� Administration • Workflow-Laufzeit • Workitems ohne Bearbeiter(Transaktion SWI2_ADM1). Dieser Report ermittelt alle Workitems ohne Bearbeiter, d.h. verwaisteWorkitems, im Rahmen eines bestimmten Auswahlzeitraums. Dieangezeigte Liste ähnelt dem Report Workitem-Selektion. Sie bietetIhnen dieselben Optionen für die Untersuchung und/oder Korrekturvon Workitems.

Workitem ohne Bearbeiterprü-fung ausführen

� Administration • Workflow-Laufzeit • Workitem ohne Bearbeiterprü-fung ausführen (Transaktion SWIA). Dieser Report ermöglicht die Ausführung von Workitems, für die Siekein möglicher Bearbeiter sind. Aus diesem Grund ist dieses Werkzeugsehr leistungsstark und sollte nur Administratoren in Produktivumge-bungen zur Verfügung gestellt werden. Mithilfe der Workitem-Selek-tion können Sie die benötigten Workitems auswählen und anschlie-ßend ausführen, diese beenden oder wieder für die Empfänger bereit-stellen (d.h. sie »zurücklegen«).

Tipp

6.6 Beheben von Pufferfehlern

Puffern bedeutet lediglich, dass das System eine Kopie bestimmter Datenim Arbeitsspeicher speichert, anstatt diese aus der Datenbank auszulesen.Dies dient der Verbesserung der Gesamtsystemleistung und ist ein gängi-ges Verfahren, besonders bei HR-bezogenen Entitäten wie Organisations-einheiten, Stellen, Planstellen, Bearbeitern, Aufgaben sowie ihren Bezie-hungen untereinander. Da es sehr viele Puffer für HR-bezogene Entitätengibt, werden die meisten dieser Puffer normalerweise nur um Mitter-nacht (Systemzeit) aktualisiert. Veraltete Puffer können sich auf höchsteigenartige Weise auf einen Workflow auswirken.

Pufferfehler vermeiden

Die Mehrzahl der Pufferfehler kann vermieden werden, indem sicherge-stellt wird, dass Puffer aktualisiert werden, wenn neue Bearbeiter hinzu-gefügt werden oder sich die Regelfestlegung oder workflowbezogenenBerechtigungen ändern. Da jedoch in Basis-Umgebungen vor 4.6x die

Wenn Sie zur Fehlerbehebung die Option Workitem ohne Bearbeiter-prüfung ausführen einsetzen müssen, sollten Sie in einer Anlage zumWorkitem erläutern, warum die Aktion erforderlich war und wer dieAusführung der Aktion angewiesen hat. Dadurch können unange-nehme Fragen von Auditoren und Vorgesetzten beantwortet bzw. ver-mieden werden, die die Geschäftsprozesse lange nach der Problem-lösung überprüfen.


entsprechenden Werkzeuge fehlen, ist hier das Aktualisieren des Puffersnoch schwieriger. Ein weiterer Ansatz ist folgender: Gewöhnen Sie sichan, Bearbeiterzuordnungen und Sicherheitsberechtigungen mindestenseinen Tag vor deren geplanter Verwendung einzurichten.

Pufferprobleme führen zu scheinbar unmöglichen Situationen:

� Das Workitem kann im Eingang des Bearbeiters vorliegen, ohne dassder Bearbeiter es ausführen kann.

� Alle Administrations- und Berechtigungseinstellungen des Bearbeiterssind richtig, doch die Bearbeiterermittlung funktioniert trotzdem nicht.

Es ist in höchstem Maß frustrierend, den ganzen Tag erfolglos nach einerProblemlösung zu suchen, am nächsten Morgen ins Büro zu kommen undfeststellen zu müssen, dass alles wieder wie gewünscht funktioniert.

6.6.1 Korrigieren von Workitems mit Pufferproblemen

Möglichkeiten zurProblembehebung

Pufferprobleme können durch die Aktualisierung von Puffern behobenwerden. Sie haben dazu folgende Möglichkeiten:

� Die Option »Laufzeitpuffer synchronisieren«Diese aktualisiert die Mehrzahl der HR-Puffer.

� Die Option »Index auffrischen« beim Zuordnen von Bearbeitern zuAufgabenDiese aktualisiert die Pufferung der Bearbeiterzuordnung zu einer Auf-gabe.

� Die Option »Organisatorisches Umfeld auffrischen« Sie befindet sich im Business Workplace (Transaktion SBWP) oder in derTransaktion zum Starten von Workflows (Transaktion SWUS). DieOption aktualisiert die Puffer der aktuellen Benutzerkennung.

Problemfälleunterscheiden

Wenn die Pufferung den Zugriff eines Bearbeiters auf ein Workitem ver-hindert, reicht die Aktualisierung der Puffer aus. Wenn die Pufferungjedoch ein Problem bei der Bearbeiterermittlung bewirkt hat, das Work-item also nicht zum richtigen Bearbeiter gesendet wurde, müssen Sie den-noch das Problem bei der Bearbeiterermittlung für Workitems beheben,die vor der Aktualisierung der Puffer erstellt wurden (siehe Abschnitt 6.5).

Mitunter scheinen Berechtigungsprobleme Pufferprobleme zu sein. Bei-spiel: wenn Sie in einem R/3-System mit strukturellen HR-Berechtigun-gen arbeiten, kann das Fehlen entsprechender Berechtigungen dazu füh-ren, dass Bearbeiter nicht auf ihre Workitems zugreifen können. Die

Beheben von Pufferfehlern 187

angezeigten Fehlermeldungen beim Versuch, das Workitem auszuführen,entsprechen oder ähneln den Fehlermeldungen, die bei Pufferproblemenangezeigt werden.

6.6.2 Vermeiden eines erneuten Auftretens von Puffer-problemen

Pufferprobleme vermeiden

Langfristig können Sie Pufferprobleme durch folgende Maßnahmen ver-meiden:

� Sicherstellen, dass die Aktualisierung relevanter Berechtigungs-, HR-und Workflow-Daten bereits am Tag vor deren Verwendung erfolgt

� Synchronisieren der Laufzeitpuffer nach dringenden Änderungen anworkflowbezogenen Berechtigungseinstellungen, wenn diese sofortverwendet werden müssen

� Informieren der Bearbeiter über Symptome von Pufferproblemen, z.B.durch eine Website. Darüber hinaus empfiehlt es sich, ihnen nachMöglichkeit einen Zugriff auf die Option Organisatorisches Umfeld auf-frischen zu erteilen, damit sie die Puffer selbst aktualisieren können.

6.6.3 Unterstützende Werkzeuge bei Pufferproblemen

Laufzeitpuffer synchronisieren

Administration • Workflow-Laufzeit • Laufzeitpuffer synchronisieren(Transaktion SWU_OBUF). Mithilfe dieser Funktion können Sie die Pufferdes Hauptarbeitsspeichers initialisieren, die von der WebFlow Engine ver-wendet werden. Sie können die aktuelle Zeit als neue Startzeit der Puffe-rung einstellen. Nach Einstellung der neuen Startzeit der Pufferung liestdas System die Daten aus der Datenbank anstatt aus dem Puffer, sodassdie aktuellen Daten verwendet werden. Während dieses Vorgangs wer-den die Daten aus dem Datenbank den Puffern erneut hinzugefügt.

Tipp

Nach Ausführung dieser Funktion weisen einige Workflow-Funktionenanfänglich eine etwas schwächere Performance auf. Dies ändert sich,sobald der Hauptarbeitsspeicher die Puffer mit optimalen Einstellungenneu erstellt hat.

Sie sollten den Laufzeitpuffer stets aktualisieren, nachdem Sie eineAufgabendefinition geändert oder neue Workflows bzw. Workflow-Versionen transportiert haben, die am Tag des Transports verwendetwerden sollen.


6.7 Weitere unterstützende WerkzeugeEs folgen verschiedene weitere Reports und Funktion, die beim Korrigie-ren von Workitem-Fehlern nützlich sein können.

Diagnose fehler-hafter Workflows

� Administration • Workflow-Laufzeit • Diagnose fehlerhafter Work-flows (Transaktion SWI2_DIAG)Diese Funktion zeigt alle fehlerhaften Workflows an und gruppiert diesegemäß der Fehlerursache (Bearbeiter, Termine, Datenfluss oder weitereKriterien). Mithilfe dieses Reports können Sie feststellen, ob bestimmteFehlertypen in mehreren Workflows immer wieder vorkommen oderob das Problem nur für ein bestimmtes Workitem gilt. In diesem Reportkönnen Sie den Workflow auch korrigieren und neu starten.

Tipp

Workflow-Restartnach Fehler

� Administration • Workflow-Laufzeit • Workflow-Restart nach Fehler(Transaktion SWPR)Mit diesem Report können Sie sich eine Liste fehlerhafter Workflows ineinem bestimmten Auswahlzeitraum anzeigen lassen und diese neustarten. Dieser Report bietet die Möglichkeit eines Massenneustartsvon Workflows.

Workitems mitTerminüberschrei-

tung

� Administration • Workflow Runtime • Workitems mit Terminüber-schreitung (Transaktion SWI2_DEAD)Für Aufgaben mit Terminen gibt es auch eine Terminüberwachung, dieauf einem Hintergrundjob basiert. Sie können die Dauer des Hinter-grundjobs oder den Job selbst ändern oder diesen planen, anzeigenoder manuell ausführen.

Workitem-Regel-überwachung

� Administration • Workflow-Laufzeit • Workitem-RegelüberwachungWenn für Schritte im Workflow Bedingungen für den Workitem-Startoder das Workitem-Ende definiert sind, müssen diese Bedingungenregelmäßig geprüft werden. Diese Aufgabe wird von einem Report aus-geführt, der von einem Hintergrundjob gesteuert wird. Sie können denHintergrundjob planen und anzeigen. Sie können den Report auchmanuell über die Option Workitem-Regelüberwachung ausführen starten.

Das System bestimmt die fehlerhaften Workitems auf der höchstenEbene. Wenn ein Workitem den Status »Fehlerhaft« hat, gehört dasangezeigte Workitem zum höchsten fehlerhaften Workflow, der sich inder Hierarchie über diesem befindet.

Help-Desk im Intranet 189

Workflows fortsetzen nach Systemabsturz

� Administration • Workflow-Laufzeit • Workflows fortsetzen nachSystemabsturz (Transaktion SWPC)Verwenden Sie diesen Report, um Workflows fortzusetzen, die nacheinem Systemabsturz zum Stehen gekommen sind und nicht mehrweiterlaufen.

6.8 Help-Desk im IntranetWie Sie bereits feststellen konnten, ist eine gute Vorbereitung die besteMöglichkeit, eine reibungslose und effiziente Verarbeitung sicherzustel-len. Durch die Verteilung der Zuständigkeit auf die Workflow-Bearbeiterkönnen Sie jedoch dafür sorgen, dass der gesamte Prozess für die Bear-beiter durchschaubarer und somit weniger »rätselhaft« wird. Dadurchkönnen sie schneller auf außergewöhnliche Umstände reagieren (z.B.wenn ein Bearbeiter ein Workitem zu lange unbearbeitet lässt) undandere, im Prozess nachfolgende Bearbeiter proaktiv unterstützen. Wäh-len Sie hierfür einen mehrfach unterteilten Ansatz:

� Arbeiten Sie mit einem webbasierten Help-Desk, um Informationen zuverteilen und allgemeine Unterstützung bereitzustellen.

� Weisen Sie die Bearbeiter an, Probleme umgehend zu melden und Siebei der Diagnose zu unterstützen. Versorgen Sie die Bearbeiter mitgenügend Informationen, damit diese erkennen können, bei welchenVorkommnissen es sich tatsächlich um Probleme handelt.

� Weisen Sie die Workflow-Administratoren an, sich um Probleme zukümmern, noch bevor diese für die Bearbeiter erkennbar werden.

6.8.1 Webbasierte Help-Desks

Einrichten einer Help-Desk-Site

Es ist sinnvoll, eine auf Web-Technologien (Intranet/Extranet) basierendeHelp-Desk-Site einzurichten, die Folgendes bereitstellt:

� Kontakttelefonnummern zur Lösung von Problemen

� Listen mit häufig gestellten Fragen. Diese Listen vereinfachen das Ver-ständnis und unterstützen die Benutzer bei der selbstständigen Diag-nose und Behebung ihrer Probleme

� Zugriff auf allgemeines Schulungsmaterial

� Zugriff auf Tipps und Tricks zum Umgang mit Eingängen, Anlagen, derDurchführung von Aufgaben usw.

� Referenzdokumente mit Erläuterungen des Geschäftsprozesses undWorkflows, z.B. ein grafisches Ablaufdiagramm


� Informationen zu neuen und bald verfügbaren Workflows

� Interessante statistische Informationen, wie z.B. die Dauer des Prozes-ses vor und nach Implementierung des Workflows oder die Anzahl undHäufigkeit von Workflows

� Einen »Vorschlagkasten« für Anregungen zum Verbessern des Work-flows

� Anerkennende Worte für Benutzer, die zur Verbesserung von Work-flows beigetragen haben

Unterstützung beiProzessverände-

rungen

Wenn sich der Geschäftsprozess ändert, ist ein Help-Desk außerdem derideale Ort zur Veröffentlichung von Informationen zu folgenden Zwe-cken:

� Darauf hinweisen, dass sich der Workflow geändert hat

� Erläutern, warum sich der Workflow geändert hat und welche Vorteiledie Änderungen bringen

� Erklären der Unterschiede zwischen neuem und altem Prozess

� Erläutern der etwaigen Auswirkungen für die Workflow-Benutzer

6.8.2 Selbsthilfe

Welche Informa-tion benötigen die

Bearbeiter?

Sorgen Sie dafür, dass die Bearbeiter ihre Rolle im Geschäftsprozess gutnachvollziehen können. Stellen Sie den Bearbeitern beispielsweise eineKopie des Workflow-Ablaufdiagramms zur Verfügung, in dem die vonihnen durchgeführten Aufgaben hervorgehoben sind. Eine andere Mög-lichkeit ist das Verteilen von Informationsdokumenten, in denen dasWorkflow-Ablaufdiagramm, die erwarteten Vorteile des neuen Work-flows und den Zugriff auf die Workitems erläutert, die aktuellsten Schu-lungsinformationen vermittelt und die Kontaktpersonen bei Problemenangegeben werden.

Sorgen Sie dafür, dass die mit dem Workitem übergebenen Anweisungenklar, präzise und vollständig sind. Lassen Sie nach Möglichkeit einigeBearbeiter vor Aktivierung des Workflows die Anweisungen lesen, umsicherzugehen, dass diese verständlich sind. Versorgen Sie die Bearbeitermit ausreichenden Informationen, damit sie Probleme identifizieren,untersuchen und beheben können. Neben der Beschleunigung der Feh-lerbehebung wird dadurch auch die Einbeziehung des Bearbeiters in denProzess gestärkt.

Ein Tag im Leben eines Workflow-Administrators 191

Informationen im Workitem

Informieren Sie den Bearbeiter im Workitem darüber, warum er das Work-item empfangen hat und an wen er sich wenden kann, wenn er meint, ersei nicht der richtige Empfänger oder er könne das Workitem nicht aus-führen:

� »Sie haben dieses Workitem empfangen, weil…«

� »Wenden Sie sich an …, wenn Sie meinen, dass Sie nicht der richtigeEmpfänger dieses Workitems sind.«

� »Wenden Sie sich an …, wenn Sie dieses Workitem nicht bearbeiten/auf diesen Hyperlink nicht zugreifen können.«

Fordern Sie die Bearbeiter auf, Probleme sofort zu melden. Einzelprob-leme sind oft schwierig nachzuvollziehen, da das Workitem häufig bereitsabgeschlossen ist und somit wichtige Hinweise verloren gehen, bevoreine Diagnose versucht werden kann.

Problemmel-dungen einfach halten

Gestalten Sie die Problemmeldung so einfach wie möglich. Ziehen Sie zudiesem Zweck einen einfachen Workflow in Betracht. Lassen Sie bei-spielsweise den Bearbeiter einen Text mit folgenden Informationen ein-geben:

� Problembeschreibung

� Code für die Art des aufgetretenen Problems (falscher Bearbeiter, feh-lende Informationen, Workitem kann nicht ausgeführt werden)

� Code für den Prozess, zu dem das Workitem gehört (Beschaffungsan-forderung, Urlaubsantrag usw.)

� Benutzerkennung und Kontaktinformationen

Sorgen Sie dafür, dass der Workflow das gemeldete Problem basierendauf der Art des aufgetretenen Problems und des betroffenen Prozesses aneinen geeigneten Bearbeiter weiterleitet. Richten Sie eine E-Mail-Ant-wort an den Initiator ein, welche die Behebung des Problems bestätigt.

6.9 Ein Tag im Leben eines Workflow-Administrators

Die Überschrift dieses Abschnitts ist vielleicht ein wenig irreführend.Denn dank des hohen Integrationsgrades von SAPs WebFlow Engine mitdem Rest der SAP-Software bewegt sich die Zeit, die für die reine Admi-nistration (im Gegensatz zur Entwicklung) aufgewendet werden muss, inder Größenordnung von einer Stunde pro Woche. Dies gilt selbst in gro-


ßen Unternehmen, in denen Workflows verstärkt eingesetzt werden. DerGroßteil dieser Zeit wird für die Aktualisierung des Organisationsmodellszur Einarbeitung von Personal- sowie organisatorischen Änderungen oderfür die Prüfung von Workflows benötigt, die sich in der Entwicklungbefinden.

Fragen undKriterien

Sollten Sie jedoch zum Workflow-Administrator bestimmt werden oderfür das Bereitstellen von Ressourcen für Workflow-Administratorenzuständig sein, müssen Sie diese Aufgabe ernst nehmen. Für diesen Fallist es sinnvoll, eine Vorstellung von den laufenden Aufgaben eines Work-flow-Administrators zu haben. Folgende Punkte müssen berücksichtigwerden:

� Wer soll der Workflow-Administrator werden?Welche Fähigkeiten werden von einem Workflow-Administrator ver-langt? Technische Fähigkeiten, geschäftliches Wissen oder beides?Kann der Systemadministrator auch als Workflow-Administrator fun-gieren? Handelt es sich um eine Voll- oder Teilzeitposition?

� Wer trifft bei einem Workflow-Ausfall die geschäftlichen Entschei-dungen?Workflows sind aktive Geschäftsprozesse. Wie interagiert derGeschäftsprozessverantwortliche mit dem Workflow-Administrator,wenn der Workflow ausfallen sollte?

� AusfallreaktionWenn ein Workflow fehlschlägt, fällt auch der Geschäftsprozess aus.Wenn der Prozess zudem wichtig genug war, um als Workflow imple-mentiert zu werden, ist jeder Ausfall ebenfalls kritisch. Was muss derWorkflow-Administrator bei einem Ausfall unternehmen?

� Laufende ÜberwachungWelches sind neben der Ausfallreaktion die laufenden Aufgaben einesWorkflow-Administrators?

� Administration und WartungWie sorgt ein Workflow-Administrator für die Erhaltung einer optima-len Effizienz der Workflow-Umgebung?

� Optimale Nutzung einer wertvollen RessourceDie Nachfrage nach Workflow-Kenntnissen ist häufig groß. Wie kanndemnach der Workflow-Administrator in Ihrem Unternehmen am bes-ten eingesetzt werden?


6.9.1 Wer soll der Workflow-Administrator werden?

Geschäftlicheund technische Fähigkeiten

Die Workflow-Administration umfasst in der Regel sowohl technische alsauch betriebswirtschaftliche Aktivitäten. Deshalb ist es sinnvoll, dass Mit-arbeiter sowohl aus dem technischen als auch dem betriebswirtschaft-lichen Bereich als Administratoren fungieren. Es gibt nur selten eine Per-son, die über alle technischen und betriebswirtschaftlichen Fähigkeitenzur Unterstützung von Workflows verfügt. Aus diesem Grund sollten Sieein interagierendes Administratorenteam zusammenstellen oder eineKontaktierungsfolge für den Support einrichten. Sowohl die technischenals auch die betriebswirtschaftlichen Mitarbeiter müssen mit dem Kon-zept Workflow vertraut sein.

Mögliche Teamstrukturen

Möglich sind verschiedene Teamstrukturen, wie z.B.:

� Ein zentrales, fest zugeordnetes Team aus technischen und geschäft-lichen Administratoren

� Eine zentraler fest zugeordneter technischer Administrator und eindezentraler geschäftlicher Administrator, der bedarfsorientiert seineArbeitszeit zur Verfügung stellt

� Regionale Teams technischer und geschäftlicher Administratoren aufTeilzeitbasis

� Ein zentraler Systemadministrator, der in Teilzeit als Workflow-Admi-nistrator fungiert, mit festgelegten geschäftlichen Kontakten für jedenGeschäftsprozess

� Workflow-Administratoren, die auch als Workflow-Entwickler fungie-ren

Entscheidungs-kriterien zur Teamstruktur

Die für Ihre Organisation geeignete Teamstruktur hängt von Folgendemab:

� Anzahl und Häufigkeit der ausgeführten WorkflowsJe mehr Workflows ausgeführt werden bzw. sich in der Entwicklungbefinden, desto wahrscheinlicher ist es, dass die Administration zueiner Vollzeitaktivität wird.

� Anzahl der Mitarbeiter, die vom Workflow betroffen sindDies betrifft nicht nur die Bearbeiter, sondern auch Mitarbeiter, diedavon abhängig sind, dass der Workflow für sie Prozesse beendet. Jemehr Mitarbeiter betroffen sind, desto mehr geschäftliche Administra-toren werden benötigt, um das Workflow-Verhalten zu vermitteln undzu erläutern. Sie können diesen Aufwand mithilfe einer Website redu-zieren, auf der das Workflow-Verhalten vermittelt und erläutert wird.


� Verfügbarkeit der Workflow-RessourcenWenn nur wenige Mitarbeiter über Workflow-Kenntnisse verfügen,können diese als Workflow-Entwickler und -Administratoren fungie-ren. Sobald Anzahl und Häufigkeit von Workflows zunehmen, ist esratsam, diese Rollen zu trennen, um das Änderungsmanagement derWorkflows zu verbessern.

� Wird der Workflow als ständige geschäftliche Verbesserung emp-funden?Spielt der Administrator also regelmäßig eine Rolle bei der Entwicklungneuer Szenarios oder wurden nur einige wenige beschränkte Prozesseaktiviert?

GrundsätzlicheVerteilung der

Verantwortlich-keiten

Die grundsätzliche Verteilung der Verantwortlichkeiten gliedert sich wirfolgt:

� Richten Sie eine Website als erste Kontaktstelle für Fragen zur Funkti-onsweise des Prozesses und den erforderlichen Vorgehensweisen ein,bzw. stellen Sie hierfür Mitarbeiter mit der entsprechenden betriebs-wirtschaftlichen Kompetenz (z.B. einen Supervisor) bereit.

� Stellen Sie einen technischen Administrator zur Lösung weiter gehen-der Probleme bereit.

� Ordnen Sie Process Owner zu, die bei einem Ausfall kontaktiert wer-den können, um betriebswirtschaftliche Entscheidungen zu treffen.Stellen Sie außerdem stellvertretende Kontaktpersonen zur Verfügung.Bei einem Ausfall kann es nötig sein, innerhalb von Minuten nach Auf-treten des Problems einen Support-Kontakt herstellen zu können.

� Stellen Sie sicher, dass der Workflow-Entwickler zur Unterstützung derProblembehebung verfügbar ist. Dies gilt insbesondere für die erstenWochen nach der Aktivierung eines neuen oder geänderten Work-flows in der Produktivumgebung.

Auf Anfangspro-bleme vorbereitet

sein

Der Workflow-Administrator steht an vorderster Front, wenn Workflow-Probleme auftreten. In der Regel handelt es sich um unternehmenswich-tige, grundlegende oder ausgesprochen weit reichende Geschäftspro-zesse, welche den Aufwand ihrer Implementierung als Workflows recht-fertigen. Aus diesem Grund muss der Workflow-Administrator in derLage sein, ab dem Moment, in dem in Ihrer Produktivumgebung zum ers-ten Mal ein Workflow ausgeführt wird, Probleme zu bewältigen. Wie Siewissen, treten die meisten Probleme in den ersten Instanzen eines neuenoder geänderten Workflows auf. Darüber hinaus ist es unrealistisch, dieWorkflow-Administration einem Systemadministrator zu übertragen und


zu erwarten, dass dieser ohne jede Workflow-Schulung Probleme unter-suchen und beheben kann.

Was benötigt ein Workflow-Administrator?

Ein Workflow-Administrator benötigt Folgendes:

� Einsicht in die Workflow-Grundlagen

� Kenntnis des von ihm unterstützten Workflows

� Praxis im Umgang mit den verschiedenen unterstützenden Werkzeu-gen zur Fehlerdiagnose und -behebung

� Geschäftliche Ansprechpartner, wenn ein Workflow ausfällt und einegeschäftliche Entscheidung getroffen werden muss

Tipp

6.9.2 Wer trifft bei einem Workflow-Ausfall die geschäftlichen Entscheidungen?

Das Korrigieren fehlerhafter Workflows ist, unabhängig vom Problem,wesentlich mehr als nur eine technische Aktivität. Bedenken Sie stets,dass der Workflow den Geschäftsprozess repräsentiert. Wenn Sie alsoEntscheidungen zum Umgang mit ausgefallenen Prozessen treffen, beein-flussen Sie unmittelbar die Geschäftsvorgänge.

Wichtige Fragen bei einem Ausfall

Sie benötigen einen Process Owner (und einen Stellvertreter, da beieinem Ausfall sofort ein Ansprechpartner benötigt wird), der kontaktiertwerden kann, um den Ausfall zu verwalten und zu beheben. Dabei müs-sen folgende Fragen beantwortet werden:

� Wie schwer wiegend ist der Ausfall aus geschäftlicher Sicht?

� Wie kritisch ist dieser bestimmte Ausfall? Kann der Ausfall, falls nochnicht kritisch, zu einem größeren Problem werden, wenn er nicht inder nächsten Stunde, am nächsten Tag, in der nächsten Woche usw.behoben wird?

� Wer muss über den Ausfall benachrichtigt werden?

� Wenn sich der Workflow auf Kunden auswirkt, kann dies bedeuten,dass der Kunde benachrichtigt werden muss. Wenn sich der Workflowauf das Leisten von Zahlungen auswirkt, kann dies bedeuten, dass Lie-feranten benachrichtigt werden müssen.

� Gibt es eine Behelfslösung? Kann die Arbeit z.B. manuell erledigt wer-den, bis das Problem gelöst ist?

Wählen Sie einen Administrator mit guten kommunikativen Fähigkei-ten und nach Möglichkeit auch mit Hotline-Erfahrung.


� Wie kann ein nochmaliger gleichartiger Ausfall verhindert werden?Muss der Workflow erweitert werden, um dieses Problem zu vermei-den? Müssen Prozeduren (z.B. für die Pflege von Bearbeiterdaten)aktualisiert werden? Muss der Help-Desk oder die Website Anweisun-gen für die Bearbeiter enthalten, um eine bessere und schnellere Mel-dung ähnlicher Probleme künftig zu fördern?

Mitarbeitereinbeziehen

Auch wenn der Workflow-Administrator die Antworten auf diese Fragenkennt, können es sich die meisten Unternehmen nicht erlauben, dass dieEntscheidungen von einer Person allein getroffen werden. Ein Unterneh-men muss üblicherweise dafür sorgen, dass der richtige Prozess weiterhinbefolgt wird und die entsprechenden Mitarbeiter in die Entscheidungenüber die auszuführenden Aktionen einbezogen werden.

Grundregeln zurProblemlösung

Auf der anderen Seite darf die Lösung von Workflow-Problemen nichtdadurch verzögert werden, dass in Besprechungen verschiedene Vorge-hensweisen ausdiskutiert werden. Folgende Grundregeln sollten unbe-dingt beachtet werden:

� Sorgen Sie dafür, dass Workflows für einen problemlosen Neustartnach einem Ausfall konzipiert werden.

� Erstellen Sie Workflows, die auf manuelle Aktionen reagieren, damitaußerhalb des Workflows ergriffene Korrekturmaßnahmen den Work-flow reaktivieren können.

� Erstellen Sie einen Maßnahmenplan, bevor das Problem auftritt. Anti-zipieren Sie im Rahmen des Workflow-Designs mögliche Ausfälle undentsprechende Behebungsmaßnahmen.

� Führen Sie nach jedem Problem, insbesondere nach wiederholt auftre-tenden Problemen, Nachbesprechungen durch, und ermitteln Sie diezugrunde liegende Fehlerursache sowie Verbesserungsmöglichkeitenzur zukünftigen Vermeidung des Fehlers.

� Sorgen Sie dafür, dass Probleme im Workflow schnell bekannt gemachtwerden, sodass Korrekturmaßnahmen ergriffen werden können. Diesbedeutet, dass der Workflow Fehler effektiv melden muss (z.B. mithilfedes standardmäßigen Fehlerüberwachungsprogramms zum Benach-richtigen des Administrators).

Beispiel:Sperrkonflikte

Es folgt ein Workflow-Beispiel aus der Praxis, das die Fehlerbehandlungveranschaulicht:

1. An einer Stelle im Workflow aktualisiert ein Hintergrund-Workitemeinige Daten. Da auch andere Mitarbeiter die Daten bearbeiten kön-nen, stellen Sperrkonflikte ein Problem dar. Das Hintergrund-Work-


item hat die Aufgabe, alle Fehler, so auch Sperrfehler, zurückzumelden.Indem dieser Fehler als temporärer Fehler festgelegt wird, wiederholtdie WebFlow Engine die Methodenausführung stets dann, wenn einSperrproblem auftritt.

2. Ist das Hintergrund-Workitem gesperrt, wiederholt die WebFlowEngine den Vorgang automatisch mehrmals nach Ablauf einer vordefi-nierten Wartefrist (z.B. 10 Minuten).

3. Sobald der Wiederholungszähler abgelaufen ist, wird das Workitem ineinen Fehlerstatus versetzt. Die Workflow-Definition sendet anschlie-ßend ein Dialog-Workitem an einen benannten Bearbeiter und fordertdiesen auf, die Tätigkeit manuell abzuschließen.

Beispiel: Bearbeiter-ermittlungsregel

Ein weiteres Beispiel:

1. An einer Stelle in einem Workflow wird ein Workitem, das eine Geneh-migungs-/Ablehnungsentscheidung anfordert, an einen Bearbeitergesendet. Die Pflege der Bearbeiterermittlungsregeln ist oft problema-tisch, da häufig kein Bearbeiter ermittelt werden kann. Die Bearbei-terermittlungsregeln werden mithilfe einer Regel von Typ Zuständigkeitgepflegt.

2. Für die Zuständigkeitsregel ist die Option Secondary Priorities aktiviert.Auf Grund dieser Regel werden besondere Bearbeiter mit einer hohenPrioritätseinstellung und Standardbearbeiter mit einer niedrigeren Prio-ritätsstufe gepflegt. Demzufolge prüft der Workflow beim Zuordnendes Workitems zuerst die besonderen Bearbeiter. Nur wenn keinbesonderer Bearbeiter gefunden wird, werden die Standardbearbeiterausgewählt. Die Standardbearbeiter wurden geschult, um den korrek-ten Bearbeiter bestimmen, das Workitem an den korrekten Bearbeiterweiterleiten und die Zuständigkeitsregel aktualisieren zu können.

Der Process Owner entscheidet

Der Workflow-Entwickler und die technischen Workflow-Administratorenkönnen bestimmt noch weitere Beispiele nennen. Doch es ist der ProcessOwner, der die optimale Entscheidung für das Unternehmen treffen muss.Unabhängig von der Qualität des Workflow-Designs muss bei einem Ausfallder Process Owner entscheiden, welche Korrekturmaßnahme ergriffen wer-den soll und ob das Korrigieren des ausgefallenen Workflows ausreicht, umden Prozess aus geschäftlicher Sicht zu berichtigen.


6.9.3 Problemreaktion

Wichtigkeit desReaktionsplans

Das Reagieren auf Probleme ist die wichtigste aller Workflow-Administra-toraufgaben. Wenn ein Prozess ausfällt, können die negativen Auswir-kungen auf den Geschäftsbetrieb und somit auch für die Workflow-Administration beträchtlich sein. Deshalb ist für diese Krisenfälle einReaktionsplan von großer Bedeutung.

Die meisten der folgenden Punkte erschließen sich von selbst.

1. Lassen Sie die Symptome des Problems von der Person genau beschrei-ben, die das Problem meldet

2. Machen Sie den Workflow mit dem gemeldeten Problem ausfindig

3. Prüfen Sie, ob der Workflow wie konzipiert ausgeführt wird

4. Wenn der Workflow wie konzipiert funktioniert und kein Fehler vor-liegt, benachrichtigen Sie die Person, die das Problem gemeldet hat,und den Process Owner. Bitten Sie den Process Owner, der Person denkonzipierten Prozess zu erläutern. Bitten Sie eventuell den ProcessOwner auch zu besprechen, ob der Workflow verbessert werden sollte.

5. Wenn der Workflow wie konzipiert funktioniert, jedoch von einerschlechten Datenpflege beeinträchtigt wird, so benachrichtigen Sieden Process Owner. Bitten Sie ihn, sich an der Organisation der Daten-korrekturen zu beteiligen, und besprechen Sie, ob bis zur Berichtigungder Daten Korrekturmaßnahmen getroffen werden sollen. InformierenSie die Person, die das Problem gemeldet hat über die Ursache des Pro-blems und die Schritte zu dessen Behebung. Vermeiden Sie Schuldzu-weisungen.

6. Ist ein Fehler aufgetreten, so führen Sie eine Diagnose durch. Benach-richtigen Sie den Process Owner über das Problem, und besprechen Siemögliche Lösungen. Informieren Sie die Person, die das Problemgemeldet hat, über die Ursache des Problems und die Schritte zu des-sen Behebung. Vermeiden Sie Schuldzuweisungen. Beheben Sie dasProblem. Informieren Sie die meldende Person und den Process Ownerüber die Behebung des Problems.

7. Speichern Sie ein Protokoll gemeldeter Fehler mit beispielsweise fol-genden Informationen:

� Betroffener Workflow

� Fehlertyp (z.B. Schulungsmangel, Prozessdiskrepanz, mangelnde Datenpflege)

� Melder des Fehlers

� An der Lösung beteiligter Process Owner


8. Halten Sie eine Nachbesprechung mit dem Process Owner ab. Je nachProblem kann dies ein kurzes Gespräch oder eine formelle Bespre-chung sein. Diskutieren Sie, ob das Problem hätte besser gelöst werdenkönnen und ob der Workflow geändert werden muss.

9. Demonstrieren Sie der Geschäftsleitung mithilfe des Protokolls gemel-deter Fehler, welche Workflows Probleme verursachen, damit Korrek-turmaßnahmen ergriffen werden.

Workflow zur Problemmeldung einrichten

Sie können nach Wunsch auch einen eigenen Workflow für die Benutzerzum Melden von Problemen einrichten, der Sie beim Suchen undBenachrichtigen des Process Owner unterstützt und schließlich das Pro-tokoll mit den gemeldeten Fehlern aktualisiert. Wird das Protokoll imSystem gespeichert, können Sie die Daten zur Administration problemloszusammenfassen.

Ist der Workflow die Ursache?

Häufig ist es nicht der Workflow selbst, der die Ursache des Problems ist,sondern eine zugrunde liegende Transaktion oder Routine, die auf eineWeise fehlgeschlagen ist, die im Workflow nicht vorhergesehen werdenkonnte. Folgende Ursachen sind u.a. möglich:

� Änderungen an der Konfiguration der Transaktionen oder Routinenohne Berücksichtigung der Auswirkung auf den Workflow. Dazu kön-nen auch scheinbar unverfängliche Änderungen gehören, wie z.B. dasHinzufügen eines neuen Wertes für einen Code.

� Änderungen von Werten – einschließlich Stammdaten –, die von derTransaktion bzw. Routine zur Ermittlung von Bearbeitern für Folge-schritte im Workflow verwendet werden (aufgrund der geändertenWerte kann z.B. ein Bearbeiterermittlung fehlgeschlagen sein)

� Änderungen am Code von Transaktionen oder Routinen aufgrundangewendeter Upgrades, Patches oder SAP-Hinweise, die sich uner-wartet auf den Workflow auswirken

� Benutzer führen die Transaktionen bzw. Routinen auf unerwarteteWeise aus, möglicherweise aufgrund nicht ausreichender oder ineffek-tiver Prozessschulung.

� Am Prozess beteiligte Benutzer agieren nicht rechtzeitig, insbesonderewenn zugrunde liegende Transaktionen oder Routinen veränderlicheDaten verwenden.

Der Workflow-Administrator als Prozessbearbeiter

Es ist nicht ungewöhnlich, dass viele »Workflow-Fehler« gemeldet wer-den, die überhaupt keine Workflow-Fehler sind. Bedenken Sie, dass derWorkflow die Sicht der Mitarbeiter auf den Geschäftsprozess darstellt.


Auch wenn der Workflow selbst nicht das Problem ist, sollten Sie zumin-dest dafür sorgen, dass eine Reaktion koordiniert wird. Zu den Aufgabendes Workflow-Administrators gehört demnach nicht nur die Diagnoseund Behebung von Fehlern, sondern er wirkt auch als Vermittler, umeinen reibungslosen Ablauf des gesamten Prozesses zu gewährleisten.Diese Aufgabe kann problemlos gemeinsam vom Administrator und Pro-cess Owner übernommen werden. Es ist ratsam, die Zuständigkeiten zuregeln, bevor der Workflow in der Produktivumgebung aktiviert wird.

6.9.4 Laufende Überwachung

Aufgaben beireibungslosem

Betrieb

Auch wenn alles reibungslos läuft, gibt es einige Aufgaben, die der Admi-nistrator erledigen kann. Bei den folgenden Aufgaben handelt es sichzumeist um Statusprüfungen, die mindestens einmal täglich ausgeführtwerden sollten. Wenn in Ihrem Unternehmen zahlreiche Workflows ein-gesetzt werden, sollten Sie diese Prüfungen natürlich häufiger vorneh-men.

� Prüfen Sie Ihren Eingang regelmäßig auf Workflow-Fehler. Der Fehler-überwachungsjob (SWWERRE) sendet schwer wiegende Fehler wieEreigniskopplungs-, Datenfluss- und Regelauflösungsfehler direkt inIhren Eingang. Auf diese Weise können Sie ggf. ein Problem beheben,bevor es von den Bearbeitern bemerkt wird.

� Führen Sie den Fehlerübersichtsreport (Diagnose fehlerhafter Work-flows, Transaktion SWI2_DIAG) aus, um eventuell nicht berücksichtigteFehler anzuzeigen.

� Prüfen Sie, ob der Fehlerüberwachungsjob (SWWERRE) korrekt ausge-führt wird.

6.9.5 Regelmäßige Umgebungsprüfungen

Unterstützen dieBenutzer den

Prozess?

Es kann nicht genug betont werden, wie wichtig der menschliche Faktorfür das Erreichen des maximalen Erfolgs der Workflow-Automatisierungist. Eine Workflow-Definition zu erstellen, welche den optimalen Prozessbeschreibt, ist eine Sache. Dafür zu sorgen, dass die Benutzer diesen Pro-zess auch unterstützen, eine andere. Prüfen Sie regelmäßig die verschie-denen Benutzergruppen, um festzustellen, ob diese mit dem Workflow inder beabsichtigten Weise arbeiten, insbesondere unmittelbar nach derAktivierung in der Produktivumgebung. Seien Sie nicht enttäuscht, wenndie Benutzer Ihre Richtlinien nicht befolgen. Arbeiten Sie mit ihnenzusammen, um die Abläufe zu verbessern.


Typische Probleme der Benutzer

Folgende Fehlverhalten sind immer wieder anzutreffen:

� Bearbeiter drucken Workitems auf Papier aus, damit Kollegen dieDetails auf Papier ausfüllen können. Der ursprüngliche Bearbeiter gibtdann die Informationen vom Papier in die entsprechende Transaktionein.

Lösung: Prüfen Sie die Geschäftslogik der Bearbeiterermittlungsregeln.

� Bearbeiter erledigen ihre Arbeit nicht rechtzeitig, da sie weitere Infor-mationen benötigen, bevor sie die Aufgabe ausführen können.

Lösung: Versuchen Sie, alle erforderlichen Informationen von vornehe-rein in die Workitem-Beschreibung einzufügen.

� Bearbeiter erledigen ihre Arbeit nicht rechtzeitig, da sie von anderenProzessen aufgehalten werden, die nicht mit dieser Aufgabe synchro-nisiert sind.

Lösung: Mithilfe von Ereignissen können Sie Prozesse miteinander syn-chronisieren.

� Der Bearbeiter versteht die auszuführende Aufgabe nicht (möglicher-weise fehlt die Workitem-Beschreibung).

Lösung: Erweitern Sie die Workitem-Beschreibung, und stellen Sie imWeb mehr Hintergrundinformationen zur Verfügung.

� Benachrichtigungen über Termine werden an die Vorgesetzten gesen-det, die sich jedoch nie beim System anmelden.

Lösung: Häufig ist es effektiver, Benachrichtigungen über Terminedirekt an die Bearbeiter anstatt an die Vorgesetzten zu senden.

� Berechtigungsprobleme hindern den Bearbeiter an der Ausführung derAufgabe auf vorgesehene Weise.

Lösung: Die Berechtigung muss geändert oder eine alternativeMethode verwendet werden (wie z.B. ein Formular).

Bedeutung der Überprüfung

Glücklicherweise sind diese Probleme eher die Ausnahme als die Regel,doch lassen sie erkennen, wie wichtig Umgebungsprüfungen nach demÜbergang in die Produktivumgebung sind. Die meisten gängigen Prob-leme können mühelos gelöst werden. Wenn sie jedoch nicht behobenwerden, können sie sich negativ auf die Gesamtperformance des Work-flows auswirken. Das Einplanen einer Umgebungsprüfung für den Zeit-raum nach dem Übergang in die Produktivumgebung ist ebenso wichtigwie das Einplanen der Benutzerakzeptanz vor diesem Zeitpunkt. BeidePunkte dürfen nicht vernachlässigt werden.


6.9.6 Administration und Wartung

Der Workflow-Administrator ist außerdem für die langfristige Betriebsfä-higkeit der WebFlow Engine zuständig. Es ist ein wichtiger Bestandteildieses Jobs, dass alte Workitems und Workflow-Protokolle regelmäßigaus dem System entfernt werden. Wenn Sie Daten in den Workitemsoder Workflow-Protokollen zum Erstellen von Reports über WIS, BWoder ähnliche Anwendungen verwenden, sorgen Sie dafür, dass dieReports ausgeführt und die erforderlichen Daten vor dem Löschen derWorkitems und Protokolle zusammengefasst werden. Folgende Hilfsmit-tel stehen für Administration und Wartung zur Verfügung:

Aufräumarbeiten Administration • Workflow-Laufzeit • Aufräumarbeiten. Die Hintergrund-jobs der WebFlow Engine erzeugen Job-Protokolle, die regelmäßig gelöschtwerden müssen. Diese Aufgabe wird von einem Report ausgeführt, der voneinem Hintergrundjob gesteuert wird. Sie können den Hintergrundjob pla-nen und anzeigen. Sie können den Report Aufräumarbeiten ausführen auchmanuell ausführen.

Archivierung undReorganisation

Administration • Workflow-Laufzeit • Reorganisation. Die Funktionenzur Archivierung und Reorganisation umfassen Reports für das Archivie-ren und Löschen von Workitems.

ArchivobjektWORKITEM

� Workitem archivierenDas Archivobjekt für Workitems heißt WORKITEM. Die Archivierungerfolgt mithilfe standardmäßiger Archivierungsprogramme. Nur been-dete oder abgebrochene Workitems werden archiviert. Wenn dasWorkitem auf eine Workflow-Instanz verweist, werden abhängigeWorkitems ebenfalls archiviert. Wenn das Workitem zu einem Work-item auf höherer Ebene gehört (z.B. wenn es ein Schritt in einemWorkflow ist), kann es erst archiviert werden, nachdem das Workitemauf höherer Ebene abgeschlossen oder abgebrochen wurde.

Sowohl die Workitem-Daten als auch entsprechende Protokolldatenwerden archiviert.Containerreferenzen werden archiviert, die Objekte,die sie repräsentieren, bleiben davon jedoch unberührt. Wenn bei-spielsweise ein Workitem über eine Objektreferenz für einen Material-stamm verfügt, wird die Referenz archiviert, ohne dass die Material-stammdaten betroffen sind. Anlagen von Workitems, die zuvor nichtarchiviert wurden, werden gelöscht.

Was geschieht beider Archivierung?

Bei der Archivierung werden Daten, die im System nicht mehr benötigtwerden, mithilfe anwendungsspezifischer Kriterien geprüft und ineiner Archivdatei abgelegt. Die Daten werden nicht aus der Datenbank


entfernt. Nachdem die zu archivierenden Dateien vollständig in dieArchivdatei kopiert wurden, können sie in einem getrennten Pro-grammlauf aus der Datenbank gelöscht werden.Alle Vorgänge undProgramme werden im Hintergrund verarbeitet. Sie können die erfor-derlichen Hintergrundjobs in der Archivverwaltung planen.

� Workflows aus Archiv anzeigenMithilfe dieses Reports können Sie sich einen Workflow für einAnwendungsobjekt anzeigen lassen. Nachdem das über die Auswahl-kriterien bestimmte Workflow-Workitem aus dem Archiv gelesenwurde, zeigt das System das Workflow-Protokoll an. Die Funktionendes Workflow-Protokolls stehen jedoch nicht vollständig zur Verfü-gung.

� Workitem löschenMithilfe dieses Reports werden Workitems aus Tabellen ohne Archivie-rung gelöscht. Wenn Sie das Kennzeichen Sofort löschen nicht setzen,wird der Report nur auf Testbasis ausgeführt. Dieser Report löschtohne Überprüfung die von Ihnen angegebenen Workitems. Sie könnenalso auch Workitems aus einem aktiven Workflow löschen! Er dienthauptsächlich dem Entfernen verwaister Workitems aus Entwicklungs-systemen.

Warnung

In einem Produktivsystem müssen Sie die Archivverwaltung zumArchivieren und Löschen von Workitems verwenden, um die Daten-konsistenz sicherzustellen.

� Workitem-Historie löschenDieser Report löscht alle zu Workitems gehörenden Workflow-Proto-kolleinträge (Workitem-Historie) ohne Archivierung. Wenn Sie dasKennzeichen Sofort löschen nicht setzen, wird der Report nur auf Test-basis ausgeführt.

Dieser Report darf in Produktivsystemen nicht verwendet werden. Erwird nicht nur langsamer als der Archivierungsreport ausgeführt, son-dern kann bei falscher Verwendung die guten Arbeitsbeziehungengefährden, die Sie mit Ihren Kollegen aufgebaut haben! Verhindern Siemittels Berechtigungskontrollen eine versehentliche Ausführung (mitAusnahme einer getesteten Reportvariante).


6.9.7 Optimale Nutzung einer wertvollen Ressource

Workflow-Kennt-nisse sind immer

noch selten

Workflow-Kenntnisse sind immer noch selten. Nutzen Sie die Fähigkeitendes Workflow-Administrators optimal, und gestalten Sie die Aufgabeinteressant, damit Ihnen Ihr Administrator so lange wie möglich erhaltenbleibt. Außer für die Administration selbst kann der Workflow-Administ-rator für folgende Aufgaben eingesetzt werden:

Weitere Aufgabenfür Workflow-

Administratoren

� Entwickeln neuer Workflows

� Erweitern vorhandener Workflows

� Überprüfen neuer und erweiterter Workflows (Qualitätssicherung)

� Schulen von Bearbeitern im Umgang mit ihren Workflows

� Schulen von Personal, das für die Datenpflege verantwortlich ist (ins-besondere für die Pflege der Bearbeiterermittlungsregeln und derWorkflow-bezogenen Berechtigungen)

� Einweisen neuer Process Owner in die Funktionsweise von Workflowssowie in die Arten von Problemen, die in ihren Workflows aufgetretensind oder auftreten können, und die entsprechenden Lösungen

Workflow-Vor-teile herausstellen

Stellen Sie die Workflow-Vorteile für das Unternehmen heraus. Dazukönnen Sie von Reports erzeugte Messwerte verwenden, welche die Vor-teile von Workflow in Zahlen ausdrücken. Weiterhin können Sie dazu denBetrieb von Workflows in der Praxis präsentieren. Sie können zudem zei-gen, wie die verschiedenen Workflow-Protokolle die Abläufe dokumen-tieren, und die Informationen vorstellen, die nach Abschluss des Prozes-ses ausgewertet werden können.

Documents

Workflow-Management mit SAP