Best Practices and Measures for Championing Your SAP Business Transformation Project towards Success

   SAP is a robust technology platform that allow seamless integration of all your internal business functions and taking your external constituents business experience to next level. These transformations can bring significant benefits to your organization by boosting your profitability and also serving as a catalyst in improving your overall market position. Typically these initiatives involve deployment of best in class solutions, optimization of internal business operations and technology innovations to enrich customer experience. A well implemented program on SAP platform can provide full operational and financial visibility to measure the performance of your organization thus enabling corporate leaders to calibrate people, processes and technology to achieve business goals.

These transformations can be very powerful and corporate leaders can take extra measures to ensure that these huge undertaking is successful so that you can achieve goals that were initially established. However, these business transformations could go horribly wrong leading to severe financial losses, drain on corporate resources and loss of trust from your customers. Typically these program failures are attributed to poor quality of implementation and lack of business engagement by IT vendor at various stages of the program. Sometimes even engaging Big 4 consulting companies does not guarantee success as many of the popular failed IT projects that have been in the news recently are attributed to the big 4 consulting firms. These companies can bring discipline and structure to the program but need to be carefully managed throughout the duration of the program to ensure they are delivering what is required to set a high quality benchmark for the future phases of your program.

   In early 2013, I was approached by an EVP of a fortune 500 company who was also the executive sponsor of their transformation program which was struggling with many challenges. Their program was about to exit the blueprint phase and business stakeholders were concerned for not knowing the details of the future state. The business leaders were skeptical if the IT vendor was leading them on a correct path. This white paper summarizes the guidance that I gave them and since then with many other companies that approached my firm. The measures and best practices discussed in this article are independent of the methodology followed by your IT vendor and should be applicable to every single business transformation initiative. Many a times we hear top IT systems integrators telling our clients that their methodology does not allow compliance to some of these measures but I strongly encourage business leaders owning these transformations to enforce these protocols. If your organization needs assistance and guidance in these areas then I recommend that you engage a good transformation advisor for your program.

This article we will stay at a very high level to provide a quick snapshot of best practices to leaders undergoing large transformations. Remember that every business and IT transformation is unique and need additional measures to be introduced during the program execution phases. However for these are some of the key measures you need to consider to ensure your IT vendor is delivering a high quality product during each of the phases of the implementation.

Planning

   A well run transformation program requires good vision and planning. Executive board of the company needs to be clear on the goals for the program and translate these goals into quantifiable objectives. In planning phase it is crucial that you benchmark your program with a compelling business case and scope.

Recommendations for Planning Phase:

• Solid business case for the program is developed which include tangible business, operational and technology driven benefits as outcome from the transformation.
• Clear defined scope for the program. Each business function (Ex. Sales, HR, Supply Chain, Distribution, Finance, etc) has produced a scope document with list of all business scenarios that are important to operate your day-to-day business. It is important that you not only identify the common scenarios but also the exceptions and the way these are handled today. The way these processes work in future state could be different but identifying these business scenarios upfront in planning phase will ensure that you are able to run your business after cutover.
• Scope and business case should include enhancements of existing processes and new solutions to be deployed in order to eliminate your current pain points. Think about the way you can invest in new solutions like cloud computing, SAP HANA, etc to enrich your customer experience. Evaluate your market competition and consider adding initiatives to the scope that will help you stay ahead of your competitors.
• Project charter should be finalized and includes program governance, program success criteria, budget,timeline and operating structure.

• Business case approved by executive committee
• Project Charter complete and signed off by the Executive Sponsor and Advisory Board
• IT vendor selection confirmed and approved by executive committee
• Business case, scope, budget, timeline and deliverables approved by Executive Sponsor and included in IT vendor’s Statement of Work.

Blueprint

   Blueprint or the design phase is the foundation for your transformation program. Over 90% of transformation program failures are result of poor quality blueprint where business was not adequately engaged and lack of clarity on future state system and capabilities before exiting blueprint.

