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
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.
[quote]Incident Management/Service Desk can raise a problem, to be reviewed by the Problem Coordinator, but they do not decide that it IS a problem.quote]
I realize some of this is basic information, but there are so many variations with organizations that it's sometimes hard to see the foundation. However, your response was exactly what I was looking for. Thank you!!
Last edited by dchell on Fri Feb 20, 2009 5:35 am; edited 1 time in total
My recommendation is that you don't answer the question if you are to say condensing remarks. I don't breath ITIL everyday - and I did my research - it has nothing to do with laziness.
I simply ignored your response and saw that someone understood what I was saying and answered my question.
I hope you can provide valuable input in the future.
Regards.
Joined: Sep 16, 2006 Posts: 3118 Location: London, UK
Posted: Fri Feb 20, 2009 6:42 am Post subject:
Dchell
From your post - as I read it... you did not. Assume on my part... and my ears are showing. You are right I should not have shot off like that but...
and I will post if I want.. reading my post is optional
Now to trying to answer your question
From a theory point of view (ITIL book v2 or v3), the incident management process handles all incidents by trying to restore service
and the problem mgmt process does not care about the service being restored (not my department syndrome) but merely trying to find out what is the root cause
commentary on above
Sometime during the IM process, the engineer will see ... well duh.. the damn machine did.... so I reboot / restart to restore service.
Incident closed ...
Where IM & PM compliment each other is as follows... I know I posted this before in here
IM (good IM and statistical analysis) finds that a particular type of incident happens during the 3rd week of every month - affecting say 20 different servers with the same issue (incident details). The outages are short as the IM resolution is to do ..... to restore service can be done rather qucikly after a short IM troubleshooting
Now PM (reactive) process is flagged by IM. NOTE: IM recommends a set of incidents for PM (reactive) process. It is UP to PM mgmt team to determine whether the issue warrants the time / resources etc dedicated to it in the face of other PM (reactive) items that are being done
So IM makes recommendations to PM but does not really make problem records....(pedantic .. but see my quote in CM process - New to CM)
PM then will either create / initiate PM (reactive) process or decide it aint worth the time / effort for several reason - time / resources / technology / life cycle of the said system and obsolesence factors.
Now.. .this pre supposed that the IM & PM processes are well defined, documented etc ie.. ITIL Best practices.
---End of part 01 _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Sep 16, 2006 Posts: 3118 Location: London, UK
Posted: Fri Feb 20, 2009 6:45 am Post subject:
And finally
reality as I have seen it
PM is usually mixed in IM escalation - from both an troubleshooting and analysis factor and not treated separately and then the lines of IM & PM get blurred really really quick
too little time is dedicated to researching root cause in some respect and testing theories etc
some times this is due to how the support is allocated - third parties / // out sourcing
and I am glad you came back... _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
In our environment (university with fresh ITIL V2 implementation, part time PM only), we set up a home-rolled Problem/KE database with a publicly visible frontend that lets "approved" staff submit what we call Problem Candidates.
Approved staff are: all ITIL (IM, SDM, PM, SLM, CM/Config in our case) managers plus our network gurus.
This way, we catch a lot of stuff. PM alone would not be able to catch all possible things doing the job part-time.
PM reviews the candidates daily, gets more BG info where necessary and then decides which ones to accept or reject. Then, PM decides prio + a queue order, and creates problem tickets in the Service desk tool > RCA etc
The current status of any Problem Candidate as it travels to be a KE or RFC is clearly visible thru this web frontend, so the originator knows where things are. Also, Service Desk sees if an incident can be matched to an existing Problem.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Fri Apr 03, 2009 4:07 am Post subject:
Bluesman wrote:
The current status of any Problem Candidate as it travels to be a KE or RFC is clearly visible thru this web frontend
Richard,
I realize you understand this, but when I'm in a pedantic mood, I use the excuse that some less experienced may not.
When you said "to be a KE...." you really meant something like "to generate a KE...."
At least I hope you did. _________________ "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
Well, I´m not a native English speaker. I just tried to show an example from real life and a newborn ITIL implementation. I believe the OP was looking for practice, not theory.
"Generate", of course, is better. Thanks for the correction.
Joined: Jul 24, 2009 Posts: 23 Location: Sydney, Australia
Posted: Wed Jul 29, 2009 1:38 pm Post subject:
DCHELL - Did you end up putting a process in place to deal with this issue ?
I have implemented a simple form that I give to anyone who requests a problem record to be created to assist me in collecting relevant information from the outset and minimise the time in having to go back and forth to get this information and to assist in the approval process. The form asks he following questions :
- Please provide a Summary of this Problem in your own words
- How long has this problem existed ?
- How did you become aware of it ?
- What criteria has been met for this to be defined as a Problem ?
Please choose one :
When a P2/UH Incident is recorded
Monitoring events that might lead to a future Incident (e.g. disk space warning, low bandwidth)
Workaround or temporary fix is not available
Repeat Incidents
Unsustainable workaround (e.g. end user not satisfied with the workaround)
Incidents caused by changes or releases
- Please list all the related Incident Records and/or RFCS that are
related to this Problem
- Do you know of any current workarounds that exist for this Problem
today ?
- What is the impact of this problem today ? (How many people are
effected by it that you are aware of and where are they located ?)
- Who shall be the stakeholder and/or contact person for this Problem ?
- What is the best contact number for this Contact ?
I have found that since this process has been implemented, it has really helped me quite a bit in determining whether a problem record should be logged and kicking things off in the right direction.
I hope this helps _________________ ITIL V3 Capability - Operational Support & Analysis Certified
All times are GMT + 10 Hours Goto page Previous1, 2
Page 2 of 2
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
