ERP and Business Continuity:
What the Experts Won’t Tell You

By Pat McAnally, Bill DiMartini, George Hakun and Joe Riley


Though the benefits of Enterprise Resource Planning (ERP) are numerous, including improvements in scheduling, idle time, inventory slack, and access to distribution channels, the use of ERP presents significant business continuity issues. Companies don’t want to talk about how vulnerable they are – for obvious reasons. And ERP vendors are in business to talk about how their software works – not about what happens if it isn’t up and running. System integrators are driving toward the completion of ERP installation and, frankly, don’t have too much experience with disaster recovery anyway. Fault-tolerant equipment manufacturers assure clients that their systems have redundant capabilities, but don’t address what happens when the physical plant takes a hit or the power grid goes down.

It is interesting to note that many companies now moving toward ERP implementation are also migrating to more complex, less robust client/server environments for the first time. In many ways, this technology transition can compound the effect of the new integration effort due to reduced platform reliability and lack of experience with client/server systems.

To understand the impact to the business of an outage, consider ERP’s key strengths:

• Integrated financials – once in place, the ERP system provides timely financial data without the need to "close the books" each month; there is no down time. But when an interruption occurs, the financial heartbeat of the company stops.

• Inventory management – companies learn to live by the tighter timeframes. But when ERP stumbles, the supply chain of raw materials stops.

• Sales – in a tightly managed ERP environment, this function is tied into inventory for availability and other systems for revenue recognition. But when the system is down, the demand loop stops.

In the broadest sense, the potential "holes" in the ERP dike fall into three general categories.

1) Complexity:
The complexity of an all-or-nothing system with so many interdependencies is an issue. Consider the multiplicity of "internal" interfaces, where different ERP modules interface with one another, different databases, third-party products, or even connections with existing legacy systems. External interfaces can be just as troublesome, creating exposures with connections to external payroll vendors, banks for wire transfer operations, and contract manufacturers, to name a few.

2) Resources:
Personnel resources and expertise are also problematic. In-house teams become fatigued from long installation schedules and unsettled by organizational change. The supply of ERP implementation professionals has always been less than the demand for them. The disaster recovery and contingency planning side of ERP is a skill set that is almost non-existent in the general job market.

3) Education:
The final category involves the mindset of senior management. Business continuity has never been a high priority item for some organizations. When it comes to ERP, the situation is exacerbated by the distraction of attempting to implement the new approach; little attention is paid to the risks of ERP. Educating senior managers about the career-busting problems with this new approach to business is critically important.

BRAVE NEW WORLD
Regardless of the industry, the prevalence and degree of integrated systems has shifted the entire business perspective. Organizations today are more sensitive to delays of any kind. The sheer scale of interconnectivity, whether it’s via the long-established electronic data interchange (EDI) or a newly created e-commerce application, is a great example of how so much has changed.

In the pre-ERP world, a business had multiple points of failure, key junctures in systems and processes where a breakdown was possible, but there were lots of work-arounds. In the ERP era, there are far fewer points of failure – but now the company is entirely vulnerable all at once – with no recourse for manual procedures and no tolerance for a recovery lag time.

When time becomes an increasingly critical asset, the organization must have a get-back-in-business strategy. In the past, a "traditional" recovery process would involve lag time between the incident and full restoration – involving travel time, tape retrievals, and often lengthy data restoration. For some organizations, a few days was acceptable, for others 24 hours was the requirement. What many now implementing ERP solutions fail to realize is that, for them, once they "go live," their strategy must include a real-time solution. Otherwise, while they are busy bringing systems back on line, the organization comes to a complete standstill. Production stops, billing stops, functions like sales and inventory stop, paychecks can’t be issued, etc. The list goes on and on, depending on the number of enterprise "modules" or functions tied together.

To make matters worse, the safety net of manual procedures to recapture lost data – the "catch-up" as it is commonly called – may not be an option for an ERP-based company. Personnel are not available; the paper trail only exists electronically. In this new breed of organization, the automated system has so much control over the proceedings, that the system is the business.

If traditional recovery efforts can be categorized as application recovery, then the ERP version of recovery is really infrastructure recovery. Recovering an ERP environment is an intricate three-tier process – which is not available unless all three tiers are in place:

• Database server with all the master applications
• Applications servers; front end systems; and subsets like middleware traffic, third party code and other tools
• Individual desktop PCs and workstations that serve as the enduser interface

For the ERP-dependent organization, a traditional 48-hour recovery could be a death-knell. The company’s required recovery "window" has been narrowed substantially by the increased level of integration within the business, and alternative approaches are needed to remedy the situation.

But how can this be done?
First, we need to reset our thinking - this ERP environment is not a hardware issue. The technology is basically the same as one finds in a non-ERP environment. What is distinctly different is the business imperative.

Business continuity planning and ERP share a common thread: they are both business issues, not technology issues. The business model supporting ERP will clearly show the penalty for interrupting the supply chain – one that is high relative to the cost of protecting it. Planning performed at the same time as the system integration is far more cost effective and allows companies to do it right the first time. Done jointly, one process hones the other.

THE CONTINUITY PLAN
Developing an effective continuity plan is no easy task. It’s a lot of work. Done right, it yields a measure of security for a business that has likely invested millions in ERP implementation. The following pointers may be helpful to keep in mind:

• Take on the business continuity issues at the start of ERP implementation.
• Your own internal people will already be fatigued by the long ERP installation process and other organizational change efforts underway. Assign business continuity experts to assist in developing an ERP-specific plan and look for them to provide experience in both multi-vendor and ERP environments.
• Develop a continuity plan that details interdependencies within the ERP solution and between ERP and the rest of the IT system infrastructure.
• Test the continuity plan on a frequent basis, using detailed scripts.
• Elevate the risks of an ERP system outage to senior management and get them involved early to come up with the right solutions. They must understand and respond to this risk.


About the Authors
This article is excerpted with permission from a White Paper prepared by SunGard Planning Solutions. The paper, located on the website www.SunGard.drexperts.com, was edited by Pat McAnally and contributors included Bill DiMartini, George Hakun and Joe Riley.