NOC / Service Desk

[mducharme]

Hi,

We are wanting to slowly move towards ITIL compliance with our Service Desk / NOC. I confess I do not have a 100% complete understanding of it, though I do understand the difference and distinction between Incident / Problem / Change and we log our tickets correctly based upon which they are.

We have two major sources of tickets:

- Customer call-ins reporting issues to the Service Desk
- Network monitoring software warning events or higher create tickets automatically in a special queue called NOC Events - NOC staff handle the events.

There is a great deal of overlap in the staffing - the same guys on the NOC team will handle high level customer issues as well. There are not enough NOC staff to properly handle events coming in, and we would like for perhaps a few of our service desk guys to double as event analysts for the NOC.

Managers here are strongly leaning towards setting up a second OTRS system for NOC Events instead of having them go into a separate queue in the current OTRS system. This means that customer service desk calls would be in a different help desk system from NOC events and could not be linked to each other except by copy and paste ticket numbers or URLs. This is being suggested to try to simplify the current system by dividing the functions as much as possible into two silos and then there is a NOC dashboard and NOC ticket search that is separate from the customer service ticket search / dashboard. Most staff would probably be logged into both OTRS systems simultaneously.

I wanted to ask about whether such a procedural/design change is consistent with ITIL guidelines. I am not sure if ITIL dictates how this type of system should be handled.

Any guidance here would be appreciated.

Thanks

[Diarmid]

mducharme,

Firstly to get you straight. You are not moving at all towards ITIL compliance - because there is no such thing as ITIL compliance. To help you to improve you must always be moving towards improvement and only using ITIL as guidance where it helps. moving towards ITIL would mean not looking where you are going.

As to your later question: ITIL never, never dictates anything!!!!

I'm not sure I what you mean by "...the difference and distinction between Incident / Problem / Change and we log our tickets correctly based upon which they are." It's one of the reasons I am so uncomfortable with the term "tickets". It is such a generic word, but in practice a ticket for an incident bears no relation to a ticket for a change or a problem. I don't see how one could do other than allocate them according to what they are.

It seems to me that splitting into two separate systems is a way of making your system more complex, not simpler. Managing priorities and resource allocations immediately becomes more difficult; as you point out, making links between incident reports will be far more difficult; staff could get dizzy remembering which system they are working in at any given moment; historical data will be fragmented and difficult to bring together - you will lose sight of the big picture; pro-active problem management will have more work to do looking for symptoms and patterns across two systems - harder to spot problems means later to fix them!

As to whether ITIL has anything explicit to say on this issue and what it says, it would be best for you to read the books and see for yourself. I dare say someone may offer you chapter and page references (but of course you could not be sure they had given you all, or even the most relevant, references and sometimes a partial answer is dangerously misleading), but I have no access to the v3 books and it would be too much like hard work for me to scour the earlier versions for this kind of question.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718