(a composite case study of how companies in the employment services sector applied integration modeling techniques to their ERP objectives)

Today's most successful companies understand and practice enterprise application integration through innovative approaches and techniques. A composite story, drawing from experiences applying Enterprise Resource Planning (ERP) software with companies in the employment services sector, provides an example of how such companies can apply integration modeling techniques to ERP objectives.

The packaged software that is provided by ERP vendors such as PeopleSoft, SAP, JD Edwards, and Baan delivers improved enterprise application integration by offering an integrated suite of applications to perform standard business functions. Back-end functions such as accounting, inventory, and shipping are supported, as well as front-end functions such as call center and sales force automation. ERP packages are used in conjunction with business process improvement techniques to upgrade big chunks of a company's supporting systems.

Companies undertake ERP implementations when they need to integrate multiple systems quickly. Sometimes business competition forces companies to undertake ERP initiatives, when competitors, due to tight integration of their own systems, can offer more desirable services and product features. At other times, technological advances require that a company upgrade all its systems to keep up with new opportunities. Yet another reason companies install ERP systems is when outsourcing initiatives have failed and they want to reinstate their own information technology systems support. When bringing this function back inside a company is a good time to overhaul the systems and make sure they're integrated and maintainable.

The new Chief Information Officer's charter was to replace obsolete computer systems with current packaged systems, providing a competitive advantage through technology. This meant using advanced systems to bring more resources to market (that is, filling jobs faster with their temporary employees), while at the same time slashing prices by reducing operating margins. The goal was to implement improved business processes by configuring and installing packaged ERP systems according to the results of an enterprise-wide reengineering effort.

The sales and service delivery team would be able to fill jobs faster with temporary employees by using sales support applications that were configured based on best practices identified and propagated throughout the organization's distribution network. New business acquisition and retention of existing customers would be enhanced through customer management software and customer information reporting.

The field offices would be able to reduce operating margins by using packaged applications that support field office functions, such as billing, payroll, time accounting, and collections. The definition of core business processes, flow of activities, and decision support needs would ensure the proper configuration of the packaged software to take advantage of reengineered processes with the latest technologies.

The pre-integrated nature of the ERP-packaged software would provide a new baseline for all the company's systems, including those that would not be involved in the initial installation. These included isolated systems without integration requirements, systems that were not included in the available ERP functions, and unique in-house applications and customized applications. Systems would be converted into the new order on a scheduled basis, and new development would target the standards established by the ERP implementation. As all applications migrated into the new systems environment, integration would increase and the company would begin to develop sophisticated knowledge management at the corporate level to be used for decision-making.

The CIO's main problem was the seemingly insurmountable gap between what he knew (the fragmented puzzle of the company's current systems) and what he needed to know (business requirements for the new systems). He had very little information about how the existing systems were actually being used to conduct business. His technical managers, field managers, and the headquarters staff that supported them all wanted the package installation to succeed. All held a piece of the information needed to make it a success, but none could see the whole picture. Without the crucial understanding of the use of current systems as a basis for defining future business requirements, the implementation project risked missing the mark.

When integration modeling techniques are applied to our CIO's problem, they fill the gap by gathering company intelligence and consolidating it into models that can be taken in at a glance. The models are used to analyze requirements for configuring the new system and to orient the technical team implementing the new software.

Figure 1 shows the process methodology followed in this example for ERP integration.

Figure 1 (click on picture to enlarge)

The process model for this ERP integration project shows the steps involved in developing the requirements for an ERP implementation. The products from each step of the process are added to the evolving set of deliverables. Deliverables from earlier steps are utilized and refined by later steps. Early steps are completed with the support of the sponsor (in the case of this example, this would be the CIO) and his senior technical advisors, setting up the heart of the process - the serial interview of business area representatives and subject matter experts. Serial interviewing proceeds in iterative fashion with the application of integration models and techniques to analyze and improve on the initial models. The next sections describe the details of the seven steps of the process:

1. Identify roles and resources.

2. Build "best guess" models.

