Beruflich Dokumente
Kultur Dokumente
1
Real World Example 1
Scenario 1 – Before Change Management 1
Scenario 2 – After Change Management 2
Benefit of Managed Change 2
There is no One-Size-Fits-All Change Management Solution 2
What Kind of Change Needs to be Managed 3
Processing Change Requests 3
Change Management Should Work Your Way 4
Software Flexibility is Essential 5
The EnterpriseWizard Solution 5
Figure 1 – Unlimited number of approvals for each change 6
Conclusion 7
Generally the means of achieving these goals involve improving communications about
upcoming changes through automatic email notifications, making change scheduling more
transparent, and ensuring that proper approvals are obtained and recorded before
making system-wide or significant changes.
How does this work in real life? Let’s look at an example of a typical scenario with and
without change control.
A company has a server running a web-based application used by all staff members to
enter their time. After a security audit, the CIO is told that access to this server needs to
be restricted to SSL and all other ports closed. He instructs an IT employee to make this
change, not realizing that the shortcuts the IT department has set up to access the appli-
cation on all employees’ desktops will be broken by this change. The IT employee makes
the change as instructed, without stopping to think about any impact this might have, and
employees are unable to enter their time because they do not know why their shortcuts
have stopped working. The change has to be backed out, users are disgruntled, and
time is wasted fixing the problem created by the change.
Note: (A) symbols indicate automatic actions that occur at various steps, for example an
Email to Notify of Approval. (G) symbols indicate a “guard” that prevents unauthorized
actions. For example, only authorized people may be allowed to make specific requests.
Because the request is for a production server used by all employees, it is routed to IT
staff who enter information into the risk analysis fields and take responsibility for either
approving or rejecting it. The form contains a set of checklist items for SSL servers such as
“test SSL certificate” and “test user access”.
The IT staff member installs an SSL certificate and after installation checks his own desk-
top shortcut. He notes that the server must be configured to automatically redirect http
to https requests before the change can take effect. On completion of this configuration,
the change is marked as Implemented. If some of these necessary steps presented a
problem, the change could be rejected and the requestor notified. The tasks are com-
pleted in the proper order, employees are automatically notified by email when the
change request is completed or rejected and the entire process is auditable. Not only is
the process transparent, but the system maintains a History that proves how it was fol-
lowed in any particular case.
Because employees are asked to think about consequences and plan for them before
jumping in and executing the change, and because the right people are notified and
asked to approve the change, errors are avoided. There is also a documented process
that was followed and that can be reported on. Another benefit is that all the time it
took to analyze the situation, install the certificate, and configure the server to automati-
cally re-route http can be tracked in the system, allowing the total cost of making this
change to be quantified.
Definitions of change can be as diverse as the methods of managing it. The Information
Technology Infrastructure Library (ITIL) defines change as “the process of moving from
one defined state to another.” While this definition is broad enough to cover a large
variety of situations, it is too broad to be helpful when applied to specific problems.
Companies must therefore make their own decisions about what kinds of activities consti-
tute the kind of changes that should be controlled in a change management system.
While most companies would probably agree that a change to an infrastructure asset,
like the corporate mail server, should definitely come under change control, other IT tasks
may be less clearcut. Take a common example: setting up network access and an email
account for a new employee. Some companies may consider new employee setup a
“change” requiring approvals, while others may consider it a standard service request.
Typically a change management system is implemented alongside a help desk or service
desk, so the business challenge is usually defining which kinds of tasks should be treated
as changes and which should be service requests. One reasonable way to distinguish
between the two is to define a change as something that requires one ore more approv-
als, while a service request can be handled immediately by IT staff members.
So if a supervisor submits a request for new employee setup for Joe Smith and no other
approvals are needed, that might be a service request, while if the same supervisor sub-
mits a request to make a change to a financial report in Peoplesoft, and this requires
approval of an accounting manager, that would probably be a change request.
Deciding which business activities are to be handled as changes is the first step in imple-
menting a change system. The main goal should be to bring the behaviors that are most
Some aspects of change management are fairly constant from business to business. A
change will typically start its life as a change request submitted by a user, and the ap-
propriate decision-makers will be automatically notified of the request.
Decision-makers should then have a mechanism for either rapidly approving/rejecting
the change or adding comments. If the request is approved, the system should be able
to schedule, remind, and notify about the change.
Users of assets affected by the change can be automatically notified by e-mail. The
system can also automate other elements of the change. For instance, when the hour for
the change arrives, the system might trigger a browser popup reminder or an email to
the person assigned to implement the change, send an email to users who will be af-
fected, and update any affected assets to change their Status to In Maintenance.
Once the change is marked as completed, the system can put the Assets’ Status back to
its previous value and send another email to any affected users to inform them that the
change has been successfully implemented.
If the change system is being used to manage software application changes or enhance-
ments, changes may be linked to particular releases and automation could notify some-
one when all changes related to a release are completed.
Given a change management system with a robust rules engine to provide the kind of
automation described above, it is up to your organization to decide how exactly you
want your change process to work. This may depend on many factors. Changes related
to assets are often handled differently from changes related to user accounts or soft-
ware applications or to any of the other objects that you may want to be subject to
change control.
An effective procedure at one business may be totally ineffective in another. When
evaluating changes, businesses will often differ in:
Which groups of people can submit change requests
The information required in change request submissions
How many approvals are needed from whom for different types of change
Whether emergency changes are handled differently from planned changes, and
if so, how
Change management software must provide the flexibility necessary to align with the
company’s overall business goals. Further, to gain full value out of the system, it should
ideally be integrated with asset and help desk management, since there is generally a
close relationship between these functions.
If you already have an asset management system, it is wise to ensure that the change
management system includes API’s necessary for easy integration. If you don’t have an
existing asset management system, then a change system that also includes asset man-
agement provides a more complete solution in the long run.
While the basic building blocks of a change management system may be similar across
systems, these building blocks may be formed into very different workflows and data
structures. Instead of hoping that a given software vendor’s version of change manage-
ment will duplicate your process and structure exactly -- an unlikely scenario – it is best
to select a software product that can implement your process the way you want it.
A flexible product should allow data structures, such as tables, fields, and relationships
between them, to be created and modified without coding. It should also have robust
workflow and rules functionality, so that you can easily build the workflow you want, ide-
ally using a graphical interface that will both document and implement the process you
want.
In summary, an effective change management system should have at least the following
features to provide a powerful, tailor-made solution:
Graphical workflow editor that can easily define your unique processes
Automated mechanisms for indicating approval or rejection of a change
Email integration with dynamic hotlinks for automated notification and easy ap-
proval at each step
Automated alerts if users have taken too long to approve/reject a change pro-
posal
For organizations that are subject to audits, the system should also be able to:
Show auditors exactly what the change process is, without code inspections
Demonstrate that the process was followed in any particular case, with full infor-
mation provided on who approved any given part of the change and when they
approved it.