T E R R Y  M 0 R I A R T Y    AND V E R N O N   T H O M P S O N

Two IRM strategies for securing quality data

Business Analysis Techniques

August, 1996

Last months column discussed the importance of business information advisory committees (BIACs) in combating data quality barriers within the business community. The personality traits that qualify people to serve on their organization's BIAC place them in high demand to support any strategic project, not just those dealing with information resource management (IRM). As much as we'd like our BIAC members to be fully dedicated to ensuring corporate data quality, their time is at a premium. We must be able to facilitate information management processes to optimize each member's involvement.

Our most valuable tool for managing the information resource is an enterprisewide business model that addresses business process and organizational concerns as well as data structure. Data modelers are quite comfortable relying on data models to represent the enterprise's information resource from a structural perspective. Although such models can represent every subject area of strategic importance to the organization, they do so only from a structural perspective. Data models focus on relationships among the major entities an organization must have knowledge of. However, we also need ways to analyze the full scope of an enterprise's IRM responsibilities from business process and organizational perspectives. Two valuable techniques for supporting analysis of these perspectives are source/use analysis and responsibility, authority, expertise, and work (RAEW) analysis.

SOURCE/USE ANALYSIS

Source/use analysis assesses interaction among the organization's major business processes with a focus on information flow. Each business process can assume the role of either source or user of the corporate data resource.

In its role as source, the business process creates and maintains data and ensures its quality and integrity. As user, the business process that uses data to produce its outputs levies requirements on the source business process regarding the quality it requires.

The standard data flow diagram (DFD) is highly effective in representing the results of source/use analysis. Of the various DFD standards available, IDEFO is best suited for communicating the source/use analysis because it does not use the "data store" construct that exists in the Yourdon or Sarson and Gane DFD. The data store construct is a holding area in which source business processes can store their data until user processes need access to it. The purpose of data stores is to isolate business processes from one another. Each process thus behaves like a black box, pulling the data it needs from its data store, manipulating it, and then returning it to the appropriate data store.

This analysis approach, while valid at the design stage, may actually be the source of some data quality problems in our existing applications portfolios. When business process boundaries are defined, some users of data involved in that process may be overlooked. Such oversights quite often occur when we cross the line between operational and decision-support business processes. We may forget to take data quality requirements of decision- support business processes into consideration when gathering operational systems requirements. To ensure data quality in source/use analysis, all information flows must be explicitly depicted to highlight the dependencies among business processes. The IDEFO notation (see Figure 1) can also depict business processes and data relationships of "control" and "mechanism" that the structured analysis and design DFD doesn't support. While the mechanism construct is not relevant to the source/use analysis, the control construct represents the business rules that constrain business process behavior. One business process's output can control other business processes. For example, the Policies and Business Rules output from the Business Policy Formulation process depicted in Figure 2 controls the Product Tailoring by Market process by placing constraints on how individual products can be tailored to meet market needs. While business process inputs and outputs are relatively stable, controls can be expected to change as the business assesses the effectiveness of its business rules. Controls may require additional analysis to ensure that reengineered processes are flexible enough to support the changes that can occur in a dynamic business environment.

Source/use analysis asks the following questions of each business process: What information do I create? What information do I use to complete the process and create the information? The source/use diagram and matrix document the answers. While we can include the entire information flow across the enterprise's business processes in a single diagram, it's much more valuable to focus on each individual business process (see Figure 2). We can use source/use analysis to determine which BIAC members must be involved in changes that impact the data. Normally, BIAC members represent the organization's business process owners. Therefore, only those members whose business processes use the data must participate in the discussions. Nonetheless, the BIAC must always consider the ripple effect of data changes. Introducing additional data to the Market Segment Needs information flow may cause corresponding changes to the Market Segment Product Offering information flow. When this effect is recognized, we must call on BIAC members associated with the downstream processes (such as Call/Sales Program, Customer Establishment, and Account Opening) to participate in the analysis.

RAEW ANALYSIS

Responsibility, authority, expertise, work (RAEW) analysis is a simple but powerful approach, more traditionally used for diagnosing the ailments associated with an organization's structure/function matrix. Often, the reason why a particular business unit performs a particular function is lost in the annals of time It may have been due to the geographical proximity of one business unit to another prior to the luxuries of today's telecommunication speeds and distributed DBMSs. Or a function may have been assigned to an individual and followed his or her progression through the ranks. Whatever the reasons were then, companies today are increasingly looking to reengineer their processes for efficiency gains tomorrow. RAEW is a useful tool to pack in the business process reengineering (BPR) kit bag.

A word of warning, however: RAEW analysis can be hazardous to the health of the presenter (usually a consultant). Senior management may be so embarrassed by such a clear representation of a malfunctioning enterprise for which it is responsible, that it takes the easy way out and kills the messenger, along with RAEW.

