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: BrigetteX
New Today: 152
New Yesterday: 202
Overall: 130716

People Online:
Visitors: 52
Members: 2
Total: 54 .

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 - Justification for separating incidents&problems in tool
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Justification for separating incidents&problems in tool

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


Joined: Mar 26, 2012
Posts: 2

PostPosted: Tue Mar 27, 2012 1:33 am    Post subject: Justification for separating incidents&problems in tool Reply with quote

Greetings ITILings

I've recently undertaken a new role to introduce problem management into a small rapidly growing IT organisation. I'm a practising problem management practitioner with seven years experience in this area, but this is the first time I've encountered such an ITIL-y challenged environment (i.e. non-existent). I'm confident I can bring about the necessary culture change within the company, but the major challenge I am facing is with the call logging tool, which has no ITIL functionality whatsoever.

The tool is made by an American company, and they readily admit to having no knowledge or concept of ITIL. There are, however, apparently plans to implement a change management module, which sounded promising at first, but they have repeatedly queried the necessity of a problem management module when I request such similar functionality. The challenge I am facing is justifying why it is necessary for them to implement such features. The management in my organisation are set on using this tool, but as already mentioned, they have no experience with ITIL, let alone problem management. Whilst they are willing to learn and are looking to me to lead in this area, I am having difficulty coming up with convincing arguments with regards to why we need a separate incident and problem section in the tool. My reasoning so far has articulated the following justifications:

Governance - no control at present over who can open / close a 'problem' (i.e. incident) record in the tool.
Best practice would dictate problem records have different fields and field values to incident records (the tool company have suggested a 'workaround' of using a series of user defined fields to overcome this, but in my opinion this is not effective and does not provide adequate control / functionality).
Reporting - difficulty to provide granular reporting on different ticket types etc.

...and that's the best I've been able to come up with. It's a bit embarrassing and I'm sure I'm missing something really obvious...but having separate problem management functionality in a call logging tool seems so obvious and sensible to me I've never encountered a situation before where someone queries what value it will add. Iíve scoured the internet and these forums, and canít find a similar scenario recorded anywhere although I'm certain people must have encountered the same situation. Any assistance / suggestions welcome...
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Mar 27, 2012 6:01 am    Post subject: Reply with quote

Nehemia,

two things spring to mind.

Firstly, get away from the phrase and concept of "a separate incident and problem section". It just loses your ground. If they are offering incident management functionality accept that, but point out that they are not providing any problem management functionality. not only are the data requirements different, but, and even more so, the process flows are different between incident and problem management.

Secondly, try to sketch out the processes at this stage and then flesh in the steps you will need to take to extract for a two way flow of information between their incident management system and whatever problem management system you can devise.

To return to my first point, you compound the problem [sorry] by allowing their mis-perception of problem management space to breath. I suspect that their, probably unconscious, assumption is that problem management is an extension of incident management and that it consists of looking at it as merely a way of digging deeper into incidents with a view to prevention. This is plausible, but bad. To emphasise the point, if you had no incidents for a month, you still aught to be doing problem management every day.

Because, in the general run of things, most problem investigations emanate from the occurrence of incidents, many think that that is where it comes from but in reality problem management should be about looking to prevent incidents whether such have yet occurred or not.

Emphasise the parts of the process that are about mitigation and problem fixing and the way in which these have to be measured by non-occurrences. Emphasise the nature of value and cost in problem solutions, something that is rarely given more than a fleeting glance when resolving an incident because there is some urgency to restore service.

I'm toodling off now to watch telly.
_________________
"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
Back to top
View user's profile Send e-mail
abu1
Itiler


Joined: Oct 26, 2011
Posts: 30

PostPosted: Wed Mar 28, 2012 7:53 pm    Post subject: Reply with quote

I am in a similar position trying to establish a new problem process to be implimented in the company. the service desk software only had incident managment and the problems were recored and stored sepertaley. but now in the latest release they have inclded problem so we can work from them within the software rather than word documents..

It is still possible, hardest thing im finding is changing the culture of the people as they are used to doing it current way which involves no problem process at all.
Back to top
View user's profile
nehemiah
Newbie
Newbie


Joined: Mar 26, 2012
Posts: 2

PostPosted: Fri Mar 30, 2012 6:57 pm    Post subject: Reply with quote

Thanks for the feedback all.

abu1 - I definitely don't want to be using work documents :S

Diarmid - I worked through some process flows as per your suggestion and as a result identified some practical logistical issues that would be encountered when trying to squeeze a problem management process into the current tool functionality - so that's given me great ammo with which to go back to the supplier and whack them over the head with. Fingers crossed they'll take my comments on board!

Thanks again for your help - it's appreciated.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Sat Mar 31, 2012 9:23 am    Post subject: Reply with quote

nehemiah,

sounds promising.

They will probably try to offer some ingenious steps in their current product, but from your perspective workarounds(!) are not acceptable because you are giving examples and do not know how many more issues will surface when you go into detailed design.

I have known software companies who offered an incessant flow of workarounds for years and so the product was never satisfactory.
_________________
"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
Back to top
View user's profile Send e-mail
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.