Keeping track of Problem records (for linking purposes)

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
jondw1970
Newbie
Newbie
Posts: 1
Joined: Mon Jul 09, 2012 8:00 pm

Tue Jul 10, 2012 11:48 am

Hi, I am a desktop manager for a medium/large/multi site company. Problem management is taking an increasing role in our effort to reduce incidents and we are being challenged to ensure dekstop techs link incidents to known problem records.

Quesiton I have that I hope for some help with is, with over 100 problem records accross the organsation, techs are often not realising that a problem record exists. We do have ability to 'search' for open records and they are all on a spreadsheet available on the intranet, but this seems a lengthy method to search/identify for every incident.

Our Serivce Desk software cannot suggest based on content so I was wondering if anyone had used any other methods to make techs (often based at remote sites also) aware of which problem records are current/closed/active to make it easier for them to link - we did think of putting up those more relevant/likely to be closed by desktop team on a large whiteboard, but again that seemed very clunky to manage.

Any suggestions or ideas would be appreciated, thanks


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Fri Jul 27, 2012 6:10 am

jondw1970,

I dare say I could invent a few tricks, but they would not necessarily be much good, and you have probably already thought of anything I could.

My best suggestion is to raise a problem. Put it on the radar. Describe the costs and risks associated with the current system. It is, after all, the problem manager's responsibility to see that the nature and status of outstanding problems is readily available to the appropriate functions. It is a problem. Get more minds focussed on it.
"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
User avatar
Boydness
Itiler
Itiler
Posts: 24
Joined: Thu Aug 02, 2012 8:00 pm

Fri Aug 03, 2012 1:30 pm

I am not sure if I fully understand the issue at hand.

Is the issue with just advising your incident handlers that problems exist that they should reference to possibly attribute new incidents to an existing problem?
Or is this excel related to problems, also containing your KEDB information (or where/how to find the KEDB entry for that problem) that they need to reference to determine the workaround to employ?

I had several sites that used excels to track the above, it was pretty difficult for them to maintain.

We employ a SharePoint, that serves many purposes. Primarily it tracks the problem external to the ticketing system (we have multiple), it is where we convert technical discussions into plain-speak for the non-technical stakeholders, and much more.
This allows for automated notification of updates to the problem case, keeping all parties up to date. Additionally, with a search function and the predefined views the information is very user friendly.
We have one very simple view that allows the titles of the problems to be sorted alphabetically, so by mandating a naming schema the first word of the title refers to the Application/Product/Service to which the problem applies followed by a concise description.

I would look at creating a SharePoint, that would provide you a centralized location to track and manage your problems, while affording on-site and off-site techs the same level of access. The use of notifications is handy for ensuring the appropriate group(s) receive a distribution of the information when that SharePoint entry is updated.


Boydness
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Sat Aug 11, 2012 6:36 am

Boydness wrote:I am not sure if I fully understand the issue at hand.
That's why I suggest raise a problem to analyse the issue. I doubt if they understand themselves at the moment what exactly is wrong (apart from the outcome).

They may have an adequate system, but the staff need guidance/training/discipline.
They may have an inadequate system and require to design something better.
SharePoint may be a candidate to provide a solution, but it may be disproportionately expensive, or there may be simpler/better/cheaper solutions.

By managing the issue as a problem, it is easier to perform proper analysis before focussing on a solution as all the relevant parties can be involved properly.
"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
Post Reply