|
New Page 1
|
- Match the program objectives with the business objectives.
Don’t allow a situation where the programs’ objectives
are different to the companies business objectives. For example,
if the business is decentralized, be careful about centralizing
your program. If your company is organized by country, be
careful about implementing by process etc
- Match the program culture with the business culture
Don’t allow a situation where the programs culture is
different to the companies culture. For example, if the business
culture is one of delegated responsibility, be careful about
using a "command and control" centralizing your
program.
- Match the program organization with the business organization
Don’t allow a situation where the programs organization is
different to the companies organization. For example, if the
company is organized by country, be careful about organizing
your program by process. Your program team structure should be
an overlay on the company organization structure.
- Define key objectives, benefits and expectations before you
start
Although difficult to do, a list of high level program
objectives for the year will help focus your team.
Ensure you have top-level management buy in
All programs need top-level management buy in. Just how high
you need to go depends on the cost and impact of the program.
Most large SAP implementations probably require buy in from the
Chairman down. The key objectives, benefits and expectations you
prepared in number 4 will help elicit the expectations from
top-level management as well.
Create a Change Management Team
Create a change management team. Spend the money - it’s
worth it. Your new system is no good if it is not used properly.
If you are contravening (or being asked to contravene) numbers
1, 2, 3 or 4, then this becomes especially critical. Remember
that change management is more than training and glossy
brochures.
Create an Integration Team
If your program spans multiple modules, organizations or
process areas, create an integration team to bridge the gap.
Give them responsibility for the pro-active identification of
integration points/issues between the teams, and also give them
the responsibility for helping the teams resolve the design
issues.
Pick your best and brightest
Demand the best and brightest for the program. Given the
impact most SAP implementations have on the organization, this
makes sense. If you don’t get the best and brightest, plan on
over-running your time and budget.
Build a milestone-based program wide plan, publish it widely,
and stick to it
This is no easy task, but if you can’t do it, then you need
to ask why. Once it is built, stick to it. Examples of good
milestones include Scope Freeze, Design Walkthrough, Prototype
Walkthrough, Configuration Freeze and Development (ABAP) Freeze.
Do not, for example, let scope change (without a real good
reason) during design, or let configuration change during
testing.
Use rapid prototyping methods
It does not take long to build a prototype of a major process
in SAP. Creating a culture of rapid, iterative prototyping
within your team(s) will save you time and money as the users
get to see results early – when changes are less expensive to
accommodate.
Don’t change the source code
Don’t. Just don’t. You’ll be sorry you did. You’ll be
surprised at how fast SAP moves, and you can’t afford to fall
behind on the upgrades.
Plan for post-implementation before you get there
Until you actually get there, the implementation or go-live
seems like the ultimate objective for the program. Once you’re
past go-live, however, you’ll realize that the go-live isn’t
the end, it’s not even the beginning of the end … it’s
actually nothing more than the end of the beginning. This is
when you will reap the rewards of number 6 (or not).
Develop retention plans for your key people before the end of
the program
One of the key post-implementation factors will be the
retention of your key people (who have, by the way, suddenly
become much more marketable). Many companies have suffered as a
result of an exodus of key people at the end of a program. More
often than not, and carefully thought out retention plan –
complete with roles and career path expectations – will
eliminate (or at least delay) this disaster-waiting-to-happen.
Use consultants wisely
Consultants can be critical to the success of your program,
but they can be expensive. Use of them depends on your company
culture (consultant friendly or not), your skills gaps and the
level of risk associated with program failure. It should not
necessarily depend on your budget – as there are times when a
company cannot afford not to hire consultants.
Have SAP involved from the start
Depending on the size of your company and program, you will
receive different levels of attention from SAP. The earlier you
get them involved in your program, the better. If nothing else,
their internal lines of communication will save you time.
Continue the 'manager'
Article Tour (2 of
5)

|
New Page 1
|