Hi Doug. I use Operational Categorization in Problem Management. I do this so the category in both Incident Management and Problem Management match when a Problem Investigation is created from an Incident. It is also helpful when we are trying to see if there is an existing problem or known error with a workaround that matches a reported Incident. This works well for us because all of our categorizations are very specific. If you use a more general categorization scheme, it may not work as well.
Let me know if you would like any additional info.
So the operational categories in 7.5 example are the same as the Resolution Categories. From talking to several companies no one is using the "verb+noun+noun" format and the vendor doesn't know what to use for operational categories (they didn't even follow their own documentation..
Anyone else willing to share that you Do or Don't use operational categories and if you DO share a sample.
Whether Operational Categorizations apply to Problem Management is really up to you and your organization. As to one possible structure for ITSM 7.x Operational Categorizations, you might consult my paper "ITSM 7 Operational Categorizations - A New Paradigm", located here on the BMCDN at http://communities.bmc.com/communities/docs/DOC-3231.
Thanks for the reply Rick, we have looked at the document your listed. It is very interesting that none of the companies I have spoken with use Operational Categories as recommended in the new paradigm document and as we investigate further the type "verb + noun + noun" really does not fit Incident Management, it collides directly with product catagorization "noun + noun" and the resolution catagorization "verb". The operational catagory as defined in the new "paradigm" seems to fit service request management not incident.
Let me restate our initial goal with operational categorization. When an incident is created, is there additional data aka "operational catagories" that will enable proactive problem management (aka data mining)? So far it seems that companies that I have spoken with the operational category is closely duplicated with other data already in the incident record in 7.0x and clearly duplicated in 7.5 incident records.
My thought right now is it that operational catagories are leftovers of the 6.x days (CTI) which has been replaced by a multitude of fields, including product catagories, resolution catagories, service and CI, and assignment groups. If you look at the samples in 7.5 that Shade recommended the operational and the resolution entries are identical, it appears the BMC is not sure what to put in for operational catagories as well. I think it's time to pull them off the form until some future need arrives that is not fulfilled by other data types.
Doug, I think I see what you're saying, and I understand and agree with much of it.
In v6, CTIs were the only way of categorizing an Incident. As a result, everything but the kitchen sink was thrown in there - I have seen companies with over 10,000 CTI combinations. In v7, they aren't as important, but can still be useful, at least in IM. Rather than leave customers with no other options but to repeat the poor methodology of the past, my document was intended to do two things:
1) Break the cycle of kitchen-sink CTIs being dumped into the OpCats. I have seen v7 customers with their OpCats so convoluted and in conflict with their ProdCats that the Assignment Engine could not derive only one group, much less an assignee, from a combination of Categorization and Location.
2) Provide nothing worse than generic placeholders for the CTI values for companies that need something to help the Assignment Engine, but don't want to really depend on them primarily for metrics and such. While OpCats may not technically be required, old paradigms die hard. While OpCats may not be required fields, the data in them is still used by lots of people to manage the business environment, and for that reason alone, I can't imagine someone installing ITSM without SOMEthing in there.
As written, I disagree that it collides with the Product Categorizations. It provides a generic overview (i.e. Install --> Software --> Laptop), allowing the Product Cats to define the details of the Software, and tying it in with the CMDB/Relationships forms to define the discrete laptop CI involved. The company can then decide whether, and in what instances, they wish to use the generic or the detailed definition to drive reporting, assignments, etc. So they gain flexibility, reduce data redundancy, minimize data maintenance, and easily enable self-service by using simple OpCats like those I defined. I don't see what is wrong with any of those things.
I agree that the absence of a recommended and well-thought out set of OpCats is a huge hole in BMC's offering - I brainstormed the idea in desperation the day my first ITSM 7 customer asked me how their v6 CTIs would work with the Product Cats. I hope you think it is, at least, better than the vacuum that seems to be the alternative. Of course, if you come up with a better solution, I would truly love to see it, and would be willing to work with you on it if you like. I might suggest that you re-read the ITIL justification for those fields first, to make sure that your design fits the ITIL model.
I might also suggest that a good solution now is usually better than a (mythical) perfect one later. Go with the best option available when you need one in place.
What do you think for IM categories to help categorize to support Problem...and align with ITILv3?
The objective would be to tie the relationship of the CI Service type in the Business Service Catalog "Parent" to the critical "Child" Technical Service CI relationships that would map to the Categorization types and help IM and PM identify what was broken.
Service Type: End User Repair (CI from ServiceCatalog)
Cat 1: Hardware or Software (pull down tab - selected HW)
Cat 2: Desktop, PDA, Laptops, Blackberry, VOIP Phones, Printer, Scanners (pull down menu from HW subset - selected Desktop)
Cat 3: Monitor, Keyboard, Mouse (pull down subsets)
For Categories could you use the Technology catalog to help identify the pull down choices for the Service Types?
Prod 1: HW
Prod 2: Dell, HP, IBM
Prod 3: ?
I was understanding the value in the Verb/Noun/Noun (Install / SW / Laptop) categorization approach but then I saw the Calbro enablement data which was very different. Inc_Rqst/Noun/Verb (Failure / HW / Upgrade).
Switching the order of Verb/Noun/Noun to Noun/Noun/Verb is not a significant divergence of the end combination but what is this FAILURE and REQUEST at the top level of Calbro data? It seems a waste of functionality because Incident or Request type is already captured in another field.
The paradigm looks good for Requests but not for Incident categorizations. Best practices are lacking granularity in the incident description per Categroizations to add sigificant value to reports and trending. What's wrong with the software or hardware? Timeout (availability), slowness (performance), data integrity, error message, just a "how to" question
For example, "my Outlook mailbox lost my personal Folders". This has become a recent problem and I want to get reporting data out of Remedy.
(Operational Cat) (Product Cat)
Paradigm: Repair / Software / Laptop SW / Desktop Apps / Microsoft Outlook Client
Calbro: Failure / Functionality / Repair SW / System Application / User Productivity
I don't see the added value from the original CTI setup. Even combining approaches, I feel I am missing a level of reportable detail, i.e. Inbox or Inbox folders or email data files ...
Repair / Software / Functionality SW / Desktop Apps / Microsoft Outlook Client /(Inbox problem)
BTW - The information of Outlook being on the laptop can be determined elsewhere from the user's asset info.
My only thought from here is to use a field or attribute for the Product definition as Core Functionality and place it in the real estate for Manufacturer.