Stop Seeking 'Average' in ERP — It Doesn't Exist

Organizations should not attempt to substantiate, or limit, ERP investments based on "average" costs and benefits, which don't take into account the context. Doing so leads to inaccurate budgeting and increased risk, for both the enterprise and the responsible ERP leader.

Key Findings

• Organizations attempt to substantiate ERP investment by seeking averages with which to measure the costs and benefits of such an endeavor.
• ERP leaders who build business cases based on averages don't take into account the context; often leading to budgetary misalignment and unrealizable management expectations.
• Reasons for averages not applying generally fall into four key areas: functional fit, geography, organization and the scope of the project.

Recommendations

• Concentrate efforts on building a clear ERP strategy that meets organizational needs.
• When estimating the effort and cost of implementing a given ERP solution, identify the complexity factors that will influence the outcome.

Analysis

During client inquiries, Gartner receives a long stream of requests for averages — across a spectrum that ranges from licensing to implementation costs to support — on which clients seek to base their ERP investment decisions.¹ The analyst response is consistent, "Seeking averages that do not account for context is potentially misleading and always inaccurate." Not accounting for an enterprise's particular context can lead to inadequate budgeting, misalignment of executive and user expectations, potential loss of momentum and potential project failure. Below, we examine the 13 most common averages requested by our clients, the reasoning behind why seeking an "average" is generally ill-advised, and how ERP leaders should instead approach each topic area. For all the reasons outlined here, Gartner does not maintain benchmarking data on "ERP" implementations. It would be impossible to create a meaningful sample size where the projects were comparable, because the individual contexts vary so much.

1. License Costs

Reasoning

Vendor license pricing is not linear — and there is no single approach by vendors. Attempting to draw conclusions based on averages, even against companies of a similar size, can definitely be misleading. Some ERP vendors price their solutions based on the region, with significant variances between regions, and the current competitive landscape — which changes constantly.

Alternatively, vendors might base pricing on a global list price, but incorporate numerous options for regional sales offices and/or partners to arrive at a competitive bid through highly creative "discounts." You might also find that it is less expensive to buy all of your licenses in one region, whether through the local direct office or a partner. Be cautious though, because this can greatly affect discounting and can have a profound impact on the quality of support delivered, or even the propensity of local support partners to show an interest in working with you or adhering to the same discounts you gained elsewhere. The regions in which you are considering using the application and the region where you finally settle on purchasing the licenses can greatly affect pricing: Regional variance alters any potential average calculation — ruling averages impractical.

It's also important to note that comparison of licensing costs has become even more difficult, because ERP initiatives now frequently include a mix of on-premises perpetual licenses and cloud subscription licenses that varies with every initiative. Additionally, there are different variants of cloud (such as public SaaS, private cloud, managed SaaS, hosted, and others), where the licensing models can be different. This means that aggregating up to averages becomes more misleading than ever.

Additional Reasons Influencing Vendor Discounts

The following is not an exhaustive list:

• Microindustry — The vendor is trying to build a presence in a particular industry subsector (for example, Caterpillar equipment dealers, commercial banking, or the dairy sector within the food and beverage sector).
• Country — The vendor is trying to build credibility or customer count, or to ramp up a new partner in a particular country.
• Potential user count or "deal" size — If your deal will increase the vendor claims of high seat deployments, or the deal size is significant, then discounts can be greatly affected.
• Functional add-ons available from the vendor or partner — Each add-on increases the deal price, and the mix of add-ons will vary from enterprise to enterprise.
• Fiscal period — The vendor's financial quarters, particularly at year-end, can make a difference to its propensity to discount.
• Partner intellectual property (IP) — Partners may often discount more heavily than a vendor selling directly, particularly where the solution includes IP developed by the partner — meaning that the partner receives the lion's share of license revenue for those parts that increase the overall revenue value, enabling more flexibility regarding discounts.
• Salesperson incentive (that is, this deal will get the salesperson into the 100% club) — An individual salesperson has minimal ability to vary the price without escalating to someone else, but the salesperson's tenacity to pursue a discount for you can be influenced by sales incentives. In addition, the salesperson doing the deal is influenced by how his or her business unit is performing against the forecast and against other regions. This will impact both the initial quote and the approach to negotiation. When on target with his or her regional or personal quota, initial quotes are often higher (that is, there is little to lose). When short of quota, initial offers tend to be lower and negotiation can be seen to be more flexible. Do not be afraid of lightly questioning the salesperson about their circumstance; any intelligence in this area can help you gain the upper hand.
• Service opportunity — Reseller partners, in particular, are prone to discounting licenses where the service content makes it worthwhile. For example, if a partner receives a 40% discount from the OEM vendor (usually the developer of the product) for reselling the product, the partner has the potential to pass all of this discount on to the customer if the implementation and customization services are significant, because it will likely gain most, if not all, of the service revenue.
• Brand value — The potential for a vendor or reseller to apply discounts can also be based on how important the addition of your brand is to its customer list.
• We use the qualifier "potential" in this context, because many vendors do not publish their price lists. This is not just through policy, but also sometimes because an intermediary is involved (a partner). The license price from the OEM vendor relates only to the part provided to the partner, not the solution that the customer receives. The solution could incorporate additional products and services that make up the overall solution to the customer. In some cases, you cannot license the product directly from the OEM (the developer of the software), but only through a partner.
• Competition — Vendors are locked in an unending battle to gain or retain customers and market share, or to encroach on another vendor's heartland. Examples include one vendor seeking to prevent another vendor from taking its customers by heavily discounting to keep the customer and maintain lucrative maintenance revenue. A vendor could also seek to sell into an organization where a competitive vendor is already an incumbent.

Advice

• Gain a clear understanding of how important your brand is to the vendor. Don't underestimate this value, and use it to your advantage during contract negotiations in terms of references, case studies, press use of your brand name and so on. Don't be afraid to start a dialogue from a position of "We don't allow any press — period."
• Be clear on how the solution costs break down and whether you are signing on partner paper or that of the owner or developer, because it may alter the vendor's ability to negotiate. Also, understand the escalation route for negotiation — that is, if the salesperson exceeds his or her authority, who is next in line, next after that and so on.
• Don't be afraid to escalate the issue with the vendor, but, before doing so, be very clear what you want the outcome to be. Vendor executives rarely get into details; they generally make discounting decisions based on the commercial value of the deal, but sometimes on more personal grounds such as their favorite sports team, or even more arbitrary reasoning.
• You get only one chance to be a new customer for a vendor, and the initial deal size could greatly influence costs for future licenses. Aiming to minimize the initial deal size in an attempt to reduce initial costs can limit your overall ability to gain discounts and may even negatively impact long-term license costs — because, under certain circumstances, the cost of licenses for up to three years after the original contract can be set at a discounted figure. Such negotiations would not be picked up as an average.
• There is no average deal size that will tip the balance, not least because deal size is not the only consideration for the vendor. When buying on-premises solutions, make sure you understand the pricing implications of phased licensing (that is, buying as you go) versus fixing all licenses at the start of the relationship and merely adding the licenses at each phase. Beware of buying "shelfware." Many companies prelicense to gain discounts, only to find that business circumstances alter and they are left with unused seats for which they have paid, or which they are committed to license.
• Be aware of the timing of your questions related to licensing and costs, because the vendor's response could very well depend on it. Also, consider timing when comparing vendors: They don't all perform at the same level; they don't organize themselves in the same way; and they don't all share the same financial period ends.

2. Anticipated Business Benefits Realized

Reasoning

Each organization approaches ERP investment and the resulting initiatives for different reasons. They approach from different competence and business performance baselines and with different sets of legacy systems. They also have differing aspirations and differing abilities to fulfill them. Establishing any type of average business benefits calculation is misleading and will be completely inaccurate. However, just because it is foolhardy to seek average business benefits realized and to apply them to your business case, that is no excuse for not building a solid benefits case.

There are still too many ERP implementations that do not have a robust or consistent benefits case. Far too often, the benefits identified in the business case are, at best, aspirational and, at worst, absent. One reason is simply the timing of the creation of the business case, which precedes the formation of the project, engagement of business process owners and, usually, a detailed understanding of the benefit potential of the investment. Even those enterprises that develop a sound benefits plan within the business case often fail to establish a robust baseline, and do not actively track and measure the actual benefits delivered during the project. Worse still, many organizations simply fail to hold business leaders and managers individually and collectively accountable to deliver these benefits. So, whatever the benefit potential was when the business case was developed, it may simply fail to be delivered or (at the very least) will be underrealized.

During the course of the project, decisions are often made without knowledge of their impact on the benefits case, leading to potential erosion of benefits. Where enterprises do implement tracking and measurements, this effort often stops too soon after go-live to accurately capture the full benefits achieved — since ERP implementations may yield benefits that take months or sometimes years to fully capture. In this situation, there is rarely any attempt to drive for additional benefits (beyond the business case), so money can be "left on the table." Project fatigue is one cause of this last situation.

Advice

• Create a benefits realization work stream in the project that commences in the ERP strategy and plan phases and continues through to the operate and evolve phases. Ensure that a clear baseline is established for the benefits case. If the benefits measures are using metrics and key performance indicators (KPIs) that are in regular business reporting mechanisms, there is a higher chance of them being monitored and measured, and enduring.
• Implement benefits tracking and measurement mechanisms during the course of the project that should be continued beyond implementation. Projects that have the most success are those that closely engage finance, to support benefits measurement and tracking, and ensure clear business ownership of each measure and benefits target.
• Adjust the benefits case during the course of the project if the business situation changes, and continue to seek incremental benefits opportunities after go-live.
• Secure management focus on the delivery of benefits. Utilize corporate incentive plans and performance measurement to explicitly target benefits' delivery for senior management and executives.
• Ensure ERP project governance includes benefits' impacts in any choices and decision making. Also, convert the project governance responsibility to a benefits-harvesting obligation once the project completes.

3. Implementation Cost

Reasoning

The factors that drive implementation cost are numerous and vary by company. Even seemingly similar companies (from an industry or size perspective) can have very different implementation costs, based on the many variables that influence the effort and cost involved in design, development and implementation. Organizational maturity can also play a huge part in this, yet that is not even part of the "vendor evaluation."

The three most common areas of difference from company to company are interfaces, data conversion and the degree of business process change involved. The choice to standardize or customize also has a significant cost impact. However, any single cost factor can be the trigger that causes a wide difference in the cost from company to company.

Advice

• There is no substitute for good, detailed planning. Avoid planning the implementation based on high-level milestones.
• If you are using a system integrator (SI) that provides a "high-level project plan," require the SI to create a detailed plan that includes the SI's and enterprise's effort and costs.
• Estimate costs based on deliverables to be created and work to be accomplished. Incorporate enterprise specifics when estimating effort and cost.
• For each activity in the project plan, identify the assumptions that drive cost estimations and other factors that will drive the cost.

4. Implementation Project Duration

Reasoning

ERP solutions range from globally rolled-out, functionally extensive (such as a primary on-premises ERP application augmented by a number of specialist cloud applications), to small or midsize business (SMB) administrative SaaS ERP. Implementation time scales can range (at the extremes) from 10 years to a few weeks. Project duration is influenced by many different factors, including functional scope, geographic and organizational scope, degree of business transformation, organizational change readiness, amount of customization, ability to leverage standard solutions, on-premises/SaaS solution profile, project staffing profile and use of rapid-implementation templates.

Implementation projects with similar scopes of effort can result in very different project durations due to a number of factors. For example, the number of resources assigned to the project team affects how much work can be performed simultaneously. In addition, the level of commitment of core team members (part-time versus full-time) directly affects how long it will take to complete the project. Project duration is also affected by the use of consultants and by the mix of consultants versus internal resources on the project team; because consultants should be experts capable of getting the job done more quickly, yet they need the internal knowledge of the business model to achieve the intended outcome. Extensive use of consultants also results in less knowledge transfer of the new applications to users in the organization, which can erode expected value over time.

The number of rollouts (also called "waves" or "phases") after the initial implementation directly affects project duration. The amount of end-user involvement in project efforts affects the time it takes to complete project tasks. Likewise, the number of third-party components involved in the solution affects the time it takes to complete project tasks. Other, less overt, factors that also affect project duration include how well the process works for making decisions that move the project forward, and how adept the enterprise is at resolving issues that could hold up progress.

Postmodern ERP even changes the profile of projects, since implementing solutions to support the ERP strategy is no longer about implementation of one monolithic ERP application but, potentially, of multiple projects of varying scope/size/solutions that comprise the enterprise's overall postmodern ERP strategy. At the same time, fundamental changes in the way that enterprises approach projects (what Gartner refers to as bimodal) must be taken into account; while many ERP implementation projects will adopt a Mode 1 approach, some postmodern ERP projects will be (at the very least) affected by Mode 2 approaches.

Advice

• When planning the project, factor in team member availability and level of commitment. Adjust durations to reflect whether consultants or internal team members are performing tasks. Add placeholder tasks to account for the time it takes to make decisions and resolve issues. Involve end users in project tasks to increase solution acceptance, but adjust the project duration accordingly.
• Account for additional rollout efforts when looking at the overall project duration. Also, adjust task durations when third-party solutions, such as cloud services, are involved.
• Develop a robust project plan based on the implementation approach (for example, use of a global template). Consider constraints and opportunities in planned implementation timings (for example, the need to avoid particular points in the annual business cycle).
• Use insights gained from external reference points to challenge and validate your plan (for example, from ERP solution vendor user group members, from the ERP solutions vendors or SI case studies, and from sector contacts) — or, do this based on your historical performance on projects.
• For plans of long overall duration, break the plan down into phases that are of more limited duration. Recognize the choices and decisions that will have to be made to achieve a short implementation timeline (for example, absolute use of standard "out of the box" functionality).
• Monitor variances to the plan during the course of the project and take remedial action to make adjustments to the outward plan as necessary.

5. Implementation Project Resourcing Plan and Team Size

Reasoning

The resourcing plan is influenced by a number of factors, including functional, geographic and organization scope. Business and IT expertise will be required to cover all functional in-scope areas, ranging from administrative ERP functions to an operational ERP scope supported by a primary ERP solution augmented by (possibly third-party and likely SaaS) add-ons and further enterprise application modules (for example, CRM). In global implementations, enterprises may decide to have global representation rather than country-by-country representation in the core team (for example, a single global finance business process owner); local resources will then be put in place only for the individual local rollout, but may have limited engagement prior to that phase of deployment.

In addition, the sourcing approach for the project will determine which roles are sourced internally and which externally. While some roles clearly necessitate internal expertise and knowledge (for example, business process owners), other roles require technical expertise that may exist only outside the enterprise (for example, application configuration experts).

Project Team Size

Project team size is usually determined by a number of factors; the primary four being: functional, geographic, the complexity of the solution(s) being implemented, and organization scope. Global-scale implementation teams often number many hundreds of people in the core team alone, which is then added to with country and/or regional implementation teams as necessary. On the other hand, an SMB may have a team of fewer than 20. Overall project team size will be further dictated by the use of external third parties (as SIs, for example) and the intended long-term ERP ongoing support and change model (for example, the ERP competency center). A "greenfield" ERP implementation project team, for example, may have members drawn from:

• The business (process experts or owners, and subject-matter experts)
• In-house IT (those who know current systems and need to develop skills in the new ERP solutions)
• A system integrator (for process, system and organizational change capabilities)
• A quality assurance partner (to review and assure the project)
• The ERP solution vendors (for ERP solution-specific expertise).

Contrastively, implementation of a SaaS ERP in a single business unit (for example, a country rollout) — by an advanced in-house ERP competency center or center of excellence working closely with local business users — will combine roles, and there may be no SI or vendor team involved in the day-to-day project. However, properly staffing postmodern ERP projects necessitates an understanding of the new and changed skills requirements in hybrid and full cloud scenarios.

Advice

• Ensure you convene a strong and decisive ERP project team; it is critical to your success. Project leads will need to identify and secure commitment from business process owners and subject matter experts to actively participate in the project's activities. Historically, the core project team should be assigned full-time to the project, and team members' day-to-day positions backfilled for the duration. While this is still the case for many ERP projects, some postmodern deployments (for example, of SaaS solutions for domain-specific capabilities) may not require all of the core team to be full-time.
• Projects that rely on a large percentage of part-time resources invariably find those resources struggling to commit the expected time to the project. If part-time resources are necessary, fully plan for and manage their time between the project and their day-to-day roles, and ensure their regular line managers have made plans to deal with their secondment to the project.
• Ensure you engage an experienced and highly skilled ERP project manager. This person may come from within your own organization; if, however, the individual is externally sourced, retain them for the life of the project.
• In project resource planning, do not forget to include all roles required, including the project sponsor, project governance body, project administrator, auditor, quality assurance, organizational change leads and postimplementation support.
• Pay particular attention to new skills and roles that you may need to secure and/or develop to successfully implement (and later support) hybrid and "flip" (to the cloud) postmodern ERP strategies. Integration skills are the most important here, but many other new/changed roles are also required — such as data architects and vendor management.
• Develop the project resource plan together with your implementation partners, clearly identifying who is responsible for staffing each role on the team. Be careful not to source roles from the implementation partner that ought to come from within your enterprise (but are lacking due to a failure to secure business commitment to the roles' provision); an ERP implementation project without strong business engagement and commitment will not succeed.
• Create and maintain organization charts for the project team, so the reporting structures and subteam makeup within the overall team are clear. If changes in the team (internal or from a partner) are required during the course of the project (due to staff turnover, for example), ensure the hand-over and transition are well-managed.
• Don't assume that a larger project team is always better. The larger the team, the more management, administration, communication and collaboration will be required — further adding to its size.
• Have the right people on the team to cover the full range of tasks and activities, with expertise that will be necessary to successfully implement the project. Do not skimp on this issue; it is an important factor in the success of the project.

6. Support Head Count

Reasoning

Head count for ERP support services varies based on a number of factors, each negating your ability to base decisions on any sort of average. These factors include what roles and services are included in the scope of services. The enterprise's application sourcing and support services sourcing strategies also affect head count. For example, if the application is sourced as SaaS, some support services will be the responsibility of the vendor or end users. If the ERP solution is on-premises but support services are outsourced, internal resources will still be needed to manage the services. Another factor that directly impacts workload and head count is leveraging super users to reduce the volume of service requests that make it to the support team.

The level of governance in place to manage the demand for support services influences workload and head count needs. Examples of other factors include the number and complexity of modules deployed, number of instances involved, number of locations being supported and variances across them, fragility or stability of the solution, volume and pace of ongoing changes, neediness of end users, amount of customization, number of interfaces, and the number of third-party applications, solutions and services included in the ERP portfolio. Each of these factors varies across enterprises, and each contributes to the amount of effort it takes to provide services — thus driving the particular skill sets, company knowledge, competencies and, ultimately, the head count required.

Advice

• Use Gartner's "Toolkit: ERP and Business Application Support Strategic Staff Planning Tool" as a framework for making staffing and head count decisions, based on the roles, services and skills needed to deliver the support for the scope of services defined, in the volume and pace that are anticipated, and at the locations where services are needed.

7. Support Service Costs

Reasoning

The factors that affect support head count also drive service costs. In particular, the volume and pace of change drives costs. A mature, stable solution will cost less to support than one that has just been implemented and is still working through a backlog of requirements, or a solution that is continually experiencing break/fix issues.

Differences between enterprises in how they govern the demand for services will result in different support costs. Whether the support organization is centralized, decentralized or a hybrid also affects the cost to provide support services. Different application and support services' sourcing strategies will result in different support service costs from company to company. For example, implementing a SaaS solution (rather than on-premises) shifts some support costs to the SaaS provider (reducing internal costs), but introduces new support roles (increasing internal costs). Even using a similar strategy, in terms of outsourcing the same services but different types of providers, affects the costs. An example of this is outsourcing to an onshore or nearshore firm, versus using an offshore service provider.

Advice

• Avoid budgeting support service costs based on peer companies. Use Gartner's "IT Key Metrics Data 2015: Key Applications Measures: Cost and Staff Profile: Current Year" and "IT Key Metrics Data 2015: Key Applications Measures: Application Support: Current Year" for baseline costs, but back this up with detailed cost estimates based on the enterprise's ERP footprint and service needs.

8. Organizational Change

Reasoning

The amount of organizational change required for each business process included in the project will vary depending on whether the process itself is changing — in addition to the software application or service being implemented — or even if the business process is to be outsourced as a service (that is, BPaaS). While some changes are minimal (such as replacing one journal entry screen with another), other changes can be tremendous (such as changing from decentralized to centralized procurement via a shared-service center). For example, the effort of implementing procurement could vary tremendously between a company that is already doing centralized procurement and one that is centralizing procurement as a part of the implementation project.

Another aspect of organizational change that directly affects project efforts is the end users' capacity for change — the ability and willingness to make the changes required for the project. A highly adaptable user community will require less time to change than users who are resistant or those who don't have the knowledge, skills or abilities needed to perform well using the new solution. End users' capacity for change is heavily influenced by the enterprise's maturity in respect of organizational change. Failure to acknowledge this influence before starting the project leads to compromised project outcomes or, worse, to user reversion and rejection of change.

Successful implementation and ongoing exploitation of SaaS solutions is dependent upon readiness for change on a more continual basis, because changes will be regularly "pushed out" by SaaS solution vendors. The organizations that will benefit most from adopting SaaS solutions are those that embrace this frequent change and exploit it for business value.

Advice

• Plan organizational change efforts based on the degree of business process change that will occur as a result of the project.
• Assess the enterprise's capacity for change, and incorporate effort and time into the project plan for addressing enterprise-specific organizational change needs.
• Do not rely on external organizational change experts; while you may need specialized support during a major implementation project, you need to raise the organization's ability to change for the long term.
• Recognize that the adoption of SaaS solutions increases the need for regular change and ensure that "change agents" are embedded within the organization.

9. ERP Application Customizations

Reasoning

Customizations have been the nightmare of ERP managers for many years. They have a major impact on an implemented system, driving up operational costs and preventing upgrades, and making it difficult for organizations to adopt new capabilities and reduce risk. There are many reasons why customizations are built despite these concerns: ranging from the inability or unwillingness of process owners to change their established behaviors, to the addition of capabilities to a packaged application to better support strategic processes and help the organization to differentiate itself. As a result, the level of customization varies dramatically between organizations and ERP initiatives — from "pure vanilla" to "heavily customized."

With the more wide-scale adoption of SaaS solutions that minimize the ability to customize, and the use of a pace-layered postmodern ERP approach that minimizes the need for customization (through better fit-for-purpose functionality), a need for some customization still exists and can, therefore, still distort an "average."

Advice

• Do not expect to operate your ERP without any customizations. Not adapting your ERP system to best support business needs, especially in areas where this is needed to drive differentiation, will limit the value of the ERP investments. Instead, identify areas that deserve customization — primarily those on the layer of differentiation in Gartner's pace-layering model — and diligently manage these throughout their entire life cycles.
• Recognize that not all "customizations" are created equal. Extensions and interfaces are less intrusive and simpler to upgrade than actual code (processing logic) changes. A nonoptimized interface may be a better long-term solution than an "optimized" code-changed interface.
• Consider using terminology — regarding "configuration" versus "customization" — in which the former denotes changes to the software that do not entail code changes, and the latter implies code changes. Be clear and consistent as to when each is required, or available.

10. Reports, Interfaces, Conversions, Extensions, Forms and Workflows

Reasoning

The number and complexity of reports, interfaces, conversions, extensions, forms and workflows varies greatly. It isn't even a given that an implementation will include them. Some projects start fresh with no data conversion, while others include converting not only current data, but also data that goes back any number of years. Some don't include extensions (customization) or workflow configuration, while others have extensive amounts of both. One project approach may be to allow no custom reports, while another project's approach could require numerous reports. The same applies to interfaces, although the same type of interface, by itself, can range from easy to extremely complex.

Advice

• For each report, interface, conversion, extension, form and workflow, identify the assumptions and factors that will drive effort and cost. For example, be specific about how many interfaces will be developed, how complex they are expected to be, and how much effort and cost are required for different complexity levels.
• As with implementation costs, avoid planning the implementation based on high-level milestones. If you're using an SI that provides a high-level project plan, require the SI to create a detailed plan that includes both its and enterprise's efforts and costs.
• Estimate costs based on deliverables to be created and work to be accomplished. Incorporate enterprise specifics when estimating the effort and cost.

11. Implementation Project Cost Overrun

Reasoning

Project cost overrun has little to do with the software — it's usually due to a poorly executed or nonexistent ERP strategy, plus the result of insufficient scoping of the project deliverables in the first place. It can also be the result of time- and materials-based service contracts without clear payable deliverables against KPIs, or poor project management. As such, there is no average for how much a project can experience cost overrun. When a project is scoped and executed correctly, the overrun should be zero; you should aim to create an incentive for partners to deliver on time, on scope and on budget.

Advice

• Spend time to correctly scope your projects. Clients implementing ERP whom Gartner speaks with say that they wish they had spent more time scoping (up to 100% more time doing so), despite pressure from the business to "get on with it."
• Define tight KPIs for implementation partners. Make the KPIs defensible and attributable.
• Vendors will try to shift the blame to you, or anywhere but themselves. Use physical deliverables and milestones as measures of the value delivered.
• Focus on developing a risk factor and mitigation task list. Identify where the main risks for overrun are, and the likely resources that will most affect success or failure. Ask your ERP vendors for their "templates" (they do have templates, even if they say they don't), and update your template with any new guidance they can provide.
• Understand the key levers to control implementation costs, and implement rigorous and routine cost reporting for the project. As soon as a variance is forecast (before it has actually occurred) probe the reasons why and take action accordingly.
• Remember, the vendor's job is to help you deliver business performance improvement, not just to implement ERP solutions.

12. Integration Issues

Reasoning

Complications often result from the need to integrate, and can depend on a number of factors. Postmodern ERP strategies, by their very nature, increase the complexity involved in integration. ERP and IT leaders can no longer rely on the integration inherent in a "megasuite," resulting in a significant requirement to support data and process integrity, and to address the resulting complexity. Breaking the inherently tight integration of an ERP suite increases the risk of violating data and business process integrity. Simply interfacing applications will not result in the same level of data and process integrity that ERP suites have historically delivered.

No two postmodern ERP strategies will be the same. They will be unique sets of solutions and therefore will render an average meaningless. Additionally, integration needs change over time as the solution portfolio changes through upgrades, new solutions being introduced and old ones being retired. This leads to a complex network of dependencies that is difficult to manage and unique to the organization at hand, with no average or typical value on any of these factors.

Advice

• Understand the complex interdependencies of the various postmodern ERP scenarios and develop an application integration strategy for your postmodern ERP strategy.
• Ensure your application integration strategy includes establishing and maintaining data integrity and synchronization across multiple solutions and delivery models such as cloud, on-premises and outsourced business processes.
• Design for simplicity wherever possible, by reducing the number of integrations and by using the most modern techniques available.

13. Number of Packaged Add-Ons

Reasoning

A postmodern business application landscape, by its very nature, consists of a collection of application suites and other products. In addition to transforming the systems of record into a more federated landscape, organizations deploy further point solutions, often described as "best-of-breed" products, on the layer of differentiation in Gartner's pace-layering model. Some examples of add-ons in product-centric companies include CRM, product life cycle management and supply chain management.

The number of systems deployed depends largely on the individual company. Again, there is no average. The more differentiated the company's business model is in its markets, the more add-ons it is likely to deploy.

Advice

• Use Gartner's tolerate, invest, migrate and eliminate (TIME) method to analyze your application portfolio in recurring cycles and to scrutinize the cost benefits of your add-on products.
• When upgrading your ERP system, analyze the potential to replace some add-ons by using similar functionality that the new version of the ERP system might provide. Make sure, however, that you do not harm your differentiation values by relying too heavily on standard functionality.
• Deploy and integrate new add-on solutions only when there is a solid business case that proves the added business value.