In ARIS Risk & Compliance Manager werden transaktionale Objekte während ihres Workflows von Aufgaben begleitet. Ein Task beinhaltet die Information, welche Benutzer oder Benutzergruppen für die Bearbeitung des transaktionalen Objekts zuständig sind. Die Aufgabenliste wird einem Benutzer nach der Anmeldung in ARIS Risk & Compliance Manager in Home > Meine Aufgaben angezeigt.
Die Bearbeiter für eine Aufgabe können folgendermaßen festgelegt werden:
Für das transaktionale Objekt wird ein Listenattribut angegeben, in dem Benutzer direkt zugeordnet sind. Aufgaben für Issues sind standardmäßig so konfiguriert.
Für das transaktionale Objekt wird ein Listenattribut angegeben, in dem eine Benutzergruppe zugeordnet ist. Die Mitglieder dieser Benutzergruppe sind für die Bearbeitung der Aufgabe verantwortlich. Standardmäßig ist das die am häufigsten verwendete Konfigurartion. Sie kann für die Konfiguration der Tasks aller transaktionalen Objekte verwendet werden bis auf Issues.
Für das transaktionale Objekt wird eine Rolle mit Rollenlevel Umgebungsspezifisch angegeben. Die Mitglieder der Benutzergruppen, die der Rolle zugeordnet sind, sind für die Bearbeitung der Aufgabe verantwortlich. Das transaktionale Objekt und die Benutzergruppen müssen derselben Umgebung zugeordnet sein.
Ist der Rolle keine Benutzergruppe zugeordnet, der Benutzergruppe keine Benutzer oder das transaktionale Objekt keiner Umgebung, ist kein Benutzer für die Aufgabe verantwortlich. Aufgaben für Deficiencys sind standardmäßig so konfiguriert.
Für das transaktionale Objekt wird eine Rolle mit Rollenlevel Umgebungsübergreifend angegeben. Die Mitglieder der Benutzergruppen, die der Rolle zugeordnet sind, sind für die Bearbeitung der Aufgabe verantwortlich. Ist der Rolle keine Benutzergruppe zugeordet oder der Benutzergruppe keine Benutzer, ist kein Benutzer für die Aufgabe verantwortlich. Standardmäßig wird diese Konfiguration nicht verwendet.
Tasks sind mit bestimmten Workflow-Status verknüpft, welche die weitere Vorgehensweise bestimmen. Diese Menge stellt den Geltungsbereich des Tasks dar und wird pro Task in drei Status unterteilt:
Erreicht ein transaktionales Objekt einen der dafür referenzierten Workflow-Status, wird ein neuer Task gestartet.
Erreicht ein transaktionales Objekt einen der dafür referenzierten Workflow-Status, gelten alle Tasks der Konfiguration dieses transaktionalen Objekts als abgeschlossen.
Erreicht ein transaktionales Objekt einen der dafür referenzierten Workflow-Status, gelten alle Tasks der Konfiguration dieses transaktionalen Objekts als nicht abgeschlossen.
Der Geltungsbereich verschiedener Aufgaben-Konfigurationen kann sich problemlos überschneiden. Zu einem transaktionalen Objekt kann es also in einem bestimmten Workflow-Status mehrere Aufgaben mit unterschiedlichen Verantwortlichkeiten geben.
Zu jedem Task kann eine Monitor-Strategie festgelegt werden. Wird sie nicht festgelegt, hat der Task für die Bearbeiter kein Fälligkeitsdatum und bleibt im System so lange im Status Offen, bis das zugehörige transaktionale Objekt durch Interaktion des Benutzers den Workflow-Status erreicht, der entweder vom Task-Status Abgeschlossen oder Nicht abgeschlossen referenziert wird. In der Standardkonfiguration ist das beispielsweise für viele Reviewer-Tasks der Fall.
Mit einer Monitor-Strategie wird der Bearbeitungs- und Kontrollzeitraum für den Task festgelegt. Sind diese Zeiträume nicht angegeben, werden Bearbeitungs- und Kontrollzeitraum des transaktionalen Objekts verwendet. Dies ist in der Standard-Konfiguration fast immer der Fall, wenn eine Monitor-Strategie spezifiziert ist. Eine Ausnahme sind Policys, bei denen die Bearbeitungsperiode der Aufgabe durch die Attribute plannedstartdate und plannedenddate sowie der Kontrollzeitraum durch die Datumsattribute controlstartdate und controlenddate festgelegt wird.
Dies ist in der Standard-Konfiguration fast immer der Fall, wenn eine Monitor-Strategie spezifiziert ist. Eine Ausnahme sind Policys, bei denen der Bearbeitungszeitraum des Tasks durch die Datumsattribute publishingstartdate und publishingenddate festgelegt wird.
Alle Tasks mit einer Monitor-Strategie werden durch den Überwachungs-Job überwacht. Die Strategie beinhaltet Monitor-Level, die festlegen, was durch den Überwachungs-Job hinsichtlich des Tasks ausgelöst werden soll. Ein Monitor-Level beinhaltet weiterhin eine zeitliche Angabe, die bestimmt, wann der Level als erreicht gilt. Diese bezieht sich auf den Bearbeitungszeitraum des Tasks. Möglich sind:
Der Monitor-Level ist erreicht, wenn zum Ausführungszeitpunkt des Überwachungs-Jobs der verstrichene Bearbeitungszeitraum den vorgegebenen Prozentwert erreicht oder überschritten hat. Der Wert muss eine Zahl von 0 bis 100 sein.
Beispiel: Monitor-Level mit Percentage-Wert 50 und Bearbeitungszeitraum 1.11. bis 30.11. Monitor-Level ist am 16.11. erreicht.
Der Monitor-Level ist erreicht, wenn zum Ausführungszeitpunkt des Überwachungs-Jobs die verbleibende Zeit bis zum Ende des Bearbeitungszeitraums kleiner oder gleich dem angegebenen Wert ist. Der Wert muss mit einer positiven Zahl gefolgt von einem Buchstaben für die Zeiteinheit angegeben werden. Mögliche Einheiten sind d (Days) oder h (Hours).
Beispiel: Monitor-Level mit ReminingTime-Wert 3d und Bearbeitungszeitraum 1.11. bis 30.11. Monitor-Level ist am 28.11. erreicht.
Erreicht ein Task einen Monitor-Level, verschickt der Überwachungs-Job die entsprechende Nachricht. Sind keine Monitor-Nachrichten konfiguriert, wird mit dem Standard-Template monitorjob, eine Nachricht an die Bearbeiter des Tasks gesendet. In der Standardkonfiguration ist das für fast alle Monitor-Level der Fall. Alternativ können für Monitor-Level eigene Nachrichten definiert werden. Dabei können Empfänger, CC-Empfänger, das Nachrichten-Template sowie der Link zu einer Liste in ARIS Risk & Compliance Manager festgelegt werden. Für Monitor-Level des Typs Percentage mit dem Wert 100 können zusätzlich zu den Nachrichten Monitor-Änderungen definiert werden. Monitor-Änderungen verwenden den Überwachungs-Job, um Werte des transaktionalen Objekts der Aufgabe zu ändern. Das Objekt kann dadurch in einen anderen Workflow-Zustand gelangen und das Erzeugen oder Schließen von Aufgaben bewirken. Ein Beispiel dafür ist in der Standardkonfiguration die Task-Konfiguration tester. Ein weiteres Beispiel, bei dem ein Attributwert geändert wird, dies aber keine Auswirkung auf bestehende Aufgaben hat, ist die Aufgabenkonfiguration issue_owner.
Falls Aufgaben durch benutzerdefinierte Attribute erweitert sind, werden die Quellen der eingefügten Werte durch das XML-Element <copyValue> angegeben. Die Attribute fromAttribute.idref und toAttribute.idref dieses XML-Elements verbinden ein Attribut des transaktionalen Objekts mit einem Attribut des generierten Tasks. Sobald der Task generiert ist, wird der Wert aus dem Attribut fromAttribute.idref in das toAttribute.idref kopiert. Beide Referenzen müssen auf Attribute desselben Typs verweisen. Ausnahmen: Listenattribute müssen auf Textattribute verweisen. Aufzählungsattribute werden nicht unterstützt.
Speicherort |
XML-Datei im Ordner xml |
Vorgehen |
Fügen Sie ein neues Element <task> an der gewünschten Stelle hinzu. Die Kombination der Eigenschaften id und objectType.idref muss in der gesamten Konfiguration eindeutig sein. Die Eigenschaft role.idref ist optional und wird nur zur Anzeige von Elementen in der Aufgabenliste verwendet. Wird sie angegeben, muss ihr Wert der ID einer definierten Rolle entsprechen. |
Dokumente |
taskconfiguration_auditmanagement.xml taskconfiguration_changemanagement.xml taskconfiguration_deficiencymanagement.xml taskconfiguration_issuemanagement.xml taskconfiguration_lossmanagement.xml taskconfiguration_policymanagement.xml taskconfiguration_riskmanagement.xml taskconfiguration_signoffmanagement.xml taskconfiguration_surveymanagement.xml taskconfiguration_testmanagement.xml |
Beispiel |
TaskConfiguration_ModifyLevels\WEB-INF\config\custom\xml\custom.xml: TaskConfiguration_AddNewColumns\WEB-INF\config\custom\xml\custom.xml: Ermittle die neuen bzw. geänderten MM-Belege ... Alle deklarierten Aufgaben |