BUSINESS RE-ENGINEERING:
THREE STEPS TO SUCCESS

Printable PDF Version

By Clive Finkelstein, Managing Director
Copyright © 1993-1996 Information Engineering Services Pty Ltd.

Contents

Clive Finkelstein - "Business Re-Engineering: Three Steps to Success"

• Synopsis
• Introduction
• Business Re-Engineering from Business Plans
• Business Re-Engineering from Business Processes
• Business Re-Engineering from Business Information
• Identifying Cross-Functional Business Processes
• Conclusion
• References
• More Information
  
• Note: An updated version of this paper, titled: "Business Re-Engineering and the Internet: Transforming Business for a Connected World" is also available to be read online from your browser, or it can be downloaded as a Word 6.0 document.

Synopsis

Organizations are rushing into Business Processes Re-engineering (BPR) to improve organizational effectiveness and efficiency, and achieve competitive advantage. But to improve processes without first knowing which business plans are addressed by the processes, and what information is needed to support those plans, may prove to be an exercise in futility. Processes are only one aspect of the business: business plans and business information are the other two essential components. Understanding the data and information resources of a business is essential. If copies of the same data exist redundantly in the organization, many business processes are needed to keep redundant data versions up-to-date and synchronized.

In contrast, Business Re-Engineering (BRE) addresses all three areas: business plans, business processes and business information. These three areas must all fully support each other if success in re-engineering is to be realised. If redundant data versions are integrated so that each authorized area of the business can share the same data, new business processes emerge. These re-engineered processes are able to cross previous functional boundaries, bringing not only improvements in business efficiency and effectiveness but in many cases also competitive advantage. This paper shows how this can be achieved through Business-Driven Information Engineering.

Back to Contents.

Introduction

Organizations are today faced with unprecedented competition on a global basis. To compete effectively, they must change: those that fail to see the need for change will not survive. This change, in most cases, involves re-engineering the business. In fact, the top two issues for managers in 1993 were found to be re-engineering the business through IT, and aligning IS and corporate goals [1]. By setting a focus on business re-engineering, and on development of information systems that directly support strategic business plans, managers can take control and turn today's chaotic environment to their competitive advantage.

To compete, organizations are downsizing. According to Drucker: "We are entering a period of change: a shift from command and control organizations to information-based organizations of knowledge specialists. The typical large business 20 years hence will have fewer than half the levels of management of its counterpart today, and no more than one third the managers" [2].

While computer power has increased 350 times in the twenty years from 1972 - 1992, the cost of that power has fallen by a factor of 60. But over this period the productivity of systems development has hardly moved [3]. The challenges of systems development are now greater than ever before. Legacy systems (computer systems introduced 10 or 20 years ago) are complex, and difficult to change. The development of new systems is also slow, and error-prone. These two factors have now become the major inhibitors to organizational change. Consider the following ...

