Applying Integration Models 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 12.1 shows the process methodology followed in the example for ERP integration.
Figure 12.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:
- Identify roles and resources
- Build "best guess" models
- Validate "best guess" models
- Conduct interviews with internal experts and external sources
- Analyze and improve models
- Generate recommendations
- Present deliverables
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.
The champion is the process owner and "chief persuader," the overall coordinator and internal PR agent for the project. He performs the following functions:
- Helps build enthusiasm
- Educates others on the project's benefits
- Generates 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
SalesThis can include the senior executive for the sales area, but it would also include sales people from the field and branch or regional managers.
MarketingIn 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 ManagementThis includes CIO, 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 EngineeringNew product development, research and development, managers, and technical specialists are included.
Business PlanningStrategic planners, senior marketing executives, investor relations experts, and sometimes legal counsel can be included, depending on the goals of the project.
Service DeliveryLine 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.
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. 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 "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. (See Chapter 13, "Using Integration Models to Synthesize Industry Models," for a discussion of industry research and integration modeling.) Test your models against a brief review of industry norms.
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.
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.
The following section on integration issues shows how integration models are applied to resolve integration issues in an ERP example.
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.
Try 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. 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.
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 models 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.