Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: BrigetteX
New Today: 152
New Yesterday: 202
Overall: 130716

People Online:
Visitors: 49
Members: 2
Total: 51 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Relationship woth Incident and Change Management
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Relationship woth Incident and Change Management

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
ryanhardcastle
Newbie
Newbie


Joined: Aug 14, 2006
Posts: 16
Location: London, UK

PostPosted: Thu Aug 17, 2006 8:44 pm    Post subject: Relationship woth Incident and Change Management Reply with quote

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
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Thu Aug 17, 2006 9:15 pm    Post subject: Reply with quote

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
Back to top
View user's profile
ryanhardcastle
Newbie
Newbie


Joined: Aug 14, 2006
Posts: 16
Location: London, UK

PostPosted: Thu Aug 17, 2006 9:26 pm    Post subject: Reply with quote

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
Back to top
View user's profile
m_croon
Senior Itiler


Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Thu Aug 17, 2006 9:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Visit poster's website
ryanhardcastle
Newbie
Newbie


Joined: Aug 14, 2006
Posts: 16
Location: London, UK

PostPosted: Thu Aug 17, 2006 9:54 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Thu Aug 17, 2006 9:56 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.