Today, in many organizations, the average development backlog (before computer applications are built and can be used) is now 3 years, while the average development time is 2 years, the average delivery behind schedule is 1 year, and the average budget overspend is double! And the proportion of the data processing budget that is spent on maintenance (correcting or changing existing application systems) is 60% - but 60% of that is expended in the first six months: fixing errors in applications that should initially have been delivered correct. And the proportion of completed application systems that are delivered, but never used (because they failed to address the businesses' true needs) is 47% [4]! This is indeed a sorry indictment of systems development technology, but the problems are not unique to the Information Technology industry.

To succeed in today's environment an organization must focus first on customers and markets, rather than on products and production. But customers today are often unable, or unwilling, to specify the characteristics or features of a product or service until they are ready to take delivery. To compete in this market environment, flexibility is key: the time to market has to go to virtual zero [5]. This suggests a strategy of Assemble-to-Order: of products, custom-built from standard components, and uniquely tailored to each customer's specific needs.

An assemble-to-order strategy applies not only to manufacturing and assembly, but to most service industries as well: such as through custom-tailored banking or insurance products, or government services. It also applies to systems development. Fortunately the solutions are known. They involve the integration of business and IT: integration on the business side of strategic business planning and business re-engineering; and on the IT side of client-server systems and object-oriented development.

Consider a typical business that accepts orders from their Sales Dept, that have been placed by customers. These orders are processed first by the Order Entry Dept, and then by the Credit Dept. Each department needs details of the customer, such as name and address, and account balance, and details of the order. These are saved in customer files and order files, held and maintained by each department as shown in Figure 1.

In satisfying these orders, items used from inventory must eventually be replaced. These are ordered by the Purchasing Dept from suppliers, and are then later paid by the Accounts Payable section of the Accounts Dept. Details of name and address, and the account balance due to the supplier, are also saved in supplier files and creditor files. These are held redundantly and are maintained separately by each department as also shown in Figure 1.

To ensure these redundant data versions are kept current and up-to-date and all versions consistently refer to the same information, any change to one data version must be immediately made to all other affected versions. For example, a customer notifies Sales of a change of address. That address change must be made not only in the Sales Dept customer file, but also in the customer file maintained by the Order Entry Dept. The same customer details are held and maintained redundantly by the Credit Dept in their client file, and by the Invoicing Section of the Accounts Dept in their debtor file.

And if the customer also does business with the organization as a supplier, that change of address must also be made to the supplier file maintained by Purchasing and to the creditor file maintained by Accounts Payable in Accounts. The address change must be made to every redundant data version, so that all information about the customer is correct and is consistent across the organization.

Figure 1: The same data often exists redundantly in an organization. Each redundant data version must be maintained current, and up-to-date. This invariably leads to the evolution of redundant processes.

This is not a computer problem: it is an organization problem! But its resolution over the years has defined the manual procedures and the organization structures adopted by countless organizations. In our earlier example, procedures are defined to capture the details of customers and make changes to those details when needed later, as in the change of customer address. Many of these procedures are also redundant, but are necessary to maintain the data versions all up-to-date. Redundant data thus leads to redundant processes.

And of course, people have to be allocated to carry out these redundant processes in each department. This staffing is unproductive and adds nothing to the bottom line: in fact, it reduces profitability. It introduces unnecessary delays in serving the customer, so reducing customer service - leading often to competitive disadvantage.

In the 1980s office automation was introduced to solve the problem. But this focused on the symptom: the time that the Address Change Form took to reach each affected department. It did not address the true problem, the redundant data - it only sped up the paper! To resolve the problem common data (name and address in our example) when identified should be stored once only, so all areas of the business that are authorized to access it can share the same data version. This is illustrated in Figure 2.

Figure 2: Common data can be shared as one data version, and made available to all authorized to use it. Specific data is then managed by each area that needs it.

While name and address is common to many areas, there is also data needed only by certain areas. An organization may have more than one role in its business dealings with us, shown by Organization Role in Figure 2: one role may be as a customer and another role as a supplier. For example, Order Entry must ensure that the value of the current order, when added to the outstanding debtor balance still to be paid (maintained by Accounting) does not exceed the customer's credit limit (maintained by the Credit Dept). Similarly Accounting must be aware of the creditor balances due to be paid to organizations that we deal with as suppliers. While this data is specific to each of these areas, the name and address of an organization may be common - regardless of its role as a customer, or as a supplier - and is shared by all.

It is in the identification of common data that the greatest impact can be made on the efficiency and responsiveness of organizations to change. Once applied, changes made to common data are immediately available to all areas that need that data to be current. And because common data is stored only once, redundant procedures that maintained redundant data are also no longer needed. Business processes that evolved over many years to ensure all areas had access to needed data (by each department maintaining its own data version) now share common data and are immediately aware of any changes.

The way in which an organization structures itself today, when common data is readily available and can be easily shared is quite different from the way it had to be organized when that data was difficult to obtain. New business processes emerge that often cross previous functional boundaries. This leads to business re-engineering. The strong interest today in business process re-engineering addresses only a subset of the broader subject of business re-engineering.

Organizations which approach business process re-engineering without recognizing and correcting the redundancy problems of organizational evolution discussed above, are inviting trouble. For example, in examining Baxter Travenol after their takeover of American Hospital Supply Co, Short and Venkatraman [6] comment that: "... although many business process redesign initiatives start out amid great fanfare and bold predictions of state-of-the-art performance improvements, lurking beneath the glare are often quite modest attempts to reduce operational cost in a single functional area, to improve product quality in a single product line, or to downsize the business to reduce the firm's cost structure."

They go on to say: "... the danger is simply that business process redesign may have little or no measurable impact on the firm's external market performance" (their emphasis). "To the extent that many companies still tend to use IT to automate existing processes rather than redesign them, investments in IT have yielded disappointing results."

We are now seeing the emergence of the "New Corporation", defined by Tapscott and Caston [7] as "the fundamental restructuring and transformation of enterprises, which in turn cascades across enterprises to create the extended enterprise and the recasting of relationships between suppliers, customers, affinity groups and competitors." In their book [8] they discuss that organizations today are now moving from the first era of Information Technology, to the second IT era.

They categorize the first era of IT by the traditional system islands built for established organization structures, using computers for the management and control of physical assets and facilities, for the management and support of the human resource, and for financial management and control systems. Computers have automated the existing procedures used by an organization, replicating redundant data and manual procedures with redundant computer files or data bases, and redundant computer processing. But these automated systems are far more resistant to change than the manual systems they replace, as discussed earlier in the Gartner Group survey. Organizations have buried themselves in concrete that has now set hard: computer systems introduced to improve organizational responsiveness now inhibit the very business changes needed to survive!

One of the original roles of middle managers was to implement internal procedures and systems that reflected directions and controls set by senior management. Their other role was to extract specific information, needed by senior management for decision-making, from underlying data at the operational levels of the organization. However the organizations that downsize by only eliminating middle managers are vulnerable. But the elimination of redundant data and redundant processes, as well, leads to dramatic cost reductions - while also ensuring that accurate information is available.

It is true that with accurate, up-to-date information available electronically and instantly, many management layers of the first IT era are no longer needed. But if this accurate information is not available, organizations invite disaster if they do not first implement effective systems to provide that information before removing these managers. Only when the earlier problems of redundant data and redundant processes are resolved can downsizing truly be effective. Then decision-making can be faster, when access to accurate, up-to-date information is available corporate-wide.

Tapscott and Caston next describe the second era of IT as that which supports open, networked enterprises. These new corporations move beyond the constraints of the organizational hierarchy. In this second era, re-engineered processes and systems in the new corporation not only cross previous functional boundaries. They move beyond the organizational hierarchy - with computer systems that can directly link suppliers and customers. For example, insurance companies link directly with agents who sell their products: insurance policies that are uniquely tailored to satisfy their customers' exact insurance needs.

Similarly airlines link with travel agents and convention organizers. The services they provide are not only booked airline flights, but also accommodation, car rental, and business meetings or holidays tailored uniquely to each customer's needs. In addition: banks provide direct online account access for their customers; manufacturers link to terminals in the trucks of their suppliers for just-in-time delivery; and governments provide information kiosks for public access, so that people can obtain the specific information they need. These are all examples of business re-engineering, in the spirit so memorably encapsulated in the title of Michael Hammer's landmark paper, "Reengineering Work: Don't Automate, Obliterate" [9].

The important point to recognize with business re-engineering, and its subset business process re-engineering, is their vital link with the development of computer application systems. But systems development has also seen dramatic change in recent years. New methods and software - called CASE (Computer-Aided Software Engineering) tools and methodologies - are now available that automate most of the manual, error-prone tasks of traditional systems development. These result in rapid development of high quality systems that can be changed easily, and fast, addressing many of the problems discussed earlier.

A detailed understanding of computer technology was a prerequisite of the traditional systems development methods, and it was therefore difficult for business managers to participate effectively. The new generation of CASE tools, such as used with business-driven Information Engineering [10], requires a detailed knowledge of the business. This knowledge is held by business managers and staff, not by computer analysts. When these business experts can use business-driven IE to apply their knowledge in a design partnership with computer experts, redundant data and processes are readily identified.

Using the knowledge of business experts across different areas that share common data, integrated data bases that eliminate redundant data and redundant processes are defined using business-driven IE CASE tools [11]. Automatic analysis of this common data by these CASE tools identifies new business processes that may cross functional boundaries, and where appropriate also cross enterprise boundaries as discussed later. These processes are automatically derived and can suggest common procedures. These can be identified and implemented across an organization, for improved efficiency and effectiveness. Business process re-engineering opportunities thus emerge.

The data bases and systems which are designed are of high business quality, able to be implemented by computer experts using the most appropriate computer technology for the business: decentralized in a client-server environment, or instead centralized. Data bases can be automatically generated for any SQL-dialect RDBMS, such as IBM DB2, ASK Ingres, Sybase, MS SQL Server, Oracle and other RDBMS products. These systems can be built using a wide variety of computer languages or development tools, as object-oriented systems that share common data and common logic. This enables systems to be built rapidly and changed easily. The CASE tools discussed earlier automatically derive object-oriented logic from the integrated data that is identified by the business experts.

The result is a dramatic gain in systems development and maintenance productivity and quality. Systems can now be built rapidly to meet the changing business requirements imposed by the intense competitive environment of today. These systems then become competitive weapons that achieve success: not just by eliminating redundant data and processes, and duplicated staffing, so leading to huge cost savings. They also provide management with accurate, up-to-date, consistent information that was difficult, if not impossible, to obtain with confidence before. In this way, IT achieves its true potential, as corporations move to the second era of Information Technology.

The remainder of this paper illustrates how this can be achieved.

As discussed above, we need to consider not only redundant data versions, but also the redundant processes which have evolved to keep redundant data versions up-to-date. Integrated data models not only eliminate redundant data versions, but also eliminate the redundant processes. Data and processes represent Business Information and Business Processes which both must support the Business Plans defined by management, shown in Figure 3.

Figure 3: Business Re-Engineering improves all three areas essential to business effectiveness: Business Plans, Business Processes and Business Information.

Back to Contents.

1. Business Re-Engineering from Business Plans

Business plans represent the ideal starting point for Business Re-Engineering, as they apply at all management levels. When defined explicitly by senior managers they are called strategic plans; when defined by middle managers they are called business plans. At lower management levels they are defined implicitly as part of the manager's job description. We will use the generic term Business Plan to refer to all of these.

Business plans define the directions set by management for each business area or organization unit. They indicate the mission of the area and its defined policies, critical success factors, goals, objectives, strategies and tactics. They are catalysts for definition of business processes, business events and business information as follows.

Policies are qualitative guidelines that define boundaries of responsibility. In a data model, policies are represented by related groups of data entities [12]. The data entities defined within a business area thus together represent the policies that apply to the management and operation of that area. A policy also establishes boundaries for business processes that are carried out by one business area, and processes that relate to other business areas. An example of a policy is:

• Employment Policy: We only hire qualified employees.

Critical Success Factors (CSFs) - also called Key Performance Indicators (KPIs) or Key Result Areas (KRAs) - define a focus or emphasis that achieves a desired result. They lead to the definition of goals and objectives. Goals and objectives are quantitative targets for achievement. Goals are long-term; objectives are short-term. They indicate WHAT is to be achieved, and have the quantitative characteristics of measure, level and time. The measure is represented by data attribute(s) within entities [13]. The level is the value to be achieved within an indicated time for the goal or objective. These attributes represent management information, and are generally derived from detailed attributes by processes at the operational level. They provide information that managers need for decision-making. An example of a measurable objective is:

• Hiring Objective: To be eligible, an applicant must exceed a score of 70% on our Skills Assessment Test at the first attempt.

There are many alternative strategies that managers may use to obtain the information they need. Strategies may contain more detailed tactics. Strategies and tactics define HOW the information is provided, and HOW it is derived. Together they lead to the definition of business processes. Examples of a strategy and business process are:

• Assessment Strategy: Interview each applicant and match to position criteria, then administer the relevant Skills Assessment Test.
• Evaluation Process:
  1. Review the completed Application Form to ensure all questions have been satisfactorily completed.
  2. Check that required references have been provided.
  3. Select and administer relevant Skills Assessment Test.
  4. Note total time taken to complete all questions.
  5. Mark responses and calculate overall score.

6. Write score and completion time on Application Form.

A strategy is initiated by a Business Event, which in turn invokes a business process. Without a business event, nothing happens: business plans, policies, goals, objectives, strategies and processes are merely passive statements. A business event initiates a business activity or activities - ie. business process(es). A business event example is:

• Interview Event: Schedule an interview date with the applicant.

Documented planning statements of mission, critical success factors, policies, goals, objectives, strategies, tactics and business events are allocated to the business area(s) or organization unit(s) involved in, or responsible for, those statements: in a Statement - Business Area Matrix or Statement - Organization Unit Matrix. This enables the subset of planning statements for each area or unit to be clearly identified.

Strategic plans that define future directions to be taken by an organization represent the most effective starting point for Business Re-Engineering. But in many organizations today the plans are obsolete, incomplete, or worse, non-existent. In these cases, another apex of the triangle in Figure 3 can be used as the starting point for Business Re-Engineering: either business processes, or business information.

Back to Contents.

2. Business Re-Engineering from Business Processes

Existing business processes, reviewed and documented by narrative description and/or DFD's show how each process is carried out today. Business areas or organization units that are involved in, or responsible for, a process are identified and documented in a Process - Business Area Matrix or a Process - Organization Unit Matrix.

A business event is the essential link between a business plan and a business process. In the plan, an event is defined as a narrative statement. It can be a physical transaction that invokes a business process. Or it may represent a change of state. The strategy or tactic that the event initiates is documented in an Event - Strategy Matrix. This link must be clearly shown. The process invoked by each event should also be clearly indicated: documented in an Event - Process Matrix.

Without links to the plan, the business reason(s) why the process exists is not clear. It may be carried out only because "we have always done it that way." If the process cannot be seen to support or implement part of the plan, or provide information needed for decision-making, then it has no reason to remain. As the past fades into history, it too can be discarded as a relic of another time. To re-engineer these processes without first determining whether they are relevant also for the future is an exercise in futility.

But if the process is essential, then the strategies implemented by the process must be clearly defined. Associated goals or objectives must be quantified for those strategies. And relevant policies that define boundaries of responsibility for the process and its planning statements must be clarified. Thus missing components of the business plan are completed, so providing clear management direction for the process.

The third apex of Figure 3 is an alternative starting point for Business Re-Engineering. In fact, business information is a far more powerful catalyst for re-engineering than business processes, as we will soon see.

Back to Contents.

3. Business Re-Engineering from Business Information

Data models developed for business areas or organization units should ideally be based on the directions set by management for the future. These are defined in business plans. Where business plans are not available, or are out-of-date, or the reasons why business processes exist today are lost in the dark recesses of history, data models of business information provide clear insight into future needs.

Data models can be developed from any statement, whether it be a narrative description of a process, or a statement of a policy, goal, objective or strategy. The redundant data versions that have evolved over time (see Figure 1) are represented as data models, consolidated into integrated data models. Data versions from different business areas are integrated so that any common data can be shared by all areas that need access to it. Regardless of whichever area updates the common data, that updated data is then available to all other areas that are authorized to see it.

With this integration, redundant business processes - earlier needed to ensure that each redundant data version is maintained up-to-date - are no longer required. Instead, new processes are needed. As common data is integrated across parts of the business, data that previously flowed to keep the redundant data versions up-to-date no longer flows. With integrated data models, implemented as integrated data bases, data still flows to and from the outside world - but little data flows inside the organization. The original processes that assumed data existed redundantly may no longer work in an integrated environment. New, integrated, cross-functional processes are required. But how can cross-functional processes be identified? Data Flow Diagrams provide little guidance in this situation.

Affinity Analysis provides little help either. This technique is widely used by the DP-driven variant of Information Engineering to group related entities into business areas or subject areas [14]. But it is now recognised as being highly subjective. It depends on the knowledge that the data modeler has of the business; of data modeling; and the thresholds that are set. As a technique, it is not repeatable. It is potentially dangerous, as indicated next.

Where allowance is made for its subjectivity, affinity analysis can be still be useful. But when its results are accepted blindly, without question, the end result can be disaster. It lacks rigor and objectivity. It can lead to the grouping of more data in a subject area than is needed to deliver priority systems. This will require more resources to develop those systems; they will take longer and cost more. This is merely embarrassing, as in: "the IS department has overrun its budget on yet another system."

But the real danger is that essential, related data may not be included in the subject area. This related data may indicate inter-dependent processes that are essential for the correct functioning of the processes represented by the priority systems. The end result? When delivered, the systems may not support all business rules that are essential for correct functioning of the business process. The systems may be useless: developed at great cost, but unable to be used. This situation is not merely embarrassing: it is disastrous! At best, it represents wasted development time and cost. At worst, it can affect an organization's ability to change rapidly, to survive in today's competitive climate.

Related data that indicates existence of inter-dependent processes leads to the definition of cross-functional processes. These may suggest re-engineered business processes.

Identifying Cross-Functional Business Processes

Cross-functional processes can be identified from an analysis of the data model, based on the concepts of data dependency. This is an objective technique, described in detail in my recent book [15]. Its significance was acknowledged in a recent article in Database Newsletter [16]. Data dependency is rigorous and repeatable: it can be applied manually, or can be fully automated. When used to analyse a specific data model, the same result will always be obtained - regardless of whether the analysis is done by man or machine.

Data dependency automatically identifies all of the data entities that a specific process is dependent upon, for referential integrity or data integrity reasons. It will automatically identify inter-dependent processes, and indicate cross-functional processes. It uncovers and provides insight into business re-engineering opportunities.

Consider the following example, based on the analysis of a data model developed for XYZ Corporation: involved in Sales and Distribution from inventory. Figure 4 shows an integrated data model that consolidates the previously separate functions of Order Entry, Purchasing, Accounts Receivable and Accounts Payable.

Key to Association Symbols and Meaning

Figure 4: Sales and Distribution data map showing the integration of Order Entry, Purchasing, Accounts Receivable and Accounts Payable functions.

Each ORGANIZATION that XYZ deals with may have different roles, as a CUSTOMER or a SUPPLIER [both shown as secondary (sub-type) entities of ORGANIZATION ROLE]. An ORDER placed for a specific role thus will be either a CUSTOMER ORDER (taken by Order Entry from customers), or a PURCHASE ORDER (placed by Purchasing with suppliers). Each ORDER contains one or many PRODUCT(s); a PRODUCT is requested in one or many ORDER(s). The intersecting (associative) entity ORDER PRODUCT has been formed by decomposing the many to many association. This represents both the Order Processing function and also the Purchasing function. This introduces an important principle of the business-driven variant of Information Engineering used in this paper:

Intersecting entities in a data model represent functions, processes and/or systems.

This principle can lead to the identification of cross-functional processes that arise from integration of the Order Entry and Purchasing functions as we shall shortly see.

Referring again to Figure 4, each ORDER PRODUCT may be a SHIPPED PRODUCT or a BACKORDER PRODUCT (for customer orders), or may be a CONFIRMED PRODUCT (for supplier purchase orders), for the PRODUCT associated with ORDER PRODUCT.

We also see that a PRODUCT has one or many SUPPLIER(s), but at least one (shown by mandatory many at SUPPLIER PRODUCT), and that a SUPPLIER provides one or many PRODUCT(s). The intersecting entity SUPPLIER PRODUCT clearly represents the Product Supply process of the Purchasing function.

Similarly, an ORGANIZATION ROLE has many INVOICE(s) for PRODUCT(s), which may either be CUSTOMER INVOICE(s) or SUPPLIER INVOICE(s). The intersecting entity INVOICE PRODUCT thus represents the Accounts Receivable and Accounts Payable functions. It may comprise a SHIPPED INV PRODUCT or BACKORDER INV PRODUCT (for customer invoices) or an ON-TIME INV PRODUCT or LATE INV PRODUCT (for supplier invoices). This can lead to the identification of cross-functional processes for Accounts Receivable and Accounts Payable.

The data model in Figure 4 is common to many organizations and industries. I have used it deliberately to illustrate fundamental principles. For example, by inspection we can already see re-engineering opportunities to integrate some functions based on our understanding of the business. But what of other business areas where mandatory rules have been defined that we are not aware of? How can we ensure that these mandatory rules are correctly applied in our area of interest? The complexity of even this simple data model demands automated data dependency analysis.

This analysis was carried out by Visible Advantage [17], a third generation CASE tool that fully automates data dependency analysis for Business Re-Engineering. The results are shown in Figure 5. It represents an extract from an analysis of the complete XYZ Corporation data model, only a subset of which is shown in Figure 4.

Each potential function, process or system represented by an intersecting entity is called a Cluster. Each cluster is numbered and named, and contains all data and processes required for its correct operation. A cluster is thus self-contained: it requires no other mandatory reference to data or processes outside it. Common, inter-dependent, or instead mandatory, data and processes are automatically included within it to ensure its correct operation.

Figure 5 shows Cluster 32, representing the Order Processing function. It has been automatically derived from the data model by Visible Advantage and is one cluster of 65 separate clusters derived from the complete XYZ data model used for this example. Each of these clusters is a potential sub-project; common data and processes appear in all clusters that depend on the data or process. The intersecting entity that is the focus of a cluster appears on the last line.

XYZ Strategic Model                                 Cluster Report
The Entire Model
Dec 20 15:49:30 2005                                   Page 11
------------------------------------------------------------------
32. ORDER PROCESSING FUNCTION (designated)
1)ORDER TYPE
1)ORGANIZATION TYPE
   2)ORGANIZATION
