Configuration Management

The basis of the RMS Service Management Suite is a powerful Configuration Management Database (CMDB) that can be populated to contain all information pertaining to Service Support and Delivery. Typical Configuration Items (CIs) held would include customer details, users, privileges, assets and inventory items, contracts, SLAs/OLAs, known errors, knowledge, incidents, problems etc. The interdependencies and relationships between these CIs are also configured within the CMDB.

Managing the Database

The RMS CMDB is pre-defined but configurable by customers using the GUI driven toolsets provided as part of the suite. The RMS CMDB is a flexible solution that provides immediate results with a low cost of ownership. Population of information, once configured, is a matter of filling in the spaces.

A Federated Approach

RMS support a federated approach to the CMDB. In many organisations information is distributed and cannot be centrally managed. To facilitate this RMS also provide a number of integration tools.

The RMS systems can be configured to provide granular access to individuals both in terms of the depth of information they get access to and how they can use the system.

Populating the CMDB

A number of options are available for managing the information:

Data Management Tool: one off and scheduled data tool
Automated Feeds
Asset Discovery and Tracking
Bar Code Scanner integration
Inventory Audit Tool for bar code scanner audits and audit reporting against the CMDB

Third Party Data Integration

RMS follow a standard methodology for integrating a new or customer specific data source.

Step 1 - Detailed specification: customer requirements are defined and a detailed mapping exercise is carried out to match data between tables and fields in the third party application and the RMS Configuration Management Database.

Step 2 - Development: RMS develop an application to integrate the applications and feed information from the third party data source into RMS and/or vice versa.

Step 3 - Testing: a test environment is set up and the integration application is tested to verify data and ensure integrity.

Step 4 - Implementation: the integration is implemented within the live environment.

Permissions, Privileges and the Customer Hierarchy

The RMS systems can be configured to provide granular access to individuals both in terms of the depth of information they get access to and how they can use the system. These are as follows:

Customer Log Ons can be restricted for inventory and incidents/problems so that they can view and log calls as appropriate. This can be set up for four levels of customer hierarchy, for example:
1. Individual Level – individual can only see their own incidents/inventory
2. Department Level – department manager can see the departments incidents/inventory
3. Business Area – manager can see incidents/inventory within their business area
4. Global – top level views of all incidents/inventory etc.
‘View Codes' determine what can and cannot be seen by groups of users. This can be used to provide a cut down view of the client technology that is relevant to the user involved and allows fields and tabs on the incident folder to be hidden.
‘Restriction Groups' determine fields which cannot be changed/ updated once an incident/problem has been logged.
‘Privilege Groups' are set up within the system and are allocated to customers/support users. Privilege groups determine access to menu options and functions within the systems.
‘Team Change Groups' determine whether incidents and problems can be passed to another team. For example, a first line incident could not be passed directly to a development team. For customer access you may wish to prevent them allocating any work to a team or individual.
‘Status Change Groups' determine which status a user can move to and from. For example, the only team to be able to close incidents are the Service Desk team.

Service Catalogue

A service catalogue can be defined within the RMS to associate Configuration Items (CIs) to key business services as shown below. This allows organisations to automatically capture ‘Service Availability' based on incident and problem logging against CIs.

A failure matrix is also associated with each Service defined. This identifies failovers, single point of failures, interdependencies validating downtime of the service and estimation of the downtime.

Services can be displayed allowing Support Users to quickly identify the business services and any downtime currently recorded against them.

Configuration Management