I am yet to see any convincing explanation on why ITIL V3 has done away with the concepts of ‘Problem Control’ and ‘Error Control’ – the two parts of the Problem management process that used to be there in V2.
-
If this was not required/ if that is not a best (good) practice, why was that in V2?( I believe there is a value in subdividing the process into those two stages, which I will explain in a short while)
-
Was it, in any way causing any sort of issues in implementing and following Problem management?
-
Is there a real value in making Problem management one consolidate process flow, as it is in V3? (In other words, is this a better practice, compared to the concept of having Problem and Error Control?)
Why are we concerned with this removal?
I used to find the earlier concept of Problem and Error Control a very logical one. Here are some of my arguments in support of such a subdivision into two stages:
-
When the organization is starting with some thing ‘unknown’ (problem), there might be an obvious need (in most cases) for cross-functional teams to analyze the same and arrive at a root cause. (You never really know if the cause is hardware, software, network, environmental, human errors or anything else). So Problem control can involve such a team/group. Once the root cause is identified, the domain of the cause is narrowed into – hence the specialists in that domain can work on resolving that cause permanently using Error Control.
-
As even ITIL V3 points out, there might not be a business case for Problem resolution in many cases (for example, where the cost of problem resolution is not justified) – but it is important to diagnose the cause and create a known error. This would mean (if we follow the two-staged approach)- Problem control is completed, and Error control is not taken up. In other words, the objective of Problem management looked very logically in two parts: “Diagnose the problem to the root cause” (Problem control) and then if there is a business case, “resolve the same permanently” (error control).
-
If the Known errors are diagnosed/made available by other processes – may be from Development, from the vendor, Incident management etc- , it is a good practice to document those into the known error database. As per the two-staged approach, Problem management could have just initiated ‘Error Control’ activities, to permanently resolve that known error. Does the current flow indicate that problem management has to again do the diagnosis, if that error need to be resolved? Or can it trigger the solution (not clear!).
One of the reason that might have triggered this change in V3 could be, the new idea that ‘ in some cases, it might be advantageous to raise a known error even before the whole diagnosis is over’.
I am not able to get any other valid reason for this change – and would really welcome any inputs in this regard…
August 12, 2010 at 1:00 am
Completley agree, I think it was just an mistake.
August 12, 2010 at 8:12 pm
In ITIL V3 there is recognition that Problem Management is a lifecycle. Moving from Problem to Known Error is in reality simply a state change in the same lifecycle: Problem- cause is unknown and work around not yet determined, Known Error- cause known and/or work around or solution determined.
V2 depicted these two activities as separate lifecycles using separate databases. V3 points out that all this data should go into one database, the KEDB, and that problems for which an error is already known (e.g. bug in software) and work around is established, they should be classified immediately as a Known Error with the corresponding work around documented.
I see the V3 depiction of Problem Management refreshing and accurate, representing the Problem and KE components of the process as one fluid work flow.
You will see some minor updates however to this process to fix some errors in the V3 book printing for Problem Management when the ITIL V3 update (3.1?) is released in the coming months.
August 12, 2010 at 10:02 pm
Hi Ted,
Thanks for the note. I don’t really agree with the view that V3 is depicting ‘everything goes into one data base’. There will definitely a problem database/system (where problem tickets will be logged)- and a known error database. I can’t recollect V3 specifically saying that even Problems will be logged into KEDB – with just a status change to show as Known error. Practically this can be done (though I prefer the other way around : Known errors as a status change in Problem Records/tickets)- But this was the case in V2 as well.
Problem control and Error control were just the way of seggregating the ‘activities’ of Problem management – and not really seggregating data/records.
September 9, 2010 at 3:33 am
Hi Vinod,
If the business finds value in having two separate databases, then this is certainly the way to go.
There is no reference that I have found in V3 to anything other than a KEDB. Note section 4.4.7, “Information Management.”
The follow V3 excerpt communicates how problems are entered to the KEDB (see end of paragraph).
“Care should be taken to avoid duplication of records (Le.
the same problem described in two or more ways as
separate records). To avoid this, the Problem Manager
should be the only person able to enter a new record.
Other support groups should be allowed, indeed
encouraged, to propose new records, but these should be
vetted by the Problem Manager before entry to the KEDB.”
I hope this helps.
September 7, 2010 at 11:09 pm
I’d have to agree with Ted. It’s the same process, just different stopping points. Thus, make it one complete process vs. two separate. The two separate implies that you could start with one vs. the other or not at all. They tried to streamline the process and make it cleaner. Now whether or not it was done well or better, that’s another question 🙂
September 8, 2010 at 3:18 pm
V2 PM has two phases, problem control and error control, not two separate processes. When a problem has been solved, i.e. we know what has caused the incidents, we need to decide if it is worth fixing. This is the error control phase.
Problems and errors are logged in CMDB.
I suggest that you take a good look at the problem management process flow picture in the V3 book. It is silly, here are three examples of it’s silliness:
1) Proactive problem mgmt is an input, but does not exist
2) Workaround decision point has only one exit i.e. there must be a workaround.
3)In resolution you either close it or go back to investigation and diagnosis (there is an important decision point missing). What happens if the rfc was not accepted.
What does it mean that “Change is not needed” and you pass directly to resolution.
September 9, 2010 at 3:40 am
Agree. The diagram is at least one area in Problem Management I’ve been told is being addressed by the forthcoming ITIL V3 update.
June 4, 2011 at 1:08 am
From my experience, problems have typically been called problems anyway, regardless of their status. It just makes everyone’s life a bit easier to deal with one less term in their dictionary. I am a fan of simplicity as long as the job gets done properly.
June 4, 2011 at 4:18 pm
I am a big fan of simplicity too. But not at the cost of losing clarity and flexibility. If adding new terms give it much more clarity and flexibility in terms of process, I dont mind two!:-) And, simplifying things by removing terminologies doesnt seems to be a consistent approach in ITIL V3 anyway…there many more processes and terms that are introduced…
March 5, 2013 at 11:03 pm
Hi Vinod,
Interesting article. I have a confusion in ITIL V3 Problem management process as well. We are in a middle of adopting our processes to ITIL V3 and I was trying to understand should we allow to create Know error records without creating a Problem record? And should it be any different in live environment and development environment. I didnt get much clarity reading through ITIL V3. Please advise.
March 7, 2013 at 3:47 pm
Ashwini,
Known error can be created without a problem record (but should ideally be controlled/governed through the problem management process who controls the KEDB). This is how you can record the known errors input from design/development/testing etc or even documented and provided by other parties like suppliers. Don’t remember about V3 exactly now, but ITIL 2011 clearly has pointers to this (for example section: “4.4.4.4 Errors detected in the development environment” in the Service Operation book).
I don’t see this aspect being any different based on the environment. Any errors identified in the development environment or testing environment will ultimately have an impact in the live environment, once deployed.
Hope this answers your question…
-Vinod
December 31, 2013 at 8:05 am
Excellent blog you have got here.. It’s hard to find quality writing like yours these
days. I seriously appreciate individuals like you! Take care!!
April 15, 2014 at 4:47 pm
Greetings from Colorado! I’m bored at work so I decided to check out your site on my iphone during lunch
break. I love the knowledge you provide here and can’t wait to take a
look when I get home. I’m surprised at how fast your blog loaded on my mobile ..
I’m not even using WIFI, just 3G .. Anyhow, superb blog!
April 27, 2017 at 11:48 pm
If some one wishes expert view regarding running a blog afterward i propose him/her to pay a quick visit this webpage, Keep up the pleasant
job.
May 11, 2017 at 7:43 pm
Hi, I think your website might be having browser compatibility issues.
When I look at your blog in Ie, it looks fine
but when opening in Internet Explorer, it has some overlapping.
I just wanted to give you a quick heads up! Other then that, wonderful blog!
June 26, 2017 at 12:45 pm
It has actually been one of the best articles i have read. It was actually very informative.Looking ahead for more blogs of this particular in near coming future
June 26, 2017 at 12:45 pm
This has been really one of the top articles i have read. It was very informative.Looking forward for a lot more blogs of this particular in near coming future
June 26, 2017 at 12:45 pm
It has been one of the top blogs i have checked out. It was actually very informative.Looking forward for more blogs of this in near coming future
July 17, 2017 at 4:53 pm
Really good info can be found on web blog.
July 25, 2017 at 6:33 am
You completed certain nice points there. I did a search on the subject and found nearly all persons will go along with with your blog.
June 19, 2021 at 1:47 pm
To use the word genius with Iblis and Asmoday is brief altering these two “enzymes”. I am going to outline just a couple of simple methods that you can do today, to make her skip you, alright?