1)NEED
   2)MARKET NEED (MARKET NEEDS ANALYSIS PROCESS)
1)MARKET
1)ORGANIZATION ROLE TYPE
1)PERIOD TYPE
   2)PERIOD
1)FINANCIAL STATEMENT TYPE
1)FINANCIAL POSITION TYPE
      3)FINANCIAL POSITION
         4)FINANCIAL STATEMENT
1)FINANCIAL ACCOUNT TYPE
            5)FINANCIAL ACCOUNT
               6)ORG ROLE FINANCIAL ACTIVITY
                     (ORG ROLE FINANCIAL MGT FUNCTION)
      3)ORGANIZATION ROLE
         4)ORDER
1)ORDER PRODUCT TYPE
   2)PRODUCT NEED (PRODUCT DEVELOPMENT PROCESS)
         4)SUPPLIER (SUPPLIER DATA BASE)
            5)SUPPLIER PRODUCT (PRODUCT SUPPLY PROCESS)
1)PRODUCT
            5)ORDER PRODUCT (ORDER PROCESSING FUNCTION)
------------------------------------------------------------------

Figure 5: Data Dependency analysis of integrated Sales and Distribution data model from Figure 4, showing inter-dependent processes in the Order Processing function.

An intersecting entity on the last cluster line (ORDER PRODUCT in Figure 5) is directly dependent on all entities listed above it that are in bold; it is inter-dependent on those entities above it that are not in bold. Inter-dependent entities represent common data and processes that are also shared by many other clusters. An intersecting entity indicates an inter-dependent function or process; the name of that process or function is shown in italicised brackets after the entity name. Thus we can see that the Order Processing function and the Product Supply, Product Development and Market Needs Analysis processes are all inter-dependent. They are also important to the Org Role Financial Mgt function. Why are these processes all included in this cluster?

