Use a Pace-Layered Application Strategy to Clean Up ERP During Upgrades and Consolidation

When remediating customizations during an ERP upgrade or consolidation, applying Pace-Layered Application Strategy concepts can help segment the customizations that are brought forward. This can reduce future maintenance costs as well as allow differentiating capabilities to be managed in a more cost-effective and responsive manner.

Key Findings

• Many complaints about the cost of maintaining ERP can be traced to poor customization practices.
• Remediating customization is a major expense during ERP upgrades and consolidations.
• Keeping the core ERP modules unmodified will reduce long-term costs and is appropriate for a system of record.
• A Pace-Layered Application Strategy provides a mechanism for segregating differentiating customizations so they are less intrusive and easier to evolve.

Recommendations

• As part of upgrade or consolidation planning, triage customizations into those unused or obsolete, those still wanted to tailor commodity processes, and those that deliver differentiating capabilities.
• Use Gartner's Pace-Layer Application Strategy to segment differentiating and innovative work from the core system of record.
• Architect systems of record to provide stable services to the faster-changing layers.
• As much as possible, rebuild customizations as less-intrusive systems of differentiation using a vendor's composite application capabilities or other techniques that avoid changing core ERP code.
• Limit the core ERP to be a system of record for nondifferentiating processes. Make them stable, roll them out as far and wide as makes business sense, and then reduce investment in core ERP to free up budget for differentiating and innovative capabilities.

The largest ERP packages by market share were first delivered almost 20 years ago. Companies at this point have shown little intention of replacing them anytime soon, so a life cycle of 30 years or more for these packages is likely. During that time, customers will inevitably face several major upgrades of these packages as vendors incorporate new features, technology, and (to keep up with the march of progress) hardware, operating systems, and databases.

In other cases, companies may have installed separate ERP instances in different regions or business units and are now looking to consolidate them into one instance to become "One Company." Upgrades are often built into these consolidation projects (see "ERP Consolidation: Standardizing Processes and Evaluating Your Options").

These upgrades and consolidations are nontrivial projects costing a significant fraction of the original implementation. With this much money and enterprise disruption at stake, the event is a good time to take stock of your overall application strategy and plan the project so that the ERP system will be easier to maintain in the future and IT can also be more responsive to business requests for new differentiating and innovative applications.

Customizing ERP Keeps on Costing

In the early days of ERP, many clients did what they had always done to packaged applications — they customized them. There were many reasons for this:

• Early versions of the package may have been missing functionality to support some industry practices.
• Users may have insisted the new package be changed to be more like the old application it replaced.
• The company may have had a unique business process that gave it differentiation in the market, which would not be found in application packages (until everyone copied the strategy).

Some of these reasons were good, some not, but in any case the company spent a lot of money on customization and ended up with a nonstandard implementation. Which is fine, until you need to upgrade. At that point, you need to reapply those customizations, in effect paying for them twice — or three or four times (see "Customization: The Cost That Keeps on Costing").

The Cost Can Be Reduced With Less-Intrusive Customization Techniques

As people saw the ruinous cost of customization, companies quickly adopted a "vanilla" strategy — the package would be installed as-written and any customization required top management to sign off. Third-party applications were banned to avoid integration costs. This brought implementation and maintenance costs under control, but often left the business frustrated by having to accept an "80% fit" to its needs.

The pendulum has begun to swing the other way, however, as companies learn approaches to customization and third-party package use that are less intrusive than changing the core ERP code. As described in "Manage ERP Customizations, Don't Avoid Them," abstraction layers can be used to isolate the customizations from the vendor-supplied code, making it easier to manage. User exits, standard APIs, and composite applications accessing ERP services are some examples.

Discussions around customization can't be one-way (i.e., IT "telling" the business what to do, or vice versa). In some organizations, the business is not used to having its application organization "discuss" customizations. It's just supposed to "do" them. Here, the application organization should use strong storytelling techniques (see "We Are Not Spock: Why Logic Loses in Change Management") to frame and lead the discussion. It may seem logical to the application organization, but it's not as easy as "just do it."

Using a Pace-Layered Application Strategy Helps Identify Differentiating Customizations

When planning an upgrade or consolidation project, a core activity is performing a form of triage on the existing customizations. They can be sorted into three categories:

• Unnecessary or obsolete — Transaction analysis tools can be used to identify customizations that have fallen out of use and, therefore, need not be brought forward. Other customizations may be obsolete, because the newer version of the ERP package now includes an equivalent feature. These are the easy ones. Don't bring them forward, and ensure that the upgrade process does not automatically do so.
• Basic changes to core functionality — These may be things like simplification of the user interface, specialized reports or documents, or simple functionality enhancements. The bar should be set high here — business and user groups should have to make a business case for the change, not just "that's how we do things here." The decision may be made to bring these forward, but care should be taken to make them minimally intrusive by following the vendor's guidelines for such changes.
• Important differentiating capabilities — these are unique changes made to give your company a capability that your competitors do not have. It might be a relatively new idea or it might be an internal business process in use for years and now embodied and automated in the software.

The last group brings us to using a Pace-Layered Application Strategy in planning. As explained in Note 1, this strategy segments applications based on how commoditized the capability is and how fast it needs to change:

• The bulk of the ERP functionality is commodity and used in similar ways by all companies that use that ERP package. It is essentially a system of record.
• The important differentiating capabilities identified in the triage process are good candidates for systems of differentiation.

This sorting of the customizations for remediation is shown in Figure 1. Note that the entire ERP suite is not necessarily a system of record — certain modules or parts of the suite could be managed as a system of differentiation (see "Applying Pace Layering to ERP Strategy"). At the same time, any application that is interfaced to ERP should be evaluated as to its layer in the overall application portfolio.

Source: Gartner (February 2012)

It is unlikely that any existing customizations are the basis of a system of innovation. Instead, the upgrade is likely to open up new vendor capabilities, such as mobile or analytical capabilities that could be brought to bear to build one.

Isolating Differentiating Customizations Reduces Costs and Improves Agility

Why treat the differentiating capabilities differently? The key reason is to make it easier to evolve those capabilities faster in the future, as competitors copy the idea and start to catch up.

Changing customizations in the ERP system will have the same issues as any other change you make — a system of record must be changed carefully and slowly to avoid disrupting key transactional activities and regulated processes. Changes must be carefully vetted, tested and scheduled. This tends to dramatically lengthen the response time.

Differentiating ideas often appear quickly and the business presses hard to implement them now and gain first-mover advantage for as long as possible. ERP and system of record can't react quickly enough, creating even more frustration for the business.

For these reasons, it is best if systems of differentiation are more isolated from the core ERP system and its release/change management processes. There are several approaches to this:

• Build composite applications that use well-defined services or APIs in the core system to get things done, but can be changed without affecting the system of record (see "SOA Enables a Pace-Layered Approach to Applications").
• Use a business process management suite (BPMS) tool to build a unique process, such as a sales order capture process with steps not covered by ERP, but use master data from ERP and, in the end, insert a sales order into ERP for fulfillment.
• Straight application development and the use of APIs.
• Use the core ERP system or a third-party application with unique configuration settings or configure a rule engine to create unique functionality.
• Integrate with cloud or platform as a service (PaaS)-built applications.

This approach lets the system of differentiation evolve faster and allows the core system of record to be "locked down" and changed infrequently, freeing up more budget for differentiating and innovative activities (see "Systems of Record: You Can't Innovate on an Unstable Foundation").

Conclusion

A Pace-Layered Application Strategy helps IT to be more responsive to the business demands for change by focusing those efforts on a small number of applications. IT can stabilize the systems of record and then dramatically reduce the maintenance cost by locking down the commodity ERP processes and minimizing changes. When forced by an upgrade or consolidation project to take off the covers and muck around inside ERP, you might as well do it in a way that will make you more efficient and agile in the future.