Introduction
The official definition of an ITIL Service Catalogue is:
(
ITIL Service Design)
A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the ITIL Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.
Although ITIL mentions or refers to a Service Catalogue, little information is provided with regards to what it might contain. In this article we have taken the opportunity to provide detail of what could be considered for inclusion. We suggest that the Service Catalogue can be produced as a simple spreadsheet. We acknowledge that additional information could be included such as deliverables, prices, ordering and request processes, although this is dependant on how the Catalogue is to be utilized by the organization.
The Service Catalogue provides the ability to contain critical information in a central repository accessible by both the IT department and the Business. The information contained within the Service Catalogue relates to all Services provided by the IT department to the Business. The Service Catalogue is generic and can be applied across all platforms, environments or geographical locations of any organization.
Several vendors offer Service Catalogues that conform to what ITIL suggest and in some cases are able to offer additional features and functionality that may benefit an organization, it may be worthwhile reviewing what they have to offer.
Service Catalogue Definitions
The following data elements are suggested for inclusion within the Service Catalogue, but are by no means exhaustive and one might expect data elements to be added or removed as the benefits and uses for the Service Catalogue are recognized.
The suggested data elements are:
- Service Name
- Service Description
- Availability
- Target Availability
- Backup
- Service Owner
- Service Representative
- Service Criticality
The suggested data elements listed above are now explained below.
Service Name
The Service Name should state the term(s) by which the Service is referred to by the Business community and also the term(s) referred to by the IT community. Clear distinction must be made as to which community the term is known by.
Simple as this may be, documenting the Service Name eliminates any confusion that may exist around the name or names of a Service. Often Service Names differ between the Business and the IT community. An understanding or translation of the Service Names is probably no more important than on the Service or Help Desk(s). A clear understanding ensures effective and efficient management of any incident or request that may be posed to the IT department.
Service Description
The Service Description should be written in easy to understand, simple, non technical terms that almost any person within the organization could understand. The Description should be at a very high level with no more than two or three lines at the most, ideally it should be written by a member of the Business community.
Availability
The Availability data should contain details relating to the availability of the service both in hours and days, stating any exceptions, for example: 07:00 – 19:00 Monday to Friday excluding Bank Holidays.
Critical periods for the Service to the Business should also be stated for example: last Thursday and Friday of each month and the last week of March (year end). Critical period information also assists Change Management with regards the authorization and scheduling of Requests for Change (RFCs).
If known, the number of Business Users who use the Service should be stated, this assists with understanding the potential impact of the unavailability of the Service. In addition it can focus the minds of the Support personnel within the IT Department and thus encourage a speedier recovery of the Service when unavailable and also ensure Changes are made at times which are acceptable to the Business i.e. with minimal impact and risk to the Service and Service Level Agreements.
Finally, if the information is not sensitive, consider including figures regarding how much revenue the Service generates for the organization, this can also assist in focusing the Support teams. In addition the cost of unavailability can be roughly calculated and reported upon in association with Service Level Management.
Target Availability
Consideration should also be given to including a target availability which the IT department is striving to achieve. Once again this should be reported upon and where the Target Availability is not being achieved Service Improvement Programs can be instigated.
Backup
The type of Backup together with its frequency should be stated, for example: incremental backups Monday – Friday and full backups on Saturday.
Service Owner
The Service Owner is the person within the organization who provides the funding for the Service – the person with the check / cheque book. In addition the Service Owner potentially provides an understanding with regards the level of Service currently being delivered and that required for the future.
Service Representative(s)
The Service Representative(s) provide a focal point for communication between the IT department and the Business community. The communication should be two-way and allows the Business and IT to work together in partnership. Examples include the provision of regular updates to the Service Representative during major outages (major incidents), as well involvement in decision making from a Business perspective. The Service Representative would then be responsible for the dissemination of the status of the Service to other members of the Service community.
The Service Representative would also be included in the ITIL Change Management process, providing input into the assessment, authorization and scheduling of any Requests for Change (RFCs).
Ultimately, the Service Representative provides an invaluable bridge between the IT department and the Business community, the importance of this relationship should not be under-estimated. Other titles could include Account Manager or Business Relationship Manager.
Service Criticality
The criticality of the Service is determined by the Business. The following list is a suggested structure for determining the ‘service categories' and corresponding criticality of organizations services, for definitions of the categories please refer to the section below entitled ‘Standard Service Definitions':
- Mission Critical
- Business Critical
- Business Operational
- Administrative Services
In addition it may be beneficial to ask the Business the sequence in which the Services should be recovered should a major disaster occur. The Businesses knowledge of revenue generation, customer impact and marketplace visibility is invaluable when determining the recovery sequence. The feasibility of the recovery sequence may need to be discussed with the IT community.
Standard Service Definitions
The service categories used in the Service Definition Matrix are based on the standard industry definitions given in the following sections.
Mission Critical
A mission critical service requires continuous availability. Breaks in service are intolerable and immediately and significantly damaging. Availability required at almost any price.
Key characteristics of this type of service are:
- Generates revenue: customer orders are booked through the service
- External customers are direct users of the services
- Underpins other services
The typical impacts of a service outage are:
- Immediate reduction in revenue
- Damaging for the company's commercial reputation and credibility
- Long-term outage threatens bankruptcy
An example of a mission critical service is a financial trading application of a bank or financial institution.
Business Critical
A business critical service requires continuous availability, though short breaks in service are not catastrophic. Availability required for effective business operation.
Key characteristics are:
- Indirectly affects revenue generation and may prevent collection of revenue
- Supports customer facing activities
The typical impacts of a service outage are:
- Inability to collect revenue efficiently
- Long-term outage can significantly reduce company cash flow
An example of a business critical service is the customer billing application.
Business Operational
Contributing to efficient business operation but out of direct line of service to customer.
Key characteristics of business operational:
The typical impacts of a service outage are:
- Reduced efficiency and increased cost of operations
An example of a business operational service is enterprise messaging.
Administrative Services
Services on the level of office productivity tools, required for business to operate. Failures are undesirable but do not affect customers and can be tolerated a little more. Cannot justify extreme additional expenses for higher availability.
Key characteristics:
The typical impacts of a service outage are:
- Reduced individual performance and productivity
Examples of administrative services applications are desktop applications.
We hope you found this article interesting and of value, if you have any comments, practical experience or advice to share then please
contact us.