3. Validate "best guess" models.

4. Conduct interviews with internal experts and external sources.

5. Analyze and improve models.

6. Generate recommendations.

7. Present deliverables.

The first step is to introduce the new roles required specifically for an integration project. The next several sections describe these roles.

The champion is the process owner and "chief persuader," the overall coordinator and internal PR agent for the project. He performs the following functions:

• Helping build enthusiasm
• Educating others on the project's benefits
• Generating support throughout the organization

In this example, the CIO clearly became the champion for the project. Monthly and sometimes more frequent meetings were held with the champion to provide ongoing updates and mid-course corrections for the duration of the project.

Business area representatives from across functions provide a sounding board for the duration of the project, giving input on what works and what doesn't (from the field). Contributors are also responsible for ongoing prioritization of needs. Represented areas include the following:

• Sales - Can include the senior executive for the sales area. Would also include salespeople from the field and branch or regional managers.
• Marketing - In our example company, the Vice President of Marketing became an important project ally, working closely with the integrators and the project champion to set direction and provide organizational support.
• Corporate Management - Includes CEO, President, and Vice-President levels. Interview results are summarized and applied to help define the goals and priorities of the project.
• MIS (Senior Technical Analysts) - Systems managers and senior technologists knowledgeable about the company's systems environment are essential to the success of the project.
• Product Engineering - New product development, research and development, managers, and technical specialists are included.
• Business Planning - Strategic planners, senior marketing executives, investor relations experts, and sometimes legal counsel can be included, depending on the goals of the project.
• Service Delivery - Line managers, customer service providers and their managers, regional executives, and branch staff can all be included from this perspective.

The role of the integrator is flexible and fluid. It requires a tolerance for ambiguity and the ability to provide reflective feedback to project stakeholders. Some of the functions of the integrator include

• Conducting the project.
• Conducting open-ended interviews.
• Starting outside the box.
• Stepping in to define issues.
• Identifying candidates to resolve issues.
• Getting back out of the box through a phased approach.

When the new roles have been introduced and understood, the integrator works with the project sponsors to identify and assign the initial resources required, including

• Internal experts to be consulted, such as subject matter experts and representatives of the business areas affected by the project or business initiative.
  
• External sources, such as industry associations, online information, consultants, and competitors.
  
• Existing models, systems, and information repositories that will be consulted to gather information for the project.

As the consultation of the initial resources identified proceeds, additional contacts and sources will surface and can be added to the list. Depending on the time availability and the depth of organizational contacts of the project sponsors, the initial list can be limited or it can be fairly comprehensive. It should not be exhaustive.

The goal of the next step is to develop a starting point for viewpoint analysis models that capture the essence of each significant point of view represented in the project.

Scenarios and viewpoint analysis models enable you to model current usage of applications across the company, interviewing as needed to understand individual differences in requirements. You then produce a series of models for each viewpoint, gathering an understanding of what is most important to each perspective.

The integrator will do just enough preliminary research to pull together a straw man, or discussion starter, as a basis for interviews. The straw man is a descriptive model you set up so that people can knock it down and correct it, which is easier than starting from scratch.

Validate the starting point models by reviewing with members of the technical team, and by reviewing existing documents. If necessary, do some external research on the industry to make sure you understand the basic concepts of doing business in the target market space. Test your models against a brief review of industry norms.

Serial interviewing is the preferred method of gathering information in viewpoint analysis models. The goal is to understand the different viewpoints without having them modify one another, as usually happens in a group setting such as Joint Application Design or focus groups.

Interviews should start by introducing the goals of the project, the point of the models, and the conventions of the models. Interview subjects can depart from the preliminary models and just describe their situation, or they can offer updates to the models. Use them as conversation starters, not as formal controls on where the interview can go. In the same vein, predetermined survey questions are usually not recommended. If desired anyway, send them out ahead of time and collect responses at the interview, only clarifying verbally what's not clear from the written responses.

A sample scenario and the related view model are presented next.

