Low-cost options for integrating. (Enterprise Integration).

A consultant examines two alternatives to major enterprise resource planning (ERP) applications, both of which can be implemented at far less cost and offer significant enhancements over multiple systems, he says.

As a result of mergers, acquisitions or a lack of IT standards, many large firms have grown into a hodgepodge of business units operating on different technology platforms. Faced with a variety of older legacy systems, different ERP vendors, different versions, numerous configurations -- or all of the above -- some companies simply opt to forgo the benefits of consolidating their financial functions and stay separated.

Others invest hundreds of millions of dollars in a common ERP platform prior to consolidating. Still others consolidate organizationally but continue to operate and maintain separate platforms. Clearly, these solutions have major drawbacks. Are there other options?

Rather than choose between the high costs of a single ERP and the constraints on productivity and customer service of multiple systems, some companies have found another way: connecting the multitude of different customer applications to a common front end.

It takes work, but the risks are containable and the benefits can be enormous. Imagine yourself in a world where your associates sign on to one system in the morning, enter transactions that post through to multiple systems, electronically route transactions to many different approvers or downstream processors, access data from these same multiple systems to respond to inquiries and generate reports that consolidate or compare data from those systems.

Imagine also that your associates are experts in the system and their jobs since they have only one seamless process to learn. Now imagine that other users such as customers, vendors and employees can access this world through a role-based portal, enter their own transactions and data and query their own information. And, hang on to that vision -- because it's what will sustain you through the effort of tackling integration.

Embarking on a technology integration strategy presents a spectrum of options, bounded by two dramatically different approaches. We'll call the first "gatekeeper" (because "asynchronous batch interface" is a mouthful) and the second "enterprise application integration," or EAI.

Both of these approaches have a multitude of variations, but we can simplify by describing them in terms of two recent "real world" examples, each involving a multinational, Fortune 100 company with multiple business units operating on 40-plus systems, looking for ways to expand and improve its shared-services offerings.

Gatekeeper

Weighed down by many older legacy applications, Company A at first opted for an ERP "big-bang" approach. Unfortunately, limited funding and a lack of centralized decision-making presented obstacles too difficult to overcome. Given its legacy proliferation, the approach it took was creative: Implement "best of breed" applications for accounts payable, billing and accounts receivable, fixed assets and travel & entertainment in the shared-services environment and link them to the older systems in the field, as shown in Diagram 1.

The benefits were huge. The new shared-services applications gave the company modern tools such as workflow and configurable tables that offered clients "flex points," while maintaining underlying process standardization, some self-service functionality and many other productivity and quality enhancements not available in its heritage applications.

On the downside, the links it built to field systems were not real-time, required effort to create and required ongoing maintenance. Also, the gatekeeper platform, while scaleable, is "linear" in the sense that future expansion (in terms of more clients or processes) requires proportionate investment. Yet, these shortcomings, even collectively, were not deal-breakers, especially when compared with the benefits.

In essence, the gatekeeper process synchronizes data of the shared-services "best of breed" applications with data contained in the field legacy systems -- most often, at the underlying database field level. As an example, purchase order (PO) data is exported from the legacy system and imported to the shared services accounts payable (AP) application. When invoices come in (electronically or manually), they are posted, matched to the PO, queued for payment and paid on their due dates. Non-PO invoices are routed as necessary for approval and coding before posting and payment. AP data and PO history are summarized and posted to legacy general ledger and purchasing systems through reverse export/import flows.

These exports and imports (or database synchronizations) are scheduled and run automatically several times a day by the gatekeeper -- which acts as a traffic cop to data flows. Nothing collides, bad data is stopped and good data flows smoothly. While not real-time, updating several times a day is often enough to satisfy business requirements for many processes. Also, the use of mapping tools simplifies development and maintenance of the gatekeeper. All things considered, it's a very workable solution despite some challenges and compromises.

Enterprise Application Integration

Company B also had a number of different technology platforms supporting its business units. However, most were various versions and instances of more modern ERP systems from vendors such as SAP, Oracle, J.D. Edwards, PeopleSoft and Lawson. Because of this, Company B was able to take a wholly different approach to integration: Develop common data entry, query and reporting screens for shared-services associates and link them real-time to field systems through a multi-tiered "middleware" infrastructure, as depicted in Diagram 2.

As information is entered in the shared-service center, it is immediately recorded and available to field users through their normal ERP interface. Likewise, when inquiries or reports are made, they directly access ERP data. To further improve service delivery, other tools (such as imaging, self-service portals, asset inventory/control applications) are interfaced to the middleware box once and used for all clients.