We saw in Figure 4 that a PRODUCT must have at least one SUPPLIER. Figure 5 thus includes the Product Supply process to ensure that we are aware of alternative suppliers for each product. But where did the Product Development and Market Needs Analysis processes come from?

Separate from the data model for Order Processing in Figure 4, the data model for the Product Development function follows the business rule that each PRODUCT we offer must address at least one NEED relating to our core business. Similarly the data model for the Market Research function follows the rule that each MARKET must have at least one core business NEED. Thus the Product Development and Market Needs Analysis processes have been included as inter-dependent processes in Figure 5.

We can now see some of the power of data dependency analysis: it uses the business rules defined across the entire enterprise. It acts as a business expert: aware of all relevant business facts. It determines if other business areas should be made aware of relevant business rules, data and processes. So what do these inter-dependent processes suggest?

They indicate that these functions and processes are all cross-functional; that potential re-engineering opportunities exist. These separate processes can be integrated. Consider the following scenario - before re-engineering:

Now consider the same scenario - after re-engineering:

What has happened in this second scenario? X was out of stock, so the Product Supply process automatically displayed all suppliers of Product X. The Purchasing function has been re-engineered so that the Order Clerk can link directly into each supplier's inventory system to check the availability and cost of X for each alternative source of supply. For the selected supplier, the Clerk placed a purchase order for immediate shipment and so could confirm the Wednesday delivery date with the customer.

