Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: StewartDug
New Today: 22
New Yesterday: 34
Overall: 231560

People Online:
Visitors: 139
Members: 0
Total: 139



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Arguments of why starting impl. with SLM process or not...
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Arguments of why starting impl. with SLM process or not...

Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message

Joined: Jan 25, 2006
Posts: 4

PostPosted: Fri Mar 17, 2006 10:58 pm    Post subject: Arguments of why starting impl. with SLM process or not... Reply with quote

Hello again,

I also wonder if there are anyone with good arguments of pros and cons with starting an implementation in this order.

1. SLM
2. Incident
2. Problem
3. Config
3. Change

Are there suggestions of better order of implementing processes?


Back to top
View user's profile
Senior Itiler

Joined: Nov 01, 2004
Posts: 83
Location: Sask, Canada

PostPosted: Thu Mar 23, 2006 3:38 am    Post subject: implementaion order Reply with quote

hmm. not sure how much of each process you plan on having up and running before you start on the next, but from my Problem Management Practitioner point-of-view, I think I would have been sunk without some kind of Change and Config being there first.
/Sharon E
Back to top
View user's profile Send e-mail

Joined: Mar 18, 2006
Posts: 4

PostPosted: Thu Mar 23, 2006 12:11 pm    Post subject: Reply with quote

I think the order should be:

1. Change
2. SLM
3. Incident
4. Problem
5. Config

Because you need the Change Management even if you alter your SLA. On the other hand, incident management is always form the first test for your SLM capabilities.

Good Luck!
Back to top
View user's profile
Senior Itiler

Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Fri Mar 24, 2006 12:45 pm    Post subject: Reply with quote

Good day all,

My vote, and it's a biased one, is to implement them all at once. The organization that tries to roll them out one at a time will spend a fortune, over time, and will have a bunch of processes and point solutions tools that don't integrate and compliment each other properly.

If you find a tool, like ours, that can provision a platform of solutions for each of the domains mentioned, all at once, then all you have to worry about is focusing on the process definitions and implementation, which can be done rather quickly once the tools are in place.

Remember, if you roll out one process at a time, you will need to pick tools to support that process. The tools you pick or build will rarely, if ever, be compatible to the tools you are going to pick and use for all of the other process domains. What this will lead to are very expensive post deployment costs, associated with the integration of all these individual point solutions.

Anyhow, I hope this helps.