To understand why Company B could elect this option, a little technical explanation of the EAI toolset is required. In terms of integration, the advantages of ERPs are twofold. First, they expose their internal business logic and rules to the outside world through an application programmatic interface, or API. Second, standardized connectors, developed by application providers and third parties, enable external communication with ERPs.

An example shows how EAI works. A processor keys in a vendor number in the common front-end application developed for invoice entry. To make sure the number is legitimate, the front-end application kicks-off a "validate vendor number" task. The need to run the task is communicated to the appropriate ERP via the connector. Since the ERP already has a process for validating vendor numbers stored within its business logic, the appropriate API is called to launch the ERP process.

When executed, the vendor number is validated against the ERP's vendor master, and a message is returned to the front-end via the same connector. If everything is okay, the invoice entry session continues; If not, the session is interrupted with an error alert to the processor. While this may sound complicated, it all happens in the time it takes for the processor to move to the next data-entry field.

Think of the implications: In addition to providing real-time access, the EAI method ensures data integrity at the ERP level. Rather than having its own data store that's routinely synchronized with client systems through a gatekeeper, EAI makes the client's ERP the "system of record" and sole repository for financial information. Put simply, there can't be mismatching data if the ERP has it all. Second, knowledge of where a data field exists among the thousands of data tables stored in an ERP is not needed, since developers aren't trying to map specific data elements. This dramatically lowers up-front development effort. Lastly, the potential for errors to occur during synchronization is eliminated.

In the end, for Company B the vision is not simply achieved, it's surpassed. They get all of the benefits of Company A's gatekeeper, plus a more easily maintained solution. In fact, code changes in the EAI system are necessary only when there is a major change in a client's ERPs, such as a full-release upgrade or a switch to a different ERP platform.

In terms of expandability, the EAI approach is both scaleable and lever-ageable. Connectors can be reused for clients with same-version software, in contrast to gatekeeper's need to re-map for every system instance.

Also, new processes can be economically added to the EAT infrastructure by reusing the more-costly internal components. Finally, the EAT platform provides flexibility to move shared services beyond transactional processing and into the role of information broker.

Because of its highly scaleable infrastructure, an EAI solution allows for rapid expansion to include additional financial and human resource functions. EAI offers more than just fast, economical growth. It also offers the promise of better information -- information that is more consistent, accurate, timely and transparent.

This is accomplished in three ways. First, reports can pull, consolidate and compare data from any system connected to the infrastructure. Think virtual close. Second, EAI applications provide one connection point for databases, data warehouses or OLAP applications. Examples here could include enterprise-wide vendor and customer masters with sales and procurement history, just to start. Third, process transformation tools such as customer relationship management (CRM) and e-procurement exchanges can be implemented across multiple business units, again with a single connection point.

Selecting Your Integration Strategy Integration, through whatever approach you choose, is merely a tool to help enable an overall business consolidation strategy. As such, it can be a very powerful tool, as it is for the two companies discussed above. At a cost of less than 5 percent of a company wide ERF implementation and a timeline of about a year, it can be a very affordable and practical way to achieve the vision.

So which strategy and how fast? Table 1 summarizes the discussion above in terms of conditions and criteria for picking a basic approach. While both approaches offer the vision, the differences are quite clear. And it's important to note that either approach can be done in stages -- one process, one ERP version -- in a way that creates learning and reduces risks as you go.

The Gatekeeper approach is a straightforward solution if you have legacy systems or can assume that there will be no major changes in the immediate future. By contrast, EAI, with its scalability and real-time data access, is a forward-looking solution that can readily expand to absorb new functions. While best suited to integrating more modern ERPs, it can also be custom developed to link legacy systems.

Table 1

Integration Approach Comparison

Criteria          EAI

Operating         Modern applications such
Environment       as SAP, PeopleSoft, Oracle,
                  JD Edwards

Data Integrity;   Data resides in one place;
Timeliness and    real-time access
Accuracy of Data

Expandability     Scaleable and leveragable

Access            Anyone with a browser
                  and a secure connection


Maintainability   Code changes are needed
                  only for a major change,
                  such as a full ERP release
                  upgrade

Criteria          Gatekeeper

Operating         Older legacy systems such
Environment       as mainframe applications
                  or older homegrown systems

Data Integrity;   Data in two places
Timeliness and    needs to be kept in sync;
Accuracy of Data  updated at intervals

Expandability     Scaleable only

Access            Limited to users with access
                  to applications inside the
                  corporate network

Maintainability   Need to maintain shared
                  services applications and
                  update data maps for
                  changes in underlying data

Rick Bertheaud, a Director with Gunn Partners, an Exult Company, specializes in bringing operational excellence to large corporate administrative functions. His consulting experience has involved all areas of finance, HR and procurement. He can be reached at [e-mail] or 413.566.9840.