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!
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
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
only the points where SD and AR integrate!
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:
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
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!
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.