Expand +

Blog Post


Defining the Four Levels of SAP-Enabled Change (Part I).

by Guy Couillard

March 2, 2012

Guy Couillard“What do we need to know to provide effective guidance to our SAP project?”

It’s a common question we get in our executive education workshops from senior executives who may have bought SAP software, but have also heard about painful projects that come in late and over budget, failing to achieve their expected benefits.

There are certainly some established best practices for governance, value realization and organizational change. And key activities around executive buy in, process ownership, scope control, readiness monitoring, end user engagement and enablement are included in many implementation methodologies. However, most are based on the assumption that all SAP projects are the same. And that’s not the case. From a governance and change perspective, one size does not fit all. Different levels of transformation call for different types of governance and change. For successful transformation, the SAP solution to be deployed (ERP, CRM, PLM, etc.) does not matter as much as the strategic intent.

In order to help executives determine the type of governance and change management their project will require, we define four levels of SAP-enabled change, which I will review in the following posts.

Level 1: Reproduce legacy functionality

The first type of SAP-enabled change is found in organizations that look at SAP as a set of building blocks that will allow them to reproduce the functionality provided by their existing, often obsolete, legacy applications. Unsustainable systems are typically the driving force for this type of change, with IT leading the charge. Business cases are based on IT cost of ownership or burning platforms, with business process improvements a tangential benefit. From a change management standpoint, we hear statements like “our goal is not to disrupt (i.e. change) the business.” 

To say that these projects are perilous is an understatement. In the 1990’s, in their first contact with enterprise systems, many public and private organizations approached their deployments in this manner. In design workshops, when asked by the consultants what their requirements would be, key users would respond “well, here’s how I do it now…” and that would become the SAP requirement. The notion of implementing “best industry practices” was paid little more than lip service.

In most cases, core SAP got modified to meet these requirements, even to the extent of reproducing process silos, making future upgrades a very expensive proposition.

The only silver lining in these projects is that assuming the project team is capable of reproducing existing user roles and tasks in SAP — somewhat unlikely but not impossible if enough money is thrown at it — there is indeed little actual change to manage. All that is required is effective information, communication and end user training. However, if user tasks and business processes (unexpectedly) are transformed, other levels of change interventions and governance are required. Without these, costly disruptions to the business are the rule.

Approaching an SAP project as an IT replacement initiative requiring only basic change management is wishful thinking at best. There is however an exception to this rule. Organizations already on SAP that decide to do a straightforward “technical” upgrade, with no added functionality, only require level 1 change and governance.

Level 2: Striving for Transparency/Standardization

At the transparency/standardization level, organizations are better informed of the potential benefits enabled by enterprise systems, in particular as catalysts for process standardization and data discipline. Business cases for these projects focus on achieving better or even real-time reporting and reducing the inefficiencies created by business units using different technologies/processes to perform similar tasks. Of all functions, finance often feels this pain the most, with the quest for a “single version of the truth” being a constant exercise in frustration.

These organizations understand that the project will require significant investments in change management and alignment of business stakeholders. Senior management understands the need to let go of locally-owned applications to adopt a common platform. They recognize that this will be disruptive and are willing to make significant investments in integrated change management. In addition to effective communication and training, we see investments in detailed organizational impact analysis, cascading sponsorship, business readiness, risk monitoring, user enablement, and super user communities. This commitment to change goes beyond the go-live date to ensure that adoption and benefits realization actually take place.

However, one key factor typically separates organizations doing this level of SAP transformation from those aiming for level 3 or 4. They tend to shy away from establishing end-to-end business process ownership and management at the operational level. Someone on the project team might carry the title of “Business Process Owner”, but that individual is often tasked with making those decisions that no one else can or want to make. There is also no clear accountability or metrics for end-to-end process performance after go-live. 

This reluctance to adopt an organizational process mindset is sometimes (still) reflected in project organization, with sub-teams organized by functional area (i.e. FICO, SD, MM, PP) rather than by end-to-end processes (order-to-cash, record-to-report, hire-to-retire, etc.).

From a consulting perspective, this approach makes it easier to train and staff resources, as it is easier to develop SAP module configuration specialists than value-based process consultants. This approach often results in evolutionary rather than revolutionary change. User tasks are revisited, but overall responsibilities change little and job descriptions remain essentially the same.

There are a number of reasons for organizations to not fully embrace business process management. Most of those reasons center around business process maturity (a topic worth exploring in a future posting).

(To Be Continued)

Guy Couillard, president and founder of OTA (, is a consultant focusing on the management of large scale change associated with the deployment of large technology projects such as SAP. Couillard specializes in the conceptual integration of the different disciplines related to the successful adoption of IT-driven innovations, namely risk management, organizational change & knowledge management, communications and branding, value realization and program management.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!