it was one said that no every change is an
improvment,but every improvement is a change.
look at change management in a nut shell, most
incidents will be directly relate to change,in
another word, when it comes down to change
management in your organization, many of the
incidents that reach the service desks are
because some types of changes or modifications
to the environment.when you trouble shooting to the
end users,what's the first thing you gonna do when
troubleshooting with somebody, you gonna ask them
what's the last thing you did to their workstations, they
call you up , they got problem,the experiencing
something crashing,some program not open, some
programs not function properly,the first question you
gonna ask them what is the last change you made to
your system.did you install any application?did you
make any situation change for your application?did you
open up any p_w_upload in your email?
did you know which website you've been to?questions
like that.to make a configuration change to the system
itself.ask the enduser if they can duplicate the last
action they took.the last change modification they
took.simple lack of resources,insufficient
preparation,poor job of doing analysis on a change to
our modification enviroment.the pilot testing is not
adquate,may be simply carelessly of on the
administrators.
-----------
obviously the goal of change management is to
manage change process , and this canbe any change
of modifications is made for a wide varioty of
reasons.change of the ip address scheme,rolling out a
new hardware solution.going  windows server
enviroment into linix server enviroment.or upgrade from
windows 2000 to a windows 2003.replacing upgrading
in this processing making changes, we want to limit the
introduction of errors and incidents relate to this
change, in a nut shell.change can be cause by 4
category of activities.change can be due to
enovation.because of new technology.and you gonna
make change because of improvement.like you found a
better sales lead tracking software solutions,by a
different vendor,better product ,more stable
product,more userfriendly product for lower price that's
improvement; you make change for simply
modification,like making modification for your firewall
devices.modification to your laptop computer for
example, to add more collap feature for your end
users,for more corrective measures,such as security patch, hotfix,correction to configuration.this is the 4 main categories for the 4 types of actions that will 
generate changes,change management is relate to
incidents, but change management is tightly couple
with configuration management because change to
configuration is constant things.adding configuration to
software and services to network devices and also
change management tightly couple link to release
management,you got a customer software
solutions,may be released 6.0, will to upgradet o
realease 7.0
-----------------
here is some key terminology of change management.
change scope : all it services ,any  configurations, any changes and processes technic and change in documentation,
change case , this what we use to predicate what kind of impact propose change is gonna have on our enviroment, so a change case will layout different situations, different senerios, that will lead to determination or clarification of the  scope of the changes that are board is proposing,this also gonna use in you cost benefit analysis.how does that change envoroment , what does it cost , what is the benefit.that's part of decision making process. this make down by a team of people, not just simply one manager. let's talk about the role of the change manager,change advisory board is a cap , this a team of individual that is basically advisory board for the change manager  as  him go through the process of assessing, priotizing  and scheduling the changes.this board should be represented by all the different areas of the IT service provider or the different business units and even 3rd party like vendors or suppliers maybe even contractors and consultants. the change advisory board is very important. change history is basically documentation.stored in the database that has information about  all the change made to a configuration item or into a databas during the life cycle during that item , this should be a history of all the change records . a change model should be a logical ,repeatable method for handling particular change categories, so if change model should be a specific predefine setup steps for changing items categories, you could have simle change model you dont' have to get approval.like pwd reset model.or a very complex model , for example a major software
release.
change record is allocate role of spree sheet.is a records that has details.particular change item.each change record should fully documented life cycle on individule change. and a change will be generated for every rfc or request for change that's received,even rfc were rejected by the manager or the change advisory board.the change record will be stored in a cms (configuration management system) . thats why change management so tightly couple with configuration management. a change schedule should be a document , it can be a web base document or hard printed document , this gonna listed all approved changes and the dates for the planned implementation will roll out for that change. A change schedule is also refer to a forward schedule of changes,
and finally change management is the process we are looking at here ITIL , its a overall process and procedure that dictate the controling of the life cycle of all change items.the primary goal of change management is to allow the beneficial change will do minimum disruption to other IT services.
-----------
First of all is recording the process , making sure all the sources of change can submitted their requests for changes at the adaquet recorded in the database.then accept them,filering out the accepted request for changes  and then accepting them to be consider even further,classific next, or you sort out the rfc in the categories, and according their priorities. for example high priority software.medium priority hardware,lower priority security.things like that,planing and approval.when you cosolidate the change, plan and approve the develop process and implemention scheme,, you also want to make sure the necessary resources are available ,time money personnel and of course involve the change advisory board.(CAB )whenever necessary. next coordination, coordinate the constrution, the pilot testing and the roll out of the change.finally the evaluation process.when you look back you need to determin if the change were successful, if it meet the expected goals.and draw conclusions and learn lesson how you can approve the change.this is the six steps
--------------
the first thing we gonna look at here in process is that all of our requests for change will be loged or recorded in some type of database, along with that particular entry, for that change item or change incidents, there will be a reference number of unknown error if it applys
, so change relate to unknown error , we gonna have that referene mirred in the database.  it may not be ,and if it is not, you won't have that number.also routine change is a standard change , for example like password update or changing the name of software package.chagne the name of object. standard service request will not gonna be assessed by change management.those will deal with by incidents management and the serivcies desk. what are these rfc come from? who generates them? problem managment? I just want the key area of these key IT servicese area could  generate request for change , problem management ,and other IT staff ,coworkers, customers ,end users , power users, they wanna generate a legislations , may be hipo legislation or sox
mandate from goverment are gonna generate request for change, may be from vendors or suppliers who is making modification on change of upgrades to their software or their hardware or their devices drivers.it could be base on the projects,may be you got a project could  lead to a number of changes.this will also ties to
a project management which will coordinate with change management the particular process like service level agreements, compacity management ,things like that.we gonna log this record, what's the log contain? it contain an unique id for the request for change, should be a unique identifier, you may also have applicable accross reference known error or problem number that's talk about and write on the first bullet board, a description of RFC, a reason for the change, any information base on the versioning.new versioning number and the new versioning  identifier, information about the individul submitting the changes.may be a name of location of the department.
a telephone number of that person.a submission date.
an estimate time frame for implemting the change, what resources allocations are projected as necessary to have that change made possible.the source should be recorded according to the ITIL standard change management. once the reqeust  for change recorded a log, you have an initial assessment,
for acceptance of rfc, youi may also optionly include re- request function for the RFC, for example, initial assessment do not accept RFC for the individul , giving them the opportunity , a certain time frame to re-submitt the RFC to better make their case, remember this RFC is relate to a particular CI, a change incident.also refer to a change incidents,change item depends on the documentation you use.