Next, the Product Development process displayed related products that met the same needs addressed by Product X. This suggested that Product Y may be of interest. An order for Y, based on the current order for X, was automatically prepared and priced - and Y was in stock. This extension to the order only needed the customer's approval for its inclusion in the delivery.

Finally, the Market Needs Analysis process knew that customers in the same market as Customer 165, who also used Products X and Y, had other needs that were addressed by Product Z. A further extension to include Z in the order was automatically prepared and priced. Z was also in stock and was able to be included in the delivery, if agreed.

Instead of waiting for stock availability from the Warehouse in the first scenario based on separate, non-integrated processes for each function, the re-engineered scenario let the Clerk place a purchase order directly with a selected supplier so that the customer's order could be satisfied. And the Product Development and Market Needs Analysis processes then suggested cross-selling opportunities based first on related products, and then on related needs in the customer's market.

Of course, this example does not illustrate a new approach to re-engineering. It is used every day in the travel industry. Any travel agent, after a flight is confirmed, will cross-sell accommodation, car rental and perhaps tours of the destination: as the confirmed travel booking indicates possible related needs. However data dependency ensures that re-engineering opportunities from inter-dependent processes are not overlooked. Let us look further at the benefits of data dependency analysis.

Some entities in Figure 5 represent existing data bases that do not need to be changed; these can be used in their present form by interfacing to them in the Order Processing function. Other entities are data bases that may need to be changed: for example, to include additional attributes or associations, or to be migrated to other hardware or software platforms. Still other entities may represent data that does not exist today. These new data bases must be defined and implemented.

