The decision of SAP implementation goes in various stages before the actual implementation starts. There are two strategically important stages of this decision process. If anything goes wrong in these two stages, there are long term effects resulting into either over engineered solutions or under mediocre solutions, delays and heavy cost overruns. Implementation approach whether it will be a “big-bang” approach, “phase wise” approach or a “parallel adoption” is selected at the beginning of the project. Irrespective of the approach, the methodology for implementation is same i.e. ASAP methodology. There are various phases of ASAP methodology.

The experiences and learning collected after various SAP implementation projects is the scope of this paper.

The objective of this research paper is to share the experience and the learning collected from various implementation projects to the system integration companies, the SAP consultants who are practicing SAP implementations and comparatively new in this field.

The methods adopted to collect primary data are direct in depth interviews & mailed questionnaires. The sample include the SAP consultants who have worked on number of implementation projects, the representatives of the companies who have implemented SAP The secondary data is collected from various published and unpublished sources. Various research papers which deal with the SAP implementation methodology are taken into consideration. Various information stored in the official online library of SAP, various information stored on SAP service portal about SAP products is also referred. Various study material published on websites which share useful information about SAP implementation is also referred as secondary data.

The first decision stage is in SAP implementation is obviously the “selection of the SAP product” amongst those available in market. This decision stage is relatively easier as the decision makers are aware of the functional processes and the business needs. A lot of input and professional guidance is also available in the market. The second stage of the decision process is extremely difficult i.e. what should be the approach of SAP implementation. This decision is not easy. The decision varies industry to industry. The volume of business, the complexity of and inter-dependency of

2

decision phase. As mentioned earlier the wrong decision lead to significant disadvantages or even to failure of the project. There are practicing consultants available in the market to consult on the approach. The steering committee (consisting of the relevant decision makers in the company and the program team of the system integrator) of the project is however required to give holistic thought to arrive at the right decisions.

Big bang approach- In this approach, the implementation happens in one shot. All users, all business processes move to the new SAP system on a given date. Phased rollout approach – In this approach, the changeover occurs in multiple phases over an extended period of time. Set of processes and relevant users logically move onto new system in a series of steps in each phase. Parallel adoption approach – In this approach, both the legacy and the new SAP system runs at the same time. Users learn the new system while working on the old. Old system is phased out once the learning curve on the new system.

As the name implies, a big bang SAP implementation happens in a single, major event. All modules are implemented and activated („Go live‟ in typical SAP language) across the entire organization. All business users across different geographical locations, running different business processes start using the new SAP system at the same time. The legacy system is set to shut down. Of course the changeover from the legacy system doesn‟t happen without proper planning. There are many pre-implementation activities that are carried out prior to the big bang. When the old system is shut down and new SAP system comes in operation, there is no turning back possible. However, there should be fallback in place, just in case of the failure. There are advantages & disadvantages to this approach. The most common criticism is the bigger risk factor if the things go wrong because of the ineffective change management. However, the implementation is quick and less costly than a long, drawn-out phased approach. Here is a list of other benefits and drawbacks of big bang implementation.

Shorter Implementation time Issues after implementation due to major change Probable post Implementation issue are anticipated in advance & normally a hyper care is planned Process details may be overlooked in the course of rapid change which may show a larger impact after implementation. The change management effort is huge. Costs are much lower compared to other approaches Employees have less time to learn the new system hence change management is very critical Implementation happens on a single date and everyone knows the date much in advance A failure in one part of the system could affect the others

Another flip side of big bang implementations is “Initial Dip Phenomenon.” Eason, author of “Information Technology and Organizational Change” and one of the original authorities on implementation strategies, describes an “initial dip phenomenon” which may happen shortly after an implementation. This phenomenon happens because users are struggling with the new system and organizational performance temporarily may decline as a result.

Phased rollout approach follows the Steady State concept. Instead of an implementation happening in a single instance, small changes occur in multiple phases over a period of time. An organization migrates from the legacy system into the new SAP system in a series of predetermined phases. This can be achieved in several different ways. Here are three well-known techniques as below. Phased rollout by module - This is the most common phased rollout strategy. Various SAP modules are implemented one at a time or in logical sets. Typically the implementation begins with core business functions – those necessary for daily operations – then add in more modules and functionality with each phase. However, some experts suggest starting with easy modules rather than mission-critical modules to minimize the risks. Phased rollout by business unit - In this approach, implementation is carried out in one or more business units or departments at a time. For example, implementation of the new SAP system starts with a sales and marketing unit. Some organizations form a project core team that travels between each location / unit during implementation phases. As the team gains more experience with

