G00276503

Postimplementation ERP Governance Best

Practices
Published: 19 May 2015

Analyst(s): Pat Phelan, Carol Hardcastle

To optimize the ongoing value from ERP investments, there must be

effective governance after go-live. The complexity of postmodern ERP
strategies raises the stakes on governance, and ERP leaders should follow
the best practices in this research to ensure governance is effective.

Key Challenges

When ERP solutions are implemented with little understanding of, or planning for,
postimplementation governance, the consequences are damaging and can lead to problems
such as increased operations costs or even a destabilized solution.

Enterprises that attempt to govern postmodern ERP with the same model used for traditional
ERP services find it to be inadequate for the number of solution components and vendors, and
increased need for integration and level of user participation required.

Too many organizations confuse governance with operational management they are not the
same.

Recommendations
ERP leaders should:

Plan early for postimplementation ERP governance, and ensure senior business and IT
leadership responsibility for it.

Establish a governance model and processes for making decisions about different types of ERP
changes, including those in postmodern scenarios.

Introduction
Long-term success with ERP requires keeping the total solution aligned with your ERP strategy and
business objectives. Postimplementation ERP governance addresses this by assigning decision-

making responsibility over requests for changes to the solution set and oversight responsibility for
how the enterprise takes the solution forward through its life cycle after initial deployment.
The ERP suite is being deconstructed as part of what Gartner calls postmodern ERP (see "2015
Strategic Road Map for Postmodern ERP"). This era brings a more federated, loosely coupled ERP
environment with much (or even all) of the functionality sourced as cloud services or via business
process outsourcers. More vendors and technologies are involved in the total ERP solution, and
business processes are being supported by multiple applications, which makes taking the ERP
solution forward after go-live more complicated and risky.
Postmodern ERP places even greater emphasis on keeping the total solution cohesive, due to the
larger number of components and services involved in these new scenarios. This is unlike the
traditional era, when business capabilities were commonly satisfied by a single vendor's suite. To
ensure uninterrupted support of business capabilities, you need to synchronize changes and ensure
their interoperability. ERP governance must consider not only more moving parts, but also that
some of these are outside the direct control of the enterprise (e.g., changes in SaaS functionality are
controlled by the vendor). This means that business stakeholders and ERP leaders need to change
how they implement and execute ERP governance.

Analysis
Plan Early for Postimplementation ERP Governance, and Ensure Senior Business
and IT Leadership Responsibility for It
For many enterprises, ERP governance is modeled after the enterprise's IT governance structure,
but this is inadequate for the types of decisions required to evolve the ERP solution through its life
cycle. Although IT governance requires business input, ERP governance requires a significant level
of senior business leader involvement in making decisions that could have a profound impact on
how ERP solutions support the business (see "ITScore for Application Organizations: Business
Engagement").
To ensure the proper level of attention and decision-making authority, ERP governance needs to
reside at the enterprise level, where senior, C-level executives from the business and IT maintain the
ERP vision and own the ERP strategy (see "How to Develop an ERP Strategy" and "Use a BusinessDriven ERP Strategy to Maximize the Value of ERP"). However, there is no one size fits all for ERP
governance (see "How to Drive 'Just Enough' Application Governance"). Enterprises where
business capabilities are changing frequently (e.g., where the adoption of a digital business model
drives greater demand for agility and flexibility) will need commensurately more frequent decision
making their governance tempo must reflect the level of business change.
As you adopt postmodern ERP strategies and move to cloud solutions and services (likely
alongside on-premises applications), some change will be imposed upon you from external sources,
such as SaaS vendors. In addition, more extensive business changes may lead to new choices. For
example, rather than asking "How do we execute this change in solution X?" the question may be

Page 2 of 11

Gartner, Inc. | G00276503

extended to also ask "What solution/service can best provide this changed/new business
capability?"
ERP and business leaders must:

Establish an ERP governance organization.

Recognize that a holistic ERP governance organization may need to consist of more than one
governance group.

Define the governance model early.

Build from existing IT and application governance approaches.

Define new and adjust existing governance policy, processes and decision-making frameworks
to reflect the HOOF scenarios that are adopted in your organization.

Establish an ERP governance organization. The overall governance group must be composed of
senior business and IT leaders that will make decisions about how to evolve the ERP portfolio over
its life cycle (see "Establish ERP Principles to Support Strategy and Governance").
Recognize that a holistic ERP governance organization may need to consist of more than one
governance group. For example, in a global organization, there may be regional governance
groups and an overall corporate/global governance group. Likewise, there may be line of business
and/or process governance groups (e.g., procure to pay or sales/distribution). Each of these must
be resourced by appropriate senior business and IT leaders.
Define the governance model early, certainly before initial implementation. Then, launch it in
the post go-live transition period, clearly defining the handover from ERP project governance. Note
that postimplementation governance does not (at least not automatically) include the benefits
realization activity, which remains a business accountability after the project implementation phase
completes.
Build from existing IT and application governance approaches. Expand them to encompass the
enterprise-spanning nature of ERP, just as many of the business processes enabled by the ERP
solution do.
Define new and adjust existing governance policy, processes and decision-making
frameworks to reflect the HOOF scenarios that are adopted in your organization (see Note 1
for a definition of these).

Establish a Governance Model and Processes for Making Decisions About the
Different Types of ERP Changes, Including Those in Postmodern Scenarios
ERP governance exists to manage the demand for change. Postmodern ERP and its numerous
sourcing options make it necessary for the ERP governance group to establish or enhance existing
principles for sourcing when making decisions about major changes (see "Establish ERP Principles
to Support Strategy and Governance" and "Toolkit: Define ERP Principles to Support Successful

Gartner, Inc. | G00276503

Page 3 of 11

Execution and Governance of ERP Strategy"). A change request for one component requires
assessment of the feasibility of the change in relation to other solution components. Postmodern
ERP complicates this further, since the ability to achieve a business need may be dependent on
external solutions that the enterprise has little or no control over.
Consider a common postmodern scenario in which a company runs a Tier 1, on-premises ERP
solution for manufacturing and order management, uses a SaaS solution for HCM, and a different
SaaS solution for indirect procurement. There are three large components in this ERP portfolio.
When a change request surfaces for HR, the ERP governance group can't address it solely from a
SaaS HCM perspective. The group must also consider how the change integrates with the onpremises ERP solution and, if necessary, how it integrates with other SaaS solutions.
Postmodern ERP governance principles should also support choices such as:

When to replace an on-premises solution with a cloud solution; for example, only if the
requirement provides differentiation or innovation (see "The Digital Business Application
Portfolio Must Embrace More Than Buy and Build" and "Postmodern ERP Is Fundamentally
Different From a Best-of-Breed Approach").

Whether to make the approved change within the current vendor's solution, seek a new vendor
that offers just the desired functionality, or replace the incumbent vendor's solution with one
that satisfies the current and new requirements (see "Identify When ERP Renovation Must Turn
Into Replacement to Support Business Goals").

There are different categories of change, each with varying degrees of potential impact to the
enterprise. In order to apply an appropriate level of decision making, the ERP governance group
needs a way to determine the type of change being requested and follow consistent processes for
addressing these different categories.
ERP and business leaders must:

Define how to categorize changes.

Manage major changes.

Define processes and workflows to categorize, assess and review major changes.

Manage minor changes.

Handle emergency changes.

Define how to categorize changes. Gartner sees common categorizations as major, minor and
emergency.
Manage major changes. Governance at this level involves determining whether to make large ERP
investments, including establishing the priority, sequence and timing of the changes. Examples of
major changes include implementing a new solution/service to satisfy a new/changed business
capability (e.g., a SaaS solution for talent management) and planning a major upgrade. Major
changes usually result in establishing separate project governance (see "How to Implement
Effective ERP Project Governance") to address the decisions needed to execute the project.
Page 4 of 11

Gartner, Inc. | G00276503

Members of the ERP governance group may serve on individual project steering committees when
the project scope aligns with the member's functional scope of responsibility. The ERP competence
center (CC) (see "Best Practices for Supporting Postmodern Hybrid ERP") provides advisors to the
governance group when making decisions about major changes. It also contributes to the
prioritization exercise, since IT factors can influence the order in which ERP changes are made.
For most enterprises, major changes can be addressed via a quarterly planning cycle. Often, the
biggest decisions will be made toward the end of the financial year when the governance group
agrees on what the ERP investment plan should be for the next financial year. During this decisionmaking session, the governance group should look at all of the project opportunities and determine
priorities and sequencing, taking into account factors such as strategic alignment, business value,
business priority, cost and resource needs. The decision-making exercise typically results in a highlevel investment plan that the governance group agrees to and approves. This forms the basis of the
coming year's ERP project and operational plan.
At the remaining quarterly meetings during the year, the governance group reviews the investment
plan and determines if it is still viable. The group monitors the investments already in process to
ensure they are still aligned with business objectives and priorities. The ERP governance group is
responsible for pulling the plug on major changes that are failing to deliver the promised benefits,
are no longer in line with business objectives, or fail to support the overall ERP vision, strategy and
roadmap. The group also considers new requests, determines if/where approved changes fit into
the plan, and identifies changes that must be deprioritized or resequenced to accommodate this.
Define processes and workflows to categorize, assess and review major changes. The
following processes are examples of processes needed. Smaller enterprises will need less complex
governance than large global organizations. Define your own processes to ensure an appropriate
level of governance over managing changes to your ERP solution.
Processes needed for major changes include:

Submit a new change request.

Log and track change requests.

Assess and approve/reject change requests.

Prioritize approved requests.

Update the investment plan.

Defer/reject unresourced requests.

Communicate the plan.

Monitor the agreed-upon investment plan.

Resolve escalated project decisions.

Submit a new change request. To support governance over major changes, you need a
way to receive potential changes for consideration. With the size of the financial

Gartner, Inc. | G00276503

Page 5 of 11

investments, resource commitments and potential business disruption involved in making

major changes, Gartner advises establishing guidelines for the information that must
accompany a major change request. All requested changes must have a defined business
outcome that includes measurable business capability improvements that can be used to
define a business case (see "Business Outcomes Are the Milestones on an Application
Strategy Road Map" and "Toolkit: Business Case Model for ERP" [Note: These documents
have been archived; some of their content may not reflect current conditions]). Change
requests that reach the governance group without the detail necessary to make an informed
decision should be routed back to the business to develop the business case for the
change.

Log and track change requests. You will need a mechanism for capturing information
about each change request. This could be a simple spreadsheet that contains key
information about each change (such as projected benefits, required business capabilities,
time frame, resource requirements and potential costs). Large enterprises with numerous
major changes may find an automated tool to be more effective (see "Market Guide for
Enterprise PPM Solutions"). The purpose for the tracking mechanism is to provide an at-aglance view of the total demand for changes. The tool is also a way to see the potential
impact on the investment plan if major changes are added or removed, or the timing is
shifted. If the project is not large enough (agree on size/scope and other categorization
criteria for this), then identify it as a minor change and treat it via the guidelines described in
the section in this research on minor changes.

Assess and approve/reject change requests. Establish guidelines and criteria for
approving and rejecting requests. Examples of criteria include quality of the business case,
value of projected benefits compared to cost to achieve them, whether affected business
processes are business-critical, and alignment of benefits to the enterprise's business
objectives. A best practice is to define an evaluation model with agreed-upon criteria and
a scoring mechanism to ensure objective and consistent assessment.

Prioritize approved requests. Since enterprises don't have unlimited resources to invest in
their ERP portfolio, approved requests may need to be assessed to determine which ones
are most urgent. Factors to consider during prioritization include the urgency of new
requests in relation to each other, and the urgency of requests in relation to the existing
investment plan.

Update the investment plan. Governance over major changes also includes figuring out
where approved changes fit into the existing investment plan. Consider how to handle highpriority requests for which there are insufficient resources versus less urgent requests that
could be addressed with available/unassigned resources. Analyze whether inserting a
change into the investment plan is feasible, given factors such as the potential disruption
due to shifting the timing or resources committed to in-process projects.

Defer/reject unresourced requests. The list of approved change requests may exceed the
enterprise's capacity to deliver, tolerance for disruption or its ability to absorb change.
Resources may not be available to work on all approved requests. New change requests
that rank lowest in priority may require more investment than the enterprise is willing/able to
make in ERP. When this happens, the governance group must decide which approved

Page 6 of 11

Gartner, Inc. | G00276503

requests will be deferred and/or rejected. Some enterprises use this activity as a secondary
rejection exercise. If the request didn't make the cut this planning year, they ask the
requester to resubmit it next year, since business conditions will have changed by then and
the request will need to be re-evaluated against the other requests made at the future date.

Communicate the plan. Be sure to include a communication step for notifying requesters
of your decisions. For approved requests, this may take the form of a high-level project
charter that outlines the approved scope, investment budget and resource commitments.
For deferred or rejected change requests, provide notification to the requester of the
governance group's decision. Provide the updated investment plan to ERP stakeholders.

Monitor the agreed-upon investment plan. On a quarterly basis, the ERP governance
group should formally review the agreed-upon investment plan. Project progress (or lack
thereof) may impact timing and resource requirements, and these could impact the timing or
resourcing of subsequent investments. Changes in business priorities or needs may require
rethinking the priority or timing of pending investments.

Resolve escalated project decisions. The ERP governance group also serves as an
escalation point for significant project decisions that go beyond the project steering
committee's scope. For example, the ERP implementation team learns partway through a
project that the reporting tools provided by the software vendor are inadequate. A decision
must be made on how to meet these needs (e.g., by acquiring and implementing a new
reporting/analytics tool). These types of decisions will typically result in a change request
that can be treated as a midyear request. However, the project's timeline may require a
decision sooner than the next planned (e.g., quarterly) review. Establish guidelines and a
process for addressing off-cycle investment decisions in order to keep projects moving
forward.

Manage minor changes. Governance at this level involves making decisions about requests for
changes that are not big enough to be addressed as individual projects or tracked in the ERP
investment plan. Minor change requests occur in larger numbers than major changes. They often
focus on a particular aspect of the ERP solution, such as a single functional area's requirements or
a single automated transaction. Many organizations categorize something as a minor change based
upon the expected effort and/or cost to implement it (e.g., less than 20 person days of effort and/or
less than $10,000). Be aware of a situation that sometimes arises, where a major project (that may
have been rejected or deprioritized) is broken into smaller pieces to secure them via the minor
change route. Governance mechanisms must not be bypassed like this.
In some enterprises, funding for this type of change comes from individual business units or as a
line item in IT's budget. When one of these scenarios is present, Gartner clients almost always tell
us that governance over the changes doesn't exist. When funding comes from IT, the business
expects the ERP CC to respond to all change requests, regardless of their impact on other users
and to do so within the funding that is budgeted. When individual business leaders have their own
budgets for ERP changes, it's even worse, because there is an expectation that what is funded will
get done regardless of the value of the change to the enterprise as a whole or its impact on other
ERP users.

Gartner, Inc. | G00276503

Page 7 of 11

ERP governance over minor changes is not about how much should be spent on changes or which
business unit has the funding to make changes. It focuses on what ERP changes should be made
and in what sequence. Even if business leaders have funds set aside for changes, they must not
bypass ERP governance and have their changes completed outside of the governance process. In
order to remove the funding issue from governing minor changes, some enterprises set aside an
annual budget at the enterprise level for all minor changes or simply as an agreed resource
utilization from the ERP CC (e.g., 250 person days effort allocated to moderate change). When the
budget is used up, that is all the minor changes that will happen during that budget year. The
volume of minor change requests may make it necessary to assign a subgroup of the ERP
governance group to oversee them and monitor the change budget throughout the year.
Processes needed for minor changes include the following:

Fund minor changes (annually).

Approve/reject change requests (throughout the year).

Add approved changes into planned releases.

Communicate release schedules.

Monitor planned changes (ongoing).

Fund minor changes (annually). The budget decision for next year's minor changes is
often made toward the end of the current financial year. The ERP governance group should
review the amount of funding that can be invested in ERP in the next year and agree on an
overall spend bucket for minor changes.

Approve/reject change requests (throughout the year). At each quarterly meeting, review
and approve/reject change requests that qualify as minor changes. Criteria similar to major
changes may apply to minor changes, but minor requests often apply to specific ERP
operations issues and should be assessed on whether the incremental improvement is
worth the total lifetime cost to implement and maintain the change.

Add approved changes into planned releases. A best practice is to group approved
minor changes together and release them into the production environment as bundled/
scheduled releases, often quarterly or semiannually. If the enterprise uses this type of
release management (see "Postmodern ERP Operations Management Best Practices"), the
governance subgroup will need to work closely with the ERP CC to sort the approved
changes into upcoming planned releases. This would be based on factors such as the
amount of effort/time required to complete a change, the number of changes already
included in a release, available capacity of the delivery team, and the amount of user
disruption (e.g., organizational changes) involved. Although minor changes may require less
development effort than major changes, they can still have a far-reaching organizational
impact. Minor changes are often scheduled into releases based on the business capabilities
affected, in order to optimize testing, business change and business outcomes.

Communicate release schedules. Communicate to stakeholders about the release timing

of approved changes. Also, let affected stakeholders know if their requests were rejected.

Page 8 of 11

Gartner, Inc. | G00276503

Monitor planned changes (ongoing). Throughout the year (e.g., during quarterly ERP
governance meetings), monitor the minor change funds that have been spent or allocated.
This includes making adjustments to the remaining budget, based on actual costs used to
date for minor changes. It may include shifting planned changes to different scheduled
releases, based on actual performance of completed and in-process changes. Finally, it
may involve cancelling or deferring planned changes in favor of newly approved change
requests that have a higher priority or more anticipated business value.

Handle emergency changes. Emergency changes are unplanned changes that are necessary to
resolve incidents. They may also include applying vendor-provided patches or fixes immediately
rather than waiting for the next scheduled minor change release. Governance at this level involves
monitoring day-to-day changes to determine if there is a larger impact that needs to be governed.
This management activity is normally the ERP CC leadership team's responsibility.
Emergency changes are elevated to the ERP governance group only if a major issue, minor change
or major change is identified during emergency change activities. One example would be when
numerous emergency changes result in introducing some instability into the ERP solution that
requires a minor or major change to resolve.
Processes needed for emergency changes include the following:

Evaluate off-cycle change requests. When an emergency change escalates into a minor or
major change request, the ERP governance subgroup or ERP governance group may need to
address the change promptly rather than wait for the next quarterly review. If this happens,
determine whether the change falls into the minor or major category, and then follow the
processes described in this research.

Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.
"Postmodern ERP Is a Vital Foundation for Digital Business, and ERP Leaders Must Act Now"
"Establish ERP Principles to Support Strategy and Governance"
"Toolkit: Define ERP Principles to Support Successful Execution and Governance of ERP Strategy"
"How to Implement Effective ERP Project Governance"
"Refresh Your Practices, Governance and Technologies to Tackle Cloud Services Integration"
Evidence
This research contains input from Gartner clients that have world-class ERP support organizations
in place and discussions with Gartner clients that have redesigned their ERP governance strategies
to accommodate postmodern ERP concepts.

Gartner, Inc. | G00276503

Page 9 of 11

Note 1 The HOOF Model: Postmodern ERP Scenarios

The hybrid, on-premises, outsourced, flip (HOOF) model outlines four possible postmodern ERP
scenarios:
Hybrid reality In this environment, many components of functionality will be delivered as cloud
services, whereas others will be maintained on-premises. Cloud services become at least an equal
partner with on-premises delivery. This environment will create significant new integration
challenges, because it relies on a more varied and loosely coupled architecture.
On-premises monolith This reflects the situation now, where the ERP is suite-focused, there is a
quest for reduced instances and a quest for a "single version of the truth" for business processes.
The ERP strategy is equated with a single, dominant ERP vendor.
Outsourced everything Many organizations have elected to outsource their IT environments,
and there will be increased adoption of BPO for ERP processes. This is driven by newer processenhancing technologies and services (PETS), in which BPO providers can become the primary
consumers of cloud-based ERP (which they then bundle with BPO services to clients).
Flip This option is where the market flips to the cloud. Instead of having on-premises core
solutions that are complemented by innovation or differentiating processes being supported outside
ERP, now all commodity best-practice business processes will be delivered as cloud services. This
will leave a much-reduced IT organization free to focus on building the innovative and differentiating
business processes required. In this case, on-premises, integrated megasuites cease to exist.

Page 10 of 11

Gartner, Inc. | G00276503

GARTNER HEADQUARTERS
Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096
Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

2015 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartners prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartners research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartners Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see Guiding Principles on Independence and Objectivity.

Gartner, Inc. | G00276503

Page 11 of 11