Problem vs known error record in small organizations

[redbaret82]

I am currently implementing problem management for a small organization of 35 IT people. I think that I will not use the separate known error record, but use only 1 problem record instead that will be used as known error record as well. I would like to do this to limit the administration for our operators. What are your thoughts about that?

[Diarmid]

In this modern world of clever databases, I'm not sure what a record is any more.

The important points are whether you can access, for example, known errors (and all the information pertaining to them) easily when you need to, and whether you can manage the information system you set up reliably and without undue cost or risk.

When designing your record structures meet your requirements for the recording, viewing, updating, and analysing of information.

I would think that the complexity of the data and the processes will be more significant as a design constraint than the size of the organization. If there are less overheads doing it one way in a small organization, surely there will be the same less overheads in a large organization.
_________________
"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

[Bluesman]

I understand you want to eliminate to duplicate lots of information, which is a good thing. And yes, it´s mostly a design question. If it works for you, then it´s OK. There is no such thing as "bending the rules" in ITIL - it´s just a recommendation.

So...I´d say GO for it. You need a few cross refs and pointers (to old incidents, to Problem/RCA history etc) , and maybe some extra status flags to make things clearer.

Tip: we use the status term "Known Problem" (under investigation, no RCA and/or no real solution found yet) in addition to "Known Error" to make things more understandable for everyone.
It makes incident matching easier and keeps the pressure up on the PM process

Good luck. /Richard
_________________
---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

[Marcel]

Either way is fine as long as it suits your needs.

In a typical Problem Mgmt process you primarily care about the following things:

- what is the problem and what do we know about it?
- what is the status of the problem?
- who is on the hook to investigate and resolve the problem?
- what is the workaround/temporary fix that we can use pending permanent resolution?
- what is the exact root cause?
- what is the permanent corrective action, if any?
- when will it be fixed?
- how can we match and link incidents to the problem?

Whether you use separate Known Error records or just a Known Error status on a Problem record does not really matter much. There are pros and cons to both approaches. As long as you set up your process and system in support of the questions listed above you will do just fine.

In our large organization we use separate records for Problems and Known Errors. Not because we believe that to be the best solution, but because that is what our ITSM tool does. I know, the process should drive what the tool does, but if your strategy - like ours - is to minimize customizations of out-of-the-box software then you sometimes have to make the best of what the tool offers. Specific to our tool I find the use of separate records cumbersome (the 2 record types are for 95% the same) and without a clear advantage. As a result some people try to 'skip' one of the records and either go straight to a Known Error without first recording a Problem or will not log a Known Error once the root cause has been found. You certainly don't want a process that people try to get around because it does not make sense to them.
_________________
Manager of Problem Management
Fortune 100 Company
ITIL Certified