Phased rollout by geography - The organizations which have multiple locations, prefer the approach “Phased rollout by geography”. The new SAP system is introduced at one or more company locations at a time. This is also referred to as the “pilot adoption method.” It‟s common for large organizations that have multiple locations or independent departments.

Companies gain knowledge and experience during the initial implementation phase that can be used in subsequent phases. Project members may develop unique implementation skills that they can be positioned for in later rollouts Not as focused and time efficient as big bang Possible to introduce existing modules while configuring future modules Involves continuous change over an extended period of time With the change occurring in parts, time is available for adjustments Each modules relies on information from other modules, so there could be critical information and integration missing Employees learn on the job, as they go Several adjustments and work around are needed due the lack of integration. Temporary interfaces are required between legacy system and new system

The third approach of SAP implementation is the “parallel adoption” approach. This is treated as the least risky implementation approach. It includes running both the legacy and new SAP system at the same time. This way, users can learn the new system while performing regular work activities on the old system. After requirements for the new system are met, then the legacy system is shut down. Parallel adoption can be considered the middle way between big bang and phased adoption. For example, the pace of the changeover is slower than big bang, but faster than phased adoption. Similarly, user adaptation is easier than big bang, but more difficult than phased adoption. The key advantages & disadvantages of parallel adoption are as follows

The risk of complete failure is avoided because both the new and old systems are running This is very expensive option as both the systems are run in parallel Users can learn the new system while working on the old. This protects the business disruptions and also improves user confidence Users need to enter data in both systems. This not only incurs cost but may also lead to data inconsistency in both systems Faster implementation than phased approach (but slower than Big bang) Reluctance to change from user is more because they keep comparing the old and new system everyday

“Software advice, INC” had conducted a survey in early 2010 to find out which ERP implementation strategies are the most popular and most successful. It is important to note that this survey was not limited to SAP implementation but for any ERP implementation. However, the inference can be very well applied to SAP implementation. With the help of Twitter and other favorite industry bloggers, they collected responses from organizations that have been involved in an implementation. The survey was very informal with just four simple questions:

• Which implementation strategy did your organization choose? Big bang, phased rollout, parallel adoption, combo of big bang and phased rollout, or other.

• If you selected other, please describe the strategy you chose.

• Was the implementation a success

• If you selected no, please explain why

No one approach can be called as the only successful approach. While one approach may work for some of the companies, it may not be the best strategy for other companies. As Jonathan Gross from „Pemeco company‟ pointed out, “The circumstances dictate the appropriateness of the implementation strategy. In some cases, a phased deployment might be more appropriate than a parallel deployment. In other cases, it might be the opposite.” Nevertheless, the survey did uncover the important fact that eighty-nine percent of respondents followed “big bang,” “phased rollout” or a combination of the two strategies.

4

Thus the survey proves that the approaches explained above are the most widely used implementation approaches.

As mentioned by Mark Jeffery and Ingmar Leliveld in their paper, “Best Practices in IT Portfolio Management”, published at MITS loan Management in 2004 “An estimated 68% of corporate IT projects are neither on time nor budget, and they don‟t deliver the originally stated business goals”. It is therefore very important that the methodology used for implementation of IT projects should be robust. SAP recommends ASAP methodology for the successful implementation. The ASAP methodology provides the steps for implementing and continuously optimizing the SAP System.

ASAP divides the implementation process into five phases and offers detailed Project Plans to assist implementation. Following figure depicts the phases of ASAP methodology roadmap. There are 5 phases in the SAP Project. Project Preparation, Business Blueprint, Realization, Final Preparation, and lastly, Go-live & Support. Phase 1 – Project Preparation (PP): The primary focus of Project Preparation Phase is getting the project started, identifying team members and developing a high-level plan. This is the first phase after the Project is kicked off. The project teams are formed. The team members understand their roles. The required domain knowledge is gathered by SAP consultants in this Phase 2 – Business Blueprint (BBP): The primary focus of this phase is to understand the business goals of the company and to understand the business processes needed to support those goals. In BBP Phase, SAP consultants do scoping of SAP system with Process Owners to map the business processes in respective SAP modules. This mapping of the processes in SAP to indicate how the respective business process will be executed in SAP is called a blueprint. The template used for documenting the Blue print may differ from company to company. But the contents are mostly same. The existing process (As-is), and To-be processes which is after SAP implementation is described in detail with flow diagrams. Any process gaps if exist are identified and the custom solution is provided if the standard SAP process does not match. The detail blueprint makes the implementation easier. The configuration elements, the data conversion points are added into the blueprint. Blueprint document is signed by Business process owners to avoid any ambiguity on solution. This is the most important exit criteria for BBP phase. Phase 3 – Realization: The purpose of Realization phase is to implement all the business processes based on the Business Blueprint. SAP consultants customize the SAP system step by step. Configuration document is created for all future references. Apart from the standard SAP configurations, system enhancements are also done in Realization phase. System enhancements have To-be documented separately & linked to the blueprint document. Functional consultants create “Functional specification” for the enhancement and the developer writes the “Technical specification”. Normally, key management reports or interfaces to exchange data from Non-SAP system fall in this category. Enhancements are developed on ABAP platform. Once the configuration & enhancements are ready, the consultants do the unit testing of the system & then the system is ready for User Acceptance Testing (UAT). Before offering the system for UAT, the key users are required to be trained to perform the testing. The training manual is created to guide and train the users. The user profiles are created based on the actual user role in the organization. User profile allows the user to perform required business transactions in SAP and stop users to perform any other transaction which is not supposed To-be performed as per his or her role. UAT Test plan is created which contain the integrated processes To-be tested. Detailed test scripts are prepared which include the set of transactions which are required to complete the process. UAT has To-

