The RMS Change Management Suite is another powerful, ‘out-of-the-box' solution combining comprehensive functionality with low cost of ownership. The tools have been designed to support the Change, Release, Configuration processes as defined by ITIL as well as providing wider workflow management.
The RMS Change Management suite is seamlessly integrated with the RMS Service Desk suite of tools and are underpinned by the same logical CMDB.
;)
RMS provide a comprehensive Change Management system that will map to the ITIL guidelines for Change Control as suggested below. The Changes within RMS can be defined as simple or as complicated as required by the process. As with the RMS Service Desk the RMS Change Management module can be configured to reflect the organisation's data structures and processes. Terminology and complexity can also be customised to customer specific requirements.
;)
A ‘Request for a Change' (RFC) can be handled at up to three levels depending on requirements and process: Project; Change; Activity.
;)
At the top level, Changes can be linked together to form ‘Projects'.
At the next level Changes envelope all the information and processes that are required prior to implementation, during implementation and post implementation within a Change folder.
;)
Fields on the change folder can be renamed, hidden or made mandatory based on customer specific requirements. The tabs can also be renamed or hidden or, with the template field, configured to capture additional information. This means the change folder can be as simple or as complex as required. These ‘view codes' can also be configured based on groups of users and their specific requirements.
At the lowest level Activities, which embody single procedures or steps within the Change, can be allocated out to individuals. These activities can be sequential or run in parallel and are released automatically.
;)
A procedure can be associated with each activity providing instructions to support the individual undertaking the task. Alternatively, documents can be linked to the activity. Email notification is available, for infrequent users of the system, and can be used to inform them that work has appeared in their worklist.
A library of change ‘models' or processes are created within the system, each defining specific processes and their associated activities. As the change is logged the model is selected and the process pulled into the change.
;)
These models can be added, copied, modified and resaved based on privilege. This allows for easy creation of models and change processes.
Permissions and privileges control access to the RMS Change system including those permitted to raise changes. An RFC can be logged:
;)
The underpinning CMDB provides an inventory store for hardware and software items. Inventory items can be linked to changes to identify work done against them.
;)
A conflict checking facility is available to check whether other work is outstanding or in progress against the selected inventory item.
;)
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.
Views of changes and activities are created using Worklists. Worklists are dynamic lists of logged changes and activities that meet a specified selection criteria. They are automatically updated at regular, user specified intervals and multiple worklists can be set up to monitor different situations. Worklists are a very effective way for Change operators to organise their workloads and they are just as effective as a means for the System Administrator or Change Manager to monitor the whole system. Worklists can be globally generated or, depending on privilege, users can define their own selection criteria and worklists.
;)
For ease of working, Change and Activity worklists are available within the Service Desk and Call worklists can be accessed directly within Change Management.
A Change Advisory Board review date can be captured against each change to provide easy identification of agenda items for forthcoming change meetings. Worklists and reports can be used to produce a forward schedule of change for these review meetings.
The Change module can be used to manage the procurement process and create assets within the CMDB as part of this.
RMS Procurement will identify the supplier, requisition number, cost code, purchase order number, expected and actual delivery dates, delivery note number, invoice number and the date the invoice was paid. Line items can be added to define how many of what product at what cost.
;)
Procurement includes the management of deliveries and can handle part deliveries.
The RMS applications are seamlessly integrated.
The RMS CMDB is accessible throughout the RMS product suite and has been designed to deliver information to the point it is required. Details on assets, contracts, warranties, suppliers, customers etc. can be accessed within each application.
Both problems and changes can be automatically or manually raised during the incident process. Problems and changes also be accessed from within both the Service Desk application or, when linked to an incident, from within the incident folder. Links between incidents, problems and changes is retained for auditing purposes and to ensure easy navigation between related information.
;)
Inventory can also be associated with incidents including the ability to log downtime of the inventory item, application or service.
Problems can generate a change. Problems will also retain the details of incidents and changes linked to them for auditing purposes and for easy navigation between related information.
Inventory can also be associated with problems including the ability to log downtime of the inventory item, application or service.
Changes raised from an incident or problem will retain a link to the related information. Incidents and problems can also be easily accessed from within the Change Module or from a Change. A right mouse click on the incident or problem field will access the relevant incident or problem.
Inventory can also be associated with changes including the ability to log downtime of the inventory item, application or service.
;)
;){kind=link}