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: DKrajewsk
New Today: 80
New Yesterday: 73
Overall: 143572

People Online:
Visitors: 70
Members: 1
Total: 71 .

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 - Parent-Child relationship
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Parent-Child relationship

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Wed Dec 31, 2008 10:32 pm    Post subject: Parent-Child relationship Reply with quote

I asked this question a couple of minutes ago but don't see it posted for some reason. Anyways, I'll give it another shot and am sure that I am not the first one asking this question. I know we tend to get nasty with silly questions but please be mindful that I have done a search for this question in the forum before actually putting it in black and white.

My question is about parent-child relationship. I understand its a relationship between two tickets. Need to underdstand whether its a relationship with a parent CI and a child CI or a parent multi-user incident and related incidents reported from the other users to gauge the workload. I'll put a scenario around around the questions.

a) SD gets a call that server X is crashed. The server X hosts applications A,B and C. The SD also gets calls for these applications being unavailable. The SD opens a parent ticket for the server X crash and opens three more tickets for A,B and C unavailability. The three tickets become the child tickets for the parent ticket for the server X.
b) SD gets a call that server X is crashed and it starts getting calls from numerous users on the issue. It opens one parent ticket and links all other user tickets with the parent ticket.

The first scenario is the one where the CI acts as a parent and the second scenario is the one where the first caller becomes the parent. Which is the right one as per your understanding.

Please scream, scratch and shout but please help.

Happy new year!

regards
Viv
Back to top
View user's profile Send e-mail
paulfixter
Itiler


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Thu Jan 01, 2009 12:52 am    Post subject: Reply with quote

Hi Viv,

If I've understood correctly, your example 1 is correct.

In our organisation we would create a Problem on our system. Does your system allow you to do this?

Remember the ITIL definition of a Problem - a major incident, or multiple calls with the same sypmtoms.

So basically I would create a Problem for the Server crash and link all incidents to it.

It doesn't matter whether a user called first or was the 10th person to report it, it's still an incident to link to your Problem record.

Therefore your Problem is the "parent" as you describe it, and the Incidents are the "children".

Also as regards your CMDB, you maye have CIs for the servers, the software and/or the availability. These CIs will (or should) be linked with relationships.
You can add the server/availability CIs to the Problem.
Any client machine names would be linked to the individual incidents.

No doubt other people will do it in different ways but this is how we would tackle it.

Hope this helps,
Cheers,
Paul
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Jan 01, 2009 1:08 am    Post subject: Reply with quote

viv, paul

what you have is an incident (not a problem ITIL Problem that is) which comes in multiple tickets

what usually happens is that all four tickets get tracked independently until some one lo and behold puts it together that the four tickets are interrelated

However, you still have four incidents

1 - server A is down
2 - app A is down
3 - app b is down
4 - app c is down

there is no guarentee that when server a service is restored - closing the incident ticket by restoring service (definition of ITIL incident - and incident mgmt); that the apps - A, B & C - may automaticaly be restored

the 3 applications may require action - stop / start / restart etc - in order to have the application's service restored/

therefore the other three tickets will still have to be handled.

When I ran a SD, I would sometimes - depending on the scale / issue open a tracking ticket in the system - to track all the related tickets,calls, emails etc as running notes for the most likely requried after action report
-----------------------

now to the other issue - incident / problem - from a pragmatic and ITIL approach

most people - even if you classify loosely senior mgmt as people - tend to say we have a problem - rather than say we have an incident

an incident in some people minds is when a toddler has an incident in the hallway - which has to be cleaned up-haha

A problem - ITIL - can NOT exist without 1 or more Incident (ITIL) that are used to as the basis for deciding on whether ITIL Problem mgmt is initiated

a problem - pragmatic - is what most tools use in phraseology instead of an incident

the prime difference twix incident and problem is as follows

incidents - service impacting ones - desire is to restore service asap
problem - is to find out why it is happening and service restoral is not part of the equation
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jan 01, 2009 3:17 am    Post subject: Reply with quote

UKVIKING wrote:
A problem - ITIL - can NOT exist without 1 or more Incident (ITIL) that are used to as the basis for deciding on whether ITIL Problem mgmt is initiated


Eh?

