So you need to do reporting and you think that adding categories and subcategories will be the solution?

But what if you are wrong?

Sometimes the obvious go-to solution is not the optimal solution; neither for the University; nor for your team!

Not convinced?

Well why do you want to report? Is it to justify the status quo? Are your reports a lamp post to provide support for not changing? If so, and you are not willing to countenance change, stop reading now…

So you are still here reading! You are willing to change! (Or were you too annoyed at being told to stop reading? )

The difficulty with change is that it might turn out to be negative rather than positive. It might be retrograde. So we tend to stick with what we know. And to over-simplify into a model that fits our view of reality even if that means it clashes with everyone else’s!

So how does this influence reporting?

Let us first consider about over-simplifying. What if our over-simplifying was contributing to our complexity and unwieldiness? This is what happens with categories and subcategories. Whilst conceptually simple, if not curated, the subcategories proliferate often duplicated under several categories. Hierarchies make management simple but are inefficient.

Hierarchies are best left to data sets that have clear inheritance. Librarians have long used meta-data to describe assets (typically books) so they can quickly retrieve them. The system may appear more  complex than a hierarchy classification but is far more powerful. It does not require imposing an arbitrary lineage to the items.

Currently we have 34 business areas owning 224 categories and 1210 subcategories. There are 225 duplicated subcategories including 40 “Unspecified”, 33 “Other”, 9 “General”, 8 “Email”, 7 “Help and Training”…..

Of those subcategories 286 have not been used this year!

A devolved hierarchical approach to categories is not working. There is a role for the ITIL Team to drive improvement in this area.

An existing example of poor category-subcategory usage might be

• Category= “[function] Request”
  • Subcategory=”Student”

The subcategory is redundant as the affiliation of caller would give whether a student (and whether they are distance, undergraduate  or taught postgraduate, and what school they are in).

The category is also redundant. The [function] is implicit from the Operator Group resolving the call. The word “Request” is redundant because it is covered by setting  to Call Type=Service Request.

Call categories and subcategories should avoid duplicating each other and what is already available from other call attributes.

Improving Reporting With Fewer Categories and Subcategories

Our service support data from UniDesk has information about the call, the time line, the caller (and therefore their affiliation, college and school), and the operator(s) (and therefore their operator group, affiliation, college and school). The Operator Group is indicative of the functional area

Additionally, when used the object and external number fields may provide very specific. These call reporting points are summarised in a table at the end.

Within Information Services, the Categories and Subcategories have been aligned with our Service Catalogue Portfolios and the Business Services, and now includes the Finance and Procurement portfolio business services hosted on behalf of Corporate Services Group. The important point is that Business Services can only belong in one Portfolio.

If a student phones to say they cannot log into Learn then the IS Helpline should categorise base on what service the student is trying to use.

• Identify the caller against our registered callers – easiest way being to ask there username and type it into the username field. This ensures we have the Affiliation (UG,PGT,PGR including distance) plus their School and College.
• Probably set the Call Type to “Incident“
• Set the Category to be “Learning and Teaching”
  • Set the Subcategory to be “Virtual Learning Environments“
• The operator may be able to identify the root cause or may escalate. The root cause for such an issue could be Learn itself, or EASE authentication or MyEd Portal, or with the student’s Student Records. This can be put into the Object field once known.
• Occasionally the requirement for some ad hoc tagging of calls is required. The External Number field is free text and may be used in this instance. This might provide the tag required later for the more advanced options of linking to Problem or Change records.

The subcategory gives us high value data of what outcome the user was trying to achieve.

Finer meta-data can be added using other tags – the form used for a service request, or the object behind the root cause of an incident. The Call Type can be reset to “Service Request” if it transpires the user has forgotten their password.

Conclusion

The University is complex. High level decision making requires consideration of how numerous datasets intersect. A leaner University approach to use of categories and subcategories, coupled with a greater use of other call meta-data has the potential to greatly improve the quality of data available for decision making and improve  the measurement of whether those decisions are beneficial.

The ITIL Team can provide expert advice on using the existing rich data sets from UniDesk intersecting with organisational hierarchy and user attributes. Further we can provide advice on how your future reporting needs can be addressed with small tweaks to existing process.

Appendix – Reporting Attributes

Why More Categories And Subcategories Will Not Solve Your Reporting Gaps / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0