CPR for ERP: Page 2

(Page 2 of 2)

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.

  • Page 2 of 2

    Previous Page
    1 2

    0 Comments (click to add your comment)
    Comment and Contribute


    (Maximum characters: 1200). You have characters left.