- Background
- Applying Integration Models for ERP
- Integration Issues
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
IntegrationIssues
To integrate applications across an enterprise, as ERP requires, you must understand their origins in the business objectives that define the system requirements. We're not looking for those origins to provide a history lesson, but more of a prime directive. The question is first how to get the prime directive and then how to get it into a context that's meaningful.
Knowledge Gaps
When systems and business functions are managed in isolation, with a manager focused on his or her turf alone, you end up with everyone responsible for a piece and no one responsible for the whole. Furthermore, you create a situation where no one knows what occurs outside his or her own rigidly defined domain. Managers learn to manage upward and downward, but not across the organization.
The result is a gap in just the kind of information that an ERP project requires: knowledge about the relationships between systems and the business objectives of applications, and knowledge about the future requirements for them to cooperate.
Scenarios and Viewpoint Analysis
To bridge the knowledge gap, you introduce scenarios and viewpoint analysis models. These 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 resulting collection of models delineates the differences between the relative positions of many project stakeholders. Some of the variations identified are minor, whereas others seem irreconcilable. However, you now have the advantage of knowing about them, and knowing them from inside the viewpoint, as they appear to the owners of the system.
On completing this analysis, you are armed with information that no one else in the company has, and that many could use.
On some of the projects from which this example was composed, the scenarios were strictly verbal. They consisted of verbal exchanges of stories, which told us why our interview subjects held the views they did. For the purposes of this example, some of the most significant scenarios have been formalized and written down. In addition, the related view models for those selected are presented below. The selected list includes
- CIO scenario
- CIO view model
- Sales scenario
- Sales view model
- Marketing scenario
- Marketing view model
- Other view models (listed to give an idea of the scope)
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 the main charter is to bring those systems into the new Millennium by installing ERP 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 12.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 but stops short of employing technical names. Depending on our goals, we could add much more detail on the systems (application names, technical platform, network and facilities types, primary data flows, processing timing windows) without changing the broad view perspective of the model. It would still stand for what the CIO sees when he looks at the technical environment from a top-down perspective. The information could still be taken in at a glance.
){kind=link}
Figure 12.2 The CIO View model depicts what the CIO sees when looking at the technical environment from a top-down perspective.
The Sales Scenario
Mac's scenario from Chapter 1, "The Context for Enterprise Application Integration (EAI)," is repeated below for the sake of convenience:
Mac, from Sales, has finally gotten his client Bill Smith to agree to a face-to-face meeting, to discuss follow-on business. He's excited because Bill's company is a big client and a lot is riding on this sale, so he's not leaving anything to chance this morning. He's wearing a $500 suit, he's got all the collateral sales materials the client could possibly want to see, he's even got his laptop with a fancy new calculator program that allows him to generate a price quote on the spot.
But as soon as he sits down across the desk from Bill, he suspects something is wrong. Bill's not smiling as big as usual and he seems to be keeping his distance this morning. Mac's antennae are shouting, "Something's wrong!" but he doesn't have a clue what it might be.
"So, Mac, your company services a lot of accounts for us all over the country, right?"
"That's right, Bill; in fact, that's one of the reasons we're a good fit for you locally. We know your company, how you like to do things; it won't take much to ramp up operations here based on what we're already doing for your company."
"So what can you tell me about the problems in Denver last night? I understand Tom's still waiting on his morning reports..."
At this point, Mac knows he's dead in the water. It's happened before, and even though he went through the roof last time, it's happening again. Nobody called to brief him, and now instead of making the sale, he's got to pacify an angry client even though he had nothing to do with the problem.
The Sales View Model
The sales view model clearly acknowledges the importance of the customer to the sales representative by placing the customer in a central position at the top of the chart. Field offices support sales activities by sending collateral materials and special offers, and by providing service to customers. The sales representative obtains sales collateral from the field office and pricing information from centrally managed computer systems. Field offices report performance results (and problems) to headquarters using central computer systems. But when that information flows only one way, sales associates struggle with the type of knowledge deficit you read about in Mac's scenario.
As you can see, the data Mac needs (performance and problem information being sent from field offices to the central computer systems) appears on the model shown in Figure 12.3, stored in databases loaded by the central computer systems, but without connections tying it back to the sales representative. In the end, changes to this model, distributing "trouble reports" across districts, provided an early warning system to the sales force, heading off the kind of blindsiding that Mac had encountered from a client.
){kind=link}
Figure 12.3 The Sales View model depicts what's important to the sales representative.
The Marketing Scenario
The VP from accounting is presenting charts and graphs on product performance and recommended price changes for next quarter. Along with marketing, they're in the quarterly meeting with the president of the division, and their teams have put in weeks of hard work, pulling together the numbers to present. Watching the accounting numbers unfold, the marketing representative knows his figures are checked and rechecked, formatted and graphed to perfection, so even a busy executive could follow along.
As accounting is summarizing the situation, she pulls out her last chart, and marketing slowly starts to shake his head. "What's going on?" he wonders to himself. "Those numbers can't be right. Somebody's way off. But this is finance, and she ought to know." And the VP from marketing suddenly knows that it's going to be a long weekend, searching back through weeks of work, trying to find the point where this train jumped the track.
The Marketing View Model
The marketing view (see Figure 12.4) captures the importance of data sharing and reporting for the analysis and presentation of across-the-board information. Requirements for the ERP implementation include the incorporation of data from internal systems, reports, and extracts, as well as from external sources.
){kind=link}
Figure 12.4 The Marketing View model captures the importance of data sharing and reporting to the marketing department.
Other View Models
For the sake of brevity, a few key view models have been included in this example. Some other view models that were developed on typical projects included
- Current Systems View—Internal Reporting
- Current Systems View—Billing and Payments
- Provider's View—Reporting for Clients
- Financial View—Billing
- Financial View—Payments
- Sales View—New Business
- Field Office View
Scenarios, some as brief as a descriptive paragraph, accompany each view model.
Specific Integration Issues
Modeling the previous viewpoints defined a clear set of business objectives for the implementation of the ERP software. Based on the models, seven specific integration issues were identified and resolved with the help of integration models:
- Redundant data and multiple non-matching data sources
- Significant data-sharing shortfall
- Poor integration of external data sources
- Lack of connectivity
- Lack of internal cost-allocation mechanisms
- Limited management reporting
- Limited client reporting
Redundant Data and Multiple Non-Matching Data Sources
The CIO view model (refer to Figure 12.2) 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 provides the visual pattern for the strategy of building a shared data repository.
The relevant portion of the CIO view model is redesigned, based on the template, to consolidate sales, order, and customer information into one shared data repository, which can be supported by the packaged ERP solution. The model in Figure 12.5 shows the solution applying the data-sharing strategy.
){kind=link}
Figure 12.5 CIO View—The Solution model applies the Seed integration model for a core component, which collects and contains an array of inputs.
The newly consolidated database becomes the sending application source for a data warehouse implementation, which is distributed using a local area network for marketing and financial reporting use.
Significant Data-Sharing Shortfall
The view models show sales teams in one location operating from customer information that is unique to that branch and not shared with other branches, even though the customers often visit and do business with many branches. Service delivery processes are also unique depending on location, and therefore cannot share information either. These concerns and the lack of integration behind them must be addressed in the requirements for the rollout of the new packaged systems.
It is important to understand how applications exchange information, and the shortfall of those methods. Many business areas routinely manage failed system interfaces by printing a report from system A, walking it over to system B's input screen and keying in the information. Analysis of the application interfaces should always include all the interfaces, automated or manual. It also should include both the designed interfaces and those that evolve as workarounds.
To resolve the issues that are revealed in both the previous sales and CIO view models, a new model emerges, as shown in Figure 12.6. In the new model, redundant data are consolidated, and multiple data sources are reconciled. Management reporting of both financial and marketing information is centralized into a data warehouse along with "trouble reports" for companywide distribution. Sales and service delivery processes are re-engineered so that information can be shared and customers can appear once in the database with all relevant information available across branches.
){kind=link}
Figure 12.6 CIO View—A New model resolves the issues that were revealed in both Sales and CIO View models.
On closer inspection, models for the financial view also indicate problems in data definitions and subsequent problems sharing data in the process that extends from pricing to customer payment collection. In fact, pricing activities belong to one business area, negotiation of contract agreements belong to another, and service delivery belongs to yet another business area, and so on through accounts receivable, billing, and collections. The definitions of data differ from one area to the next, and this ERP project offers the first opportunity, in many cases, for these areas to work together on common definitions.
To define the requirements for data integration in the shared databases, the Flow template (see Figure 12.7) is utilized.
){kind=link}
Figure 12.7 Process and flow analysis utilizes the Flow template to trace the course of information, goods, services, and communications.
The Flow template helps the team depict the steps involved and begin reconciling data definitions. Separating the steps through workflow analysis enables the team to identify variances in data definitions and helps them understand the use and required content of related repositories.
As guidelines providing data flow for the shared database strategy, the resulting new view model (shown in Figure 12.8) provides the solution. Other models and specifications are developed to detail the data entities and relationships encompassed by the Flow template.
){kind=link}
Figure 12.8 The Financial View model depicts the steps and data involved in the process that extends from pricing to payment.
Based on the Financial view model, the team understands that it must determine an overall definition of product for the company, and the support of marketing executives is enlisted for this effort. What makes up a product is defined according to key parameters in the following areas:
- Market
- Customer type
- Delivery mechanism
- Investment cost/return
- Business unit
- Type of account
- Line of business
- Geography
- Performance measurements
- Pricing guidelines
- Competition
The team learned that the pricing categories must lead to the terms of contractual agreements, reflecting their structure. Contracts should reconcile with the invoice categories in use, and all of these must add up to the payment categories. Pricing categories incorporating direct and indirect costs are established and defined. The terms of contractual agreements are defined and categorized. Billing requirements are established, with the invoice to include "the minimum amount of information that the client needs in order to pay." Finally the cost equation for pricing is analyzed and the rules for allocating cost back to customers or to other accounting units is clarified and documented.
Lack of Integration of External Data Sources
The Marketing view model in Figure 12.4 indicates the importance of integrating external data sources into the systems solution. However, many of these sources are amorphous and not well understood. The Cell template helps marketing analyze the subject areas for inclusion, capturing the significant definitions and data sources. The model in Figure 12.9 shows the initial set of subject areas as determined by the business strategies for market positioning.
){kind=link}
Figure 12.9 The Business Strategies for Market Positioning model depicts the initial set of subject areas defined by the marketing area.
Cell models enable you to analyze and define data interfaces, initiating the requirements for the shared-data architecture. Subsequent models focus on the data required for each cell compartment, as shown in Figure 12.10, which shows one example of the models developed to depict the next level down from broad subject area definitions to detailed data models.
){kind=link}
It is then an easy transition from the previous model to producing use case models for the technical requirement level. Figure 12.11 shows the resulting use case model from which the technical requirements can then be driven down into class diagrams, component diagrams, and so forth.
){kind=link}
Lack of Connectivity
One requirement that had to be supported by the ERP implementation was to improve on the company's distribution of information by providing new mechanisms of connectivity.
The Ring template (see Figure 12.12) provides the pattern element for distribution. The Ring template models peer-to-peer relationships in non-directional organization. It is applied here as a mode of connectivity.
){kind=link}
Figure 12.10 Next-level models focus on usage requirements.
Figure 12.11 The Use Case Tree model depicts the activities involved in competitive analysis.
Figure 12.12 The Ring template is useful for depicting the chaining of events, people, devices, or network addresses. It models peer-to-peer relationships.
With companies employing growth strategies that are powered by merger and acquisition, issues of connectivity are common. One of the less obvious problems is that different acquired companies configure their branch and field offices in different ways. They combine support offices with regional branches, and have different means of tying all the information back to headquarters.
The Ring template is applied to produce a consolidated connectivity map for all the different configurations that exist in branches in the field, as shown in Figure 12.13.
){kind=link}
The Office Connectivity Map shows the variety of available models for networking branches together and how they are connected to both field support and headquarters.
In this diagram, the outer ring represents connections to support back-office functions such as payroll, billing, and collection. The inner ring represents enabling decisionsupport functions, including statistical reporting that goes from branches or support offices to the corporate offices and the compiled summary information that goes back to the branch, such as branch performance, profit and loss, and weekly and monthly job order statistics.
Corporate Office (#1 on the diagram) represents corporate headquarters where back-office functions take place, including payroll, billing, collection, legal, marketing and sales, and recruiting support, technology support, training and human resources, and so forth.
Branch Support Office (configuration #2 on the diagram) shows how main branches operate, with an area manager and support personnel performing administrative support and marketing and sales support in the Branch Support Office, while relying on Corporate Office to provide other back-office functions. In some instances, branch offices report hierarchically to a regional branch support office, which reports to corporate, and in others, a branch can report to another branch, which then reports to a region reporting to corporate.
Figure 12.13 The Network View model of Office Connectivity Map shows the different configurations that exist in branches in the field.
Self-Supporting Branch depicts branches where one branch operates as if it were an independent entity, providing all its own front and back office support functions, and relating to corporate only through performance and decision-support reporting.
Branch (#4 on the diagram) depicts a possible target model for the future, where the branch is supported in both front and back-office functions by the corporate office through automation, creating a "virtual office" environment.
Branch Support Office (#5 on the diagram) represents offices where the original corporate headquarters of the acquired company is still providing front and back-office support.
Branch Support Office (#6 on the diagram) shows how branches operate with the original headquarters providing administrative and sales and recruiting support, and back-office functions such as payroll and billing coming out of the corporate office. This example also shows satellite offices, which are employed to extend the reach of a branch and provide a local presence in a more distant market.
Lack of Internal Cost-Allocation Mechanisms
Initial interviews surfaced accounting problems with the allocation of overhead costs, where managed accounts carried an unfair proportion of the burden for infrastructure cost and retail accounts were unintentionally subsidized. The Tree template (see Figure 12.14) was used to explore the distribution alternatives for correcting the internal allocation of costs.
){kind=link}
Figure 12.14 The Tree template is used to explore the distribution alternatives.
After the cost of support services is allocated properly over the four market divisions of the example company, the divisions can, in turn, allocate expenses to the field offices (see the Cost Allocation View in Figure 12.15). Feedback mechanisms are also designed for managing projections and year-end overages.
){kind=link}
Limited Management Reporting
Another problem that rises to the surface in enterprise-wide efforts is that of comparing statistics from incompatible systems. Within the confines of one system, the numbers can make sense to the recipients of system reports. But as the marketing scenario demonstrated, fragmented information sources can lead to mismatches in management reporting.
Figure 12.15 The Cost Allocation View model depicts the strategy for absorption of overhead cost.
The goal of the corporate information repository is to store data once, updating it only under controlled conditions. The model in Figure 12.16 shows the solution, housing financial and customer information in a data warehouse for reconciled management reporting to all levels.
){kind=link}
Figure 12.16 The Management Reporting View—The Solution model depicts the use of a shared repository to reconcile management reporting.
Limited Client Reporting
Client reporting trends in employment services created a demand for extensive reporting of service statistics such as turnover, absenteeism, number of calls, average response speed, skills supplied, staff usage, and reasons for staffing levels. It was important to consolidate these service statistics into shared databases as well, as depicted in Figure 12.17, for distribution to identified types of clients.
){kind=link}
Figure 12.17 The Client Reporting View model depicts the shared repository solution for data sharing.
Subsequent use-case models and technical specifications defined the programs and reports required and their distribution plan. The increased integration of the client reporting view enabled major customers of the employment services firm to identify the most successful locations and their practices, the least successful locations and their practices, and to transfer best practices accordingly. Weekly and monthly tracking of key indicators was automated and supported by performance incentives.