Incidents -> Problems -> Know Errors -> RFC

[Lucy]

Does anybody have a flow chart of the decision making/workflow of handling a call raised via a service desk setup?

I am looking at implementing ITIL compatible processes and choosing a new service desk/bug tracking tool for a department that does not operate a strict 'service desk' environment as it really services inidents/problems/requests relating to coding bugs and development enhancements. I anticipate, in this environment, that most of the 'incidents' will be 'problems' and once identified as 'known errors' these will need to be resolved by coding changes, a 'RFC'.

I am trying to come up with some logical process that integrates these states. Any help/experience appreciated. My big question at the moment is when in the process do problems and known errors get closed? There's plenty of speak about resolving and closing incidents, but nothing I can see on problems and known errors.

Thanks

Lucy

[mrcasal]

I think that you must close a problem when the RFC with the final solution, is running on the real enviroment.

And I think, that you must allow to open inicidents, and relate them to closed problems, becouse sometimes the RFC could not fix the bug.

[Azard]

Hi, you can refer to the ITIL Service Support Book - Annex 5E: Incident Handling on the Service Desk (flow) [this is what is in in my version].

Not sure if this is what you are looking for. You also have to keep in mind, that your buisness requirements should drive more specific detail to the process flows.

Cheers,