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: KBraund
New Today: 9
New Yesterday: 72
Overall: 139699

People Online:
Visitors: 67
Members: 1
Total: 68 .

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 process causing Incidents to go out of SLA
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change Management process causing Incidents to go out of SLA

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


Joined: Apr 03, 2008
Posts: 5

PostPosted: Thu Apr 03, 2008 8:01 pm    Post subject: Change Management process causing Incidents to go out of SLA Reply with quote

This is probably a bit specific, but i'm wondering if anyone else here has had to deal with a situation similar to this. Or, even better, someone has published a process.

The Service Management tool we use has a very strict SLA clock on Incidents. The package we have does not include ITIL Change Management, so this process is modelled outside the Service Management tool.

The issue I have is that this week we had an Incident which was logged with a 5 day SLA. Turned out that the 3rd party supplier of the application at fault needed to develop a patch to fix a simple report saving error. This was submitted on an RFC after the patch was identified, but Impact Analysis dictated that this needed to go to CAB as it involved downtime across the business. Only problem is that the next CAB was being held outside the SLA for the Incident resolution.

This was in no way an Emergency Change because it was only a fault with saving a single report on an otherwise perfectly functioning service. In this instance I have advised that the Incident is going to have to go out of SLA and they will attribute it to the Change Management process.

Thoughts?
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Thu Apr 03, 2008 8:17 pm    Post subject: Reply with quote

Hi Pete,

The problem is fairly common. It's not your processes that are the issue here, it's the SLA.

SLAs need to be realistic and one of the golden things you learn with ITIL is that you need to take into account 'underpinning contacts' and OLAs before you can set the overall SLA. In otherwords you're kinda at the mercy of your supply SLAs when setting your internat IT 2 B SLAs.

Let's not forget some basics about SLAs, which I don't doubt you already know, but it's good to give context:

If you're 100% within an SLA then it's too easy, maybe it is perfect, but unlikely. So it's easy for complacency to set in an performance to dip.

If you're only hitting 50% then maybe it's too unrealistic, you get beaten up continuously and performance probably gets worse for it.

So whoever in your organisation agrees and sets SLAs needs to be pragmatic and cut their cloth to suit.

So interpret your example to mean that you need a specific, separate SLA for the scenario (and other similar ones) you've described, or you go back and renegotiate your third part SLAs though that's often a slow and painful process. In fact they might just not be able to offer you a better service anyway...

Now you've just got to get the customer/management to accept that reality.
Hope that helps a little,

Urgent
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
peted
Newbie
Newbie


Joined: Apr 03, 2008
Posts: 5

PostPosted: Thu Apr 03, 2008 8:57 pm    Post subject: Reply with quote

That is reasuring, thank you. I've recently joined an organisation which seems to be trying to shake off a VERY reactive culture. Allowing an Incident to go out of SLA is seen as a mark against an individual. They are used to being able to tweak and change the infrastructure unregulated to get jobs done.

I am impressed at how the majority of people here have embrassed Change Management, but there are still some old practices which have trouble sitting nicely with ITIL.
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Thu Apr 03, 2008 11:57 pm    Post subject: Reply with quote

Hi,

you clould take another approach. Let is go out of SLA ...but have it clearly stated in the SLA and your CM process that any Incident that requries a change froma 3rd party and CAB approval will be removed from the SLA count if it goes out of SLA.

You should not be blowing an SLA becuase of another processes basic requirement - i.e. CAB review / approval and lead times.

Define it clearly and be able to identify the incidents so you can later remove them from the count.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
peted
Newbie
Newbie


Joined: Apr 03, 2008
Posts: 5

PostPosted: Fri Apr 04, 2008 1:22 am    Post subject: Reply with quote

Yes, whenever Incidents overrun their SLA you have to put a 'reason' code in there. I've asked that the back office teams start using 'Change Management' as the reason so these can be tracked. Senior Managers of these teams seemed to be more than happy to do this as previously these 'reason' codes have been used as an indicator to show Head Of level where processes are broken or individuals/suppliers who are holding the organisation back.

I'm hoping that I can use this indicator to either remove those Incidents from SLM, or address the issue that the Service Level is not set practically to start with.
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Fri Apr 04, 2008 2:14 am    Post subject: Reply with quote

Thats spot on.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
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.