Experienced SAP project managers know all too well that the approach and scope of a project must be carefully defined if it going to be successful. Large, complex, and global SAP projects present especially tremendous challenges: Project managers not only have to identify what, when, and how to implement the SAP system in a global environment, but this complex process must also then be managed in a way that minimizes the risks while optimizing the benefits to the business. Given that there are multiple approaches to implementation — from high-budget, high-risk, high-reward, big-bang approaches to phased approaches that vary considerably in scope and scale — how can decision makers ensure that they have considered all the relevant factors and made the best choices to meet their business needs?

To answer that question, I’ll use the analytic hierarchy process (AHP). It provides a real-world methodology for breaking down an implementation into manageable tasks that can be analyzed and aligned to meet their organization’s business objectives. More particularly, I have drawn on my own implementation experiences to identify several specific types of phased approaches that you can use to refine the decision-making process. I’ll show you how to design AHP decision hierarchies that can help you choose the approach or combination of these approaches most suited to your objectives.

Previous articles have focused on implementation methodologies (e.g., ASAP) that outline the different phases of a project implementation, project organization structure, and subsequent deliverables. This article takes a different approach: It aims, instead, at helping program managers, project managers, and team leads to define and design an optimal implementation approach. I’ll begin by distinguishing different kinds of phased approaches according to their predominating orientation: function, process, geography, organization units, or business partners. Then I’ll show you how to use the AHP methodology to sift through and organize the relevant data, trace various value chains, define and rank business criteria according to the needs and goals of the business, and then compare and rank the implementation options against those business criteria. I also assume you have a basic understanding of SAP implementation methodology, scope definition, and project management.

The Varieties of Implementation Approach

Organizations that have implemented SAP systems over time have differed widely in their needs and objectives, so a variety of approaches have naturally developed. A particular implementation approach is defined according to its own characteristic ways of grouping, timing, and sequencing all the elements necessary for developing and deploying SAP-enabled business processes. Because of this, two different companies that are both implementing, say, SAP ERP Financials may well take very different approaches: ABC Manufacturing Co. might roll out this solution in its UK regional offices before expanding into other regions; XYZ Medical Technologies might roll out the solution in its medical supplies division before extending it into its medical equipment and pharmaceuticals divisions. Both implementation approaches — the former regional, the latter organizational — share a number of common objectives, although their criteria for meeting those objectives differ. Among the key objectives that every implementation must take into account are:

• Effective timing and sequencing for implementation of SAP and business-related applications and technologies 
• Allowing early realization of business benefits and opportunities 
• Minimizing business disruptions 
• Improving the project’s risk management profile by recognizing the project’s impact on business units, end users, and customers 
• Presenting inputs for developing high-level estimates for the project timeline  
• Identifying the requirements for project resources and for technical infrastructure 
• Presenting a proposed roll-out schedule and its links to a firm’s legacy systems and any other relevant business or technology initiatives 
• Accounting for the complexities of various business processes and the impact of varied geographic scope, legacy systems, and data requirements across the firm 
• Reducing the total cost of ownership (TCO) of both SAP and any remaining legacy solutions or bolt-on business applications necessary for the SAP system 

In my example, both ABC Manufacturing and XYZ Medical Technologies, if they have done their implementation homework, undertake their respective implementation strategies because they are the most effective for timing and sequencing, realizing benefits and opportunities, minimizing business disruptions, and so on. Of course — and this is the kicker — they may find midway through their implementation that their analyses were incomplete, that they had failed to recognize certain risks or opportunities, and that another approach might have lead to better results. They might have even averted some costly mistakes.

Adequately understanding what characterizes the various approaches to implementation, then, can have vital consequences for the business. Before you see how AHP can help you analyze these approaches according to your own business requirements, let’s try to understand these various approaches in a little more detail.

Big Bang vs. Phased Approach to Implementation 

The big-bang SAP implementation approach, as the name implies, means the deployment of all future-state business processes with SAP and related technologies across the entire enterprise in a single phase. A typical example of a big-bang implementation might include implementing financial accounting (FI), sales and distribution (SD), materials management (MM), SAP ERP Human Capital Management (SAP ERP HCM), and production planning (PP) modules in a single phase across the entire enterprise — all of which go live at the same time, on the same date, for the enterprise’s entire user community.

