Join Mark Thomas for an in-depth discussion in this video Problem-management activities, part of Cert Prep: ITIL Foundations.
- So, Problem Management's few activities that, some of those might look familiar to you, cos it generally follows the same initial process that we have within Incident Management. So, the first step is to detect, detect that there is a problem there. So, little bit different from an incident. We may find, or detect problems through suppliers, we may detect problems through looking at or trending multiple recurring incidents, or we may detect because we had a major incident. Also we may detect, remember proactively versus reactively.
So, we need to detect that that's even there, first, so once we detect that, we then go log that ticket. We officially recognize this, it's given a number, and it's given the basic date time group, general information, to now accept that we have opened up a ticket for that. One of the things also that I see a lot of organizations, because Problem Management requires a lot of time, resources and effort, a lot of times those tickets are required in order to trigger the resource planning, or the resource allocation against certain problem tickets.
Cos you can imagine, with a big backlog of problem tickets, it's going to take a lot of your technical resources to be able to tackle a lot of these problems. So, we've got to log, then we go through the categorization. It's categorization similar to what we did in Incident Management, we had this categorization hierarchy or schema in which we used, I will give you a very, very good recommendation, I was in part of an organization where we created our categorization schema for incidents, we created a categorization schema for problems, this was done before I got there, when I asked to look at comparisons between problem tickets by category, and incidents by category, and what positive effects those problem tickets have had, I was told that the categorization schemas were completely different, so we didn't have an apples to apples comparison.
So I'll give you a little bit of advice, try to make sure that your categorization schemas match up as well as you could possibly get those, from a categorization. Next, prioritization, not much different, we look at urgency and impact within the prioritization. Again there may be service levels, customer requirements, around the prioritization and the timescales involved, around how we prioritize those. And then we go into the fun stuff here. The investigation and diagnosis. This is what I started to really look at over here, I just really called this Root Cause Analysis, okay? That's just kind of just an overall tag for that.
But in the investigation and diagnosis phase, you know the goal is to find root cause, and so, the CMS, Configuration Management System's very critical, very vital to using for the research. Other tools, other things that you can use include chronological analysis, right? Look at the time frame around when certain activities took place. Pain Value Analysis, another ITIL-endorsed problem root cause analysis methodology's called Kepner and Tregoe, you may also be doing brainstorming, Ishikawa diagrams or otherwise known as the fishbone diagrams, and also Pareto analysis, which is kind of based on the 80/20 rule.
So there's some techniques you might be able to use, here in investigation, in diagnosis. Okay, so we go through the investigation, diagnosis, and we think we have found that problem or we're very positive we found what the issue is, we can now create the known error record. Okay, so remember a known error, alright, we have to have a known error and a workaround that we store in that known error database. And what that does now is that allows us to have a record of what the error is, what workaround we can use, so the next time that incident shows back up, we can quickly close that, or we can quickly resolve that issue for our customers, okay.
Now, before we can kinda finish up with all this resolution stuff, couple things we have to think about. Remember, if it's a resolution that requires a change, we have to make sure we're looking at Change Release Management to ensure that we properly look at the risks, and make sure that we schedule those changes appropriately. Another thing to think about is, you know, from a financial standpoint, we might be able to give information on the financial aspect, or the cost of resolving, or preventing those future problem or incidents from coming back again, okay? So, we've got to create the known error record, we've got that information in there, on the resolution, it's either accepted as a workaround, or submitted as a permanent change, via change management, and then once we are convinced this thing has been deployed, this problem hopefully, if we're doing the process right, we have removed that problem from creating further incidents, we have a high degree, a high likelihood, or probability, that it's not coming back.
And it's within our financial means, we have the confidence that it's actually resolved the problem, okay. When we go into the closure piece, right, remember, kind of, some of the things we have to have in here. Once we get into closure, again, validate that what we have done is actually working, but if you have a major problem, that's determined by your organization, you should do something called a major problem review, okay, and that major problem review is an after-action review to help determine what happened, how can we do better next time, usually that's facilitated by the problem manager, so that's might be one of those things you might be required to look at as a part of that.
You may also want to look at what documentation needs to be updated in your SKMS, right, documentation like known error database documentation, any artifacts or any user guides, or any types of things that might help your operations team be able to handle those in the future, okay. One of the key things that I always like about this, is it's got this little things that says development known errors, you've probably looked at that and wondering, "What in the world is that all about?" Well, there are times, there are times when you are going through release and deployment activities where sometimes it is acceptable, because of time constraints, because of certain, some other things that you may have, to, I hate to say it this way, deploy minor errors as a part of a release, okay.
Sometimes it's unavoidable. If that's the case, if you have the proper approvals, and you're looking at it from that perspective, also, make sure they're documented in the known error database, because then you have workarounds, that come along with those, and then you may be able to fix those in future releases that come up at a later point. So those are some things that you might be, that you might consider as part of that known error database as well. So remember, known error database, owned and operated, by that problem management team, we wanna reduce the number of incidents, or the amount of pain we're gonna have, on those incidents that we cannot avoid.
Next video, we're gonna take a look at some of the interfaces that we have between the problem management process and other processes.
ITIL® is a registered trade mark of AXELOS Limited. This ITIL Foundations course is offered by Interface Technical Training, ATO of EXIN.