- Service Name
- Service Description
- Target Availability
- Service Owner
- Service Representative
- Service Criticality
- Mission Critical
- Business Critical
- Business Operational
- Administrative Services
- Generates revenue: customer orders are booked through the service
- External customers are direct users of the services
- Underpins other services
- Immediate reduction in revenue
- Damaging for the company's commercial reputation and credibility
- Long-term outage threatens bankruptcy
- Indirectly affects revenue generation and may prevent collection of revenue
- Supports customer facing activities
- Inability to collect revenue efficiently
- Long-term outage can significantly reduce company cash flow
- Internal users only
- Reduced efficiency and increased cost of operations
- Internal users only
- Reduced individual performance and productivity
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'.
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.
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.
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.
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.
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.
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.
(There are 5 comments awaiting publication).