- 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.
Read more on SAP Business One Interview Questions
- 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.
More information SAP Business One Questions And Answers
- 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.
Everyone has heard the horror stories of cost overruns on SAP programmes. While there are a few factors which are outside the control of the programme managers (e.g. business change, funding withdrawn) the majority of the responsibility lies at their door.
From the programme managers viewpoint it is essential to get early warning that things are starting to slip. One of the quickest way to lose your job is to surprise your board 4 weeks from go-live with the message that the programme is 6 months late.
One of the best ways to get this early warning is through implementing a gate methodology which forces a structured review of the programme at pre-defined checkpoints along the way. In essence you build gates at the exit points of the major phases of the programme. Naturally these are also the entrance points to the next major phase.
Let's assume that you have five major phases as follows: Scope & Plan, Design, Build, Test, Go-Live. You would then have five major gates as well - each positioned at the exit point of the five phases: Gate 1 - Exit Scope & Plan, Gate 2 - Exit Design, Gate 3 - Exit Build, Gate 4 - Exit Test and Gate 5 - Go-Live. Potential criteria for each of these gates could be as follows:
Gate 1 - Exit Scope & Plan
- Is there a scope document, and does it cover all aspects of scope including functionality requirements, modules to be implemented, geography, gaps, interfaces, organisational aspects, technical aspects, data conversion etc
- Is there a plan, and does it include detailed tasks (nothing longer than two weeks), with resource names mapped to tasks, and is it resource balanced (no simple task)
- Is the design team mobilised
- Is there a design authority in place, and is the change control process agreed
- Is the sandbox SAP system ready, and is there a client strategy document agreed
Gate 2 - Exit Design
- Has the design been documented, including SAP transactions identified, and signed off by the business. A design walkthrough is strongly recommended.
- Have critical areas of the design (depending on your business) been prototyped in the sandbox
- Have all gaps and interfaces been identified, specified and estimated
- Has the data required been identified and mapped to legacy (ignore this at your peril), and have the data conversion programmes been identified and specified at a high level
- Have the roles required been identified
- Have control requirements been identified
- Has the plan been updated, and (if necessary) the scope document updated
Read more on SAP Business One PDF Books
Gate 3 - Exit Build
- Has the system been fully built and unit tested in the development system (not the sandbox), and signed off by the business. A config walkthrough is strongly recommended.
- Have the gaps and interfaces been fully built and unit tested (this is a grey area)
- Have the data conversion programmes been built and unit tested (this is not a grey area)
- Has the system gone through any scenario-based validation (a step up from unit testing). It is probably best to include this in the Design phase since you cannot be fully satisfied your requirements have been met until you run business scenarios through the system.
- Has the configuration been fully documented, and the design documentation updated (if necessary)
- Have the roles been built
- Have the control requirements been built
- Has the plan been updated, and (if necessary) the scope document updated
Gate 4 - Exit Test
- Has the system been fully tested in the test system (not the development system), and signed off by the business. A test walkthrough is strongly recommended.
- Have the gaps, interfaces and data conversion programmes been fully tested and signed off
- Have the user procedures been documented and tested
- Has the training material been completed and tested
- Has the system been tested by running converted data through it (warning: expect to do this four or five times before it works properly)
- Have all critical test problems been resolved.
Gate 5 - Go-Live (done a few days prior to go-live)
- Have the users been trained
- Are the user procedures in place
- Is the user documentation in place
- Did the data conversion work
- Is the support team in place
- Is your 'cutover control room' ready, manned 24 hrs, and have detailed cutover plans in place (this might have started already for the data conversion)
- Have you done a trial cutover
- Do you have a contingency plan
- Everyone feeling well rested? Then push the button!
Find more information SAP Business OneDownload attached file:
You must be Loged in to download file