Recommendations for Blueprint Phase:

• BPD (Business Process Design) documents are produced by your IT vendor for each business scenario in scope. This document should include mapping of Level 1 to Level 5 process flows and each business requirement mapped to these process steps. Your vendor SAP functional consultants should conduct a thorough stepwise to-be process flow review as a prerequisite. For greenfield SAP programs, the to-be process flows can be conceptual but for global template or standardized SAP module deployment this walk through should be conducted in a SAP Sandbox or if available an QA system.
• Additionally in blueprint, detailed business requirements should be produced and added to the HLR scenarios document. A requirement traceability matrix should be created that maps each business requirement to at least one business process flow. These flows should then be mapped to standard solution or a gap followed by link to at least one UAT scenario. This approach will ascertain if each of your business requirement is tested in User Acceptance Testing by at least one UAT scenario.
• Fit-Gap Analysis – All BPD documents should include fit-gap analysis for each process step against standard SAP solution being deployed. All gaps should have high level solution direction that will serve as the starting point for functional design of these gap in the build phase.
• Solution Inventory – This deliverable should include summary of all configuration objects and gaps in SAP that were identified during the blueprint phase.
• Integrated Solution Architecture document should be created by the Solution Architect from your IT vendor. This document should show layout of SAP system with modules being deployed along with external systems that will be integrated with the new SAP platform. All changes to standard SAP software specific to the project should be well documented in this blueprint phase deliverable and further updated in build phase.

• All BPDs are reviewed and signed off by Business Leads for each business function
• Solution Inventory approved and signed off by IT program lead and approved by Advisory Board
• Solution Architecture reviewed and approved by IT Program Lead
• Build plan and IT/Business resource requirements reviewed with confirmed commitment from all key stakeholders
• All change requests reviewed by Change Control Review Board with documented outcome
• Build milestones and quality gates approved by Project Board
• Final signoff by the Executive Sponsor to exit the blueprint phase based on recommendation from Advisory Board.

Build Phase

   Initially in build phase, IT architects, technical and functional consultants will configure, design and build the to-be SAP solution. However, this phase is not only about build and IT. Early in build phase the business and data migration team should start assessing the quality of data in legacy systems and also verify the migration tools along with strategy. Another important task for business SMEs and key users is to define comprehensive stepwise UAT scenarios that should include standalone tests within each business function as well as end-to-end scenarios.

Recommendations for Build Phase:

