In-Depth

ROI or DOA? ERP Deployment Without Workload Management Can Kill the Project

• 09/01/1998

Lured by the promise of Enterprise Resource Planning (ERP) technology – increased efficiency of business processes, improved quantitative/qualitative data, enhanced decision support, reduced cost of operations – the Fortune 500 has raced to jump on the ERP bandwagon. Only a few years after companies like SAP, Baan, and PeopleSoft emerged from obscurity, it’s the rare Fortune 500 company that doesn’t have an Enterprise Resource Planning (ERP) project in the works, in development, or in production.

Migration to an ERP system is an immensely complex and invasive undertaking, one that reaches into all areas of the business and frequently takes years to complete; costs may run into the tens or even hundreds of millions of dollars once expenditures on hardware, software, consulting, testing, customization, administration and training are totaled. Yet, despite the immense investment required to get an ERP system into production, a surprising number of corporations fail to plan adequately for post-deployment operation and administration of their ERP systems.

"When you’re implementing a large ERP application, your attention and resources are spent making it work, getting it implemented," explains Gordon Lamb, ERP Management Technical Manager, GE Capital. So the whole management and operations of this environment seems to get ignored until the last minute, or sometimes even after it’s gone into production." Top-level executives may be focused on achieving immediate business objectives (such as rolling out the chronically late, over-budgeted ERP system). They may believe that the ERP system will include adequate administrative tools, or that existing management facilities will suffice to administer the ERP system. More often, they simply do not consider what will occur after the ERP application "goes live." As a result, the IT operations staff too often finds itself administering business-critical client/server applications without adequate preparation and lacking the basic management tools that would be considered essential on the host.

Unfortunately, without effective management even the most carefully planned and implemented ERP solution cannot hope to perform as designed. Too many things can go wrong, from basic network or system glitches to failed batch jobs, lost output, or slow or overworked systems. Nor can IT infrastructure monitoring tools (such as a network management platforms) offer adequate monitoring and control of the ERP application. These consoles can tell an IT administrator that the servers are up and the network response time is excellent, but if last night’s order fulfillment job didn’t run, a ship-shape computing environment won’t explain a failed business process.

To ensure that an ERP system is operating correctly and at peak efficiency, IT must have control of and visibility into all the processes that comprise that system. This is no simple task: ERP installations typically generate hundreds of jobs, from batch processing, database updates, ledger postings, to order processing, report queuing, server back-ups and more. At Philips Semiconductor, for example, which is rolling out Phase I of its ERP project in North America on Baan, the IT operations staff has already identified over 170 jobs that will require scheduling across four Baan application servers and a database server – in addition to jobs scheduled on the mainframe. Most of these jobs are business-critical; operators must ensure that they run correctly, on time and in the correct order, and they must be able to quickly respond to any problems or failures.

In the centralized host environment, managing the workload was typically a matter of scheduling batch jobs in the appropriate order. Host administrators have powerful tools, such as OPC to help them automate the scheduling process: starting jobs based on calendar dates or other events; defining dependencies among jobs; and recovering gracefully from failures or notifying appropriate staff to attend to the problem. The distributed environment in which most ERP applications operate is far more complex. Yet, more often than not, administrators lack even rudimentary tools to manage workloads, and are forced to rely on a home-grown, patchwork solution based on native OS utilities and whatever scheduling functionality may be included in the ERP application itself. Frequently, administrators wind up scheduling and launching jobs manually, a labor-intensive and extremely error-prone method of handling business-critical data processing.

Such a casual, uncoordinated approach to handling corporate workflow is a sure-fire way to sabotage an ERP project for a number of reasons:

1. Complexity of the ERP Environment. The typical ERP solution in a large corporation is a networked, client/server-based application (or group of applications) that typically resides on multiple, geographically dispersed servers across the enterprise. It may extend into multiple operating system environments (NT, UNIX, OS/390), and require data transfer to and from multiple external applications and databases.

A typical example of such a system is in production at Sonoco, one of the world’s largest packaging goods manufacturers. Sonoco is converting two of its largest divisions from mainframe processing to client/server systems running ERP applications. The company selected Baan running in conjunction with I2, a decision support package, and PeopleSoft Financials and HR Payroll Benefits on the financial side. Legacy financial data remains on the company’s IBM mainframe, which also hosts a separate ERP system used by one of the company’s divisions. The databases and applications for PeopleSoft and Baan run on distributed UNIX systems, and data must also be sent back and forth from the NT environment, which supports Sonoco’s Lotus Notes application.

This complex data processing environment is, unsurprisingly, "a management nightmare," according to Dan Theismann, Manager of Support Services at Sonoco. Information must constantly flow back and forth across the various platforms to the correct location at the correct time, and in the correct order. Data on inventory transactions recorded by the ERP system must be reformatted and transferred to the financial package for inventory-on-hand and financial reporting; invoices created by customers through the ERP system must be transferred to yet another financial package to be reconciled with accounts receivable. Hundreds of such cross-platform, time-sensitive, multiple-dependency jobs must be launched and monitored for the ERP system to function as planned.

Given this level of complexity, Theismann explains, manual or custom-scripted scheduling was simply not an option. "When we mapped out what it would take to keep track of all the different jobs and the scripts that we would have to write just to pass files between platforms, and when we started adding the number of man-hours and considered the potential of information being lost, it was quite clear that automated scheduling needed to happen."

2. Limitations of ERP Scheduling Utilities. Given the huge outlays their companies are making for ERP applications, executives might be forgiven for assuming that these applications will magically run themselves, but alas, this is not the case. While most ERP applications do provide some basic scheduling services, the level of functionality is inadequate for managing a complex production environment.

