SAP Basis
A few terms to help the uninitiated:-
* SAP - World class, highly integrated business system processes and software used by many of the world's largest and medium sized businesses.
* APO - 'Advanced Planner and Optimiser', SAP's primary module aimed at supply chain planning, now changed its name/morphed into SCM 'Supply Chain Management'.
* PP & PP-PI - SAP's modules that deal with the business processes around manufacturing and supply operations. PP is essentially a production job model responding to customer orders, whereas PP-PI is aimed at continuous production models - most factory scenarios.
My Background
Having spent 7 years understanding and implementing SAP APO supply chain planning systems and the 7 years before that understanding and implementing SAP for manufacturing operations, I've learnt a thing or two along the way about what this SAP thing is all about.
Why go SAP Company-wide?
Most companies that have moved toSAP Basis have had huge learnings along the way. SAP is usually bought by the boardroom and not, as was previously the case, on the back of the CIO recommending a technical solution to support that business's current and perceived future needs. The case for buying SAP now is probably stronger than it was but it is essentially:-
* High level of integration between business processes
* Coverage of most business scenarios
* With the SAP model now well established and third party companies providing services that fit into the SAP model this brings
o Opportunities for outsourcing almost anything, not even core processes are sacrosanct
o Following the crowd and aligning with a standard SAP IT infrastructural model should bring stability and predictability for costs and resource requirements
Is that a real assessment?
It is becoming more real as time goes on but Companies need to understand how to use SAP or more importantly how not to use SAP!
SAP is highly configurable and parameterised and its standard software modules, that carry out specific functions, are not only modifiable by configuration but also by lots of open back doors where a 'user-exit' alters how that piece of software works. A user-exit is just that, it exits from the standard code to do something else, specific to your business.
There are now many ways of going away from the SAP straight and narrow and adapting SAP to be something more like your business scenario. All of this adapting, all of this configuration, costs money and is likely to have to be redone when you find you need to upgrade to the latest version of SAP. You have to upgrade because the software won't be supported for ever so its not really a choice beyond whether you upgrade this year or next and SAP consultancy skills don't come cheaply. In a 'normal market' there is a high level of competition for the right skills, particularly in the more esoteric or niche areas of SAP such as APO.
What does SAP really mean to a company?
To get the benefits of SAP and to prevent it costing a fortune, companies are best advised to change their business processes to fit with one of SAP's standard scenarios. The company benefits in doing this because it provides an opportunity to have a good spring clean throughout and get rid of herds of sacred cows that are usually grazing on the fat of the company and maybe bleeding it dry!
So to go SAP, you do these things (Prince-2 models work well):-
* Start up the project
o Pull together a start-up programme team
o Identify stakeholders
o Assess the organisational and budget requirements for implementation
o Gain approval
* Initiate the project within the organisation
o Build programme team size - develop its strength (training)
o Education - make the case to all the stakeholders (employees, shareholders etc).
* Build the technical teams skills, those who will:-
o build the SAP server system environments,
o provide network infrastructures throughout the organisation
o understand the SAP engine and safeguard from spurious development changes
* Build process development teams
o Pull teams of business people together as full-time development teams
o Align teams with SAP's model, eg. in process manufacturing, there is an end to end process starting with planning thro' purchasing, manufacturing, ending with stock.
o Develop team knowledge in SAP and in their company's processes
o Map the processes 'AS-IS' and 'TO-BE' , identifying 'GAPS'
o Gaps are potential SAP modifications and potential sacred cows. So gaps need to be fought out at top level with external input to challenge the way it has always been.
o Establish master data standards
o Collect master data and establish mechanisms to keep this up to date
o Education - keep the message flow going to the stakeholders
o Play with SAP, first as small close models and building up to large scale integrated models to learn about SAP and your business processes and identify what's missing.
* Build implementation teams
o Rerun the training and finding out steps with the larger teams to output:-
+ many more people understanding the proposed business processes, SAP functionality and how to apply it to the specific scenarios they will be working in.
+ Document manuals for all process areas and quick reference cards for the system
o Gain commitment from the management layers that some of those involved will continue to support these processes post go-live.
o Pass on training to the end users using real data in a test environment
There can be an unrealistic tendency to think that once SAP is in, the job is done and the company can reduce its IT support numbers, and the organisation will just get on with life. Sadly, it isn't unheard of for companies to implement SAP, only to rip it out again months later because their processes are in chaos. It also isn't unheard of for a good implementation and support structure to be undermined later by cutting support resources because 'it seems to be running fine'.
SAP Basis isn't a turnkey system with no maintenance needs. It mirrors the business and just as the business needs to deal with new products, waste materials and shred its old order sheets and invoices after time, the same needs to happen inside SAP.
Whilst the project team sizes can shrink considerably after implementation, you are best advised to maintain a core of specialists who can look after their functional areas, understand the implications of upgrades and be in touch with the user community. The latter will need a good network of SAP supporters, Super Users; people doing regular functional jobs who have the aptitude to both understand their bit of the system and be able to relate it to their colleagues. They will need coordination too, otherwise you have a heard of cats on your hands!
How do you make all this happen?
You need good quality Business Analysts, some can be found within your organisation and a healthy dose of experience from seasoned SAP campaigners, specifically for Basis (SAP engine and techie sorts), Module Implementation consultants (for the specific modules such as FI, PP, MM, PM, APO etc) and Programme Office Management.