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: TBromham
New Today: 35
New Yesterday: 60
Overall: 139585

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

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 - Relationships of Change Categories and Incident Categories
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Relationships of Change Categories and Incident Categories

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


Joined: Apr 18, 2006
Posts: 3
Location: Ohio

PostPosted: Wed Apr 19, 2006 1:30 am    Post subject: Relationships of Change Categories and Incident Categories Reply with quote

Hello all,

I've began an assignment with a company that wants to implement service management based upon ITIL but not necessarily ITIL methodology. And against my advice, they want to focus initially on Change Management rather than Incident Management (their primary pain point).

The issue I have is this; they want Change Categories defined in respect to Incident Categories that have not yet been defined. I've warned them that this is possible but they have to realize upfront that this means we have to accept the Categories will require updating once Incident is implemented (in roughly 3 months).

I'm looking for feedback regarding some broad-based Changed Categories given this situation. I'm trying to incorporate Impact and Risk assessment into Category definition but need a little external support for my subbestions:
- Category 1: Changes that will require a total system or environmental interruption of a Tier One application or Infrastructure component to implement.
- Category 2: Changes that will require a partial system or environmental interruption of a Tier One or total interruption of a Tier Two application or Infrastructure component.
Category 3: Changes that will require a partial system or environmental interruption of a Tier Two or total interruption of a Tier Three application or Infrastructure component.
- Category 4: Routine or Standard Changes that have previously successfully completed a Category 2 or 3 implementation and been approved as a Category 4 Change.

Again... I'm trying to keep a relationship with potential Incident Categorization. I'd appreciate any feedback.

Scott
Back to top
View user's profile
Ed
Senior Itiler


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

PostPosted: Wed Apr 19, 2006 5:20 pm    Post subject: Reply with quote

Scott

It seems to me you are being asked to re-invent the wheel

Your Cat 1 is my Basic Major
Your Cat 2 is my Basic Significant
Your Cat 3 is my Basic Minor
& Cat 4 is my Standard

As they are ITIL categories these will all fit with Incident - provided you understand that this is what they are, you can call them what you like.

I have to say that we implemented Change first - ok we had a help desk, but no contact between them and Change. Our reason was that our servers were collapsing because of cowboy implementations and no control.

It has worked beyond my wildest dreams and we now, some 4 years later, have a stable environment that actually works. Oh and the help desk has become a Service Desk and we are talking about implementation of all the rest of the processes!

I hope this gives you some comfort

Regards

Ed
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Thu Apr 20, 2006 2:45 am    Post subject: Reply with quote

Good Day,

Yes, we also use a generic "Severity" to decribe the change:

1 = Critical
2 = High
3 = Medium
4 = Low

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


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

PostPosted: Thu Apr 20, 2006 9:41 am    Post subject: Reply with quote

In the following I am 'reading between the lines' with respect to the company you are mentioning:

An interest in linking change and incident classification indicates a foucs on the break/fix activity of incident management. Particularly the ability to capture what 'broke' (and was fixed). Technically - that's the root casue of an incident and belongs to problem managment.

There isn't a 'logically' strong link between the classification of incidents and changes. Forcing one introduces subtle but significant risks that the incident management process will have its efficiency undermined. (Primarily by providing shonkey analytics)

Incidents and changes both have scope and priority - but as they occur in different contexts there is not an automatically commensurate scale for assessing and applying these. Not even 'impact' - a high impact incident could require immediate redmediation through a very low impact change. (Eg swapping a broken item with an identical one) That is, impact in incident management is the effect of the incident on the user community. The impact of a change is really its effect on the infrastructure and the capabilities of services - which then transaltes into user impact. Conversely, a change with a massive impact on the architecture of the infrastructre could be totally invisible from an service capability/end user point of view. Similar differences in the context apply to scope and priority.

So even where some of the attributes of a change or an incident appear to be identical they have quite different 'meanings'.

What is probably being sought in the company you are working for is the ability to link incidents and changes through: a) any CIs that are in error and updated to fix that error, c) the severity of any incidents and the priority and scope of changes required to remedy them, and (less likely) c) any CIs that were changed and then caused incident. In short, there is an interest in 'things' and 'what broken things cost'.

Common categorisation is a poor, and very blunt, tool for establishing those connections between incident and change records.

Rather your processses should capture audit information that shows clearly how incidents progress to changes (whether through problems, known errors,, and RFCs or not). Whether changes are causing incidents. How choices between possible changes can be supported by data about the impact incidents are having. And so on. And you should look at recording CI data against incidents where this is identified during resolution of a break-fix incident or in more formal problem management.

Remember most incidents will not be neatly CI 'defined' - acknowledge and accomodate the desire to track and identify 'faults' - but don't let that requirement shoe-horn your incident management processes into an abitrary information ontology.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
stortss1
Newbie
Newbie


Joined: Apr 18, 2006
Posts: 3
Location: Ohio

PostPosted: Thu Apr 20, 2006 11:11 am    Post subject: Thanks! Very helpful! Reply with quote

I appreciate the feedback. This is what I was looking for and puts it in the words that I couldn't express myself. I appreciate the help!
Back to top
View user's profile
bootwhile
Newbie
Newbie


Joined: Jun 11, 2007
Posts: 6

PostPosted: Tue Jun 12, 2007 4:38 pm    Post subject: Reply with quote

1 V Critical Critical changes have the greatest risk factor as well as the potential for major impact upon service level objectives. These changes nornnally require extensive planning, scheduling, activity coordination between mutliple support groups, and on occasion on extension to normal maintenance windows. Additionally, this risk of change is typically implemented in steps over an extend period of time whenever possible.
2 V Major Major changes typically have a medium risk factor and the potential for a significant impact upon service level objectives. These changes also require extensive planning, scheduling, activity coordination between mutliple support groups. Additionally, this risk of change is typically implemented in steps over an extend period of time whenever possible.
3 V Medium Medium changes have a lower risk factor and a potential for minimal impact upon service level objectives. These changes require through planning, scheduling and activity coordination between support groups.
4 V Minor Minor changes imply a NO risk factor, potentially have no impact upon service level objectives. Planning, scheduling and activity coordination between a group insures that this rick of change is installed successfully.
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.