A phased approach, on the other hand, means implementing future-state business processes with SAP and related technologies in multiple phases. The phases might be based on geography, business processes, business units or functional areas, and so on. An example of a phased implementation might include implementing FI followed later by MM, SD, PP, and SAP ERP HCM in subsequent phases or waves.

The big-bang approach leads to immediate standardization of business processes across the enterprise, maximizing the benefits. The approach eliminates any bridging strategy between legacy and SAP related solutions (as all legacy systems are migrated into SAP systems in this approach). Hence, there is no requirement of complex interfaces or interim business processes. The complexity of master data maintenance is drastically reduced because of the reduced number of non-SAP systems. In this approach, the project timeline to get to newer SAP business solutions could be long but the overall timeline in comparison with a phased approach to migrate to a future state may still be shorter. This approach provides an opportunity to synergize the resources across multiple and diverse teams.

However, there are high risks associated with implementing the solution across the enterprise. This significantly increases the requirements for training, change management, and post-implementation support. Due to a large scope and team, this approach requires a solid project and program management structure. Finally, the approach requires business readiness for absorbing and sustaining the changes that accompany such a project, along with having a concrete business continuity plan.

In contrast, the phased approach means a more manageable scope, project structure, and team structure, leading to a sustainable implementation. This approach can focus effort on training and change management with overall reduced risk. In particular, this approach affords the opportunity to leverage the learning from initial phases to the subsequent phases of the project. This approach also simplifies business sustainability and business continuity plans.

On the other hand, the phased approach needs a bridging strategy, which adds to the cost of the project from designing and maintaining throwaway interfaces. This approach also requires support structure for both legacy environment and SAP related technologies, thereby adding to the TCO of diverse systems to support the business. The phased approach also drives interim business processes and complex master data maintenance across multiple systems.

Drivers of a Phased-Approach Implementation

Many factors, both external and internal, drive an organization’s ability to implement complex SAP solutions toward a phased approach to implementation. Budget and resources represent the most obvious constraints, but there are many others. For example, one company’s executives may be leading the charge for implementation, recognizing the vital need for better business intelligence than its multiple non-communicating legacy systems can provide, yet the long process of getting end users up to speed and developing adequate reporting may dictate a tightly controlled process and phased approach. At another company, end users may be clamoring for more effective systems, while the company’s precarious market position leads to executive risk aversion. Nor is it uncommon to find that the eagerness of executives, IT staff, and end users for implementation is confronted by a scarcity of qualified project managers. All these factors amount to constraints and tend to drive organizations to implement SAP systems in a phased manner since anything else proves unsustainable.

Given the need, then, to carefully manage and execute a phased approach — and it is quite a balancing act to manage all the likely constraints — let’s examine the various kinds of phased approaches in more detail. By understanding their differing emphases, their pros and cons, and the tensions among them, you can have a stronger basis for your decisions.

Variations of a Phased-Approach Implementation 

In the following sections, I’ll analyze in detail different types of phased-approach implementations. The analysis highlights the benefits and implications of functional approach, business process approach, organizational approach, and business partner phase implementation approach.

Functional Approach 

As its name implies, the functional approach focuses on implementing a business function or functions across an enterprise. An example of this approach might involve deploying accounts payable (AP) and accounts receivable (AR) company-wide. Another example might be implementing Payroll across an enterprise, or introducing a particular component of SAP ERP HCM to the entire company’s employee base.

The functional approach has a very defined and limited scope, business user group, and business benefits, thereby making it less risky in comparison to the big-bang approach. The risk is limited to the target business group for the functional implementation. The functional approach has fewer dependencies in cross-functional areas and a relatively easy buy-in. The overall project management, training, and execution are simpler in this approach. The approach can lead to early realization of benefits and set up an environment for project success for the implementation and business team.

