Worfklow-Applikationen
Workflow ist das elektronische Nachbilden des Flusses von Papierdokumenten durch eine Organisation. Zu den Vorteilen gegenüber Papier zählen neben höherer Transparenz auch weniger Arbeitsaufwand und einfachere Stellvertretung.
ATEGRA hat in den letzten Jahren zahlreiche Workflow-Anwendungen entwickelt. Das Know-How und die Erfahrungen aus diesen Projekten stellen wir Ihnen gerne zur Verfügung.
Dieses Dokument enthält Informationen allgemeiner Natur und dient als Einführung in das Thema und zur Übersicht zu Design-Elementen von Workflow-Anwendungen.
Im folgenden ein paar fundamentale charakteristische Alternativen beim Design von Workflow-Lösungen:
Ad-Hoc- vs. vordefinierter Workflow
- ad-hoc-Workflow: der Anwender bestimmt jedesmal neu und von Hand wie der Laufweg sein soll, oder wer der nächste Bearbeiter ist
- vordefinierter Workflow: der Prozesseigner bestimmt wie der Laufweg für alle Prozesse ist; das System routet anhand dieser Definitionen automatisch; dabei sind dennoch gewisse Ausnahmen durch den Anwender möglich, wie z.B. zurück zum letzten Bearbeiter, zurück an den Anfang oder Abbruch
Serieller vs. paralleler Workflow
- serieller Workflow: die Schritte werden sequentiell von den verschiedenen Anwendern abgearbeitet
- paralleler Workflow: hier müssen i.d.R. Daten physisch vervielfacht (fork) und später wieder vermischt werden (merge); dies ist nicht-trivial zu programmieren (dieser Ansatz in IBM Notes/Domino-Workflow implementiert)
Personen vs. Rollen resp. Gruppen
- entweder der aktuelle Bearbeiter kennt die Präsenzen und Absenzen der nächsten Mitarbeiter und wählt den nächsten Bearbeiter aus dem Adressbuch aus und es wird der Name einer Person eingetragen
- oder der aktuelle Bearbeiter kennt die Absenzen/Präsenzen der zuständigen Stelle nicht und wählt den Namen einer Rolle resp. Gruppe aus dem Adressbuch aus; die Gruppe organisiert sich intern und hat bestimmt, wer eintreffende Arbeiten erledigt
Arbeit weitergeben vs. Arbeit nehmen
- entweder der aktuelle Bearbeiter gibt die Arbeit an die nächste Person weiter
- oder der nächste Bearbeiter übernimmt die Arbeit
Je nach Workflow- resp. Programmier-Modell wird die Arbeit automatisch dem nächsten Bearbeiter in die Pendenzenliste eingereiht oder der nächste Bearbeiter muss sich die Arbeit selber nehmen.
Arbeit zugeteilt vs. angenommen
- zunächst ist die Arbeit bloss zugeteilt
- anschliessend nimmt der Bearbeiter die Arbeit an
Beide Ereignisse können ausgewertet werden für das automatische Auslösen von Aktionen oder das Eintragen in der Workflow-Historie.
Elektronische und Papierdokumente
- entweder werden nur elektronische Dokumente geroutet
- oder gleichzeitig auch Papierdokumente
Elemente für die Spezifikation eines Workflows
- die involvierten Rollen
- die auszuführenden Aktivitäten (inkl. Verb und Objekt)
- die Status der Vorgänge
Lösungselement: Weiterreichen der Arbeit
Dies ist die wichtigste Funktion. Es soll möglichst einfach sein, eine Arbeit an eine andere Person oder Gruppe (oder Rolle) weiterzureichen. Dazu soll man möglichst bequem die Person oder Gruppe auswählen können (aus einer Liste mit nicht allzu vielen Einträgen) oder das System soll selber vorschlagen, welche Gruppe die Nächste ist. Dazu soll man eine kurze Nachricht mitsenden können, was zu tun ist. Auch dazu eine Liste mit Auswahlmöglichkeiten. Ferner soll auch ein Wunschtermin (= Frist) mitgeliefert werden können. Das ganze sollte als Subform eingebaut werden können.
Die Arbeit wird erst dann weitergereicht, wenn der Benutzer einen Button drückt. Dabei wird der aktuelle Bearbeiter in die Liste der alten Bearbeiter eingetragen und der nächste Bearbeiter in das Feld aktueller Bearbeiter. Das Feld nächster Bearbeiter wird entweder geleert oder es wird automatisch der nächste Bearbeiter eingetragen. Das Weiterreichen ist immer auch mit einem E-Mail an den nächsten Bearbeiter verbunden. Optional kann auch der Ersteller, jeder frühere Bearbeiter ein eMail dazu erhalten („Arbeit wurde am … an … weitergereicht“). Der Empfänger soll ebenfalls per Knopfdruck die Arbeit an den Sender zurückschicken können unter Angabe eines Grundes. Datenstruktur: Jedesmal wenn der Anwender auf den Button „Weiterleiten“ drückt wird eine Tabelle nachgeführt. Dies ist eigentlich eine Workflow-History.
Lösungselement: Status und Statusänderung
Es ist wichtig pro Fall die Status zu definieren. Es sollen möglichst wenige sein. Beispiel: In Bearbeitung, abgeschlossen, abgebrochen, archiviert, sistiert.
Diverse Design- und Lösungselemente
- Ansicht „Meine Geschäfte“: zeigt ausschliesslich Geschäfte an, bei denen der Anwender als Bearbeiter eingetragen ist
- Mail-In-Agent: ein Kunde sendet ein eMail mit Informationen zu einem bestimmten Geschäft und gibt die Geschäftsnummer an im Subject. Die Datenbank wird als Mail-In-DB unter einer bestimmten Adresse zur Verfügung gestellt. Ein Mail-In-Agent scannt das Subject ab und berechnet ein Feld mit der Geschäftsnummer und weitere Felder, die zur Kategorisierung des eMails als Dokument in verschiedenen Ansichten dienen.
Mail, sobald der Nachfolger das Geschäft bearbeitet hat
- System mit „wichtigen Ereignissen“: eMail sobald ein wichtiges Ereignis eingetroffen ist. Es gibt eine Tabelle mit allen „wichtigen Ereignissen“. Pro Geschäft kann der erste Bearbeiter festlegen, welche Ereignisse für das vorliegende Geschäft „wichtig“ sind. Diese werden jedesmal vor dem Weiterleiten dem Anwender zur Auswahl angezeigt.
ähnliche Begriffe: Geschäft, Prozesstyp, Arbeit, Job, Task, Aufgabe, Pendenz, Web-Formulare mit und ohne elektronische Unterschrift
Varianten der Workflow-Historie
- Tabelle mit den Spalten Datum, Zeit, Name des Anwenders, Aktion
- Tabelle mit
- Namen der letzten Bearbeiter
- Datum, ab dem der Job dem Anwender zugeteilt war
- Aufgabe, die erledigt werden sollte (Kurznachricht)
- Wartezeit in hh:mm bis zur Annahme
- Datum, an dem der Bearbeiter die Aufgabe angenommen oder zurückgewiesen hat
- Vermerk zur Arbeit, die erledigt wurde
- Bearbeitungsdauer in hh:mm
