Keeping Focus

[JohnKing]

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.

[UKVIKING]

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

[JohnKing]

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.

[UKVIKING]

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

[BorisBear]

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.

[JohnKing]

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

[BorisBear]

[RT]

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?

[UKVIKING]

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

[JoePearson]