• All functional and technical design documents for gaps identified during the blueprint in the standard SAP solution should be reviewed by IT Solution Architect and approved by IT leadership.
• Configuration Rationale and Master Data Design documents should be created for each configuration set and master data entity respectively. These deliverables should be reviewed by Solution Architect and business content (if any) should be signed off by business functional leads.
• Data Migration lead should drive the extraction and cleansing of data in the legacy systems. The DM lead should drive preliminary review and approval of cleansed data from business data owners.
• At least two cycles of data migration simulation runs should be conducted. These simulation cycles should be an iterative process until 95-98% data accuracy with data load is achieved. Each cycle should involve validation of post migrated data in QA system by business stakeholders with signoff from Data Migration lead. About 2-5% data should be used for each of these cycles to allow enough sampling but also ensuring that you have sufficient data for future cycles.
• Each business function should document UAT scripts covering all business scenarios defined in the scoping phase of the project. Each scenario and business requirement should be covered by at least one UAT test script. Documentation should be stepwise with expected results for each step. Business Functional Lead should review and signoff all UAT scripts for completeness and accuracy. They should also validate that these UAT scripts cover all common scenarios along with variations, exceptions and negative tests.
• Internal auditors should review all UAT scenarios and confirm that all necessary IT general controls are included in these scripts. Also auditors and process owners need to confirm that all applicable compliance checks (eg. Sarbanes- Oxley) are included in the UAT scripts where necessary. In addition, IT Security Lead should signoff confirming all user roles and authorizations are properly setup with no conflicts in segregation of duties.
• Business Migration Strategy draft should be prepared and reviewed by all business stakeholders in build phase. This deliverables can be finalized and signed off about 4-6 weeks before entering final preparation phase.
• Integrated cutover strategy draft should be reviewed with all cutover stakeholders before exiting the build phase. Cutover strategy should include detailed cutover tasks showing interdependencies between cutover activities with an owner against each cutover task.
• GoLive success markers provided in the project business case should be reviewed with the business key users in conjunction with KPIs, benchmarks. Tools and reports to be used after cutover to measure these KPIs should be reviewed with business SMEs and confirmed by Business Functional Lead.
• End user training plan and documentation should be produced by IT vendor in collaboration with business SME. These training documents should be approved by each business functional lead.
• Org Change Management Strategy draft should be reviewed with business stakeholders along with internal stakeholders that interact with external constituents in order to understand the impact on external community. This document should include all change impacts to processes, internal operations, people and external constituents including customers, suppliers, business partners, affiliates, distributors and other third parties. It is important that change impact is reviewed early with all the above stakeholders so that any necessary calibration to the program can be considered before exiting build phase.
• A full suite of regression tests should be executed once the build is complete for Global Template or standard SAP module(s) deployment to confirm that any modifications to the template core system processes did not break existing standard template functionality. IT Project Manager should signoff indicating successful completion of regression tests. Regression testing should be ideally completed prior to UAT and can be conducted simultaneously with SIT.

• All configurations are complete and gaps in standard SAP solution are resolved. IT Project Manager and Solution Architect has signed off on these build deliverables.
• Systems Integration Testing (SIT) is completed successfully by IT vendor and the output is signed off by the IT Program Lead, IT Project Manager and also the Solution Architect.
• Data Migration approach and tools are verified with simulation runs and signed off by Data Migration lead.
• All other deliverables discussed in the above recommendations are completed and approved by respective owners.

User Acceptance Testing (UAT)

   In my view, UAT should not only test but confirm the quality of your blueprint and build phases. Some transformation programs fail because they consider UAT as the first instance of verification of to be processes. In UAT business should confirm that processes reviewed in blueprint phase are working exactly as anticipated. It is a best practice to include as many business critical end users as participants in UAT along with SMEs so that they have enough time to understand the new system processes and capabilities.

Recommendations for UAT:

• Ensure in UAT kickoff that all testers having a clear understanding of UAT structure and daily goals to be achieved. Tools to log UAT output and issues tracking should be reviewed with all participants.
• Step-by-step output of each UAT script should be logged with confirmation from SME or business lead that script was successfully completed. All E2E UAT scenarios should be signed off by the process owners.
• All updates to master data source arising out of UAT issues should be done by data migration team and signed off by Data Migration Lead.
• Business functional leads along with Executive Sponsor should sign off on UAT completion only when all UAT scenarios are successfully completed and all defects are resolved with re-tests.
• IT Project Manager should ensure a new QA system is setup prior to UAT completion which will be used to perform migration dry run.

Cutover Preparation Phase

   Cutover Preparation phase is the time to verify that all cutover prerequisites are fulfilled and your entire organization is ready to cutover onto the new system.

Recommendations for Cutover Preparation Phase:

• Conduct reviews of cutover, business migration, data migration and org change strategies with final approvals on each of these documents from respective owners.
• Confirm pre-cutover and post GoLive communication plan with internal and external constituents.
• Disaster recovery and rollback plan should be finalized and signed off by your IT infrastructure and IT Program Lead.
• For large SAP transformation programs involving multi-business functions and large data entity conversions, it is important to conduct a pre-cutover dry run in new QA environment with inclusion of at least 95% data set that will be actually used during the cutover. This will simulate your ECC cutover tasks to ensure that you can smoothly migrate the data and also execute key transactions in within this QA system. The 5% allowance is for master data and transactions that may change between the dry run and GoLive. Business SMEs should perform pre-load and post-load validations in this QA system followed by approval from each business functional lead that own these data objects and transactional data.
• Confirm ownership and protocols to monitor SOX compliance and IT controls in the new environment.

