Posted: Wed Apr 19, 2006 1:30 am Post subject: Relationships of Change Categories and Incident Categories
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.
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Wed Apr 19, 2006 5:20 pm Post subject:
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!
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Thu Apr 20, 2006 9:41 am Post subject:
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.
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.
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