PC Replacement Process

[pasfou]

Hi all,
I have some difficulties to understand the relationchip between ITIL processes, moreover english is not my language

I considered the example of a PC break and is replacement.

Step 1) incident management via service desk function
diagnose, send Service Request (not RFC) to appropriate technical service.
Step 2) Configuration management
the technical service update the status of the old pc, prepare the new one, and update the information and status in the assets management (something like cmdb).
Step 3) Release management
the technical service send the pc to the user

I've got 2 remarks about this scenario.

1) I'm not sure Release management is a step of a pc replacement because it's a pre-establihed procedure ((service request);( is it?)).
However, in the first chapter of Release management we can read that RM is used to implement new software Releases or hardware into the operational environment. But few lines later we can also read "Release Management should be used for: large or critical hardware rollouts, especially when there is a dependency on a related software Change in the business systems, i.e. not every single PC that needs to be installed". So I'm in trouble with these two sentences.

Could anyone suggest me the appropriate path of a PC replacement in ITIL processes?

2) In Itil, there is 10 process. But no one describe the example of changing a PC.
Do we have to compose our own processes by assembling "component process" from ITIL? (see example above, step 1, 2, 3)

Does anyone get some home-made example of a representation of day to day used processes?
Could he spread these examples to the community?

Thanks

[rjp]

pasfou,

actaully your english is pretty good. And you are not doing too badly on your understanding of how the task of replacing a PC in response to a failure fits into the ITIL processes.

The only 'technical' adjustement to your decritpion of the process would be that Change Management updates the CMDB records on the old and new PC.

In a way all Config Management is about is 'information' - it scopes, defines and implements the data structures, monitors and controls the information - through discovery, baselines, audits, etc., and provides the information required by the other processes.

You comments about release management are pretty accurate also. Generally release management would not be involved with a change at that level.

To be very 'pure' - though only for the purposes of explanation - you would have two circumstances under which you might deploy a new PC:

1 - The situation you described: Ie., in response to a failure. This actually would be an incident rather than a service request, and Incident Management would raise an RFC that effects a 'standard' change. That is a change that is pre-approved. More over, some people might not consider this a 'change' at all because in replacing like for like, you really haven't altered the infrastructure. (But CMDB would still be updated). I don't think it matters all that much.

2 - A PC may be deployed simply becasue one is required - eg., in the case of a new staff member being employed, or the end of lease on the existing one. In such a case you would have a Service Request procedure to allow the client to request one (if that is part of your agreed service) and your Desktop Support Unit to respond in a managed way.

So really the difference between an Incident and a Service Request is the trigger (not necessarily the response). Though of course an Incident will entail the investigation and diagnosis of a disrutpion, while a Service Request will not.

So apart from a detail of two, you pretty much have it right.

More generally - remember that ITIL is not a replacement for standard operational activity of units in an IT organisation.

So you would still have, for example, a Desktop Support Group, or something like it, who would still be the ones who did the work in removing the old PC and deploying the new one. And they would carry out this duty under the control of Incident Management and Change Management processes.

That is, ITIL doesn't mean you have a Change Management team or Release Management team who go out and make the changes.

These are processes designed to manage (control, monitor, measure, report, coordinate, plan, etc) the work any IT department already does. They are complimentary disciplines to standard operational practices.

This is why ITIL doesn't detail specific processes for tasks such as your example. As management processes they are need to be applicable to any operational process. If they weren't they wouldn't be management processes.

Which means yes, we do have to work out how we are going to apply those processes to controlling and managing (rather than doing) activities like the one in your example.

Hope that helps somewhat - but like I said, you have got a fairly good grasp of the process relationships.

[spyder]

Actually this is a pretty good example of the need for flexible interpretation and case by case application of the principles of ITIL. The PC can be viewed as a component of the infrastructure and replaced through normal life cycle replacement process (Project perhaps?) or, the failure / malfunction be considered a "Problem" - or potential Problem for investigation- which begs the question why would you replace an entire PC - was it the Known Error? If so, that's probably a Problem with future implications and need for proactive Problem management - bad batch, poor design, etc. It all depends - also, slightly off the original scenario, but pehaps relevant, depending in the CIs and attributes there may or may not be a link to Change and/or Config based on the level of "independent change" - if a power supply or monitor was replaced vs the entire PC those components may not be identified in the CMDB - hence no interaction with either process.