7. Another Way to Implement Change—Workflow
As
in testing, documentation, minimizing variables in the SAP landscape,
and so on, the concept of workflow is another excellent change
management facilitator. One of my SAP customers tells me they enjoy an
exceptionally smooth change management process by employing the
following “workflow-based” approach to implementing new changes. For
this example, let’s say that the impending major change is with regard
to adding the HR functional module to the company’s current SAP R/3
implementation. An initial budget has been approved, and
executive/senior management sponsorship is already in place:
The
customer/end-user organization meets with the change team on a weekly
basis. The team consists of the manager of the group (the change
manager, or a designate), a few key technical SAP TSO resources (based
on the nature of the upcoming projects or change waves), appropriate
functional representatives, and the supervisor of computer operations.
Based on the change to be implemented, a basic work breakdown structure
(WBS) or simple “scope of work” is drafted during this meeting (for
larger-scope projects, like adding HR, people are expected to come to
the meetings with their initial work breakdown structures, rather than
consuming valuable time to do so in the meeting).
Success criteria are identified.
A priority level for the particular change is established.
Test
hardware, software, infrastructure resources, end-user liaisons,
functional liaisons, and technical liaisons (collectively termed
“resources”) are identified during this initial meeting.
End-user,
functional, and technical team leaders are sought, and usually named at
this time. For big changes, a project manager is named as well. The
meeting ends, and each Team Leader takes with them action items with
regard to completing their piece of the WBS, fleshing out timelines,
identifying constraints, and so on.
In
another meeting attended by all team leaders and the project manager
and/or change manager, the tasks and milestones for inclusion into the master project schedule (leveraging what this customer calls a change checklist)
are identified. A preliminary timeline is drafted by each Team Leader,
reflecting the needs of the area in which they are responsible.
Constraints are reviewed (holiday/vacation schedules, availability of critical resources, and so on), and the meeting ends.
The
change checklists are merged and reviewed at another meeting to ensure
that the workflow inherent to each individual area still “works” and
“flows.”
The
merged and now revised master change checklist is formally reviewed and
introduced into the master project schedule some time in the next few
days. The change manager owns the master project schedule.
The
project manager or change manager coordinates with the technical lead,
SAP Basis team, and any solution stack partners to ensure that hardware
resizing is addressed. With regard to this HR example, the database
server will eventually be taxed more, the application server layer will
need to grow, security issues inherent to maintaining HR data will need
to be addressed, accessibility to the system via Web Application Server
or ITS might need to be considered, and so on.
Meanwhile,
the technical lead begins to work with the computer operations
supervisor to secure technical sandbox or development resources,
reserve testing time, and so on, in preparation for initially testing
the change.
My
customer uses this workflow approach to track changes in progress, too.
Note that the weekly change management meeting ranges in time from an
hour (status update meetings) to perhaps three or four hours (for major
functional or infrastructure changes). This HR scenario would
constitute a half-day meeting, for example.
Like
the best of plans, our plans sometimes change, though. If changes to
the master project schedule are required, the following activities need
to occur:
Establishing new timelines
Reviewing resources again
Identifying and reviewing constraints again
I’m
told that changes to the master project schedule mirror typical IT
project plan changes, including slips due to unforeseen technical
complexities, lack of key resources, scope creep, budget issues, and
lack of ability to appease everyone’s vision of how the change needs to
be tested or implemented. Special considerations and circumstances have
taken their toll on past projects, too, usually related to other
testing or change control projects taking precedence over the change
being discussed.
8. Change Control Tool Sets and Approaches
When
it comes to managing change, we are not alone. Long before SAP projects
consumed so many IT and end-user organizations, we all somehow managed
to implement other enterprise-wide projects. Tools and approaches like
the following have long been accepted by IT project management
professionals:
Embracing formal project planning methodologies and training
Management meetings, held to gain high-level management or team leader consensus
Team meetings, held to obtain status updates and ensure the team was making progress
Communication planning, and the toolkits that facilitate this
Change management training—processes, approaches, best practices, and so on
Training focused on problem-solving techniques
Training focused on assessment/analysis techniques
Business case management approaches, and training supporting this
Leveraging subject matter experts, via internal and external consulting resources
Change management software applications
With
regard to this last item, change management software applications, a
number of these abound specifically for mySAP.com. I seem to run into a
particular company more than any other—Kintana. Their “Kintana
Accelerator for mySAP.com” allows for end-to-end change management,
while also providing visibility into potential problem areas (like
resource constraints, timeline inconsistencies, and so on).
A
good change management tool will also hide unnecessary complexity
(again, to increase visibility into problem areas), and automate much
of the work of managing change. I like Kintana’s product because it is
not limited to managing a specific SAP Solution Stack—various UNIX
flavors, Windows 2000/NT, even mainframe database servers are all
supported. Finally, because Kintana has products for other enterprise
applications like PeopleSoft, Oracle, and Siebel, an investment in
Kintana can really pay off across a mixed enterprise landscape. Read
more about Kintana by visiting their Web site, or leveraging the “LINK
- Kintana Accelerator for mySAP.com” document on the Planning CD.
I
suggest that the capabilities and characteristics outlined in the
following list serve as an evaluation guide for comparing the various
change management toolsets available today. That is, a change
management tool should accomplish the following:
Provide a consistent and repeatable process for managing change across the SAP system landscape
Safeguard the production SAP system from improperly executed or unauthorized changes
Provide audit-trail capabilities of previous changes to the system
Provide the SAP TSO with the information needed to monitor change waves, track priorities and resources, and so on.
Such
an application minimizes unplanned downtime by reducing risks
associated with making changes. And it also shrinks the amount of time
people need to spend in change control meetings!
When
it comes to managing the thousands of table settings and other options
within an SAP client, SAP change management will always present a
challenge to the organization managing it. By its very nature, the
flexibility that end-user organizations love about mySAP.com becomes a
driving factor in terms of the amount of time that is devoted to change
management. Good change management tools will minimize the time by
automating repetitive tasks related to transports, recompiles, system
refreshes, migrations, and similar tasks. Thus, any software tool or
utility that can ease some of this burden should be welcomed and fully
embraced by the SAP technical support organization.
9. Feedback—Improving Change Management Incrementally
When
it comes to improving any process, it is usually helpful afterwards to
ask and try to answer the same questions that drove creating or
updating the process in the first place. This constitutes a feedback
loop when end users and other stakeholders are answering the questions
for us. With regard to the change management process and organization,
then, the following questions are appropriate:
How successful was the change? Were the success criteria drafted at the first change meeting on target or appropriate?
How long after the change did it (or will it) take to stabilize the production system?
Overall,
how disruptive was the change to the business? And what can we learn
from this, to further minimize the impact of changes in the future?
What individual and organizational benefits of the change have been communicated to our stakeholders?
What have end users given up or sacrificed as a result of the change (additional downtime, loss of other functionality)?
What
skills and resources were actually required to implement the change?
That is, how can we better plan for and execute similar changes in the
future?
How well did the change
team/project team understand and execute their roles and
responsibilities during the change process? Where can we improve?
We
have now concluded our discussion on change management best practices
and approaches. In the next section, I take a broader look at exactly
how change impacts not only every layer of the SAP Solution Stack, but
every phase of an SAP implementation as well.
