Integration Modeling Techniques for Enterprise Resource Planning (An ERP Case Study)

Applying Integration Modeling for ERP

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

The process model for an ERP integration project specifies the steps that must be taken to complete the project.

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.

1. Identify Roles and Resources

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

A. Champion

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.

B. Contributors

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.

C. Integrator

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.

2. Build "Best Guess" Models

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.

3. Validate "Best Guess" Models

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.

4. Conduct Interviews with Internal Experts and External Sources

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 CIO Scenario

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

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

The CIO View model depicts what the CIO sees when looking at the technical environment from a top-down perspective.

5. Analyze and Improve Models

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

The seed template provides the visual pattern for an integration solution.

6. Generate Recommendations

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

The CIO View Solution model applies the Seed Integration model for a core component, which collects and contains an array of inputs.

7. Present Deliverables

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.