Phase 4 – Final Preparation (FP): The purpose of this phase is to ensure that the complete testing is done, end-user training is completed & project is ready for cut over. The master data is uploaded in this phase. The data is collected by users in earlier phases in the data collection templates provided by consultants. Consultants create the data upload tools & train users to upload the data. Users upload the data in test system as well as production system just before the final cut over. In final cut over, the legacy system is stopped & open data like active purchase orders, active production orders etc. are uploaded in SAP. Upon completion of FP phase, the company will be ready to run business in the productive SAP system. Another important note to remember here is that, there would be a mirror production client as a Final test/check point. The system readiness check /audit here can be done by an external party such as SAP. This is to ensure that, during Go-live, there will be less or no hiccups. Phase 5 – Go Live and Support: Once the cut over is complete, the system is ready to handle productive business. A golden transaction is performed in productive system and the result is checked. This is called “Go live” of SAP system. Users are then unlocked and allowed to use their day to day business transactions. Important aspect of this phase is hyper-care support. Here, consultants would be on-site or off-site for a period of time to ensure that everything runs smoothly. They do the required hand holding to the end users so that they become capable to handle the day to day business through SAP. This is called the warranty period and it depends on client/vendor how long this period should last. Within this support phase, normally a champion user group is created who provide the support to the end users in longer run. Some companies prefer to hand over the long term support to vendors. The knowledge transfer to such support team also takes place in same phase. Go Live and support phase is signed off based on these criteria. Any open issues are enlisted and agreement is made on the resolution of the same. That becomes the exit of the SAP project.

The deliverables of each phase may change project to project or company to company, however, the standard deliverables in the ideal SAP implementation project is as follows.

Phase 1: Project Charter (Document) Set-up of Project Infrastructure including Project Preparation

• Project Schedule (Document)

• Project Organization and Standards (Document)

• Project Kick-off meeting

• Development Server set up

• Project Preparation phase sign off

network, desktops, printers, fax machine, etc.

• Deployment of core team members

• Formation / Identification of Steering Committee, Process Owners, Project Sponsor, Executive Committee and Change management team

• Hardware for Development Environment and Solution Manager

• Connectivity to all identified go-live sites established and tested

Phase 2: Business Blueprint

• Business Blueprint document which includes the following:

o Business Organization Structure o Gap Analysis o Identification of developments having details of – Enhancements, Reports, validations, Interfaces, and Layouts (Print-outs) o Business Process details o Master and Open Data template o Overview of Cutover approach o Authorization matrix

• Quality Server set up

• Business Blueprint phase sign off

• Sign-off Project Preparation phase

• Identification and deployment of Master Data Management team

• Hardware for QA Environment

Phase 3: Realization

• Migration of Programs/ reports to Quality Server Environment

• Technical Specifications for Developments

• Integration test (Document and Issue log)

• Production Server set up

• Realization Phase sign off Environment

• Sign-off Business Blueprint document and phase

• Hardware and Infrastructure for End User Training

• Identification and deployment of End users

• Identification of business roles and business authorization profiles

• Preparation of Integration testing scenarios

• Conduct Integration testing

 Hardware for Production Server

6

Phase 4:

• Cut Over Strategy

• Establish Internal Help Desk with the help of client

• Sign-off integration testing and Realization phase

• Validated master data for upload into Production server

• Completion of End-User training

• Identification of users mapped to business roles and business authorization profiles

• Requisite hardware (PC, Printers, Routers, LAN, etc) and software (MSOffice, Antivirus, SAPGUI, etc) are installed and tested for all end-users

Phase 5:

• Close open issues and Post Go Live Support Phase sign-off

• Project Closure Sign-off

• Sign-off Final Preparation phase

• Master and cutover data transferred to productive system are validated.

• Signoff Go Live

• Signoff project Closure

Various activities which are performed in respective phase and the responsibility to perform the activity may differ in various projects. However, the activities and the distribution of responsibilities between the SI partner & the company in which the SAP is implemented (referred as client) in ideal project is as indicated below.

Project Preparation Hardware Requirement Report / Sizing SI Partner Core team deployment / Project Infrastructure setup for Project Team members (Hardware and system environment setup –PCs, Networks, OSS Connectivity, etc.) for training Client SAP Functional Overview to Project Core Team SI Partner Agreed and Finalized Project Schedule SI Partner Client Defining Project goals and objectives Client SI Partner Preparing the Project organization and standards SI Partner Client Hardware and system environment setup - Solution Manager and Development Server Client Sign-off - Project Preparation phase Client Business Blueprint Organizational structure definition Client SI Partner As-Is document discussion Client / SI Partner Organizational structure mapping into SAP SI Partner Identify list of major business flows and initial assessment of business processes for coverage SI Partner Client Map major business flows and assessment of coverage / process variations SI Partner Client Create Business Blueprint Document SI Partner Client Setup QA System SI Partner Client Business Process document - sign-off, completeness for each application component Client List of developments /Gaps identification SI Partner Release of template for Master Data collection SI Partner Approach for End User Training and Documentation SI Partner Client Release of template for Authorization matrix SI Partner Business Blueprint phase Signoff Client Realization Functional Specifications for all Developments SI Partner Client Baseline Configuration SI Partner Client Back Up Strategy SI Partner Unit Test (Baseline) Plan SI Partner Client Conduct of Unit testing (Baseline) with model data Client SI Partner Unit tests (Baseline) issue resolution SI Partner Technical specifications and development of upload / download / interfaces / enhancements / reports / forms SI Partner Client Extraction of data from legacy Client

systems / cleaning / verification and formatting in SAP templates Loading (migration) of data into SAP using data migration tools / conversion programs SI Partner Client Programs for developments, interfaces and enhancements, conversions, etc. SI Partner Client Carry out Final Configuration and Document SI Partner Client Identifying roles and mapping to authorization structure Client SI Partner Establishing Authorization Management SI Partner Client Create detailed Integration Test plans SI Partner Client Create detailed integration test scripts and approval/ Testing all development programs Client SI Partner Create master data for Integration testing Client SI Partner Integration testing (User Acceptance Test : UAT) of the configured system using the populated representative master / transaction data Client Identify end-user training requirements / create End user Training Plan and training system Client SI Partner Create Training Infrastructure at all major locations / regions; ensure availability of users as per calendar Client Create End User Training Documents Client Impart training to Core Users of SI Partner Plan for Internal Helpdesk - Resources and Infrastructure Client Install and Commission Production System Environment Client Final Preparation Go Live Cut Over Plan SI Partner Client Productive client setup SI Partner Client Collection, cleaning, reform and verification of open item data prior to upload Client Validate master data for upload in Productive client Client Validation of Master data transferred to Productive client Client End User training Client User ids and authorizations created SI Partner Go-live readiness (H/W, N/W, GUI installation, etc) Client SI Partner Go-live readiness: network connectivity to plants and warehouses Client Creation of Master Data Governance Team Client Creation of User and Authorization Governance Team Client Necessary technical infrastructure for end-users Client Production system checking completion Client Formation and operation of Helpdesk Client SI Partner Production System Readiness for Go-Live Client Post-Go-Live Support Commencement of commercial transactions on productive client Client Verification of Business results Client SI Partner Issue resolution post Go-Live Client Sign off of Go-Live Client Project / Phase Closure - Sign -off Client

For the successful SAP implementation, only using ASAP methodology is not sufficient. There are other aspects of methodology which also constitute in the

8

The implementation of SAP ERP 6.0 demands a complete and thorough understanding of both the Management concepts and the SAP system framework. There is a need for appropriate training initiative to ensure successful implementation of the project. It is highly recommended that training is handled as focused Change Management activity for the successful SAP implementation. The prerequisites of effective training are as follows

• A Training Needs Analysis is conducted by the Client Change Management team to understand and ensure that the real training requirements of the various users are being addressed, in addition to the planned training by SI partner

