Rick, Here's some documentation I wrote up for a customer workshop that might help you.
Keep in mind, one size does *not* fit all. In fact, there's a suprising difference in operational tasks between support organizations even in the same industry. There will be some overlap, certainly, but using someone else's Categorizations would not be a very good starting point, IMHO. With that in mind, here be da rulez.... Categorization Guidelines 1. Use "Real" Data. It's a common mistake to try and tackle Categorization in one large chunk or to try and hypothetically define Categories. Rather than try and answer the question "What do I do?" or "What Categories do I nee?" take an example of what you do and ask "How can I Categorize this?" Refer to your current tickets or tracking tool or pick specific instances to examine. Once you've established a source for your Use Cases, form the description of the Use Case into a single sentence (or use the Summary or Description from your ticket data). For example: "User needs after hours badge access to Building 12". From that sentence, pick the direct object - "badge access" in this case - and use that to start your hierarchy. From "badge access", put the Use Case into a larger context first - some examples: "Building Access" ," Facilities", "Security", "Kronos". Then break the Use Case down into more granular terms. For example: "After Hours Access", "Building 12", "Add", "Modify", etc. This should generate a column of values. Once you've got the first pass on your list, reduce the list to only include pertinent items. Use the rest of the rules below to help strike items from your list until you've adequately described the nature of the Case. Repeat this step a few times with different Use Cases and patterns unfailingly emerge. 2. Avoid Redundancy If the data exists on other parts of the Form, don't include in your Categorization. Since it's not uncommon for Categorization levels to be somewhat scarce, redundant data will invariably take up space better utilized in describing what you are categorizing. Additionally, other data elements tend to change or get renamed. By keeping your Categories purely descriptive, you'll save data administration later as you'll not need to update Categorization for existing records. 3. Stop at the End This seems intuitive, but it's a common mistake to force values into lower levels of a hierarchy where none are needed. If you've determined values that fully describe what you need and you're fully aware of how that data is used, but the hierarchy stops at Tier 2 (or even Tier 1!) then.stop. The system will require all 3 levels be populated, but the values need not be significant at all Tiers. 4. Expect Data to Change There's an old saying - "The Best is the enemy of the Good". This means that trying to get something perfect before you use it means you will, in all likelihood, never use it. This is also known as "Paralysis by Analysis" or "Creeping Elegance". When determining your Categorization, keep in mind that what you did 6 months or a year ago was probably somewhat different than what you do today. Business changes, requirements change, and therefore, so will your data. Your starting Categorizations need not be comprehensive and perfect before they add value. 5. Include an "Other" Value. Just as you can expect data to change, you can also expect your business to change ahead of your data. It is far better to have data not categorized than categorized wrong. By including an "Other" or similar value, you give your users the ability to correctly enter data about new things in a way that's easy to identify. Conversely, miscategorized records will be impossible to find. Periodic reviews can assist you in updating your Categorizations, as well as identify "training opportunities": (read: lazy users). 6. Use a Single Path Each thing that you categorize should be represented in only one way in your Categorizations. This will help ensure your data stays consistent. Conversely, each "path" through your Categorizations can accommodate 1 or more things. This is related to Rule #3 - only go as far as you need to go to get the significant values you want. Use caution, however, as making a Categorization path too generic can dilute the significance of your Categorizations as a whole. 7. Use Familiar Terms and Nomenclature If your organization refers to SAP, PeopleSoftt, etc. as "Big Apps", use the term "Big Apps" in your Categories and not "Enterprise Applications", "Global Multi-User Multi-Tier Financial Applications" or some other unfamiliar, albeit technically correct, name. Keeping the familiar names will help in proper data entry. 7. Remember Data Usage. Finally, keep in mind what your Categorizations will be used for. In Remedy, Categorizations drive potential Assignments, Reporting, Solutions/Knowledge Bases, and are an aid in performing Searches. You want to ensure your Categorizations support these functions, so periodically perform a "sanity check" to make sure your Categorizations fulfill your needs. Hope this helps, Chris -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Roger Justice Sent: Tuesday, May 01, 2007 3:59 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM 7 Operational Categorizations ** Your Tier 1 and 3 need to be reversed then it will make sense with the new ITIL driven design concepts. -----Original Message----- From: [EMAIL PROTECTED] To: arslist@ARSLIST.ORG Sent: Tue, 1 May 2007 6:41 PM Subject: ITSM 7 Operational Categorizations ** I am searching for good examples of how to set up the Operational Categorization sets in ITSM 7.0, and finding the pickings pretty slim (the Remedy KB is typically sparse). Conceptually, I know that it needs to complement the Product Categorization, primarily by NOT duplicating the information contained therein. Knowing that I want to keep them related to symptoms that would be reported by users while still being useful in reporting, here's kinda what I am thinking about here. TIER 1 TIER 2 TIER 3 Application Request Installation Application Problem Connectivity Application Problem Functionality Hardware Request Upgrade Hardware Problem Peripheral Unfortunately, there don't seem to be many examples of a good setup of Cat 1,2,3 for the Op. Cats, (yes, I have seen the sample data) and I'm struggling to format a good, consistent set on my own. Does the example I included make sense, or do you see problems with it? Rick Cook __20060125_______________________This posting was submitted with HTML in it___ ---------------------------------------------------------------------------- -- AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com. __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
