Tips & Tricks: Project Implementation

 

Home
Up
Are you losing out?
Upgrading SAP
SAP Truths
Good Ideas Dept.
Mission
Search
Site Map
Contact / Resume

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.