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: JLorenzo
New Today: 67
New Yesterday: 89
Overall: 139485

People Online:
Visitors: 75
Members: 4
Total: 79 .

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

Keeping Focus

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


Joined: Dec 29, 2008
Posts: 5
Location: Midlands UK

PostPosted: Thu Jan 08, 2009 7:06 am    Post subject: Keeping Focus Reply with quote

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
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Jan 13, 2009 6:53 pm    Post subject: Reply with quote

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
View user's profile
JohnKing
Newbie
Newbie


Joined: Dec 29, 2008
Posts: 5
Location: Midlands UK

PostPosted: Tue Jan 13, 2009 9:24 pm    Post subject: Reply with quote

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
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Jan 13, 2009 9:34 pm    Post subject: Reply with quote

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
View user's profile
BorisBear
Senior Itiler


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

PostPosted: Tue Jan 13, 2009 10:33 pm    Post subject: Reply with quote

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
View user's profile
JohnKing
Newbie
Newbie


Joined: Dec 29, 2008
Posts: 5
Location: Midlands UK

PostPosted: Wed Jan 14, 2009 10:55 pm    Post subject: Reply with quote

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 Smile

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
View user's profile
BorisBear
Senior Itiler


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

PostPosted: Fri Jan 16, 2009 4:46 am    Post subject: Reply with quote

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 Smile

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
View user's profile
RT
Itiler


Joined: Jan 26, 2009
Posts: 26

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

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
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Jan 27, 2009 12:32 am    Post subject: Reply with quote

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
View user's profile
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Wed Feb 04, 2009 2:29 am    Post subject: Re: Keeping Focus Reply with quote

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
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem 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.