SAP is one of the most popular technology in the world today allowing companies to run and manage their end-to-end business processes on one integrated technology platform. SAP NetWeaver allows companies to integrate third party systems and external web applications together with SAP core ECC system(s) there by providing a robust technology infrastructure. This helps enterprises which have already invested in other third party systems to preserve their investment to support their business growth. Now having said all about SAP, you all know that any SAP transformation project is a huge undertaking and every customer wants to put maximum effort and dedicated workforce to make the implementation successful.
Today I would like to emphasize on some best practices all SAP customers may want to consider to minimize any risks and ensure success of your IT transformation project. Every company has different business needs to meet their corporate growth strategy which makes each SAP project unique in its own way and I will share some best practices on a very high level that your SAP project leadership can use to their advantage to ensure sap partner that their SAP project is setup for success.
So how does a IT Transformation project begin? Typically, An IT strategy to support a company’s short term and long term business growth is established by the C-level executive leadership (mostly by CEO, CIO, CFO, Vice Presidents of business and IT / Systems). Once the IT strategy is defined and approved, an executive steering committee is formed with some of the above executives and key leadership people representing the business. The project is then officially kicked off into planning, preparation, blueprint, functional design, technical design & build, test, deploy, go-live and maintenance phases. There are different best practices or actions I recommend depending on the client and project circumstances. It may not be practically possible to cover best practices for all scenarios in this article. But, I will make an attempt to cover the best practices and proactive measures at a macro level that should be followed during each of the implementation phases to minimize risks and avoid any unforeseen challenges to budget and go-live dates.
In part 1, I will discuss best practices for SAP project planning phase which includes business readiness, technology (and SAP modules/packages) selection, selection of SAP implementation partner (also known as SAP Systems Integrator) and finally the project preparation phase. Part 2 and 3 will cover the remainder phases of your SAP project.
Early on in this phase, the steering committee should meet and establish the initial composition of project leadership that should include a program sponsor, business lead and IT lead who are part of your business today and shall continue to lead the IT strategy of the company going forward.
Business Readiness (Define Goals, Scope & Engagement Model)
In the planning phase, initially the project leadership should meet with key stakeholders and define their department objectives that should be met by the SAP project. For example, if the new transformation project includes a new business initiative or significant enhancements to existing business processes, then time to go-live will be a major factor. Is the go-live timeframe aligning with the time when you are planning to launch the new business initiative? Next thing I will recommend is to prioritize the important project factors such as schedule, budget, and quality so that these constraints can be clearly articulated during the vendor selection process. Also, define the high level scope of the project into 3 distinct categories for each business work stream such as ‘High’, ‘Medium’ and ‘Low’ priority. Also, business stakeholders and leadership needs to identify scope items that can be eliminated if the project budget and schedule is challenged. To the minimum it would be good to have a PMO process in place to de-scope any of the items when time or budget is challenged.
During this phase the project leadership team should review the scope of the project and decide on the engagement model with the software implementation vendor. Typically you can choose between a ‘Fixed Fee’ or ‘Time & Materials’ engagement model. Fixed Fee model means the vendor has to implement the whole project or each phase of the project for a fixed price. With Fixed Fee model, you as a customer need to define your scope clearly so that you can include it in the statement of work. Fixed fee will also mean that you will be typically charged in most cases about 20% surcharge by systems integrator to cover the risk to deliver the project on a scope that was mutually agreed upon at a fixed price. The drawback with this approach is sometimes there is a potential for quality of deliverables to be impacted in the process of delivering solution as quickly as possible within the predefined budget. A change control board should be established and protocol for handling change requests should be defined. It is advisable to do quality reviews on deliverables and overall implementation to ensure that solution delivered is of high quality. The other engagement model is ‘Time & Materials’ wherein the customer is paying for resources on time and material basis. Project management office (PMO) has to monitor the project budget with respect to progress on deliverables very closely to ensure that project is delivered within the budget. It is easy to add scope and resources to meet deadlines thereby overshooting the planned budget. With this model I will recommend an additional third party or in-house SAP project manager (apart from SI project and/or delivery manager) to ensure project delivery in time and budget. Estimates and re-estimates should be done in a timely manner at appropriate milestones within each phase when using this model. If the SAP implementation project is complex and scope is not clearly known then this may be a better option. Now, in this phase you should analyze all the pros and cons of both of these models and pick one that suits the best for your business.
Usually planning phase can last between few weeks to a few months and if you have business team members already identified for the implementation, you can engage them in defining the future state business requirements. This would help accelerate the business requirements gathering phase and creation of BPRDs during the blueprint.
In this article an assumption is made that you have already made a decision to go with SAP, but nevertheless not all projects go with a presumed technology of choice. In very brief, if your company needs to select a technology to support your IT growth strategy there are several factors that need to be taken into account such as the following:
- Scalability of the technology platform
- Ability to support the long term business growth in terms of functionality, data volume, performance, etc.
- Robust integration capabilities with internal and external systems
- SOA (Service Oriented Architecture) capabilities
- Ability to enhance the system in-house after go-live with minimal or no support from the product development team from the technology vendor
- Business functionality fit with SAP standard modules such as FI-CO, SD, MM, IS Solutions, BI, PI, etc.
Choosing a Systems Integrator (or SAP Implementation Partner)
Once you have selected SAP as your technology platform, the next step in the process is to identify potential SAP implementation partners with the help of a program advisor or SAP America. Invite potential vendor sales executives and supporting teams for a pre-planning workshops to orient vendors with objectives and high level business requirements of the project. Invite proposals from each of these vendor companies followed by formal onsite review of each proposal. Onsite review should include formal presentation on how the vendor plans to deliver the solution using an implementation methodology of their choice and also demonstration of vendor’s resource expertise in the SAP modules that need to be implemented. I would recommend selecting minimum of at least two vendors through this process to move onto bid invitations and further negotiations. Let’s refer to these vendors that are selected to bid as ‘Prospective Systems Integrator or Prospective SI’. In order to get the most competitive project bids, you need to negotiate project bids between at least two companies to arrive at a competitive bid. But bear in mind that vendor prior implementation experience and in-house SAP modules expertise should be competitive before deciding to negotiate the bids.
A formal vendor evaluation sheet should be prepared to select a prospective systems integrator. The project leadership should divide and conquer to do each vendor research and fill the evaluation sheet to cover the following aspects. First, we need to evaluate whether the prospective systems integrator (referred to as ‘SI’) has successfully delivered a similar project (same industry, solution and size) in the past and check for client references. Also check if the prospective SI has delivered the project within the estimated budget. If the budget was exceeded it would be nice to know by what percentage the budget was exceeded and reasons for the same. Check if there are enough SAP skilled resources with the SI in each SAP module that need to be implemented by conducting a few SAP architect and senior consultant interviews. In most projects, offshore delivery capabilities play a major role. If this applies to your project then analyze the offshore presence and check for effectiveness & productivity of the offshore team on a past project. Are you planning to have a SAP ‘Center of Excellence’ within your company to support the SAP system post go-live? If there is no COE or the staffing within the COE is limited, you might want to check if the systems integrator has a production support and maintenance capabilities onsite / offshore to support the production environment 24 X 7.
Depending on the implementation methodology, this phase may resemble to the one prior to blueprint phase. If the systems integrator is running the PMO and overall project, ensure that all project and team (or work stream) charters are defined during this phase. Each charter should clearly define the scope of the project or the relevant work stream, identify key stakeholders and define the key roles of participants. To the minimum I would recommend a charter for each of the following that should be prepared and signed off by the SAP project leadership.
- Overall project charter
- Overall business team (and individual business work stream in case of large projects)
- Organizational Change Management charter
- Integration team charter (includes legacy / external apps, PI & ECC integration)
- Technical Architecture Charter (SAP Systems Architecture)
- Application Development Charter (covering RICEF + W )
- Legacy Systems Charter (Only if legacy or 3rd party external applications are significantly enhanced to support a new business model or integrate with SAP ECC system )
- SOA Charter (Although this may be integrated in parts within business and integration charters, I strongly recommend a separate charter with an architecture team to lead SOA if your business has a heavy emphasis on Service Oriented Architecture. Having a separate charter for SOA has heavily benefited my past projects to have robust, non-redundant and efficient enterprise services.)
The next point I would like to emphasize is very critical especially if you are using a SAP implementation partner (or Systems Integrator – SI) to prime your project. You should interview and select the SI leadership including the client partner and executive leadership from the systems integrator. Having a proven and knowledgeable leader with the SAP technology and business both together is the very critical to the success of the project. In general, I would not recommend two or more people in the senior leadership of the SI with some representing SAP technology and others representing business expertise. It is merely because these individuals may come from separate departments or groups within the SI organization and there may be a potential conflict of interest between these groups. Even if you do hire two or more senior executives from the SI, then I would recommend having an independent project advisor for your project to ensure that your project goals and solution delivery milestones are not compromised.
Sometime the initial bid from the systems integrator may include project end-to-end initial estimates. If not, then make sure that estimates are done for the entire project supported by a staffing model. Again, as pointed above there will be a few milestones in your project when re-estimations will be done followed by adjustments to the staffing model. Based on this staffing model, I would suggest interviewing and selecting all other SI key personnel like the project manager, OCM lead, RICEF lead, PI lead, BI lead, SAP Basis or technical architecture lead and SAP functional leads for each work stream. Architects and other SAP consultants for both functional and technical work streams can be selected during blueprint as per planned start dates as determined by the staffing model. If you have a systems integrator other than SAP, then I would say it is nice to have at least an architect (senior SAP consultant) from SAP America on the project to seek SAP functional expertise and also to leverage any SAP solution assistance from SAP experts and core development.