![]](/nav/3dbar_grey_right_1.gif)
|
 |
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:
- Internal users only
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:
- Internal users only
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.
2010-06-25 by "pete.hipkiss"
Congratulations At last someone who has defined a Service Catalogue in a concise and practial way
2010-10-18 by "peter.hodgetts"
Very helpful. Thank you.
2011-01-06 by "cfp"
I find this article extremely good, consice, consistent and coherent. A good usable interpretation of ITIL. Thanks
2011-01-19 by "sachinsalvi"
Service catalouge is prime important from Service Management standpoint and your points on how to achive good catalouge are praise worthy.
2011-02-25 by "kafshar"
Very helpful. Thank you
2011-03-31 by "alyke11"
That's good work. Thanks for the depth.
2011-04-05 by "amandabarkus"
Thank you for the article. I would have liked to see some information on how to define a service, maybe with a set of questions that one can answer to decide if an application should be considered a service on its own or not. For example, a trading system is a service but a small program that translates messages from one format to another may not be a service on its own (could be grouped with some other service). This type of basic info would be really valuable to your community.
Replies to the post above;
2011-05-09
Many thanks for your enquiry. It is an interesting question that you ask. It is worthwhile establishing under ITIL what the definition of a 'Service' is... the definition states:
A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.
Determining what constitutes a service within your organization will ultimately require sitting down with the various 'Business' and / or 'Customer' representatives and simply asking the question. It is quite an experience obtaining the Business or Customers view of the service(s) offered by IT - it can be humbling seeing services offered from those who receive them.
In our experience we have found following on from the formuation of a 'Service Catalogue' is the establishment of Service Level Agreements. It is at this stage that we find that 'critical' elements of a service are identified and need to be documented. On one occassion we met with the Finance department representatives who stated that on the last working day of each month the availability of a specific printer was critical to the organization as a whole. The 'configuration item' details were captured and the Configuration Management System (CMS) was updated to reflect the criticality of the printer at specific times. The Service Desk were then able to raise appropriate 'severity' incidents thus ensuring the appropriate response and support were provided.
The printer may well have been perceived as part of the Desktop service yet the importance overlapped into the Financial service itself, yet without liaising with the Business the criticality of the printer may never had been known.
There will inevitably be components of an overall service that are critical to certain customer or business communities, needless to say understanding who will be effected is very important. Working with the 'Key Service Contact' will assist with defining exactly what constitutes a 'service'.
A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.
Determining what constitutes a service within your organization will ultimately require sitting down with the various 'Business' and / or 'Customer' representatives and simply asking the question. It is quite an experience obtaining the Business or Customers view of the service(s) offered by IT - it can be humbling seeing services offered from those who receive them.
In our experience we have found following on from the formuation of a 'Service Catalogue' is the establishment of Service Level Agreements. It is at this stage that we find that 'critical' elements of a service are identified and need to be documented. On one occassion we met with the Finance department representatives who stated that on the last working day of each month the availability of a specific printer was critical to the organization as a whole. The 'configuration item' details were captured and the Configuration Management System (CMS) was updated to reflect the criticality of the printer at specific times. The Service Desk were then able to raise appropriate 'severity' incidents thus ensuring the appropriate response and support were provided.
The printer may well have been perceived as part of the Desktop service yet the importance overlapped into the Financial service itself, yet without liaising with the Business the criticality of the printer may never had been known.
There will inevitably be components of an overall service that are critical to certain customer or business communities, needless to say understanding who will be effected is very important. Working with the 'Key Service Contact' will assist with defining exactly what constitutes a 'service'.
2011-04-13 by "fredrik.m.lind"
The information contained within the Service Catalogue relates to all Services provided by the IT department to the Business. Sounds promising but reading further I get the impression that it only covers IT systems ?
Replies to the post above;
2011-04-29
The Service Catalogue has been written to refer to IT systems but incorporating Business Services should not be an issue as the approach is flexible.
We would simply add the Business Services and perhaps for simplicity, using a spreadsheet, colour code such services as necessary.
Secondly review the headings to ensure they are still applicable for your Business Services requirements.
We have used such an approach whereby a Service Catalogue is produced incorporating services that are provided by individual regions.
We would simply add the Business Services and perhaps for simplicity, using a spreadsheet, colour code such services as necessary.
Secondly review the headings to ensure they are still applicable for your Business Services requirements.
We have used such an approach whereby a Service Catalogue is produced incorporating services that are provided by individual regions.
2011-06-01 by "bannyk.76"
It would be helpful if some templates on Technical Service Catalog and Business Service Catalog are provided.
Secondly the way IT sees a service and from business stand point are completely different. So if you could provide a mechanism on how you can align business service underpinning with IT and produce a Business service catalog would be helpful.
Secondly the way IT sees a service and from business stand point are completely different. So if you could provide a mechanism on how you can align business service underpinning with IT and produce a Business service catalog would be helpful.
2011-11-08 by "andy_peters"
This made an interesting read. I hope to meet with our business reps soon, so should be interesting!
2011-11-23 by "neil"
Why is Service Catalogue mentioned in detail in Service Strategy (ITIL foundation exam book) when it is Service Design?
Replies to the post above;
2011-11-28
I suspect that the Service Catalogue is stipulated in Service Strategy as it is a mechanism to capture details of 'services' that may very well not come to fruition, in other words strategically they are captured as an entry but due to events and direction of the organization may become superfluous and therefore do not enter the 'Service Design' phase.
It might be worthwhile taking a look at the following article as it probably explains things a little better:
ITIL V3 Service Portfolio and Lifecycle
Please come back and share your thoughts.
It might be worthwhile taking a look at the following article as it probably explains things a little better:
ITIL V3 Service Portfolio and Lifecycle
Please come back and share your thoughts.
(There are 2 comments awaiting publication).
NB: This page is © Copyright ITILnews.com and / or the relevant publishing author. You may copy this article only in it's entirety, including any author bio and / or credits, and you must link back to www.itilnews.com.