However, the functional approach defers the benefits for the functional areas not part of the implementation and thus has reduced benefits from an overall enterprise standpoint. The benefits from the new processes could be suboptimized due to piecemeal implementation. The approach calls for the additional effort and maintenance of bridging interfaces and the solutions can lead to a lack of integration across business functions for a substantial period of time. The interim business solutions can lead to adverse employee performance due to the length of the transitional period before integration in other functional areas.

Business Process Approach

In the business process approach, the focus of implementation is on deploying one or more end-to-end business processes (e.g., plan-to-produce, order-to-cash, hire-to-retire). Each business process stands alone but touches multiple functional areas, affects different user communities, and probably affects different geographies, as well.

The business process approach directs the enterprise on high-value initiatives and rapid success. For example, a consumer business can drive maximum benefits by implementing the order-to-cash business process. The approach facilitates the development of the business process view for the enterprise. The business process view offers a higher degree of integration between system and processes.

It is very difficult to segment highly integrated business processes. This approach implements standalone end-to-end business solutions, thereby requiring bridging and throwaway interfaces. The approach requires major training, communication, resources, and effort across the enterprise.

Organizational Approach 

The organizational approach to implementation involves the implementation of functions and processes in a single organization before rolling out similar functionality or business processes to second, third, and subsequent organizations. This type of approach lends itself to businesses made up of independent operating companies, agencies, or business units. One of the key assumptions for this approach is that the legacy system must be able to be phased out by each organization as it adopts SAP systems.

The organizational approach is sometimes called the geographic approach. In the geographic approach, the focus of the implementation is a single geographic area (which may comprise a number of organizational or business units as well as business processes). For a global implementation, the geographic approach might be country-specific.

The organizational or geographic approach leverages the physical boundaries between the organization and the geography for a phased implementation. The advantage in this approach is the migration of an organization or geography in the future business solution, thereby paving the way for a rapid implementation across multiple organizations or geographies. This approach also gives an opportunity to formulate and sustain support structures in a phased manner and drive the scalability of future needs.

Invariably though, the global design decisions lengthen the overall implementation time and difficulty in coming to a global consensus on the major design decisions. In addition, this approach requires good master data strategy and BI strategy to drive the consolidated reporting requirements across the organization or geography. The dynamism of business can also lead to functionality changes in the organization already live with the SAP system, making managing the business changes tricky. A strong scope management approach is needed until all the organization units or geographies have moved to the new solutions.

Business Partners Approach 

The business partners approach involves the implementation of functions or processes for a group of customers or vendors before rolling out the functionality to a subsequent group of customers or vendors.

An example of this approach is implementing order-to-cash for Electronic Data Interchange (EDI) customers followed by implementing order-to-cash for other customer groups. One of the key assumptions is that the customer group should be separate from a business perspective.

This approach offers an alternative to reduce potential effects on wider business partners and reduction in risks by cash flow effects because of the change. However, it also creates some challenges in segregating the business partners suitable for the implementation. Additionally, the approach can lead to partners dealing with multiple systems and require design and configuration for the entire partner’s base. The approach may also require bridging interfaces and a solid master data strategy encompassing multiple systems.

An SAP implementation might actually include any number of combined approaches as discussed previously. For example, a firm might initiate an organizational roll-out (e.g., requisition-to-check for a division or a business unit), followed by a roll-out predicated on specific organizational, geographic, or business partner needs and goals.

Phased Approach Implementation Evaluation 

The following section discusses the AHP to evaluate alternatives for optimal implementation. The AHP is a structured technique to help make complex decisions. The AHP model breaks the goal into a hierarchy of quantitative or qualitative criteria and subcriteria that you can analyze separately. Once the hierarchy is built, pairwise comparison is performed for each combination of criteria and subcriteria by a cross-functional team of IT and business users drafting the overall implementation plan. The model converts the comparisons to numerical values and a numerical weight or priority is derived for each node in the hierarchy. In the final steps, numerical priorities are derived for each of the alternatives.