Most ERP packages do not come with necessary scheduling capabilities like business calendars and high numbers of dependencies. Nor do they offer visibility into a job once launched. If the job fails, the operator must restart it from the beginning. There is also no way of terminating jobs that are running, so runaway processes must be allowed to continue to their natural termination point, if and when that occurs. Most importantly, none of the scheduling tools enable scheduling of jobs outside of the ERP application environment itself, so that all transfers of data into and out of the ERP system must be performed manually.

While ERP vendors may not volunteer these limitations, they’re not concealing them, either. To the contrary, most are working closely with third-party workload management vendors to develop more robust, cross-platform scheduling solutions. Products like Tivoli Maestro, for example, provide internal and external scheduling for Baan, SAP R/3 and Oracle.

3. Inevitability of Change. Frequently, IT operations staff will attempt to address the gaps in scheduling functionality through custom scripting (using the CRON function in UNIX, for example, to schedule jobs). Unfortunately, the IT environment is rarely static, while custom-scripted solutions tend to be fixed.

A large wholesale drug company, for example, realized early on in its SAP R/3 deployment that it needed a way to schedule data flow across multiple systems – inventory management, pricing/contracts, routes and deliveries, and general ledger – running on different platforms. IT administrators decided to script a custom application to handle the transfers. Not surprisingly, the project proved far more complex than envisioned and ultimately took eight to 10 man-months of skilled labor to complete.

Unfortunately, the hard-wired scheduling system proved inept at handling ad hoc requests. Customers would dial in to the application to place orders. This required a coordinated response across the entire system as these customer requests were first batched at the foreign host, then sent to SAP R/3 to fulfill orders and send the status of each transaction back to its original requester. Because the process was initiated by the end user, it could not be effectively handled by the inflexible custom scripts and the company eventually abandoned the scripting project altogether in favor of a third-party scheduling tool.

Even in relatively predictable environments, change is likely to occur with enough frequency to ensure that IT will never stop scripting. Updates to the operating system, the ERP system, the database, or any of the other applications accessed by the ERP system render existing scripts obsolete. Without the flexibility of a centralized, automated scheduling tool, IT operations staff may find themselves effectively in the business of application development, as they constantly work to revise their shell of scripts. And even if they’re up to the challenge, they still will have no ability to monitor or manage the jobs that are running on their systems. The procedure for launching business-critical processing will remain "click-and-pray."

Achieving effective workload management in the ERP environment requires a robust scheduling package capable of automating, coordinating, and monitoring jobs across multiple platforms. However, tools alone cannot suffice to ensure smooth operations. IT must have a clear understanding of the ERP system, the business functions it supports, and the jobs that must be performed in order to provide that support. [See Sidebar: 9 Keys to Effective ERP Workload Management]

On the other hand, without an effective cross-platform scheduler, even the best-organized, most efficient IT operations staff will have trouble keeping tabs on the hundreds of jobs running in the enterprise. Unfortunately, selling executives on the business payback of production automation tools like job schedulers is no easy task. Executives see the up front cost of workload management, but they may not understand the cost of not deploying them – and those costs can be substantial. Manual, ad hoc job scheduling is a risky proposition, and every time a job fails to run, or runs incorrectly, it has an effect on the corporate bottom line. End users may be left without the information they need to make key business decisions; customers may be prevented from placing orders; invoices may not be sent or may reflect incorrect data; data may be posted twice, generating incorrect data which is then used for corporate decision-making, compounding the error.

Fortunately, the business case for workload management is not difficult to make. The advantages of centralized, automated workload management are well-established in the host environment, and they are becoming just as compelling in the client/server ERP environment:

Reduced Costs of Operations. Workload management products free IT from the necessity of writing and revising scripts and launching and monitoring jobs manually. They can instead set up schedules based on business priorities and manage by exception. Centralized scheduling also eliminates the need to train IT staff on multiple platforms; instead, they can manage distributed systems through a common interface.

Increased Efficiency of Business Processing. In the ERP environment, like the host environment, there is typically a batch window that must be managed. By efficiently scheduling processing during that batch window, and intelligently distributing that processing around the network based on system availability (load balancing), IT can ensure that necessary processing is completed in the allotted time. It can also intelligently schedule ad hoc jobs to execute in the most efficient way, based on business priorities.

Improved Reliability. An effective workload management tool typically includes fault-tolerant capabilities that ensure processing will continue in the event of a network or system failure. It can automatically restart failed jobs at or near the point of failure, rather than at the beginning. By identifying the point of failure, IT can identify and correct problems in the data processing flow.

Greater Data Integrity. Data in transit is data at risk, and by clearly defining dependencies among jobs, tracking jobs from initiation to completion, and quickly responding to errors, a workload management tool reduces the chances that data integrity will be compromised through job failure or error. Centralized scheduling also enables improved security, ensuring that changes to workloads are authorized.

Increased Flexibility. Business is constantly changing as user and business requirements change. A central job scheduling package enables simple reconfiguration of corporate data flows based on business priorities. It will also scale as the scope of the ERP project increases.

Conclusion

ERP systems are highly complex, distributed applications that can generate hundreds or thousands of jobs, and they require robust, host-class operations management if they are to perform as designed. Unfortunately, while powerful client/server workload management tools are currently available and – relative to the cost of the ERP project – inexpensive, they are often overlooked by the ERP launch team in their rush to deploy the new system. By identifying the need for robust workload management early on, including IT operations in the ERP deployment process, and concurrently deploying a cross-platform scheduler, corporations will be taking simple, common-sense steps towards realizing the ROI on their massive investments in ERP technology.

ABOUT THE AUTHOR:

To Sidebar