What about pro-active problem management?

Spotting situations that could/will lead to incidents.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jan 01, 2009 3:28 am    Post subject: Reply with quote

paulfixter wrote:
Remember the ITIL definition of a Problem ... multiple calls with the same sypmtoms.


No!

Not if they relate to the same event.

It is multiple occurrences that indicate a possible problem, not multiple calls.

If your server crashed because of a power failure you don't escalate to problem status just because 20 (or 120) people report the loss of service. You might if it happened twice in a week, or if the potential cost of a single crash was great.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
BorisBear
Senior Itiler


Joined: Mar 10, 2008
Posts: 403
Location: Sunderland

PostPosted: Fri Jan 02, 2009 9:55 pm    Post subject: Reply with quote

paulfixter wrote:



Remember the ITIL definition of a Problem - a major incident, or multiple calls with the same sypmtoms.

So basically I would create a Problem for the Server crash and link all incidents to it.

It doesn't matter whether a user called first or was the 10th person to report it, it's still an incident to link to your Problem record.

Therefore your Problem is the "parent" as you describe it, and the Incidents are the "children".


Paul



Commiserations - you have just failed your ITIL exam
Back to top
View user's profile
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Sun Jan 04, 2009 4:00 pm    Post subject: Parent-Child relationship Reply with quote

Happy new year to all Very Happy

I am glad that I was able to generate some heat on the topic knowing the fact that this is not the first time this question is posted in this forum.
I feel that I am fairly clear about ITIL Incident and Problem. A big problem of a server crash which affects thousands of users is actually an ITIL incident, though we can call it as a major incident but definitely not a problem till the time it repeats and the root cause is not defined and the fix (in form of a change or without it)is not implemented.
My question was essentially to understand if we should have a ' CI' based parent-child relationship or a 'User' based Parent-child relationship. 100% agreed with UKViking that the we should have four tickets and should not close the three related ones assuming that the applications are restored once the server is restored. However, can we still link/relate the three incidents to the one which pertains to the server which houses these three applications. The intention is to arrive at a reasonable impact analysis while performing a change on the boxes. The incidents of the subsequent callers can be logged as 'duplicate' tickets and aligned to the Child tickets. It looks like a 'tool' question however has some nuances on how the disciplines should ideally work. Thanks for your inputs.
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sun Jan 04, 2009 4:18 pm    Post subject: Re: Parent-Child relationship Reply with quote

viv121 wrote:
but definitely not a problem till the time it repeats and the root cause is not defined and the fix (in form of a change or without it)is not implemented.


Not strictly correct.

It is legitimate to raise a problem after a single incident if

a) the cause is unclear and the potential cost of a repeated incident is very high.
or
b) it is thought to be symptomatic of an underlying problem that could (already) have other adverse effects.

Don't forget that you do not need any incidents to set up a problem if analysis and observation suggest that something is threatening services. Unusual patterns of workload peaks, for example, could be worthy of investigation.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
paulfixter
Itiler


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Mon Jan 05, 2009 5:12 pm    Post subject: Reply with quote

BorisBear wrote:
paulfixter wrote:



Remember the ITIL definition of a Problem - a major incident, or multiple calls with the same sypmtoms.

So basically I would create a Problem for the Server crash and link all incidents to it.

It doesn't matter whether a user called first or was the 10th person to report it, it's still an incident to link to your Problem record.

Therefore your Problem is the "parent" as you describe it, and the Incidents are the "children".


Paul



Commiserations - you have just failed your ITIL exam


Really helpful comment - Cheers!
Back to top
View user's profile
paulfixter
Itiler


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Mon Jan 05, 2009 5:22 pm    Post subject: Reply with quote

Diarmid wrote:
paulfixter wrote:
Remember the ITIL definition of a Problem ... multiple calls with the same sypmtoms.


No!

Not if they relate to the same event.

It is multiple occurrences that indicate a possible problem, not multiple calls.

If your server crashed because of a power failure you don't escalate to problem status just because 20 (or 120) people report the loss of service. You might if it happened twice in a week, or if the potential cost of a single crash was great.


OK....but to quote page 96 of the blue book:

"A Problem is a condition often identified as a result of multiple incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident.....but for which the impact is significant".