The AHP modeling I’ll describe is an illustration of how it can help you make a decision about an optimal implementation approach. Depending on the client situation, the evaluated alternatives vary and could be a combination of approaches discussed in the previous section. On the same lines, the pair-wise comparison of the criteria and subcriteria vary and in some cases it can be based on pure values rather than qualitative comparison (e.g., cost).

Step 1. Model the Goal as a Hierarchy 

An AHP hierarchy is a structured way of defining the goal. The different elements of the AHP hierarchy are the overall goal, a group of alternatives and criteria that relate the alternative to the goal. You can break down the criteria into subcriteria depending on the complexity of the problem. In this illustration, the optimal implementation approach is the defined goal. The groups of alternatives are a big-bang approach, functional approach, business partner approach, business process approach, and organizational approach.

In this example, the main criteria that relate the alternatives to the goal are organizational readiness, risks, benefits realization, and technology solution. Each of these criteria is further broken down into subcriteria: For example, change management, post-implementation, training, skills availability, and business disruption are subcriteria for the main criterion organizational readiness. Each of the boxes in the hierarchy is called a node. See Figure 1 for the goal, criteria, and subcriteria in the hierarchy. In this illustration, the AHP software model available at www.ahpproject.com is used to perform the selection of the optimal implementation. The hierarchy elements are defined in this step for the goal in the software application.

Figure 1

Goal, main criteria, and subcriteria as defined in the AHP software model (www.ahpproject.com)

Step 2. Establish Priorities for the Criteria and Subcriteria by Pair-Wise Comparison 

Once the hierarchy is defined, the AHP model is used to establish the priorities for the nodes defined above. The priorities indicate the relative weight given to the criteria in a given group of nodes. The weight refers to the relative importance, preference, or likelihood being considered by the evaluation team. In the initialization process, the AHP software, which is free to download at www.ahpproject.com, by default gives equal priority to all the criteria with the group of nodes. As the AHP process continues the priorities change from the default values to reflect the judgment of the evaluation team about the various criteria within a group.

Pairwise Comparison

The pairwise comparison of the criteria with respect to the goal is scored by the model for the following combinations:

• Organizational readiness vs. risk
• Organizational readiness vs. cost
• Organizational readiness vs. benefits realization
• Organizational readiness vs. technology solution
• Risk vs. cost
• Risk vs. benefits realization
• Risk vs. technology solution
• Cost vs. benefits realization
• Cost vs. technology solution
• Benefits realization vs. technology solution

The comparison is performed by selecting the dominant element and the value on a scale from 1 to 9. In certain comparisons, you can perform direct rating if the values for the criteria can be mathematically evaluated. See Figure 2 for the pairwise comparison between risk and organizational readiness as an example.

Figure 2

Pairwise comparison of organizational readiness vs. risk

The pairwise comparison is performed for all the combinations defined above and the values are directly entered in the AHP software. The AHP software uses mathematical calculations (eigenvector values) to convert these judgments into priorities for each criterion. The software also calculates a consistency ration (CR) that expresses the internal consistency of the judgments that have been entered. When you compare elements in pairs you may be inconsistent. The rule of thumb is to keep the CR at less than 0.1. If the CR is greater than 0.1, you should improve the consistency of comparisons by reassessing the pairwise comparison. The software returns the priorities of the criteria for all the nodes within the group. The result from the software is shown graphically in Figure 3.

Figure 3

Priorities of the criteria from the AHP software

Once the priorities have been established for the main criteria, the pairwise comparison is performed for all the subcriteria within the main criteria. For example, the pairwise comparison is performed for the subcriterion change management, post-implementation, training, skills availability, and business disruption within the criteria organizational readiness. The pairwise comparison is repeated for all the other subcriteria.

Step 3. Compare Alternatives

You then need to compare the alternatives of the lowest nodes in the hierarchy. Figure 4 depicts an example of a comparison of the possible implementation approaches for the subcriterion change management. For comparison between a big-bang approach and a functional approach for the change management subcriterion, it is relatively simple to perform the change assessment and deploy the tools to manage the change in the functional approach as compared to the big-bang approach. Table 1 shows the definition of the subcriteria and questions to evaluate alternatives.

Figure 4

