Relationship woth Incident and Change Management

[ryanhardcastle]

Hi all,

I am currently drafting a change policy for our company. Within the policy I have made the following statement:

"It is also important to note that the rectification of an Incident is not a Change. For example if a PC is broken, and is replaced following a call to the Supplier Service Desk, the process which it follows is not within the scope of Change Management, but rather Incident and Configuration Management."

Is this in fact correct?

If is it could one also assume that if a centralised service, e.g. a router, was to fail, and required replacement as part of an incident solution, would this not also become an Incident/Problem process rather than Change?

Currently our suppliers will request downtime of the service as an emergency change, to repair/replace equipment resulting from an incident.

I need to apply great care and attention to how we define a Change and ensure the policy is watertight as it is quite a hot topic at the moment.

Regards,

Ryan

[Ed]

Hi Ryan

You are correct in thinking that defining 'a Change' is one of the most important things to do when writing a Change policy document - I found it quite tough. What I came up with is as follows:

Definition of a Change
The authorized addition, modification, or removal of approved, supported or base lined: hardware, network, software, environment, system, desktop build, or associated documentation.

If you accept that this is correct, then your questionable statement is actually wrong.

Rectification of an incident can result in a Change. In fact it most usually will.

The only way that I can see your example PC fix avoiding becoming a Change, is if you/your company decide that PC's are not subject to Change Management.

I hope this helps

Regards

Ed

[ryanhardcastle]

Ed,

Thanks that is quite a succinct definition. I do think the statement is correct but if we take the same example, a broken PC, I am seeing blurred lines between the disciplines.

I must clarify that our IT services are outsourced and that my company manage the service provided by these suppliers to our end-users.

Incident Management will be involved to rectify the Incident, which in this example is to replace the PC. As things currently operate under exisiting processes the supplier (who are outsourced) will arrange for the replacement using their own internal processes, most likely change processes.

I can see how configuration management has a part as they would be responsible for ensuring that the changes to the environment are reflected in the CMDB.

Where would you consider change to become involved and in what capacity? I can see how the addition/removal of equipment is a change role but only if this were outside of an active incident.

I might be confusing matters as we outsource.

Regards,

Ryan

[m_croon]

I would draw a practical (yet subjective) line on the distinction between front end and back end infrastructure. If front end (pc, printer etc.), impact is usually much smaller. As an organisation, you can simply decide that fixing disruptions on front end is under control of incident management (after all: ITIL is just a set of guidelines, nothing more). If back end (servers, routers etc.), impact is usually so high that I'd suggest putting the solving of disruptions under (emergency procedure of) change management.

Config could (also) come in by registering on product level which products are front end or back end, to avoid any mistakes.

[ryanhardcastle]

Good answer m_croon!

I think I will go with that. It makes sense that if something affects a centralised service then change should be involved. There is the risk of becoming too involved, with what are essentially minor incidents, which is what I was worried about.

Thanks for your help everyone.

Regards,

Ryan

[Ed]

Ryan

no confusion here

I am working for a company that is an outsourcing supplier and I am the Change Manager.

So here goes:

We ask our customers & suppliers to 'buy into' our Change processes as they follow ITIL guidelines.

If your PC is part of a CMDB and is baselined then any rectification will require that an RFC (Request For Change) is raised. Regardless of who it is raised by, I would want both my (as supplier) and the Customer's (if they have one) Forward Schedule Of Change updated by this RFC and it's subsequent Release.

This would give visibility of that Change to all who need to see it.

We accept Notifications from our Customers from their Change systems and feed them into our FSoC as a matter of course.

So I would expect you to receive a notification from your outsourcer that a Change is taking place, and that you would then feed that into your FSoC even if it was as a simple notification. We also ask for authorisations from our Customers if the Change is big enough / Significant enough to warrant it - This is done via our Customer Account Managers.

I hope this helps

Regards

Ed