During the realization phase of a SAP project, your main focus is on solution design (functional & technical), RICEF development, data conversion readiness, system configuration, unit test and other end-to-end testing of the SAP system with final acceptance by the business. QA testing including assembly, integration and product testing. The ultimate goal of this phase is to build, configure and test the SAP system and release it for go-live.
- Review of RICEF estimates by SI Development Team: Most systems integrators may onboard RICEF development team (also technical or build team) at the beginning of the realization phase. Development team has to deliver the RICEF objects within the timeline and effort that were estimated prior to beginning their work. It is important that you have the application development lead and technical architects from your systems integrator review the estimates that were done at the end of the blueprint phase and refine these numbers by working with the PMO and project leadership.
- Ensure that SI staffing model for realization phase matches with the work effort in estimation: SAP system configuration, RICEF development and testing work effort is estimated by the SI followed by your approval at the end of blueprint. Now make sure that the number of resources in each team matches with the effort required to complete the deliverables as per the RICEF estimates. Other teams such as PMO, BASIS, OCM and Training are duration based and staffing of these work streams should match with the estimates provided by the SI at the start of the project.
- Enforce strict change control governance: This is where projects run into cost overruns due to excessive or poor management of change requests. Have an independent third party advisor along with project sponsor serve as the head of change control board. All change requests should be analyzed and challenged with any scope/cost adjustments by the advisor and project sponsor. If extra objects or effort is requested, you should thoroughly analyze the reasons for these changes. Each change request should also be technically challenged if necessary. Proper governance on change requests can lead to significant cost savings. Always have a senior SAP skilled resources to audit change requests if you do not have an advisor on the project.
- Review, approve & sign-off on all deliverables: All deliverables in the realization phase should be reviewed and signed-off by the project SMEs and leads from the SAP customer before it can be taken to the next step. Universal Project Deliverable Acceptance & Approval Form should be used. If your project does not have a template, I can gladly provide one for your project.
Functional Design / Technical Design / Build / Unit Test / Integration Test
SAP RICEF functional specification should be reviewed by the business SME and signed-off by business team lead and overall business lead.
OCM/Training plans, documents and delivery aid should be reviewed & accepted by your internal OCM/Training Lead and business stakeholders. Business stakeholders, project manager and internal OCM Lead should have signed off on this deliverable.
RICEF technical designs should be approved to the minimum by SI RICEF Lead. This leads can be a ABAP Lead, SAP PI Lead, BI/BOBJ Lead or Conversion Lead depending on the RICEF object type. Your internal technical leads should review and signoff on these designs. Business may have limited knowledge and capability to review SAP technical solution. But the business should certainly test and approve individual RICEF object.
I recommend you hiring your own internal SME or leads for your company who are senior level experienced resources in SAP ABAP, SAP PI, SAP BI and SAP BASIS. This will build your internal SAP technical system expertise to support your business post go-live.
Security and IT infrastructure deliverables should be reviewed by your internal SAP BASIS lead and overall IT lead of your project.
Some systems integrators may try to avoid Deliverable Acceptance forms and the process of seeking written approvals from the client. But, I strongly insist the client executive leadership to enforce deliverable acceptance + signoff by your internal team. This sign-off and acceptance forms will serve as your critical supporting documents if your project lands into unforeseen challenges or may be even goes into legal proceedings.
- Early baseline configuration of SAP system: This will help the developers of your RICEF objects to perform unit tests properly with basic system configuration required for testing. Review the configuration with business process owners. Completion of SAP system configuration from the start of baseline configuration is an iterative process. I recommend thorough documentation of each change to the initial baseline config in the configuration rationale. This would provide the business leadership an insight into your business process configuration and history of all changes that were made. It will also serve as a configuration reference guide after your system go-live.
IMPORTANT: This baseline and final configuration should be part of configuration rationale. It should be approved and signed off by the SME and business lead. Configuration Rationale should include all changes that were done to support successful integration test of business process scenarios.
- DOCUMENT! DOCUMENT! Each SAP customer is unique and hence the system setup and configuration: For your internal project SME and leads, I always believe in documentation as you learn or do things in SAP system. When you learn something about SAP system configuration, system processes, transactions, programs, etc. please document it even if it is your own raw language. You are learning a lot during the entire project and it is natural tendency of a human being to forget information especially when there is an overload. Documentation if needed will only help you as your own internal reference guide.
- Integration test only after completion of all unit tests: Integration tests will follow upon completion of unit tests and overall when the RICEF development with the necessary system configuration is complete. SAP Integration Testing will test your end to end business process (typically multiple unit test scenarios) is working together. It is ideal to start integration test for your entire project only when all unit testing is completed. But many projects have tight timeline and this may need to be started sooner. To the minimum I would recommend that all the unit tests associated with an integration test scenario be complete and signed off before beginning with a specific end-to-end integration test. All integration tests should be signed off by SME, team leads and overall business leads. Your QA lead should coordinate and manage completion of integration tests, assembly tests and UAT.
- Thorough Integration Tests: I recommend maximum business users and SME participation for integration testing of your SAP solution. This will allow multiple resources doing the same end-to-end integration tests with broader coverage of test scenarios and natural human tendencies while using the SAP system.
Thorough Integration Testing w/multiple users = Better Quality Production System
Your SME and users from run the business (RTB) will anyway work in the new SAP system. So why not include them a little early allowing a better knowledge transition and also benefiting the project team to allow more users test their business processes.
- Regression Testing “A MUST”: You must have heard this several times in IT projects. “I created a fix for business process A but that broke business processes D, E & F.” Well! While implementing SAP it is no exception. If you enhance a system process or fix a system defect, please make sure all the other processes that are affected by this change are tested thoroughly. If you are using SAP eCATT or other automated test tools, then I suggest creating regression tests that you can run periodically but more so when you change configuration or RICEF object. I have seen a lot of projects run into production issues after go-live because of changes that were made during testing phases. But these changes were made to fix a business process but it had a negative impact on other related business processes. Just before go-live run a final SAP integration test cycle to ensure all the business processes are working as desired “end-to-end” after all changes have been implemented in the system.
- Start data cleansing and conversion early enough to meet system delivery deadlines: Begin analysis and cleansing of data in your legacy system early in realization. Start with the development of transformation and load programs early enough so that these objects are ready before integration testing. By end of realization you should have completed loading sample data into your QA environment and business process owners should have successfully tested their business scenarios with this sample data. Ensure approval and sign off on the data conversion for each business work stream upon completion of these tests.
- SAP America Go-Live Readiness Check: Finally, I highly recommend inviting SAP America / SAP AG for a quick “Go-Live Check” to get a blessing that you are ready to go-live with your SAP system. SAP America / SAP Inc over the years have reviewed, troubleshooted and fixed major implementation problems on several thousands of projects. This check will only benefit you to avoid any obvious system go-live problems associated with your SAP components and overall solution.