New Service Desk Solution - Subject Tree - HELP!

[griznuts]

Hello, I just ran across this website and have found a lot of good information on it already. I work for a large organization of approximately 1500 users (which could balloon up to 20,000 in the event of a major catastrophe) that are distributed across the state. We began incorporating ITIL philosophies about a year ago. We have recently purchased an ITIL-compliant service desk solution. We are going to take a phased approach and begin with the rollout of Inicident Management, followed by Change Management. I am having a hard time getting started on creating the subject tree/incident classification schema. I have identified SME's from the functional groups that will be using the application. Can anyone recommend a good website, book, or starting point? I would love to see a small example of a subject tree that follows ITIL best practices. I guess the biggest issue that I am running into is the 1st level. The subtypes should come easy from there. I have heard mixed suggestions on what should be located on the top level. I have been told that you want to keep it generic so that you can group like items together. On the other hand, I have also heard that you want to list all major CI's on the top level such as all of our systems.

Any help would be greatly appreciated.

[Mark-OLoughlin]

Hi,

first off "ITIL-compliant service desk solution" - does not exist. You cannot be compliant to ITIL. it is not a standard - but the tool can be designed to support the "best practice" guidelines.

As for the tree structure - have a look at your CMDB and identify possible calls and tyoes of calls. Also have a think about what you want to report on first. The category tree will provide an input into a report to allow you to see and understand ..... (this bit you need to identify).

You can start simple - and then grow the list as to go the other way will be more difficut to change in the future. If in doubt start small. The ITIl SS book has a starting point to get you going.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[griznuts]

Thank you for your response. By stating that the solution is ITIL-compliant, my point was that the software is modular based. We purchased the Incident, Problem, and Change Management component. There is a flow from the different modules to one another. I have all of the items that the groups wish to report on, however; some teams have given me basic information and others gave me data that they want broken down into 6 layers. I have to decifer and classify these items together so that we can keep it simple for the end users. I will point out one thing that is causing an issue, and that is that Senior Management has not decided on a CMDB vendor. I just need to move forward with this because the groups have provided me with the items that they will eventually include in the CMDB. You had mentioned the ITIL SS book. I just did a web search, is that the "ITIL Service Strateg" book?

[Mark-OLoughlin]

Hi,

the book is the Service Support book from the V2 track. I would not buy if for the sake of getting a start on an incident tree structure but it does offer guidance overall in helping figure out how to put all this together.

Also have a look at getting the ISO 2000 standard - should be a free download. That wil help a bit but won't go into too much soecific detail.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[OhioScott]

My issues with this typically stem from lack of stakeholder agreement. So in the short term I use the category structure of Change Management for my subject tree for implementation and then let continuous improvement adjust the tree as necessary.

This move isn't for everyone but in my case it was either that or face 'analysis paralysis'.

I agree with Mark though that CMDB is crucial. If you can't implement Configuration Management, at least put together a listing of configuration items and rate them for importance in order to assign values for incident prioritization. Depending upon the type/size of your company, if you have to file a SOX 404 Narrative, the Financially Significant Technologies would be a good start for your critical applications and the databases & servers that support them. Also be sure to include the network components.

Just lessons from my experiences.

[OhioScott]

Sorry... I guess I should clarify what I used for Change Management categorization. For the implementation in question, I was able to get agreement on the use of a CI's criticality to a business operation and the impact of the business process on financial operations to define Change Category.

Since we couldn't get agreement for Incident, I used the same components to define the criticality of equipment for Incident and the nature of the incident to define severity.

[Doober]

In my experience implementing SD tools, there's a great paradox in Subject Tree creation. There's always a LOT of energy (hence debate) put into a careful design, but there is very little reward for the effort. Why? Because many organizations don't report on it.

How will you know if you need to report on it?

Well, ask yourself this: What questions do we have now (or soon) that will require a subject tree to answer?