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
- Target Availability
- Service Owner
- Service Representative
- Service Criticality
The suggested data elements listed above are now explained below.
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.
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.
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.
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.
The type of Backup together with its frequency should be stated, for example: incremental backups Monday – Friday and full backups on Saturday.
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.
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.
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.
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.
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.
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.
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.
- 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.
GreyCampus provides 50% discount on professional certification courses like Project Management Professional, Six Sigma Green Belt, Six Sigma Black Belt, Lean Six Sigma Green Belt, Lean Six Sigma Black Belt, ITIL Foundation, PRINCE2 Foundation, PRINCE2 Practitioner, PMI-ACP, CAPM.
Use Coupon code "PROF50" on all Online standard courses to avail this offer.
25 VISITOR COMMENTS
2010-06-25 by "pete.hipkiss"
2010-10-18 by "peter.hodgetts"
2011-01-06 by "cfp"
2011-01-19 by "sachinsalvi"
2011-02-25 by "kafshar"
2011-03-31 by "alyke11"
2011-04-05 by "amandabarkus"
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"
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"
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"
2011-11-23 by "neil"
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.
2012-05-04 by "ralf.hemmers"
2012-08-07 by "ami"
1. Price (Monthly and setup fee)
2. SLA time frames
There is an interesting question:
those the SLA level is a property of each service or should it be separated to different services (one service can be offered in different SLA levels).
The Service Catalogue has been explained as perhaps the fundamentals to include. nevertheless the additions suggested could also be included.
In answer to your question which we have hopefully understood we have the following comment:
In our experience we have often written Service Level Agreements (SLAs) and referenced the Service Catalogue or added it as an appendix of the SLA. The SLA may apply to a specific group of customers who for instance use one particular service or it could apply to a specific customer who uses a set or portfolio of services.
Care should be taken when including pricing within the catalogue as some customers may which this information to not be widely available. We would recommend checking with the customer before including. Secondly, the Service Catalogue should be easily accessible to all as it provides a single point of reference and eradicates potential confusion.
So based on your customer base, whether they are internal or external customers you wish to use the service catalogue for general use, but possibly provide a separate version which contains pricing to aid with discussions with those stakeholders involved with budgets and paying for services.
It would be interesting to have your thoughts on this matter and potential the direction you may or have taken.
2012-11-26 by "hi_lizm"
2013-03-16 by "nanalekgau08"
The Service Catalogue can be produced in whatever media that works for the organization in question.
I have produced the Service Catalogue as an Excel spreadsheet which was attached as an appendix to a Service Level Agreement. I have also created a Service Catalogue in Word format that was a separate document in in its own right that was referenced by a Service Level Agreement. Also consider having the agreed Service Catalogue accessible via an organizations intranet.
So as you see it does depend on the audience who are going to use the Service Catalogue. It would be interesting to hear if any other formats having been used successfully.
2013-03-23 by "Kristathompson"
2014-01-15 by "deallen"
We support 3 quasi-autonomous Bus. Our services are arranged in a 3 tier hierarchy:
1) families of services
2) lines of service
3) the app service.
Family: Prod & App Dev Services
Lines: Doc&Localization, Training, Config&Build, Quality, RequirementsMgmt, and TaskMgmt.
Services: Each line has 1 - 6 app services.This structure let's us analyze costs/benefit at each of the three levels: Familly, Line, Service.
2014-07-24 by "bill.cooper"
2015-05-27 by "mannk"
2015-10-15 by "sophie.reynolds"
2015-11-11 by "larsholdgaard1"
2016-02-08 by "joe.dsouza"
The second paragraph of "Availability" should have been under discussion under "Scope".
If I were to rewrite this, I would include "Scope" as a separate sub topic and discuss scope related discussions under that...
Also under "Availability" the last paragraph discusses "Operational Costs". Wrong place. And no separate space for "Operational Costs".
There are other smaller improvements I could suggest but those are minor and probably not worth sweating over...
2016-03-24 by "bryan.gervais"
2018-09-11 by "ekralicek"
2021-09-30 by "s40359"