While the general perception is that any IT project (& especially SAP) always overruns schedule as well as budget, there are certain learnings I would like to share with you customers/prospects, which should make you aware of the potential red-flags to take corrective actions (or best, preempt and plan for it) and thereby stick closest possible to the project plan / budget.
Even though problems/red-flags vary from project to project, like unique thumb prints (& no way I’m listing all of them), I would like to address the mother of all SAP projects and that is:
SAP Implementation Projects /Rollouts -
End-to-End Implementation is every SAP consultant’s dream and ..every customer’s nightmare!
Risks involved are just huge. Here are some pointers:
1. Choice of Implementation partner– This is a decider. This also doesn’t mean that you have to necessarily go for Tier-one vendor as a risk-mitigation measure. Besides the usual capability-check (which all customers do without fail), the other key thing is to find out the fitment between the vendor & your business-users. (Simple question – Can the vendor resources speak your business-users’ language (besides talking usual jargon)? And here, I just don’t mean knowledge of a particular language but overall fitment. Since SAP implementation (& especially Requirement Gathering aka Business Blueprint) involves vigorous interaction with business users, ignore this point at your own peril.
2. Implementation team– You must assess each & every vendor resource (or, especially Lead roles and or critical roles, if the project size is huge) to find out his/her credentials, breadth & depth of respective module’s knowledge & relevant domain experience. The consultant needs to understand not only your business processes but also should know mapping them in SAP. And remember, there are consultants who are glib talkers but struggle in configuring processes in SAP and then there are consultants who can configure almost any process in SAP but can’t open their mouth! Ideal SAP resource is having a blend of both!! (To be realistic – look for closest possible balance). Pay special attention while choosing Project Manager. See the project team (in terms of size & skills) is commensurate with the scope. If any ramp-up / spike is needed for any rollout wave or any particular phase (like Realization), plan for it in advance. If there is any offsite/offshore component (and it has to be minimal & something which needs less/no user interaction), get the clarity beforehand.
3. Team work– You should be taking due care in choosing your own team (business leads who would be involved extensively along with the vendor resources, like, current role they’re playing, what role/additional responsibility they would be shouldering post-Go-Live & can they explain the business processes properly). See that your team is sufficiently empowered to take business decisions / provide inputs. (In plain words – they should not go to CFO or Business-heads for every small inputs /decision, causing delay to project timelines). Also, both teams need to gel and work as one team. Otherwise the issues of non-cooperation, delayed/no responses & distrust could snowball into major escalation impacting project timelines. Team-building exercises, weekend picnics etc. go a long way in building the camaraderie.
Remember, a SAP Implementation Project is like a juggernaut! Let it roll smoothly and in intended direction.
4. Scope creep - Here the golden rule is to follow a frozen/signed-off Business Blueprint like a Bible & avoid any other changes (which are deviations from the agreed scope – amounting to Change Request). Besides the known risks of project timelines getting impacted and budget over-run, by every user-exit you’re increasing the maintenance overheads and also increasing the complexity of future technical upgrades. Notwithstanding SAP is a very comprehensive ERP software & that it allows changes/customization, you need to draw a line somewhere (& stick to it) else, as they say in jest, your SAP becomes ‘Z-SAP’!
5. Change Management– Accept it. All of us don’t like change. (Just think of changing your iPhone for Android or vice-versa J ) Users, who are used to working on a particular software day in, day out for years, are bound to feel anxious while moving to SAP (& add to that, the unspoken fear of retrenchment, due to process automation/optimization/redundancy) So, may it be fear of learning (or any other), it needs to be addressed duly, much before the Go-Live. No matter how best SAP is implemented, if the users are not using it properly or not using it at all, it is a Failure you can’t afford!
6. Master template- This is applicable only for roll-outs. You need to design and agree on the master template (also called as global template) which would be rolled out globally. Here the key is, to follow template to 70% to 80% and allow country-specific localization (besides the mandatory statutory requirements of tax, financial statements etc.) to max 30%. The rollout waves (timelines/sequence/dependency) need to be planned & the core-team (from each country) needs to be identified to make it a success
7. Legacy Data Migration– In plain words, getting your current data (master data & transactions) into SAP. But it is never as easy as it appears. No wonder, I’ve seen many projects getting delayed in the last and most crucial lap of the implementation cycle. The issues of duplicate master records (e.g. same customer existing under 5 different codes!), inactive masters, the monster material master data (& how each field will be mapped in SAP), how many of years of transactions do we really need, are some of the nagging questions which organizations need to address. If the project size & complexity is huge, formation of a separate task force for data migration, right in the early stage of project would accord due focus to this topic. Organizations need to address the issues of data duplication / data clean up / data validation (in other words, ‘data massaging’) else if such data is migrated to SAP, it becomes a case of ‘garbage in, garbage out’. Vendor team needs to provide a detail migration plan showing how they will upload various masters/transaction, using which method/technology, in which sequence, cutover date etc. To iron out all the issues, a mock run of data migration is a must.
8. Documentation – Unless properly planned, knowledge resides mostly (& only) in the heads of individuals (vendor resources and or business teams) or in their notebook PCs. So, when these individuals leave, you’re in trouble. (Keep aside the data confidentiality issues, I’m talking of basic documentation related to project). You also understand the severity of this issue especially when new vendor is on-boarded (say, post-Go-Live) & knowledge-transition is planned.
Here are some best practices to tackle this:
- Designate someone as Documentation Lead. His brief will be simple, ensure due documentation of every process, in every phase of the project. Plan for his backup resource too.
- Store it on a shared drive / network / cloud with due access mechanism.
- If the project is huge (thumb rule – If the number of SAP users is more than 300 it is a BIG project) , choose a good documentation management tool and ensure it is used
- Ensure vendor team is documenting & storing it on the designated place
- v. Plan one Documentation Audit to find out the gaps
- vi. As a bare minimum, a SAP implementation project’s repository should include following documents (names may differ but essence would remain) :
- Project Charter
- Project Plan
- Business Blueprint
- Business Process Procedure
- Test cases (Unit testing / Integration testing / User Acceptance testing / regression testing (if relevant)
- Data Migration plan
- List of custom objects with one-liner description
- Functional specifications
- Technical specifications
- User roles (authorization matrix)
- SAP Patches / OSS Notes implemented (when & why)
9. Project Governance – You need someone (from your side) to work closely with the vendor team, to monitor progress almost on a daily basis, to look for the chinks / red-flags at every stage, in short - to follow what has been covered in earlier points. Considering the criticality, business impact & the budget, very often SAP projects are seen to be driven by CFOs (& not CIOs). In either case, ensure the right senior stakeholders are involved in the Project Steering Committee. Ego management is one more delicate task you need to handle adroitly. Ensure the Steering Committee meets at preplanned intervals & issues are tabled/addressed.
Good Luck to join the ever-growing fraternity of ‘Happy SAP Customers’!!!