ITIL templates

change_rfc.md

Change RFC

Request for Change RFC - Checklist

Overview :

The Request for Change (RFC) is formal request for the implementation of a Change. A Request for Change is to be submitted to Change Management for any non-standard Change (a set of standard/ routine Changes is usually defined by Change Management; these are minor Changes which do not require submission to the Change Management process). A Change is backed by a Change Owner, holding a budget for its implementation. In many cases the Change Owner is identical with the RFC initiator. Typically Changes are owned by Service Management roles (e.g. the Problem Manager or Capacity Manager) or by IT management. The RFC is a precursor to the Change Record and contains all information required to approve a Change. Further information is added as the Change progresses through its lifecycle. The level of detail depends on the size and likely impact of the Change. Often there will be references to further documents containing more detailed information, e.g. a detailed Change proposal. As major Changes are typically implemented as projects, the RFC often takes on the role of what is also known as a "Project Charter".

• Unique ID :
• Date of submission :
• Change Owner :
• Initiator of the RFC :
  (if not identical with Change Owner)
• Proposed Change priority :

• Low
• Normal
• High
• Very High (Emergency Change)
  (may be overruled by Change Management during Change assessment)

• Reference to Change Proposal
  (if the Change is related to a Change Proposal submitted at an earlier stage)
• Description of the Change being applied for :
• Summary description :
• Business case :
• Reason for the Change to be implemented :
• Costs :
• Benefits :
• Consequences if the Change is not implemented :
• References (e.g. to a Problem Record triggering this RFC) :
• Business areas on the client-side affected by the Change :
• Services affected by the Change :
• IT infrastructure components (CIs) affected by the Change :
• Technology aspects (is a new technology being introduced?) :
• Risks : (Risks during the implementation of the Change)
• Identified risks :
• Counter-measures :
  (e.g. reversion procedure)
• Back-out strategy for the case of a failed Change implementation :
• Time schedule :
  (Predicted/suggested time schedule for the implementation)
• Estimate of resources for the implementation :
• Required personnel resources :
  (from which areas?)
• Estimated work effort for the required personnel resources :
• Cost estimate :
  (itemized for bigger Changes)
• Budget :
  (Statement as to whether a budget is allocated and cleared for this Change)
• Additional supporting documents :
  (If applicable, index of additional supporting documents, e.g. the Service Design Package for major additions or modifications to services)
• Approval or rejection :
• Date :
• Person/ body in charge of the approval :
  (Change Manager/ CAB/ ECAB)
• Change reviewers :
• Priority assigned by Change Management :
• Restrictions :
• If applicable, reasons for rejecting the RFC :

CMS_CMDB.md

Configuration Management System (CMS)/ Configuration Management Database (CMDB)

Overview

The Configuration Management System (CMS) is a set of tools and data that is used for collecting, storing, managing, updating, analyzing and presenting data about all configuration items and their relationships. A CMS may manage more than one physical Configuration Management Databases (CMDB). Its underlying structure is defined by the Configuration Model, a logical model of the IT organization’s service assets. The CMS is used to store information on all Configuration Items (CIs) under the control of Configuration Management. CIs can be of various types: the CMS almost always covers services and IT infrastructure, but might also cover other item types like policies, project documentation, employees, suppliers, etc.

Configuration Model and CI Types

The structure of the CMS is defined by the Configuration Model, which specifies the types of CIs managed through the CMS, including their attributes and relationships. The Configuration Model is often maintained as a (set of) documents or data models. It also manifests itself, for example, in the table structure of the databases used to store configuration information. The Configuration Model typically defines the following structural aspects of the CMS:

• CI types and sub-types
  1. CI types and sub-types managed in the CMS, usually in the form of a tree structure as in the following example:
  2. Main types (e.g. Service, Hardware, Software, Document, Staff ...)
  3. Sub-types (e.g. Server, Printer, ... - refinement of the main type into sub-types) … further sub-types as appropriate
