Next,
we'll spend a few moments speaking about the
implementation of change management.
Think for a moment back to the last time you
attended a change management meeting,
were you so riveted in desiring to attend another one as soon as
possible because it was just such a refreshing,
concise, and informative event?
Why is it that you think change management meetings are so problematic?
Think back to your experience of the change management meeting
that leaves you wanting for a better experience.
The first thing that we need to address is who is the change
management meeting designed to service?
If you answered anything other than the business,
you may be a contributor to why the change
management meeting is such a dreary time.
If someone is mentioning the VTEP tunnel endpoint and the need to modify the
Ethernet MTUs to ensure that they are not dropped frames,
then that is a traceable reason why the meeting is so onerous.
If the technologist is focusing on the technology and not the service,
they are no different from a host or a maître d' that focuses on
the refrigeration and ovens in a restaurant when you'd like the
menu to choose the foods you came to eat.
Just as the systems used to produce the foods are not the focus for your meal,
neither should the technology that produces the benefits be
the focus in the change management meeting.
Imagine this language from a technologist in a change management meeting
that says the service that drives the following revenue has an update to
assist in managing a higher customer volume.
The business gets that, and they understand it.
Components of change management would include the policy for change management
that should be established and documented to define service components under
the control of the change management capability.
The policy should also delineate categories of change and how to manage them.
In a moment, we'll review the types of change.
The initiation of change management will be guided by service,
design, and transition and will be implemented according to the policy.
So think about major activities, including the adding of new services,
the removal, and the transfer of services.
And then you have activities.
What are things that need to come under the auspices of
an official change management board?
What are the business benefits?
The feasibility and the financial impact of a particular type of change?
What kind of impact does it have on the customers under
which that change is going to take place?
Continuity, serviceability, information security, and other requests.
We should be forming a picture by this point.
A very important point that we should be deriving in this
discussion is that change management is the umbrella for all the
other managements that we just mentioned.
Capacity, service, availability, information security,
continual service improvement, configuration management,
deployment management, batch management,
all of them should come underneath change management.
When we think of the change management activities,
it really is about planning to improve a service,
it's about engaging the organization for the change that needs to take place,
which would include all stakeholders and all stages of the
change; the actual design and transition is essential for
deployment of new services or significant changes to existing
services; the obtaining and the building,
ensuring that you have engagement and cooperation within and across
all the projects; and the delivery and support would continue during
the live operations and support to ensure that the change has been
adopted and is sustainable.
There are three types of change.
The first one, a standard change, are low risk and preauthorized.
That means that they don't need to be part of a formal meeting.
These changes have complete documentation and can be
implemented without additional authorization.
A normal change are those that need to be scheduled,
tested, assessed, and authorized by means of a change management board.
Typically, under the auspices of that change management board,
normal changes have been reviewed for a corresponding impact and can follow a
streamlined approach that supports high‑automation pipelines for continuous
integration and continuous deployment environments.
An emergency change is implementation of a change that
could be normal under normal circumstances,
but now what you're doing is you're dealing with an
incident or a high‑impact security concern.
These changes are not going to be on the normal schedule,
and the process for assessment and authorization are expedited.
Configuration management now allows the technologist to take off their business
hat, coming out of the change management meeting, and then to go into the idea
of identifying the actual technological systems.
So this would include hardware, software, network suppliers, documentation.
But even though you're in a technological world,
you should be considering the impact of service, so
updating changes to the environment is another reason why
you do configuration management.
You're looking at configuration items that are consequential
to delivery of the service‑value chain.
You're also ensuring that you have accuracy of the collected data
that details the visibility into the version,
the model, the vendor, the release date,
and other information that would help you to resolve problems
that might come from the changed update.
There also needs to be an ongoing audit of the change that has taken place,
and the infrastructure to expose undocumented items and also things that are
not conforming to the change management board's policy.