Service request, change request or a release?

[Hena]

Hi,

In our organisation, we have a mature change management process, a service request process that is weak, and no release management (no appetite from management). We do laptop and blackberry refreshes as hardware become old (2-4 years) and these are currently handled as service requests created and managed by IT. The service requests are either long term, or submitted as short term SRs with specific users listed for the refresh. Recently, we have started talking about incidents that have been caused by these service request and how our outsourced helpdesk not doing a good job of relating them to the service request (most likely because they don't know). The service manager has asked if the hardware refreshes should be managed as a delegated change which is one RFC for multiple implementations for a longer period of time with the condition that there is a set schedule and same procedures every time. This way we can manage the incidents better. She is basically looking for the mature change process to deal with something our less mature service request process can't handle. The scope of the change process as defined on our company is when you make a change to the IT infrastructure or to the services IT delivers. Technically, our scope is wide enough to say that blackberry and laptop is a service provided by IT.

The questions that came to my mind after that conversation:
1) In the ITIL world, can service request cause incidents? I can't find much info on this.
2) Should normal hardware refresh be covered under the change process or does it belong under a different process such as service request or release & deployment?
3) Should new standards for hardware and software on end points go through the change process? I.e. if we make Windows 7 our new corporate standard, should there be an RFC to make it so? We do that for security policies that are pushed out to end points.

Your thoughts on this are appreciated!