The bracketed numbers preceding each entity listed in Figure 5 show the project phase in which that entity should be defined in greater detail. We see here another benefit of data dependency: it results in the automatic derivation of project plans. Each entity with a higher phase number is indented one further position to the right. The cluster appears in outline form, and can be read as a conceptual Gantt Chart. It can also provide input to any Project Management package for more detailed project planning.

A cluster in outline form can be used to display a data map automatically. For example, vertically aligning each entity by phase, from left to right, shows the data map in Pert Chart format. Or instead entities can be horizontally displayed by phase, from top to bottom, in an Organization Chart format. An entity name is displayed in an entity box; the attribute names may also be displayed in the entity box, together with details such as create, read, update, or delete responsibility, if required. And because the data map is generated automatically, it can be displayed using different data modeling conventions: such as IE notation, or instead IDEF1X.

This ability to automatically generate data maps in different formats is a characteristic of third generation CASE tools: data maps can be displayed from clusters. They do not have to be manually drawn; they can be automatically generated. When new entities are added, or associations changed, affected data maps are not changed manually: they are automatically regenerated. Similarly, process maps can be generated from data models. For example, data access processes (Create, Read, Update, Delete), that operate against entities as reusable methods, can be automatically generated as object-oriented process maps by such third generation CASE tools.

