Posted: Wed Mar 26, 2008 1:22 am Post subject: Service catalog and CMDB
I'm in charge in my company of creating a service catalog and map it with the CIs defined in our CMDB.
I'm not really familiar with IT services. I've been looking through the internet to have an exact definition of it services, with no results .
Could you please give me a definition of what should be considered as it service?
For example, we have a billing system that is formed by some modules, does each module should be considered as a service?
what about all the services used internally, as DNS? FTP? VPN? etc...
How should these be considered?
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Wed Mar 26, 2008 2:03 am Post subject:
The easy answer is: a service is whatever you want it to be. With that I mean that there is no exclusive definition of a service. Ask 100 service managers for their definition and most likely you'll get 101 answers.
That said, check out the following posts before restarting this one:
ITIL Discussion: Definition of services
ITIL Discussion: What data to be collected for compiling service catalogue
ITIL Discussion: Supporting service specification
I am sure that you'll find something worthwhile there.
Joined: Mar 04, 2008 Posts: 1890 Location: Helensburgh
Posted: Wed Mar 26, 2008 2:15 am Post subject:
I see the experts have got in before me. I'll post this anyway in case it helps and because I've written it and don't want to have wasted my time.
I can offer a few pointers, but they may sound not very helpful.
Firstly, there is no such thing as an exact definition of an IT service. What you call a service depends on what you want to do with it.
Maybe a service is something your customers can choose to use (and pay for?); in that case you have to call it something your customers understand and they have to understand what it does for them.
Take your billing system. Is it practical to offer a single module as a service to a customer without exposing that customer to the rest of the system? Probably not, but if it is then the module could be a service.
More likely, different users (same customer) will use different parts of the system. Then it is better for modules to be service components of the same overall service.
With internal services things can get complicated:
Some things can be regarded as services to the service staff - e.g. help desk software system, performance monitoring system. So, in many ways it is a service but your customers are internal - it's down to policy and culture how you designate that.
Some could be background things that glue your infrastructure together - probably DNS and VPN, but it depends on how you want to recover costs how you treat these. I don't see these going in a service catalogue.
Some might fall between all the stools - FTP is a good example, I can imagine an end user suddenly calling up to ask if they can use FTP to communicate with an outside body; then it really ought to be set up as a service.
I think that you will find other people take a completely different view on this subject. The impractical extremes of a service catalogue are to put it at a high generic level (because it is difficult to make meaningful quantitative and qualitative statements about it) or to pitch it down at technical sub-component level (e.g. receive email, send email, tidy email, backup email instead of just email service)
There is also the issue of services that are so specific that they are only for one part of your organization (Bills of Quantity, metallic fatigue analysis) and others that will have widespread use (email, diary) and the in-betweens - of course - that are used widely but have to be under control of one "customer" (self-service HR, accounting processes). So you have to design a catalogue that makes sense of all that. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
I've passed the ITIL fondation and Practitioner training and exams successfully .
This didn't give me a more clear definition of IT services
In my company, I'm in charge of the change management process but I have lots of problems defining the impact of each change. That's why I need to define the services we provide to our end users and those we provide internally and define also the interaction between all these services and the CIs of our CMDB.
Diarmid, Thanks for your answer.
Another question is for SLAs, do we need to create one SLA for each service we provide to the users?
Joined: Mar 04, 2008 Posts: 1890 Location: Helensburgh
Posted: Wed Mar 26, 2008 7:28 pm Post subject:
there are two schools of thought on this.
One is to provide an SLA per customer with subordinate sections for each service. The advantages of this are the ease of customer service review, easy tailoring and dove-tailing of services for that customer, and probably some more stuff that will come to mind later.
The second is to define an SLA for each discrete service and package them up for each customer as required. This way you have a consistent framework for how you define each service.
I sometimes thing that it doesn't matter tuppence which you do because pretty much all the same words will appear in much the same way either way round and so it's just a matter of document control.
On the other hand, with internal service provision, there can be complications. For example you will/may not want to negotiate certain services (such as email) separately with each division. This is easiest achieved if you have individual SLAs because you will/ought to be negotiating the agreement with some corporate body.
So, surprise, surprise. This answer turns out to be: it depends on the relationships between service provider and service customers or how your corporate culture works. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
as for the SLA per service / customer it depends. If you are starting out you probably don't have a service catalogue therefore canot produce an SLA for each servcie. You can however produce a single SLA covering say - standard responce and resolution times for incidents and service requests that apply across the board. This can be seem ad a global SLA. As you develop your understanding of services you can then develop individual SLA's on a per service basis which may aslo still refer back to the global SLA for the incident response and resolution times (generally associated with the priority of incidents)
One thing to note is that if youdo go down the road of one SLA per service and you have 100 services do you have the admin resources to keep the SLA's up to date and reviwed etc.
As for services - yes it depends who we define as the customer. However to get thing doing define a service as somethig that helps achieve a business outcome = business service.
What makes up a business service are the IT Systems that are in place that provides the ability for a user to "use" or "consume" a busines service.
IT systems can be LAN, WAN, Exchange systems
A user does not talk about using the LAN or an Exchange systems - they talk about being able to send emails. Email could be seen as a business service built on IT Systems.
Business services should be precieved by the user and be labled in "user" speak.
Granted this is a generalist view on Services but I feel that you need to speprate out the IT Systems and Business Services to understand "services" and then link them together. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum