The implement of SAP software, such as SAP R/3 is almost always a massive operation that brings a lot of changes in the organization. The whole process can take up to several years. Virtually every person in the organization is involved, whether they are part of the SAP technical support organization (TSO) or the actual end-users of the SAP software. The resulting changes that the implementation of SAP generates are intended to reach high level goals, such as improved communication and increased return on information (as people will work with the same information). It is therefore important that the implementation process is planned and executed using a solid method. There are various SAP implementation methods. An example of how one company, Robert Bosch GmbH, implemented SAP R/3 over 10 years is available. This study shows that designing IT architecture is critical in SAP implementation practices.

IEEE scholar journal reports an industrial case in which the senior management successfully dealt with a troubled SAP R/3 implementation in an international fast-moving consumer goods (FMCG) company during 2001 and 2002. (Lui 2008)

The following table provides a summary of all of the activities that form the SAP implementation process. These activities will be described with more detail and elaborated with examples in the rest of this entry.

Project preparation edit

Mission Key is also what defines slack.

Design and initially staff the SAP TSO

The first major step of the project preparation phase is to design and initially staff an SAP technical support organization (TSO), which is the organization that is charged with addressing and designing a Craft solution vision.

The second project preparation job is to define a so-called solution vision, i.e. a vision of the future-state of the SAP solution, where it is important to address both business and financial requirements (budgets). The main focus within the vision should be on the company’s core business and how the SAP solution will better enable that core business to be successful. Next to that, the shortcomings of the current systems should be described and short but clear requirements should be provided regarding availability (uptime), security, manageability and scalability of the SAP system.

Sizing and blueprinting edit

The next phase is often referred to as the sizing and blueprinting phase and forms the main chunk of the implementation process. The phase is illustrated below.

This phase starts with performing a total cost of ownership analysis (TCO analysis) to determine how to get the best business solution at the lowest costs. This means to compare SAP solution stack options and alternatives and then determine what costs each part of the stack will bring and when these costs will be incurred. Parts of the stack are for example the hardware, operating system and database, which form the acquisition costs. Next to that, there should be taken a look at recurring costs like maintenance costs and downtime costs. Instead of performing a complete TCO analysis for various solution stack alternatives that would like to compare, it can be wise just to do a so-called delta analysis, where only the differences between solutions (stacks) are identified and analyzed. The image at the right depicts the essence of a delta analysis.

Identify high availability and disaster recovery requirements

The next step is identifying the high availability requirements and the more serious disaster recovery requirements. This is to plan what to do with later downtime of the SAP system, caused by e.g. hardware failures, application failures or power outages. It is important to calculate the cost of downtime, so that an organization has a good idea of its actual availability requirements.

Engage SAP solution stack vendors

A true sizing process is to engage the SAP solution stack vendors, which is the next step. This means selecting the best SAP hardware and software technology partners for all layers and components of the solution stack, based on a side-by-side sizing comparison. The most important factors that are of influence here are the estimated numbers of (concurrent) users and batch sizes. A wise thing to do is to involve SAP SE itself to let them create a sizing proposal stating the advised solution stack, before moving to SAP's technology partners/SAP vendors, like Accenture, HP and IBM. A simplified solution stack is depicted at the right, showing the many layers for which software and hardware has to be acquired. Note the overlap with the OSI model.

Staff TSO

The TSO (Technical Support Organisation) is the most important resource for an organization that is implementing SAP, so staffing the TSO is a vital job which can consume a lot of time. In a previous phase, the organization should already have staffed the most vital positions. At this point the organization should staff the bulk of the TSO, i.e. fill the positions that directly support the near-term objectives of the implementation, which are to develop and begin the installation/implementation of the SAP data center. Examples are: data center experts, network infrastructure experts, security specialists and database administration experts.

There are many ways to find the right people within or outside the organization for all of the TSO positions and it depends on the organization how much time it wants to spend on staffing.

Training

One of the most vital stages of the implementation process is training. Few people within an organization are SAP experts or even have worked with SAP software. It is therefore important to train the end users but especially the SAP TSO: the people who design and implement the solution. The usual activity is to train a group of key users who in turn train the staff (source: practicalsap.com). The organisation's key users must be involved in the implementation project and testing of the system. Many people within the TSO need all kinds of training. Some examples of these positions:

• SAP Network Specialists
• SAP Database Administrators
• SAP Security specialists
• Documentation specialists
• Et cetera

All of these people need to acquire the required SAP knowledge and skills or even SAP certifications through training. Moreover, people need to learn to do business in a totally new way. To define how much SAP training every person needs, a company can make use of a skillset matrix. With this matrix, a manager can identify who possesses what knowledge, to manage and plan training, by defining the height of expertise with a number between e.g. 1 and 4 for each skill for each employee.

Setup SAP data center

The next step is to set up the SAP data center. This means either building a new data center facility or transforming the current data center into a foundation capable of supporting the SAP solution stack, i.e. all of the technology layers and components (SAP software products) in a productive SAP installation. The most important factor when designing the data center is availability. The high availability and disaster recovery requirements which should have been defined earlier, give a good idea of the required data center requirements to host the SAP software. Data center requirements can be a:

• Physical requirement like power requirements
• Rack requirement
• Network infrastructure requirement or
• Requirement to the network server.

Perform installations

The following step is to install the required SAP software parts which are called components and technological foundations like a web application server or enterprise portals, to a state ready for business process configuration. The most vital sub steps are to prepare your OS, prepare the database server and then start installing SAP software. Here it is important to use installation guides, which are published for each SAP component or technology solution by SAP SE. Examples of SAP components are:

• R/3 Enterprise — Transaction Processing
• mySAP BI — Business Information Warehouse
• mySAP CRM — Customer Relationship Management
• mySAP KW — Knowledge Warehouse
• mySAP PLM — Product Lifecycle Management
• mySAP SCM — Supply Chain Management
• mySAP SEM — Strategic Enterprise Management
• mySAP SRM — Supplier Relationship Management
• mySAP HCM — Human Capital Management

Round out support for SAP

Before moving into the functional development phase, the organization should identify and staff the remaining TSO roles, e.g. roles that relate to helpdesk work and other such support providing work.

Realization edit

The next phase is the functional development phase, where it is all about change management and testing. This phase is depicted below.

Address change management

The next challenge for an organization is all about change management / change control, which means to develop a planned approach to the changes the organization faces. The objective here is to maximize the collective efforts of all people involved in the change and to minimize the risk of failure of implementing the changes related to the SAP implementation.

The implementation of SAP software will most surely come with many changes and an organization can expect many natural reactions, i.e. denial, to these changes. To fight this, it is most important to create a solid project team dedicated to change management and to communicate the solution vision and goals of this team. This team should be prepared to handle the many change issues that come from various sources like:

• End-user requests
• End-User regular activities
• Operations
• Data center team
• DBA group
• Systems management

SAP systems and operations management

Next thing is to create a foundation for the SAP systems management and SAP computer operations, by creating a SAP operations manual and by evaluating SAP management applications. The manual is a collection of current state system documentation, day-to-day and other regularly scheduled operations tasks, various installation and operations checklists and how-to process documents.

Functional, integration and regression testing

Testing is important before going live with any system. Before going live with a SAP system, it is vital to do many different kinds of testing, since there is often a large, complex infrastructure of hardware and software involved. Both requirements as well as quality parameters are to be tested. Important types of testing are:

• Functional testing: to test using functional use cases, i.e. a set of conditions or variables under which a tester will determine if a certain business process works
• Integration testing
• Regression testing

All tests should be preceded by creating solid test plans.

Agreements will be met. This can be done with SAP's standard application benchmarks, to benchmark the organization's configurations against configurations that have been tested by SAP's hardware technology partners. Again, a test plan should be created at first.

Integration test edit

Integration test in SAP implementation process involves testing the interaction between different modules or systems to ensure seamless data exchange and proper functioning of business processes. It begins with identify integration points followed by developing test scenarios and preparing relevant test data. Tests are executed to validate data accuracy, process integrity and error handling. Documentation of test results and regression testing after system changes are essential for maintain system reliability and business continuity. Integration testing plays an important role to ensure the effectiveness and reliability of the SAP era.

Final preparation edit

Prepare for cutover

The final phase before going live with SAP is often referred to as the cutover phase, which is the process of transitioning from one system to a new one. The organization needs to plan, prepare and execute the cutover, by creating a cutover plan that describes all cutover tasks that have to be performed before the actual go-live. Examples of cutover tasks are:

• Review and update all systems-related operations procedures like backup policies and system monitoring
• Assign ownership of SAP's functional processes to individuals
• Let SAP SE do a GoingLive check, to get their blessing to go live with the system
• Lock down the system, i.e. do not make any more changes to the SAP system

Go live & Support edit

All of the previously described phases all lead towards this final moment: the go-live. Go-live means to turn on the SAP system for the end-users and to obtain feedback on the solution and to monitor the solution. It is also the moment where product software adoption comes into play. More information on this topic:

• Product Software Adoption: Big Bang Adoption
• Product Software Adoption: Parallel Adoption
• Product Software Adoption: Phased Adoption

• SAP ERP
• T-code
• Product Software Adoption
• Wikipedia:WikiProject Method engineering

• Lui, Kim Man (2008). "Rescuing Troubled Software Projects by Team Transformation: A Case Study With an ERP Project". IEEE Transactions on Engineering Management 55 (1): 171 - 184. doi:10.1109/TEM.2007.912933.
• Anderson, G.W. (2003). SAP Planning: Best Practices in Implementation. Sams Publishing
• Francalanci, C. (2001). Predicting the implementation effort of ERP projects: empirical evidence on SAP/R3. Journal of information technology, Vol. 16, Issue 1, pp. 33–48.
• Hirt, S. G., Swanson, E. B. (1999). Adopting SAP at Siemens Power Corporation. Journal of Information Technology, Vol. 14, Issue 3, pp243–251.
• Krumbholz, M., Maiden, N. (2001). The implementation of enterprise resource planning packages in different organisational and national cultures. Information systems, Vol. 26, Issue 3, pp. 185–204.
• Sankar, C.S., and Rau, K-H., (2006). Implementation Strategies for SAP R/3 in a Multinational Organization, Cybertech Publishing, Hershey, PA, 2006.
• Xue, Y., Liang, H., Boulton, W.R., Snyder, C.A. (2005) ERP implementation failures in China: Case studies with implications for ERP vendors. International journal of production economics, Vol. 97, Issue 3, pp. 279–295.
• Yusuf, Y., Gunasekaran, A., Abthorpe, M.S. (2004). Enterprise information systems project implementation: A case study of ERP in Rolls-Royce. International journal of production economics, Vol. 87, Issue: 3, pp. 251–266.