• Attributes (Attributes to be managed for each CI type)
• Status values (allowed status values describing the lifecycle of the CI types)
• Relationships between CI types E.g. "Is a component of" "Is associated with" "Uses" "Is a new version of" "Will be replaced by", …
• Authorities and controls
  1. CI type owner
  2. Authorities for creating, authorizing, modifying or deleting the CIs of this type, as appropriate, normally assigned as access rights in the CMS and relevant sub-systems
  3. Applicable controls, guidelines and policies (e.g. mechanisms to ensure that only authorized personnel is able to apply changes to the CIs and modify the related CI records in the CMS, or controls/ procedures to ensure the configuration data remain consistent when CIs are added or removed)
  4. Applicable guidelines and policies
  5. Reporting, auditing and verification requirements

Configuration Item Records - CI Records

The details of actual CIs ("instances of CI types") are stored in CI Records. The exact set of attributes to be maintained for a CI will vary depending on the CI type at hand, as specified in the Configuration Model.

CI Records typically contain the following information:

• Identifier (Unique identifier - ID)
• Name
• Description
• CI owner (CI owner/ person in charge)
• CI type
• Manufacturer information
  1. Manufacturer name
  2. Serial number
  3. License number/ reference to license contract
• Version information
• Location
  1. Physical location, if applicable
  2. Logical location, if applicable (e.g. URL or directory on a fileserver)
• Modification history of the CI Record
  1. Date of CI Record creation
  2. Modifications
  3. Date
  4. Person in charge
  5. Description of modification
• Status history (description of the life cycle of a CI with status values, as for example "Undergoing Test", ..., "Active", ..., "Undergoing Maintenance", ..., "Out of Operation", ...)
  1. Present status and version
  2. Status and version history (historical Changes to the status of the CI or Changes planned for the future)
  3. Status change
  4. Description
  5. Time and date of the Change in status
• Relationships to other CIs E.g. "Is a component of" "Is associated with" "Uses" "Is a new version of" "Will be replaced by", … ... including relationships to services supported by the CI.
• Licensing information
• Document references
  1. Contractual documentation
  2. Operating documentation
  3. User documentation
  4. Emergency-relevant documentation
  5. Other documentation

References to Configuration Items (CIs) - Note

CIs are typically referenced from other service management systems.
In an Incident Management system, for example, an Incident Record will contain a reference to one or more affected CIs. So these relationships are recorded in Incident Records rather than the CI records.

incident_record.md

Incident Record

Incident Record - Checklist

Overview :

An Incident Record is a set of data with all details of an Incident, documenting the history of the Incident from registration to resolution.
An Incident is defined as an unplanned interruption or reduction in quality of an IT service. Every event that could potentially impair an IT service in the future is also an Incident (e.g. the failure of one hard-drive of a set of mirrored drives).

• Unique ID
  (Unique ID of the Incident - usually allocated automatically by the system)
• Date and time of recording
• Method of notification
  (e.g. telephone, e-mail, intranet portal, event monitoring system)
• Service Desk agent
  (If applicable, Service Desk agent registering the Incident)
• Caller/ user data
  (If applicable, caller/ user contact information)
• Callback method
• Description of symptoms
• Affected users, locations and/ or business areas
• Affected service(s)
• Incident priority
• Incident Priority, a function of the following components :
  • Urgency (available time until the resolution of the Incident)
  • Impact (damage caused or potential damage to the business or the IT infrastructure)
  • Priority (for example expressed in priority codes like "Critical", "High", "Medium", "Low", "Very Low"): The result from the combination of urgency and impact
  • Major Incident flag (to indicate that the Incident is treated as a Major Incident)
  • (for further information, refer to the checklist Incident Prioritization Guideline)
• Relationships to CIs
  (Links to primary Configuration Items (CIs) affected by the Incident)
• Incident category
• Incident category, usually selected from a category-tree according to the following example :
  1. Hardware error
     1. Server A
        1. Component x
           1. Symptom a
           2. Symptom b
              ...
        2. Component y
           ...
     2. Server B
        ...
  2. Software error
     1. System A
     2. System B
        ...
  3. Network error
     ...
     (Incident categories should be harmonized with Problem categories to support matching between Incidents and Problems)