Re-engineered, cross-functional processes identified using data dependency analysis can also suggest reorganization opportunities. For example, inter-dependent processes may all be brought together in a new organization unit. Or they may remain in their present organization structure, but can be integrated automatically by the computer only when needed - as in the re-engineered scenario discussed above.

Back to Contents.

Conclusion

To re-engineer only by improving processes using Business Process Re-engineering (BPR) is like closing the barn door after the horse has bolted! Existing processes must be related back to business plans. Only those processes that support plans relevant to the future should be considered for re-engineering. If a process is important and there are no plans today to guide the process, then plans must be defined that will provide the needed process guidance for the future. If this is not done, then BPR has the same long term impact on an organization's competitiveness as rearranging the deckchairs had on the survival of the Titanic.

Business plans include policies, goals, objectives, strategies and tactics. They may need information for decision-making that is not presently available in the enterprise. This information may be derived from data that does not exist today. Thus no functions or processes will presently exist that provide the information, or that maintain non-existent data up-to-date. By looking at processes only, BPR may never have seen the need for this new information, data, functions and processes.

However the business plans provide a catalyst for definition of data and information in data models defined at each relevant management level. These data models are analysed automatically by data dependency to determine inter-dependent processes. In turn, these suggest cross-functional re-engineered processes. Data dependency analysis derives the project plans automatically to implement the data bases and systems needed by these re-engineered processes.

