Definition of Major Problem

[plietzen]

Hi,

does any of you have a clear definition of when a problem becomes a major problem ?

Best regards
Peter

[mcardinal]

Because ITIL is a framework, you will have a hard time finding a clear definition in the literature.

Your best bet is to work closely with your customers and the business to have them help you determine what they consider a major problem. Once determined, it might be wise to record that in the SLAs so that everyone is on the same page.

Our definition is basically something that stops our ability to generate revenue. If we cannot sell insurance and financial products, we are dead in the water.

Hope this helps.

Michael

[nuker]

Exactly. It allways depends on the "business needs".
_________________
gruss nuker

[rjp]

ITIL doesn't provide a formula for classifying problems as major or minor.

It may help, however, to think about what such a classification ensures: appropriate and timely attention to problems that have a negative impact on the business. That is, it is to ascertain which identified problem gets priority.

You have two ways to go depending on your scale and setup. Both of the approaches listed below should be a part of problem management, but there is some scope for deciding where the emphasis is going to be:

1) Formal definition and process based classification.

2) Skill and knowledge based judgement call.

The key factors as the others stated is the impact to the business.

A formal approach (1) will use:

The CMDB - to analyze service impact and dependencies (how many services are affected, which ones, how severely, what are the at risk services in the problem worsens.)

SLAs - to identify services (and the components in the infrastructure) that are considered mission critical.

In addition the forward schedule of changes may come into play - are scheduled changes, or the next release, at risk of being delayed until the problem is rectified.

A set of impact and urgency metrics (no of business units impacted, nature of impact - slowed, halted, at risk etc), would be calculated objectively and combined with arbitrary rules (any problem impacting the accounts receivable system is automatically deemed to be 'major'.

This requires clear and well developed processes, and a fair level of maturity in Service Level Management and Configuration Management.

NB: The formal approach is often problematic because the most common sequence for implementing ITIL is Service Desk / Incident Management then Problem and Change management - with Service Level and Configuration Management bringing up the rear.

So often about the time folk are seeking a formal mechanism for classifying incidents into major and minor, there often is insufficient supporting information and workflow to do so.

Which leaves the skills based approach (2) - Make it someone's job (initially) - ideally someone who is recognized as the 'Problem Manager', but otherwise, someone who understands the business and the infrastructure, whose job it is to be aware of all the current problems and make a call as to which ones will be handled first. With the authority to do so.

So long as problems are being dealt with in an order commensurate with their potential to hurt the business you have achieved the objective behind separating them into major and minor classes.

Note: One possible 'rule' that you may encounter is that a major problem is one, the solution of which, goes through change control. IE: If a formal RFC and CAB sign-off is required the problem is Major, if it can be fixed through a minor pre-approved change then it is 'Minor'.

Take care with this approach - because you won't be able to assign the status until after you have the solution. And it is possible that a trivial break-fix issue with a single CI somewhere could have quite a large impact on the business. IF you are going to designated major problems you best do it before you start working on their solutions.