Laura Brown – principal consultant
1112 Riverbend Club Drive - Atlanta, GA 30339
PHONE: 770-953-0534 FAX: 770-952-7863
Integration Modeling Techniques for Enterprise Resource Planning
(a composite case study of how companies in the employment
services sector applied integration modeling techniques to their ERP
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.
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
(click on picture to enlarge)
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
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.
The champion is the process owner and "chief persuader," the
overall coordinator and internal PR agent for the project. He performs the
- 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
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
- 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
- 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
- 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
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
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.
(click on picture to enlarge)
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.
(click on picture to enlarge)
The seed template provides the visual pattern for an integration
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
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
(click on picture to enlarge)
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.
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.)