Each change is split into five areas against which activities are assigned as relevant to the process being defined (if a stage does not need to be undertaken it can be reflected in the system)
Activities can be sequential or run in parallel and are released automatically.
Each activity, within each stage can be allocated to a team or individual along with a required by date and how long the task is likely to take. As users complete each activity, the system can also be configured to prompt them to enter how long the task actually took. This allows detailed reviews of the time planned for tasks, changes and projects with a comparison against what actually happens.
Pre-assessment tasks are those engaged in and completed prior to formal assessment can be made.
Assessment can be configured to include risk and impact analysis. Risk areas such as availability, business, operational etc can be set up against which assessors enter the likelihood that something will go wrong along with the severity if it does. An in-built escalation point, or hazard rating, can be configured to automatically escalation changes considered to be too high risk.
;)
Assessment can be carried out remotely via the Customer Service Centre, email or within the Change Management module. Assessors can differ from model to model and can be sequenced ie if an assessor has ultimate decision they may be first to assess.
Pre-authorisation activities are those engaged in and completed prior to formal authorisation can be undertaken.
Authorisation can be carried out remotely via the Customer Service Centre, email or within the Change Management module. Authorisation can differ from model to model and can be sequenced ie if an authoriser has ultimate decision they may be first to assess.
;)
Once assessment and authorisation have been successfully completed, implementation activities are automatically kicked off.
Implementation activities are designed to implement the Request for Change. As with all other stages, activities can be released sequentially or in parallel to the teams or individuals involved.
A Back-Out plan is detailed in the ‘Back-Out section'. Back-out activities, which would only be engaged if the RFC was cancelled and/or work carried out needs to be reversed, are detailed.
‘Post-Implementation' activities are to carry out peripheral activities that can be completed once the change has been implemented, for example, producing documentation, updating the CMDB etc,
Against each change or workflow is an SLA which will automatically identify a ‘required by date'. Each activity within the change or workflow can be automatically or manually scheduled against the overall target date with a corresponding ‘required by' and ‘planned' date. As activities and changes approach and breach these targets it will be immediately visible through the system using colour coding and worklists. Each activity can also capture actual as well as planned time taken allowing organisations to see where bottlenecks are occurring and where workflows can be improved. This is a key facilitator to a Service Improvement program.
Once the model has been selected the Schedule button automatically sets up the correct timed sequences according to the SLA/Priority and the estimated periods of time needed to carry out each activity.