Cutover Period

   Cutover period is time sensitive period that include execution of all pre-cutover activities leading up to the day of GoLive. Daily all hands review of cutover tasks are conducted by IT Project Manager and Cutover Lead. All cutover tasks should be sequentially planned considering the dependencies between master data objects and transaction data.

Some Recommendations for Cutover:

• Schedule at least four Go-NoGo checkpoints during the cutover period. First checkpoint to confirm the master data is loaded correctly with post-load validation approval from business data owners. Second checkpoint should be scheduled when primary transaction data sets are loaded like inventories, policies, financials, etc. Third check point held when all transactional data is loaded into production and verified by business owners of these entities. And finally the last Go-NoGo checkpoint scheduled when pilot processing of few select transactions is conducted in the new live production system. A separate Steering Committee ‘Go-NoGo’ should be scheduled between third and final checkpoint discussed above. Additional checkpoints should be considered depending on the magnitude and complexity of your business transformation program.
• Each master data entity should be validated and signed off by the business owner after migration into the production system.
• All open transactional entities like open claims, open sales orders, open policies, open purchase orders, collections, AR/AP etc should be validated and approved by business functional owners after migration to production.
• Any manual corrections should be documented and pre-approved by business and Cutover Lead.
• A centralized cutover directory should be created that includes all business and IT contact person for each area of the program along with first and second level of escalation points. There should be a functional email address and hotline for all customers, third parties, partners and other external stakeholders to reach out in case they have issues working with the newly deployed systems.

Post Cutover Stabilization

   Now that you are live it is important to keep an open channel of communication with entire business community to ensure smooth operations in the new production system. IT vendor project team should be in place to support the cutover for at least 3-5 months after GoLive depending on the magnitude and complexity of the cutover. Business teams for large transformations may require operational guidance and support from IT SAP experts for extended period ranging from 8-12 months. Confirm capabilities of internal support staff if your IT vendor has already transitioned the project to your IT Center of Excellence. This period could involve new post-cutover enhancements to production systems in order to address pain-points, bottlenecks and efficiency improvements.

Recommendations for Post Cutover Stabilization:

• Verify all GoLive issues are logged and reviewed in all hands meeting at least once every day after cutover for a few weeks until the number of open issues have subsided to predetermined acceptable level.
• Business functional leads along with Business program manager should review the success markers (incl. KPIs) regularly to ensure operational benchmarks are achieved.
• IT Project Manager should monitor and report system performance statistics to Project Board along with technical KPIs. If you have outsourced your IT services to another third party company then extra precaution should be taken to confirm the capabilities and readiness of the provider. The Project Manager of your outsourced IT provider should confirm that complete knowledge transfer has been received by their support personnel for each business function. Final signoff on readiness should be sought from the IT Project Manager and Transition Lead from the program IT vendor. With these measures you can reduce risks associated with complex business transformation programs and keep your implementation on track for a successful deployment.

About the Author

Deepak Mandrekar is an Executive SAP Program Leader and also the Founder of iii Technologies. For last 8 years he has led six SAP business transformation programs as a Trusted Advisor and Executive Program Leader primarily engaged by the CIO, CFO and Executive Sponsors heading these implementations. Overall he has been part of 14 SAP transformations in North America throughout his career starting as SAP Solution Architect in early years and quickly moving into program leadership roles. Some of these transformations have included global template deployments and select others involved significant custom development. He is widely recognized in the industry for turnaround of struggling transformation programs with customized best practices and strategic direction. Deepak holds a Master of Science in Engineering from Purdue University.
☏ (609) 901-8000