• The Project Team in association with the Client Change Management Team need to take appropriate care while developing the training curriculum so as to make it flexible To-be imparted to various levels of users who may be at different levels of learning curve and grasping ability.

• The Client Change Management Team, along with the Project Leads needs to evaluate the various media and facilitate the availability of the same along with appropriate infrastructure and support systems for effective delivery of the various training programs.

• Training feedback is collected at the end of each classroom training sessions to measure effectiveness of the training.

Quality management during the project implementation is extremely critical activity. In every implementation the quality management methodology may differ based on the complexity of the project. The basic purpose of Quality management is Quality planning, Quality assurance and Quality control. Quality Planning – This includes defining objectives, goals, project quality organization, applicable quality standards and standard processes tailored to such standards in the form of a formal quality plan. Such processes are tailored during the pre-preparation phase to suit specific customer needs. This phase also includes planning reporting and controls for the project. Quality Assurance – This includes applying relevant Quality Gates at defined milestones, planned management as well as artifact reviews, defect Quality Control – This includes putting in corrective measures for the relevant Quality Gates for management control at defined milestones if any defects observed. Quality gets are created at the exit of each project phase. Various parameters are identified at the beginning of the project & checked in respective phase.

In any SAP implementation project, project governance is the key success factor. The project governance ensures the effective participation at all the levels within the project i.e. strategic, tactical and operational. Strategic governance ensures collaboration between the SI partner and the client at for strategic decision making. The tactical governance ensures the collaboration between two parties for all project planning aspects. The operational governance ensures the collaborations between two parties at activity level in the project execution. The means of exercising effective governance is setting up the right organization structure. Steering committee layer, Program and project management layer and the execution layer are the three major levels in organization structure. The project sponsor, managers & executive team is fitted into a well thought project organization structure. After creating the structure, assigning a very clearly defines role and responsibility to each team member is also very important.

Every project has a certain amount of risk involved. As per the standard principles, the risk of project failure is high at the beginning and it reduced as the project progresses. However, ineffective risk management may lead to the surprises and project failures. Risk Management is therefore iterative activity, performed throughout the project until the end of the project. The project manager creates a risk register at the start of project and enters all risks in the register. Every risk is assesses and its probability of occurrence is determined. The impact of every risk items is analyzed in terms of cost and possibility of project failure. The best way to eliminate the risk is avoid the risk. However, it is not possible every time. The mitigation plan is in therefore in place. Mitigation action is identified if the risk arises during the project so that the impact in minimal. Following diagram

The critical starting point of the Project is the rightly identified scope. However, in practical scenarios there are the additional requirements identified during the project for the meaningful completion of the project. If such requirements are accepted without much due diligence, there is a high possibility of project getting delayed. Whereas, if some of the requirements are so critical that if those are not addressed, the key benefits are realized or even there are possibilities that project doesn‟t go to the completion. A strong Change Control Management is therefore required to strike out the correct balance. Every change is tracked using Change Request (CR) and follows the change control mechanism. The CR process is divided into following 4 major steps such as creation of change request, feasibility analysis and suggesting probable solution, Go-No Go decision on change request and change request implementation.

For the successful SAP implementation selecting right approach is very important. The approach whether it is a big bang or others changes company to company based on the business needs, urgencies, business volumes, geographical needs, IT maturity of users and the impact of change. Using the appropriate project methodology is also equally important. Use of ASAP methodology ensures that all the activities in the project are well planned, the scope is rightly defined and the satisfied solution is designed, the necessary configurations are completed, necessary developments are completed and system is tested, necessary data is migrated & system is ready to use for business purpose. Other important aspects of methodology are meaningful Training, strict Quality Control, effective governance and organization structure, appropriate Risk Management and strong Change Control mechanism.

Dr. Manas Kumar Sanyal, Sajal Kanti Bhadra, Sudhangsu Das (2012). “ERP implementation issues and challenges: A FISHBONE analysis in context to Indian industries”, International Journal of Research in Management and Technology, (ISSN: 2249-9563),Vol. 2 No.2, pp. 220 -229 Injazz J. Chen (2003). “Planning of ERP systems: Analysis and future trends”, Business process management journal Vol 7 No 5, pp. 374-386 Joseph R. Muscatello (2003). “Implementing enterprise resource planning (ERP) systems in small and midsize manufacturing firms”, IJOPM journal Vol 23 No.8, pp. 850-871 Sankar, Chetan (2006). “Implementation strategies for SAP R/3 in a Multinational organizations: Lessons from the real-world case study”, Idea Group Inc (IGI), e-book.