As long as the application consultants’ limited understanding of your business drive your SAP implementation, it will only reflect their SAP capabilities. If you want more, then your project focus must become business driven rather than vendor and consultant driven.
Frequently I see or hear SAP consultants, even those who claim to be “Platinum” level consultants, who really do not understand the extent of the capabilities of SAP as a business process and systems platform. Even though these Platinum consultants may have many years of experience with SAP, many of them started out in SAP and gained little practical business experience before their SAP careers.
The SAP implementation environment includes several stakeholders: from the developers of the system, to the vendors, to the consultants, the project team, and the ultimate users. Each one of these holds a certain cultural assumption towards the ERP implementation and use process. Particularly, the developers’ and consultants’ cultural assumptions are embedded in the very roots of the software (technology) itself.
Molla, A. and Loukis, I. Success and Failure of ERP Technology Transfer: A Framework for Analysing Congruence of Host and System Cultures, working paper pg. 7, 2005 citing Skok, W. & Legge, M. (2001) Evaluating enterprise resource planning systems using an interpretive approach. Proceedings of the 2001 ACM SIGCPR conference on Computer Personnel Research, San Diego, April, pp.189-197.
Business-Driven Implementations Must Replace System Integrator Driven Implementations
The dynamic of a consulting vendor driven implementation must give way to a business-driven implementation. Many SAP consultants have never been directly responsible for business activities before their SAP exposure. Also, few of them have had to do ongoing business production support work after going live with SAP, so they have little business and user experience to ensure business benefit.
As the SAP licensee, paying for the implementation, you must ensure that you drive the project to stay focused on business results.
You can only have business results if you define the business reasons and drivers for the implementation, and then incorporate them into the Request for Proposal (RFP) process. This way, you set the expectation with a vendor that business needs and business expectations will drive the direction of implementation.
- Throughout the course of the project, periodically revisit the original business drivers for the project.
- Insist that the system integrator provide status reports that address the details of each business driver.
- Incorporate business driver progress into weekly team lead/consultant status reports, or at a minimum monthly steering committee reports.
Requiring the system integrator to constantly address the business drivers reinforces that expectation throughout the project and to the project team. It also more clearly identifies skilled consultants and resources from those on the project that you may need to replace and request a credit from the system integrator for. After all, if they sold and proposed to you on business benefit, and if business benefit (goals, objectives, etc.) are spelled out for your project, then you need to enforce that in your contract and in your project.
A correctly developed business case, RFP, project charter, scope document, system integrator contract (which should include credits for underperforming consultants) and other tools will ensure your project achieves the results you expect. All of these tools serve as opportunities to set the expectation with the consultants, and with the business, that this is a business project for business benefit. A properly done RFP will also ensure that you are getting the best resources for your money from an implementation vendor, as you receive apples to apples proposals and quotes. A solid contract that defines you as the sole determining party for which consultants are performing, and then credit provisions for non-performance, keeps things on track as well.
Barriers to a Successful SAP Project
In 1999, Deloitte Consulting published a piece entitled “ERP’s Second Wave,” which identified several barriers to successful SAP implementations. I have added a designation for whether they fall into the “People, Process, or Technology” areas:
|
ERP Barriers |
Area |
|
Lack of Discipline |
People |
|
Lack of Change Management |
People |
|
Inadequate Training |
People |
|
Poor Reporting Procedures |
Process |
|
Inadequate Process Engineering |
Process |
|
Misplaced Benefit Ownership |
People |
|
Inadequate Internal Staff |
People |
|
Poor Prioritization of Resources |
Process |
|
Poor Software Functionality |
Technical |
|
Inadequate Ongoing Support |
Technical |
|
Poor Business Performance |
Process |
|
Underperforming Project Team |
People |
|
Poor Application Management |
Process |
|
Upgrade Performed Poorly |
People |
Notice that although certain functional barriers may fall within a Process or Technology area, every one of the barriers is either strongly, or completely, influenced by People. You simply cannot ignore the People involved in your project. The level of discipline required with SAP dramatically affects organizational norms directly related to the tolerance for change because of the new processes incorporated throughout the enterprise. Sumner, M. (2000) Risk factors in enterprise-wide/ERP projects (Journal of Information Technology, 15, pp.317-327).
Since implementation vendors such as Deloitte are obviously aware of these barriers to success, why do they continue to repeat them? Worse still, why do customers still allow system integrators to do this?
SAP Project Risks and Risk Mitigation
This list of barriers provides a great starting point for the project risks you may need to address. Right from the beginning of your project, your RFI and RFP system vendor or system integrator evaluation should include an evaluation of these risks. And it can’t stop there. You must be diligent throughout the project to ensure that your project team is ready and able to address your ongoing project needs from a business perspective.
If you are not willing to force your vendor to replace underperforming consultants, then you are implicitly accepting being stolen from. After all, when you consider the annualized rate you are paying for those consultants, why again do you pay for resources who are unable to deliver?
Be sure to review and evaluate these barriers to success throughout your entire SAP implementation and business project.