Only when all three apexes are addressed in the BRE triangle of Figure 3 can Business Re-Engineering fully consider the needs of the business for the future. These are the three steps to success in BRE. Only then can re-engineered organizations be built that are effective, efficient, best-of-breed, and able to compete aggressively in the future.

Back to Contents.

References

1. CSC Index, "Top IS Management Issues", CSC Index, Cambridge: MA (1992)
2. Peter Drucker, "The Coming of the New Organization", Harvard Business Review, Cambridge: MA, (Jan-Feb 1988)
3. Amdahl Australia, Amdahl Executive Institute Report, Sydney: NSW (1992)
4. Gartner Group, "US Federal Survey", Sentry Market Research, Boston: MA (1992)
5. John Zachman, "Framework for Information Systems Architecture", Zachman International, Los Angeles: CA (1992)
6. Short and Venkatraman, "Beyond Business Process Redesign: Redefining Baxter's Business Network", Sloan Management Review (Fall 1992)
7. D. Tapscott and A. Caston, "Paradigm Shift: Interview with Tapscott and Caston", Information Week (Oct 5, 1992)
8. D. Tapscott and A. Caston, "Paradigm Shift: The New Promise of Information Technology", McGraw-Hill, New York: NY (1993)
9. Michael Hammer, "Reengineering Work: Don't Automate, Obliterate", Harvard Business Review, Cambridge: MA (Jul-Aug 1990)
10. Information Engineering (IE) - first developed in Australia and New Zealand in the late 1970s by the Information Engineering Services companies, and supported in the USA by Visible Systems Corporation - is now the dominant systems development methodology world-wide. Business-driven IE, developed for the 1990s by the same group of companies, is the next IE generation and addresses the business problems described in this paper.
11. These software products are Visible Advantage (a third generation CASE tool that automates business-driven IE) and Visible Advisor (a hypermedia methodology reference product for business-driven IE). They run under Windows 3.1, Windows 95 or Windows NT on IBM-compatible PCs and can be used to design and build systems for any hardware or software platform environment. Both products were developed in the USA by VisibleSystems Corporation (Visible) in Washington, DC.
12. A data entity represents data that is stored for later reference. It is a logical representation of data, implemented physically as a Table in a relational data base environment.
13. Data attributes provide information about the data entity in which they reside. Attributes are physically implemented as Columns in a Table.
14. Many CASE tools supporting DP-driven IE (developed in the 70s to support the 80s) still use Affinity Analysis. These CASE tools include IEW and ADW (by KnowledgeWare, purchased by Sterling Software), IEF (TI), and others. Affinity Analysis does not provide the analytical rigour that is needed to identify cross-functional processes, which are vital for success with Business Re-Engineering in the 90s.
15. Clive Finkelstein, "Information Engineering: Strategic Systems Development", Addison-Wesley, Reading: MA (1992).
16. Stephen McClure, "Information Engineering for Client/Server Architectures", Data Base Newsletter, Boston: MA (Jul-Aug 1993).
17. Visible Advantage is a third generation CASE tool that runs under Windows 3.1, Windows 95 or Windows NT. It automatically uses data dependency to analyse data models, identify cross-functional process opportunities for business re-engineering, and derive project plans from data models. Visible Advantage is fully supported in: USA by Visible Systems Corporation (Visible) in Washington, DC; Australia by Information Engineering Services Pty Ltd (IES) in Melbourne; and New Zealand by Information Engineering Services Ltd (IENZ) in Auckland, NZ.

Back to Contents.

More Information

For more information on Business Re-Engineering tools and services in this paper, contact:

Back to Contents.