Operational Category 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.

8. 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.