Volume 13, Update 4 • Use the AHP … · 2019-11-12 · organization units, or business partners. Then I’ll show you how to use the AHP methodology to sift through and orga-nize

Volume 13, Update 4 • www.SAPpro.com

©2011 SAP Professional Journal • Reprinted with permission from the 2011 Update 4 issue of SAP Professional Journal • Reproduction or distribution in any form is strictly prohibited without the permission of the publisher, Wellesley Information Services.

This article is found in the SAP Professional Journal knowledgebase where new articles are added every week.

Articles in the SAP Professional Journal knowledgebase help you overcome your toughest SAP challenges. They’re packed with detailed instruction, best prac-

tices, and guidance not found anywhere else on ABAP, Java development, master data management, performance optimizing and monitor-ing, portal design and implementation, upgrade and migration strategies, and many other topics. Your 12-month subscription gives your entire team access to the most sought-after expertise from the world’s top experts in SAP technology. It’s like adding additional experts to your SAP team who have all the answers — without the cost of hiring them. Subscribe at www.sappro.com.

This document is for your personal use only. Reproduction or distribution in any form is strictly prohibited without the permission of the publisher, Wellesley Information Services. For information about the SAP Professional Journal and other WIS publications, visit www.sappro.com

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

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) (a multicriteria decision-making method-ology that Michal Szymaczek intro- duced to SAP Professional Journal readers in his article, “Encourage Effec-tive Decision Making with the Analytic Hierarchy Process” at www.sappro.com/article.cfm?id=3650). It provides readers with a real-world methodology

Experienced SAP project managers know all too well that the approach and scope of a project must be carefully defined if it is going to be successful. Large, complex, and global SAP proj-ects 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 then must also be managed in a way that minimizes the risks while optimiz-ing the benefits to the business. Given that there are multiple approaches to implementation — from high-budget, high-risk, high-reward, big-bang

Understand the complexities of breaking down a complex SAP project implementation into manageable chunks, reflecting a scope capable of aligning with and meeting an organization’s specific goals. Build an implementation approach and business case by understanding the advantages and disadvantages of variations of the phased approach. Finally, learn how to use the analytic hierarchy process (AHP) model to evaluate the alter-natives in a scientific way, as well as perform sensitivity analysis and a head-to-head comparison of alternatives.

Use the AHP Methodology to More Effectively Define and Evaluate Your SAP Implementation Approach

by Jeetendra Kumar, IT Director, Coca-Cola Enterprises, Inc.

Besides the implementation approach, the analytic hierarchy process (AHP) evaluation helps build alignment among business stakeholders and the project team. A workshop approach with the key business stakeholders and the project leadership team can help drive the aligned path for implementation. The AHP evalua-tion helps define the scope and draw boundaries to drive a suc-cessful implementation.

Key Concept>>


you how to design AHP decision hierar-chies 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 differ-ent 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 orien-tation: function, process, geography, organization units, or business partners. Then I’ll show you how to use the AHP methodology to sift through and orga-nize 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 methodol-ogy, scope definition, and project management.

Introduction: The Varieties of Implementation ApproachOrganizations that have implemented SAP systems over time have differed widely in their needs and objectives, so a variety of approaches has 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 deploy-ing SAP-enabled business processes. Because of this, two different compa-nies that are both implementing, say, SAP ERP Financials may well take very different approaches: ABC Manufactur-ing Co. might roll out this solution in its UK regional offices before expanding into other regions; XYZ Medical Tech-nologies 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 objec-tives, 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 manage-ment profile by recognizing the proj-ect’s impact on business units, end users, and customers

• Presenting inputs for developing

high-level estimates for the project timeline

• Identifying the requirements for proj-ect resources and for technical infra-structure

• Presenting a proposed roll-out sched-ule and its links to a firm’s legacy systems and any other relevant busi-ness or technology initiatives

• Accounting for the complexities of various business processes and the impact of varied geographic scope, legacy systems, and data require-ments across the firm

• Reducing the total cost of ownership (TCO) of both SAP and any remain-ing legacy solutions or bolt-on busi-ness applications necessary for the SAP system

In my example, both ABC Manufactur-ing 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 dis-ruptions, 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 charac-terizes 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.

There are a handful of other good sources you should read in con-junction with this article. One is Michal’s article that I mentioned earlier. Another, for more founda-tional information, is Michal’s 2005 SAP Professional Journal article “Reduce Project Risk by Integration Project Management Body of Knowledge (PMBOK) Tools and Techniques with ASAP," which you can read at www.sappro.com/article.cfm?id=3405. You should also check out the book SAP Plan-ning: Best Practices in Implemen- tation, written by SAP Professional Journal technical advisor George Anderson.

Note>>



Big Bang vs. Phased Approach to Implementation The big-bang SAP implementation approach, as the name implies, means the deployment of all future-state busi-ness 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 account-ing (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 busi-ness 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 im-mediate standardization of business processes across the enterprise, maxi-mizing the benefits. The approach eliminates any bridging strategy between legacy and SAP related sol-utions (as all legacy systems are migrated into SAP systems in this approach). Hence, there is no require-ment for 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 in-creases 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 manage-ment structure. Finally, the approach requires business readiness for absorb-ing 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 struc-ture, 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 sub-sequent phases of the project. This approach also simplifies business sustain-ability 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 inter-nal, drive an organization’s ability to

implement complex SAP solutions toward a phased approach to implemen-tation. Budget and resources represent the most obvious constraints, but there are many others. For example, one com-pany’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 aver-sion. 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 under-standing 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 a 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 func-tional implementation. The functional approach has fewer dependencies in cross-functional areas and a relatively easy buy-in. The overall project manage-ment, 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 enter-prise 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 integra-tion 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 trans-itional period before integra-tion in other functional areas.

Business Process Approach In the business process approach, the focus of implementation is on deploy-

ing 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 multi-ple 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 con-sumer business can drive maximum benefits by implementing the order-to-cash business process. The approach facilitates the development of the busi-ness 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 inter-faces. The approach requires major training, communication, resources, and effort across the enterprise.

Organizational Approach The organizational approach to imple-mentation involves the implementation of functions and processes in a single organization before rolling out similar functionality or business processes to second, third, and subsequent organiza-tions. This type of approach lends itself to businesses made up of independent oper-ating 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 organi-zation as it adopts SAP systems.

The organizational approach is some-times called the geographic approach. In the geographic approach, the focus of the implementation is a single geo-graphic 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 bound-aries between the organization and the geography for a phased implementation. The advantage in this approach is the migration of an organization or geogra-phy in the future business solution, thereby paving the way for a rapid implementation across multiple organi-zations 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 imple-mentation 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 organiza-tion already live with the SAP system, making managing the business changes tricky. A strong scope management approach is needed until all the organi-zation 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 function-ality to a subsequent group of customers or vendors.

An example of this approach is imple-menting order-to-cash for Electronic Data Interchange (EDI) customers fol-lowed by implementing order-to-cash for other customer groups. One of the



key assumptions is that the customer group should be separate from a busi-ness perspective.

The approach offers an alternative to reduce potential effects on wider busi-ness 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 implementa-tion. Additionally, the approach can lead to partners dealing with multiple systems and require design and config-uration for the entire partner’s base. The approach may also require bridg-ing 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 sepa-rately. Once the hierarchy is built, pairwise comparison is performed for each combination of criteria and sub-criteria 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 situation, the evaluated alterna-tives vary and could be a combination

of approaches discussed in the previ-ous section. Along 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 differ-ent elements of the AHP hierarchy are the overall goal, a group of alter-natives, 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 alternatives are a big-bang approach, functional approach, business partner approach, business process approach, and orga-nizational approach.

In this example, the main criteria that relate the alternatives to the goal are organizational readiness, risks, cost, 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, crite-ria, 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.

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

Figure 1


parisons, you can perform direct rating if the values for the criteria can be mathe-matically evaluated. See Figure 2 for the pairwise comparison between risk and organizational readiness as an example.

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 ratio (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 reas-sessing the pairwise comparison. The software returns the priorities of the crite-ria for all the nodes within the group. The result from the software is shown graphi-cally in Figure 3.

Once the priorities have been established for the main criteria, the pairwise com-parison is performed for all the subcriteria within the main criteria. For example, the pairwise comparison is performed for the subcriterion change

Pairwise comparison of organizational readiness vs. risk

Figure 2

Priorities of the criteria from the AHP softwareFigure 3

Step 2. Establish Priorities for the Criteria and Subcriteria by Pairwise Comparison Once the hierarchy is defined, the AHP model is used to establish the priorities for the nodes defined above. The priori-ties 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 initializa-tion 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 select-ing the dominant element and the value on a scale from 1 to 9. In certain com-



management, post-implementation, train-ing, skills availability, and business disruption within the criterion organiza-tional 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. Fig- ure 4 depicts an example of a comparison of the possible implementation approaches for the sub-criterion 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.

In this example, the dominant element is the Functional approach and the value selected is Strong importance plus. Sim-ilarly, all the other alternative pairs are compared using the change manage-ment criteria. The step is repeated for all the lower-level nodes. As indicated above, Table 1 defines some of the sub-criteria and assists the user of the AHP software program to select the dominant element and define the value for the element in the illustration for optimiz-ing the implementation approach. In addition, the earlier section of the article that describes the different approaches of implementations should help you determine the value while per-forming the alternative evaluation.

Figure 5 shows all the evaluated subcri-teria for each main criterion and the alternatives comparison evaluation from the AHP software program. The consis-tency ratio is also shown in Figure 5.

Note the CR value for all the compari-son is less than 0.1, which signifies consistency in the pairwise comparison in this example.

At this point, all comparisons of the criteria and subcriteria have been per-formed 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 organi-zational readiness is 0.34 (Figure 6). Figure 7 shows the scores of the alternatives relative to the criterion orga-nizational readiness.

As a result, the AHP software program based on the AHP hierarchy, global priori-

Alternative comparison of the change management subcriterionFigure 4


ties, and alternative comparisons outputs the summary score (Figure 8). In this illustration, the business process approach is the optimal approach with 0.234 fol-lowed by business partners and the organizational approach. The closeness of the business partners approach and orga-nizational approach may prompt you to perform the AHP analysis again for these three alternatives only and derive the optimal implementation approach.

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

Sensitivity Analysis The AHP program generates the sensi-tivity charts for each node. It provides analysis on how the alternatives rank-ing 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 organiza-tional 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.

As indicated earlier in the article, the AHP software calculates the local and global pri-ority of all subcriteria. In the following section, the graphical results of the subcri-terion 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 availabil-ity, post-implementation, and business continuity) within the criterion organiza-

tional 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 11 shows another illustration of sensitivity analysis at the change manage-ment node. If the local priority change management changes to more than 0.60, then the optimal implementation changes to the business partners approach.

Subcriterion Definition and questions for alternatives evaluation

Speed of benefits The criterion is to evaluate the need of early realization of the ben-efits in the organization. Will the evaluated option help in realizing quick optimization of the business process, lead to data integrity, help decommission legacy applications, and standardize the busi-ness process?

External business partners impact

The criterion is to evaluate the positive or negative impact on exter-nal business partners such as vendors and customers. Will the evaluated option enhance external customer and vendor business processes? Does the customer or vendor need to interact with mul-tiple systems?

Scale of business risk The criterion is to evaluate the scale of business risk in terms of business continuity and disruptions to the business cycle. Will the evaluated option affect the entire customer base and impose risks on the revenue and shareholders’ value?

Bridging cost The criterion is to evaluate the building of the transitional interfaces to support the phased implementation. Will the evaluated option have fewer throwaway interfaces to be built?

Skills availability The criterion is to evaluate the availability of internal and external resources for the approach. Will the evaluated option require skills that have wider availability? Will the evaluated option require build-ing a knowledgebase or require external resources?

Probability of completion

The criterion is to evaluate the completion of the in-scope function-ality for the approach. What is the likelihood of the completion with the evaluated approach compared to other approaches?

Scalability The criterion is to evaluate the scalability of the solution for future changes to the business processes. Will the approach support the opportunities for growth in the business?

Post-implementation support

The criterion is to evaluate the organizational needs to support the post-go-live phase. Will the approach require multiple teams to support transitional functions in the business? Will the approach require support in future-state solutions and phasing out legacy solutions?

Change management The criterion is to evaluate the change management impact on the business. Will the approach facilitate changes to the organization, processes, and functions in manageable and sustainable pieces? Will the approach reduce the change management complexity? Will the approach take into account the business readiness for the change?

Training The criterion is to evaluate the ease of the execution of train-ing strategy to the business users. Will the approach facilitate sustainable learning to the end user? Will the approach optimize the training delivery to the end user in terms of timeliness and resources to impart the knowledge?

Master data and data conversion

The criterion is to evaluate the ease of master data maintenance and data conversion. Will the approach require master data in mul-tiple systems and increase the complexity to maintain data in sync? Will the approach reduce the complexity of transactional data migra-tion in terms of open items or mid-year conversion?

Definition of subcriteria and questions for alternative comparisonTable 1



The evaluated subcriteria and consistency ratio

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

Figure 6

Alternative results for the organizational readiness criterionFigure 7


Summary score for all the evaluated alternatives

Sensitivity analysis of organizational readiness criteria

Figure 8

Figure 9



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 out-weighs the business process approach for the risk and organization readiness criteria but falls behind the other crite-ria technology solution, benefits realization, and cost. The radar chart in Figure 13 indicates the spread of sub-

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

Sensitivity analysis of the change management criterion

Figure 10

Figure 11


criteria for the business process approach and business partner approaches. The chart highlights the sub-criteria where the business process approach outweighs the business partner approach and vice versa. n

Other good AHP resources include the book How to Make a Decision: The Analytic Hierarchy Process by Thomas L. Saaty, published by RWS Publications, and “An illus-trated guide to the Analytic Hierarchy Process,” by Rainer Haas and Oliver Mexiner at www.fakr.noaa.gov/sustainablefisher-ies/sslmc/july-06/ahptutorial.pdf.

Note>>

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

Figure 13

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

Figure 12

Jeetendra Kumar is the IT director at Coca-Cola Enterprises, Inc. Prior to Coca-Cola Enterprises, Jeetendra worked as a consultant at Deloitte, IBM, Price-

waterhouseCoopers, and HCL Infosystems in their respective SAP practices. You may contact Jeetendra via email at [email protected] or [email protected].

Documents

Volume 13, Update 4 • Use the AHP … · 2019-11-12 · organization units, or business partners. Then I’ll show you how to use the AHP methodology to sift through and orga-nize