Once upon a time a ITIL tool incomplete...

[Gaia]

hello, i am new in ITIL so i hope my questions has sense
And here you are my story:

Recently it has been implanted a ITIL tool in my company (ITIL-TOOL), but unfortunately only the Incident Management module has been implemented, so PM and Change Request are missing in that tool.

In my company there is a support team (let´s call them SA2), (level of support 2), specific for the issues related to the internal software Applications of the company.

Howewer, the following support level for these Software applications (development team, let's call them SA3), has a tool for managing Bugs and Change Request in their software applications (DEV-TOOL). But ITIL-Tool and DEV-Tool are not synchonized automatically.

Well, i´d like to be corrected in my following proposals of solutions. Let´s suppose SA2 receives an incident and they are in these 3 different situations:

a) It´s a incident of a particular user with an application. SA2 resolves the incident and put the incident in resolved. Finished.

b) SA2 detects is a Bug in the software that of course is affecting to all the users of that application. There is no workaround for the Incident. They put the incident in stand-by and open a "Problem" in the tool DEV-TOOL, (because ITIL-TOOL has not the module PM!), so SA3 will start to analyze the bug. SA2 keeps the cross reference between the incident and the problem. are these roles right? I am not sure if SA2 (who detects the "Problem") should create the ticket for the problem, or if SA3 should. When SA3 resolves the bug they close the Problem in DEV-TOOL and then SA2 can close the associated Incidents in ITIL-TOOL.

c) SA2 detect that the Incident can be solved with a fast workaround (ie running a database script), but they can´t do it by themselves, so they re-assign the Incident to the appropiate Team.

d) SA2 detect that the users need a new functionality in the application, so SA2 put the incident in stand-by and they introduce Change Request in DEV-Tool in order to be evaluated and maybe implemented.

Thanks a lot for your answers...sorry for the long story but i´d like to be sure of the best workflow.
gaia

[rjp]

Gaia,

Obviously it is good if you can enable all your processes in the same system.

However it is not essential, nor is their only one specific process for handling incidents and problems. Rather the key questions are those such as:

Are incidents and problems handled separately with: incident resolution aimed at restoration of the customer's productivity and problem resolution aimed at fixing the causes: And can incidents be related to problems?

Are the processes ensuring that the right people (with responsibility and accountability) are getting the work in a timely manner. And that management can see an control this activity?

Are the sufficiently defined 'control points' - known conditions where records are 'parked', 'acted on', 'transferred to others', 'trigger events in a related processes', etc.

Is the whole thing visible to the people who are hadling the customer/end-user through all of this. Ideally the Service Desk?

Are you collecting enough meaningful information out of all your activity, to assess how well it is going, what it's costing you, and indetify areas that warrant improvement?

Are these processes at the very least, stable and repeatable - ie. they pretty much get carried out the same way in each instance?

The 'best' processes are the ones that address these points as efficiently and consistently as you can with the resources you have available. (Some people say that 'best practice' is a fantasy, and that only 'better practice' is worth talking about.)

Except for reporting and stability/repeatability which you don't talk about, it doesn't look too bad to me. Of course there is always room for improvement, but I can't see any glaring mistakes in what you are doing. Not with the details you have provided here.

Besides, judging from the overall tone of your question, you have already identified your key issue: Getting some kind of integrated process management in place, instead of utilising stiched together capability from a number of different areas. In this you are correct - it probably does need attention.