Tracking Changes from Requests

[svien]

In the ITIL Service Support process diagram (in ITIL foundation training guide) it shows the 3 inputs into change management are;

Incident Management
Problem Management
Customers, Users, Business

In the first 2 cases this is very straight forward as incidents are already recorded at the service desk and can be escalated accordingly.

Where my questions lie are in requests which come directly in from customers, users, vendors.
Should these RFC's have a incident request attached to them with details of why a change has been requested?
If so should the ticket get created after the workgroup(user) has decided what they want changed or should it get created when they start to address a problem (meaning it might be open for a long while)?
Or should 'workgroups' work as a project and not enter a change until they are finished with there work and then create an RFC ?

Any help would be appreciated thanks.

[ARoll]

What you are describing is something that we have gone through in previous organization as well as will be dealing with in my new organization. Essentially, pending your tool set, this would more than likely fall into a Service Request or Task that would be routed to the appropriate supprot team (or workgroup). The service request or task would entail what it is they are desiring. Because it would be something new or an enhancement so to speak it doesn't fall under an incident as the service is working as expected. Granted varying opinions and i for one would like to hear others the flow would look like this:

Service Request to Support Team -> Task Created for Research -> RFC Required (Yes - Enter RFC Process - Update Service Request to an WIP or similar status to not affect Service Level Timers, No Close Task and close out service request with requestor) -> Implementation of Change -> Verification of Success close SR.

Rather High Level to process flow but i think speaks the meat of a would be flow.