6 Replies Latest reply: May 13, 2009 8:39 AM by Björn Calabuig RSS

Resolution Categorization

Jose Pedro Teixeira

Hi,

 

Does anyone know of an article were Resolution Categorization and Resolution Product Categorization best practices are discussed?

 

I’m wondering on the best way to use them in the Incident Module!

 

Regards,

Jose Pedro

  • 1. Re: Resolution Categorization
    Björn Calabuig

    Hi Jose,

    I unfortunatelly don't know about a best practice document, but if I could give you an advice, try to limit your expectations regarding this matter.

     

    A good rule of thumb would be, for example, to have the same set of Operational Categorization tiers than for Resolution Categorization tiers: an Incident should have been created with a wrong operational categorization, or maybe, during the incident's lifecycle, someone decides to change this operational categorization or maybe, when resolving the incident, someone decides that the correct categorization is different from the original one.

     

    This Resolution Categorization tiers, in my opinion, should be the same than the ones defined for the Operational Categorization. But this will involve a lot of work to do: it's a n-to-n relationship... I mean, for each Operational Categorization entry triplet, youll have n possibilities as output.

     

    Maybe there's a better approach, limiting the possible Resolution Categorizations for each Operational Categorization entered. But you'll still have a lot orf work to do initialy and later, mantaining all this info.

     

    Maybe someone can enlight us with a best practice document.

     

    Kind Regards,

    Björn.

  • 2. Re: Resolution Categorization
    Jose Pedro Teixeira

    Dear Björn,

    I tend to agree with you, when you say “Resolution Categorization tiers, should be the same than the ones defined for the Operational Categorization” the same with Resolution Product Categorization.

    What I’m not sure is, if these fields should be used to track incident categorization changes! Maybe it’s old habit from previous versions, but if incident was wrongly categorized I would change the Operational or Product Categories them self. This way is possible to set a different service target for the “correct” categorization, use auto assign, or allow multiple changes – witch I don’t see as advisable, but must consider has a possibility.

    Considering this scenario I still have doubts on the usefulness of this resolution categorization. I could understand using them to feed a resolution knowledge base, but even then, I have difficulties understanding the need for a Resolution Product Categorization different from Incident’s Product Categorization.

    Any contributions on the subject?

    Regards,
    Jose Pedro

  • 3. Re: Resolution Categorization
    Björn Calabuig

    Jose Pedro,

     

    I didn't ment to say or, at least, I didn't want to say that Resolution Categorization and/or Resolution Product Categorization should be used to track Incident categorization changes (for achieving this, there are other methods like auditing fields).

     

    Instead they should be used, when an Incident has been solved, to give the possibility to change the initial Operational Categorization and/or Product Categorization tiers because someone thinks the initial categorization doesn't reflects the final situation for that Incident (and, for example, reporting could also be based on those "final" resolution tiers).

     

    Or maybe to complement the initial Operational Categorization and/or Product Categorization tiers. For example, you could have the following incident categorization:

     

    Incident Classification Tab:

    Operational Categorization Tier 1: Operational malfunction

    Operational Categorization Tier 2: Software

    Operational Categorization Tier 3: SAP

     

    Product Categorization Tier 1: Information Systems

    Product Categorization Tier 2: SAP R/3

    Product Categorization Tier 3: SAP SD

    Product Name: Weighbridges

    ...

     

    Incident Resolution Tab:

    Resolution Categorization Tier 1: FIN-ACC Financial Accounting

    Resolution Categorization Tier 2: GLA General Accounting

    Resolution Categorization Tier 3: -

     

    Product Categorization Tier 1: Information Systems

    Product Categorization Tier 2: SAP R/3

    Product Categorization Tier 3: SAP SD

    Product Name: Weighbridges

    ...

     

    In this sample, you use the Resolution Categorization tiers to go deeper into the resolution, specifying the affected SAP process and subprocess.

     

    Or, as you says, maybe thinking on the Resolution Categorization as a way to feed a Resolution KDB would be a good approach.

     

    Realistic said, a "recategorization" for Product Categorization tiers will not be as usual as one affecting the Operational Categorization tiers, but it could also happen.

     

    Kind Regards,

    Björn.

  • 4. Re: Resolution Categorization
    abrock

    Please review Rick Cook's document on categorizations which can be found in the document section of this site - http://communities.bmc.com/communities/docs/DOC-3231

     

    it should give you lots of ideas of how to move forward

     

    Anne Brock

  • 5. Re: Resolution Categorization
    Steve Wilson

    I disagree.  The concept of whether something was entered with the wrong categorization tends to happen with the product categorization...which is why it exists in both places.  Example:  Incident submitted with Op Cat of: Failure > Software > E-mail and Prod Cat of: Software > Desktop > E-mail.  At the time the incident is resolved, it turns out that it was a hardware issue with the switch.  Resolution Cat might be: Hardware > Reboot > Switch and a different Prod Cat of: Hardware > Network > Switch.

     

    The operational categorization is used to describe what kind of Incident it is. Failure > Software > E-mail, etc.  Think of the operational categorization as a way to break down the summary of the incident into three tiers for easier searching, reporting, etc.  The Resolution Categorization is used to breakdown the content of the Resolution field; i.e., how the Incident was resolved, into three tiers...also for easier searching, reporting, etc.  Examples: Reset > Password, Hardware > Switch > Reboot, etc.  So I don't think it's logical to have the same data in the resolution categorization as the operational categorization.  If the intent was to do so, then that data would have been stored in the same form.

     

    BMC is continuing to strive to improve the sample data included with the applications to provide best practice examples.  Stay tuned.

  • 6. Re: Resolution Categorization
    Björn Calabuig

    Hi,

    After reading the document "Remedy_ITSM_7_Operational_Categorizations", one thing is clear, there are many approaches but there must be always a starting point, and the one exposed seems generic enough to be applied in many circumstances.

     

    The question now is to find a best practices approach for Resolution OpCat and Resolution ProdCat.

     

    Steve, I agree with you but, I still think that the easiest way to have a starting Resolution OpCat  (in my opinion) is to use the Classification OpCat. That's because I said in prior posts that having the same data in the Resolution OpCat as the Classification OpCat would be an easy starting solution and because, in my opinion and in my experience on different Customers, there are many situations that lead to an initial incorrect Incident Classification OpCat (maybe caused by a Support Staff error when creating the Incident, maybe caused because the Classification OpCat itself is not present and the Support Staff technician selects the most likely one he could found, maybe because the Incident Templates are incorrect...)

     

    In this situation, what to do with this Incident? Correct the Classification OpCat or leave it just the way it was created and use the Resolution OpCat to reflect the correct OpCat, just when resolving the Incident?

     

    Doing this way, maybe this could help to identify:

     

    - incorrect Classification OpCat's:

    some Incidents are always corrected with a different Resolution OpCat... maybe the Support Staff technicians should learn to use the correct one!

     

    - obsolete Classification OpCat's:

    some Incidents are always corrected with a different Resolution OpCat... maybe the Classification OpCat is obsolete and the new should be used!

     

    These are just thoughts expressed aloud based on "living" experiencies and taken decissions based on the lack of information (Best practices, BMC official documentation with good samples,...).

     

    Kind Regards,

    Björn.