In this article, I will discuss a process
commonly used to implement change, and identify what I consider to be
best-in-class change management practices.
Although
the labels may differ, organizations possessing a firm grasp on
managing change have adopted a process similar to the following:
- Create a project team dedicated to change
- Communicate the vision and goals of this team
- Acquire project team resources
- Monitor people/organizational issues
- Determine change management processes and practices to be leveraged, including tool sets
- Reorganize to support these processes and practices
- Implement these processes and practices
- Monitor completion of the project plan’s tasks and milestones
- Communicate feedback, revise processes and practices as required, and continue to monitor
When
it comes to managing change, topics like procedures, processes,
guidelines, managing to a plan, tool sets, and so on naturally come to
mind. Some guidebooks to change suggest an even simpler path to
implementing change, focusing on project plan execution, communication
plan execution, and stakeholder management. I have assembled a more
representative list, though, that I believe reflects best-in-class
change management practices as observed in my experience. These
practices are illustrated in Figure 1, and include the following:
Testing
Documentation
Standards
Release strategy
Clear communications
Workflow
Tool sets
Feedback loop
Each of these best-in-class practices to change management is discussed next.
1. The Core Philosophy Behind Change Control—Testing
Prior
to any change being implemented in a system, it must be tested. This is
true regardless of the enormity, location, or relevance of the system.
In other words, if the system is truly important or otherwise
mission-critical to its end users, it follows that anything that
potentially affects the availability of this system must be thoroughly tested first. Sound testing has the following requirements or characteristics:
A highly available and stable test environment is key.
The staff is sufficient to handle a large load of new/changed test projects or “test cases.”
To encourage repeatable and rapid testing capabilities, an automated testing tool or tools should be leveraged.
Test
cases should mirror process design, including exception handling, error
corrections, reversals, and so on. By their nature, therefore,
well-understood business processes often make the best test cases.
Testing must fully cover and verify all SAP integration points, and all possible input data.
Test
cases should be able to run “standalone.” That is, there should be no
dependencies on external data or other test cases, unless testing these
dependencies is the goal of the testing.
Testing
must help an organization determine the impact that change has on other
areas in the SAP implementation or within the company (that is,
business process changes).
To be most
effective, the individuals tasked with building test cases should be
very familiar with the functional or technology area in which they are
testing. This includes access to formal training as required.
In a new implementation, the testing phase
and related timelines should be broken out from your master project
plan, to allow for the granular level of detail required but not
typically found or warranted in the master project plan (in other
words, a high-level project plan like the SIPP included on the Planning
CD is not appropriate for planning and tracking granular-level test
case execution).
The end users should
determine what constitutes successful business-process output, based on
what they also deem as acceptable input.
Early
and earnest involvement on the part of functional design teams helps
them to understand the high priority of testing and test cases.
Test cases are refined and otherwise updated when gaps are discovered.
Changes
resulting from testing should be reflected in documentation, from
end-user-based to test-case documentation leveraged by the SAP TSO and
more.
If testing reflects the relative importance of a system, it’s safe to say that documentation
reflects how seriously this importance is taken—the more critical a
system, the better the documentation package should be that supports
it. Why? Because documentation directly impacts how effectively the system can be used, managed, and supported. The central role that documentation plays in change management is covered next.
2. How Documentation Impacts Change Management
Before we begin, it must be understood that the term “documentation”
in the context of change management means many things. To the mySAP
solution’s end users, the word “documentation” applies primarily to
functional test cases. Each test case must be documented such that the
case is very repeatable, and easily modified as the underlying SAP
system evolves with each SAP Support Package and new functional
enhancements. The key here is maintaining the data entry points, like
which particular company codes apply to which materials, which storage
locations apply to which plants, and so on. All of this is typically
documented in a documentation “package.”
To
the folks tasked with training, “documentation” relates to everything a
person new to a job task or position needs to know to become an
effective mySAP.com component end user. Thus, documenting the process
or work flow associated with each test case is paramount. And these
trainers also need to understand how to maintain this documentation,
the most effective ways of laying it out and presenting or delivering
it (workshops, formal training, Internet-based, and so on), and any
delta training required to be delivered between change management waves
or releases (discussed later).
Documented
workflow, process, and system training are all relevant and critical.
This is because regardless of the goal of a specific set of
documentation, it quickly becomes an integral part of supporting a
business unit’s standard operating procedures and processes.
Up
to this point, I have only looked at documentation from an end-user
perspective. To the SAP Technical Support Organization, though, the
term “documentation” refers to the various tools and approaches used to
manage change. This also includes documenting processes, like the
“promote to production” process, or anything regarding timelines (that
is, the amount of time a change stays and is tested in the technical
sandbox before being promoted to the next system, and then the next,
and so
on). Finally, documentation to the IS professional means frequently
redocumenting the “current state” of the entire SAP Solution Stack, and
updating how-to documentation as appropriate, such that all changes are
easily identified and tracked throughout the life of the mySAP.com
component’s system landscape.
3. Minimizing Change Management with Standards
For
most companies, maintaining less of a variety of IT technology—whether
this be a certain model of server, or type of disk drive, or version of
software package—will cost less in the long run and prove easier to
manage than maintaining a mix of products that might better fit each
variance and niche-requirement within a particular SAP system
landscape. For example, at one of my SAP customer sites, the client
selected Microsoft Windows 2000 Advanced Server as their standard OS,
even though Windows 2000 Server would have been adequate in quite a few
instances, not to mention cheaper. Similarly, they standardized on a
single model of database and application server, even though it
provided additional processing headroom in some instances, and
therefore cost a bit more up front than other models—in the long run,
we all believed that the total cost of ownership would prove to be
lower because this client had fewer alternatives to deal with.
That is, with fewer types and kinds of hardware and software to run
through the change control process every time a new firmware update or
Service Pack became available, stability of the SAP landscape would be
better preserved.
This example represents
technology areas where standardization served to minimize the change
management activities required to support the SAP landscape. Additional
reasons to standardize include the following:
- Fewer
hardware spares need to be maintained (less costly than maintaining one
or more spare hardware components for each component deployed in
production).
- You can take advantage of bulk buying or
quantity discounts (where “20 of these” is less expensive to acquire
than “7 of these” and “6 of those” and “2 of that” and “5 of those new
ones”).
- Less training is required for the SAP support
staff (no requirement to spend budget money training the operations
staff in supporting different variations of the OS, for example, or
different disk subsystem platforms, or database releases).
- The
staff becomes very familiar and comfortable supporting fewer hardware
platforms/components (no requirement to spend budget money training
staff in supporting multiple server models, for example), and support
calls are addressed faster.
- You
will enjoy less unplanned downtime, because components are
interchangeable (less risk of having to wait for a hard-to-find or
out-of-stock part in the event of a critical server component failure),
and less component variety equates to fewer changes that must be
initiated, tested, and ultimately promoted to production.
