At this point in your SAP implementation,
your solution vision has materialized in front of you—the SAP Data
Center and quite a number of SAP instances are finally running, and the
development team is making solid progress by now. Your SAP Technical
Support Organization is busy planning for the production phase, too.
All of this activity is at serious risk, though, if you do not give
attention to the process of managing change. Addressing change management or change control—the
terms are interchangeable—is “just another critical cog” in the machine
we call SAP. As with any enterprise or mission-critical system or
application, how an organization manages changes to that system must be
defined. Thus, before we take a look at best practices and approaches
regarding change management, a quick review is in order. Later, I’ll
highlight its value and importance in terms of maintaining a highly
available SAP system, as well as covering information on organizational
structures.
Change Management Mentality
A
productive mySAP solution environment is not expected to remain static.
That is, as functional and business requirements, software upgrades, OS
and hardware updates, and other subtle changes are requested or
required, the environment will evolve over time. Although this
evolution is good in terms of keeping a customer’s employees productive
and informed, an enormous opportunity to introduce instability into the
production environment exists, in the form of changes
to the production system. Therefore, if these changes are not managed
well, and managed consistently, the result over time will be much
different than the desired outcome—the system will prove to be less
than reliable, prone to unscheduled downtime, and more difficult to
manage than otherwise required.
Fortunately,
change management in regards to mission-critical enterprise
environments has typically been taken quite seriously. I work every day
with wonderful enterprise-wide examples of sound change control in
action, from mainframe-class and large UNIX implementations to
successful PC server-based enterprise environments. All of these
companies have embraced what can only be described as a no-nonsense
“mainframe mentality” to change control—it’s taken very seriously, and
it shows in their high system uptimes, low unplanned outages, and
ultimately happier, more productive end users.
Often,
when the topic of change management or change control is brought up in
the context of an enterprise application, managing the functional
changes within the application layer itself seems to capture the center
of attention. That is, all too often the focus is of a functional
nature. True, much of what drives changes to a system is initiated on
behalf of the end users and functional folks who reconfigure and test
SAP’s business processes. But many organizations that are not
end-user-based, not to mention technology drivers, serve to initiate
change as well, as you see in Figure 1.
And each change ultimately must be reviewed, approved,
developed/implemented, and eventually migrated or promoted throughout
the SAP system landscape. With little exaggeration, then, I can say
that nearly every member of the SAP Technical Support Organization can
therefore impact, or be impacted by, change control.
Managing
and implementing changes is a very precise activity, fraught with
system-wide ramifications if addressed less than absolutely correctly
day after day. And it is often unfortunately a labor-intensive task,
impacting functional teams, developers, SAP infrastructure support
folks, database administrators, the SAP Basis team, SAP administrators,
Enterprise Operations, the SAP Support Center, and more, not to mention
the Training, Documentation, and Change Management teams themselves.
Yes,
change management affects much more than just the SAP functional layer.
The entire SAP Solution Stack is impacted. So, too, is the entire SAP
system landscape and every phase of implementation. Your management
team drives and is affected by changes as well. And finally, change
management must focus on human and organizational success factors, too,
because these factors greatly impact whether end-user productivity or
behavior is indeed improved.
“Change”
often goes against the very values held dear by members of an
organization. This explains why changes in the daily routine or culture
of an organization must be proactively discussed and not ignored. Our
natural reaction to change, on the other hand, is to deny it at first,
and then to simply resist it when we figure out that the change will
not “go away.” Eventually, a critical juncture emerges—the change is
either accepted, or it is rejected, as Figure 2 illustrates.
This natural reaction must be addressed as much as anything else when organizational change takes place.
Change
is inevitable. But even fewer people than we think actually enjoy
change and can embrace and adapt to it quickly. Fortunately, the reward
for organizations that handle change effectively is compelling.
Effectively managing change is focused on SAP end users and other stakeholders, resulting in a more stable system, a better-performing system, a highly effective system, and so on.
In addition, the mission of change control often amounts to the following goals:
- Providing
solutions to users’ system problems (ushering in improved business
processes), which further tends to improve system utilization or value
- Improving system testing
- Maintaining documentation
- Maintaining training levels
- Improving knowledge management
- Implementing improved operational processes and procedures
The Real Reason for Managing Change—Stakeholders
Stakeholders in an SAP implementation include anyone with a vested interest in the success of the project. Gaining their buy-in is essential. However, the degree in which
stakeholders are impacted by the project vary, and therefore their
commitment level varies as well. A common way of breaking these
commitment levels down is by ownership, identity, participation,
agreement, and awareness.
To best address
organizational change like that driven by an SAP implementation,
consider the following guidelines and best practices when it comes to
designing or developing a change management organization:
- Stay
focused on the needs of the stakeholders. This should drive everything
from timelines to priorities, the structure of the organization, and
how processes are ultimately deployed.
- Leverage an
experienced change management consultant to review your environment and
help design your change management organization.
- Get as
much feedback as practical from stakeholders, including what they think
needs to be done with regard to developing an organization focused on
managing change.
- Delegate decisions to end users
whenever possible. With their decisions driving the project in many
ways, buy-in is practically a given, and priorities tend to be
naturally maintained.
- Ensure that the project plan allows enough time to formulate and implement a change management organization.
- Ensure
that the stakeholders understand the impact of your mySAP technical
designs. To that end, I am reminded of a customer who moved from a
single SAP production instance to a federation of systems connected via
ALE. The impact of this on the business, in that all data wasn’t
available on all systems, had to be understood and accepted by the
business.
- Finally, rather than trying to control
change, instead take the position that it is more effective in the long
run to understand and manage it.
If
you follow these guidelines, not only will it become apparent who the
primary people impacted by the project are, but it will allow for
preliminary stakeholder profiles to be developed for the SAP project.
And each stakeholder’s commitment levels will make themselves known,
too. Finally, general change management and communication models can be
created with each specific stakeholder/audience in mind.
