It seems that the Process Report allows tracking Tasks (defined within the process) against their completion being late only on the level of the entire Process (i.e., rather than deadlines assigned individual individual tasks). What is the best practice in case I want to track specific tasks if they were completed on time? For example, the process requires both review and approval. I would like to define: Time allowed to complete the Review (lets call it OLA 1 (operational Agreement with the Reviewer) Time allowed to complete the Approve (lets call it OLA 2), and Time allowed to complete the the entire process or service (lets call it SLA (Service Level Agreement), defined as OLA1 + OLA2 + additional buffer) The above represents typical ITIL thinking, in line with which the end-to-end delivery time of each Service (SLA), needs to be orchestrated as a timed collaboration of various Actors expected to deliver their contributions to the specific OLAs, and ideally the progress of such sequence is traced so that escalations, in case of any of the OLAs violations are immediately highlighted to make the recovery of the entire sequence possible. In case we cannot track all the links in the delivery chain, but only the overall timing, there is little chance to respond in a proactive manner.

Tracking task versus process execution

jerzym0001 over 5 years ago

It seems that the Process Report allows tracking Tasks (defined within the process) against their completion being late only on the level of the entire Process (i.e., rather than deadlines assigned individual individual tasks).

What is the best practice in case I want to track specific tasks if they were completed on time? For example, the process requires both review and approval. I would like to define:

Time allowed to complete the Review (lets call it OLA 1 (operational Agreement with the Reviewer)
Time allowed to complete the Approve (lets call it OLA 2), and
Time allowed to complete the the entire process or service (lets call it SLA (Service Level Agreement), defined as OLA1 + OLA2 + additional buffer)

The above represents typical ITIL thinking, in line with which the end-to-end delivery time of each Service (SLA), needs to be orchestrated as a timed collaboration of various Actors expected to deliver their contributions to the specific OLAs, and ideally the progress of such sequence is traced so that escalations, in case of any of the OLAs violations are immediately highlighted to make the recovery of the entire sequence possible.

In case we cannot track all the links in the delivery chain, but only the overall timing, there is little chance to respond in a proactive manner.

Discussion posts and replies are publicly visible

0 Stewart Burchell
Appian Employee
over 5 years ago

I would encourage you to think about the problem differently. What are you going to do with this information, assuming it's going to be recorded post-facto? If the purpose is to ensure that overall SLAs (or individual OLAs) are met, then build this as pre-emptive actions in the process. Design your Tasks to have a relevant combination of Escalations and Exceptions to try to ensure that the SLAs and OLAs are met. That, after all, is the purpose of Management Information - situational awareness that leads to action. If this is at all deterministic then automate it.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 jerzym0001 over 5 years ago in reply to Stewart Burchell

Thank you, fully agree. At the time of my posting I was still not aware that Escalations, Exceptions and Deadlines can be configuired at the Task level. Obviously, my purpose to establish OLAs and SLAs is to enable tracking the completion progress of tasks to enable pro-active escaltion/recovery. Again, thank you for your timely response. I gor my learning from here: docs.appian.com/.../Process_Node_and_Smart_Service_Properties.html
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel