A new report by Gartner Inc. encourages companies to divide their ERP systems into different abstraction layers before ERP upgrades or consolidations so they can incorporate later changes faster and more efficiently without disturbing the core ERP code.
“What we’re saying is take a look at different applications that you have, different business processes, and divide them into three layers based on how fast they need to change and what kind of attributes they need,” said Bill Swanton, the analyst who wrote the report. “You have different layers that change at different rates.”
More on ERP upgrades
Learn how Gartner’s pace layer strategy applies to
Understand why ERP upgrades are never clear-cut
Read how one manufacturer made long-needed changes to its ERP
The so-called “pace” layer strategy promoted by the Stamford, Conn.-based research company calls for assigning to the first layer customizations that have fallen out of use or are no longer relevant, and as a result can be left out of the upgrade or consolidation. “Don't bring them forward, and ensure that the upgrade process does not automatically do so,” Swanton writes in the report.
The second layer should consist of very basic changes to core ERP functions, including simplification of the user interface and specialized reports and documents or simple feature enhancements. Only essential changes should be brought forward, and companies should take care to make sure those changes have minimal impact on the system by following the vendor’s guidelines for customization.
The third layer includes changes that help the company differentiate itself from competition and are typically made at a faster rate than changes to the core “system of record” ERP, the report states.
'Pace' development options for ERP upgrades
Companies have several means available for dividing their ERP systems into abstraction layers, according to Gartner analyst Bill Swanton. They can choose from the following:
- Building composite applications that use well-defined services or application programming interfaces (APIs) in the core ERP system to get things done, but which can be changed without affecting the system of record
- Using a business process management suite (BPMS) to build a unique process, such as a sales order capture process that has steps not covered by ERP. Companies taking this route should use master data from ERP and, in the end, insert a sales order into ERP for the fulfillment stage
- Going with straight application development and employing APIs
- Using the core ERP system or a third-party application with unique configuration settings or configuring a rule engine to create unique functionality.
- Integrating with a cloud-based or Platform as a Service-built application
The layers allow newer, innovative changes to be made without waiting for IT to change the whole system at once, Swanton said.
“[Business] guys want to do something new and different, and want to respond to something in the market. The ERP guys say, ‘OK, in 18 months from now, you can have it,’ ” Swanton said. “It’s not seen as being responsive, and in the end, the business guys go around IT.”
There are several ways to build the layers, Swanton said, including developing composite applications and configuring rules engines (see “‘Pace’ development options for ERP upgrades”).
“Duet Enterprise should be that extra layer,” said Gartner analyst Jeff Woods. “If you engineer this correctly, Duet Enterprise can serve as one of the ‘systems of innovation’ layers that resides above [SAP] ECC, uses data from ECC, uses processes from ECC, but then also has a very lightweight environment that you can change very quickly.”
Tips on applying pace layers to ERP upgrades
Swanton makes the following additional recommendations for pursuing a pace-layer strategy:
- During their ERP consolidation or upgrade planning, companies should divide past customizations into unused or obsolete, those still needed or wanted for tailoring “commoditized” business processes, and those that deliver capabilities that differentiate them from their competitors.
- Architect the systems of record to provide stable services that can be used by 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.