Alternative comparison of the change management subcriteria

Figure 1

Definition of subcriteria and questions for alternative comparison

Figure 5 shows all the evaluated subcriteria for each main criterion and the alternatives comparison evaluation from the AHP software program. The consistency ratio is also shown in Figure 5. Note the CR value for all the comparison is less than 0.1, which signifies consistency in the pairwise comparison in this example.

Figure 5

The evaluated subcriteria and consistency ratio

At this point, all comparisons of the criteria and subcriteria have been performed and the AHP software has calculated the local priority for each node at each level. Also, as you know how much the priority of each subcriterion contributes to the priority of the parent node and the priority of the parents to the goal, the AHP software calculates the global priority of each subcriterion.

As an example, the global and local weight (priority) of the criterion organizational readiness is 0.34 (Figure 6). Figure 7 shows the scores of the alternatives relative to the criterion organizational readiness.

Figure 6

Weight (priority) of organizational readiness criteria relative to all other nodes at this level

Figure 7

Alternative results for the organizational readiness criterion

As a result, the AHP software program based on the AHP hierarchy, global priorities, and alternative comparisons outputs the summary score (Figure 8). In this illustration, the business process approach is the optimal approach with 0.234 followed by business partners and the organizational approach. The closeness of the business partners approach and organizational approach may prompt you to perform the AHP analysis again for these three alternatives only and derive the optimal implementation approach.

Figure 8

Summary score for all the evaluated alternatives

The following section outlines some of the tools to perform further analysis of the alternatives and expands on the calculation of local and global priorities.

Sensitivity Analysis

The AHP program generates the sensitivity charts for each node. It provides analysis on how the alternatives ranking behaves in response to changes in priorities. Figure 9 shows an example in which the current priority value of the criterion organizational readiness is 0.34, so the optimal implementation is the business process approach followed by the business partners approach. If the priority of the criterion organizational readiness is increased to 0.55, then the optimal implementation approach is the business partners approach followed by the business process approach. The AHP program allows you to perform the sensitivity analysis at any of the nodes and analyze the criteria and subcriteria.

Figure 9

Sensitivity analysis of organizational readiness criteria

As indicated earlier in the article, the AHP software calculates the local and global priority of all subcriteria. In the following section, the graphical results of the subcriterion change management within the criterion organization readiness is shown. Figure 10 indicates the local priority of change management (0.18) with respect to other subcriteria (training, skills availability, post-implementation, and business continuity) within the criteria organizational readiness. The global priority of the change management criterion is the product of the parent organizational readiness global priority (0.34) and change management’s local priority (0.18), which is 0.06.

Figure 10

Local and global weight (priority) of the subcriterion change management

Figure 11 shows another illustration of sensitivity analysis at the change management node. If the local priority change management changes to more than 0.60, then the optimal implementation changes to the business partners approach.

Figure 11

Sensitivity analysis of the change management criterion

Head-to-Head Comparison of Alternatives 

The AHP program outputs radar charts to provide a comparison between two selected alternatives. The radar charts for the head-to-head comparison for the business process approach and business partners approach is shown in Figure 12 for main criteria and Figure 13 for subcriteria. The radar charts are useful in this example because of the relative closeness of the summary scores of these approaches. In Figure 12, the business partners approach outweighs the Business process approach for the risk and organization readiness criteria but falls behind the other criteria technology solution, benefits realization, and cost. The radar chart in Figure 13 indicates the spread of subcriteria for the business process approach and business partner approaches. The chart highlights the subcriteria where the business process approach outweighs the business partner approach and vice versa.

Figure 12

Head-to-head comparison of the business process approach vs. the business partner approach: major criteria

Figure 13

Head-to-head comparison of the business process approach vs. business partner approach: subcriteria

Jeetendra Kumar

Jeetendra Kumar is the IT director at Coca-Cola Enterprises, Inc. Prior to Coca-Cola Enterprises, Jeetendra worked as a consultant at Deloitte, IBM, PricewaterhouseCoopers, and HCL Infosystems in their respective SAP practices.

You may contact the author at k_jeetu@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.