Anyone who has implemented an ITSM process knows that one benefits greatly by creating a well-defined and documented process activity flow. The flow describes each role and the activities each role executes as process practitioners. The process activity flow describes each activity associated with the process from start to finish, as well as the flow of records through the various stages and states of their lifecycle until closed.
The process activity flow is optimally a swim-lane process model which is created using modeling tools such as Microsoft Visio or OpenText’s ProVision. Once the activities of the process are defined, we then enter contextual information for each. Contextual information describes what actually occurs during execution of each specific activity.
Contextual information and the process activities documented within the Standard Operating Procedures document is at a higher level than work instructions which come later in process definition. Work instructions are very detailed, and include commands, login instructions, and screen images specific to the tool being used.
Processes must be defined to be tool agnostic. Therefore, within the contextual information for each activity we don’t define specifics related to tools. Contextual information places the specific process activity in context of the process and in a standardized format. Once the contextual information is documented for each activity, it is then extracted and documented when we create the Standard Operating Procedures for the process or function.
The standard my team uses to define each activity within the standard operating procedures document (SOP) is:
|<activity #> <Activity Title>|
|Objective||The explanation of WHY things are done within the activity.|
|Responsibility||The person who is responsible to carry out the activity.|
|Policy Statement||Documented management expectations and intentions that are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes.|
|Initiated by||Defines who initiates this activity.|
|Initiates||Defines what is initiated by this activity.|
|Accepts||Upstream deliverable(s) from other activities that have input to the current activity.|
|Procedure||Documented steps that specify how to achieve an Activity. This information will later be used to document training and work instructions.|
|Delivers||Downstream deliverable(s) from the current activity that will have input to another activity.|
|Metric(s)||Something that is measured and reported to help manage a Process, IT Service or Activity.|
|Requirements||Criteria (quality levels or standards) that must be met to execute the activity.|
|Revision History||Date this activity table was last updated|
As soon as you have the record states and stages defined, you can then set performance thresholds which define the optimal length of time the process/record is permitted to remain in each stage/state.
For instance, when a record is created, it may be in an “open” or “initial” state as a request, and awaiting review to either reject or accept. How long is acceptable for each request to sit waiting for a review? Does it depend upon the priority of the request? Does it depend upon who is making the request? After the request sits for a time period that exceeds the threshold, what is done? Is an email sent to remind someone that the time has been exceeded? Does someone manually intervene to ensure an approval decision is made so that it can continue to move efficiently through the process? The answer to these and other relevant questions will depend upon your business requirements.
An acceptable threshold of time should be defined and agreed to for each stage of the process, each state of the record, and the execution of each key activity of the process or function. In addition, the actions taken in response to a record or activity exceeding a defined threshold (whether it is also defined at an OLO, OLA, SLO, or SLA or not) needs to be pre-determined and agreed to with the Core Stakeholders. This is called: “making a metric actionable”. Don’t measure unless there is a business purpose for the data. Don’t go through the effort of defining, recording, measuring, and monitoring metric data unless it can be used to monitor process execution and to manage or improve the process in some way. If we’re going to instrument a capability to measure key process activities, then we also want to ensure we pre-define what normal execution activity is expected to look like and the response when activity execution falls outside of the pre-defined normal operational tolerances.
We may also measure critical success factors, key performance indicators, and metrics with pre-defined thresholds that indicate process operational efficiency in terms of volumes. For instance, not having over 10 incidents in your assignee group’s queue that have aged beyond a given threshold or having exceeded a predefined SLA service level based upon incident priority.
Each business has different requirements and each Process Owner will need to spend the time it takes to define and align with process Core Stakeholders on what is measured, how it is measured, when it is measured, what constitutes normal operational levels vs. abnormal, and what actions are taken in response to operational anomalies. Regular reporting is then set up to report on and interpret the results against the pre-defined criteria. The reports and any actionable results are reviewed during the regular process service review.
Once defined, the Process Owner and Core Stakeholders will have a clear and aligned definition of what constitutes “normal” operational levels of process or function execution. Practitioners with issues executing within defined operational tolerances can be identified, counseled, guided, and trained to improve.
Using Operational Pipeline Monitoring you ensure records are being moved through the process efficiently according to established service levels and process standards. The Process Owning team as well as Core Stakeholder practitioner groups will be able to quickly recognize inefficiencies in process execution and intervene at key points in the process in order to maintain and improve process efficacy on behalf of the Customer. Another critical benefit is that the entire process is always “audit ready”; which is especially useful for businesses whose I.T. departments undergo audit scrutiny on a regular basis.