Better
ways to implement
Select the best
possible
business representatives for your project team
If the rest of the business
is up in arms or scrambling to cover their loss because of the people
appointed to be
on your SAP implementation team, then you most likely have the right
people on your team!
Remember that your business representative will help map SAP to your
business - your whole company is going to feel the effects of that person's
expertise.
Select the most
experienced consultants
If someone has more than 3
full-term implementations under their belt, they are more than likely
solid candidates to support your efforts. You will pay one
way or the other for less-experienced consultants working without guidance on
your implementation.
Partner with your consultants - don't let them run the show
Typically for any project
implementation team a combination of business representatives and
consultants are used. It makes sense at the team-lead and project
management levels that a one-to-one split is employed - each
business manager has one counterpart that guides them through the
implementation plan.
In the end, the implementation is owned by the
business and ownership should be assumed very early on.
Organize your project teams along
the lines of SAP's applications (SD, MM, FI), not by process
SAP supports the integration
of processes, but organizing your team by process (e.g. Order to Cash)
is not necessarily the
best approach to take when initially implementing! The reason is
that it detracts from the individual application-teams focus - e.g a SD
team member can't afford to spend time at weekly meetings discussing
the intricacies of current AR issues. They need to spend productive time
discussing
only the points where SD and AR integrate!
An application-centric team promotes mini "centers of excellence" as well
as more closely knit application teams.
Know how to address integration
If your teams are
application-centric instead of process-centric, then how do you promote integrating them? The
answer is 4-fold:
-
Identify integration points
between applications early (your consultants should know where they are
configured - they're technically defined by sap's design!)
-
Hold integration workshops at
key intervals between relevant pairs of application teams
-
Document integration
relationships as part of the project deliverables
-
Use common master data and master data
templates to define different material and partner types.
Proactively promote team integration
The most effective way to achieve this is
through master data. Human nature is a very special thing:
people tend to get really cozy with the data they have created (besides,
it works great with their configuration). In most cases, the odds
are good that the data doesn't quite work with the rest of the system.
The most convenient is to set up a script or
load file that generates new master records according to master record
type (e.g. packaging material, standard material, group customer, retail
customer). It's tough initially to get these to work on a global
scale, but well worth the effort once successful. Promote their use throughout the project team to
generate 'latest version' master records at the push of a button. If
a transaction doesn't work with a 'skeleton' master record, then there's a
problem!
Don't design your project documentation deliverables
without specific reference to implementation activities
Unless the project documentation
specifically supports a specific activity in a specific
phase of the implementation, you stand the risk of documenting wastefully!
The last thing you can afford is to be rushing to complete a document has
little or nothing to do with the system work you are trying to
complete.
Always build on documentation from previous project phases
If a document was produced
in any phase of a project it should be expanded upon or at least used in
the subsequent project phase. Each successive implementation phase
builds on the previous phase - the documentation should naturally follow suit!
It is
hard to understand how so much time can be devoted to documentation which
is not aligned with project phase activities. There is no question
that documentation is extremely important, but a Spartan (for want of a
better word) and value-add approach to its design omits potentially huge
levels of waste.
|