The Initial Dilemma

The first real hurdle we ran into was classification / categorization of our records. We’ll use Incident as an example. There are hundreds of opinions on how an Incident should be categorized and I personally question how ITIL V3 compliant many of these recommendations are. Here is a thread that gives some examples of differing opinions.

On the surface this seemed straight forward if we wanted to model ITIL V3. We will use a Service oriented approach to Incident classification as Incident Management is not about determining root cause it is about recording what was reported by the end user. When we want component level visibility (Network, Printer, PrinterABC1…) of root causes for reporting purposes we will simply query the Incident Records and their associated CI (Configuration Item) information.

Wait a minute. We’re not implementing Configuration Management/CMDB. We don’t have CI information. This is where tool limitations and resource constraints can come into play.

With minimal resources at our disposal for ongoing tool maintenance and administration the decision was made rather early to limit customizations to only those necessary. Out of the box our tool uses the same categories for Incident, Service, Problem, and Change records. This became the dilemma. How do we come up with one standard set of categories that can cover all of these areas while still allowing for Service capture and separation of Service Requests from Incidents? We did not want to add an entire category tier dedicated to simply separating these category types and we did not want to get into a lot of database and forms customization.

Again – we are taking a big bite and need to follow the KISS principle if we want buy-in from our staff. This is indeed organizational change and not a switch flipping exercise.