CPR for ERP

See if this scenario sounds familiar: Your company–or one that you know of–has bought into the admittedly alluring idea that you can purchase commercial enterprise resource planning (ERP) software that integrates the entire enterprise. This concept will allow you to use sexy new Web or client/server technology that replaces all of your ugly, homegrown mainframe systems that just can’t seem to keep pace with your needs. Even better, because you are buying instead of building, your business experts can be in charge of the implementation instead of the technocrats in IT. Without IT and their tedious development and testing disciplines underfoot, things will move much faster.

It’s not as though you won’t need some help, of course. A crack team of consultants will parachute in for this event–but they won’t be customizing the software, exactly. They’ll be reengineering your business processes to take advantage of the powerful new system. So, as soon as they have configured a few options here and there to take into account any idiosyncrasies of your operations, they will be airlifted out and you will be catapulted into the promised land of streamlined efficiency. Oh, and IT can keep things humming along with a couple of people.

Customizing software is almost inevitable, but the minute you change it, you can no longer accept new upgrades from the vendor without reimplementing the changes–and retesting everything!

So what’s wrong with this picture? It’s what happens next.

The unfortunate fact remains that few companies conduct their operations in a homogenized manner–the trend toward business-process standardization notwithstanding. In fact, it is often those very business-process idiosyncrasies that give the company a competitive edge. Few purchased enterprise systems can actually replace every nook and cranny of your homegrown applications; so some coding around the edges is inevitable.

What this means is that few, if any, ERP implementations are out of the box. Every last line of business-process configuration or software customization has to be developed and tested before the initial implementation and every time a new release of the ERP system is installed, or a configuration change is made, or your infrastructure is upgraded, or… Get the picture? By then, the consultants, their expertise, and the hefty budget, are all long gone.

Business-process contortion

Consider the manufacturing conglomerate that sought to replace a crazy quilt of legacy applications with a fully integrated ERP system. The company understood the enormity of the task and budgeted the time, money, and consulting resources accordingly. Two years were invested in exhaustive analyses of the existing “as is” business processes and reiterative design of the target “to be” processes. Out of this came a set of distilled business rules and transaction scripts used to configure the ERP system. About a dozen legacy applications that had no commercial equivalent were integrated through a series of interfaces, coming and going. End users around the world were trained in the avalanche of new processes, and the implementation team of both consultants and power users conducted lengthy and detailed tests. The deadline arrived. Go live!

The first few weeks were a little rough… OK, really wild. The help desk was completely overwhelmed as end users struggled to map their responsibilities to the new order. Security was a problem, as the clearance levels controlled access to processes, and many users found themselves without permission to get their jobs done. Various interfaces failed, many because they weren’t integrated into the job schedulers. The servers showed immediate signs of performance hiccups so upgrades were put on order.

In some cases shipments had to be sent by charter jet, since the whole coordination between manufacturing, warehousing, and shipping had a few kinks. No less than 60 consultants raced around, pagers humming, cell phones ringing, plugging their fingers into holes in the dike. An extension to the project budget had to be approved to keep the consulting team around longer, and heated negotiations took place to keep on board key people who had already been scheduled for their next project.

Eventually things seemed to calm down, but it was more like being in the eye of a hurricane. Three things happened in the ensuing months:

• First, a growing stack of change requests began to pile up. Many from process decisions that sounded good on paper, but simply failed the reality test. Often processes are policies in action: For example, “the salesforce will never be allowed to ship goods on approval” is a policy decision that is ultimately enforced by the software. Naturally, the first order from a key customer for a new product was sold on approval, with promises of much bigger orders to come if the product passed customer acceptance. Because the software did not permit it, complicated workarounds had to be created.

These change requests were added on top of the list that had already been accumulated from the initial implementation. As the deadline neared, requirements that didn’t make the window were sidelined for “later.” Some of these requirements were for integrating systems that had initially been stuck together with paper clips and tape, with the promise of future efficiencies.

• Second, the new equipment upgrades began to arrive. The data-storage requirements were underestimated, burgeoning history files were filled with transactions no one wanted to purge because, well, just in case. The overall throughput ground to a halt during certain jobs, and there were mysterious, intermittent breaks between interconnected networks.

• And, finally, the ERP vendor announces the availability of a major upgrade that contains many critical enhancements–just to complete the coming chaos.

No free rides

It became painfully apparent that implementing ERP is a process without end. Just because you buy a system instead of build it doesn’t mean you are out of the software-quality business. In this case, the hapless IT department found themselves with a high-risk task–rewiring the house while keeping the lights on–and a fraction of the resources and budget that had been allocated for the initial implementation. Because the original configuration and testing had been primarily performed by consultants, the IT department lacked people, processes, and the skills to do it effectively and efficiently.

Few purchased enterprise systems can replace every nook and cranny of your homegrown apps, so some coding around the edges is inevitable.

The lesson here is there are no free rides. There is a reason why you have an IT department and all of those stodgy–but critical–disciplines like software integration and system- and acceptance-testing. The software, infrastructure, and business processes have to work in the real world.

Further, making the software fit the business makes customization almost inevitable, but the minute you change the ERP software, you can no longer accept new upgrades from the vendor without reimplementing the changes–and retesting everything! The consultants who made the original changes are long gone, of course, so guess who gets saddled with this adventure? Those pesky IT people. How ironic.

Finally, the old, stodgy mainframe you just “had” to get rid of in order to join the new technical order has been replaced by a patchwork of servers, and your systems support costs have been multiplied instead of divided. You quickly find out there was a reason for those cumbersome layers of systems management and security software.

Software is software, whether bought or built, and you have to be sure it fits in with all the surrounding systems, that it works end to end, and that your business users can still get their jobs done in a timely and efficient way. And, you don’t have to do this just to “go live” with ERP, you have to do it forevermore. //

Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.