So to take your example, if a server crashed because of a power failure, this is a single significant incident, therefore I would raise a Problem record.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Mon Jan 05, 2009 6:38 pm    Post subject: Reply with quote

Paul

The core part of a problem is an unknown underlying root cause...

If you know the server failed because of a power failure, then it does not meet the criteria for a problem record in addition to the incident record

however, if the data centre lost power due to a UPS and all servers died because of this, then this would be a major incident and handled via a major incident process - which should involve both incident and problem managers

BTW: BorisBear was pointing out that your understanding of a problem was faulty
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Dec 22, 2008
Posts: 36
Location: Wakefield, West Yorkshire, UK

PostPosted: Mon Jan 05, 2009 6:41 pm    Post subject: Reply with quote

UKVIKING wrote:
Paul

The core part of a problem is an unknown underlying root cause...

If you know the server failed because of a power failure, then it does not meet the criteria for a problem record in addition to the incident record

however, if the data centre lost power due to a UPS and all servers died because of this, then this would be a major incident and handled via a major incident process - which should involve both incident and problem managers

BTW: BorisBear was pointing out that your understanding of a problem was faulty


Thank you John, clarification much appreciated.

Ta, Paul
Back to top
View user's profile
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Mon Jan 05, 2009 11:50 pm    Post subject: Parent-Child relationship Reply with quote

I have always undserstood that we need to do a RCA for a ITIL 'problem' and if we know that we get multiple calls due to high cpu utilization or a UPS failure where lies the RCA and hence a known issue with a possible workaround generating multiple calls can't be termed as a problem but may be a major incident. I have always practised this and was interested in understanding that if we should have the Parent Incident for the server X and Child incidents for Apps A,B,C,D and E which are hosted on the server X. I agree that we should have sepatrate major incidents for the different applications but shouldn't they be linked with the original problem which essentially is a server incident. To cut the long story short, can we have the parent-child relation for incidents or is it essentially for the problems.
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Jan 06, 2009 12:34 am    Post subject: Reply with quote

viv121,

if you know the cause of high cpu utilization, then you have already done the RCA and, unless it was a one-off freak occurrence, you ought to have an ongoing problem for it. Same with UPS or anything else.



Regarding parent-child etc. there is too much detail in the question. The only answer is to determine what works effectively in your situation. I.e. you decide!

Whether you have parent-child relationships (or any other type of relationship) entirely depends on what will provide you with effective management of the incidents and problems. You do need rules, but they are not ITIL rules (obviously); they are your own.

You want to ensure that responses are timely and adequate (or better), and that things don't get missed, and that your management is not overburdened or over-complex.

The application of abstracted rules will ruin your services.


Any incident that is related to an outstanding problem is best linked to that problem.


The "original problem" is not a "server incident" because an incident is not a problem. If there is a problem it is the underlying cause of the incident and it has the potential to do more damage.


Keep the distinction between incident and problem simple: anything you call an incident, you work hard to restore service levels immediately; anything you call a problem, you work hard to discover the underlying cause of incidents (or potential incidents) and you then remove the threat.

Some of the reasons you have relationships between incidents and problems are:
1. to ensure that you know about the causes of all your incidents.
2. to document the continuing cost of unresolved problems.
3. to apply any follow-up actions to specific cases once the problem is resolved or the workaround is defined.
4. to be able to account to senior management. (e.g. via incident review and problem review activities)
5. to hold as data for service improvement actions.

Therefore it is not a good idea to dance about with the definitions or to build too much complexity into how you structure them.

An organization does not necessarily need a classification for "major" incidents (it may be able to effectively prioritise and resource and manage every incident on its merit).

Is your last question back to front? It is much easier to understand incidents begetting incidents, than problems begetting problems, since problems are essentially underlying situations that need rectified. work on a problem, may discover another problem, but is less likely to "own" it.

With incidents there is some practicality. E.g.:
1. reported incident - service A down
2. reported incident - service B down
3. reported incident - server down
Actual incident - server down.
However you need the knowledge that services are down so that you can manage their reloading in the context that they crashed (e.g. recovery actions). I.e. you may have to take more actions than just rebooting the server and there may be people to notify or involve in action.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk 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.