View previous topic :: View next topic |
Author |
Message |
JohnKing Newbie


Joined: Dec 29, 2008 Posts: 5 Location: Midlands UK
|
Posted: Thu Jan 08, 2009 7:06 am Post subject: Keeping Focus |
|
|
Hi
First post in the forum. Having been reading for the last week or so and some really good stuff on here.
I am after some advice with the following issue. Currently using our service desk we will create a problem reference which will keep the history of the problem and any incident references. However with the service desk and site analysts that will resolve and see the problems they wont add new incidents to the problem at closure.
This means that when the monthly analysis is done by the Problem Managment team (me) its a case of trawl back through the incidents for the period to assign them to the master problem.
We are looking to improve the focus of other members of our wider team on problem managment and there part in the next year. However im looking for some tips on how I can keep focus of the problems that they have initaly raised. |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
|
Posted: Tue Jan 13, 2009 6:53 pm Post subject: |
|
|
WARNING
Mixing problem mgmt and incident mgmt it seems
incident - any activity that is NOT part of the normal service
problem - an unknown unlying root cause of one or more incidents where the root cause needs to find
the purpose of incident mgmt is to return the service to what it should be
the purpose of problem mgmt is to find out why the incidents were happening and what the solution is
2 different paths
are you talking about problem mgmt - where some incidents may be recommended as candidates to have problem records records or incident gmmt undert he guise of problem mgmt _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
JohnKing Newbie


Joined: Dec 29, 2008 Posts: 5 Location: Midlands UK
|
Posted: Tue Jan 13, 2009 9:24 pm Post subject: |
|
|
Thanks for replying.
Let me give you an example of the scenario that Im thinking about. The business is expering an issue with email. The individual incidents are resolved and we have a solution for the problem.
However for us to give it a priority for problem managment and push forward a proper solution we need to understand the impact and number of incidents its generating. We would have a master problem for the issue and would look for the analysts when they resolve the incident to close the incident against the problem.
This way we can open the problem and see that YZ Calls ahve been raised against the problem and help strenghten the case for resolution. |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
|
Posted: Tue Jan 13, 2009 9:34 pm Post subject: |
|
|
John King
First,
what were the incidents -
spam ?
network failure
system failure
space for mail
some have symptoms for the individual(s) but are actually service issues
What was the solution to the incidents......?
what was the critieria for making the incidents a candidate for a problem
if you know the root cause of the incidents, you really dont have a candidate for a problem - under reactive problem mgmt
If the underlying root cause is that the architecture for the mail system is too small, not robust enough, then this is more of a service delivery issue than a service support issue
This should be handled by the people that provide the service not the team that supports the service- misuse of manpower/resources, time etc _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
BorisBear Senior Itiler

Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
|
Posted: Tue Jan 13, 2009 10:33 pm Post subject: |
|
|
Problems? Master Problems? It all sounds like you are getting very confused.
I think what you are saying (maybe not in these specific words) is that you have separate records for Incidents, Problems and Known Errors.
You resolve the Incidents by getting things up and running and raise a Problem record to investigate underlying cause.
You resolve the Problem by finding underlying cause, possibly a workaround and a clear path to a permanent resolution - you raise a Known Error record to take forward this clear path to permanent resolution.
Using your logic (I think) you need to prioritise fixes for Known Error - am I thinking along the right lines? To do this you need to establish impact by looking at how many incidents have been raised that would relate to this Known Error. However because resolving groups only link incidents to open problems and in this case the problem has been closed in favour of a known error you are finding that the technical groups are not linking the incidents to the closed problems which makes your life harder.
Is this more or less what you are talking about?
If so there are a number of simple answers - leave the problem record open, link incidents to known error records, etc.
There is nothing insurmountable in my humble opinion, its just all about how you execute the process. Alternatively give a slap to anyone who doesn't link the incidents correctly. |
|
Back to top |
|
 |
JohnKing Newbie


Joined: Dec 29, 2008 Posts: 5 Location: Midlands UK
|
Posted: Wed Jan 14, 2009 10:55 pm Post subject: |
|
|
BorisBear you explained it much better than me. Thanks for the response.
I like the slap idea however there seems to be some rules against beatings in the work place
I think my confusion comes from the fact that we try to link everything in with our service desk software and rather than follow process we tend to follow the work flow of the software.
Its given me some area's for thought thanks for your help |
|
Back to top |
|
 |
BorisBear Senior Itiler

Joined: Mar 10, 2008 Posts: 403 Location: Sunderland
|
Posted: Fri Jan 16, 2009 4:46 am Post subject: |
|
|
JohnKing wrote: | BorisBear you explained it much better than me. Thanks for the response.
I like the slap idea however there seems to be some rules against beatings in the work place
I think my confusion comes from the fact that we try to link everything in with our service desk software and rather than follow process we tend to follow the work flow of the software.
Its given me some area's for thought thanks for your help |
Ah, the old Service Desk Software chestnut. Its not uncommon for organisations to allow the software to determine their processes.
For what its worth if you are operating with distinct records for Known Errors I would encourage the linking of new occurrences to the Known Errors. The reason for this is it encourages Service Desk staff and the technical groups to refer often to the Known Errors and possibly speeds up diagnosis. When I have worked in Problem Management I have set up Known Error Logs and made it part of Service Desk process that when they take a call from a user they check the log to see whether it is a pre-existing Known Error and advise the user of the appropriate work-around and planned fix date (if one is known). Indeed I have published Known Error Logs on the intranet to encourage some self service amongst users although to some extent this defeats your object of capturing all incidents to prioritise fixes.
If the software doesn't allow you to do all this then just leave the problem records open until you have a permanent fix, politics permitting (some IT Managers are particularly anal about the number of outstanding problem records that they have). |
|
Back to top |
|
 |
RT Itiler

Joined: Jan 26, 2009 Posts: 26
|
Posted: Tue Jan 27, 2009 12:12 am Post subject: |
|
|
Does the software actually prevent you from linking incidents to closed problem records? If not, could you just retrain the service desk to link to the closed problems? |
|
Back to top |
|
 |
UKVIKING Senior Itiler

Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
|
Posted: Tue Jan 27, 2009 12:32 am Post subject: |
|
|
Tools should follow the process.
Not the other way round. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter |
|
Back to top |
|
 |
JoePearson Senior Itiler

Joined: Oct 13, 2006 Posts: 116 Location: South Africa
|
Posted: Wed Feb 04, 2009 2:29 am Post subject: Re: Keeping Focus |
|
|
JohnKing wrote: | Currently using our service desk we will create a problem reference which will keep the history of the problem and any incident references. However with the service desk and site analysts that will resolve and see the problems they wont add new incidents to the problem at closure. |
One thought: you may benefit from more work being done (by the service desk and site analysts, if they are 2nd-line support or similar) in incident matching. This process activity, described rather thinly in the ITIL books (shown in Incident Mgt, referenced in Problem Mgt, but not really defined), is where the incoming Incident is matched against Known Errors.
This imposes some burden on the people logging and maintaining Known Error record (aka possibly Problem record with Known Error status) to make it easy for service desk staff to do the matching.
The point is that if a matching Known Error exists, it tells you the workaround, by definition.
Matching new Incidents to open Problems (which are not yet Known Errors) is less obviously useful to swift incident resolution, but you can make it part of the same activity and enforce it that way. From how I read your issue, that would help.
For certain, it's less efficient and less likely to be done well at month-end by problem mgt staff.
Makes sense? |
|
Back to top |
|
 |
|