Generalized Approach for Integration of Companies in SAP – II

Continuning from the last post, ‘Generalized Approach for Integration of Companies in SAP’, the categories been defined were as follows:

• Planning and Management
• Preparation 
• Documentation and Requirements
• Scope
• Communication
• Data Loading
• Testing
• Team-work and Roles & Responsibilities
• Outputs/ABAP Developments
• Power Users
• Workload and Effectiveness

Planning and Management
The success of a project depends critically upon the effort, care and skill we apply in its initial planning. Scope should be clearly defined for each process. All the phases/stages of the project should have proper Time scales & Milestone defined.
For each Module, there should be a Core Business and Functional Team; & there should be Core-Process team along with Process-Owners for critical processes.          All the teams should be clearly communicated their tasks, roles and the expectancies. The project plan should be communicated /shared with all the team members as to have a clear picture as to the progress of the project and as to their contribution needed for the success of the project.

Preparation 
The Consultants role starts from the beginning; right from the workshops being conducted where they need to devote time with the power users and the end-user as to have better understanding of the system and processes. The Consultants should review all the processes along with the configuration as to make effective presentation to the business users for the change or the new process in the migrated system and also advice the Power-users for the documentation been done.

Documentation and Requirements
All the Business process existing and the New process being proposed in the system should be created as a reference point. A systematic review by the associated Consultants, business team and the processor-owners should be conducted for all the documents being drafted by the power users. As at this stage itself the requirements should be challenged so that they logically ”stack up” in the exiting system, rather than just accepting them. Also, the Process should be identified as ‘Go-Live critical’ at the Business Analysis/Planning stage itself.

Scope
It is well said, “To choose time is to save time”. Time is KEY to all projects, and since scope affects time, or project duration, they are linked. It’s imperative to have a clear understanding of what will be included and what process would be ‘done away with’ in the integrated system. All needs to be communicated to the management and the power-users in the beginning of the project itself, as it is fundamental to a project’s success. Time taken to develop a good and well-defined scope is time well spent. Enough time should be taken in form of business workshops to educate the acquired company business users as to the new processes replacing their existing process. It’s always good to have a well-defined scope document ‘signed-off’ by the management and also have a more detailed separate ‘scope document’ prepared for project team.

Communication
There should be effective communication between all the teams involved during all the stages of the project. Apart from having internal team meetings, there should be regular cross-team meeting also as to ascertain the progress being made and understand the functionalities dependencies impact. The Project plan should also be communicated to all the teams on regular basis as to understand the progress being made in the project and as to what areas needs attention and focus in comparison to the complete picture.

Data Loading
One of the most important activity in any project is ‘Data loading’ from the existing system to the new system. In a migration project, at times the general ‘myth’ is as both the system are on SAP, the data loading can be a simple process, as data needs to be exported from one system and imported to another system. Though this myth is busted big time in later stages of the project especially if proper planning is not done for the same. It’s always good to have special dedicated teams responsible only for data migration. The team should be co-headed by an experienced cross-functional consultant and a business manager involved with day-to-day activities. Pre-load checks should be added for the data so that common problems with data formats and non-existing configuration can be tested before running uploads. The team main responsibility should be to identify the data to be migrated, usage of correct templates to collect the data, verify the correctness of data after each load with the power-users. It’s been seen that most projects initial stages of testing are lost or effective testing is not done due to lack of proper master data not been in the system.

Testing
In an integration project, the test scripts should be prepared for each individual process to be tested in the system and in coordination and consultation with the business power-users. Each cycle testing should be well documented in terms of checklists, list of questions and revised quality of scripts. Less emphasis should be observed on volume testing and more on Quality and the processes [covering key scenarios] during initial test cycles.
Apart from individual test scripts, there should be process test scripts also envisaging the complete process-cycle. The process-owners should be responsible for making sure the process is complete and is being executed as defined in the scope document. The testing results should be shared across the teams.  Another important factor, “Data” should be refreshed in development box periodically for effective development of the processes. Care should be taken to make sure the accuracy and correctness of data as it can have a high impact on all processes and can result in incorrectly processes being signed-off. The Business team leads along with the process owners should chalk-out a clear and well-defined plan in scheduling the tests especially for Day-in-Life phase testing. It is always good to have less number of cycle tests though the testing period should be extended to have an end-to-end quality testing. 

Team-work and Roles & Responsibilities
Project success is directly tied to effective involvement of business and the Key stakeholders. The Roles and responsibilities should be clear and well defined. Apart from the business team leaders, it’s always good to have process owners who need to take the ownership of the complete process cycle. This holds more ground in case of integration project where a number of parties may be involved, namely external consultants, management team from the two companies, etc.
For major issues like Data-loading, outputs, there should be core teams. The Data-loading core team should consist of Managers from acquired and acquiring company & experienced Functional Consultants. This team should drive the correctness and availability of data and the process to be followed for uploading the same into the new system, validate for accuracy and co-coordinating with each business team as to the correctness of data after each data-load, co-ordinate with the management team for getting the appropriate resources assigned for data collection and educate the Power users on the responsibilities for data migration. As Outputs are critical to successful Go-Live, a core team comprising of functional and technical consultants should be responsible for all the outputs/reports. The main responsibility of this team should be to seek   sign-off from all business [legal, FI, management, etc] for the initial specification rather than after most work done.

Outputs/ABAP Developments
Outputs from SAP, forms an integral part for any project to be a success. As at the end of the day these are to be generated from the system to be sent out to the customers, yet at times, they are generally ignored or enough attention is not given to them at the beginning of the project.

Different Teams should be created from the core development team for the outputs. Sign-off specifications should be handed to the development team along with data in development system. The important and critical functionalities & gap functionalities should be monitored regularly as to have a clear picture at the Go-Live. 

Power Users
The Power-users assigned to the project should have an in-depth knowledge of one or more functional/business systems. Knowledge transfer should be done to PU ahead of business workshops as it can help both the parties in keeping key user in the loop on decisions and also involve the end-users at an early stage in the project.
The Roles and responsibilities need to be very clearly clarified to Power users / End users to avoid confusion and the team leads should ensure the Power users stick to the designated roles.
It’s always a good practice to involve the PU who have been through an implementation as they would be able to explain not only technical / business details but will also be able to explain the other phases of the projects. Adequate resources should be assigned for each process ensuring that they are not over-stretched and their workload is manageable.

Workload and Effectiveness
In every project we witness symptoms of crisis and as experience has taught us that projects should clearly understand human abilities & capabilities. The strategy should clearly lay down principles of work with respect to every project. The certain factors that can govern the strategy, can be, reasonable workload, as having too much work is a recipe for stress, which is bad for a person’s health and well being over the longer-term. Understanding Critical processes, Resource allocation, rooms, overlapping stages, tight due dates should be identified/planned well in advance. Planning well in advance shall work as an antidote for stress. Also, Overlapping of training and data-load preparation should be avoided; Timing of tests should not conflict with Month End activities, etc.
To maintain a high level of effectiveness, the complete team should be at the same site especially at the Days-in-Live tests and the Go-Live, as on-ground support is more effective and efficient than remote support. Another crucial area, ‘Transports’ should be handled by Functional teams themselves for control of move to test system. One consultant should be responsible for all transports and handling all aspects of that to production system.

In my concluding blog for this series, i would be presenting a Case Study/recent migration project i am involved in for the key challenges/Issues and the learning from the project.