• Links to related Incident Records
  (if a similar outstanding Incident exists, to which the new Incident is able to be attributed)
• Links to related Problem Records
  (Links to related Problem Records - if any outstanding Problems exist, to which the new Incident is able to be attributed)
• Incident status change history
• Date and time
• Person in charge
• Reason for status change
• New Incident status
• Activity log/ resolution history
• Most service desk systems allow maintaining a simple log of steps carried out to resolve the Incident. Some systems, however, also provide the means to assign “Tasks” to Incidents. Akin to the Incidents they are assigned to, Tasks are typically characterized by properties like name, description, owner, priority, etc. and contain a status history and activity log of their own.
• Closure data
• Closure categories (if required, revised product and Incident categorizations)
• Problems raised (if the Incident is likely to recur and preventive action is necessary)
• Resolution type (elimination of the root cause vs. application of a Workaround; if the Incident was resolved by applying a Workaround: indication of applied Workaround)
• Customer feedback (is the Incident resolved from the customer’s/ user’s point of view?)

service_portfolio.md

Service Portfolio

Overview

Fig. 1: ITIL Service Portfolio - Definition and information flow.
The Service Portfolio represents a complete list of the services managed by the service provider.
Some of these services are visible to the customers (Business Services, whose level of service is defined by SLAs), while others are not (Infrastructure Services, whose level of service is defined by OLAs or UCs).
The Service Portfolio contains present contractual commitments, new service development, and retired services. It also includes third-party Infrastructure Services which are an integral part of the service offerings to customers.
The Service Portfolio is divided into three sections: Service Pipeline, Active Services (Service Catalogue), and Retired Services. Services should be clustered according to Lines of Service based on common business activities they support. Only active services are visible to customers.
Rather than maintaining one single document, it is advisable to create a hierarchical structure of linked documents, or to use a dedicated database or application in order to manage the Service Portfolio. Ideally, the Service Portfolio is part of the CMS.

Service Portfolio - Contents

For each service the Service Portfolio defines:

• Name
• Current lifecycle status of the service (e.g., "Proposed", "Defined", "Chartered", "Designed", "Built", "Tested", "Released", "Operational", "Retired")
• Service Type
  1. Customer-facing service (services delivered to the customers) or supporting/technical service (invisible to the customers, used to underpin customer-facing services)
  2. Internal/ external: Internally provided service or a service sourced from an external service supplier
• Service Owner (responsibility for service provisioning)
• Customers (customers currently using this service)
• Contacts and procedures for signing up to the service
  1. e.g. contact details of the responsible Service Level Manager
  2. Procedure for signing up
• Description/ desired customer outcome
  1. Business justification (value added from a business point of view)
  2. Business processes/ activities on the customer side supported by the service
  3. Desired outcome in terms of utility (example: "Field staff can access enterprise applications xxx and yyy without being constrained by location or time")
  4. Desired outcome in terms of warranty (example: "Access is facilitated worldwide in a secure and reliable manner")
• Offerings and packages, variations
  1. e.g. different Service Level packages on offer
  2. e.g. different coverage of time zones
  3. e.g. different coverage of geographical regions
• Costs and pricing
  1. Available pricing schemes for the service provision
  2. Rules for penalties/ charge backs
• Dependencies
  1. Services
  2. Required Infrastructure Services (Infrastructure Services on which this service depends)
  3. Supported services (other services which depend on this service)
  4. Components/ Configuration Items (major CIs like on which this service depends)
• Planned changes to the service (if any)
  1. References to relevant plans (e.g. Service Strategy Plan, Strategic Action Plans, entries in the CSI Register)
  2. Business case/ cost-benefit analysis
  3. Priority of the envisaged change
  4. Risks associated with the envisaged change
  5. Time schedule and status information
• References to further documents