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

Current Membership

Latest: OEdmiston
New Today: 0
New Yesterday: 97
Overall: 143673

People Online:
Visitors: 52
Members: 1
Total: 53 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

ITIL :: View topic - Change Management relation with SLA's
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change Management relation with SLA's

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
bobduncan76
Newbie
Newbie


Joined: Jun 05, 2006
Posts: 12

PostPosted: Tue Dec 19, 2006 12:10 am    Post subject: Change Management relation with SLA's Reply with quote

What details would Change Managament want from an SLA?

TIA.

Bob.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3305
Location: London, UK

PostPosted: Tue Dec 19, 2006 6:34 am    Post subject: Reply with quote

Well

I want the Service Catelogue details as to the service being provided to the users

Data like

Who the users are for the service provided
what are the expectations in the SLA about maintenance windows, changes etc

I want the entire SLA so when I have to deal with the service associated with the SLA, I know some of the risks/impacts of changes on that services
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Tue Apr 24, 2007 7:55 pm    Post subject: Reply with quote

>>What details would Change Managament want from an SLA?

>what are the expectations in the SLA about maintenance windows,
>changes etc

This a a little vague. There should not be expectations in an SLA, there should be hard data. e.g. the maintenance window is 0000 - 0200 on the 1st Sunday of the month etc. In fact the SLA and SLD (Service Level Description) should be dictating all of the major influences in the change process for that service. By that I mean the cost, the time taken to perform a change, the affected systems, windows in which the change may be performed etc.

>I want the entire SLA so when I have to deal with the service
>associated with the SLA, I know some of the risks/impacts of
>changes on that services

I agree you'd want the entire SLA, (and the SLD as well). But again this is a little vague. You *must* have the SLA/SLD so that you know *all* of the potential risks and impacts on the existing service.

How can the CAB authorise a change if it does not know the cost, impact, lead times, risk, change window etc. for that service? In other words all of the information the CAB needs to process a change request should exist in the SLA/SLD. This is also how the CAB knows whether a request is urgent or not.

The change management process is reasonably easy to define in terms of the processes, roles and responsibilities. However, the data captured, timings, and decision making factors are all dependent on the specific service, and hence on the SLA/SLD.

The SLA/SLD should be driving the change management process to a much greater degree than the general impression I get from reading this forum suggests.

Dave
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3305
Location: London, UK

PostPosted: Wed Apr 25, 2007 4:32 am    Post subject: Reply with quote

Dave,

If there is a service being provided using IT equipment, there needs to be within the SLA or contract that the department supporting that kit can conduct periodic maintainence (monthly) on the kit and consider the time outside of SLA Operating Hours

In addition. the IT Operations group needs also to have the ability to do emergency S/W and H/W patching in regards to security or vulnerability concerns

Some SLAs are written very broadly, poorly or not at all when it comes to needed downtime, service hours etc.

The Change Mgmt process while it does need to identify the risks and impacts of a change, the members of teh CAB should come from the service provider and the service consumer - even it is all one company

As to costing etc, that is usually handled with a company through cross charging or budget codes of the staff's hours.

I dont think a change request should be held up because of penny pinching.

It usually costs the company more later
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Wed Apr 25, 2007 7:12 pm    Post subject: Reply with quote

John,
this seems to have become a longer post than I expected; apologies to those who like short answers:-)

I totally agree with what you say, but I'm not sure how that is incompatible with my post. Any halfway competent ICT provider will ensure they have provision for emergency maintenance at any time - however this should not be an excuse to subvert the change procedure.

On the other hand the change procedure must allow for emergencies, which is what ITIL does with 'Urgent Changes'. How that happens depends on the environment and the service involved: it might allow for the ICT provider to go ahead and make the change, and inform the customer retrospectively, or it might still require approval from the CAB irrespective of the threat to the service.

I totally agree that most SLA/SLDs are poorly written, but that does not change their importance to the change process. Not only should they set parameters for changes to be processed, they also should define the benchmarks by which the performance of the service and service provider are measured. Otherwise how do you know you are getting what you pay for?

I know many organisations, espcially those that provide their ICT solutions in-house, do not bother with internal SLAs to their own customers (i.e. the business) but this is poor practice. Worse, it normally ends up slowing down the change process as the CAB must do a lot of extra work determining information such as cost, impact etc. Information that should be in the SLA/SLD.

Indeed there is a strong argument for the CAB having a predefined set of criteria that a service must meet before it is accepted as a service. This should include SLA/SLDs with a minimum set of required parameters such as cost, lead time, maintenance windows etc.

Of course this does not always work in some situations, but the CAB can always impose SLA values on 'services' that do not have them. It is then up to the service provider to agree these, or provide their own values.

The usual argument against this is that the organisation wants to be 'lean, mean, flexible and responsive'. But what that often means is that the organisation operates in perpetual crisis mode, and is particularly vulnerable to key staff leaving or being absent for whatever reason.

>As to costing etc, that is usually handled with a company through
>cross charging or budget codes of the staff's hours.

That is very dependant on the environment. I work mainly with large corporates where many services are outsourced, and generally have known prices. Internal cross charging is frequent of course, but particlarly when the company is a multi-national, it is not always possible, or even legal. Cross-charging can become cross-subsidation which goes against competition laws in many countries.

It still think it is better to create SLAs and fix costs as far as possible.

I agree it is not always possible to have a known cost for a service, particularly when it involves development. But this is why (IMO) it is usually better to separate service development from routine change management - but that also of course is dependant on the type of change, and the environment.

I do feel this is one of the areas where ITIL can be confusing - in many organisations changes due to service development and routine changes to existing services (moves/adds/deletes) are handled differently, which I personally think this is correct.

>I dont think a change request should be held up because of
>penny pinching.

I'm not sure what you mean about holding up a change request due to penny pinching. A change request follows a set process where the costs are evaluated as part of that process, and cost is then a factor in whether the change is authorised or not. The only way cost should hold up the process is when it is not known - and having well defined SLAs will help prevent that situation.

Hmm, another hour of theoretically productive work gone;-) Still, it is great to have this forum and I wish there had been something similiar around years ago!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management 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 http://www.nukecops.com

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.