The IT department has teams supporting systems in 12 sites across the country, and the only similarity between the 12 is the general function the systems are performing. Different hardware and software configurations are in each site- some PC-based, some midrange, and a couple even running dumb terminals against old mainframes. The software was written at different times by different vendors, some of which aren't even in business anymore. It's a hodge-podge of aging systems, and a big problem is there's no way to leverage resources across that chasm.

No one can provide an overview of all the systems. None of the technical managers can see the forest for the trees, and they spend all their time putting out local fires. What's needed is not just knowledge of all the systems and what they do in technology terms. What's really needed is to know why they do what they do, and whether they need to continue doing it, today and tomorrow. Because not only must yesterday's systems and technology be understood, but also the main charter is to bring those systems into the new millennium by installing Enterprise Resource Planning systems. At the same time, new technologies must be utilized to pay off by supporting re-engineered business processes and the changing demands of a fast-paced marketplace, before the competition does it first, and puts the company out of business altogether.

The CIO View model (see Figure 2) shows a broad viewpoint, with high-level information about systems, and the end users of the technology represented. It describes the functions of the systems while stopping short of employing technical names.

Figure 2 (click on picture to enlarge)

This is the point where you step back, review the viewpoint analysis models, and begin to select and apply the desired integration models. Scenarios and view models typically reveal the integration issues of the project, surfacing the concerns of the business area representatives.

As you begin to identify solutions, you will update the models and return them to interview subjects for their feedback and corroboration. This process is an iterative cycle that terminates when the new models have become clear and project participants understand the responses to their particular concerns.

In our example, the CIO View model revealed that this company was storing duplicate information about the same business subjects, as well as maintaining multiple non-matching sources for that information. They were producing marketing reports from one set of systems and financial reports from another. Little wonder that those reports rarely delivered matching financials to the executives.

Before implementing a new system, the redundant data needed to be consolidated into a shared data repository. The seed template, shown in Figure 3, provides the visual pattern for the strategy of building a shared data repository.

Figure 3 (click on picture to enlarge)

The outcome of one or more iterations of analyzing and improving viewpoint models is formulated into a set of recommendations for the overall solution. The recommendations should include action items at two levels: near-term deliverables and long-term plans.

An effort to identify areas of opportunity where relatively simple, minor, or low-cost improvements can be made in such a way that significant integration benefits are accrued is needed. These opportunities are considered "low-hanging fruit" because they are most within reach and available to be harvested early on in the Enterprise Resource Planning project.

The purpose of introducing a tactical element at this time in the project is twofold:

• Early returns in cost and time savings
  
• Visible successes from the project early on to build credibility and support throughout the organization

The recommendations presented should provide both interim solutions and long-term or strategic solutions.

The relevant portion of the CIO View model is redesigned, based on the seed template, to consolidate sales, order, and customer information into one shared data repository that can be supported by the packaged ERP solution. The model in Figure 4 shows the solution applying the data sharing strategy.

Figure 4 (click on picture to enlarge)

Deliverables presented should draw on the pool of scenarios, view models, and integration models developed. They are organized to present the recommended solutions in the context of their business setting.

View models and integration model solutions are presented to the project champion and business area contributors. They provide the requirement basis for configuring the ERP package. The integrator will collaborate with specialists knowledgeable in the installation requirements of the package selected.

Integration model solutions provide the basis for subsequent technical models. A subset of the solutions models and subsequent technical models are presented to the technical teams who will carry out the actual implementation of the packaged solution. View models can be presented if the team needs orientation to specific current implementations.

On implementing an ERP packaged system, the implementation model is provided by the vendor, so what is most needed from the standpoint of the company installing the package are the requirements for configuring and integrating the package system. When integration models were applied to the companies represented by this case study, they provided the glue between the business area representative's views and the technical team. The resulting solution models were used to orient the staff resources that were brought in by the package vendor. They were also used to carve out the implementation project and orient the internal teams who would carry out the project.

(Reprint of an article first published on InformIT's guest expert page.  All rights reserved.)