The origin of RAEW is a mystery to us. Although we've encountered the approach at several different companies, we haven't been able to determine who actually created this marvelous technique. (We'd be more than happy to give credit to its creator(s) if they step forward.)

One of the benefits of this tool is that it can be used at either the enterprise or application level. However, to ensure proper distribution of management responsibility for data shared across the organization, it's best to begin with an enterprisewide analysis.

The first prerequisite for any RAEW analysis is a functional decomposition, or a process model, as provided by a complete source/use model. The activities from the functional decomposition form the axis for the matrix rows. Matrix columns are mapped to the organization's structure. Depending on the level of analysis, organizational units may represent company divisions, departments, or even individuals. Each matrix cell therefore represents a function that may or may not be performed by a specific organizational unit. Each organizational unit's role is analyzed for each function and assigned one of the following codes:

* R = Is responsible for the function/ activity

* A = Has authority for the function/ activity

* E = Has expertise in the function/ activity

* W = Performs the work of the function/activity.

A given organizational unit may assume multiple roles for a given function. A blank cell indicates that a unit has no involvement with the corresponding function

Let's consider what RAEW matrix in Table 1 reveals about a mythical financial institution, the GonRong Bank Inc.

Some of the problems we find on analyzing the matrix from the business function perspective follow:

* Although more than one division is responsible for performing the Business Policy Formulation function, no division has the authority to do so.

* No division is working on the Product Design function, yet several have the necessary expertise.

* No division performs the work for the Market Segment Analysis function.

* Several divisions perform the work associated with the Product Tailoring by Market function. Three of these divisions have the authority, none has the responsibility, and only one has the expertise to perform the work.

From an organization structure perspective, we can identify the following problems:

* The marketing division doesn't perform work against any function.

* The strategic planning division performs work for the Product Tailoring by Market function but lacks the necessary expertise.

* The sales division is responsible for four functions, has the requisite expertise, and performs all the work for two of them, yet lacks authority for them all.

Having described how this method works, let's examine how it can improve data quality and reduce data disparity within an organization. Rather than using RAEW as a diagnostic device, let's use it as a strategic planning tool that can help us identify which processes cause poor data. We can then eliminate-or at least reduce such processes. Using this tool, we can create a road map for how authority, responsibility, expertise, and work should be distributed. We can then incorporate this road map into the solution for managing the quality of data shared across the organization.

The processes necessary to eradicate the causes of disparate data include:

* Definition and maintenance of the currency, timeliness, completeness, accuracy, response time, retention period, and security rules associated with the data

* Verification that rules are defined and adhered to for the correct use of attributes within existing applications

* Identification of crucial but missing data (such as data that one business unit requests but another fails to collect)

* Verification that the correct data is being collected at the source

* Identification and eradication of duplicate data for the same real-world object.

Responsibility for defining data requirements and collecting data from a source clearly lies with the user(s). We must therefore include users in one of the matrix columns. We also know that different user communities will view the data world differently. To avoid disparity and retain the full value of data, the corporation will need the BIAC-which represents the collective will of users-to resolve some of these issues. This committee should also appear on the matrix. It should have certain authority and responsibilities and must therefore have some control over a budget for ensuring optimal data sharing. After all, integration costs money.

The BIAC must perform those tasks specific to the resolution of these issues, which so often fall into the cracks between divisions in traditional organizations. If the BIAC members do not have the right expertise, the committee will fail. Therefore, the RAEW analysis should be applied to ensure that the business has organized itself to manage the information resource properly. You can use the RAEW matrix in Table 2 as a starting point for customizing a matrix that reflects how your enterprise should allocate responsibilities for its information resource.

We should perform enterprisewide business analysis from two stand points how the organization wants to conduct business ("to-be" environment) and how the organization is actually conducting business ("as-is"). While we may develop different models (data model, source/use model, and RAEW matrix) to represent each perspective, they should all use the same terminology and represent the same level of detail so that they show comparable versions of the organization's state. (Develop your to-be models first so that you describe the current environment in the context of the environment your organization wants to establish.) Both perspectives should identify the following types of anomalies in the organization's current information resource:

* Information the business needs but cannot retrieve in a useful or timely form

* Situations in which information does not flow correctly among the business processes

* Business units that are not properly organized to ensure that the data they capture meets the enterprise's data quality standards.

Once the enterprise has identified where the current information resource quality diverges from what the enterprise needs to conduct business effectively, it is ready to reengineer its business processes and supporting applications portfolio to ensure high-quality data across the enterprise.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. Her common business models have been used as the basis of customer models for companies within the financial services, telecommunication, software/hardware technology manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com.

Vernon Thompson is a senior consultant at Spectrum Technology Group, specializing in data architecture and data management.  He can be reached at 102617.3556@compuserve.com.