[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website

Joined: Jul 26, 2005
Posts: 42
Location: Northern Virginia, USA

PostPosted: Fri Mar 24, 2006 10:57 pm    Post subject: Delay if Possible Reply with quote

If you can, I think SLAs should be one of the last products of an ITIL implementation. SLAs need to be based on reliable metrics, with processes and procedures in place to collect and monitor them. All too often SLAs are cut first based on myth, and far too much time is spent trying to meet unrealistic goals.
Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Sat Mar 25, 2006 12:12 am    Post subject: Reply with quote

I may as well add my current thinking in regard to the processes mentioned. Take into account the fact that we are not yet formally implementing ITIL where I work, I'm kind of slipping ideas for working practice through the back door until we get the official go ahead!

1a. - Part of SLM - defining the services before...

1b. Service Desk and Incident Management- I think that a relatively mature incident management and service desk are needed before putting anything on top of them to help understand what it is you are actually dealing with.

2. Change - If you aren't dealing with faults, then you are dealing with changes to the service, configuration, etc. So I think this process is important before you start on configuration otherwise you have no control over what is there and how it is updated.

3. The rest of SLM - WIth the first parts in place, you should have the basis for some measuring and be able to create a reasonable SLA with realistic expectations.

4. Config - This is important to support all the other processes, but as I already said, there is no point having it without a good change process in place.

5. Problem - Out of the processes mentioned I view this more as a 'nice to have' and put in once the basics are right and everyone is working together. If you have enough people to put it in alongside Incident management then great, we don't.
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Sat Mar 25, 2006 1:49 am    Post subject: Reply with quote

Having already implemented Change without Config - No don't ask! This is not something I would recomend to anyone.

There are too many potential problems waiting for you - problem changes because Joe didn't reaslise that this config file impacted these other three processes. Etc etc etc.

I firmly believe that if you must do the implementation piecemeal then be very aware that Change, Config and Release go hand in hand.


Back to top
View user's profile
Senior Itiler

Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Sat Mar 25, 2006 10:06 am    Post subject: Reply with quote

I'd be listening to the people who have actually done it in the real world rather than me Smile

Good point on the change, config, and release. I tend to see the change and config a little like the chicken and the egg quandry. You don't want to have config without change for the reason I stated above, but equally you don't want change without config as you want to know what you are impacting. The answer, do both!

Ideally the three go in at the same time due to the dependencies between processes.

In the same way ideally you'd look at service desk, incident, and problem as a group correct?

I honestly don't think there is any easy or right answer to this one. No matter which processes you opt for, you'll always be missing out on the benefits that are brought about by having all of the processes.

I suppose the real question is which benefits do you want to achieve first, then implement the processes that help you get there... Thoughts?
Back to top
View user's profile Visit poster's website

Joined: Jan 25, 2006
Posts: 4

PostPosted: Mon Mar 27, 2006 9:27 pm    Post subject: Reply with quote

Thanks to all of you who have taken time to answer on my question.

However, they gave me more questions than answers since my teacher at the ITIL Service Manager course gave the following order and reasons of initial processes to start with:

1. Service Level Management - In order to define what to deliver and what the requirements are.

2. Service Desk, Incident and problem - In order to start delivering what customers expect.

3. Config and Change - In order to handle changes of the infrastructure.

Those processes show the quick-wins best and will then handle the risk of loosing commitment after first year. In a pure best way according to ITIL my teacher said starting with Config and Change would be best, but then you could have hard time getting attention after a while since implementing those processes will cost and doesn't show the quick-wins as good as the previous suggestion. Any thought about this?

I guess there is no single way (right or wrong) of how to do this, so it was interesting to get all your oppinions.


Back to top
View user's profile
Senior Itiler

Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Mon Mar 27, 2006 11:48 pm    Post subject: Reply with quote


your teacher is pretty much on the money. I would suggest the following clarifications might be helpful:

Services are the heart and soul of the ITIL framework - everything revolves around this concept and without it you are just doing better technology provision. So yes SLM is the obvious strating point.

The good news is that Service Definition (and Service Level Management in general) is probably the most scalable process in ITIL. If you start by simply producing rudimentrary Service Definitions, perhaps a simple catalogue of services, and in the absence of mature customer relations you can implement Service Level Objectives (unilateral) to stand in for missing SLAs.

That will be enough to kick start your Service Desk and Incident management process. These too can be scaled effectively. The trick is to keep them in scope, and not to overload them with compensations for the missing processes. The example I site most is the tendency to build an initial incident classification schema that categorises your infrastructure. Totally unecessary - a simple service / symptom type schema can support all you incident managment objectives and produce excellent business information.

The usual step then is to implement problem and change mangement.

Problem management is less problematic than you might think - because most of the 'firefighting' you curently do is probably that. The hard part will be to build the process connections between you incident management and problem management processes to ensure that problem management is being driven by the service quality imperitives your incident management process should be identifying.

Change management can be scaled also. Of course it is best if configuration management is in place - but there will be a lot of standard changes you can begin with. Secondly, you are already changing things without config management. There is a lot in change management that can be of value even without a CMDB to update, because it will introduce formal assessment, approval, planning, back-out planning etc. (Of course these are more effective with advanced config data, but that doesn't mean these disciplines have no value in their own right.)

And finally config management: This can actually be scaled. As I said you are already dealing with the infrastructure anyway - to whatever level of competancy. So instead of trying to build a total-it-universe picture, and aim straight at delta-audit capability, think of the CMDB as a 'picture' of your infrastructure - an abstraction. or representation that you use in management control processes. There is a differrence between 'accuracy' and 'detail' - in both pictures and CMDBs. (A picture of the earth from the moon has less detail than a picture from orbit, but it is just as accurate). In the CMDB accuracy is actually more important than detail.

Which is a long winded way of saying you can scale a CMDB from the top down. Start with your Services, and populate the CMDB first with simple records representing the major systems that produce them. Apply change and configuration management controls at that level - it can be done, because that's already what's going on in the heads of your technology owners anyway. Then as you develop and mature your processes, and especially your service definition model, you can extend the scope of the CMDB 'down' into the detail of the infrastructure, until you get to the point where the cost and returns are balanced according to your overall service management objectives.

I caution against the concept of 'quick wins' however - that always leads to dissapoinment. Rather I advocate realistic 'scope'. Learn how to objectively assess Service Management process maturity before you do anything, then set the initial maturity levels you are aiming for realistically. Make sure you identify the true value that can be achieved at the target level and promote that. Remember everyone who delivers more than they promise succeeds Smile

Personally I know what it's like to slog away for two years and never seem to get anywhere, and I know what it is like to work for six weeks and return real demonstrable value. Wink

Go for it....
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger

Joined: May 11, 2006
Posts: 32

PostPosted: Wed May 17, 2006 6:15 pm    Post subject: Reply with quote

I mainly agree with ITILIMP.

From Change Manager point of view I could do nothing without:

1. Basic SLM (at least Service Catalogue)
2. Service Desk and Incident Management
3. Configuration Management

I cannot imagine to have controlled Changes withouth at least some basic Configuration Management.

Problem Management I would put somewhere at the end of your list.

I don't think it is possible to implement processess one by one and that's it. You have to implement part of SLM, part of Change Mgt., part of Configuration Mgt. and then again and again until you reach satisfactory level.

It is a very good recomendation to see ITIL deployment as a big, long-term project, which products are handed over to Operations.
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.