Is Stable ERP an Oxymoron?

After going live with ERP, management will be anxious to know when the ERP system has reached a steady state (if ever). As part of the project plan, IT and line-of-business (LOB) executives must define what "stable ERP" means, and when it can be achieved.

META Trend: During 2004/05, post-"go live" ERP organizations will focus on total cost of ownership, value delivery, usability, continuous business improvement, and targeted extensions (e.g., supplier relationship management, channel management). ERP vendors will offer enhanced post-implementation services to maturing ERP customers. During 2004-07, ERP vendors will redouble their efforts to penetrate the midmarket, competing more aggressively with Microsoft and a shrinking set of small ERP vendors. By 2007, ERP vendors will embrace Web services to support inter-enterprise integration.

There is always a great deal of excitement around the “mythical” go-live date for ERP. Quite often, however, this is the date when the project is supposed to end - not the date when all deliverables have been met. Therefore, the first phase of understanding ERP stability is to understand clearly the environment of the go-live date and its relationship to a stable ERP environment. This is important for IT staff, but it is especially critical for the business executives who “own” the project.

The State of the World on the Go-Live Date
The application center of excellence (ACOE) is the critical organization framework for delivering stable business applications, especially large ERP systems.

The ACOE is responsible for all business apps, and though quite large, is the “next” in the current portfolio. The ACOE staff handles functions that include the help desk, configuration, customization, testing, security, training, documentation, database administration, network, and operations issues. Most clients are poorly prepared to manage an ACOE; thus, the stability of the ERP system is greatly impacted. Done correctly, the ACOE manages the handoff from the go-live team and ensures that numerous key areas are covered, including:

• Functionality: Business owners should know unequivocally what has been delivered. All the required functionally must be documented, and end users must have been through rigorous training programs. Moreover, it is also assumed that the company conducted change management sessions with key stakeholders. This applies not only to business processes, but also to reporting/analysis. In addition, business users must have a level of assurance that integration with other business systems has been completed, and that bulk data transfers are in place to support data warehousing initiatives. We believe no more than 20% of new ERP systems have real clarity about functionality delivered.
• IT versus LOB roles: This question revolves around what expanded roles business superusers will play after go-live. In an ideal environment, some business users will have (close to) full-time jobs around the ERP systems, and will be actively involved in helping their colleagues (i.e., help desk requests) work on departmental reports/queries and designing new configurations as part of continuous business improvement. The IT group must develop application expertise (per module), which will enable it to perform customizations, manage testing, and play Level 3 roles on the help desk (since end users find wearing beepers anathema). We believe fewer than 50% of clients going live have sorted out the IT versus LOB roles.
• Help desk: The help desk should evolve from its traditional role. To be successful, problems should be promoted to the business, IT staff, and vendor, in that order. In particular, it is expected that the help desk (or security group) will carefully manage the assignment of new logon IDs to the system.
• Program/project offices: It is required that the ERP program office “live” beyond the go-live date and be able to handle various business and IT issues. In particular, the program office must be staffed to deal with the proliferation of change requests coming from the LOB. It is our experience that LOB staff members are quite creative (read: “We would love to have it the way it was”), and the program office must review all configuration requests carefully and make a determination as to which requests will be allowed.

• Dispersion of the ERP team: There are three main ways that the ERP team breaks up: 1) providing support for the new system; 2) resuming the members’ old day jobs; and 3) working on Phase 2 of the project. It is obvious that the more staff members remain with Phase 1 after go-live, the greater the chance for a stable system. Yet, this is not always the case.
• Help desk volumes: Soon after go-live, we would expect two help desk calls per user per month. As steady state is achieved, that should decrease to one call per end user every two to three months. The vendor should provide statistics on help desk volumes based on key variables (e.g., industry, number of physical locations, number of interfaces), and these volumes (computed over time) should be memorialized in service-level agreements between IT and LOB personnel.
• Managing change: A large amount of change (often welcomed) will come from new configuration changes (i.e., changing the system behavior without coding). New configurations will not impact stability as long as the following orderly process is followed:
  The end user configures the change on a test machine
  The new configuration is written up and presented to the ERP committee
  If approved, the configuration change goes to the IT group
  IT staff members manage all phases of the “promote to production” process
  
• Global shared services, global processes: There is an enormous tendency for LOBs to insist that their way is “special,” and for example, that they have a way of handling discounts that is entirely unique. The more the company globalizes shared services (e.g., accounts payable, procurement) and the more the LOBs must justify one-off configuration changes, the greater the likelihood that the system will become stable quickly.
• Globalization: The more countries in which the company operates in, the greater the likelihood of ERP instability. Great care must be exercised in globalizations after go-live, since business executives may insist on products, invoices, and purchase orders in local language.
• Phase 2 of the ERP system: The next phase of the project must be isolated from Phase 1, and IT and LOB executives must be sure that too many resources are not removed from the Phase 1 project.

Business Impact: The faster an ERP system is stabilized, the more quickly quantifiable benefits are realized at a manageable cost.

META Group originally published this article on 18 March 2004.