Business Process Reengineering and Beyond · understanding the business processes, a methodology...

International Technical Support Organization

Business Process Reengineering and Beyond

December 1995

SG24-2590-00

International Technical Support Organization

Business Process Reengineering and Beyond

December 1995

SG24-2590-00

IBM

Take Note!

Before using this information and the product it supports, be sure to read the general information under“Special Notices” on page xiii.

First Edition (December 1995)

This edition applies to BETA Version .06 of Business Modeling Tool (BMT), BETA Version 0.3.31 of VisualAgeRequirements Tool for use with the OS/2 Operating System, and Version 2.1.0 of FlowMark for use with the OS/2and AIX Operating Systems.

Warning

This book is based on a pre-GA version of a product and may not apply when the product becomes generallyavailable. It is recommended that, when the product becomes generally available, you destroy all copies ofthis version of the book that you have in your possession.

Order publications through your IBM representative or the IBM branch office serving your locality. Publicationsare not stocked at the address given below.

An ITSO Technical Bulletin Evaluation Form for reader′s feedback appears facing Chapter 1. If the form has beenremoved, comments may be addressed to:

IBM Corporation, International Technical Support OrganizationDept. 471 Building 80-E2650 Harry RoadSan Jose, California 95120-6099

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in anyway it believes appropriate without incurring any obligation to you.

Copyright International Business Machines Corporation 1995. All rights reserved.Note to U.S. Government Users - Documentation related to restricted rights - Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Abstract

This document describes the major forces driving organizations to reexaminetheir business processes. It looks at an IBM-developed framework forunderstanding the business processes, a methodology for business processreengineering (BPR) called IBM′s Line of Visibility Engineering Methodology(LOVEM), and the following IBM technologies that support the reengineeringprocess through the capture of business rules and requirements: ProModelerand VisualAge Requirements Tool. Also discussed is workflow managementtechnology as a logical extension to the BPR process, as achieved with IBM′sFlowMark product.

This document is written for consultants, information systems professionals, andIBM account teams who are working in the area of business processreengineering, requirements gathering, or workflow management. Someknowledge of business process reengineering concepts and traditionalapplication development techniques would increase the value of this publication.

(199 pages)

Copyright IBM Corp. 1995 iii

iv Beyond BPR

Contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i i i

Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii i

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvHow This Document is Organized . . . . . . . . . . . . . . . . . . . . . . . . . xviRelated Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviITSO Redbooks on the World Wide Web (WWW) . . . . . . . . . . . . . . . . . xviiAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Part 1. Context Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Business Processes Overview . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2. The Changing Environment . . . . . . . . . . . . . . . . . . . . . . . 52.1 Forces Driving Corporate Change . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Constant Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 3. A Model for Business Processes . . . . . . . . . . . . . . . . . . . . 93.1 The Human Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 The Customer-Supplier Relationship . . . . . . . . . . . . . . . . . . . . . . 103.3 Customer-Supplier Communications . . . . . . . . . . . . . . . . . . . . . . 123.4 Traditional Process Definition Methods . . . . . . . . . . . . . . . . . . . . . 143.5 Process Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.6 Business Process Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7 Who Are the Customers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.8 Case Study Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.8.1 Missing Roles and Phases . . . . . . . . . . . . . . . . . . . . . . . . . . 173.8.2 Connecting the Commitments . . . . . . . . . . . . . . . . . . . . . . . . 173.8.3 Estimates versus Commitments . . . . . . . . . . . . . . . . . . . . . . 193.8.4 Structuring Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . 193.8.5 Roles and Organization Structure . . . . . . . . . . . . . . . . . . . . . 19

3.9 Designing Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 203.9.1 New Process Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.9.2 Redesigning Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.10 Business Process Definition: A New Tool . . . . . . . . . . . . . . . . . . 223.11 An IBM Business Process Reengineering Example: Customer

Relationship Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.11.1 CRM Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.11.2 CRM Project Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.11.3 Sample Transaction Scenarios . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 4. Information Systems Architecture . . . . . . . . . . . . . . . . . . . 274.1 The Architecture Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Bubble Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.2 Architect ′s Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.3 Architect ′s Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.4 Contractor′s Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1.5 Shop Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Copyright IBM Corp. 1995 v

4.2 Are Architectural Representations Generic? . . . . . . . . . . . . . . . . . . 314.3 Different Views of an Information System . . . . . . . . . . . . . . . . . . . 32

4.3.1 ISA Framework Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4 Value of the Information Systems Architecture Framework . . . . . . . . . 36

Chapter 5. A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1 Universal Trust Company Overview . . . . . . . . . . . . . . . . . . . . . . . 425.2 Mortgage Application Process . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 Cycle Time Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Headquarters Real Estate Administrator . . . . . . . . . . . . . . . . . . . . 44

Part 2. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line ofVisibility Engineering Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1 Introducing LOVEM-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.1 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Components of LOVEM-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.1 Process Path Management . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.2 Process Maturity Rating and Key Indicators . . . . . . . . . . . . . . . 556.2.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.4 Types of LOVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.3 Architecture Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . 596.3.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 596.3.2 ALOVC Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.4 Logical Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 646.4.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 656.4.2 LLOVC Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.5 Physical Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . . . 676.5.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 676.5.2 PLOVC Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.6 Job Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.6.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 726.6.2 JLOVC Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.6.3 JLOVC Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.7 Reengineering Using the LOVCs . . . . . . . . . . . . . . . . . . . . . . . . . 786.7.1 Criteria for Choosing Business Process Reengineering or Process

Redesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.7.2 Major Business Process Reengineering Roadmap . . . . . . . . . . . 806.7.3 Documenting As Is Processes . . . . . . . . . . . . . . . . . . . . . . . 816.7.4 Architecting To Be Processes . . . . . . . . . . . . . . . . . . . . . . . . 826.7.5 Designing To Be Process Models . . . . . . . . . . . . . . . . . . . . . 84

Chapter 7. Workflow Management . . . . . . . . . . . . . . . . . . . . . . . . . . 877.1 Application Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.2 Business Reengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.4 An Application Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.5 Three Dimensions of Workflow Definition . . . . . . . . . . . . . . . . . . . 90

7.5.1 The Process View: What Is Performed . . . . . . . . . . . . . . . . . . 907.5.2 The Organization View: Who Performs . . . . . . . . . . . . . . . . . . 927.5.3 The Infrastructure View: Which Resources Are Used . . . . . . . . . 92

7.6 Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

vi Beyond BPR

7.6.1 Buildtime Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.6.2 Runtime Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.6.3 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.7 Process-Based Application Development . . . . . . . . . . . . . . . . . . . 957.8 Workflow-Based Application Development . . . . . . . . . . . . . . . . . . . 96

7.8.1 Process Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.9 Object-Oriented Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Part 3. Tools for Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Chapter 8. Business Modeling Tool . . . . . . . . . . . . . . . . . . . . . . . . 1018.1 Basic Activities of the Business Modeling Tool . . . . . . . . . . . . . . . 102

8.1.1 Gathering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028.1.2 Modeling Business Processes . . . . . . . . . . . . . . . . . . . . . . 1028.1.3 Analyzing, Improving, and Monitoring the Process . . . . . . . . . . 103

8.2 Using Business Modeling Tool . . . . . . . . . . . . . . . . . . . . . . . . . 1038.2.1 Business Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048.2.2 Using the Export Facility . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.2.3 Using the LOVCs of BMT . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.3 Generating Workflow Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 1098.3.1 FlowMark and the FlowMark Definition Language . . . . . . . . . . . 1098.3.2 BMT Generation of FlowMark Definition Language . . . . . . . . . . 1108.3.3 From LOVCs to FlowMark Definition Language . . . . . . . . . . . . 111

8.4 Complementary Modeling Techniques . . . . . . . . . . . . . . . . . . . . 1118.4.1 BMT Hierarchical Structure Diagram . . . . . . . . . . . . . . . . . . 1118.4.2 BMT Logical Transformation List . . . . . . . . . . . . . . . . . . . . . 113

Chapter 9. VisualAge Requirements Tool . . . . . . . . . . . . . . . . . . . . . 1179.1 Introducing VisualAge Requirements Tool . . . . . . . . . . . . . . . . . . 118

9.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189.1.2 Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

9.2 Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229.3 Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239.4 The User Requirement Statement . . . . . . . . . . . . . . . . . . . . . . . 1249.5 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

9.5.1 VisualAge Requirements Tool User Environment . . . . . . . . . . . 1259.6 Business Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269.7 Business Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1289.8 Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1329.9 Business Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

9.9.1 Data Dependency Relationships . . . . . . . . . . . . . . . . . . . . . 1429.10 Business Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1439.11 Data Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1449.12 Review Requirements Statements with Users . . . . . . . . . . . . . . . 1459.13 VisualAge Requirements Tool Reports . . . . . . . . . . . . . . . . . . . 145

Chapter 10. FlowMark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14910.1 FlowMark Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

10.1.1 Buildtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15010.1.2 Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.1.3 Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.1.4 How These Pieces Fit Together . . . . . . . . . . . . . . . . . . . . . 154

10.2 Modeling with Buildtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15510.2.1 Creating a FlowMark Model . . . . . . . . . . . . . . . . . . . . . . . 157

Contents vii

10.2.2 Creating Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . 15910.2.3 Creating Program Registrations . . . . . . . . . . . . . . . . . . . . . 15910.2.4 Defining Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16110.2.5 Defining Program Activities . . . . . . . . . . . . . . . . . . . . . . . 16210.2.6 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16410.2.7 Preparing Application Programs . . . . . . . . . . . . . . . . . . . . 165

10.3 Executing with Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16510.3.1 Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16610.3.2 Process Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

10.4 External Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16710.4.1 Importing BMT FlowMark Definition Language . . . . . . . . . . . . 168

10.5 From LOVCs to FlowMark Implementation . . . . . . . . . . . . . . . . . 171

Part 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapter 11. Closing Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17511.1 The Rise of the Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . 17511.2 Understanding Business Processes . . . . . . . . . . . . . . . . . . . . . 17611.3 From Theory to Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

11.3.1 The Boundary Between Business Process and Application System 17811.3.2 Business Processes and the Software Design Process . . . . . . . 17811.3.3 From Models to Action . . . . . . . . . . . . . . . . . . . . . . . . . . 18111.3.4 Business Processes and Application Development . . . . . . . . . 18111.3.5 The Goal: Dynamic Business Processes . . . . . . . . . . . . . . . 182

Appendix A. Customer Relationship Management Processes, OperationalRoles, and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

A.1 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185A.2 Operational Roles and Responsibilities . . . . . . . . . . . . . . . . . . . 186

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

viii Beyond BPR

Figures

1. The Accountability-Procedure Scale . . . . . . . . . . . . . . . . . . . . . . 11 2. The Customer-Supplier Commitment Chain . . . . . . . . . . . . . . . . . 12 3. The Customer-Supplier Approach . . . . . . . . . . . . . . . . . . . . . . . 15 4. The North American Car Dealership Process . . . . . . . . . . . . . . . . 18 5. The Japanese Car Dealership Process . . . . . . . . . . . . . . . . . . . . 19 6. Roles, Jobs and Process Teams . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Framework for Information Systems Architecture . . . . . . . . . . . . . . 33 8. Business Modeling Tool Information Systems Architecture Classification 37 9. VisualAge Requirements Tool Information Systems Architecture

Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3810. FlowMark Information Systems Architecture Classification . . . . . . . . 3911. Process Path Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 5312. Generic LOVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5713. Comparison of Levels of Abstraction and Levels of Detail . . . . . . . . . 5814. Universal Trust Company Mortgage ALOVC . . . . . . . . . . . . . . . . . 6015. Mortgage LLOVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6516. Universal Trust Company Mortgage PLOVC . . . . . . . . . . . . . . . . . 6817. Mortgage JLOVC for the Headquarters Real Estate Administrator Job . 7318. Data and Flow Independence . . . . . . . . . . . . . . . . . . . . . . . . . . 8919. A Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9120. Staff Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9221. The Workflow Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9322. Process-Based Application Development . . . . . . . . . . . . . . . . . . . 9723. Business Models Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 10424. Mortgage Application Tree View . . . . . . . . . . . . . . . . . . . . . . . 10525. Editor Window for JLOVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10626. Export Options Pop-Up Menu . . . . . . . . . . . . . . . . . . . . . . . . . 10827. Hierarchical Structure Diagram Choices . . . . . . . . . . . . . . . . . . 11228. Hierarchical Structure Diagram LOVC Example . . . . . . . . . . . . . . 11229. Hierarchical Structure Diagram Activity Example . . . . . . . . . . . . . 11330. Universal Trust Company Mortgage Application PLOVC . . . . . . . . . 12531. VisualAge Requirements Tool Main Window . . . . . . . . . . . . . . . . 12632. Operation Diagram View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12733. Info Request Business Transaction Settings Pop-up Menu . . . . . . . 12934. Info Request Business Transaction Types . . . . . . . . . . . . . . . . . 13035. Info Request Business Transaction User Role . . . . . . . . . . . . . . . 13136. Info Request Business Transaction General Information . . . . . . . . . 13237. Quotation Business Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . 13338. Quotation Business Rule Settings . . . . . . . . . . . . . . . . . . . . . . 13439. Quotation Business Rule Action 1 . . . . . . . . . . . . . . . . . . . . . . 13540. Quotation Business Rule Classification . . . . . . . . . . . . . . . . . . . 13641. Customer, Prospect, and Product Business Information . . . . . . . . . 14142. Business Information Type . . . . . . . . . . . . . . . . . . . . . . . . . . 14243. Information Dependency Diagram View . . . . . . . . . . . . . . . . . . . 14344. Business Information and Business Facts . . . . . . . . . . . . . . . . . 14445. Sample Business Transaction Report . . . . . . . . . . . . . . . . . . . . 14546. Sample Business Information Report . . . . . . . . . . . . . . . . . . . . 14647. Sample Business Rule Report . . . . . . . . . . . . . . . . . . . . . . . . 14648. Sample Fact Dictionary Report . . . . . . . . . . . . . . . . . . . . . . . . 14749. FlowMark Diagram with Program Activities . . . . . . . . . . . . . . . . 157

Copyright IBM Corp. 1995 ix

50. FlowMark Diagram with Program Activities, Control Connectors, andData Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

51. Data Structure of Application Data . . . . . . . . . . . . . . . . . . . . . . 15952. Program Settings of the Verify_Mtge_Apprvl_Pgm . . . . . . . . . . . . 16053. OS/2 Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16154. Start Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16255. Transition Page of the Control Connector Setting . . . . . . . . . . . . . 16356. Animation of the Mortgage Application in FlowMark Buildtime . . . . . 16457. Runtime Process Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16558. Work List Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16659. Import Window in FlowMark . . . . . . . . . . . . . . . . . . . . . . . . . . 16960. FlowMark Diagram of the Mortgage Application Imported From BMT . 17061. Information Systems Architecture . . . . . . . . . . . . . . . . . . . . . . 17962. Data and Process Models and Information Systems Architecture . . . 18063. Business Process Models and Information Systems Architecture . . . 18064. New Dimensions of Competition . . . . . . . . . . . . . . . . . . . . . . . 183

x Beyond BPR

Tables

1. Building-Construction Architectural Representations . . . . . . . . . . . . 30 2. Architectural Representations Compared . . . . . . . . . . . . . . . . . . 31 3. Business Rule Classification and Suggested Synonyms . . . . . . . . . 137 4. Correspondence between BMT and FlowMark Components . . . . . . 156

Copyright IBM Corp. 1995 xi

xii Beyond BPR

Special Notices

The information in this publication is not intended as the specification of anyprogramming interfaces that are provided by the Business Modeling Tool,VisualAge Requirements Tool, or FlowMark. See the PUBLICATIONS section ofthe IBM Programming Announcement for FlowMark for more information aboutwhat publications are considered to be product documentation.

References in this publication to IBM products, programs or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is not intendedto state or imply that only IBM′s product, program, or service may be used. Anyfunctionally equivalent program that does not infringe any of IBM′s intellectualproperty rights may be used instead of the IBM product, program or service.

Information in this book was developed in conjunction with use of the equipmentspecified, and is limited in application to those specific hardware and softwareproducts and levels.

IBM may have patents or pending patent applications covering subject matter inthis document. The furnishing of this document does not give you any license tothese patents. You can send license inquiries, in writing, to the IBM Director ofLicensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The use of this information or theimplementation of any of these techniques is a customer responsibility anddepends on the customer′s ability to evaluate and integrate them into thecustomer ′s operational environment. While each item may have been reviewedby IBM for accuracy in a specific situation, there is no guarantee that the sameor similar results will be obtained elsewhere. Customers attempting to adaptthese techniques to their own environments do so at their own risk.

The following document contains examples of data and reports used in dailybusiness operations. To illustrate them as completely as possible, the examplescontain the names of individuals, companies, brands, and products. All of thesenames are fictitious and any similarity to the names and addresses used by anactual business enterprise is entirely coincidental.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

The following terms are trademarks of other companies:

C-bus is a trademark of Corollary, Inc.

PC Direct is a trademark of Ziff Communications Company and isused by IBM Corporation under license.

AIX CICSFlowMark IBMLOVEM-E IMSOS/2 SearchManager/2System Object Model Time and PlaceVisualAge VisualInfo

Copyright IBM Corp. 1995 xiii

UNIX is a registered trademark in the United States and othercountries licensed exclusively through X/Open Company Limited.

Windows is a trademark of Microsoft Corporation.

Other trademarks are trademarks of their respective companies.

Lotus Development Corporation

xiv Beyond BPR

Preface

If business process reengineering (BPR) is as powerful a tool as it appears tobe, organizations must develop the capability to analyze and redesign theirbusiness processes. Since many elements of the redesigned processes will beimplemented as computer application systems, new modeling andcommunications techniques will be required to facilitate communication betweenthe business person and information technologists. This publication is intendedto help consultants, customer information systems management, and IBMaccount teams understand the new methodologies and tools which must beemployed to document and understand the current processes and aid in thedesign of new ones. The objectives of this document are to:

• Document the major forces driving organizations to reexamine their businessprocesses.

• Describe a framework for understanding business processes.

• Position business process reengineering and its outputs within theframework for information systems architecture described by John Zachman.

• Describe a methodology for BPR, IBM′s Enhanced Line of VisibilityEngineering Methodology (LOVEM-E).

• Examine technologies that support the reengineering process and thecapture of business rules and facts for use in developing applicationsystems. A common business process, an application for mortgagefinancing, is introduced to illustrate the use of these technologies in the BPRprocess.

• Investigate workflow technology as a logical extension of a process-orientedview of business processes and the BPR process. The mortgage financingsample application is implemented in IBM′s workflow management tool,FlowMark, to illustrate this linkage.

• Discuss how the outputs of a BPR process can complement the developmentof application systems.

Some knowledge of business process reengineering concepts and traditionalapplication development techniques would increase the value of this publication.

Copyright IBM Corp. 1995 xv

How This Document is OrganizedThe document is organized in four major parts:

Part 1, “Context Setting” on page 1

This part describes the volatile business environment that is causingcompanies to examine the way they do business. This part is comprised ofthe following chapters:

• Chapter 1, “Business Processes Overview”• Chapter 2, “The Changing Environment”• Chapter 3, “A Model for Business Processes”• Chapter 4, “Information Systems Architecture”• Chapter 5, “A Case Study”

Part 2, “Roadmap” on page 47

This part describes two methods for defining your business: IBM ′s EnhancedLine of Visibility Methodology and workflow management. This part consistsof the following chapters:

• Chapter 6, “Business Process Reengineering Using IBM′s EnhancedLine of Visibility Engineering Methodology”

• Chapter 7, “Workflow Management”

Part 3, “Tools for Productivity” on page 99

This part describes the various IBM tools that are available to aid in theprocess of documenting, capturing requirements, and implementing possiblereengineered alternatives. Three tools are discussed: Business ModelingTool, VisualAge Requirements Tool, and FlowMark. This part consists of thefollowing chapters:

• Chapter 8, “Business Modeling Tool”• Chapter 9, “VisualAge Requirements Tool”• Chapter 10, “FlowMark”

Part 4, “Conclusions” on page 173

This part consists of our conclusions and closing thoughts. We recommendreading this part if you are interested in a summary or overview of the ideasin the book.

Related PublicationsThe publications listed in this section are considered particularly suitable for amore detailed discussion of the topics covered in this document.

• John A. Zachman, 1987. ″A Framework for Information SystemsArchitecture.″ IBM Systems Journal, Vol. 26, no. 3.

• John F. Sowa and John A. Zachman, 1987. ″Extending and Formalizing theFramework for Information Systems Architecture.″ IBM Systems Journal, Vol.31, no. 3. G321-0108-00.

• William H. Davidson, 1993. ″Beyond Reengineering: The Three Phases ofBusiness Transformation.″ IBM Systems Journal, Vol. 32, no. 1.G321-0110-00.

• Allan L. Scherr, 1993. ″A New Approach to Business Processes.″ IBMSystems Journal, Vol. 32, no. 1. G321-0110-00.

xvi Beyond BPR

• Sumantra Ghoshal and Christopher A. Bartlett, ″Changing the Role of TopManagement: Beyond Structure to Process.″ Harvard Business Review,January-February, 1995.

• Michael Hammer and James Champy, Reengineering the Corporation: AManifesto for Business Revolution. (New York: HarperCollins, 1993),SR28-4952-00.

• Charles Handy, The Age of Unreason. (Boston: Harvard Business SchoolPress, 1989).

• FlowMark for OS/2: Managing Your Workflow. SH19-8176-01.

• FlowMark V2.1 Managing Your Workflow. SH19-8243-00.

• US English Modeling Workflow. SH19-8175-01.

• FlowMark V2.1 Modeling Workflow. SH19-8241-00.

• IBM LOVEM/CABE Consultant′s Guide Version 2.0.

• Business Modeling Tool User′s Guide.

A complete list of International Technical Support Organization publications,known as redbooks, with a brief description of each, may be in:

International Technical Support Organization Bibliography of Redbooks,GG24-3070.

To get a catalog of ITSO redbooks, VNET users may type:

TOOLS SENDTO WTSCPOK TOOLS REDBOOKS GET REDBOOKS CATALOG

A listing of all redbooks, sorted by category, may also be found on MKTTOOLSas ITSOCAT TXT. This package is updated monthly.

How to Order ITSO Redbooks

IBM employees in the USA may order ITSO books and CD-ROMs usingPUBORD Customers in the USA may order by calling 1-800-879-2755 or byfaxing 1-800-445-9269. Most major credit cards are accepted. Outside theUSA, customers should contact their local IBM office. For guidance onordering, send a note to BOOKSHOP at DKIBMVM1 or E-mail [email protected].

Customers may order hardcopy ITSO books individually or in customizedsets, called BOFs, which relate to specific functions of interest. IBMemployees and customers may also order ITSO books in online format onCD-ROM collections, which contain redbooks on a variety of products.

ITSO Redbooks on the World Wide Web (WWW)Internet users may find information about redbooks on the ITSO World Wide Webhome page. To access the ITSO Web pages, point your Web browser to thefollowing URL:

http://www.redbooks.ibm.com/redbooks

Preface xvii

IBM employees may access LIST3820s of redbooks as well. The internalRedbooks home page may be found at the following URL:

http://w3.itsc.pok.ibm.com/redbooks/redbooks.html

AcknowledgmentsThis project was designed and managed by:

Paulette J.A. SoperInternational Technical Support Organization, San Jose Center

The authors of this document are:

Allan HeltonIBM Canada Ltd.

Eric ZulaybarIBM Philippines

Paulette J.A. SoperInternational Technical Support Organization, San Jose Center

This publication is the result of a residency conducted at the InternationalTechnical Support Organization, San Jose Center.

Thanks to the following people for the invaluable advice and guidance providedin the production of this document:

Dr. J. Carlos GotiIBM Corporation, Santa Teresa Lab

Terry AllardIBM Corporation, Santa Teresa Lab

Alan BrownIBM Canada Ltd., BPR Consulting Practice

Wolfgang TrautmannIBM Canada Ltd., BPR Consulting Practice

Enrico ZapantaIBM Canada Ltd., Systems Integration

Michael BreidthardtGerman Software Division Lab

Gerhard MuellerGerman Software Division Lab

Dr. Bernd HoffmannGerman Software Division Lab

Bernd WiedmannGerman Software Division Lab

xviii Beyond BPR

Dr. Peter DeichmannGerman Software Division Lab

Karl Van LeuvenGerman Software Division Lab

Thomas BilfingerInternational Technical Support Organization, San Jose Center

Leif TrulssonInternational Technical Support Organization, San Jose Center

Laura NystromEditor

Preface xix

xx Beyond BPR

Part 1. Context Setting

Copyright IBM Corp. 1995 1

2 Beyond BPR

Chapter 1. Business Processes Overview

Many books and articles have documented the fiercely competitive nature oftoday′s global marketplace. Most of these publications agree an organization′ssurvival depends on delivering new products and services on an almostcontinuous basis, with ever-improving quality, better service, and decreasingprices. However, few organizations were designed for these new competitiverules. The traditional hierarchical organization was proficient at controlling rapidgrowth during a time of rising demand, but has not proven effective at producingthe innovation and responsiveness demanded by today′s customer.

Faced with an increasingly difficult competitive environment, many organizationsare reexamining their approach and developing new strategies which enablethem to compete more effectively. The development of these strategies isbeyond the scope of this document; our interest lies in the development of thebusiness processes through which an organization executes its new strategy. Toset the stage and get you thinking about business processes lets consider atypical business process, order fulfillment.

Order fulfillment includes the activities which begin when a customer places anorder and ends when the goods are delivered and payment collected. Typically,this process involves 10 or more steps performed by different individuals indifferent departments. Someone in customer service receives the order, logs itin, and checks it for completeness and accuracy. Then the order goes toaccounting where someone runs a credit check on the customer. Next, someonein sales determines the price to charge. Then the order travels to inventorycontrol, where someone checks to see if the goods are on hand. If not, the ordergets routed to production scheduling, which issues a back order. Eventually,warehouse operations develops a shipment schedule, shipping determines theshipment method and picks the route and carrier. Product handling picks theproducts from the warehouse, verifies the accuracy of the order, assembles thepicked items, and loads them. Shipping releases the goods to the carrier whichtakes responsibility for delivering them to the customer.

When the customer asks for exactly what the process was designed to deliver,all is well. However, if the customer order deviates in even a small way fromthe standard process, or the customer tries to change their order once it isinitiated, the chances of meeting customer expectations drop dramatically.Process breakdowns occur because of the number of hand-offs and transitionsand, when they do, there is little accountability because, although there aremany groups involved in the process, often no single unit is responsible forsuccessful order fulfillment.

To respond to the realities of the new economy, leading companies arerestructuring around the business process, in our example, order fulfillment.The formerly hierarchic organization is flattened, replaced by a number ofprocess teams responsible for the major organizational processes. Employeeshave evolved into process team members who more likely report to a processowner than a manager in the traditional sense. To provide the responsiveness,flexibility and accountability demanded by today′s customer, these teams areempowered to make their own decisions and encouraged to make changeswhich improve their processes on a continuous basis.


Business Process Reengineering (BPR) is the term often used to describe thecollection of techniques which are used to model existing and develop newbusiness processes and has been used successfully by a number oforganizations to restructure the way they perform work. Because of its success,many organizations are beginning to rethink the role of organization structureand conclude work should be organized around the business process.

Based on the experience of its early adopters, business process reengineeringoffers a set of techniques which can assist organizations in redesigning coreprocesses to meet today′s challenges and, as its use pervades an organization,become a powerful instrument for organization transformation.

4 Beyond BPR

Chapter 2. The Changing Environment

As the competition for global markets intensifies, the formula for gaining andholding market share is undergoing major change. In former times, anorganization would position itself along one of three competitive dimensions:quality, time to market, or cost; then it would optimize its position on thatdimension relative to its competition. The quality leader, for example, was notexpected to also compete on the basis of price or time to market.

Those times have changed. It is no longer sufficient to compete along only oneof these dimensions. Companies are beginning to offer higher quality at lowerprices, stealing market share from competitors that used to own either the“quality” or “low cost” positions in their marketplace. “Time to market,” or thetime from when a product is first conceived to when it becomes availablecommercially, has become a matter of survival rather than a basis forcompetition. Success in the marketplace of today goes to those companies whocan deliver better products faster and cheaper. Lasting advantage is difficult toachieve and once gained is often fleeting as competitors respond to the leader′sproduct or process improvements.

That sweeping change is underway is not in dispute. Is this continuous changeof the kind we have known for the last 50 years in which the past predicted thefuture? Or are we in the throes of discontinuous change which challenges us todevelop new patterns of behavior and new approaches? Charles Handy, in hisbook The Age of Unreason, believes there is little doubt we are experiencingdiscontinuous change.

Handy goes on to suggest that a broad historical and economic change is underway, in which organizations are restructuring to better cope with an environmentthat is highly unpredictable. He suggests these major changes follow apredictable sequence:

Fright: The possibility of bankruptcy, takeover, or collapse.

New faces: New people are brought in at the top.

New questions: Questions, study groups, investigations into old ways andnew options.

New structures: The existing pattern is broken up and rearranged to givenew talent scope and break up old clubs.

New goals and standards: The new organization sets itself new aims andtargets.1

This pattern has a ring of truth for those of us employed by corporateorganizations which have restructured and are now involved in rethinking andredesigning their organization structures and processes. But what is driving thisdiscontinuous change? Why now? In the next section we consider the primaryforces that are compelling companies to reorganize.

1 Handy, Charles, The Age of Unreason. (Boston: Harvard Business School Press, 1989), p.10.


2.1 Forces Driving Corporate ChangeMany writers have documented the forces driving change in organizations.Among these, Hammer and Champy2 have identified three pervasive forces:customers, competition, and constant change.

2.1.1 CustomersFor most of this century the idea of a mass market has allowed sellers to treattheir customers as if they were more or less the same. Even if they were not,and of course they never were, those that were not satisfied had little choicebecause the market was primarily national and the few competitors offered moreor less the same products and services. Henry Ford summed up the attitude ofmass market suppliers with his famous remark, “They can have any color carthey want as long as it′s black.”

Now however, the balance of power in the seller-customer relationship hasshifted. Sellers no longer have the upper hand; customers do. Customers nowtell suppliers what they want, when they want it, how they want it, and what theywill pay. The customer′s newfound power is precipitating profound change infirms who have known only mass markets.

Now that they are unleashed, customers are demanding products designed fortheir unique needs. The mass market has fragmented, with some markets nowconsisting of only a single customer. Suppliers can no longer think in generalabout the customer; they must think about a specific customer, the one they areserving at a given point in time.

2.1.2 CompetitionThe nature of competition is also much different than it was in the mid-1980s. Itused to be straightforward: the company that could get to market first with anacceptable product or service at the best price would get the sale. Marketswere national and there was generally a small number of competitors who kneweach other intimately.

All this has changed. Similar goods compete in different markets according tolocal rules. In one market, competition may be based on price, in anotherselection, and in a third, on a combination of quality and service. Falling tradebarriers have made the marketplace global, with strong competitors driving outthe weaker ones, and the best price, highest quality, or best service availablehas become the standard for all competitors.

Size is no longer automatically an advantage. Startup companies can enter amarket with the next generation of product or service and garner significantmarket share ahead of the existing suppliers. A particular kind of product, suchas computers, permits even small companies the reach previously enjoyed byonly large companies with extensive distribution networks.

2 Hammer, Michael and Champy, James, Reengineering the Corporation: A Manifesto for Business Revolution. (New York:HarperCollins, 1993), pp. 18-24.

6 Beyond BPR

2.1.3 Constant ChangeIt may seem circular to talk about how change itself is an important changeagent in reshaping organizations; after all, it is not as though the environmentwas ever truly static. What is significant about the last 10 years is the change inthe nature and rate of change. Global markets, technology, shrinking productlife cycles, and niche competitors have all combined to make the environmentmore dynamic than ever, forcing organizations to consider new ways ofstructuring themselves to provide the required flexibility and responsiveness.

Hierarchic organizations were designed to provide control over rapid growth andexpansion in a period of rising incomes and strong demand. The hierarchicorganization was well suited for this because it was inherently scalable. When acompany needed to grow, it added workers at the bottom of the organization andthe required number of managers in the layers above. Change was discouragedbecause it increased cost by rendering equipment obsolete, reducing managerialcontrol, increasing the complexity of individual jobs, and producing waste anderror.

Work in these organizations was based on division of both professional andmanual labor into narrow task-based specialties. Accountability was based onthe individual task rather than overall results. The customer was taken forgranted as workers focused inward to their manager and organization.

The shortcomings of hierarchic organizations have been well documented but, tosummarize, they are generally regarded as inflexible, unresponsive, lacking incustomer focus, obsessed with activity rather than results, and costly because ofthe overhead associated with linking the task-based activities. It should beobvious by now that these characteristics make it difficult for these organizationsto respond to the types of challenges outlined in this section.

New organization designs are starting to emerge and overcome theseshortcomings. In these new designs, work is organized around processes, notactivities. Team-based structures spanning functional units overcome barriersbetween functional organizations. The members of these teams are frontlineemployees who monitor their competitive environment continuously, obtaininginformation from a variety of sources, including customers, suppliers, andcompetitors. Team members are empowered not only to redesign old,task-based processes, but also to continuously improve the redesignedprocesses. This type of control requires less supervision, reduces organizationlayers, and so improves responsiveness.

There is a growing conviction in the management literature that processdefinition and improvement excellence is a core capability that organizationsmust develop to succeed. Moreover, it is considered a necessary phase oforganizational transformation that can lead to the development of newcapabilities, products, and services.3

In the next section we take a closer look at the nature of business processes andtheir key characteristics. This provides the building blocks for understanding thebusiness process design technique and methodology discussed in Part 2,“Roadmap” on page 47.

3 Davidson, Will iam H. 1993. “Beyond Reengineering: The Three Phases of Business Transformation.” IBM Systems Journal 32,no. 1:65-79.

Chapter 2. The Changing Environment 7

8 Beyond BPR

Chapter 3. A Model for Business Processes

The business process has become a key organizing principle of the neworganization style and the primary means by which the organization executes itsstrategy and delivers value to its customers. Almost equally important, it is themechanism through which the organization gathers, analyzes, and conveys theinformation necessary for continuous process improvement. But what exactly isa business process? Hammer and Champy define a business process:

“As a collection of activities that takes one or more kinds of input and creates anoutput that is of value to the customer.”4

While this is a reasonable high-level definition of a business process, it isimportant for us to have a more detailed understanding of business processesas background for the business process modeling technique that will bepresented in Part 2, “Roadmap” on page 47.

In this chapter we take a detailed look at the nature of business processes. Wepresent a model described by Dr. Allan Scherr of IBM5 that suggests that thecommunications, and resulting commitments, generated by a customer-supplierexchange is the core building block of business processes.

This chapter contains the following topics:

3.1, “The Human Element” on page 10

3.2, “The Customer-Supplier Relationship” on page 10

3.3, “Customer-Supplier Communications” on page 12

3.4, “Traditional Process Definition Methods” on page 14

3.5, “Process Measurement” on page 14

3.6, “Business Process Definition” on page 15

3.7, “Who Are the Customers?” on page 16

3.8, “Case Study Lessons” on page 16

3.9, “Designing Business Processes” on page 20

3.10, “Business Process Definition: A New Tool” on page 22

3.11, “An IBM Business Process Reengineering Example: CustomerRelationship Management” on page 22

4 Hammer, Michael and Champy, James. Reengineering the Corporation: A Manifesto for Business Revolution. (New York,HarperCollins, 1993), p. 35.

5 Scherr, Allan L. 1993. “A New Approach to Business Processes” IBM Systems Journal 32, no. 1:80-98.


3.1 The Human ElementUnderstanding the nature of business processes is important because theyextend the conventional concern for tasks, activities, and data and focus on thedimension of people and their accountabilities—their roles, agreements, andrelationships. Business processes also provide business people with a usefultool for gaining new insights into their operations and dealing with concernssuch as:

• Quality• Customer satisfaction• Cycle time• Employee accountability• Employee empowerment• Supplier relations• The use of computer automation to support business• Employee training

Business processes are a key link between the concerns of the business personand the information technologist. They provide a common language that allowsbusiness people to express the design of their business processes in a waymeaningful to them while providing clear direction for supporting informationtechnology.

Although automation of business processes is the primary use of informationtechnology in organizations, few computer applications are designed and builtwith explicit consideration of the business process they will support. Mostcomputer applications are designed by focusing on the procedures and data.The primary objective of the design process is to show the relationship betweenprocedural elements (both computer-based and manual) and the use of data.The people who perform the business processes and, more importantly, thosefor whom they are performed, usually customers, are often not explicitlyrecognized or appear as data records, input-output mechanisms, or substitutesfor programs.

Designing business processes in this manner often does not fully define thecomplete range of cases to which the process might need to respond. As wediscussed in Chapter 2, “The Changing Environment” on page 5, becausecustomer focus is so critical to success in the new economy, a key challenge isto design business processes that support unforeseen or spontaneous customerrequirements. New process design approaches are needed that can recognizethe central role of the customer and the importance of the communicationsbetween the customer and supplier during a business process.

3.2 The Customer-Supplier RelationshipScherr ′s process definition technique focuses on people and the accountabilitiesthat arise from their roles, agreements, and commitments.6 The termaccountability is developed more fully in the following section but refers to whatan individual is held responsible for by others. Scherr thinks consideration ofaccountabilities is vital and adds another dimension to understanding businessprocesses not found in procedural and data-based approaches. He believes

6 Ibid., p. 82.

10 Beyond BPR

conducting business is fundamentally the conveying of commitments, with anunderstanding of where the accountability lies for fulfilling the commitments, inaddition to the procedures and data. This is essential for a clear understandingof the business processes.

To illustrate this point consider two hypothetical organizations: one hascompletely defined procedures but no accountabilities, such as a governmentbureaucracy, and the other has well-defined accountabilities but undefinedprocedures, such as a startup company. Figure 1 illustrates this relationship.

Figure 1. The Accountabil ity-Procedure Scale

Scherr defines a business process as “a series of customer-supplierrelationships that produces specific results at specific points in time.”7 The firstcustomer-supplier relationship is often between an actual paying customer andan organization representative such as a salesperson or customer supportrepresentative who then becomes a customer of suppliers within theorganization. This customer-supplier commitment chain continues to the depthnecessary to complete the transaction. Figure 2 on page 12 shows an exampleof a customer-supplier commitment chain.

7 Ibid., p. 81.

Chapter 3. A Model for Business Processes 11

Figure 2. The Customer-Supplier Commitment Chain

The nature of this communication is the foundation of Scherr′s approach tobusiness processes. In the following section, an individual customer-suppliercommunication and its key role as the primary building block of businessprocesses are discussed.

3.3 Customer-Supplier CommunicationsScherr describes the conduct of business as fundamentally the conveyance ofcommitments.8 A customer who places an order, a supplier who accepts theorder, and the supplier who provides a product the customer accepts and paysfor are all enacting different elements of commitment. Thus, an order is acommitment by the customer to accept what is being ordered and to pay for it.The supplier′s acceptance of the order conveys a commitment to deliver. If thesupplier does not deliver an accepted order, the failure is considered a brokencommitment. An examination of the following typical business transactionsindicates that commitment is the key element of the communication betweencustomer and supplier:

• Applying for a loan (asking for a commitment from the bank)

• Approving an engineering change request (agreeing that a change is to beeffected)

• Requesting a salary increase for an employee (seeking commitment frommanagement)

8 Ibid., p. 82.

12 Beyond BPR

• Offering a customer a product or service (committing to deliver if the offer isaccepted)

• Collecting a bill (receiving payment on previously agreed upon terms)

This approach establishes commitment as the basis for communications in thecustomer supplier relationship. The communications between the two partiescan be divided into four phases:

1. The opening communication that begins the conversation, either a requestfrom the customer or an offer from the supplier.

2. The negotiation about the supplier ′s deliverable, the payment by thecustomer, timing, and any other conditions. Technically, these are theconditions of satisfaction for the agreement. Agreement is reached when thesupplier accepts the customer′s request or the customer accepts thesupplier ′s offer. Obviously, either party can counter with a request or offerbefore agreement is reached.

3. The performance or production and delivery by the supplier of the goods orservices that were agreed to in phase 2, specifically, the fulfillment of theconditions of satisfaction by the supplier.

4. The assessment and acceptance of the result by the customer. At this pointthe customer might express satisfaction with the result. The customer′s sideof the agreement on conditions of satisfaction are fulfilled in this phase.

Each of these actions represents the conveyance of a commitment. A completerequest would include a statement of the conditions of satisfaction desired by therequester, including time for fulfillment. By making a request, the requester iscommitting to accept what is being requested if the conditions of satisfaction aremet.

Accepting a request conveys the commitment to deliver the requested conditionsof satisfaction within a specified time. An offer is the commitment to deliver aproposed set of conditions of satisfaction (including a time frame) if the offer isaccepted. If negotiation takes place, the conditions of satisfaction are usuallyrefined with each iteration. When one party agrees to the other party′s proposedconditions of satisfaction, both parties become committed to a single statementof the conditions for satisfaction.

When the supplier reports completion, the commitment being communicated isan affirmation or assertion that the conditions of satisfaction have been met. Ifthe customer rejects the supplier′s work product, the supplier can rework,replace, or redo the work product. Finally, at any point, either party canwithdraw.

Two additional factors are fundamental. First, when the supplier declarescompletion, the work either has been completed on time or not. Second, duringthe assessment phase, customer satisfaction with the transaction can bedetermined. The arrangement for satisfaction feedback from the customer canbe included in the original conditions of satisfaction.

At the completion of a customer-supplier transaction, there are no survivingcommitments. In other words, all of the commitments created during thetransaction are satisfied or one of the parties has withdrawn. If there aresurviving commitments, then the transaction would be extended to include them.


This customer-supplier protocol has the property of being complete: all possibleoutcomes can be represented. Moreover, it can be scaled up to describe thehighest-level transactions of an enterprise and scaled down to describe thespecific actions taken by an individual. Because of these properties thecustomer-supplier protocol forms the basic building block for defining businessprocesses.

3.4 Traditional Process Definition MethodsThe major differences between this approach and the traditional (procedures anddata) process definition approach are:

• The explicit consideration of who performs the activities that make up theprocess. The classic process definition technique focuses only on theprocedural aspects of the process and is described solely by its inputs andoutputs.

• In the classic approach, first the process requirements are defined, then theactivities necessary to meet the requirements. Since the requirements areset when the process is defined, allowances are seldom made for additionalrequirements negotiated during the execution of the process itself.Therefore, conditions of satisfaction are usually fixed, established during thedefinition of the process rather than during the performance of the processitself.

• Measuring customer satisfaction with the customer-supplier approach ismuch easier. In the classical approach, customer satisfaction is measuredusing post-sales surveys, making it difficult to identify root causes ofdissatisfaction when they occur. Using the customer-supplier method,measuring customer satisfaction is easy; it is effectively built-in anddetermined on a transaction-by-transaction basis as part of the assessmentphase.

• When processes are defined around procedures and activities, the resultingprocess structure is often arbitrary, more strongly reflecting organizationalhistory and interpersonal relationships than the actual work of the process.It is rare for two different views of the same set of activities to result in thesame groupings and relationships.

When the customer-supplier approach is used to describe processes,starting with customers and accountability, there is a higher degree ofconsistency when different people look at the same process.

3.5 Process MeasurementWhen the customer-supplier approach is used to define processes, a consistentset of measurements can be developed for each customer-supplier relationship.These standard measurements consist of three basic types of information:

• Time for each phase, overall time, timeliness of the supplier completion,

• Overall outcome and the history of moves leading to it, and

• Customer satisfaction.

Figure 3 on page 15 illustrates the chronology and outcomes of each phase ofthe customer-supplier process. In any of these cases, the customer may not besatisfied with the supplier′s performance. Customer satisfaction is consideredindependent of whether the work product is accepted. It is not uncommon for

14 Beyond BPR

customers to accept goods they are not completely satisfied with. It is alsopossible to find examples of a satisfied customer not accepting the work product.Therefore, customer satisfaction is determined by a specific inquiry.

Figure 3. The Customer-Supplier Approach

3.6 Business Process DefinitionUsing the customer-supplier approach, each one of the customer-supplierrelationships has its own conditions of satisfaction and four-phase (opening,negotiation, performance, assessment) sequence. However, the relationshipsare interdependent. For example, the customer′s original request (the order)would not be accepted by the salesperson without confirmation from theorder-fulfillment manager that the ordered items could be shipped within thetime requested by the customer. The balance of the process might proceed asfollows:

• The customer gives an order (request) to the salesperson. Conditions ofsatisfaction are item quantities, prices, and the date the items are required.

• The salesperson checks prices and, if correct, requests a deliverycommitment from the inventory manager.

• The inventory manager determines if the requested items can be supplied bythe requested time. This determination involves checking inventories andthe manufacturing plant. If there is insufficient inventory new manufacturing


is scheduled. On the basis of these considerations, the inventory manageraccepts the salesperson′s request or makes a counteroffer.

• To schedule new manufacturing, required materials are checked and, if noton hand or pending in the “pipeline,” a supplier is requested to providethem.

• The salesperson conveys the acceptance or counteroffer to the customer,and agreement is reached.

• The inventory is replenished by the manufacturing group if required. Thisactivity requires scheduling manufacturing, which, in turn, can requireobtaining materials from an outside supplier.

• The inventory manager packages the order and requests shipment throughthe shipping company. If the delivery dates do not match the originalconditions of satisfaction, other shippers are consulted, and the customerinformed if appropriate.

• The completion report from the shipping company is a bill of lading signedby the customer. It is forwarded back to the salesperson as a completionreport for open requests.

• The customer pays the bill and reports the level of satisfaction.

3.7 Who Are the Customers?One of the most important questions to consider when designing businessprocesses using this approach is who is the customer. In some cases, thecustomer is actually a customer who is paying for goods or services. However,many processes never deal with an external paying customer. The betterquestion to ask when determining the customer of a process is: “Who must besatisfied with the work product of this process?” Asking the question this way notonly identifies the external or internal customer, but also correctly identifies theshareholders, employee, government regulator, external auditor, or labor unionas the customer of certain processes where appropriate.

A related problem is determining the customer in the case of a product orservice that does not yet exist. No customer can make a request for the productor service, nor is anything offered. New product development processestypically gather information from a variety of sources and develop a set ofproduct or service requirements that potential future customers might want in aproduct or service. These requirements are assembled by an employee orgroup who acts as a proxy or surrogate for the future customers. In thisinstance, this group is the customer.

3.8 Case Study LessonsThis approach has been used in a number of case studies and two generalinsights occur: omissions are identified and alternative business processdesigns become clear.9 The omissions usually involve missing roles, phases, orincomplete conditions of satisfaction. Alternative business process designsinclude the structures of both the accountabilities in an organization and thecustomer-supplier relationship. Both kinds of insight are valuable in designing

9 Ibid., p. 89.

16 Beyond BPR

new or improved business processes that offer higher quality results andimprove customer satisfaction.

3.8.1 Missing Roles and PhasesIn most cases, the most obvious omission is the lack of a clearly definedcustomer role. Or, worse yet, when some internal organizations describe theirprocesses, the organizations appear as customers to all of the surroundingorganizational entities. If there is no clear customer-supplier chain from theoutside customer to the internal organization, processes are being performedwithout a context. Symptoms of this lack of context include unstated or assumedconditions for satisfaction and imprecise or incomplete feedback on customersatisfaction. A telltale sign of a process without an ultimate customer is theabsence of the four-phase process. Usually there is no request or offer openingthe process, the request does not match what the process ultimately delivers, orthe customer acceptance phase is missing.

The two most frequently omitted phases in existing business processes arenegotiation and assessment. In a typical example, work appears in an in-basketand the system assumes the work will be performed according to predefinedprocess and performance standards and the customer will accept it. Whilejustified in certain instances, this reduces the role of the customer and limits theconditions of satisfaction to those defined during the process definition.Conditions of acceptance set during process design can be wasteful andinflexible:

• There is no way to deal with exceptional, high-priority, or unplannedrequests.

• The easier-to-handle requests are sometimes delayed until the last minute.

• The harder-to-handle requests are sometimes rushed through the processwith lower quality just to meet the time criteria.

• Rework is caused by not completely understanding what the customer wants.

• Customer expectations are not managed.

When the negotiation phase is missing, conditions of satisfaction are left vague,thereby missing a critical opportunity to manage customer expectations. As aconsequence of not explicitly setting customer expectations, it is difficult tosubsequently manage customer satisfaction. Obviously, without an assessmentphase there is no direct customer feedback.

3.8.2 Connecting the CommitmentsAccountabilities and roles in an organization are not independent of one another.The customer-supplier approach to process design makes it very clear whenthere is a break in accountability within a business process. In an example towhich many will instantly relate, Scherr describes the operation of a NorthAmerican auto dealership as an example of a process in which there is a breakin accountability between the group in the dealership responsible for selling andthose responsible for servicing the car. It is usually left up to the customer toensure the car is maintained at the dealership where it was purchased.10

Figure 4 on page 18 depicts this process.

10 Ibid., p. 91.


Figure 4. The North American Car Dealership Process

The Japanese car dealership process is quite different from its North Americancounterpart. In Japan, the customer representative is the interface to all of thedealership ′s offerings for the customer. This person, for example, suggests anew car when the service history on the existing one indicates it should bereplaced and might also handle financing, insurance, and used cars for othermembers of the customer′s family. The customer representative is accountablefor the customer′s complete relationship with the dealership over an extendedperiod of time. Figure 5 on page 19 illustrates the Japanese process.

18 Beyond BPR

Figure 5. The Japanese Car Dealership Process

3.8.3 Estimates versus CommitmentsMisunderstandings between customers and suppliers can often arise over thedifference between an estimate and a commitment. In the absence ofdisclaimers to the contrary, the customer assumes an estimate to be acommitment. This can later prove to be an invalid assumption and result incustomer dissatisfaction that could have been avoided had the customer-suppliercommunication been more unequivocal.

3.8.4 Structuring AccountabilityAccountability can be viewed as a supplier′s commitment to fulfill a customer′sconditions of satisfaction. The original customer in a business process has noaccountability in the process (except to pay the bill when due). The first supplierin the chain is responsible for meeting the customer′s conditions of satisfaction.This initial accountability can be completely delegated to secondary suppliers orsplit between several suppliers. Regardless of how the accountability isstructured, it must be possible to identify those accountable at each stage of theoverall customer-supplier chain.

3.8.5 Roles and Organization StructureWhen a business process is described as a series of customer-supplierrelationships it is simple to recognize the roles and associated responsibilities ineach of the relationships. Since roles are assigned to individuals, the job of anygiven individual can be determined by identifying all the roles to which theperson has been assigned. Organizational entities, for example, the orderfulfillment team, are formed by those who play roles in the order fulfillmentprocess. Related job functions are easy to discern; they are those whose roles


share a common process. Figure 6 on page 20 shows these relationships andhow they can be used to represent the structure of an organization.

Figure 6. Roles, Jobs and Process Teams

3.9 Designing Business ProcessesScherr suggests two general paths to process definition. The choice of which tofollow depends on whether the process exists and whether process definitionwork has already begun using another approach.11

11 Ibid., p. 96.

20 Beyond BPR

3.9.1 New Process DesignWhen no process exists or several smaller processes are to be integrated,Scherr suggests starting with the question, “Who is the customer?” As discussedearlier, the customer is the person or entity the process is intended to serve orsatisfy. Obviously, if paying customers are served they are at the beginning ofthe customer-supplier chain. Within an enterprise, a department′s or division′scustomers are usually in the management chain and in the organizations thatare served.

It is often difficult to identify the first customer in a chain of customer-supplierrelationships. One suggested technique is to identify the key interactions thatoccur between the people involved in the process. Usually, when theseconversations are examined, the roles of those involved in the process emergeand a first customer is identified.

Once the customer is identified, the next question is, “What requests does thecustomer make of us?” or “What offers do we make to the customers?” In thecase of an internal organization, the question often focuses on the types ofrequests from management that the internal organization has accepted.

Then, for each customer and request type, the roles (people) involved in relatingto the customer and fulfilling the request or offer are identified. In defining rolesit is usually better to initially identify too many rather than too few. It is easier tocombine roles than to split them up.

Once the roles are defined, the next step is to arrange them in acustomer-supplier chain. The easiest way to do this is usually to try scenariosstarting with the initial customer in the chain and “walking” the customer′srequest or supplier′s offer through the entire chain. As this is done, the requestsexchanged in each customer-supplier pair in the chain are identified.

The final step is to detail the procedures followed to fulfill each role′s individualaccountabilities. This could involve both computer-based and manualprocedures. It is usually not valuable to extend the analysis to include theprocedures the initial customer uses to initiate the request. It is usuallysufficient to document the form and content of the expected request from thecustomer. Similarly, suppliers at the end of the customer-supplier chain areoften considered “black boxes,” or an unknown. An internal supplier can beviewed in the same manner. For example, a sales process that uses the creditdepartment to obtain credit ratings on prospective customers does notnecessarily need to analyze the process used by credit departments to obtaincredit information.

As the detailed procedures or activities are described, the actions to take whenexceptions occur are added. Decisions are made about whether the customer′srequest will ever be countered with an offer, the response to a customerwithdrawal at different points, the circumstances under which withdrawal wouldoccur, the response to a customer′s rejection of the work product, and so forth.For every exception there are several possibilities:

• Detailing the procedures for generating or handling the exception,

• Specifying that a particular exception is not generated, or

• Specifying that the individual playing the role being detailed is empowered tochoose the appropriate course of action when and if the exception occurs.


3.9.2 Redesigning ProcessesIf detailed procedural definitions already exist, it is relatively easy to incorporatethem into the customer-supplier chain. The first step is to arrange theprocedural definitions on the basis of the roles for whom they are performed.For example, if there is a specific customer intake procedure, this would bedescribed as a customer activity. Finally, customer-supplier pairs can be added,a step that usually reveals missing elements, unclear or unstated conditions ofsatisfaction, or outcomes not anticipated in the prior procedural work. Typically,these new elements can be handled by augmenting the procedures.

Defining the data and information elements of the processes can beaccomplished in a similar way. Each activity specified will use or generate data.Some data will be generated and used in the same process; other data willcross process boundaries. If all of the processes of an enterprise are describedin this way, there can be a complete mapping to all of the elements of theenterprise-wide data model. If no such model exists, defining the processes is agood way to create it. In either case, the activities that use or generate dataelements are identified as the process details are defined.

3.10 Business Process Definition: A New ToolBy analyzing business processes, elements that can benefit from computerautomation can be seen clearly and the benefits quantified. Business processdefinition allows the value of the application of information technology tobusiness to be identified and quantified in terms of real costs, process cycletime, and customer satisfaction.

The addition of the customer-supplier communication and accountability toclassic process definition techniques is valuable. It provides a view of problemswith customer satisfaction, organizational efficiency, quality, employeeempowerment, and customer-supplier relations that other approaches do notoffer. This view is not intended to replace procedure and data-basedapproaches; it is presented as an addition that provides new information whichcan enhance the effectiveness of business processes and their supportingapplication systems.

3.11 An IBM Business Process Reengineering Example: CustomerRelationship Management

Over the past few years IBM has aggressively restructured itself, dramaticallyreducing the size of its workforce and expense structure. However, revenuegrowth has proved elusive, and customer satisfaction, though improving, is notyet satisfactory. To improve the effectiveness of its field marketing and servicepersonnel and operate on a more consistent basis worldwide, IBM hasembarked on an ambitious reengineering of its marketing and service processesas part of a project known within IBM as the Customer RelationshipManagement (CRM) Reengineering Project.

The CRM design is based on the business process model and the businessprocess modeling technique described in this document. Some of the highlightsof this reengineering effort include:

Core process. Because reengineering is time consuming, expensive, anddisruptive for an organization it is usually justified only for those processes

22 Beyond BPR

that are vital to the organization′s success. By any measurement, CRM is acore process to IBM. It will replace and consolidate all existing customerfulfillment processes and systems in IBM′s worldwide operations but isconsidered essential to achieving IBM′s vision for delivering value to itscustomers.

Setting and meeting customer expectations. The process design is based ona customer encounter, whether it is initiated by IBM or the customer. Whena customer makes a request of IBM, satisfaction usually depends on howwell IBM meets the expectations. If these expectations are clearlyunderstood and agreed upon by both IBM and the customer, IBM has ahigher likelihood of satisfying the customer. This initial encounter with IBMmay be only the first in a series of customer-supplier relationships, many ofwhich will occur internal to IBM as it marshals the resources to respond tothe original customer request. The business process must ensure that eachof these downstream customer-supplier encounters develops conditions ofsatisfaction and is as rigorously managed as the one involving the payingcustomer.

Customer feedback. The collection of feedback occurs in every phase of thecustomer encounter: opening, negotiation, performance, and assessment.Collecting performance data is important to managing customer expectationsand essential for process improvement.

3.11.1 CRM Project OverviewThe purpose of the Customer Relationship Management (CRM) reengineeringproject is to reshape the sales and support processes executed by IBM′scustomer contact personnel (both direct employees and business partners) andthe staffs that support them. Once redesigned, these processes will be deployedthroughout IBM′s marketing and services organizations worldwide. The uniformapplication of these processes will make IBM more consistently and predictablyresponsive to both customers and other IBM professionals.

3.11.2 CRM Project ApproachThe project will deliver a set of redesigned processes, an integrated set ofsupporting applications, and changes to the IBM management system in twomajor phases. CRM Phase 1 will establish a standard process and applicationplatform across all IBM marketing and services organization. Productivityimprovements will lead to reduced sales expenses, and general andadministrative expenses, and is expected to positively influence revenue growthand customer satisfaction.

While the primary focus of CRM Phase 1 is to deploy standard practices andapplications, the project team is also working with the IBM product divisions todetermine the best approach to providing them with access to the valuablemarket and customer data to be generated by the CRM applications.

CRM Phase 2 will not be completed until mid-1995, but it is planned to includethe results of a customer fulfillment reengineering project and additionalrelationship management reengineering work. Significant enhancements to theCRM Phase 1 processes and applications will also be delivered in this phase.


3.11.2.1 Customer RequirementsThe CRM reengineering project is grounded in the changes customers areasking of IBM. The IBM Consulting Group analyzed multiple sources ofcustomer data and feedback and found our customers cite seven broadcharacteristics they value in a vendor and want IBM to improve upon. Thesecustomer “imperatives” include:

• Fulfil l ing commitments• Ease of doing business• Cost and price• Understanding the customer• Responsiveness and accessibility• Communication• Competence

In addition to these imperatives, the reengineering work is based oncustomer-preferred buying behaviors. In today′s marketplace, customers wanttheir information technology suppliers to provide varying levels of service andprice depending on the customer′s situation and personal preference.

3.11.2.2 CRM Processes, Operational Roles, and ResponsibilitiesPlease refer to Appendix A, “Customer Relationship Management Processes,Operational Roles, and Responsibilities” on page 185 for these details.

3.11.3 Sample Transaction ScenariosPerhaps the best way to understand the change IBM customers, employees, andbusiness partners will see as a result of the CRM process is to walk through afew typical customer requests and transactions.

3.11.3.1 Customer Request for a Customized SolutionA customer with a Latin American transportation company has a logisticsapplication requirement. Though the enjoying an excellent relationship with thiscustomer, the client representative is not personally familiar with logisticsapplications. In our current environment, the client representative might spend asignificant amount of time personally pursuing this opportunity despite notknowing IBM ′s offerings or skilled resource in the transportation area.

In the redesigned customer relationship process, the client representativeregisters the opportunity in an opportunity management application. Anopportunity manager makes a preliminary assessment based on the marketsegment plan, IBM offerings, available skilled resource, and other qualificationcriteria, all available in the information warehouse. The opportunity managerdetermines this is an attractive opportunity, assigns an opportunity owner whohas experience with logistics applications, and electronically informs the clientrepresentative.

The opportunity owner contacts the customer, agreeing to take the lead for IBMto address the customer′s logistics requirements and to remain as the primaryIBM contact on this project through successful implementation. Locating aninstalled logistics solution in the worldwide reference database, the opportunityowner was prepared to discuss it with the customer in just one day. Theopportunity owner could then quickly tailor the solution with other IBM offeringsfound in the offering information database and customize the pricing, terms, andconditions using the standard pricing and contract management applications. Asadditional preparation for meeting with the customer, the opportunity owner

24 Beyond BPR

checks the customer profile information to become more familiar with thecustomer ′s business and relationship history with IBM. The customer is pleasedwith the fast turnaround and the skilled resource that IBM applied to the problemand signs the contract. In the meantime, the client representative was not tiedup looking for the right skills to respond to the logistics application and had timeto uncover a new fleet management opportunity within the same company.


26 Beyond BPR

Chapter 4. Information Systems Architecture

In modern organizations, business processes and information systems form asymbiotic relationship: many leading-edge business processes would beimpossible without computers and most of the justification for informationsystems investment comes from their support of business processes. However,the domains of business and computers are very different: business focuses onentities, processes, locations, people, times, and purposes while computersconsist of data, the programs that manipulate the data, and a technologyinfrastructure. For information systems to be usefully applied to problems in thereal world, there must be mechanisms to relate the two domains.

A number of modeling techniques have emerged over the years to bridge theseworlds, such as flowcharts, entity-relationship and process flow diagrams, anddata flow diagrams. But each of these techniques is specialized for a differentpurpose. By concentrating on one aspect, the individual technique loses sight ofthe overall information system and how it relates to the enterprise and thesurrounding environment. Flowcharts, for example, focus on the operationsperformed by a computer and their sequence. Flowcharts are useful for showingalgorithms, but pay little attention to the data structure processed by thealgorithm; data is considered only as it is being operated on.

An architecture provides a means of describing and relating these differentviews of an information system. The pioneering work in an architecture forinformation systems was done by John Zachman of IBM who proposed, in 1987,a framework for information systems architecture (ISA).12 This initial work definedan architecture relating data, function, and network models, which are the what ,how , and where of an information system.

In 1992, Zachman extended ISA to include three additional views: people (who),time (when), and motivation (why).13 It may be more convenient to think of thepeople view as the challenge of allocating work and structuring authority andresponsibility in an organization. Similarly, t ime is the challenge of optimizingthe utilization of resources while satisfying commitments. Finally, motivationconsiders the issue of organization objectives and strategies for achieving them.

In Chapter 6, “Business Process Reengineering Using IBM′s Enhanced Line ofVisibility Engineering Methodology” on page 49, we present a methodology forbusiness process engineering that generates models and documentation ofpresent and desired business processes. We consider business process modelsa new and valuable tool for modeling an information system and an importantaddition to the data and function-based models of traditional analysis. ISA isvaluable because the framework provides a means of linking these differentmodels into a consistent view of an information system.

In this chapter we look at the overall ISA framework in preparation for thediscussion of business engineering methods, models, and tools included inPart 3, “Tools for Productivity” on page 99.

12 Zachman, John A. 1987. “A Framework for Information Systems Architecture.” IBM Systems Journal 26, no. 3:276-92.

13 Sowa, John F. and Zachman, John A. 1987. “Extending and Formalizing the Framework for Information Systems Architecture.”IBM Systems Journal 31, no. 3:590-616.


This chapter includes the following topics:

4.1, “The Architecture Concept” on page 29

4.2, “Are Architectural Representations Generic?” on page 31

4.3, “Different Views of an Information System” on page 32

4.4, “Value of the Information Systems Architecture Framework” on page 36

28 Beyond BPR

4.1 The Architecture ConceptIn considering the question, “What is an information systems architecture?”Zachman draws on a thousand years of experience in the field of classicalarchitecture to develop the analogous information systems architecturespecifications and work products. The word architecture is a metaphor thatcompares the construction of an information system to the construction of abuilding. In constructing a building, a classical architect develops a number ofdifferent work products, each designed to achieve a different purpose.

4.1.1 Bubble ChartsIn the initial conceptual representation, developed through a dialog between theprospective owner and the architect, the structure is represented as a number of“bubbles,” with each bubble representing a room, its gross size, spatialrelationship, and other details. Collectively, bubble charts define the scope ofthe project.

The bubble charts serve two purposes. First, they capture the owner′s vision forthe structure and serve as a basis for the architect′s actual design. Second,they are the medium through which the architect conveys the understanding ofthe owner′s concept in sufficient detail to convince the owner to proceed with theproject.

4.1.2 Architect′s DrawingsThe architect′s drawings are a depiction of the final structure from the owner′sperspective and include floor plans, cutaway views, and pictorial representationsdepicting the design of the final structure. These drawings enable the owner toagree or disagree with the architect′s concept or suggest modifications to thedesign. While these drawings can be very detailed, they are typically developedonly to the level of detail required for the owner to approve the design.

4.1.3 Architect′s PlansThe architect then translates the owner′s concept and requirements into aproduct, the plans. The plans are the architect′s representation of the finalstructure as opposed to the owner ′s representation, which is depicted in thedrawings.

These plans are typically composed of a number of categories of detailedrepresentations including, for example, site work, the electrical system, masonry,and structure. These plans comprise the architect′s final work product andeventually become the official record of the finished structure.

The architect′s plans serve as the basis for negotiation with a generalcontractor. They enable the owner to take the plans to a contractor and solicitprice quotations with reasonable assurance the delivered structure will be thesame as pictured in the architect′s drawings.

Chapter 4. Information Systems Architecture 29

4.1.4 Contractor′s PlansThe contractor then uses the architect′s plans to produce contractor′s plans,which represent the builder ′s perspective. These plans break down thearchitect′s plans into the component substructures to ease coordination of theactual construction activities that the builders perform. At this point, thecontractor may also realize there is a technology constraint that restricts thecontractor ′s ability to produce exactly what the architect designed. When thisoccurs, the contractor must develop an alternate approach to delivering thearchitect′s design and obtain agreement on the proposed change from allaffected parties.

4.1.5 Shop PlansThe subcontractor responsible for an individual substructure may producedetailed drawings (shop plans) of a specific substructure component. Thesedrawings, while based on the contractor′s plans, are used only by thesubcontractor. An example of a shop plan might be the specification for acomponent to be fabricated specifically for use in the project, either by thesubcontractor or a job shop working on their behalf.

The final representation of the structure is, of course, the building itself.

Table 1 summarizes these different representations.

Table 1. Building-Construction Architectural Representations

Representation Purpose

Bubble charts

Represent basic concepts for buildingIllustrate gross size, shape, spatial relationshipsDevelop a mutual understanding between architect

and ownerInitiate the project

Architect′s drawings

Represent the owner′s version of the final buildingShow floor plans, cutaways, picturesManifest the agreement between architect and

owner on the buildingEstablish the contract

Architect′s plans

Finalize the building as seen by the architectTranslate the owner′s view into a productInclude detailed drawings, multiple categoriesProvide basis for negotiation with general

contractor

Contractor′s plans

Finalize the building as seen by the builderRepresent the architect′s plans as constrained by

laws of nature and available technologyDescribe “How to build it”Direct construction activities

Shop plans

Illustrate subcontractor′s design of a part/sectionShow a detailed stand-alone modelSpecify what is to be constructedProvide patterns

Building Realize the project

30 Beyond BPR

4.2 Are Architectural Representations Generic?Zachman speculated this generalized view of the architectural representationscreated to build a structure would apply equally well to other complexengineering projects. He tested his hypothesis by analyzing the process ofmanufacturing a military airplane and found conceptual equivalents in thismanufacturing activity to the architectural representations of the constructionindustry. Encouraged by these findings, he postulated there is likely to be “ananalogous set of architectural representations produced during the process ofbuilding any complex engineering product, including an information system.”14

Zachman concludes each of the major participants, the owner, the architect, andthe builder, have their own, distinct conception of the product. The owner has inmind a product that will serve some purpose. The architect translates thisperception of a product into the owner′s perspective. The architect thentranslates this representation into a physical product, which is the architect′srepresentation. Finally, the builder applies the constraints of the laws of natureand available technology to produce the product, using his or her own distinctrepresentation.

Zachman went on to observe that the three representations do not merely makeup a set of representations, each of which displays a level of detail greater thanthe previous one. The architect′s representation (architect′s plans) are not just asucceeding, increasing level of detail of the owner′s representation (architect′sdrawings). They are different in nature, content, and terminology and representa different perspective. The level of detail in the architect′s representation(architect′s plans) is often variable, and quite independent of the level of detail ofthe owner′s representation (architect′s drawings).15

Information systems representations analogous to the building example areshown in Table 2.

Table 2. Architectural Representations Compared

GenericDescription

BuildingRepresentation

Information SystemsRepresentation

Initial concept Bubble charts Scope

Owner′srepresentation

Architect ′s drawings Business model

Architect′srepresentation

Architect ′s plans System model

Builder′srepresentation

Contractor′s plans Technology model

Out-of-contextrepresentation

Shop plans Components

Product Building Actual system

14 Zachman, John A. 1987. “A Framework for Information Systems Architecture.” IBM Systems Journal 26, no. 3:281.

15 Ibid., p. 282.


4.3 Different Views of an Information SystemThe five different perspectives, planner, owner, designer, builder, andsubcontractor, of an information system make up one dimension of the ISA. Thesecond dimension is made up of six different views of the nature of theinformation system:

Data (what)Function (how)Network (where)People (who)Time (when)Motivation (why)

Combining the six different views with the five different perspectives leads to thethirty different perspectives of an information system pictured in figures shown inFigure 7 on page 33.

32 Beyond BPR

Figure 7 (Part 1 of 2). Framework for Information Systems Architecture


Figure 7 (Part 2 of 2). Framework for Information Systems Architecture

We will not take you through a laborious discussion of the contents of each ofthe thirty cells that make up the ISA framework. Instead we offer some insighton what the framework represents and how you can use it to understand thedifferent facets of an information system.

As we have discussed above, the framework represents six different ways ofrelating an information system to the real world, corresponding to the familiarEnglish question words, what, how, where, who, when, and why. By definingcolumns for each of these views, the framework allows an individual view to beisolated which provides a convenient means of controlling the complexity of the

34 Beyond BPR

different types of models. Since all of the columns of the framework are views ofthe same underlying enterprise, they are all related.

Most of the enterprise modeling activity to date was focused in the data andfunction columns. Networks of distributed systems brought some focus to thenetwork column, but few formal modeling techniques gained widespreadacceptance. With the arrival of workstation technology and client/serversystems, attention is once again focusing on the network column and theimportance of the data and logic placement decision in developing aninformation systems architecture.

The new additions to ISA, people (who), time (when), and motivation (why), areparticularly germane to our discussion of business processes. Today, there isno broad acceptance in the information processing community on modelingtechniques for these views of an information system. In the future, we believethe business process modeling technique and tools described in Part 2,“Roadmap” on page 47 of this document will represent the types of models thatwill become the accepted means of describing the people, time, and motivationdimensions of an information system.

4.3.1 ISA Framework RulesZachman provided the following rules to assist the reader in understanding ISAand its application.16

Rule 1: The columns have no order. Order implies priorities and creates a biastoward one aspect at the expense of others. All columns are equally importantbecause all are abstractions of the same enterprise.

Rule 2: Each column has a simple, basic model. Each column represents anabstraction from the real world for convenience of description. These modelsinclude:

Data (what)Function (how)Network (where)People (who)Time (when)Motivation (why)

Rule 3: The basic model of each column must be unique. The individual modelsmay be related to one another because they are all abstractions of the samereal-world enterprise, but each model represents a separate and uniqueconcept.

Rule 4: Each row represents a distinct perspective. This rule is most easilydemonstrated by the Business Model, System Model, and Technology Modelrows, which represent the owner′s, architect′s, and builder′s perspectives. Eachperspective is different because it deals with a different set of constraints. Forexample, the owner deals with usability constraints, both aesthetic andfunctional, and the architect deals with design constraints, the laws of physics ornature, and the builder deals with construction constraints, the state of the art inmethods and technologies.

16 Zachman, John A. 1992. “Extending and Formalizing the Framework for Information Systems Architecture.” IBM SystemsJournal 31, no. 3:590-616.


Rule 5: Each cell is unique. Since each column has a unique basic model thatmakes each column unique and each row has a different perspective, each cellin the framework is unique. Zachman likens ISA to a “periodic table” forinformation entities, providing a classification scheme for information entities,allowing different entities to be combined to provide different views of aninformation system.

Because each cell is unique, different techniques and different graphicrepresentations are appropriate for different cells. This also accounts for thelarge number of information systems design models and methodologies thathave emerged over the years.

Rule 6: Combining the cells in one row forms a complete model. The sum of allcells in a given row is the most complete depiction of reality from theperspective of that row. As new cells in a given row are defined each new celldescription must be consistent with the perspective of that row. Each cell in agiven row can be defined and is independent of any other cells in the row, yeteach cell is but one abstraction of the same perspective of reality. Therefore,each cell is related to every other cell in the same row.

4.4 Value of the Information Systems Architecture FrameworkISA provides value for this discussion because it offers a means of classifyingand understanding:

Models and methodologiesTools

Models and methodologies: By classifying six different modeling domains (data,function, network, people, time, and motivation), ISA provides a means ofclassifying different models and the methodologies that produce them. ISA hasno bias toward one modeling approach or methodology over another because allare abstractions of the same enterprise. Traditional programmers, for example,tend to have a bias towards function. They usually begin by designingalgorithms that implement the function and leave the data as an afterthought.They may even claim there is no need to expend resources on defining modelsother than the function or process models.

Programmers from the data community prefer data modeling to be done firstbecause, historically, if data is not designed first its design will be compromised.There are also those who claim the network should be modeled first because thelocation of data and programs should drive the design.

Classifying tools: By examining the outputs of a modeling or applicationdevelopment tool, a tool can be classified according to ISA by either theperspective or modeling domain it supports. In Part 2, “Roadmap” on page 47,we examine three tools that support the business process reengineeringprocess. These tools are:

• Business Modeling Tool (BMT), for business process modeling• VisualAge Requirements Tool, for business systems requirements definition• FlowMark, for workflow management.

Figure 8 on page 37, Figure 9 on page 38, and Figure 10 on page 39 show theISA classification for each of these tools.

36 Beyond BPR

Figure 8. Business Model ing Tool Information Systems Architecture Classification


Figure 9. VisualAge Requirements Tool Information Systems Architecture Classification

38 Beyond BPR

Figure 10. FlowMark Information Systems Architecture Classification


40 Beyond BPR

Chapter 5. A Case Study

This chapter describes an application that we use in the succeeding portions ofthe book to illustrate a methodology and the technologies that allow us to doBPR. The organization that we use in our case is the Universal Trust Company.The line of business (LOB) that our case examines is mortgage applicationprocessing. The following topics are presented:

5.1, “Universal Trust Company Overview” on page 42

5.2, “Mortgage Application Process” on page 42

5.3, “Headquarters Real Estate Administrator” on page 44


5.1 Universal Trust Company OverviewUniversal Trust Company provides, among other financial services, consumermortgages to both new and existing mortgage customers. Lately, the companyhas been aggressive in promoting its products and services, advertising itsofferings on a number of newspapers and television channels. To support theadvertising campaign, the company set up a help desk to answer customerinquiries on offerings (for example, on rates and terms) at any time duringbanking hours.

When a customer applies for a mortgage, the people on the help desk completea mortgage application. The application is then verified. Once verified, themortgage application is put through the approval process. Upon approval, fundsare committed. The terms and conditions document is then prepared and isgiven to the customer for signature.

When the customer returns the signed mortgage document, a mortgage accountis set up. When the customer makes a mortgage payment, the mortgageaccount is debited.

Updates about customers and prospects are also recorded when they contactthe company, or when the company contacts them.

5.2 Mortgage Application ProcessThis section contains the details of the mortgage application process. It coverswhat information is needed in the different processes, and what office tools areused.

Provide Mortgage Data

Customers request mortgage information by telephoning the branch loan officer(BLO). The BLO enters prospect information into the mortgage system andreceives back the requested general mortgage information. The BLO then relaysthe general mortgage information to the customer.

Receive Mortgage Data

To request a mortgage, the customer goes to the branch and completes amortgage application with the assistance of the BLO. The BLO enters themortgage application information into the mortgage system once the applicationis completed. The completed mortgage application form is given to thecustomer for immediate signature or for signing and returning.

Approve Mortgage Application

After the signed application is returned to the BLO, one copy is filed in themortgage filing cabinet and another copy is forwarded to the headquarters realestate administrator (HQ REA). The HQ REA sets up the property appraisal, thenelectronically sends the mortgage property information to the appraiser.

The appraiser completes the appraisal, then files one copy of the appraisal inthe real estate filing cabinet and faxes another copy to the HQ REA.

42 Beyond BPR

The HQ REA verifies whether the mortgage is rejected or approved. The HQREA then files one copy of the property appraisal report in the HQ real estateadministration filing cabinet. If the mortgage application was rejected, the HQREA forwards the rejected mortgage application to the BLO. The BLO calls tonotify the customer of the mortgage rejection. If the mortgage application wasapproved, the HQ REA forwards the approved mortgage application to the BLO.The BLO calls to notify the customer of the mortgage approval.

Commit Funds

The approved mortgage application form is sent to the HQ signing officer (HQSO) by the HQ REA. The HQ SO allocates funds for the mortgage. The HQ SOsends one copy of the approved mortgage form back to the HQ REA. The HQREA enters the approved mortgage details into the mortgage system.

Prepare Mortgage Down Payment

Another copy of the approved mortgage form is sent to HQ legal services (HQLS) to prepare the mortgage documents. Then the HQ LS sends the mortgagedocuments to the BLO. The BLO presents the mortgage documents to thecustomer for signature.

Set Up Mortgage Account

When the BLO receives the signed mortgage documents from the customer, theBLO forwards the documents to the HQ mortgage payment office (HQ MPO). TheHQ MPO sets up a mortgage account in the mortgage system and mails acompleted mortgage package to the customer.

Debit Mortgage Account

When the customer makes mortgage payments, the HQ MPO debits themortgage account in the mortgage system.

5.2.1 Cycle Time DetailsIt takes on the average ten days from the time the customer requests amortgage to the time the approved mortgage document is presented forsignature. Customers have mentioned that a maximum of seven daysturnaround time is required for the Universal Trust Company to be competitive inthe marketplace.

It takes on the average one day from the day the customer requests a mortgageuntil the BLO forwards the application to the HQ REA. It takes another six daysto complete the mortgage appraisal process. Most appraisers take two days tocomplete the appraisal.

The mortgage is verified on the same day as the appraisal is received andrushed to the BLO to notify the customer of acceptance or rejection.

The funds are also signed off on the same day. It takes an additional day for theHQ REA to receive the mortgage details and enter these in the system, and forthe HQ LS to prepare the mortgage documents and present these to thecustomer for signature.

Once the signed mortgage documents are returned to the BLO (almostimmediately after presentation to the customer), the completed package is

Chapter 5. A Case Study 43

mailed to the customer on the next day. The customer then has 30 days to makethe first mortgage payment.

5.3 Headquarters Real Estate AdministratorThis section goes into the details of the activities of the headquarters real estateadministrator (HQ REA) in the mortgage application process. It includes somenotes about the HQ REA job.

Set Up Property Appraisal

Each application contains details about the property to be appraised, such as theaddress and the listed price, plus the closing date. The applications areprioritized by closing date and sorted by location. The property location isdetermined and based on its location, the nearest appraisal office is assigned.The appraisal request is sent via electronic mail. The turnaround time for theappraisal is six working days.

Verify Mortgage Approval

The appraisal is reviewed and checked for completeness. If the appraisal isincomplete, it is sent back to the appraiser. The credit data needs to be verifiedas well. The application is manually updated with the appraisal and credit data.Based on this information, the application is either approved or rejected. Theproperty appraisal report is then filed in the HQ administration file. If theapplication is approved, it is copied and the master is sent to the BLO bycourier. The copy is sent to the HQ signing officer. If the application is rejected,it is sent to the BLO through internal mail.

Enter Approved Mortgage Details

The HQ REA enters the approved mortgage details into the mortgage system.

Notes about the HQ REA Job

• It is an extremely busy job.

• Work is constantly interrupted by the telephone. Calls are received primarilyfrom the BLO inquiring on the status of the appraisals.

• Determining priority of appraisal takes ten minutes. Everything has a highpriority.

• Setting up an appraisal is extremely manual. A large map on the wall helpsbut it is out-of-date and the information on it has to be verified with a file ofmiscellaneous notes to determine the geographic location of the property.Mortgage applications rarely include the zip code. One has to refer to thezip code book and compare the notes and the map. This takes about twohours.

• The appraisal office lists are all manual and not sorted alphabetically. Ittakes about 50 minutes to find the appraisal office nearest the propertylocation.

• Appraisers want to receive several requests at the same time. Therefore,the HQ REA waits until the end of the day before sending the request toensure that all requests are together. There is often only one request.

44 Beyond BPR

• Keying in the e-mail request to the appraiser takes about 45 minutes. Thereis a sequence that needs to be followed when keying in the e-mail, and allinformation in the application needs to be keyed in.

• Market and real estate knowledge is needed to review and check theappraisal. There have been instances when there are wide variationsamong the appraisals, depending on the appraiser. So occasionally, the HQREA sends the appraisals back to the appraiser for reassessment. The HQREA therefore does not like to start the credit check until after the appraisalis complete. It takes about 1.5 hours to review and check an appraisal.

• Verifying credit is a bottleneck. Therefore, the HQ REA walks to the creditdepartment with the mortgage applications and waits or comes back at alater time to ensure a one-day turnaround. It takes 10 minutes to verify thecredit.

• Once the credit rating is received from the credit department, the HQ REAupdates the mortgage application with the appraisal value and the creditrating. This takes 10 minutes.

• Photocopying the mortgage application takes a maximum of 10 minutes.

• The HQ REA is requesting a fax machine. Currently, the HQ REA sends theapproved applications by rush courier to reach the branch for same-daycustomer notification.

• It only takes 15 minutes to enter the information into the system. Thisusually happens the following day after the funds are approved.

Chapter 5. A Case Study 45

46 Beyond BPR

Part 2. Roadmap


48 Beyond BPR

Chapter 6. Business Process Reengineering Using IBM′s EnhancedLine of Visibility Engineering Methodology

In the previous chapters, we examined the business environment today, realizedthe importance of the customer, and recognized the need to reorganize ourbusinesses from hierarchical organizations into process organizations. Thischapter introduces a methodology, Enhanced Line of Visibility EngineeringMethodology (LOVEM-E), that allows you to view your business as a series ofprocesses that focus on the customer.

This chapter is the basis for the succeeding topics that cover the applicationtools that you can use with this methodology.

In this chapter, we explain LOVEM-E, apply it to Universal Trust Company, andpresent how the methodology is used in reengineering projects. This chapterincludes the following topics:

6.1, “Introducing LOVEM-E” on page 50

6.2, “Components of LOVEM-E” on page 52

6.3, “Architecture Line of Visibility Chart” on page 59

6.4, “Logical Line of Visibility Chart” on page 64

6.5, “Physical Line of Visibility Chart” on page 67

6.6, “Job Line of Visibility Chart” on page 72

6.7, “Reengineering Using the LOVCs” on page 78


6.1 Introducing LOVEM-ELOVEM-E is a business process engineering or reengineering methodologydesigned for business and systems professionals. It addresses customersatisfaction, market-driven quality, internal service levels, and total qualitymanagement. The focus of LOVEM-E is the service encounters with customersand clients. It puts emphasis on interfaces, such as, internal and externalhand-offs and dependencies, and interfaces to systems and automation.

LOVEM-E is based on the process path management concept. It uses a pictoriallanguage to demonstrate the processes of an enterprise. Symbols representlogical and physical process and data components. Their arrangementrepresents the sequence and order of a process path or workflow. In this way,each service encounter, process or data component, problem, or opportunity canbe examined in the appropriate context of a process path, and the maturity levelfor the overall process path can be established. LOVEM-E shows all theelements of your business in relationship to one another.

LOVEM-E is also built on the realization that business and systems professionalsare jointly responsible for process design and management. Business processdesign and ongoing business process management, according to servicesmarketing principles, must be shared between business and systemsprofessionals. LOVEM-E offers a common specification language that letsbusiness and systems professionals document, analyze, evaluate, rate, andmanage business processes and systems functions. In addition, employees andmanagement within your business, as well as your relationship with customers,vendors, and suppliers can benefit from this common specification language.

6.1.1 UseYou can use LOVEM-E for the following major applications:

To create a blueprint of your current business to support your efforts to:

• Define your business at the enterprise, business unit, and job levels tosupport:− Business process management− Business process reengineering− Process and systems education− Communication.

• Focus on service encounters to improve customer satisfaction• Identify process problems or opportunities• Set key indicators, such as number of errors, cycle time, costs, and

customer satisfaction• Rate the maturity of your processes• Refine and improve business processes• Understand and improve cycle time and costs• Plan the skills for a given job• Identify and eliminate critical workload problems• Educate new employees (this can be especially useful in areas of high

staff turnover)• Identify and resolve negative results at critical measurement points on

your process path• Focus on process quality.

50 Beyond BPR

To support your reengineering effort if you want to make quantum leapimprovements to your organization and processes. LOVEM-E can help youto:

• Understand your service encounters with customers• Understand your current business, organization, and processes• Model various what if scenarios on how your business could look• Create a blueprint of your reengineered business, its processes,

workflows, and jobs• Create a migration plan and business case to move from your current

(As Is) to your future (To Be) environment• Provide future job level details to help understand systems, skills, tools,

training, and education requirements.

To design workflow solutions to ensure that:

• People and automation are working together effectively and efficiently• The right work gets to the right person at the right time• The correct data and information get to the right person at the right time.

To design solutions for document and folder management, as well as, callflow management.

To use LOVEM-E blueprints as a common specification language to:

• Communicate between functions and departments• Educate executives, managers, or people in new jobs about their

customers, processes, external and internal interfaces, and criticalmeasurement points

• Communicate with your customers, suppliers, and other external parties.

LOVEM-E is most effective when used as a part of an overall plan for businessprocess modeling (BPM), business process reengineering (BPR), or businesstransformation (BT). It complements other BPM, BPR, and BT analysis anddesign approaches.

6.1.2 BenefitsBelow is a summary of the benefits of LOVEM-E:

• Easy-to-use:

− Uses a language business and systems professionals can easilyunderstand

− Can be used independently of other tools− Is highly flexible.

• Shows both internal and external hand-offs and dependencies

• Leads to higher process quality by showing:

− Problems, pitfalls, and bottlenecks− How to reduce cycle time− How to improve customer satisfaction− How to improve employee morale− How to lower cost and increase revenue.

• Establishes accountability and ownership

• Helps to identify areas where employees need new skills, education, andtraining

• Tracks time and identifies critical milestones or measurement points

Chapter 6. Business Process Reengineering Using IBM ′s Enhanced Line of Visibil ity Engineering Methodology 51

• Identifies the service encounters with your customers

• Shows the interfaces between manual activities and systems

• Leads to better and more integrated systems and data.

Success Factors

LOVEM-E has to be applied consistently across an enterprise, a line ofbusiness, or a major reengineering project.

Summary

LOVEM-E is a concise set of business process management and businessprocess reengineering techniques that you can apply in a wide range ofsituations, from business process blueprinting for day-to-day operationalmanagement to radical business process reengineering.

The focus is the service encounters with your customers and clients fordesigning customer and client satisfaction into the processes. LOVEM-E alsohas many other important focus areas, such as employee morale, cost andcycle time reduction, productivity, internal efficiency, and quality.

By using LOVEM-E, you can identify:

• Service encounters• Opportunities• Problem areas• Solutions.

By evaluating, analyzing, and rating the processes or activities involved in aprocess path or workflow from a customer′s and employee′s point-of-view,you can quickly identify problems and opportunities; this often leads tosolutions. For example, you may discover that you are going through severalsteps when there is no proven value to either the customer or your business.Once you have identified these unnecessary steps, you can eliminate them.

The results of your process analysis and design with LOVEM-E can lead toeffective workflow solutions and to solutions for document and foldermanagement or call flow management.

6.2 Components of LOVEM-EThis section defines the components of LOVEM-E. It discusses the following:

• Process path management concepts• Line of visibility chart (LOVC) structure• The different types of LOVCs.

6.2.1 Process Path ManagementBusinesses are usually organized in vertical process structures. In Figure 11 onpage 53 for example, the sell, order, supply, distribute, settle, deliver, andsupport processes are organized vertically. Although vertical structurescontribute to internal excellence, the customer remains outside the system. As

52 Beyond BPR

business organizations recognize the importance of customer satisfaction, thecustomer becomes the focus, the final arbiter, of business processes.

Figure 11. Process Path Management

A process path is a sequence of processes or activities that start and end with acustomer service encounter. A process path starts from a customer process,cuts across several functions of an organization as the customer encounter ishandled, and ends in another customer process as information, goods orservices are provided to the customer.

A process path can be defined at both the logical and the physical levels. At thelogical level, it is a sequence of processes. At the physical level, it is asequence of manual activities and system functions.

Typically, each process path has different process characteristics: for example, ahigh-profit line of business (LOB) usually has many processes aimed at helpingthe operation of the business. On the other hand, a low-profit LOB has tomanage expenses cautiously and tightly, thus not needing many processes.Many modern businesses offer highly customized products and services thathave varying objectives, and thus varying number of processes. Managing thesedifferent process paths with the focus on the customer calls for a new way oflooking at business: management across vertical processes, which is processpath management.

LOVEM-E is based on process path management. The design point of theLOVEM-E is geared towards process path management and process path designfrom the customer′s point of view. It uses a graphical language to demonstratethe processes of an enterprise. Symbols represent logical and physicalprocesses, and data components. Each LOVC sequentially traces the different


processes and data involved in handling a customer encounter from the pointwhen it happens to the point when all activities needed to handle the customerencounter have been completed and the customer is satisfied. In this way, eachservice encounter, process and data component, problem, or opportunity can beexamined, and the maturity level for the process or process path can beestablished. Designing and managing processes and process paths that fit theneeds of customers generate the customer satisfaction that ultimately bringsbusiness success.

6.2.1.1 Data FlowsIn process paths, data flows are data flowing from one process to another. Thedata is required to handle the customer encounter. Data flows identify the datathat is generated from or required by the customer or internal processes.

6.2.1.2 Processes and ActivitiesA process can mean an entire line of business (LOB), such as the mortgageLOB. Or a process can mean the smallest unit of work, such as entering datainto a data processing system or informing the customer that the mortgageapplication has been approved.

To delineate the logical views of a business from the physical views, the termprocess in LOVEM-E means a logical process that can be transformed intoseveral manual activities and system functions.

Processes are a series of actions or operations conducing to an end. These arethe operations that are performed to handle a customer encounter. Activities ofa process are the particular operations required to handle a customerencounter. LOVEM-E contains two types of processes and activities:

Customer processes and activities. Customer processes are the collection ofactivities that a customer performs when interacting with a businessorganization. Inquiring about, requesting, or receiving information, goods, orservices are examples of customer processes. In LOVEM-E, these are foundin the logical charts.

Customer activities are the specific activities that are performed bycustomers when interacting with a business organization. Signingapplication forms, accepting appraisal time, and receiving approval noticesare examples of customer activities. In LOVEM-E, these are found in thephysical charts.

Customer processes and activities can initiate, end, or reside in the middleof process paths.

Business processes and activities. Business processes are the collection ofactivities that a business organization performs to handle the customerprocesses. They show what the organization does in general terms. InLOVEM-E, these are found in the logical charts.

Business activities are the actual actions and operations that theorganization performs to handle the customer process. In LOVEM-E, theseare found in the physical charts.

Business processes and activities have data flowing in and out of them.They receive data flows from other processes or activities, perform anoperation on the data, and send data flows to the next processes oractivities. In LOVCs, processes and activities are presented sequentiallyfrom left to right.

54 Beyond BPR

6.2.2 Process Maturity Rating and Key IndicatorsAn important aspect of business process management is to determine the level ofmaturity of a process or process path. To be able to rate the level of maturityfor a process or process path, certain rating criteria have to be established andadhered to. When establishing the maturity criteria for a process or processpath, you have to differentiate between strategic and operational goals and keyindicators.

Strategic goals and key indicators can, for example, be set once a year.Examples of strategic goals and key indicators are:

Key indicator Strategic goal

Billing errors Reduce the number of billing errors by 50%

Cycle time Reduce the cycle time by 30%

Operational goals and key indicators are derived from the strategic goals andkey indicators and are set and checked more frequently, for example, monthly.Examples of operational goals and key indicators are:

Key indicator Operational goal

Employee education Educate all 20 employees in the billing department indefect prevention within the next month

Data integrity Check the completeness, accuracy, and timeliness of datapassed to the billing department from the order entry anddistribution departments.

Base and target values should be set for each key indicator. While base valuescan be measured and observed over a certain period of time, say three months,target values should be set progressively more challenging, until the strategicgoal has been achieved.

It is advisable to put a checkpoint measurement plan in place for each keyindicator and associated goal, which defines what should be measured, how andhow often it should be measured, and who is responsible for taking andinterpreting the measurements.

Following are more examples of key indicators for individual organizationalunits:

Leasing The number of payment schedules in error

Purchasing How long it takes from an initial request to whenan order is placed with the supplier

Personnel How long it takes to answer a job application

Direct marketing Cost per potential customer who responds to anadvertisement in writing

Regional service centers Customer satisfaction with services

In this example, customer satisfaction cannot be determined until the otherprocesses are completed. That is why the key indicator customer satisfactionshould be used only in conjunction with key indicators for the other processes;in other words, this key indicator depends on the key indicators of otherprocesses.


Establishing key indicators and their associated checkpoints can also requireautomating the taking of measurements.

Statistical methods and simple analytical aids can be used to evaluate andpresent the measurement results. This enables objective decisions based on keyindicators, data, and facts. Examples of analytical aids are:

• Trend charts• Histograms• Pareto diagrams• Cause and effect diagrams.

The maturity level of a process or process path can be established with the helpof any of the four types of LOVCs. While the logical LOVCs, like the ALOVC andLLOVC, are better suited for establishing a high-level rating and for settingstrategic goals and key indicators, the physical LOVCs, like the PLOVC andJLOVC, are better suited for coming up with detailed ratings and for settingoperational goals and key indicators, since they contain all operational aspectsof the process path. An As Is or a To Be process maturity rating should beassociated with every LOVC blueprint.

Success Factor

Aligning strategic goals and key indicators across the entire process pathmust be done before establishing process maturity levels and rating criteria.

6.2.3 StructureAlthough there are several templates of LOVCs, all share a common structuresimilar to Figure 12 on page 57. All LOVCs are made up of several horizontalbands and lines. Bands show who is performing each process. Lines givebackground information to the processes putting these processes in perspectiveto the business. Following are the lines and the bands that can be found in allthe LOVCs:

56 Beyond BPR

Figure 12. Generic LOVC

6.2.3.1 The Customer BandThe customer band is the area where all customer processes and activitiesreside. The customer band is at the top of an LOVC.

6.2.3.2 The Enterprise BandsBelow the customer band are the enterprise bands. These bands represent thedifferent functions, departments, jobs, or roles that perform processes of abusiness organization and handle customer processes and activities. Severalenterprise bands usually exist in an LOVC because several functions,departments, jobs, or roles are involved in handling customer encounters.These functions, departments, jobs, or roles can be internal or external to theorganization but are all seen by the customer as part of the organization.

6.2.3.3 The Line of VisibilityThe line of visibility separates the customer band from the enterprise band. Allthe data flows that go through this line are the customer encounters or themoments of truth that happen between customers and organizations. This line ofvisibility presents the image of the organization as viewed by its customers. Nomatter how efficient a particular function, department, job, or role is, what isvisible to the customer is the total service provided by the organization, which isthe entire series of processes from beginning to end.


6.2.4 Types of LOVCsThere are four types of LOVCs:

• The architecture line of visibility chart (ALOVC)• The logical line of visibility chart (LLOVC)• The physical line of visibility chart (PLOVC)• The job line of visibility chart (JLOVC)

Each LOVC provides a different view of the business of an organization and hasits own LOVC template. Users of the LOVCs would use one of these chartsdepending on the level of abstraction or the level of detail that they would wantto cover. Figure 13 compares the different LOVCs based on their levels ofabstraction and levels of detail.

Figure 13. Comparison of Levels of Abstraction and Levels of Detail

6.2.4.1 Comparison of Logical and Physical RepresentationsDifferent process engineering and reengineering activities can be carried out atvarious levels of abstraction, for example:

• At the enterprise architecture level, as expressed by the ALOVC• At the logical and physical process path levels, as expressed by the LLOVC

and PLOVC• At the job level, as expressed by the JLOVC.

Logical, Unconstrained: You can start with a logical representation of yourbusiness processes to get a stable framework for your design work. This wouldbe the equivalent of drawing a map of a continent showing only the borders of

58 Beyond BPR

countries with capitals, mountains and rivers but without railroads, roads, orother constraining elements.

At this logical level, you focus on why the process is needed and what theprocess does, not how it is done. At this stage, you do not add any constraintssuch as organization, time, people, tools, and so on to the process. Tographically represent the logical process path views, you can use:

• The ALOVC for the enterprise architecture process path view• The LLOVC for the process path view for one line of business.

Physical, Constrained: Once you have a stable enterprise architecture and alogical process path design, you can start to add the various constraining factorsto the design such as organizations, people, information and goods flows,electronic data interchange (EDI) transactions, documents and forms, systems,means of transportation, timing parameters, or any other real-life items thatcontribute to a process or process path. This is like adding all the roads,mountains, airports, or other specifics to a map of a country.

At this physical design stage, you can start by experimenting with variousalternative models before committing to a detailed design.

To graphically represent the physical process path views, you can use:

• The PLOVC for modeling the physical constraints of the process path• The JLOVC for modeling the physical constraints of individual jobs

6.3 Architecture Line of Visibility ChartThe architecture line of visibility chart (ALOVC) is the highest level ofabstraction. It is logical and unconstrained, and is used in developing anorganization ′s architecture. It focuses only on the main customer processes, theorganization ′s processes that support these, and the key data components thatare used. It depicts the strategies that an organization has embarked on whendoing business with its customers, and how it uses services and data to supportits strategies. It also shows what processes are critical to the organization andare subject to quality planning.

6.3.1 Structure and Main ComponentsFigure 14 on page 60 is an examples of an ALOVC.


Figure 14 (Part 1 of 2). Universal Trust Company Mortgage ALOVC

60 Beyond BPR

Figure 14 (Part 2 of 2). Universal Trust Company Mortgage ALOVC

Customer Band

The top band, above the LOV, shows the major customer processes.

Line of Visibility

The LOV is the interface between the customer and the internal processes. Theinteractions represent:

• Service encounters• Moments of truth• The company′s image.

Service Encounter Support Buses

Directly below the LOV are the two service encounter support buses:

• The Inquiry Management Bus• The Change Management Bus

They are dynamic process buses and highlight the importance of the mostfrequent service encounters, which are customer inquiries and customer changerequests.


These two process buses are repetitive and unpredictable processes that couldhappen at any point during a relationship with your customer. They cross all theother operational roles and processes, and can be invoked at any time by thecustomer or by internal processes.

The ALOVC focuses on the first touch, only touch principle. For the first touch,only touch principle to be effective, you need accurate, complete, and timelydata, which is available through the cross service encounter data buses at anypoint on the path.

Note: The term bus is borrowed from the electrical engineering, or computerdesign, language, and signifies a continuum with concrete contact, orentry and exit, points.

Logical Roles

Three bands show the three major logical roles found in any fulfillmententerprise. These are:

• The marketer

The key contact with the customer. Usually, this contact initiates andmanages the contractual relationship.

• The fulfiller

The key contact responsible for fulfilling the promise made by the enterpriseto its customer, through the contract or order.

• The settler

The key contact responsible for managing the customer′s financialobligations to the enterprise, or the enterprise′s financial obligations to thecustomer based on the contract.

These roles carry out distinct and concrete processes.

The boundaries between the operational roles represent internal interfaces.They highlight:

• Interactions between the three major operational roles• What others see• Internal moments of truth• Where hand-offs take place• Where dependencies are shown.

Cross Service Encounter Data Buses

A data bus is like a high-level dynamic data store that can link the processarchitecture to a separate data architecture.

Data or information is one of the most important assets of any enterprise. Youmust understand and manage it at the architecture level as well as at any levelof design and implementation. The two key data entities of any enterprise are:

• Customer• Products and services.

The most important relationship between these two entities is the contract ororder that ties the customer to your products and services.

The three data buses reflect these two key entities and their relationship:

62 Beyond BPR

Contact (or Customer) Data. Captures information about customers. Thiscan be the traditional customer record data; but it can also be anyinterpersonal relationship information about service encounters. It can alsoinclude what the customers need and want over and above the currentcontract, or any other information that helps delight the customer in futureservice encounters.

Offering (or Product and Service) Data. Captures information about thecurrent and future products and services that might affect the existingrelationship and future relations with a customer. This bus can also captureinformation about any competitive or complementary products and servicesfor this relationship.

Promise (or Contract and Order) Data. Captures information about thecurrent contracts and orders that your enterprise has with a customer. Anyother information that can help define, clarify, expand on contracts andorders with a customer, or that is useful in future relations, can also becaptured through this bus.

Process Quality Management Bus

On this bus, you can show measurements to be taken for the process path, suchas critical measurement points, intervals between service encounters,transaction volumes at specific instances on the path, or any other benchmarkmeasurements. These measurements should be tied to customer research inorder to achieve customer satisfaction. You can also show other businessparameters on this bus, such as critical success factors (CSFs), goals, strategies,and policies (GSPs), and critical measurement points (CMPs).

6.3.2 ALOVC ExampleFigure 14 on page 60 is an example of an ALOVC of the Universal TrustCompany.

In the examples, the top band (above the LOV) shows the customer processes:

• Receive product data• Request product data• Apply for product• Request change to application• Agree to terms and conditions• Make payments.

Below the LOV are the four major components of the overall bankingarchitecture. They are:

• Service encounter support buses• Operational roles• Cross service encounter data buses• Process quality management bus.

For example, while the customer process apply for product is performed bysending the application data to the marketer, two other processes occur: theverify application process and the approve application process.

The verify application process also updates the contact data bus and the promisedata bus. In addition, a critical measurement point is created on the processquality management bus to capture the date application received information.


The approve application process uses the following information:

• Customer data from the contact data bus• Product data from the offering data bus• Other contact data from the promise data bus.

Once approved, the approved application is forwarded to the fulfiller who thencommits the funds.

Success Factor

If senior management accepts the high-level business architecture (includingthe business rules, policies, directions, and guiding principles), the chancesare better for a successful implementation of the reengineered process. Thechances are further increased if customers, partners, and all other interestedparties also accept the architecture.

Summary

The ALOVC is a convenient way to document a process architecture at theenterprise level. It is a good start to a top-down business processreengineering project. The most important features are:

• The service encounters with customers

• The first touch, only touch design principle

• The essential enterprise processes linked to the essential information

• Quality factors identified throughout the enterprise process path,including process maturity ratings

The ALOVC provides a stable framework for downstream designs.

6.4 Logical Line of Visibility ChartThe logical line of visibility chart (LLOVC) is the starting point for creating adesign of the different offerings or lines of business of an organization. It is away to develop models and blueprints of process paths for these lines ofbusiness. It identifies only generic functions and processes, and shows which ofthese processes require data. Because it is high-level and does not includephysical constraints (for example existing systems and geographic locations), itprovides a stable view of a process path.

64 Beyond BPR

6.4.1 Structure and Main ComponentsUnlike the ALOVC with its predefined template, the LLOVC is more free-form.You can still use a template with a band for the customer processes above theLOV, but the internal processes can have as many bands and as much detail asyou need. You can also show a data bus at the bottom of the chart for clarity.

Figure 15 shows an example of an LLOVC.

Figure 15. Mortgage LLOVC

Customer Band

The top band, above the LOV, shows the major customer processes.

Line of Visibility

The LOV is the interface between a customer process and an internal processand represents what the customer sees. It reflects:

• A service encounter• A moment of truth• The company′s image.

Note: The service encounters occur at the LOV.


Logical Business Area Bands

There are several bands that represent logical business areas. They contain theinternal logical processes and data flows.

Between two business area bands, there are lines that represent internalinterfaces. They can be thought of as internal LOVs, representing:

• What the other business area sees• Internal moments of truth• Where hand-offs take place• Where dependencies are shown.

Data Bus

An optional data bus can exist. This represents enterprise data that the processpath requires.

6.4.2 LLOVC ExamplesFigure 15 on page 65 illustrates an LLOVC of the mortgages process path ofUniversal Trust Company. The top band above the line of visibility (LOV) showsthe customer processes:

• Request mortgage information• Request mortgage• Sign mortgage documents• Make mortgage payments.

Below the LOV five bands represent the five major logical business areas thatare involved in the process path:

• Sell• Order• Supply• Distribute• Settle.

Each band contains the most important logical processes that the logicalbusiness area is responsible for. For example, the sell business area isresponsible for providing mortgage data, and the distribute business area isresponsible for preparing mortgage documents.

The processes are connected with data flows that are required in this processpath. For example, the order business area needs mortgage application datafrom the customer before it can verify the mortgage application data. Similarly,the settle business area needs payment data from the customer and mortgagepayment details from the internal process set up mortgage account before it candebit the mortgage account.

At the bottom of the chart is an optional data bus that helps to highlight theimportance of some data for downstream use. For example, customer data isupdated by the provide mortgage data and verify mortgage application dataprocesses.

66 Beyond BPR

Success Factor

If the high-level design for a LOB is integrated in the overall businessarchitecture, and if senior management accepts it, the chances are better fora successful implementation of the reengineered process.

Summary

The LLOVC is an important part of LOVEM-E because it has many differentbusiness process engineering applications. The most important features are:

• The service encounter with the customer

• Internal interfaces or dependencies

• Process sequence or flow

• Data flows

• Business parameters, such as CMPs, CSFs, and GSPs

The LLOVC provides a stable framework for downstream designs.

6.5 Physical Line of Visibility ChartThe physical line of visibility chart (PLOVC) is a graphical representation of thephysical constraints of a process path. It sequentially organizes and shows indetail all the important physical aspects of a process path. For one particularprocess path it presents the manual activities and their interfaces to:

• Customer processes• Other internal activities• Automated systems.

It also shows the cycle time of that process. The output is a model or a blueprintof the process path implemented under the constraints of the business.

6.5.1 Structure and Main ComponentsThe PLOVC template is very similar to the LLOVC with the addition of:

• The manual/automation interface line• The time line.

Figure 16 on page 68 shows an example of a PLOVC.


Figure 16 (Part 1 of 2). Universal Trust Company Mortgage PLOVC

68 Beyond BPR

Figure 16 (Part 2 of 2). Universal Trust Company Mortgage PLOVC

The contents of a PLOVC are significantly different to the contents of an LLOVC.You are now dealing with the physical constraints of the process path. On theleft-hand side of the chart in Figure 16 on page 68 are the descriptions for thebands, which now represent specific business functions, departments, jobs, orinternal/external organizations. All the symbols are of a physical, or tangible,nature.

Customer Band

The top band, above the LOV, shows the customer activities.

Line of Visibility

The LOV is the interface between a customer activity and an internal activity orsystem; it represents:

• What the customer sees• A service encounter• A moment of truth• The company′s image.



Internal/External Organizations Band

One of the bands below the LOV can be designated as an internal or externalorganizations band and contain internal organization units that do not belong tothis process path or external organization units that this process path deals with,such as vendors, suppliers, government agencies, and financial institutions.

Specific Function/Department/Job Bands

Usually several bands are required to represent the specific functions,departments, or jobs that contain the manual activities and information flows,goods flows, and control flows.

Between these bands, there are lines that which represent internal interfaces,orhand-offs. They can be thought of as internal LOVs, showing:

• What the other function sees• Internal moments of truth• Where hand-offs take place• Where dependencies are shown.

Manual/Automation Interface Line

The manual/automation interface line represents the interface between systemsand:

• Customer activities• Internal activities• Internal/external organizations• External systems.

The interfaces can be to batch or online systems.

Note: Systems that do not directly interface with the process path can be shownbelow the manual/automation interface line. These can be connectedthrough information flows with systems or with computer data storesbelow the interface line.

Time Line

The time line represents:

• The time it takes or should take between activities• The cycle time for the entire process path• Bottlenecks and areas that slow down your processes• Current time measurements and internal targets

The time line can be expressed in any relevant unit of time, for example, inhours, business or calendar days, weeks, months.

6.5.2 PLOVC ExamplesFigure 16 on page 68 is an examples of the As Is PLOVC for the mortgagesprocess path of Universal Trust Company.

In Figure 16 on page 68, the top band above the LOV shows the customeractivities:

• Request mortgage information• Request mortgage• Sign mortgage application

70 Beyond BPR

• Accept appraisal time• Receive mortgage rejection notice• Receive mortgage acceptance notice• Sign mortgage document• Receive complete mortgage package documents• Make mortgage payments.

Below the LOV, there are six bands representing the six jobs required to performthe mortgages process path. The specific jobs are:

• Branch loan officer• Headquarters real estate administrator• Appraiser• Headquarters signing officer• Headquarters legal services• Headquarters mortgage payment office.

Each band contains the activities and information flows, goods flows, and controlflows that the job is responsible for; for example, the headquarters real estateadministrator is responsible for setting up the property appraisal, verifyingmortgage approval, and entering approved mortgage details in the mortgagesystem. The appraiser is responsible only for appraising the mortgage property.The activities are connected through information flows, goods flows, and controlflows that are required for this process path. For example, the branch loanofficer requires mortgage application information from the customer and paymentinformation from the mortgage system to perform the assist with mortgageapplication completion activity, which sends the mortgage application informationin hardcopy to the customer and updates the mortgage system with customermortgage application information.

The customer returns the signed mortgage information document to the branchloan officer, who then forwards the signed mortgage information document to theheadquarters real estate administrator and files a copy of the document in themortgage file cabinet.

The time line at the bottom of Figure 16 on page 68 shows that it requires sevendays from the initial customer request today until Universal Trust Companyprovides the customer with the property appraisal results. Customer researchshows that it should require three days, maximum, which the companydesignates as its target for reengineering.

Success Factor

Building various implementation alternatives can greatly enhance theprobability of arriving at the best design for customer satisfaction andemployee morale.

Customer satisfaction and employee morale are the two pillars of businesssuccess.


Summary

The PLOVC is an important technique for business process reengineering aswell as for making day-to-day decisions or operating and managing yourbusiness. The most important features:

• The design point is the service encounter with the customer.

• Other focus areas are:

− Internal and external interfaces at the function, department, and joblevels

− Interfaces to systems

− Cycle time

− Critical measurement points

− Information and goods flow media, such as telephone, fax, truck, ordocument

− Control flows

− Opportunity areas and problem areas

− Costs for the entire process path or for individual components

− Process maturity ratings and key indicators.

• The PLOVC helps you to validate your understanding of the As Is processpath and helps you to build To Be scenarios and blueprints.

• You work at the physical, or constrained, level, which provides a clearpicture of reality.

• It is not only a blueprinting and design technique but also an effectiveway for communication and education.

6.6 Job Line of Visibility ChartThe job line of visibility chart (JLOVC) is the lowest level of abstraction. Itfocuses on one job at a time and organizes and shows sequentially all thephysical aspects of that job. It focuses on a job′s manual activities and theirinterfaces to:

• Customer processes• Internal functions, departments, and jobs• External agencies (for example, vendors and financial institutions)• Automated systems.

The JLOVC also shows the cycle time of that process. The output is a model ora blueprint of a job at the physical level.

6.6.1 Structure and Main ComponentsThe JLOVC template is very similar to the PLOVC; however, it has only oneinternal band.

Figure 17 on page 73 shows an example of a JLOVC.

72 Beyond BPR

Figure 17 (Part 1 of 3). Mortgage JLOVC for the Headquarters Real Estate Administrator Job



74 Beyond BPR


Customer Band

The top band, above the LOV, shows the major customer activities.

Line of Visibility

The LOV is the interface between a customer and an internal activity or system.It represents:

• What the customer sees• A service encounter• A moment of truth• The company′s image.


Internal/External Organizations Band

Directly below the LOV is an auxiliary band, showing all the interfacing internaland external organizations (other than the customer) for the job: interfaces withother internal departments or jobs, or external organizations.

The interface line between this band and the main band shows theinternal/external service encounters:


• What others see• Moments of truth• Where hand-offs take place• Where dependencies are shown.

Manual/Automation Interface Line

The interface between systems and the following can be interfaces to batch oronline systems:

• Customer activities• Internal activities• Internal/external organization units• External systems.

Note: External systems that do not directly interface with the job can be shownbelow the interface line. They can be connected through informationflows with the systems or with computer data stores below the interfaceline.

Time Line

The time line represents:

• The time it takes, or should take, between activities• The cycle time for the entire job• Bottlenecks• Current measurements and internal target

The time line can be expressed using any relevant unit of time, for example,business days, calendar days, weeks, or hours.

6.6.2 JLOVC ExamplesFigure 17 on page 73 illustrates the As Is JLOVC of the headquarters real estateadministrator in the mortgage process path of Universal Trust Company.

In Figure 17 on page 73, the headquarters real estate administrator has nocontact with the customer but interfaces with three internal jobs: the branchloan officer, the appraiser, and the headquarters signing officer.

The headquarters real estate administrator sets up the property appraisal afterreceiving the signed mortgage information document from the branch loanofficer. Once the appraiser receives the mortgage property information throughelectronic link, and the property has been appraised, a property appraisalinformation report is faxed to the headquarters real estate administrator, whothen verifies the mortgage approval, sends the mortgage approval informationdocument to the bank loan officer and the approved mortgage details documentto the headquarters signing officer. The headquarters signing officer sends theapproved mortgage details document back to the headquarters real estateadministrator, who then and enters the approved mortgage details into themortgage system. If, however, the mortgage application is rejected, theheadquarters real estate administrator sends the mortgage rejection informationdocument to the branch loan officer. In either case, the property appraisalinformation report is filed in the headquarters real estate administrator′s filingcabinet

The time line indicates that it requires seven days from when the headquartersreal estate administrator receives the signed mortgage information until the

76 Beyond BPR

approved mortgage information is entered into the mortgage system. Thedesired target is three days. Therefore, some reengineering of the job and itsinterfaces is required.

6.6.3 JLOVC ApplicationsBecause a JLOVC provides you with a very detailed blueprint of one job, it has anumber of applications, including:

• Job costing• Time duration details• Subjobs• Job decomposition• Systems requirements• Repetitive activities (loops)• Job skills• Job proficiency education• Job redesign.

Success Factors

Building various implementation alternatives for individual jobs cangreatly enhance the probability of arriving at the best design for customersatisfaction and employee morale.

Customer satisfaction and employee morale are the two pillars ofbusiness success!

Integrating all aspects of the job design in the process path designminimizes the risk of problems with upstream and downstreamdependencies.


Summary

The JLOVC helps you design individual jobs and assists in making day-to-daydecisions on the operations and management of one job. The mostimportant features are:

• The service encounter with the customer

• Internal and external interfaces

• Organizational interfaces: dependencies and hand-offs

• Interfaces to systems

• Cycle time

• Visibility of business control parameters

• Job maturity ratings and key indicators

• Information and goods flow media, such as telephones and trucks

• Costs for the entire job or for individual components

• Job skills.

The JLOVC is:

• A graphical means for validating your understanding of the As Is job

• An aid for building To Be scenarios and blueprints

• Readily understood by business professionals, because it deals withphysical realities

• A means for communication and education

• The basis for building a total job profile for all aspects of a job.

6.7 Reengineering Using the LOVCsBusiness processes are often engineered or reengineered in the context of aspecial project. Within the project, LOVEM-E can be used with other techniquesor technologies.

Your project plan will change depending on the objectives and type of processreengineering. If the objective is to design a new process that replaces anexisting process, then you require a good understanding of the current processdesign, and a solid understanding of the new design objectives. Typically BPRprojects are in one of the following two categories.

Radical BPR projects.

Radical BPR emphasizes breakthrough thinking, and is often driven byexternal needs or opportunities that cannot be achieved simply by alteringthe existing process. Radical BPR is done periodically when conditionswarrant the investment. In radical BPR, you de-emphasize the current wayof doing things, and concentrate on breakthrough diagrams.

Radical BPR projects offer the potential of dramatic improvements, but alsoinvolve high risk and large investments. Although your project sponsormight have asked for radical reengineering, you must pay attention along theway to short term incremental opportunities for improvement. Uncovering

78 Beyond BPR

low risk and low cost opportunities ensures that your BPR project deliversvalue early.

Once you implement a radically new process, the resulting blueprint mustbecome part of the incremental improvement process. With today′saccelerated product development cycles and shorter product life cycles,reengineering is required more frequently. Therefore, organizations need asolid base of process blueprints in place so that reengineering changes canbe made quickly and effectively.

Process redesign projects.

Process redesign projects are similar to radical BPR projects because theyinvolve investment in process engineering and enabling to implement thechange. However, you use a different approach for process redesign thanfor radical BPR. In process redesign, you study the existing processextensively, and alter it based on observation and feedback about theprocess.

You use LOVEM-E to support both endeavors, but the individual techniques areapplied with different emphasis. In process redesign, the As Is blueprints form abase that you use to alter and create the To Be blueprints. So you begin byexamining your As Is blueprints. Look for their weaknesses, then build your ToBe models.

However, in radical BPR, you design the To Be process from a new point ofview. Avoid referring to your As Is processes because these are the processesyou are moving away from. You do not want to be influenced by them, for yourcreativity in developing new processes may become limited. So you approachyour To Be process from a clean slate. Find out what the essential tasks arethat will make your processes work, and from those develop To Be models.

You usually know before you start a project whether its objective is processredesign or radical BPR. In some cases, however, it might become apparentduring an incremental design that the project needs radical reengineering. Ifthis happens, the process redesign team will suggest taking a radical BPRapproach to the project.

6.7.1 Criteria for Choosing Business Process Reengineering or ProcessRedesign

Several criteria influence the type of reengineering you should use. The greaterthe impact to your business, the more you should consider radical BPR.

Criteria to consider are:

• The severity of the problem, such as in customer satisfaction, competitivepressure, or business performance

• Breakthrough opportunities, such as in technology and customer service

• Level of investment planned and required, such as in business objectivesand constraints

• Scope and authority of the process team, such as in level of representationand access to decision makers.


6.7.2 Major Business Process Reengineering RoadmapLOVEM-E has a well-defined process describing the activities for reengineeringmajor projects. This section lists the major activities of reengineering projects.For details on these activities, see the IBM LOVEM-E User′s Guide.

1. Planning phase

• Step 1: Define the problem or opportunity.

− Identify the executive sponsor.− Establish the planning phase exit criteria.− Assign a steering committee.− Understand what your customers need and want.− Create the high-level As Is blueprints.

• Step 2: Scope the project.

− Choose a facilitator and a process analyst.− Hold an initial planning session.− Document the planning session deliverables in a project objectives

document.− Create the overall project plan.− Create change control plans.− Create communication plans.− Create risk assessments.− Complete the planning phase exit checklist.

2. Assessment phase

• Establish the assessment phase exit criteria.• Arrange the facilities.• Choose a facilitator and a process analyst.• Select other participants.• Educate the participants.• Create the more detailed As Is blueprints.• Analyze the problem symptoms.• Perform root cause analyses.• Revisit the focus areas, scope, and objectives.• Document and review all deliverables.• Update the overall project plan.• Create a detailed plan and schedule for the reengineering phase.• Complete the assessment phase exit checklist.

3. Reengineering phase

• Establish the reengineering phase exit criteria.• Arrange the facilities.• Select other participants.• Educate the new participants.• Revisit the risk assessment.• Create the alternative To Be models.• Create high-level business cases for the alternatives.• Select an alternative.• Create detailed blueprints for the selected model.• Prototype the new processes.• Define the systems requirements.• Work with systems development.• Create migration scenarios and the migration plan.• Create a detailed business case for the migration plan.

80 Beyond BPR

• Document and review all deliverables.• Make investment decisions.• Complete the reengineering phase exit checklist.

6.7.3 Documenting As Is ProcessesTo understand the current business environment, you must conduct As Isblueprinting sessions, creating blueprints of your current business, in enoughdetail that you can draw the necessary conclusions. You can achieve this bycreating a set of high-level logical and physical LOVCs while focusing on yourcustomer expectations.

The time spent on As Is blueprinting should be minimal compared to the overallreengineering effort. You can always come back to these blueprints and addmore detail when required.

Whether you have a large project with several action teams, or a smaller projectwith just one team, each team member has to actively participate in creating theblueprints. You cannot afford to have the facilitators and process analyst do allthe work, while other team members act as information resources andreviewers.

With As Is blueprints, you analyze real or perceived problems based oncustomer research information and your blueprints. If not already identified onthe blueprints, add the problem areas to the blueprints and document them withbackup material.

You can follow two steps to create As Is blueprints:

Step 1: Create a logical view.

• Objectives

− To get a stable framework of your current business processesthrough the eyes of your customer

− To assess your current business processes from the point of view ofcustomer satisfaction.

• Activities

At this logical level, you:

− Create As Is ALOVCs and LLOVCs, with documentation− Focus on the service encounters with your customers− Focus on what the process path does, not how it is done− Ignore any constraints, such as organization, time, people, and tools.

• Deliverables

A set of blueprints of your business at the logical level in the form of:

− As Is ALOVCs for your enterprise process path− As Is LLOVCs for showing the process path view for one of several

LOBs− Documentation of service encounters, processes, data requirements,

business rules, policies, strategies, and directions− Benchmarking information in terms of cycle time, process path costs,

transaction volumes, and so on.


Step 2: Create a physical view.

• Objective

To document and understand the factors contributing to how the processpath works.

• Activities

At this physical level, you:

− Create To Be PLOVCs and JLOVCs with documentation− Focus on the service encounters with customers− Add the various constraints such as telephones, electronic data

interchange (EDI), documents and forms, systems, and so on− Add the time it takes to complete the process path, critical

measurement points, problem areas, or other factors that help youunderstand the existing process path and jobs

− Benchmark to understand the performance of the As Is process pathand jobs.

• Deliverables

A set of blueprints of your business at the physical level in the form of:

− As Is PLOVCS of the constrained aspects of the process path− As Is JLOVCs of the actual physical constraints of individual jobs− Documentation of the service encounters, activities, procedures,

information flows and media, process and cycle times, systemsinterfaces, and so on

• Once you have created As Is blueprints of your business, you can usethem for the following:

− Operating your business and making decisions on a day-to-day basis− Improving business processes incrementally, including systems

improvements− Reengineering business processes, including systems reengineering.

6.7.4 Architecting To Be ProcessesThe reengineering, or To Be, phase is the most critical phase for projects thatwill radically change in the business. This phase is also the most difficultbecause you are trying to create a vision of a radically different business thatbreaks all of the current paradigms. The resulting blueprint should reflect aquantum leap improvement in anticipated customer satisfaction and businessperformance.

So you begin the creative part of the reengineering process. By brainstorming,visioning, and using breakthrough thinking, you can create a number of totallydifferent business scenarios that do not resemble your As Is blueprints. Fromthese, you can create a set of different To Be models that represent alternativefuture process paths and jobs. These alternative models need not be completeor detailed, but should capture the most important service encounters with thecustomer, major internal and external interfaces, hand-offs, dependencies, andproposed opportunities for automation.

Once you have selected a model to implement, begin the actual detailed designwork. You can follow two steps to create To Be blueprints:

Step 1: Create a logical view.

82 Beyond BPR

• Objectives

− To get a stable framework of your current design work− To indicate potential radical changes− To define the scope for the reengineering work.

• Activities

At this logical level, you:

− Create To Be ALOVCs and LLOVCs, with documentation− Focus on the service encounters with your customers− Focus on what the process path does, not how it is done− Ignore any constraints, such as organization, time, people, and tools.

• Deliverables

Models and blueprints of your redesigned business process in the formof:

− To Be ALOVCs for your enterprise process path− To Be LLOVCs of your LOB process paths− Documentation of To Be service encounters, processes, data

requirements, business rules, policies, strategies, and directions.

Step 2: Create a physical view.

• Objective

To model and blueprint the factors contributing to how you shouldimplement the new process path and associated jobs.

• Activities

At this physical level, you:

− Create multiple To Be models using high-level PLOVCs and JLOVCswith documentation

− Focus on the service encounters with customers

− Add the various constraints such as telephones, electronic datainterchange (EDI), documents and forms, systems, and so on

− Experiment by modeling alternatives and what-if scenarios beforecommitting to a detailed design and blueprint (the time-consumingpart of the process)

− Add the times it could or should take to perform the new processpath or job to the time line. Place critical measurement points atthose places on the chart where you want measurements to be takenfor customer satisfaction or internal controls

− Create a detailed blueprint of the selected alternative, includingblueprints of all jobs that are required for the new process path

− Indicate systems and skills requirements on the job blueprints.

• Deliverables

Models and detailed blueprints of the new process path in terms of:

− To Be PLOVCS showing all constrained aspects of the process path− To Be JLOVCs showing all actual physical constraints of individual

jobs


− Documentation of the service encounters, activities, procedures,information flows and media, process and cycle times, systemsinterfaces, and so on.

Once you create the various models, you need a high-level business case foreach one showing the costs and benefits, and how and when your organizationcould implement the various models. The To Be models and business cases arethen reviewed and one model is selected for detailed work.

6.7.5 Designing To Be Process ModelsAccording to Hammer and Champy in Reengineering the Corporation, there areno hard and fast rules for performing reengineering because reengineering is asearch for new models that can take many different forms. Which models willnot work is easy to determine. They are usually the models we currently livewith. Which models will work is more difficult to project, unless of course theyhave already been tried. This difficult search leads us to two approaches we canuse to develop effective models, especially when performing process redesign:

• Pattern To Be models from those that have proven to be effective.

A number of organizations have already embarked on reengineering. Youcan draw on the successes of these organizations, especially those from thesame industry as your business, to determine which models you can adopt.

• Perform benchmarks on the different To Be models.

It is best to test your To Be models before you implement them. Results canbe measured and benefits can be quantified.

Designing models for radical reengineering requires more work; however, weknow that the rewards are far greater with radical reengineering. Newprocesses may provide the competitive advantage that will set your organizationapart from the rest. Still, trailblazing with processes that have never been usedbefore entails more risk. It is also more difficult to measure the effects of radicalreengineering because the process yields benefits that are not immediatelyobvious.

We do not claim that we have a proven formula for success. Success dependsheavily on the creativity, resourcefulness, and experience of the peopleperforming the reengineering. However, the graphical representations ofLOVEM-E do have implicit lessons for us to use to arrive at effectivereengineered processes. Let us examine what some of these lessons are:

• Combining tasks within a job band. If different people perform severalconsecutive tasks within a job band, consider reducing, perhaps to one, thenumber of people who perform the tasks. Reducing the number of hand-offswithin a department reduces wait time, resulting in immediate benefits to theLOVEM-E time line. It also increases the familiarity of the worker with thework performed because he or she is exposed to more aspects of the work.In relation to the customer-supplier relationship mentioned in 3.2, “TheCustomer-Supplier Relationship” on page 10, the worker can focus on whatwill satisfy the customer and the conditions that will make the customercontinue negotiations.

• Combining tasks across job bands. When several consecutive tasks acrossdifferent job bands are combined, hand-offs between different jobs arereduced. From practical experience, we know that hand-offs between jobsare the most disruptive. Not only are geographies concerned, but

84 Beyond BPR

philosophies and orientations can differ between jobs. In LOVEM-E, betweencustomer encounters, the relationships of each band are the elements of theentire process. Minimizing internal relationships or bands performing aprocess often improves the quality and speed of delivery of goods andservices to the customer. Thus, combining tasks that span several jobsresults in new jobs with new philosophies and orientations that are morefocused on the customer.

It is not easy to combine tasks within jobs or across several jobs. Theimmediate concern with this effort is the capacity of the worker. However, withthe explosion of information technology, the capacity of workers increases,allowing them to perform much more than they could perform before. It alsoenables workers to do more for customers. Thus proper use of informationtechnology greatly affects the capacity and ability of workers to provide improvedquality and speed in the delivery of goods and services to the customer.

Success Factors

Information technology in reengineering is not merely automating. Rather,radical reengineering becomes possible because of information technology.When performing reengineering, do not use information technology toperform processes faster. Use it to enable radical process changes.


86 Beyond BPR

Chapter 7. Workflow Management

Workflow management provides a set of functions that allow customers to define,validate, execute, manage, and reassess their business processes in anautomated, yet dynamic way. These business processes can be line of businessactivities, for example, contracting for a purchase, the processing of aninsurance claim, managing a lawsuit from start to finish, the steps in applicationdevelopment, or an enterprise-wide management function, such as installing asoftware update.

“Workflow Management is a proactive computer system that manages the flow ofwork among participants, according to a procedure consisting of a number oftasks. It coordinates user and system participants, together with the appropriatedata resources, which may be accessible directly by the system or offline, toachieve defined objectives by set deadlines. The coordination involves passingtasks from participant to participant in correct sequence, ensuring that all fulfillthese required contributions, taking default actions when necessary.”17


7.1, “Application Structures” on page 88

7.2, “Business Reengineering” on page 88

7.3, “Applications” on page 88

7.4, “An Application Integrator” on page 90

7.5, “Three Dimensions of Workflow Definition” on page 90

7.6, “Resource Manager” on page 93

7.7, “Process-Based Application Development” on page 95

7.8, “Workflow-Based Application Development” on page 96

7.9, “Object-Oriented Technology” on page 97

17 OVUM Corporation. 1991.


7.1 Application StructuresIn many companies, valuable process definitions are buried deep within the logicof application programs. Changing a business process means changing theapplication programs, which can be a time-consuming and expensiveprogramming task. With workflow management, programs provide service toprocesses and not vice versa. The application consists of a set of smallprograms or other processes; the sequence of program execution is describedas processes to the workflow resource manager. The workflow resourcemanager controls:

• The flow of control from one program to the next• The data passed along the process• The initiation of programs and manual procedures• The assignment of work to people who perform the work• The capture of status information• Execution history tracking• Restart and recovery.

7.2 Business ReengineeringWorkflow-based applications are typically not created by revamping existingapplications. They are the result of business reengineering, “the fundamentalrethinking and radical redesign of business processes to achieve dramaticimprovements in critical, contemporary measures of performance, such as cost,quality, service, and speed.”18

The result of business reengineering is a well-documented process, which canbe implemented and executed using a workflow management system. Businessreengineering is typically performed by exploiting business modeling tools, suchas those described in Part 3, “Tools for Productivity” on page 99.

7.3 ApplicationsMore than two decades ago, applications were highly dependent upon how datawas organized on a disk. Changes in data organization required changes in allaffected programs. To overcome this so-called data dependency of applications,database management systems were built. When database managementsystems are used, applications become more flexible and less vulnerable tochanges in the data organization.

Similarly, many contemporary applications do not easily allow enterprises tochange their processes. Large application systems contain the code that directlyrepresents these processes so that changing the processes requires changingthe corresponding application systems. While the logic of a particular step of abusiness process belongs to the proper application, the knowledge ofsequencing these steps and distributing them to the responsible organizationalunits makes the application vulnerable with respect to changes of the underlyingbusiness processes: applications can be called flow dependent.

18 Hammer, Michael and Champy, James. Reengineering the Corporation: A Manifesto for Business Revolution. (New York:HarperCollins, 1993).

88 Beyond BPR

Exploiting workflow technology removes the flow dependency of applicationsbecause the task of dispersing work is extracted from the application programs.As a result, applications become more flexible and less vulnerable to changes inthe business processes supported by the applications.

A flow independent application consists of a workflow definition and a set ofprograms that provide function and data services to the workflow definition. Thisallows a new application and technology architecture: the application can be anetworked application, with the application programs running in ageographically-dispersed network consisting of different types and classes ofcomputer systems. The binding of each activity to its supporting applicationprogram occurs at the time of execution based on the definitions in the workflow.

This topology independence is another example of the flexibility offered byworkflow applications. Because the workflow resource manager does notassume any inherent structure between the workflow activities and theirassociated application programs, a workflow application can be implemented ina client/server structure with the client providing information presentationservices and the server supporting the database, application processing, andadministration services. This relationship is shown in Figure 18.

Figure 18. Data and Flow Independence

Finally, application development productivity typically improves whenapplications are developed using workflow management technology. Theprocess model is usually developed more quickly and the initial systemspecification is often of higher quality because of the early involvement of thesystem ′s user in its development. Once the process model has been modeledand defined with the workflow manager, the procedures and data required tosupport the process can be developed. Because the process model is managedby the workflow manager, application programs are typically smaller, lesscomplex, easier to test and therefore, faster to develop and deliver.

Chapter 7. Workf low Management 89

7.4 An Application IntegratorThe workflow resource manager can also be used to link existing applications,even if each was developed independently. Consider a situation where legacyapplications provide most of the desired function but a new business or legalrequirement arises that extends the legacy applications beyond their designpoint. A workflow resource manager can provide a new process model thatcombines the underlying legacy applications, hiding their invocation mechanismsand automatically passing data from one application to the other.

Because the context and state of such an integrated application is persistentdata (for example, data stored in files or database management systems), thehistory of the individual application executions, their order, and their localcontext is tracked. In error situations that require compensation, the systemcan, based on this persistent data, automatically schedule previously definedcompensation steps to correct an error condition.

The coupled applications can run under the control of various transactionmonitors, or as native operating system programs. They can be transactions, ornonrecoverable units. They can run locally, or distributed in heterogeneousenvironments. The workflow management system ties them together, displayingthe middleware facet of workflow management.

7.5 Three Dimensions of Workflow DefinitionTo define enterprise-wide processes involves identifying the actions andactivities of the process, the people, or means that perform the activities and theresources used. The workflow resource manager must support the definition ofprocesses through the following three independent views:

• Processes view (what)• Organizational view (who)• Infrastructure view (which)

7.5.1 The Process View: What Is PerformedA process is described through a number of activities that need to be performedto achieve the desired process outcome (see Figure 19 on page 91).

The activities can be performed by people or resources (where resources couldbe a computer system). The activities are connected by arrows that describe thepotential flow through a process. The decision as to which path to follow isdescribed by transition logic (for example, if the mortgage is greater than$100,000, refer the application to a more senior loan officer).

90 Beyond BPR

Figure 19. A Process Model

A specific process performed according to a process model is called a processinstance (or process for short). It is possible to have many process instances ofthe same process model, each of them with a different status at a point in time.An activity is defined as an action performed at a certain location by a person orresource. At an enterprise level this is the smallest piece of action described ina process model. This activity can then be further divided into its componentfunctions to describe in detail all the actions a person or a computer systemperforms.

This procedure is called refinement and allows a consistent transition fromenterprise processes into software structures or application programs, and theninto tasks, which can be performed by computer systems and people.

This description of a process shows the dynamic behavior or control view of aprocess. To complete the description of a process, the data required by thevarious activities must be defined.

Information has to be provided as input and output after the activity is executed.These information templates are called input and output containers. Activitycontainers hold information handled during a process instance. Programsexecuted as part of the process can access data stored in these containers inaddition to conventional files and databases.


7.5.2 The Organization View: Who PerformsAs part of process modeling, people or resources performing the individualactivities are defined. This organizational view describes the structure of theenterprise (for example, departments, projects, or process teams) and thepeople performing the activities as they are related to the structure. Theinformation about the people includes their skills and the roles they can perform.The organizational information includes rules like escalation (for example, whena process exceeds a predefined threshold) and substitution (for example, whenone team member is unavailable). For each activity, the process modelerdefines who should perform the activity (see Figure 20). This is specified interms of organizational information, which at run time is resolved into a set ofpeople or resources. The association of activities and organizational informationis called staff assignment and the resolution, staff resolution.

Figure 20. Staff Assignment

The information gathered supports combining individuals into process teams;this is a necessary task in a successful process reengineering effort. Forexample, intelligent use of the staff definition is a means for an enterprise tostructure their education plans and guide resource allocation, organizationchanges, and hiring plans. When subsequently applied, the organizationalstructure is changed to reflect the business processes, resulting in a flatter and,oftentimes, more focused organization.

7.5.3 The Infrastructure View: Which Resources Are UsedAn activity (what) is performed by a person or on behalf of a person (who). Theinfrastructure defines which computer system resources are available to performan activity, for example, which program is used and which machine runs theprogram (that is, where the program is executed).

When a person starts an assigned activity, the appropriate informationtechnology resources are determined and allocated. This includes selecting theproper programs, determining the right invocation mechanism, or transferringdata from one server to another. Some of these assignments are performeddynamically, which allows balancing of work and systems.

92 Beyond BPR

7.5.3.1 Combining All ViewsTaking the three views, processes, organizations, and infrastructure, theworkflow can be represented as the navigation through a three-dimensionalspace defined by: what, who, which, which is shown in Figure 21. If a workflowmanager can clearly represent these three dimensions, it can likely providestrong support for the workflows (or enterprise processes represented byworkflows) resulting from reengineering activities. When workflow applicationsystems are devised from document, image handling, or office systems, often thethree dimensions are not clearly separated. This can result in the need to defineand use document status to support navigation within process instances.

Figure 21. The Workflow Cube

7.6 Resource ManagerThe functions supported by the workflow resource manager are delivered by thefollowing components:

• Buildtime− Workflow definition− Animation− Simulation and capacity planning− Import/export of process models

• Runtime− Navigation− Worklist handling− Program invocation− Auditing− Monitoring

• Administration


7.6.1 Buildtime SupportBuildtime supports the definition of process models and the management oforganizational information. In addition, it provides the capability to animate andsimulate those models and organizational structures, and to import and exportthem.

Process models are usually defined with a graphical editor that places activitieson the editor working area and connects them with arrows to represent controland data flow. Some workflow resource managers also offer a workflowdefinition language that provides an alternative to the graphical interface fordefining process models and a mechanism for the exchange of workflowdefinitions between different workflow management systems and businessmodeling tools.

To verify a workflow model, it can be visually animated, a stage in which themodeler navigates through the model and examines the behavior of every singlenavigation step. To predict the total behavior of a workflow management systemwithin an enterprise, it is necessary to simulate the execution of multipleprocesses. This allows the modeler to detect resource constraints anddetermine where improvements in the process model are required. Additionally,simulation can also use data collected from prior process runs.

7.6.2 Runtime SupportRuntime provides the environment and support for the execution of processes.A server component is responsible for navigating the process graphs,performing staff resolution, maintaining the work lists of users, invokingprograms on behalf of users, and generating audit trail information. The serverdoes this for multiple instances of multiple processes. A client componentmanages the user interface work area, the local work list, includingsynchronization with the persistent worklist on the server, and executesprograms on a client′s workstation. It also provides application programminginterfaces (APIs), which allow programs to invoke process-relevant operations,such as starting or terminating a process. A monitoring facility can be used todisplay the status of every process started by the user.

Navigating a process graph and staff assignment is performed by the navigationengine in the process server. It selects the next set of activities to be performedby evaluating the control flow. For each selected activity, it determines thepeople to perform the activity, and makes this information persistent in the database to provide recovery. The worklist function in the server maintains theworklists of all users assigned to the specific server that allows a user to sign onto the workflow resource manager at any supported workstation.

If desired, every action of the workflow resource manager can be recorded as itis executed and stored to provide audit trail information. This record can thenbe used to evaluate the effectiveness of the process and suggest areas forimprovement.

The runtime client has a GUI, which allows the user to start, terminate, suspend,and resume processes, to maintain work lists with work items, and to startactivities. If the selected activity is a computer program, it retrieves the properprogram registration information, determines the data to be made available indata containers, launches the program, and determines the returned informationafter the program is completed.

94 Beyond BPR

If users are assigned to different servers of the workflow resource manager,either complete subprocesses or work items are distributed between the serversresponsible for supporting the involved users.

In the case of distributed work items, navigation through the process isperformed by the workflow resource manager where the process originates. Ifstaff resolution determines that a user is serviced by another workflow resourcemanager server, the target server is responsible for the work item until it hasbeen completed by the user.

For distributed subprocesses the level of distribution is the process. Theoriginating server informs the target server about the process to be started andpasses the process input container to the target server. The process ismanaged by the target server until it is complete. All relevant information isthen passed back to the originating server so that navigation can continue.

7.6.3 AdministrationThe administration of a workflow resource manager is divided into systemadministration and process administration.

System administration deals with managing the basic resources of the workflowresource manager:

• Administration of the database• Management of the organization information• Management of the process models• Distribution of information between multiple workflow resource manager

servers• Management of audit trails.

Process administration deals with managing the tasks associated with processinstances:

• Querying the status of the workflow resource manager servers (activeprocess instances, number of work items assigned)

• Reassigning work items for balancing work load• Monitoring the status of exception situations.

7.7 Process-Based Application DevelopmentThe three major components of a process model consist of the flow of controland data between its activities, the distribution of each activity to its responsibleorganization unit, and the linkage of each activity to its supporting computerprogram. The computer programs implement the basic functions of theunderlying business process and usually provide a distinct function such assupport for a single business rule or database access.

When the workflow paradigm is adopted as the fundamental applicationstructure, the business users of the new system are typically involved with theanalysis of the business process and identifying the support required bycomputer systems. A business modeling tool allows them to describe businessprocesses without any data-processing terminology, and in terms relevant totheir area of expertise, like critical success factors, process goals, qualitymeasures, and required resources.


7.8 Workflow-Based Application DevelopmentAs shown in Figure 22 on page 97, developing workflow applications generallystarts with business modeling. A business modeling tool captures, for example,information about the actions that build a process, the business objects that aremanipulated by the actions, possible sequencing of actions, and responsibleorganization units. Thus workflow-relevant information can be derivedautomatically and put into a workflow management system as a processtemplate. This process template is then refined into a complete process modelby using the buildtime component of the workflow management system.

When refining the process template into a process model, some actions capturedin the business modeling tool will be further refined in subprocesses whileothers will become activities that are directly associated with programs. Someof these programs will already exist and some need to be written. For newlywritten programs, the workflow manager helps with different tools to buildprograms that fit smoothly into the workflow manager′s runtime environment.For example, visual builders can be exploited for composing programs fromparts, a program modeling tool supporting a contemporary methodology can beused for the construction of more complicated programs, or a program can evenmodel regular activities. The workflow manager will then request from the userthe acknowledgement that the manual task has been completed successfully.

A business modeling tool also develops targets for a new process, for example,expected duration and total cost. These goals can then be translated intoprocess execution activities that are recorded in an audit log. Based on theaudit log, a process performance monitor provides a statistical analysis of theperformance of process instances. This process feedback information can beused as the basis for process improvement activities or to initiate a new cycle ofprocess modeling.

Similarly, business objects captured by the business modeling tool can betransformed into entities of a data modeling tool. These entities can be refinedinto conceptual data models for the various business areas supported by thetargeted business processes. Because each local conceptual data model can beperceived as the view of a business area in the enterprise data model, a viewintegration tool supports the combination of business area data models into anenterprise data model. Input and output containers of activities can be modeledas views onto the organization data model. Based on the relationship betweenthe organization data model and a relational database, database definitionsoftware can be generated, which retrieves and stores container instances inrelational databases.

96 Beyond BPR

Figure 22. Process-Based Application Development

7.8.1 Process VerificationThe correct and efficient execution of processes is vital for the successfuloperation of the enterprise. An animation tool allows the verification of processlogic. This is done by simulating the control flow, the data flow, and the flowbetween the affected organization units of a single instance of one processmodel.

If the process model is considered a correct representation of the process logic,a simulation tool can help verify whether the process, as designed andimplemented, will meet its targets when stressed with volumes similar toexpected production volumes.

Once the process model is in production various execution measurements canbe monitored. The process performance monitor will collect and represent theactual and the statistical behavior of the processes. The results can indicate thenecessity of ongoing reengineering work because of deviation from targetprocess goals.

7.9 Object-Oriented TechnologyEnterprises today invest in object-oriented technology to improve the productivityof their programmers and to enable business professionals to build applications.The building of applications will become more and more component-based.

Object technology and workflow technology are two complementarytechnologies: one can exploit the other in a variety of ways, resulting in


synergies that are equally valuable to both, but they can also coexist so thateach technology has its own area where it can be applied without the other.

Coexistence means the workflow resource manager executes programs writtenin an object-oriented programming language. The workflow resource managerstarts programs through a variety of means. For example, the workflow resourcemanager can invoke programs provided as executable files, scripts, or entrypoints in dynamic link libraries (DLLs), CICS, IMS transactions, or messagequeue applications. Because the way a program is constructed is irrelevant tothese invocation mechanisms, the workflow manager can start the correspondingprogram regardless of whether they are written in a third generation language(3GL), fourth generation language (4GL), or object-oriented (OO) programminglanguage.

If the encapsulation feature of object-oriented technology is used, the details ofthe business process can be hidden in the object-oriented application′s classesand methods. As a consequence, the business process becomes dependent onthe application′s process model and is not explicitly described and madeavailable to a broader community.

However, object-oriented technology can provide business object componentsfor application construction which can be directly integrated into the businessprocess by the workflow resource manager. The workflow resource managermaintains the application′s process model and controls how, when, and bywhom the services provided by the various business objects are exploited. Thisapproach preserves the application development benefits of a workflow resourcemanager while at the same time leveraging OO technology components.

If System Object Model (SOM) technology is used to construct business objects,they may be used directly by the workflow resource manager through its abilityto invoke SOM object methods directly. When extended by distributed SOM(DSOM), the location of the SOM object becomes irrelevant to the workflowresource manager.

A business object can communicate in an object-oriented manner with theworkflow resource manager in order to influence the navigation through thebusiness process to which the business object belongs. A workflow frameworkthat provides services as objects allows for that. Again, exploiting SOMtechnology for this can be beneficial because of language neutrality and binarycompatibility.

98 Beyond BPR

Part 3. Tools for Productivity


100 Beyond BPR

Chapter 8. Business Modeling Tool

We have covered the IBM LOVEM-E and workflow management concepts. In thischapter, we present the IBM Business Modeling Tool (BMT), which captures theLOVCs and other important information about your business processes. Usingsome of this information, BMT also allows you to generate workflow scripts.


8.1, “Basic Activities of the Business Modeling Tool” on page 102

8.2, “Using Business Modeling Tool” on page 103

8.3, “Generating Workflow Scripts” on page 109

8.4, “Complementary Modeling Techniques” on page 111


8.1 Basic Activities of the Business Modeling ToolTo stay competitive, most companies need to improve customer service, reducecycle time, use resources efficiently, reduce costs, boost employee morale, andencourage teamwork. One way to achieve these goals is for companies toperfect their business processes.

BMT is a design and analysis tool based on LOVEM-E. Business consultants andbusiness analysts use BMT to help companies first analyze, then improve orreengineer their business processes.

BMT shows companies how customers see and experience their businessprocesses, as a first step toward improving customer service. BMT helps tovisualize, document, and analyze a business process to reveal defects such asextended cycle times, high costs, wasted resources, and insufficient employeeskills.

8.1.1 Gathering InformationFirst the information about a business process must be gathered. Then theinformation, including roles of departments and activities involved, customersatisfaction, control parameters, conditions, and generated goods, is put intoBMT charts and notebooks.

This information, also available in report form, shows key indicators such ascycle times, costs, opportunities, problems, or goals. A complete set of chartsand reports can identify delays, bottlenecks, or other problem areas in aprocess.

8.1.2 Modeling Business ProcessesAll LOVCs show customer processes or activities, a line of visibility, andcompany departments or process stages. They can also show boundariesbetween manual and automated activities, lengths of time, and business objects,such as activities, tasks, and information flows.

Using BMT, consultants can construct a business process from the top down, thebottom up, or both.

Top down approach:

The top down approach assumes that you already know which charts you needto analyze a business process. This approach consists of the following steps:

1. Create a chart of a business process.

2. Add process path elements to the chart.

3. Define each element in the chart.

Bottom up approach:

The bottom up approach assumes that you already know which activities,information flows, critical success factors, and other elements make up theprocess path you are modeling. This approach consists of the following steps:

1. Define each process path element.

2. Create a chart and add elements to the chart.

102 Beyond BPR

3. Retrieve the specific elements created earlier and assign them to theelements you just added to the chart.

8.1.3 Analyzing, Improving, and Monitoring the ProcessIn a typical analysis of a business process, consultants or analysts first createALOVCs and LLOVCs for an overall view of what the company does.Consultants also create logical transformation lists (LTLs) to transformprocesses into activities. They then create As Is and To Be PLOVCs, in whichthe processes and subprocesses of an ALOVC or LLOVC become real activitiesand tasks performed in real departments. Finally, consultants create As Is andTo Be JLOVCs to analyze each individual job.

Throughout the entire reengineering exercise, the consultants build hierarchicalstructure diagrams (HSDs) to view the structure of processes and activities.

At the end of the assessment phase, consultants confer with analysts and thereengineering team to recommend possible ways to achieve short-term andlong-term goals. Company executives review the charts and reports, considerthe recommendations, and then decide what steps to take toward improving orreengineering the process.

Business process reengineering does not end with the implementation of areengineered or an improved process; it is an ongoing procedure. To staycompetitive, a company must continue to measure key indicators and monitor itsprocesses systematically. Regular measurement and monitoring ensure thatcurrent goals are met and new goals within reach.

Consultants also use the As Is charts of the new process to check against theold To Be blueprint to show how the improved or reengineered process isperforming and where adjustments are required.

8.2 Using Business Modeling ToolIf you have used BMT before, there will be a file cabinet icon for each businessmodel. The first time you start BMT, there will only be the sample modeldelivered with the product. Figure 23 on page 104 shows the mortgageapplication model in the Business Models window.

Chapter 8. Business Modeling Tool 103

Figure 23. Business Models Window

8.2.1 Business ModelsBusiness Models contains a variety of objects, arranged in a tree view.Figure 24 on page 105 illustrates the mortgage application tree view with theCharts object expanded. Business Models contains the following types ofobjects:

Charts LLOVCs, PLOVCs, JLOVCs, and Other Charts

HSDs Decomposition diagrams of goals, activities, and criticalsuccess factors, for example.

Organizations Elements of a process path that represent customerprocedures, business functions, business areas,departments, and jobs on LOVCs. Organizations that youdefine in notebooks appear as bands on LOVCs.

Logical objects Elements of a process path used in physical models, suchas customer activities, activities, information flows, andsystems.

Assignable objects Controls that you can assign to process path elements:AIRs, critical success factors, goals, metrics, opportunityareas, policies, problem areas, and strategies.

104 Beyond BPR

Figure 24. Mortgage Application Tree View

To work on an object:

1. Select plus ( + ) signs to expand the tree until you reach the object on whichyou want to work.

2. Double-click on a specific object to open its notebook or double-click on achart object to define bands for the chart and start the Editor.

The Editor window is the drawing tool where you build the different LOVCs.Following the steps described in Business Modeling Tool: User′s Guide, you cancreate all of the LOVCs of the Universal Trust Company that we studied inChapter 6, “Business Process Reengineering Using IBM′s Enhanced Line ofVisibility Engineering Methodology” on page 49. The Editor window consists ofthe following areas (see Figure 25 on page 106):

Menu bar From the menu bar, you can use the Chart, Selected, Edit,View, Symbols, Options, and Help menus.

Tool bar Select a tool bar icon to perform such activities as savingthe chart, printing the current chart, cutting, pasting,copying, undoing, enlarging or reducing the scale of achart, fitting the chart into one window, displaying thechart at the default scale, and getting help.

Symbol palette The symbols displayed in the symbol palette are differentfor each chart type. Exactly where on a chart you canplace a symbol also depends on the type of chart you areusing.


Drawing area The drawing area is where you create and update chartsby selecting and manipulating symbols.

Band area On LOVCs, the left side of the drawing is the band area.To find out which symbols are allowed in a certain band,click mouse button 2 on an empty space inside that bandon the right side of the drawing area. Select Symbols fromthe menu and the allowed symbols will be highlighted.

Status area This area contains several fields below the drawing areathat display status information for the user, such as whathas just happened or what to do next, scale of the currentchart, and type of chart.

Figure 25. Editor Window for JLOVC

Additional general information on the BMT Editor can be found in the discussionof working with BMT in the BMT User′s Guide. When you have finished, you

106 Beyond BPR

should have the LOVCs shown in Figure 14 on page 60, Figure 15 on page 65,Figure 16 on page 68, and Figure 17 on page 73.

Charting Dos and Don′ts

Use the following guidelines to create LOVCs:

• Keep them simple.• Use the real names of all components.• Use one symbol per activity, system, or system function.• Use common and well-defined terms and definitions.• Connect all processes or activities in the path in sequence.• Describe each component on the chart for future reference.• On LLOVCs, ensure that each process receives and generates a flow of

data.• On PLOVCs and JLOVCs, ensure that each activity receives and

generates a flow of information, goods, or control.• Ensure that a process receives the input required from a data flow to

produce the expected output.• Ensure that an activity receives the input required from an information,

goods, or control flow to produce the expected output.

8.2.2 Using the Export FacilityBMT lets you share the charts you make with other graphics software. BMTachieves this by providing an export feature that produces output files in fourcommon formats. These formats, shown in Figure 26 on page 108, are:

• OS/2 bitmap• Windows bitmap• TIFF• PCX• FlowMark FDL• Spreadsheet


Figure 26. Export Options Pop-Up Menu

This feature is valuable for incorporating the charts you just made intopresentations. Support for TIFF, a popular imaging format, is also useful forintegrating your charts with imaging applications. This means that companieswith an imaging system installed can allow their staff to share BMT charts. TheIBM VisualInfo and the IBM Visual Document Library, two of IBM′s imaging anddocument management software products, support TIFF.

8.2.3 Using the LOVCs of BMTIn 6.1.1, “Use” on page 50, we discussed five major applications of LOVCs.Using BMT addresses the following reasons:

• Creating a blueprint of your current business

Creating a blueprint of the current business is not an easy task. A lot ofresearch has to be done and this takes some time. It may take severaliterations to capture the processes your organization has and to understandhow these processes handle information. More effort is required if yourprocesses span several roles, departments, or jobs. By storing your LOVCin BMT, you preserve all your efforts as you build your As Is blueprint overtime.

BMT integrity checking also helps minimize errors in creating LOVCs. Byproviding immediate feedback, rework is minimized, resulting in fasterdevelopment of the current business blueprint.

• Supporting reengineering efforts

Reengineering requires a fair amount of modeling. Several To Be modelsare drawn by BMT to determine the best way of performing businessprocesses that satisfy the customer. Modeling in BMT can be performed

108 Beyond BPR

faster since charts can be replicated and modified to create alternativemodels. Therefore, the total reengineering time is shortened.

BMT integrity checking also helps minimize modeling errors. By providingimmediate feedback, rework is minimized resulting in faster development ofreengineered business models.

• Using the IBM LOVEM-E blueprints as a common specification language

As mentioned previously, BMT allows you to create clear and consistentLOVCs. By performing integrity checks when building charts, BMT helps youavoid charts that are confusing and inconsistent.

BMT allows you to communicate the LOVCs using other software through theexport facility. By incorporating your LOVCs in other presentation softwareyou can add more messages and techniques in communicating your LOVCs.

BMT allows a company with an imaging system to easily access the LOVCs.By providing the facility to export in TIFF format, BMT enables imagingsoftwares to access LOVCs. This lets more people in the organization viewand understand the company′s LOVCs.

8.3 Generating Workflow ScriptsIn 6.1.1, “Use” on page 50, we also discussed that a reason for creating LOVCsis to design workflow solutions. This section presents how BMT supportsdesigning of workflow solutions with LOVCs. A more detailed discussion onworkflow solutions is covered in Chapter 10, “FlowMark” on page 149.

In 7.8, “Workflow-Based Application Development” on page 96, we discussedthat developing workflow applications generally starts with business modeling.In this case, after having created our LOVCs, BMT has already capturedinformation about the actions that build the processes, the business objects thatare manipulated by the actions, the sequence of the actions, and the responsibleorganization units. BMT capitalizes on the information it has stored by providingthe facility to generate the FlowMark definition language (FDL). Thus,workflow-relevant information can be derived automatically and put intoFlowMark as a process template.

8.3.1 FlowMark and the FlowMark Definition LanguageFlowMark is the IBM workflow management solution that controls the executionof business processes. FlowMark provides functions for the interactive definitionof process models, for their testing with graphical animation, for the execution ofworkflows by automatically interpreting the process models, for helping endusers manage their work via work lists, and for the recording of execution-timeparameters for the purpose of analyzing processes after execution.

The process models defining the workflows are graphically represented byFlowMark as networks of activities. Each activity is described by assigning arole, the required program or tool to carry out the activity, and data to bemanipulated by the program. These attributes are stored in a FlowMarkdatabase.

The FlowMark workflow manager provides an export utility program to retrieveany of the definitions that you store in a FlowMark database and generates anASCII text file, in an external format called FlowMark definition language (FDL),containing these definitions.


Inversely, FlowMark provides an import utility to read FDL and create definitionsin its FlowMark database that define part or all of your workflow model. Fromthis, you can use the FlowMark functions to test and execute the workflow model.This is the utility for which BMT generates FDL.

8.3.2 BMT Generation of FlowMark Definition LanguageSince FlowMark executes actual business processes, BMT generates FDL fromphysical charts. Only PLOVCs and JLOVCs can produce FDL.

To generate FDL, you have to create all the PLOVCs and JLOVCs of the processpath you are interested in. You should ensure that each activity and informationflow has at least an identifier and a name. When entering this information, youcan reuse already-defined objects by using the Find function if you areemploying the bottom up approach (see 8.1.2, “Modeling Business Processes”on page 102). You also need to enter the band names representing the differentjobs in the PLOVCs and JLOVCs.

Having the information from the physical charts, BMT performs the followingwhen generating FDL:

1. Gets the active PLOVC or JLOVC in the BMT editor

2. Builds the PLOVC/JLOVC hierarchy and get all the affected PLOVCs andJLOVCs

This is because PLOVCs can contain PLOVCs and JLOVCs, and JLOVCs cancontain JLOVCs.

3. Extracts the involved PLOVC and JLOVC objects to create corresponding FDLscripts

4. Arranges the FDL scripts in the proper format

5. Saves the FDL script using the filename of the active PLOVC/JLOVC with thefdl extension.

BMT checks the FDL script before generating it, to make the import procedure aserror free as possible. To produce a successful FDL generation, you shouldhave at least IDs and names in all your symbols, and program names (found inthe program tab) of the system symbols.

Also, when importing an FDL file, make sure that your BMT symbol names donot have apostrophes in them. When you generate FDLs, BMT encapsulates thenames with single quotation marks. During the import procedure, whenFlowMark reads the names, it looks for the FDL single quotation marks beforeand after the name and extracts the name within. If there is an apostrophe inthe name, the FDL would confuse FlowMark and result in an error. If there areapostrophes in the names in the generated FDL, either remove them from theBMT symbols and generate another FDL, or edit the generated FDL file anddelete the apostrophes in the name, leaving only the FDL single quotation marksbefore and after the name.

In FlowMark, you need to access the FDL file generated by BMT and import it tothe FlowMark database. From there, you can now test and execute the processmodel.

110 Beyond BPR

8.3.3 From LOVCs to FlowMark Definition LanguageWhen reengineering, once you select your To Be model you can have certainportions of your business processes implemented in a workflow. With thePLOVCs and JLOVCs of these business processes you created, BMT generatesFDLs to be imported to the FlowMark database. From there you can immediatelytest and execute your business process models.

This integration between BMT and FlowMark allows you to implement yourbusiness processes immediately and at a lower cost. BMT automatically createsFDL, an output format that FlowMark can read to build and run business processmodels. No additional conversion of output needs to done. Therefore, yourbusiness reengineering cycle time will be reduced, allowing your businessorganization to provide enhanced products and services and improve customersatisfaction at the earliest possible time. Also, no additional tools arenecessary. This minimizes your business reengineering costs.

8.4 Complementary Modeling TechniquesBMT currently supports the complementary modeling technique, the hierarchicalstructure diagram (HSD) in an automated fashion, and allows for the manualcreation of logical transformation lists (LTLs) using the Other Charts object of theBusiness Modeling Tool. This section shows how you can use HSDs in BMT.

8.4.1 BMT Hierarchical Structure DiagramThe hierarchical structure diagram (HSD) allows you to decompose certainLOVEM-E symbols into greater detail. It provides a convenient way tounderstand the components of a process or organization design. You can use itat any level of abstraction or detail.

With BMT, you can use this tree structure to access any of the models orblueprints directly, thus obtaining a graphical table of contents of your LOVEM-Emodels and blueprints.

You can create HSDs for the following in BMT:

• Activities• Critical success factors• Goals• Processes• Systems

Figure 27 on page 112 shows the HSD choices in the Tree View for themortgage model.


Figure 27. Hierarchical Structure Diagram Choices

HSD LOVCs have a tight coupling to their related LOVCs. For example, if youstart with a PLOVC (PLOV1) and add another PLOVC (PLOV2) and a JLOVC(JLOV1) symbol in it, this is displayed in the HSD LOVC as shown in Figure 28.

Figure 28. Hierarchical Structure Diagram LOVC Example

Similarly, HSD activities have a tight coupling to their related LOVCs. Forexample, if you start with a PLOVC1 and add Activity11, Activity12, and PLOVC2,and in PLOVC2 you add Activity21, JLOVC2, and Activity22, this is reflected in theHSD activity chart as shown in Figure 29 on page 113.

112 Beyond BPR

Figure 29. Hierarchical Structure Diagram Activity Example

HSD critical success factors and goals are used for accumulative decompositionand are not coupled to LOVCs. This is the same for HSD organization units,because you can add bands (organizational units) from different organizationallevels to a PLOVC. HSD is used to do a functional decomposition of systemsinto subsystems and system functions.

Summary

HSDs help in providing greater detail about some of the objects in BMT.HSDs also show the relationship with other objects, giving you a betterperspective of the elements of the business processes of an organization.

8.4.2 BMT Logical Transformation ListThe logical transformation list (LTL) forms a bridge between the logical and thephysical models. Using the LTL, you can build physical implementationscenarios for logical processes on an ALOVC, LLOVC, or logical HSD. Forexample, the logical process, enter order, can be implemented in many differentways. It can be:

• Fully automated, using EDI or some other automated ordering system

• Completely manual, where you write the order either directly, or copy it froman order form, into an order file

• A combination of automated and manual procedures, such as typing theorder from an order form into an order system.


The LTL is used for logical-to-physical transformation. It is an integral part of atop-down design process. You start with logical models, which you transforminto various implementation scenarios before building physical models and finalblueprints. LTLs are created in the Other Charts object of the BMT editor.

• All manual

You can implement the logical process verify mortgage data completelymanually by performing the following activities:

− Compare customer information to customer file− Tick off each correct field− Phone customer (for correct information)− Phone branch loan officer (for correct information)− Correct the application (if there was an error)− Correct the customer file (if there was an error).

• All automated

You can fully automate the same logical process through the followingsystem functions:

− Compare customer information to customer file− Inform the customer whether it is OK or not OK− Add to pending file (if not OK)− Update the customer file (if information is not correct)− Update the application (if information is not correct)− Add to log file.

• Part manual and part automated.

You can implement the same logical process through the following manualactivities and system functions:

− Manual activities

- Enter customer information- Phone customer (for correct information)- Phone branch loan officer (for correct information)- Enter correct information.

− System functions

- Compare customer information to customer file- Display OK/Not OK- Update customer file (if not OK)- Update application (if not OK).

You now create design alternatives for each scenario. For each alternative, listthe activities and the system functions that you need to perform the logicalprocess.

Once you decide which implementation scenario is the most suitable, you canuse the activities and system functions from the LTL to populate your physicalmodels.

114 Beyond BPR

Success Factor

The logical-to-physical transformation requires experience in business andsystems design. It also requires an understanding of what is feasible from atechnology, cultural, or financial point of view.

Summary

The LTL is used to transform logical processes into physical designalternatives. These can be all manual, or all automated, or partly manual andpartly automated. Performing the logical-to-physical transformation requiresbusiness and systems design skills. The BMT LTL capability has no formalstructure; it is simply a blank canvas to draw upon.


116 Beyond BPR

Chapter 9. VisualAge Requirements Tool

VisualAge Requirements Tool is a tool that helps business users discover thesystem functions they need to support their processes. Through a highlyintuitive visual representation scheme, VisualAge Requirements Tool letsbusiness and systems professionals jointly define system requirements from abusiness perspective.

In previous chapters, we described a method for business process engineering,LOVEM-E, and a tool, BMT, that supports the method′s documentationrequirements. You may have noticed that business process modeling focusesprimarily on activities, the people who perform them, and the time required tocomplete a single iteration of the process. Analysis of the detailed functionalrequirements of the activities that the process team performs is often consideredout of scope or reserved for a later stage in the reengineering project.

In this chapter, we explore VisualAge Requirements Tool and how it integrateswith LOVEM-E and BMT to rapidly develop specifications of the system-relatedactivities identified during business process modeling. This chapter consists ofthe following topics:

9.1, “Introducing VisualAge Requirements Tool” on page 118

9.2, “Business Objects” on page 122

9.3, “Associations” on page 123

9.4, “The User Requirement Statement” on page 124

9.5, “Positioning” on page 124

9.6, “Business Operation” on page 126

9.7, “Business Transactions” on page 128

9.8, “Business Rules” on page 132

9.9, “Business Information” on page 140

9.10, “Business Facts” on page 143

9.11, “Data Consolidation” on page 144

9.12, “Review Requirements Statements with Users” on page 145

9.13, “VisualAge Requirements Tool Reports” on page 145


9.1 Introducing VisualAge Requirements ToolVisualAge Requirements Tool provides a rich and extensive set of graphicalrepresentations that you can select, modify, and manipulate.

You can view graphical representations that dynamically change as you changethe specification of the business object. You can use the mouse, or otherpointing device, to easily view and change the view of your business operations.You can quickly browse views of business elements, scan complex graphs bypositioning and zooming, and tailor your views according to your immediateneeds.

VisualAge Requirements Tool helps you identify the elements of a businessoperation and document their interconnections and then explore the behavior ofthat business operation. It makes it easy to collect and enter key operationaldata about your enterprise and presents that data in clear dynamic graphics foryou to study and validate.

To record and represent operational behavior, VisualAge Requirements Tooluses new technologies in analysis, storage, and presentation that were notavailable a few years ago. VisualAge Requirements Tool hides the computertechnology and presents descriptions of business behavior in your terms, usingbusiness constructs.

You do not have to learn a special language to use VisualAge RequirementsTool. You can identify, describe, and view business-user requirements in yourlanguage, not a computer′s.

9.1.1 AdvantagesVisualAge Requirements Tool provides the following advantages:

• Quick, easy creation of the business objects to prepare user requirementstatements. Objects are presented in easy-to-identify icons, attributes arespecified and displayed in easy-to-use online notebooks, and associationsare depicted graphically.

• Facilities to view different aspects of the information graphically.

• Instantaneous updating of all VisualAge Requirements Tool views. As soonas you make a change in one VisualAge Requirements Tool view, it isimmediately propagated throughout the entire business operation. All viewsalways reflect the current state of your requirement statements.

• Business operations to delimit the scope within a portion of the business.Operations can be imbedded within operations to allow systemdecomposition, including very large systems and client/server functionaldistribution.

• Classification of business rules to facilitate their discovery and retrieval.

• A business fact dictionary to manage names and structures of businessfacts, which provide a large part of the business enterprise terminology.

• User-controlled completeness indicators, which can be queried to manageyour progress.

• An annotation facility for reviewers to comment on business elements.

• Powerful, but easy-to-formulate and easy-to-use, queries about allassociations.

118 Beyond BPR

• Management of connections to implementation elements for reuse andimpact analysis.

9.1.2 UsesBusiness changes typically drive the need for changes in business operationsand the corresponding changes in user requirements. During the businesscycle, need for change is identified, requirements are specified, applications areimplemented, and then the modified operation is used in production.

VisualAge Requirements Tool helps you to quickly and accurately define userrequirements for the business operations and communicate those requirementseffectively to system developers. Additionally, system developers can useVisualAge Requirements Tool data to better plan, develop, and test the businessoperations. VisualAge Requirements Tool provides a basis for evolutionarychange and element reuse.

9.1.2.1 Help Users Determine Their RequirementsVisualAge Requirements Tool helps you determine what you want the system todo with regard to business operations.

Although users are often dissatisfied with the systems that support them, theycannot communicate their needs in a form comprehensible to systemdevelopers. Users and developers have trouble communicating. Thisbreakdown in communication causes the development of systems that do notmeet the user′s expectations.

Users have a hard time specifying systems ahead of time because the insertionof a new system in their business operations alters those business operations inways that are hard to anticipate, generating additional requirements and makingsome of the system′s functions obsolete.

VisualAge Requirements Tool emphasizes function, or system behavior, ratherthan the user interface. VisualAge Requirements Tool identifies the system′sservices through the concept of business transactions and the behavior of thoseservices through the concepts of business rules and business information.

Once the requirements are specified, business users can use VisualAgeRequirements Tool to simulate the behavior of each of the specified services andevaluate them from a business viewpoint.

With VisualAge Requirements Tool, you can represent and analyze systembehavior without prototyping. VisualAge Requirements Tool helps managecompleteness and consistency of the requirements, thus enhancing theconfidence level in the specification. Reviewers can easily view and commenton VisualAge Requirements Tool specifications online. You can make changeseasily so reviewers can validate them quickly.

9.1.2.2 Help Users Specify Required System BehaviorThe behavior of a business operation is a key element of user requirements, andVisualAge Requirements Tool helps you specify this behavior.

The same information that you need to discover your requirements is used torecord those requirements. No time is lost restructuring the information neededto discover and understand behavior requirements into the specification ofbehavior.

Chapter 9. VisualAge Requirements Tool 119

The support of VisualAge Requirements Tool for user-managed completenesslends confidence that the specifications represent what is really needed.

9.1.2.3 Help Users Communicate Their RequirementsVisualAge Requirements Tool provides you with a semiformal representation ofsystem behavior to use as the means of communicating with your colleaguesand system developers.

Once you understand the requirements, you have to express them in aconsistent manner for use by information technology analysts. Traditionally, inthe application development process this step is called analysis.

In application development, business users work in what is called the problemdomain, and system personnel work in the solution domain. These domainshave their own terminology and conventions. VisualAge Requirements Tool isdesigned to work at the boundaries of these domains and useseasy-to-understand terminology that both groups can comprehend. VisualAgeRequirements Tool users define business elements by introducing theterminology of their choice to describe operational and behavioral aspects oftheir requirements specification.

The same VisualAge Requirements Tool information used to describe thebusiness requirements is used to express the results of the analysis phase ofapplication development.

9.1.2.4 Give Developers Requirements They Can UnderstandVisualAge Requirements Tool provides system developers with behavioralrequirements specifications that they can use for system analysis. Theinformation displayed by VisualAge Requirements Tool conveys analysis resultsthat meet various application development needs:

• VisualAge Requirements Tool provides the following elements for datadesign:

− Identification of entities (business information) and their attributes(business facts)

− Identification of relationships (associations) between entities

− Constraints on these entities (business rule defines associations).

• VisualAge Requirements Tool provides the following elements for proceduralprogram design:

− Identification of all required program functions (groups of businesstransactions that are connected through business rules)

− Specification of the program functions (business rules and their dataretrieval and update requirements)

− Program function reuse (support for business rule uses business ruleassociations).

• VisualAge Requirements Tool provides the following elements forobject-oriented design:

− Identification of use cases and user roles (business transactions andtheir user role presentations)

120 Beyond BPR

− Identification of business object classes (business information), theirstates (attribute and business rule defines associations), theirassociations (depends associations), and methods (business rules).

− Identification of function sequencing classes (business transactions andthe sequence of business rules they trigger).

9.1.2.5 Give Developers Requirements Useful for Planning TestsVisualAge Requirements Tool provides system developers with a behavioralrequirements specification they can use to develop functional verification testplans.

During functional verification, system developers show system users (businesspersonnel) that the functions specified in the requirements statement aresatisfied by the proposed system update. VisualAge Requirements Tool providesa clear way to show this evolution from requirements to system.

Every business transaction should have test cases that show every possiblebehavior as determined by the specified business rules. Behavior is simple toexpress because the results of an input transaction are the output transactionsthat it produces and the effects on the system′s persistent memory (businessinformation). Business rules control both the output transactions and the effectson business information.

For every input transaction, testers should create test cases that exercise everycondition dictated by the business rules. Test cases should ensure that theappropriate business transactions are produced and the business informationreflects the appropriate changes.

9.1.2.6 Give Developers Requirements Helpful for Cost EstimatingVisualAge Requirements Tool provides system developers with a behavioralrequirements specification they can use to calculate function points and thusdevelop an early cost estimate for the new system.

The elements in the VisualAge Requirements Tool model provide sufficientinformation to calculate function points. The function point method derives asingle number that expresses the functional contents of a system. That numberis calculated by identifying all input and output (business transactions), dataaccesses (business rules that use business information), and databases or files(business information). An analyst gives each of these elements a complexityfactor, and the numbers are added up by category. The totals for each categoryare multiplied by a weighting factor, and all numbers are added again to derivethe final function point estimation.

9.1.2.7 Provide Basis for System Evolutionary ChangesVisualAge Requirements Tool provides a basis for a business operation′sevolutionary changes involving both business and system personnel.

A business operation developed with VisualAge Requirements Tool to expressrequirements is well positioned for future changes and evolution. New functionsare represented as new business transactions. Existing business rules mayalready support those transactions. You can validate new behavior bycomparing it with existing behavior.


You can analyze affected business rules to identify changes in existing businesstransactions. You can analyze functional changes at the business level toevaluate the total impact on the business operation.

These activities, coupled with the function point calculations, provide a solidbase for making decisions relating to function and cost. You can do what-ifevaluations using the information presented by VisualAge Requirements Tool.

9.1.2.8 Map Business Requirements to Implementation ElementsBusiness transactions identify the need for interchange between the user andthe business operation. The actual implementation of the interchange can beachieved in many different ways—through a business form, a computer screen,or with a mouse interaction. VisualAge Requirements Tool provides the linkbetween the business requirement function and the implementation elementsthat support them.

Requirements drive the function provided by the system. Implementationelements are created to support requirement elements, and the elements mustcorrespond. For example:

• Business transactions might correspond to graphical user interfaces (GUIs),screens of nonprogrammable terminals (NPTs), CICS transactions, IMStransactions, or printed reports.

• Business rules might correspond to program modules, program procedures,or data constraints.

• Business information might correspond to databases or data files.

VisualAge Requirements Tool tracks these correspondences and makes reuseand impact analysis a reality for the business user and the system developer.You can tell where business rules are implemented and quickly change them tosupport the evolution of the business.

With VisualAge Requirements Tool, development effort to make parts reusablepays off because parts are visible and easy to find.

9.2 Business ObjectsVisualAge Requirements Tool uses only a few basic business elements to recordand display business operations. Collectively, these elements are businessobjects. The primary business object is the business operation.

The business objects used by VisualAge Requirements Tool include:

Business operation A delineated part of a business enterprise that reflects abusiness process that is manual, automated, or both. Abusiness operation is a functional grouping of businessobjects. It can group other business operations, businesstransactions, business rules, business information, andbusiness facts.

Examples: accounts receivable, accounts payable,inventory processing, payroll, quality control

Business transaction The interactions between users and the business operationunder study. Users include people and other businessoperations.

122 Beyond BPR

Examples: order quotation request, customer qualificationapplication, order quotation report

Business rule The behavior of a business operation. Business rulesdetail what is done and under what conditions duringprocessing in a business operation. Business rules can beclassified by the activities that businesses perform tohandle their business objects effectively.

Examples: create quotation, define order, define item,define customer, define order quotation report.

Business information Persistent data maintained by a business operationreflecting external business objects.

Examples: customer, order, item

Business fact A discrete data element or a composite of various dataelements. A business fact can be included in otherbusiness facts, as well as in business transactions andbusiness information. Business facts are relevant to allbusiness operations and are therefore stored centrally, inthe business fact dictionary.

Examples: customer number, customer address, item partnumber

9.3 AssociationsBusiness objects interact with each other in specific relationships calledassociations.

Defines A business rule can specify, or define, constraints on businessinformation and business transactions.

Depends Business information can be contingent on, or depend on, otherbusiness information.

Includes A business transaction and business information canencompass, or include, a business fact. A business fact caninclude another business fact.

Initiates A business rule can start, or initiate, a business transaction.

Interrogates A business rule can obtain information from, or interrogate,business information.

Modifies A business rule can change the content of, or modify, businessinformation.

Triggers A business transaction can start, or trigger, a business rule.

Uses A business rule can employ, or use, another business rule.

Using these constructs, VisualAge Requirements Tool helps you quickly specifythe behavior of your business operations. You can then iteratively view, detail,and modify them to develop the user requirement statements you want.


9.4 The User Requirement StatementThe data you enter in VisualAge Requirements Tool makes up your userrequirement statement. VisualAge Requirements Tool provides a wide selectionof views to analyze, validate, and communicate your requirements.

9.5 PositioningLet′s be a little more specific about the linkage between VisualAgeRequirements Tool, LOVEM-E, and BMT. One of the key work products from aLOVEM-E project is the PLOVC. In 6.5, “Physical Line of Visibility Chart” onpage 67 we developed a PLOVC for Universal Trust Company′s mortgageapplication process. You may have noticed a key characteristic of the PLOVC:its manual/automation line. This line defines the interface between the manualand automated activities of a process. System interfaces are shown on thePLOVC as process blocks that straddle the manual/automation line. LOVEM-Edescribes, in general terms, the function of the process block, but its focus is onthe overall process, not the details of an individual process block. This is whereVisualAge Requirements Tool fits. Still operating in the business domain, asopposed to the systems domain, VisualAge Requirements Tool provides a smallnumber of versatile business objects that can be used to represent the functionalrequirements of a process block.

The sample PLOVC in Figure 30 on page 125 shows the manual/automation lineand its relationship to system process blocks. The system process blocks formthe link between BMT and VisualAge Requirements Tool. In this section wecontinue our work with Universal Trust Company′s mortgage application andshow how VisualAge Requirements Tool can be used to define the systembehavior of the PLOVC′s system process blocks.

124 Beyond BPR

Figure 30. Universal Trust Company Mortgage Application PLOVC

Detailed discussion of how the VisualAge Requirements Tool windows in thesections that follow were produced is beyond the scope of this section. Fordetailed information on VisualAge Requirements Tool use, refer to VisualAgeRequirements Tool for OS/2 User′s Guide . The subsequent discussion assumesan entry level knowledge of OS/2 GUI controls and their function.

9.5.1 VisualAge Requirements Tool User EnvironmentThe VisualAge Requirements Tool main window is pictured in Figure 31 onpage 126. It contains the VisualAge Requirements Tool business objects (theirfull names as used by VisualAge Requirements Tool, if different from thoseshown, are enclosed in parentheses):

• Business operation• Transaction (business transaction)• Rule (business rule)


• Information (business information)• Fact (business fact)• Fact Dictionary

Figure 31. VisualAge Requirements Tool Main Window

With the exception of the Fact Dictionary, these objects are OS/2 templates; thebusiness operation template was used to create the mortgage application andmortgage renewal business operation objects. The Fact Dictionary is an objectthat serves as the storehouse for business facts included in VisualAgeRequirements Tool business operations, but more on this in a moment.

9.6 Business OperationThe Business Operation serves as the container for VisualAge RequirementsTool business objects and typically encompasses a business area or process.The Business Operation, along with the business objects it includes, make upthe user requirements statement. In this section, we use VisualAgeRequirements Tool to develop the system requirements for the mortgageapplication business operation. The mortgage renewal business operationshown in the main window is an example of the support for multiple businessoperations that VisualAge Requirements Tool offers. A business operation canbe nested within another business operation, thus enabling VisualAgeRequirements Tool to be used to define requirements for large processesconsisting of a number of individual business operations.

Selecting the mortgage application business operation presents the user with theOperation Diagram View pictured in Figure 32 on page 127. The OperationDiagram is the complete picture of the business operation and shows all thebusiness objects used to represent the required function.

126 Beyond BPR

Figure 32. Operation Diagram View

The Operation Diagram can become quite crowded when modeling a complexbusiness operation. VisualAge Requirements Tool provides two tools, Overviewand Zoom lens, which can be used separately or in conjunction to manage thelevel of detail visible in the Operation Diagram. The user can select and size thearea of general interest with Overview, then use Zoom lens to enlarge andcenter it within the window.

From the Operation menu in the Operation Diagram, the user can access otherviews of the business operation. The other views available include the:

Settings and Icon view. Settings provides a notebook through which the usercan rename the business operation. The Icon view provides an icon view ofthe business objects included in the business operation. The Icon view isless useful than the Operation Diagram view because it does not showassociations that provide valuable information on the relationships betweenthe business objects.

Operation diagram view. Allows the user to open another view of thisbusiness operation that can be useful for a user working with two differentparts of a business operation simultaneously.


Information dependency diagram view. We say more about this view in 9.9.1,“Data Dependency Relationships” on page 142. It can be used to show thebusiness information included in the business operation. It identifies theentities (business information) and their attributes (business facts) and therelationships and constraints among entities.

User role view. This view is discussed in more detail in 9.7, “BusinessTransactions.” It provides a view showing all the business transactions thatcan be performed by a particular user. It can be used to check forcompleteness; for example, it quickly reveals if any business transactionsrequired by a specific user are missing.

Incomplete business objects. VisualAge Requirements Tool businesstransactions, rules, and information all have a completeness indicator toindicate whether the business object is completely defined. VisualAgeRequirements Tool uses this indicator to generate a view showingincomplete business objects that can be used to assess progress inmodeling a business operation.

Rules classified as. VisualAge Requirements Tool provides a business rulesclassification scheme that can be used to categorize business rules. Thistopic is covered in more detail below, but this menu option provides a meansto quickly identify business rules that share the same classification.

Operation containing. We mentioned above that VisualAge RequirementsTool business operations can be nested within other business operations. Inour example, we chose to model the mortgage application process. It may,in fact, be a subprocess of a mortgage administration business operation.This option could be used to show the overall business operation to whichthe current business operation belongs.

9.7 Business TransactionsThe business transaction is one of the fundamental concepts of VisualAgeRequirements Tool. The VisualAge Requirements Tool approach emphasizesthe function, or system behavior, a system must provide, rather than focusingnarrowly on user interface, process, or data design. The business transaction isthe means through which business users obtain their services and are used toactivate business rules which, in turn, can define, query, or change businessinformation. Transactions can originate from either an external event (forexample, a customer request for a quote) or a business rule (for example, checkcredit limit).

In our mortgage application example, we use the info request businesstransaction to illustrate the use of a business transaction and its relationship tobusiness rules and business information. Info request is a business transactioninitiated when either a customer or a prospect contacts Universal Trust forinformation on its mortgage products.

The settings for info request are stored in a notebook and can be accesseddirectly through the info request object or through a pop-up menu like the oneshown in Figure 33 on page 129.

128 Beyond BPR

Figure 33. Info Request Business Transaction Settings Pop-up Menu

Figure 34 on page 130 shows the Type page of the info request businesstransaction settings.


Figure 34. Info Request Business Transaction Types

Four different types of transactions can be defined:

Event Notification. A business transaction that alerts the system of anexternal event.

Query. A business transaction that requests information regarding thecurrent content of business information.

Report. A business transaction that produces output for its user. Reporttransactions don′ t alter the contents of business information.

Prompt. A combined input and output transaction that is used to collectinformation from the user.

A Logged check box can also be set if instances of this transaction are to besaved for future reference.

In the case of our info request transaction, a user has contacted the branch loanofficer and requested information on Universal Trust Company′s mortgageproducts, so we assign the event notification transaction type to this transaction.

Figure 35 on page 131 shows the User page of the info request businesstransaction.

130 Beyond BPR

Figure 35. Info Request Business Transaction User Role

This page records the user who created the transaction. Two choices areavailable:

User. Indicates the business transaction receives input from the user of thebusiness operation.

Business Operation. Indicates the transaction sends output to a user.

The User Role captures the name, title or category of the user who eithercreates the business transaction or is the destination of any output sent throughthis business transaction and is used to produce the User Role Diagram. TheUser Role Diagram allows the user to relate transactions to the users whoperform or initiate them. This is useful for not only ensuring transactioncoverage within a user role, but also for confirming there is an appropriatematch between transactions and user role. For example, a specific transactioncan require training or skill beyond that possessed by those currently in the role.In this case, either additional training or a change in the user role for thetransaction may be necessary.

The Completed page of the info request business transaction notebook allowsthe user to indicate completion status for this object and is used to generateviews of completed objects and those objects that require additional work to


complete. The notes panel allows reviewers and other users to add detailedcomments.

The General page shown in Figure 36 is the final page of the info requestsettings notebook and contains the name of the business transaction and anyadditional descriptive information the user would like to provide about thetransaction.

Figure 36. Info Request Business Transaction General Information

9.8 Business RulesBusiness transactions capture the interactions between users and the businessoperation, and business information maintains the current status of entities ofinterest to the business operation. Business rules provide the link betweentransactions and information and describe the behavior of the businessoperation. Business rules detail what is done and under what conditions duringthe normal running of the business operation.

VisualAge Requirements Tool business rules can:

• Use other rules. This is to support rule reuse by making repeatedspecification of rules unnecessary.

132 Beyond BPR

• Change or define states of business information objects.

• Create instances of known transactions for execution.

• Either continue or stop the invocation of actions that follow in a sequence.

To restate this more in terms of implementation, a business transaction isanalogous to a user asking the system to process an order, look up a customerrecord, or produce a report. Business information is the data necessary to fulfillthese requests. Business rules are a business user representation of thefunction provided by the program modules, program procedures, or dataconstraints that operate on business information to support user requests.

Returning to Universal Trust Company′s mortgage application business process,we can see in Figure 37 that the info request business transaction triggers thequotation business rule, which is shown enclosed by the small square.

Figure 37. Quotation Business Rule

The information and functions available through the quotation business ruleobject through a pop-up menu are:


Settings. We take a detailed look at this business rule′s settings below but,briefly, this is where details of the business rule′s actions and classificationare captured.

Transactions initiated, Transactions that trigger, and Transactions defined.These options show views of transactions initiated by this rule, thetransaction that triggered this rule, and transactions defined by this rule (forexample, the contents of a report).

Information modified, interrogated, or defined. These views show thebusiness information affected by this business rule.

Rules used and Rules that use. These views show the forward and backwardrelationships between this rule and other business rules.

Operation containing. This view shows the other business operations(business processes) that contain this business rule.

Figure 38 shows the Settings for the quotation business rule. The Complete andGeneral sections have been discussed before and are the same for businessrules, so we do not cover them here. Our interest lies in the Actions andClassification sections of the business rule settings.

Figure 38. Quotation Business Rule Settings

134 Beyond BPR

As the text on the Action panel indicates, new actions are created by selectingthe New button, which adds a numbered tab to the bottom of the Actions page ofthe notebook. However, because there are already two actions defined for theQuotation business rule, we select tab 1 to open the first action, shown inFigure 39 on page 135.

Figure 39. Quotation Business Rule Action 1

The business rule Actions are evaluated sequentially, beginning with theCondition found in Action 1. The Actions are interpreted as follows:

1. If the Condition is true, read the Result.

a. If the Result says to stop, exit from the business rule.b. If there are no more Actions, exit from the rule.

c. Read the next action and return to step 1.

2. If the Condition is false:

a. If there are no more Actions, exit from the rule.b. If there is another Action, return to step 1.

In our Universal Trust Company example, the Condition for Action 1 is whetherthe customer requesting mortgage information is an existing customer. If true,the Result indicates the following action will be taken:


1. Look up customer information in the CUSTOMER business information forinclusion in PROSPECT business information.

2. Look up the rates and terms product information in PRODUCT. 3. Provide the customer quote by invoking the QUOTATION REPORT business

transaction. 4. Record the prospect in PROSPECT.

Action 2 covers the case where the person requesting mortgage information isnot an existing customer and differs only from Action 1 in that customerinformation is not looked up in CUSTOMER before being recorded in PROSPECT.

A group of Actions form a stack; the sequence of the Actions can be changed byselecting the Up button, which advances the Action towards the first tab, or theDown button, which moves the Action towards the last tab.

The Classification section of the business rule, which is shown in Figure 40, letsa business rule be classified according to its primary activity. The RuleClassification entry allows selection of one of twenty-five classificationcategories. A Synonym can also be entered, which, like the Rule Classification,can be used to search for related business rules.

Figure 40. Quotation Business Rule Classification

136 Beyond BPR

VisualAge Requirements Tool uses the business rule classification shown inTable 3 on page 137. The classification scheme is a series of generic activitiesthat businesses perform to handle their business objects effectively. Theactivities are task areas or management and control areas, and they can beautomated or performed by people.

This business rule classification covers a complete set of task areas. All taskareas are carried out in a business enterprise against its business objects. Insome cases, the task is performed formally, possibly automated or otherwiseexplicitly controlled. In other cases, the task is performed informally,infrequently, and often with no resulting documentation.

VisualAge Requirements Tool supports synonyms specified by you so that youcan use different terms to classify a specific activity. You likely use differentterms to classify the same activity when applied to different business objects.For example, you may build a plant, but you assemble products in that plant.

A quick reference summary of each business rule classification category follows.Each category is named, followed by a list of suggested synonyms, and brieflydescribed. Synonyms are optional; you can select from those suggested orsupply your own.

Activities on Individual Business Objects

1. Make: build, create, assemble, compile, define, acquire

Table 3. Business Rule Classification and Suggested Synonyms

On individual business objects1. Make: build, create, assemble, compile, define, acquire2. Move: transfer, position, receive, ship, store, disburse3. Test: quality control, inspect, verify, audit, appraise4. Maintain: repair, adjust, calibrate, update5. Scrap: delete, reject, manage end-of-life, tear down, dismantle6. Set-up: prepare, format7. Catalog: describe, account for, identify, list8. Unit costing: pricing9. Keep history: log events, journalingTrack and control business objects and processes10. Monitor: track, measure, evaluate, age11. Schedule: dispatch, release, prioritize, expedite, allocate12. Optimize: balance13. Collect data: acquire information14. Report status: show current situation15. Report exceptions: show exceptions16. Keep summarized history: maintain summarized versioned data17. Report summarized history: show summarized versioned dataPlan and account for processes18. Sourcing19. Develop estimates: set standards, propose targets, set controllimits, establish quotas20. Requirements planning21. Budgeting: control expenses, monitor bill ing, supervise payroll22. Load solutioning: load balancing, contract vendorsLong-range planning and strategy23. Forecasting: trend analysis24. Modeling: make statistical decisions25. Strategic planning


The make category accounts for the basic interaction between the enterpriseand the business object. This interaction is the reason for the initial interestof the enterprise in the business object. It is an expansion of the makeconcept, which is frequently used in shop-floor control (make, move, test)literature.

2. Move: transfer, position, receive, ship, store, disburse

The move category establishes changes in the physical, or logical, locationof the business object. Location can be expressed by building number,department number, disk address, or any other reference. This activity isrequired because most business objects must often be relocated or movedduring their interaction with the enterprise.

3. Test: quality control, inspect, verify, audit, appraise

The test category verifies the quality of business objects at different points inthe product cycle. Test introduces the lowest level of process feedback.Very few processes exist in which no inspection or quality check occurs.

4. Maintain: repair, adjust, calibrate, update

The maintain category closes the feedback loop initiated by test. Recordsthat represent physical business objects must be maintained or updated toreflect real-world changes.

5. Scrap: delete, reject, manage end-of-life, tear down, dismantle

The scrap category is required when it is not economical or possible tosalvage a defective or unnecessary business object.

6. Set-up: prepare, format

The set-up category is not productive in itself, but the activities areperformed because they are necessary or because we expect benefits fromthem in the future.

7. Catalog: describe, account for, identify, list

The catalog category is not as vital as some other categories, but it isneeded to track managed business objects. It represents the tasks requiredto track individual business objects or batches of business objects to keepbasic facts about them.

8. Unit costing: pricing

The unit costing category represents the costing of business objects atdifferent points of their processing. Because costing requires a significantresource expense, normally only some of the business objects are costed.Costing is done primarily for products of the enterprise.

9. Keep history: log events, journaling

The keep history category activities are performed against individual, orbatches, of business objects. Information about particular events thatoccurred in relation to the business object is kept and time stamped.Historical data is maintained until the business object leaves the enterprise′ssphere of interest. These activities often are carried out informally throughnotes or other records.

Activities to Track and Control Business Objects and Processes

10. Monitor: track, measure, evaluate, age

138 Beyond BPR

The monitor category establishes a fundamental management tool toevaluate the state of a process or business object. It is a basic source forreporting activities.

11. Schedule: dispatch, release, prioritize, expedite, allocate

The schedule category reflects the way management establishes and altersthe order in which business objects are processed. The information requiredfor these activities is obtained from reporting activities or externalcommunications.

12. Optimize: balance

The optimize category is a form of planning because real-world processesare affected by schedule activities.

13. Collect data: acquire information

The collect data category represents all of the actions performed to supplyinformation about processes and business objects. It covers all of theinformation transfer protocols, data files, and error-correcting cycles.

14. Report status: show current situation

The report status category presents current data about processes andbusiness objects for people or systems to use. Data is gathered throughcollect data activities.

15. Report exceptions: show exceptions

The report exceptions category is similar to report status, except data ispresented only for processes or business objects outside established norms.It is fundamental to management-by-exception disciplines.

16. Keep summarized history: maintain summarized versioned data

The keep summarized history category takes information from current filesand accumulates it in historical form: year-to-date, month-to-date,week-to-date, or other time brackets. The summarization can be based onthe business object type or physical attribute.

17. Report summarized history: show summarized versioned data

The report summarized history category produces reports from summarizedhistory files.

Activities to Plan and Account for Processes

18. Sourcing

The sourcing category covers decisions about which process is going tohandle business objects on hand. Typically, make or buy decisions fall inthis category, but it also includes deciding whether to rework existing stockor develop new processes and material.

19. Develop estimates: set standards, propose targets, set control limits,establish quotas

The develop estimates category establishes parameters to track the progressof processes and business objects. The parameters are used by reportexceptions.

20. Requirements planning

The requirements planning category determines the time frames, kinds, andquantities of resources needed to satisfy demand for business objects.


21. Budgeting: control expenses, monitor billing, supervise payroll

The budgeting category determines the cost and control of the expenses of aprocess in relation to a given business object. It also covers billing for thevalue added to the business objects.

22. Load solutioning: load balancing, contract vendors

The load solutioning category addresses the optimization of processutilization based on the sourcing decisions made through sourcing . This is ahigh-level optimize, applying to individual processes, because it applies toprocess lines or larger operational units.

Activities to Accomplish Long-Range Planning

23. Forecasting: trend analysis

The forecasting category determines trends across processes and businessobjects and forecasts future requirements.

24. Modeling: make statistical decisions

The modeling category implements process object models to resolve what-ifquestions and perform sensitivity analysis. Support for decisions is based onmodel outputs.

25. Strategic planning

The strategic planning category sets direction based on information orforecasts about the overall environment, either external or internal to theenterprise.

9.9 Business InformationBusiness information is another of the major business object types in VisualAgeRequirements Tool. They represent the external entities or things of interest tothe business or organization which, collectively, maintain the knowledgerequired to operate the business. In data modeling terms, business informationis much like the entity found in entity-relationship modeling. In fact, as we′ ll seebelow, VisualAge Requirements Tool can produce a data dependency diagramthat is similar to an entity-relationship diagram except it is presented at a higherlevel of detail.

VisualAge Requirements Tool divides business information into twosubcategories that are generally equivalent to master and transaction files. Adescriptor is equivalent to the master file concept and is the businessinformation category responsible for maintaining current information whichreflects the ongoing flow of transactions through the system. A transaction log isanalogous to a transaction file and keeps a journal of past transactions. Not alltransactions need logs (for example, queries may not) but they often need to beremembered for future reference. Transaction logs are needed as an extraservice by systems to track their own business transactions.

The Universal Trust Company info request transaction introduced above usesthree different business information objects, customer, prospect, and product.Figure 41 on page 141 shows these objects enclosed with small squares.

140 Beyond BPR

Figure 41. Customer, Prospect, and Product Business Information

Some of the information and functions available through the customer businessinformation object are:

Settings: In addition to the status and general attributes found on allVisualAge Requirements Tool business objects, Settings is used to indicatethe category of business information (descriptor or transaction log).

Information depended upon and Information that depends on: These viewsshow the constraints that exist between this and other business information.

Rules that modify, Rules that interrogate, Rules that define: Provide viewsthat show the business rules responsible for modifying (updating),interrogating (inquiring), and defining (creating) business information. Theseviews provide important information. Consider the following simple example.If there are no business rules that define (create) this business information,the system has no business rule that creates a new instance of this businessinformation.

Facts included: Provides a view of the business facts (attributes) which thisbusiness information (entity) includes.

Operation containing: Indication of which business operation (businessprocess) contains this business information.


Figure 42 on page 142 shows the customer business information settings whichindicates customer is a descriptor business information object.

Figure 42. Business Information Type

9.9.1 Data Dependency RelationshipsOur Universal Trust Company mortgage application example contains fourdifferent business information objects, Product, Prospect, Customer, andMortgage. In Figure 43 on page 143 the VisualAge Requirements ToolInformation Dependency diagram illustrates the relationship between thesedifferent types of business information. This diagram is similar in form to theentity-relationship (E-R) diagrams generated in formal data modeling but withoutthe depth of relationship detail and formal representation of E-R diagrams.

142 Beyond BPR

Figure 43. Information Dependency Diagram View

9.10 Business FactsIn constructing a VisualAge Requirements Tool business operation model theinitial focus is on business transactions and business information. Once theseare identified the analysis of the business information can move to a lower leveland identify the pertinent facts relevant to the business transaction and entity. InVisualAge Requirements Tool these facts (or attributes) are called businessfacts. Business facts are created and stored in the Fact Dictionary and thenadded to individual business information objects as the understanding of therelationships between business transactions, information, and facts grows.

Figure 44 on page 144 shows the business facts included in the customerbusiness information object. Business facts are added to the customer businessinformation object by dragging the business fact icons from the Fact Dictionary tothe Facts Included view for the customer business information.


Figure 44. Business Information and Business Facts

9.11 Data ConsolidationBefore reviewing the requirements with users, the business rule classificationdata should be reviewed to uncover any rules that may have been overlooked.These rules might not be triggered by transactions, even though they should be.A decision needs to be made on whether they belong to existing transactionsand were overlooked or whether new transactions are needed.

144 Beyond BPR

To complete the process:

1. Use the User Role diagram to verify all business transactions are identified.Are all create, update, and delete needs supported by the listedtransactions?

2. Use the Operation diagram to verify all business rules are triggered by atransaction.

3. Use the transaction flow diagram to review the behavior of businesstransactions.

4. Iterate these steps until you are satisfied.

9.12 Review Requirements Statements with UsersThe final step, at least in each iteration of the requirements specification, is touse VisualAge Requirements Tool to display, describe, and discuss therequirements with the users of the system being specified. The VisualAgeRequirements Tool presentation is highly intuitive and grasped quickly by users,encouraging their participation in critiquing, improving, and validating therequirements. Changes can be made to the specifications as the users reviewthe material. Once validated, the requirements specification is ready to be usedin implementation. A sample of VisualAge Requirements Tool reports that canbe used to support implementation projects is shown in the following section.

9.13 VisualAge Requirements Tool ReportsFigure 45, Figure 46 on page 146, Figure 47 on page 146, and Figure 48 onpage 147 contain samples of the reports produced by VisualAge RequirementsTool.

Figure 45. Sample Business Transaction Report


Figure 46. Sample Business Information Report

Figure 47. Sample Business Rule Report

146 Beyond BPR

Figure 48. Sample Fact Dictionary Report


148 Beyond BPR

Chapter 10. FlowMark

In Chapter 7, “Workflow Management” on page 87 we discussed workflowmanagement concepts. This chapter introduces FlowMark, IBM′s workflowmanagement solution.

In this chapter, we explain the two components of FlowMark: Buildtime andRuntime. We will also explore how the Universal Trust Company MortgageApplication can be implemented in FlowMark and discuss how FlowMark fits inthe reengineering picture. This chapter includes the following topics:

10.1, “FlowMark Description” on page 150

10.2, “Modeling with Buildtime” on page 155

10.3, “Executing with Runtime” on page 165

10.4, “External Format” on page 167

10.5, “From LOVCs to FlowMark Implementation” on page 171


10.1 FlowMark DescriptionAs business processes become more and more complex, planning andmanaging all the activities and resources involved in getting a job done becomemore challenging. Tracking the flow of work through an enterprise requires timeand diverse skills and knowledge.

These challenges can be reduced by using a well-documented workflow modelto automate your business processes. Automating your processes can save yourorganization time and money by presenting the right activity to the right personat the right time, supported by the information and the programs to perform theactivity. You can build into your workflow models the business regulations thatyou want to enforce. FlowMark provides you benefits in the following areas:

Application integration. FlowMark supports several types of applications. Itcan execute programs residing in workstation or host systems. It can runapplications on OS/2, Windows, AIX, CICS, IMS, and TSO. It can alsointegrate with Lotus Notes, Lotus cc:Mail, Search Manager/2, Easel, Timeand Place/2, VisualInfo, and 3270 host applications using HLLAPI. BecauseFlowMark can drive several types of applications, you can share databetween these applications. Therefore, you can put together solutions thatmake the best use of different technologies, resulting in efficient andcost-effective solutions.

Flow independence. With FlowMark, changes in an organization′s processdo not affect the applications. Applications are not tightly bound to thesequence in which they are performed. When processes change, the rightapplications can easily be reassigned to the right activities of the newprocess. You therefore shorten application development time during processchanges.

Parallel development of programs. FlowMark handles the passing of datafrom one application to another and the sequencing of program execution.Because of this, applications can be written with focus on the results, insteadof on the interface with other applications. Therefore, applications can bedeveloped in parallel as they have become more independent of each other.This leads to shorter application development cycles, especially whenimplementing new application systems.

The FlowMark workflow manager helps you automate your business processes.It integrates the tasks performed by computer applications with the everydaytasks of staff members. FlowMark accomplishes this using its two majorcomponents.

10.1.1 BuildtimeFlowMark Buildtime contains folders for modeling processes and administeringthe system. Only modelers and system administrators need a Buildtimeworkstation. Using FlowMark Buildtime, you can:

• Define, graphically depict, and document models of your processes• Assign staff members to the activities in the processes• Associate OS/2, AIX, and Windows programs with particular activities• Animate your workflow models to test them.

With FlowMark Buildtime, you build models of an enterprise′s processes. Theproduct is designed to run anything from simple, linear processes to those that

150 Beyond BPR

contain many activities, alternative paths, and multiple instances of the sameactivity in parallel.

A convenient graphical interface is provided for specifying this information.Process models can be animated with sample data to verify their completenessand viability. Once this has been done, Buildtime process models become readyfor translation (conversion) into Runtime process templates, from whichexecutable copies can be made.

10.1.2 RuntimeFlowMark Runtime contains folders for controlling processes and using worklists. Most users need a Runtime workstation. Using FlowMark Runtime, youcan:

• Start processes that have been translated from FlowMark Buildtime• Manage processes that are already started• Start activities that running processes make ready• Transfer activities from one user′s work list to another′s• Track processes and the status of activities assigned to staff members.

With FlowMark Runtime, an authorized person creates an executable copy of aprocess template by translating a Buildtime process model. Each such copy iscalled a process instance, and each step is called instantiation.

Once an authorized person starts a process instance, Runtime maintains thework lists of the staff to whom activities are assigned. Each staff member′s worklist receives assigned activities of running process instances. When the staffmember starts an activity, FlowMark starts the program specified in the processmodel and can pass it any necessary data. The staff member then generallyinteracts with the program to perform the activity. Activities, such as programs,can also be defined so that they start automatically. When an activity is finished,Runtime adds the next activity in the process to the work lists of all staffmembers to whom it is assigned. Authorized people can intervene to suspend,resume, stop, and restart process instances.

10.1.3 Workflow ModelA workflow model is a complete representation of a process, comprising aprocess diagram and the settings that define the logic behind the components ofthe diagram.

Using the settings notebooks and other dialogs provided by FlowMark Buildtime,you create workflow models from these components. You can then convert theworkflow models into process templates for use in FlowMark Runtime. Thecomponents of the FlowMark diagram are the following:

Process diagram. Whereas a process document uses words to describe thesequence of working procedures, a process diagram uses symbols torepresent the activities that make up the process. The possible ways thatwork and data can flow through a model are represented graphically byarrows called connectors.

A workflow model consists of several elements:

• Processes• Activities• Blocks

Chapter 10. FlowMark 151

• Connectors• Containers for data• Conditions• Programs• Staff

Process. A process is a sequence of activities that must be completed toaccomplish a task. The process is the top-level element of a FlowMarkworkflow model. Multiple instances of a FlowMark process can run inparallel.

Activity. An activity is a step within a process. It represents a piece of workthat the assigned person can complete by starting a program or anotherprocess. A FlowMark workflow model consists of the following types ofactivities:

Program activity Has a program assigned to perform it. The program isinvoked when the activity is started. In a fullyautomated workflow, the program performs the activitywithout human intervention. Otherwise, the user muststart the activity by selecting it from a Runtime worklist. Output from the program can be used in the exitcondition for the program activity and for the transitionconditions to other activities.

Process activity Has a process assigned to perform it. The process isinvoked when the activity is started. A process activityrepresents a way to reuse a set of activities that arecommon to different processes. Output from theprocess can be used in the exit condition for theprocess activity and for the transition conditions toother activities.

Block. A block is a modeling construct used in a process diagram for one ormore of the following purposes:

• Reducing the complexity of a process diagram. You can group severalactivities and nested blocks together under one block symbol to keep theprocess diagram uncluttered.

• Looping through a series of activities. If you specify an exit condition forthe block, the activities in the block are executed repeatedly until the exitcondition evaluates to true.

• Implementing bundles. By following the restrictions for bundles, you canreplicate a single activity as many times as are necessary to processdata input to the block at run time.

Bundle A bundle is a special kind of block that supportsmultiple instantiations of a single program or processactivity at run time. Use of this modeling constructenables your workflow model to cope with situationswhere an indeterminate number of activities arerequired at run time.

The activity that is replicated is called the patternactivity, and each instance of it is called a bundleactivity. The number of bundle activities created at runtime is determined by a special program activity calledthe planning activity. A special executable program

152 Beyond BPR

EXMPOBCL.EXE is supplied with the FlowMarkworkflow manager for use in planning activity.

Control Flow. The flow of control through a running process determines thesequence in which activities are executed. The FlowMark workflow managernavigates a path through the process that is determined by the evaluation totrue of start conditions, exit conditions, and transition conditions.

Connector. Connectors link activities in a workflow model. Usingconnectors, you define the sequence of activities and the transmission ofdata between activities. The activity from which a connector originates iscalled the origin activity. The activity to which the connector points is calledthe target activity. Connectors are not required in a workflow model in whichall activities should become ready to start when the process is started andno data is passed between activities.

In FlowMark process diagrams, there are the following types of connectors:

Control connector Specifies the sequence of activities in a workflowmodel. Several control connectors can be associatedwith an activity. A control connector has a conditionassociated with it that directs the flow. This is called atransition condition.

Default connector Specifies where control should flow when the transitioncondition of no other control connector leaving anactivity evaluates to true. Default connectors enableyour workflow model to cope with exceptional events.

Data connector Specifies the flow of data in a workflow model. A dataconnector originates from an activity or a block andhas an activity or a block as its target. You can specifythat output data is to go to one target or to multipletargets. A target can have more than one incomingdata connector.

Data Container. In a FlowMark workflow model, storage is allocated for theinput and output data of the process and of the activities and blocks within it.

Each activity has a data container for input and a data container for output.To transfer data to and from blocks or processes, you use the special datacontainers called source and sink. Source represents the input container fora process or block, and sink represents the output container.

Each data container is defined by a data structure. Data connectorsrepresent the transfer of data from output containers to input containers.When a data connector joins an output container with an input container, andthe data structures of the two containers match exactly, the FlowMarkworkflow manager maps the data automatically. Otherwise, you must mapindividual members of the output data structure onto members of the inputdata structure.

Data Structure. A data structure is an ordered list of variables, calledmembers, that have a name and a data type. The maximum size of a datastructure is 256 member items. Data types are string, long, floating point,and structure. The FlowMark workflow manager supports one-dimensionalarrays of any of these data types, with a maximum size of 256 elements.

Condition. Conditions are the means by which you specify the flow of controlin a process. In FlowMark workflow models, you define logical expressionsthat are evaluated by FlowMark Runtime to determine when an activity may


start, end, and pass control to the next activity. Here are the types ofconditions:

Start condition The condition that determines when an activity withincoming control connectors can start. The startcondition can specify that all incoming controlconnectors must evaluate to true, or that at least oneof them must evaluate to true. Whatever the startcondition, all incoming connectors must be evaluatedbefore the activity can start. If an activity has noincoming control connectors, it becomes ready whenthe process or block containing it starts.

Exit condition A logical expression that, if specified, must evaluate totrue for control to pass from an activity or block.

Transition condition A logical expression associated with a controlconnector. If specified, it must evaluate to true forcontrol to flow along the connector.

Program. In the FlowMark workflow manager, program means acomputer-based application program that supports the work to be done in anactivity. Program activities reference executable programs using the logicalnames associated with the programs in FlowMark program registrations.The program registration can contain run time parameters for the executableprogram.

Staff. Each activity in a process is assigned to one or more staff membersdefined in the FlowMark database. Whether an activity is started manuallyby the user or automatically by the FlowMark workflow manager, andwhether it requires user interaction to complete or completes automatically,a staff member must be assigned to it.

FlowMark staff definition entails more than identifying people at yourenterprise to the FlowMark database. For each person defined, you canspecify a level, an organization, and multiple roles. These attributes can beused at run time to dynamically assign activities to people with suitableattributes.

10.1.4 How These Pieces Fit TogetherYou create your workflow model in FlowMark Buildtime. You draw a diagram ofyour process using the symbols for activities and blocks. The process canconsist of just one activity or of many activities and blocks.

You can leave all the activities in the process detached from each other, inwhich case they all become ready to start simultaneously. If the order in whichactivities start is important in your process, you can control this by linking themwith control connectors. When the process is running, the conditions you defineon these connectors are used to determine which activities are started andwhich are not.

You can also link activities and blocks with data connectors, if the data used byor resulting from one activity is required by a subsequent one.

You assign people and programs to the activities. You can be very flexible inyour staff assignments. Instead of assigning an activity to a specific person, youcan assign it to a group of people who meet specific criteria at run time. Anyone of them can start the activity.

154 Beyond BPR

The program registrations that you assign to activities and any input and outputdata structure definitions that the activities require must be known to theFlowMark database before you create your model.

After you have created your model and tested it, you translate it into a form thatcan be used by end users of FlowMark Runtime. When someone starts aninstance of the translated process, the FlowMark workflow manager navigatesthrough the process and automates the sequencing of activities.

You can make changes to or even erase your workflow model after you havetranslated it, and the template and instances of it used in Runtime are notaffected. If you want a changed version of your model to be used in Runtime,you must translate the changed version.

10.2 Modeling with BuildtimeFlowMark deals with actual activities. These are the programs that will run tocomplete the workflow. Therefore, our starting point in our case is the physicalcharts, namely the PLOVCs and the JLOVCs of our Universal Trust Companymortgage example.

First, identify all the To Be models that were generated from your businessprocess reengineering. In real life you want to assess To Be models, not As Ismodels. Your want to see how efficient and cost effective each model is. Youalso want to project what impact each model has to your customers. But in thisexercise, for simplicity let us assume that you want to assess implementing animaging system in the As Is Mortgage LOB from forward mortgage application(AC3) activity to set up mortgage account (AC13). This imaging system willcomplement the Mortgage System of Universal Trust Company.

Also, workflow management is defined in Chapter 7, “Workflow Management”on page 87 as being implemented through automation. This implies that theactivities of a process that will be implemented as a workflow must have someform of automation. Processes are usually made up of automated and manualactivities. In FlowMark, automated activities are performed by associating theseto programs. So during execution, when the workflow manager encounters anautomated activity, the automated activity calls a program and that programexecutes.

Manual activities on the other hand are associated with checklist programs.These checklist programs provide the user a list of activities that need to bechecked to reflect what manual activities have been performed. This is soFlowMark can inform the user that all preceding activities have been performedand the manual activity can now begin. Also, this is a way for FlowMark to getfeedback on the results of the manual activities so that you can use thatinformation later in the workflow. So during execution, when the workflowmanager encounters a manual activity, it calls a checklist program. FlowMarkprovides a checklist program, EXMPOMAN.EXE, that you can use. However, youcan develop a more sophisticated checklist program if you wish.

In the mortgage application example, implementing an imaging system to all theactivities from AC3 through AC13 results in a fully automated workflowimplementation.


Some LOVEM-E/BMT components have corresponding FlowMark components.Table 4 on page 156 shows the correspondence between LOVEM-E/BMTcomponents and FlowMark components.

Table 4. Correspondence between BMT and FlowMark Components

Because the activities from AC3 through AC13 had been entered in BMT, youneed to map each activity from the BMT PLOVC to a FlowMark program activity.You need to ensure that each activity is at its lowest detail. If you have a PLOVCcontaining PLOVCs and JLOVCs, and JLOVCs containing more JLOVCs (seeFigure 29 on page 113), then you have to map all the activities in all the PLOVCsand JLOVCs that apply to FlowMark program activities.

In our mortgage example, if we intend to implement our programs down to thetask level for the headquarters real estate administrator job, then we should mapthe PLOV activities set up property appraisal (AC4) and verify mortgage approval(AC6) to FlowMark process activities, and then map their JLOVC activities toFlowMark program activities. But for simplicity we do not include the activitiesof our JLOVCs in this exercise.

Therefore, our interest is only in the activities from AC3 through AC13 in thePLOVC found in Figure 16 on page 68. It involves the following 11 activities:

AC3—Forward mortgage applicationAC4—Set up property appraisalAC5—Appraise mortgage propertyAC6—Verify mortgage approvalAC7—Notify of mortgage rejectionAC8—Notify of mortgage acceptanceAC9—Sign off funds for mortgageAC10—Enter approved mortgage detailsAC11—Prepare mortgage documentsAC12—Present mortgage documentsAC13—Set up mortgage account

LOVEM-E (BMT) Components FlowMark Components

Activity and task Program activity

PLOV and JLOV Process activi ty

Loop Block activi ty

Information flow Control and data connectors

Function, department or job Staff definit ion

Start condit ion Start or transition condition

Exit condition Exit or transition condition

Description Documentation of a program or aprocess activity

PA, OA, GSP, AIR, CSF, MR, keyindicator

Documentation of a program or aprocess activity

156 Beyond BPR

10.2.1 Creating a FlowMark ModelThis section assumes you installed the FlowMark workflow manager. Log on toFlowMark Buildtime and map these activities to FlowMark program activities.Go to the Buildtime Processes Folder and create a new process. Then open thatprocess and put the program activities in the diagram. For detailed instructionson drawing a diagram in FlowMark, refer to the discussion of drawing thediagram of a new or existing process in the FlowMark V2.1 Modeling Workflowmanual. Figure 49 shows how AC3 through AC13 are mapped into FlowMarkprogram activities. AC2 assist mortgage application completion appears on theFlowMark screens but will not be discussed.

Figure 49. FlowMark Diagram with Program Activities

Notice that customer processes and systems in BMT are not included in thediagram. Customer processes are external to FlowMark workflows. FlowMarkencompasses only the business processes. FlowMark can enhance the interfaceto the customer, though. It can provide information that the customer needs andprovide this in well-designed printouts for the customer to keep. Or it can runinteractive transaction programs which the customer can interface with.

Systems are imbedded in the FlowMark program activities. You first create aprogram registration in the FlowMark Program Folder. Open the programregistration and define what the program is, what data it needs, what data itgenerates, where it resides, what platforms it runs on, what parameters to pass,and how it should run. Then, in the program activities, you define whichprogram registration needs to be called.

Now connect the program activities you just created in FlowMark with controlconnectors and data connectors. Control connectors specify what sequence the


program activities will follow. Data connectors specify where the data will flow.Figure 50 on page 158 shows program activities AC3 through AC13 with controland data connectors.

Figure 50. FlowMark Diagram with Program Activities, Control Connectors, and Data Connectors

You do not need to map our BMT document storage (cabinet) symbols. This isbecause our document storage will be part of our imaging system, not FlowMark.

You now have program activities with control and data connectors. You can nowdefine what the actual programs that will be called are, what data the programactivities will use, and who can access and execute these program activities.

Recommendation

We recommend that you create your model in this sequence:

1. Draw the model. This is when you put all the activities of a process in adiagram.

2. Define the components of each activity. These are the data structures,programs, and staff.

3. Go back to the model and associate the components to the activities ofthe model.

Having laid down your model first, it is easy to determine what componentsneed to be defined.

158 Beyond BPR

10.2.2 Creating Data StructuresNow you need to define what data your workflow will use. You need input datafor program activities and output data for program activities. The input datastructure can be the same or different from the output data structure. In thisexercise, since we concentrate more on processes than on data, we leave it upto you to design your own data structures for the mortgage application. Onceyou have done this, go to the Data Structures Folder and create your datastructures for the mortgage application. For detailed instructions on creatingdata structures, refer to the discussion of defining a data structure object inFlowMark V2.1 Modeling Workflow. Figure 51 shows an example of anapplication data structure.

Figure 51. Data Structure of Application Data

10.2.3 Creating Program RegistrationsNow you need to define what programs FlowMark will use. Each programactivity must reference a program registration. Go to the Program Folder andcreate your program registrations. In FlowMark Buildtime, the actual programsneed not exist at the moment. But in FlowMark Runtime, the actual programsmust be ready for execution. For detailed instructions on creating programregistrations, refer to the discussion of creating a program registration inFlowMark V2.1 Modeling Workflow. Figure 52 on page 160 shows an example ofa program registration that uses application data.


Figure 52. Program Settings of the Verify_Mtge_Apprvl_Pgm

Notice that the check box Same data structure for programming activity ischecked. This ensures that the data structures you will define in the programactivity setting are the same as those you define here.

The actual application that will execute In FlowMark Runtime is defined in one ofthe platform pages. FlowMark allows you to run application programs in threeplatforms: OS/2, AIX, and Windows. For each program registration, select whichplatform you want your application program to run on and enter the name andthe location (path) of your program.

If you want to execute an application program in OS/2 or Windows that willrequire user intervention, select the Visible and Start in foreground options in theplatform tab of the program settings. This will ensure that when the applicationprogram executes, it becomes noticeable to the user in his workstation.Figure 53 on page 161 shows an example of the program VERIF.EXE defined inthe OS/2 page of the Verify_Mtge_Apprvl_Pgm Program Registration.

160 Beyond BPR

Figure 53. OS/2 Tab

Recommendation

We recommend that you define your data structures before your programregistrations. This is because you need to enter your data structures in yourprogram registration settings.

10.2.4 Defining StaffFlowMark provides ways of logically defining who can run workflow programs. Itdoes this by allowing you to define organizations, levels, and roles. Therefore,when you specify who is authorized to run programs, you need not list all thepeople you are authorizing. You can authorize by role, level, or organization.Define roles, levels, and organizations in their respective folders in the StaffFolder.

The People Folder defines the FlowMark users. It is there where you can addthe roles, levels, and organizations they belong to. It is also there where youauthorize FlowMark functions to each user.

You do not need to perform your staff definitions if you will be testing on astand-alone environment. This is because you can perform all your testing usingthe administrator user ID. But if you will test your applications using severalclients and you want to log on to them at the same time, then you need to createyour staff definitions.


10.2.5 Defining Program ActivitiesNow you can put everything together in the FlowMark mortgage applicationmodel. Go back to the Buildtime process model and access the diagram of themortgage application. For each program activity, add the program, datastructure, and staff you have defined earlier.

You can define programs to execute automatically in the program activitysettings. You do this by selecting the option automatic in the start tab. This isuseful for programs that do not require human intervention in your workflow.Figure 54 shows an example of the start tab for the verify mortgage approvalprogram activity and how it is set to start automatically. Once a mortgageapplication has been approved or denied, this program activity can automaticallyexecute to check the status of the application and route the image of theapplication to the right people based on the status.

Figure 54. Start Tab

The program activities verify mortgage approval and sign off funds for mortgageneed further discussion since there are multiple data flows flowing out of them.There is a transition definition in the control settings of control connectors thatallow you to state what condition needs to be fulfilled so that control will bepassed on to the next program activity. If this is left blank, control automaticallypasses to the next program activity.

So when you have two or more control connectors coming out of a programactivity, and you want control to be passed to all the program activities attachedto these control connectors (an AND condition), no additional definition needs to

162 Beyond BPR

be done. When this happens, the program activities that receive control will runsimultaneously, producing parallel flows. This is what happens after the sign offfunds for mortgage program activity.

When you have two control connectors coming out of a program activity and youwant control to be passed to either one or the other program activity dependingon some data value (an OR condition), then you need to specify the transitioncondition of each of the control connectors. In the case of verify mortgageapproval, the control is passed either to notify of mortgage rejection or to notifyof mortgage approval, and the data that has to be checked is status (seeFigure 51 on page 159). Therefore, in the transition page of the controlconnector leading to notify of mortgage rejection, you can put Status =REJECTED. In the transition page of the control connector leading to notify ofmortgage approval, you can put Status = APPROVED. Since there is anothercontrol connector leading to sign off funds for mortgage and you want control tobe passed to this if the application is approved, you can put in the transitionpage of the control connector Status = APPROVED. Figure 55 shows thetransition page of the control connector leading to sign off funds for mortgage.

Figure 55. Transition Page of the Control Connector Setting

Note that the variable in the transition page is case sensitive. Therefore, the textrepresenting variables should be exactly the same as the name of the variable inthe data structure definition. If they are not exactly the same, FlowMark cannotrecognize the transition variable and the control of the workflow model becomesunpredictable.


10.2.6 AnimationNow you can test your mortgage application model by animating it. Theanimation facility of FlowMark provides another means to verify and debug aprocess model by simulating a process instance. You can explore various pathsforward and backward through the process step by step at any time duringdevelopment. You can simulate the different behavior of people and programs.It helps you visualize how your workflow model will behave when you move it toFlowMark Runtime.

You also see the data structures you use as FlowMark displays the datacontainers of every process activity that is running. You can test your workflowby entering values in the data containers and seeing how your workflow runswith these values.

Figure 56 shows the mortgage application model during animation.

Figure 56. Animation of the Mortgage Application in FlowMark Buildt ime

For detailed instructions on animating workflow models, refer to the discussionof using the animation facility in FlowMark V2.1 Modeling Workflow.

164 Beyond BPR

10.2.7 Preparing Application ProgramsOnce you are satisfied with the behavior of your FlowMark workflow model, youare ready to translate the model to a form that FlowMark Runtime can use. Butbefore you do, make sure that your application programs have been defined inthe program registration and are ready for execution. If they have not beendefined, the translation of your FlowMark model will fail. If they are not ready forexecution, your workflow model will fail when FlowMark Runtime calls theseprograms.

Prepare simple application programs that are easy to develop yet provide agood feel of how the final application will look. Since at this point you are onlyprototyping the application, you should balance development speed withapplication functionality. REXX, an IBM programming language, is highlyrecommended. It is similar to Basic and is therefore easy to learn and use. Yetit can create GUI interfaces allowing you to prototype functionally richapplications.

10.3 Executing with RuntimeOnce you translate your mortgage application model in FlowMark Buildtime andprepare the programs that the workflow model will call, you can log on toFlowMark Runtime. Open the Runtime Processes to see what workflow processtemplates you can activate. When you activate a process template, it creates aprocess instance. When you activate a process instance the workflow behind theprocess template begins execution. Figure 57 shows an example of a RuntimeProcess folder that has one process template, three ready process instances,and two running process instances.

Figure 57. Runtime Process Folder

FlowMark Runtime allows you to run several process instances of the sameprocess template. This means that you can run parallel process instances, all ofwhich come from the same workflow model. Therefore, you can perform paralleltesting by entering different data in each process instance to test how theworkflow will respond. During production, each process instance can representongoing transactions of different customers.


In the Work List folder, you can see all the activities you are authorized to workon. When you activate an activity or when the program activity in FlowMarkBuildtime has been defined to start automatically, the application programdefined for this activity will run. Figure 58 on page 166 shows an example of aWork List folder with two running activities.

Figure 58. Work List Folder

In FlowMark Buildtime, you may have defined prototype application programs inyour workflow model to get an initial feel of how your workflow model willbehave. These are the programs you will work with when you execute activitiesin the Work List folder.

When you are satisfied with the behavior of your workflow model in FlowMarkRuntime, you can simply substitute your prototype applications with moresophisticated applications. In FlowMark Buildtime, you may have to redefine theprograms in the Program folder, then translate the workflow model again in theBuildtime Process folder.

Activities of a workflow model in FlowMark can run on different workstations.Therefore, activities in FlowMark are dynamic because they can be assigned toany person, run any program, and use any data you define.

A process ends when there are no activities with a ready, pending, suspended,or running status. A process that has been successfully completed is shownwith the finished status in the Runtime Processes folder.

See FlowMark V2.1 Managing Your Workflow for details on the functions ofFlowMark Runtime.

10.3.1 Audit TrailFlowMark Runtime produces an audit trail when a process model is executed. Itkeeps a full record of the activities performed and the performance of theprocesses. This can be used to track results, and to help to find and eliminatebottlenecks in processes. If there are problems with the logistics of the model,these can become apparent in the audit trail.

FlowMark creates one audit trail file per day to track running process instancesand changes from one day to the next at midnight. If the audit trail server is

166 Beyond BPR

restarted, it either appends to the existing file for the day or creates a new file ifthe day has changed.

10.3.2 Process MonitorFlowMark Runtime includes a process monitor that shows you the status of arunning process instance as a diagram. You select the process you want tomonitor from the Runtime Process folder.

You can use the process monitor to see workflow models in actual operation.The process monitor view looks like the workflow model animation view. Itshows all the activities in your process, the flow of control between the activities,and which paths have been navigated through the particular instance of yourprocess.

10.4 External FormatAny of the definitions that you store in a FlowMark database can be described inan ASCII text file in an external format called FlowMark definition language(FDL). The FlowMark workflow manager provides two utility programs to helpyou use process, program, data structure, block, and staff definitions in FDLformat.

The export utility. The export utility enables you to export definitions from aFlowMark database into an FDL text file. These definitions include:

• Process definitions

• Staff definitions

• Program registrations

• Data structure definitions

The exported text file is in a format called FlowMark definition language(FDL).

You can export FlowMark workflow information to:

• Back up the workflow definitions you have modeled using the FlowMarkworkflow manager

• Change workflow definitions using a text editor

• Copy workflow definitions from one FlowMark database to another

• Create a document that describes, in detail, the definitions in yourworkflow model

The import utility. The import utility enables you to import definitions froman FDL text file into a FlowMark database to define part or all of yourworkflow model. Using the import utility provided with the FlowMarkworkflow manager, you can transfer workflow definitions from FDL files intoyour database. You can import workflow information into a FlowMarkdatabase to:

• Restore workflow information stored in an FDL source file to yourFlowMark database

• Import workflow information defined externally to the FlowMark workflowmanager using FDL


• Merge workflow information from two different databases to create a newdatabase.

You can also use these utilities to create documents containing informationabout the definitions in FDL files, such as statistics and cross-reference listings.These documents can be viewed on your workstation or printed on the host.

Using the syntax of FDL you can:

• Use a simple text editor to create definitions for FlowMark workflow models.

• Make changes to an FDL file that has been created by the export utility fromdefinitions in your database and then reimport the file. In some cases, thiscan be a quicker way of creating and changing workflow models than usingthe graphical interface.

• Write programs that produce FDL definitions you can use in your workflowmodels.

10.4.1 Importing BMT FlowMark Definition LanguageIn 8.3, “Generating Workflow Scripts” on page 109 we discussed BMT generationof FDL. Our interest in this section is to import the FDL that was generated byBMT.

When you generate BMT FDLs, BMT uses the mapping in Table 4 on page 156.This mapping allows BMT to create correct FDLs. By specifying the componentsin BMT, you define the FlowMark components that will be generated in the FDL.

Importing FDL to FlowMark is straightforward. The procedure is outlined in thediscussion of invoking the import utility from the Buildtime folder in FlowMarkV2.1 Modeling Workflow. Since BMT has already checked the FDL script beforegenerating it, you should not experience any major problems importing this toFlowMark. However, you should check all the object names in the FDL andmake sure they conform with the syntax of names that FlowMark imposes. Thesyntax of names can be found in FlowMark V2.1 Modeling Workflow.

When importing FDL, FlowMark first scans the FDL to see that the definitions youare going to import in the database do not conflict with definitions alreadyexisting in the database. FlowMark provides you several options when thishappens:

• Ask for a decision• Take existing objects• Rename New objects• Overwrite existing objects.

Figure 59 on page 169 shows an example of the MTGEPLOV.FDL file about to beimported to FlowMark.

168 Beyond BPR

Figure 59. Import Window in FlowMark

To be sure that you preserve critical data, you have to know what definitions areimportant in your current FlowMark database, and what definitions you are goingto import from your FDL.

If you generate the Universal Trust Company mortgage application PLOVC inBMT, you will get the entire Mortgage PLOVC. Edit the FDL to include only theactivities from AC3 through AC13, and import this FDL to FlowMark. If you viewthe process diagram, you will see a workflow model that looks like Figure 60 onpage 170.


Figure 60. FlowMark Diagram of the Mortgage Application Imported From BMT

Notice that FlowMark lays out the program activities vertically. However, theprogram activities, the control connectors, and the data connectors are exactlythe same as those you created earlier in Figure 50 on page 158.

The amount of staff and program definitions the imported workflow model willhave in FlowMark will depend on how much information you defined in BMT. Itis always good for you to check these folders to ensure that these definitions arecomplete.

However, BMT does not pass data definitions because the data structuredefinitions of FlowMark are far more sophisticated than that of BMT. Becausethe LOVCs do not focus on data entities, BMT does not do so as well. Therefore,in FlowMark, you need to create new data structures or use existing ones for theworkflow models that you import from BMT.

170 Beyond BPR

10.5 From LOVCs to FlowMark ImplementationIn a reengineering project, after the LOV As Is charts have been established andthe To Be models have been drawn in BMT, FlowMark can be used in verifyingthe To Be models. Start from To Be PLOVCs and JLOVCs. Using FlowMark′sstrong affiliation with BMT, the task of migrating from these BMT charts toFlowMark ′s Buildtime process diagrams becomes very fast and easy.

You can test each alternative model through the animation facility of FlowMarkBuildtime if you want to assess these immediately. Or you can develop simple,easy to develop yet functionally rich application prototypes (in REXX forexample) and execute these in FlowMark Runtime to delve into more substantialtesting of your alternative models. Either way, FlowMark helps you to assessimmediately your alternative To Be models, resulting in a shorter reengineeringcycle.

Even though you are not going to implement workflow, FlowMark can help youvisualize the sequence of activities of your entire LOB process. You cansimulate all your automated and manual processes, and test how they willbehave given different inputs. You can even test your application programs indifferent operating systems to find out which operating system works best foryou. FlowMark therefore provides you the flexibility to change the environmentand conditions that your applications will run in, allowing you to find the mosteffective way to implement your applications.

Once you have selected a To Be model to implement, you have to decide if youwill implement your LOB using workflow technology. FlowMark provides benefitsin the following areas:

• Application integration• Flow independence• Parallel development of programs.

Before you implement your applications in FlowMark Runtime, you should definein your workflow model your production applications. Once that is done, you canimmediately implement your workflow model in production.

FlowMark therefore allows you to take off quickly from your business modeldesigns. It extracts these models from the BMT FDLs and converts them intorunning models for your evaluation. When you have selected a model, FlowMarktranslates this model to an executable form. By simply associating the selectedmodel to running applications, you can implement your process model inproduction right away. FlowMark shortens your reengineering cycle, allowingyou to provide improved customer service with a well-studied solution at theearliest possible time.


Summary

Business process reengineering is the prescription of how the companyperforms a particular LOB in an optimal manner. FlowMark allow a companyto provide the right piece of work at the right time to the right personsupported by the right application. Furthermore, the auditing features ofFlowMark allow the monitoring of the execution of each process instance andthe checking of the appropriateness of the overall performance of a businessprocess according to the company′s goals. This can result in either constantimprovement of a process or reinitiating business process reengineering ofparticular processes.

172 Beyond BPR

Part 4. Conclusions


174 Beyond BPR

Chapter 11. Closing Thoughts

There is strong evidence the modern organization, which traces its origin to theearly days of the twentieth century in North America and spread to Europe andJapan after World War II, is undergoing a dramatic transformation.

This style of organization, which had its origins in the work of Adam Smith whofirst described the idea of division of labor as an organizing principle, was laterrefined by Frederick Taylor, Henry Ford, and Alfred Sloan. Frederick Taylorapplied division of labor to the British factory early in the twentieth century andHenry Ford adapted it to the assembly line. Sloan′s contribution came in the1920′s when, as the head of General Motors, he brought the division of labor tomanagement as a means of controlling the complex and rapidly expandingGeneral Motors empire.

In these types of organizations, management′s role was to ensure the workers′tasks were well defined, measured, and controlled. Managers regarded theirsubordinates as little more than a factor of production and tried to make thembehave in the same manner as the machines they supported. The managersdesigned systems, procedures, and policies that would ensure all employeesconformed to the company way. The goal was to make the middle managers′and workers ′ activities more predictable and thus more controllable. Changewas discouraged because it made machinery obsolete, forced costlychangeovers, and reduced managerial control.

This organization style, which still prevails in many of our corporate andgovernment organizations, was designed to manage growth in the stableenvironment characteristic of the post-World War II era. However, this era isdrawing to a close and organizations designed to ensure control and conformityface a difficult transition if they are to deliver the creativity and initiative that thenew, global economy demands. But what is driving this change, and why now?

11.1 The Rise of the CustomerFor most of this century, the supplier held the balance of power in thecustomer-supplier relationship. Now, as the economy globalizes, power isshifting to the customer. It is no longer sufficient for an organization to deliveran innovative product, or a low-cost product, or a high-quality product; today′sconsumers have grown accustomed to receiving all three in the products theybuy.

This evokes a second major change. As customers become increasinglyselective about their purchases, competition among those supplying thesecustomers intensifies. Any product or process advantages a supplier achievesover its competitors typically proves fleeting and is quickly nullified by acompetitive response.

Finally, this change in the customer, and the response from the organizationsthat serve them, has produced a third major characteristic of the new economy.That is, lasting competitive advantage can only be achieved by organizationsthat can cope with continuous change. If satisfying a customer′s needs is theprimary organizing principle and there are a number of capable suppliers, tosucceed, an organization must structure itself to deliver ever-increasing value to


its chosen customers. As many commentators have pointed out, successfulorganizations are those that operate in such close association with theircustomers and marketplace that new customer needs and desires are sensedalmost before the customer articulates them. These organizations then use ahighly developed process capability to translate these vaguely articulated needsinto new products or services.

While we developed our scenario from the perspective of a commercialorganization competing in a marketplace, the same pressures face governmentagencies today. As the electorate becomes more discriminating and has itsexpectations of quality and choice raised by the private sector, it expects higherquality and more responsive government service. When combined with the callsfor government to control and reduce their deficits, there is growing pressure ongovernment to streamline its service delivery.

These pressures are forcing many organizations to rethink their strategy andleading many to conclude they must reengineer and transform theirorganizations to remain competitive in the new economy. This decision toreengineer is often driven by the need to achieve major gains in:

• Customer satisfaction• Customer service and quality• Cost reduction and cycle time improvement• Employee morale• Competitive position.

Although transformation projects can be conducted at any level of anorganization, if radical transformation involving major organizational processesis undertaken, it must be initiated, driven, and actively supported by seniormanagement. Once senior management sets the new strategy, the focus of thetransformation effort shifts to the development, or reengineering, of newbusiness processes that execute the new strategic direction.

11.2 Understanding Business ProcessesAs we discussed in this document, conducting business is fundamentally theconveying and managing of commitments between an organization and itscustomers. If we assume a customer is satisfied when the product or servicedelivered matches what was committed, it follows that managing the contents ofthe customer-supplier communications becomes a significant focus area forunderstanding and reengineering business processes.

These moments of truth are the communication between customer and supplierthat begin with an opening phase, during which the customer identifies theirrequirements, and continue with a negotiation phase where the customer andsupplier agree on the details of the supplier′s work product, the timing of itsdelivery, payment, and any other conditions. This negotiation phase can takeplace in a single conversation or over an extended period, but it is essential itoccur because it establishes the conditions of satisfaction that, if fulfilled, resultin customer satisfaction. It is also important because it provides the basis, afterthe performance phase, for an assessment phase in which the customer acceptsor rejects the work product and valuable information about the success or failureof the process is collected.

While the most obvious customer-supplier communication takes place betweenan external, paying customer and an organization′s point of customer contact,

176 Beyond BPR

this initial contact will typically spawn a number of activities inside theorganization to fulfill the commitments made to the paying customer. Theseinternal activities exhibit the same four phases of customer-suppliercommunication—opening, negotiation, performance, and assessment—as thecustomer-supplier exchange with the paying customer. A complex product orservice can involve linking a number of these customer-supplier communicationsin order to fulfill the commitments made to the external customer.

A final characteristic of the customer-supplier communications approach thatmakes it valuable for understanding business processes is that a completecustomer-supplier communication can represent all possible outcomes of atransaction. Many traditional process definition techniques decide the outcomesof the process during the initial definition of the process, making it difficult forthe process to respond to unforeseen or special circumstances and leading tothe classic response of a bureaucracy: “We don ′ t have a procedure to handleyour case.” The negotiation phase provides the flexibility to determineconditions of satisfaction on a case-by-case basis, empowering employees torespond effectively in customer moments of truth and providing aninformation-gathering opportunity valuable for future process improvement.

These three deceptively simple concepts are the key building blocks for anunderstanding of business processes. To reiterate, they include:

Customer-supplier communications, consisting of an opening, negotiation,performance, and assessment phases.

Linked customer-supplier communications. The basic customer-suppliercommunication can be linked with other customer-supplier pairs to the depthnecessary to complete even complex activities.

Completeness of customer-supplier communications. All possible outcomesof the communication can be identified and documented.

11.3 From Theory to PracticeBecause the building block of a business process is an individualcustomer-supplier relationship and a complete business process consists of alinked series of these relationships, a business process can be documented bydefining the details of its individual customer-supplier relationships. LOVEM-Eprovides this support through a business process engineering method. Themethod is based on a graphical process description language that can be usedby business professionals and analysts to document and design anorganization ′s processes.

Using the LOVEM-E symbols and diagrams, the customer-supplier relationship ismodeled as a set of adjacent bands on a LOVEM-E diagram. The model can beexpanded to the depth necessary to represent the customer-supplierrelationships with a special band reserved for the customer-supplier relationshipinvolving the external, paying customer. This relationship occurs through whatis known as the line of visibility, a LOVEM-E device which focuses attention onthe importance of the customer view of the business process.

Through its graphical representations, known collectively as line of visibilitycharts (LOVC), LOVEM-E can be used to show the relationship between anorganization or business unit and its customers at the business process or job

Chapter 11. Closing Thoughts 177

level. The various LOVCs highlight not only service encounters with customers,but also:

Internal interfaces, hand-offs, and dependencies.

Processes, activities, and procedures a business performs with specificemphasis on those that involve a customer.

Major data entities and data flow that are required by a business process.

Data dependencies, or those parts of the process where information isrequired by the customer contact to ensure customer satisfaction.

Process cycle time and critical measurement points allow the capture anddisplay of critical process measurements on the LOVCs where they can becompared with target measurements that are internally developed orrepresent benchmarking data of key competitors.

Process path costing for a business process can be generated from datacaptured in LOVCs and used to compare the costs of one businessprocess design with alternative designs.

Job skill requirements are established by documenting the skill required toperform a job function in a process design. By defining skill requirementsthrough the JLOVC, business process designers can identify areas whereemployees require more training or job designs need to be restructured toimprove workload balance.

Manual/automation interface where the manual aspects of the businessprocesses interface with automated systems.

11.3.1 The Boundary Between Business Process and Application SystemWhile LOVEM-E is not a systems development methodology, its outputs canprovide a context for the development of application systems that supportreengineered business processes. Through the manual/automation line ithighlights clearly the interface between the manual activities of the process andthe application systems that support it. Using LOVEM-E can provide bothbusiness people and systems developers with valuable insight into the businessrequirements that new systems must support. LOVEM-E blueprints can be usedto:

• Build systems with a customer-oriented business process path view

• Highlight the impact systems have on customers

• Validate the systems ability to support the end-to-end business process

• Validate the systems capability to support individual jobs

• Support the design of systems with modular component functions that enablereuse and reconfiguration.

11.3.2 Business Processes and the Software Design ProcessBefore describing the relationship of business process models and workflowmanagement, it is worth digressing to position business process modelsalongside the data and process models that are typically used to developmentapplication systems.

Earlier in the document we used the ISA framework to position business processmodels with traditional data and process models. The ISA framework suggestsan information system is built using a variety of different models, each suited to

178 Beyond BPR

a different purpose. It provides a systematic way of relating real worldphenomena to their representation in computers and application systems. Forexample, ISA suggests there are three major models useful for describing aninformation system:

• Business model• System model• Technology model

Each of these models, in turn, can be viewed from six different perspectives orviews:

• Data• Function• Network• People• Time• Motivation

Combining the three models with the six views produces the framework shownin Figure 61.

Figure 61. Information Systems Architecture

The data and process models that are traditionally used to design and buildapplication systems map into the ISA framework in the fashion shown inFigure 62 on page 180.


Figure 62. Data and Process Models and Information Systems Architecture

In this document we have suggested that business process models, while not yetas formalized as data and process models, are a valuable addition to applicationsystems models because they provide additional insight into application systemrequirements through their focus on the business process support requirements.Figure 63 shows the positioning of business process models (lighter shading)within the ISA framework.

Figure 63. Business Process Models and Information Systems Architecture

180 Beyond BPR

It seems that intuitively obvious models that consider the people, time, andmotivation perspectives of an information system would be valuable in producingapplication systems that more closely model the real world. The ISA frameworkmakes clear that traditional process and data models, by only dealing with thedata and function views from the technology and system model perspective,cannot capture all the details of something as complex as a modern businessprocess.

While it is early in the evolution of business process models, and nodiagramming standards exist, we expect this will be an area of increasingactivity and, over time, we expect to see formal business process diagrammingstandards emerge that should permit tighter integration between businessprocess and data and process models.

11.3.3 From Models to ActionWorkflow management is an exciting technology that is complementary to thebusiness process modeling process. Some of the more advanced businessprocess reengineering methods, such as LOVEM-E, provide computer-basedbusiness tools that enhance the documentation process and enforce consistencyin the design of the business process. Enforcing consistency can produce amodel that is sufficiently detailed to support migration of the business processmodel directly to workflow management software. The workflow manager canthen execute the model and orchestrate the resources necessary to completethe process, such as application programs, data, and people.

A workflow management application maintains the process flow and dispersal ofwork separately from the software that implements the business rules and dataaccess. Because the process model is maintained and executed by the workflowmanager, an application can be implemented in a modular fashion in whichdifferent components of the application are spread across different machines ina heterogeneous environment. The workflow manager uses the definitions in itsworkflow to dynamically call applications at run time, providing an applicationdeveloper and system administrator with great flexibility in locating andchanging application components.

Workflow application development can also be highly productive. Usinggraphical construction and test techniques, the process model can be developedand tested quickly, which simplifies the development of application componentsthat enforce business rules and manage persistent data. Because thesecomponents typically consist of small, distinct pieces of software withwell-defined interfaces, they lend themselves to rapid reconfiguration and easymaintenance.

Once installed, a workflow application can use process metrics establishedduring the reengineering phase to record process performance information. Thisinformation can be further analyzed by process designers and yield valuableinsight into further process improvement opportunities.

11.3.4 Business Processes and Application DevelopmentAlthough a detailed discussion of the transition from business process models toapplication system design models is beyond the scope of this document, wewant to share a few general observations on the role of business processmodels in the application development process.


Business processes provide a context for application systems. Becausebusiness process support is the primary justification for investment ininformation technology in most enterprises, formally recognizing the role ofbusiness processes in the application development process is a valuableextension to traditional information systems modeling approaches.

Documentation is aimed at business users. Because business professionalsare the primary audience for business process analysis and design, thedocumentation is oriented towards a business, rather than systems,professional. In spite of this original orientation we believe business processmodels can offer valuable insight into system requirements for systemsdesigners.

Function modeling. Business process modeling tools do not provide detailedfunction models. It can be valuable to extend a business processreengineering project to include function modeling at the level of thebusiness professional to provide a more complete set of models for systemsdesign.

The business process to workflow link. With the advent of linkages betweenbusiness process modeling and workflow management tools there are newopportunities to tightly integrate business processes with applicationsystems.

Business process models are implementation independent. There is noimplementation decision implicit in business process models; they produceoutputs that can be useful in data design, procedural program design, andobject-oriented design.

11.3.5 The Goal: Dynamic Business ProcessesWe have emphasized throughout this document that organizations are entering aperiod of discontinuous change that will challenge their ability to respond. Theability to both reengineer and continuously improve business processes will becritical to maintaining competitiveness in the new business environment.

With a strong process management capability, an organization can usereengineered processes not only to implement today′s strategy but also tocompete with a weapon that shapes future strategy. A number of leadingcompanies are already competing using a superior process capability as a basisfor the development and delivery of new products. As Figure 64 on page 183suggests, there is evidence a strong process capability is a necessary precursorfor the mass customization organization whose process capability is soadvanced it can create new products that are tailored to individual customers.

182 Beyond BPR

Figure 64. New Dimensions of Competit ion

This new competitive strategy, in which an organization′s strength is rooted in itsprocess management skill, will become characteristic of successfulorganizations in the years to come. We hope the tools and techniques outlinedin this document can serve as a starting point for transforming your organizationinto one positioned to prosper in the new, global economy.


184 Beyond BPR

Appendix A. Customer Relationship Management Processes,Operational Roles, and Responsibilities

This appendix describes the processes, operational roles, and responsibilitiesthat make up the Customer Relationship Management (CRM) process.

A.1 ProcessesThe CRM process consists of the following subprocesses:

Market Management, the set of activities that enables a business entity tomake informed and sound judgements regarding the market segments itchooses to pursue, the solutions it needs to deliver to customers withinthose segments, the resources it needs to allocate, and the return oninvestment it should expect.

Relationship Management, the set of activities that IBM and business partnerpersonnel use to understand our customers, share that understanding withthose who need it, identify opportunities based on customer understanding,respond to customer requests, and manage all of our contacts withcustomers so that expectations and commitments are met.

Opportunity Management, the set of activities that evaluates the relativeattractiveness of opportunities by qualifying, comparing, ranking andultimately selecting the ones to pursue. Through a link to skills managementthe right resources are identified and assigned to selected opportunities.

Service and Support, which includes building customer support plans,managing customer support requests, preventive maintenance activities,product support, and parts management.

Solution Design and Delivery, which includes all activities required to reviewand understand an opportunity, define a solution, create a proposal, build,test and deliver the solution as well as generate a bill and administer thecontract.

Customer Satisfaction Management, which includes building a strategy formeeting customer expectations and increasing customer satisfaction withIBM, understanding the root cause of dissatisfaction, resolving customerissues, and measuring our success by collecting customer feedback.

Skills Management, which ensures that market-valued skills are available bybuilding the skills to support the market segment plans. It provides aninventory of those skills in order to deliver the right skill, at the right cost, tothe right place, at the right time.

Offering Information Management, which collects the information about allhardware, software, services, and solutions developed throughout theextended IBM enterprise, and distributes it to all customers, businesspartners and IBMers who request information about IBM′s offerings.

Information Management, which builds an information warehouse throughunderstanding information requirements, identifying sources of information,sharing the information, and improving the process for acquiring theinformation.


Supplier Management, the process that identifies, selects, and buildspartnerships with suppliers that support and enhance our ability to satisfyour customers.

Business Partner Management, the process that identifies, selects, and buildsstrong working relationships with business partners, who support andenhance our ability to satisfy our customers.

A.2 Operational Roles and ResponsibilitiesThe CRM process includes the following roles and responsibilities:

Opportunity Noticer, who can be anyone in IBM. The objective is not only tomake known all opportunities found during the course of business, but alsoto allow anybody having information on any lead to ensure it is registered.However, for a detected opportunity to be registered, another role isrequired, the opportunity identifier.

Opportunity Identifier, who:

• Qualifies the client by collecting information on the client′s needs,financial commitments, and the conditions of satisfaction

• Decides whether to pursue the opportunity• Registers the opportunity, identifies the market segment, and selects the

opportunity owner.

Opportunity Owner, who is responsible for managing the customerrelationship throughout the life of the opportunity. This includesresponsibility for customer satisfaction, and for IBM quality and profit. Theopportunity owner determines if additional assistance is needed to evaluatethe opportunity and can request it from a qualify helper, located through theresource coordinator.

In qualifying the opportunity, the opportunity owner must answer thesequestions:

• Is this a defined customer project?• Has the customer budgeted for this opportunity?• What is the strategic value to the customer?• Is the customer part of a larger enterprise? If so, has the complete

enterprise value of the customer been considered in evaluating theopportunity?

• Can we meet the customer′s conditions of satisfaction?• Do we have a competitive solution?• What kind of pricing and profitability are realistic?• Is the opportunity strategic to IBM?• Is the project achievable from the perspective of available skills?

Qualify Helper, who assists the opportunity owner in qualifying a specificopportunity. This is an optional role. The qualify helper provides subjectmatter expertise needed to determine the viability of the opportunity.

Opportunity Business Manager, who evaluates the entire portfolio ofopportunities that can exist within the business unit, unlike the opportunityowner, who views only one opportunity at a time. The opportunity businessmanager is responsible for ranking opportunities according to how they canachieve the objectives of the business unit. When evaluating an opportunity,the opportunity business manager looks at several factors:

186 Beyond BPR

• The opportunity′s strategic value within the unit′s market segmentbusiness plan

• The strategic value of the opportunity considering worldwide unitinterests

• Competitive pricing and profitability• Availability of human resources• Availability of possible preexisting solutions• Availability of financial resources.

The decision on whether to select an opportunity for pursuit is made afterthe opportunity business manager has evaluated, ranked, and determinedresource availability for the entire portfolio of potential opportunities. Theopportunity business manager then notifies the opportunity owner of thedecision. The opportunity owner then presents the decision to the customer.

Proposal Team Leader, who defines exactly what the offering to the customerwill be. The proposal team leader builds the proposal plan and owns itscontents. As owner of the proposal content, the team leader establishesplans and dates and coordinates all proposal documents.

The responsibilities of the proposal team leader include:

• Understanding customer requirements• Obtaining and managing resources• Working with specialists to match IBM offerings to customer

requirements• Managing the proposal creation process and communications with all

parties• Ensuring that all appropriate elements are in the solution.

The proposal team leader works with the solution team to determine thesolution′s:

• ComponentsHardwareSoftwareServicesFinancingMaintenance

• Terms and conditions• Milestones• Financing.

The responsibilities of the proposal team leader can be fulfilled by theopportunity owner if the proposed solution is simple.

Proposal Solution Architecture Team, which develops the solutionarchitecture and ensures its technical feasibility and integrity. The team isresponsible for:

• Providing specialized skills• Value-pricing the total solution• Writing the proposal or statement of work.

The statement of work will become part of the contract between IBM and thecustomer. It must be clear and accurate. It provides appropriate detail on:

• The configuration and components of the solution• The work products to be delivered to the customer• The completion criteria for the solution.

Appendix A. Customer Relationship Management Processes, Operational Roles, and Responsibil it ies 187

The solution team can consist of one person or many, depending on theexpertise needed during the development of the proposed solution.

Quality Assurer, who ensures both the customer′s and IBM′s businessrequirements are met and is responsible for improving the quality of thesolution′s implementation.

The quality assurer looks at the delivery plan for the solution, and thesolution itself, and the level of risk posed by the solution and asks thesequestions:

• Will this solution work successfully?• Can we deliver the specified services within the quoted price?• Can we install this solution properly?

Delivery Team, which focuses on effectively delivering the solution. The firstactivity for the delivery team is developing the project management plan forthe solution. This plan is reviewed with quality assurance to ensure we meetthe customer′s conditions of satisfaction including certain milestones.

The delivery team is directly responsible for meeting three major milestonesfor the project:

• Building the solution• Testing the solution• Delivering the solution to the customer.

Project Team Leader, who manages the execution of the contract and isresponsible for:

• Registering the contract• Ordering products and services• Ensuring that necessary quality assurance reviews are completed• Managing the project schedule• Closing the project• Collecting customer feedback after the solution has been delivered• Starting any support for the solution

Resource Coordinator, who is responsible for validating requests for skillhuman resource, identifying, selecting, and assigning people to businessopportunities.

Feedback Collector, who collects data from customers on their relationshipswith IBM, on our products and services, and on our customer encounters.This data can be collected through telephone, mailings, face to face, orelectronically. The feedback collector captures and categorizes answers andissues requests and comments. The feedback collector also identifieschanges in the customer profiles and makes appropriate updates.

Resolution Owner, an individual who has been assigned a customer issue tobe resolved within a predetermined period. The resolution owner isresponsible for managing the customer′s satisfaction, perceptions,expectations, and reactions. The resolution owner is expected to develop anaction plan that meets the customer′s expectations and to track that actionplan.

188 Beyond BPR

Glossary

activity. A manual process component, usuallyassociated with a job. It receives information, actsupon it, and sends it to a downstream activity, asystem, a customer, or other external or internalinterface.

architecture line of visibility chart (ALOVC). Thegraphical representation of the essential customerand enterprise processes and key data needs andtheir main characteristics arranged in a sequence.

As Is. The depiction of the current businessprocesses or environment.

band. The horizontal section on an LOVC thatcontains the processes or activities of a major logicalprocess or function, like marketing or order , or aphysical organization, like a department or a job.

bus. A term borrowed from electrical engineering (orcomputer design) that signifies a continuum withconcrete contact (entry and exit) points. In thismanual, it represents a continuum of repetitive andunpredictable processes, a set of sequential datastores, or a continuum for capturing critical processquality measurement points.

business process. See process

business process reengineering (BPR). A disciplinedapproach to radically changing business processes.

client/server. An information systems structure thatsplits (distributes) the applications, data, or servicesbetween two or more systems.

constrained. Pertaining to, or characteristic of, thePLOVC and JLOVC techniques, or representative ofthe factors that define how a process or job isperformed (for example, time, organization, andtechnology are constraining factors).

critical measurement point (CMP). Any point on theprocess path or within a job that is of criticalimportance, and where a measurement should betaken. Measurements can be in units of time orquantity.

critical success factor (CSF). A qualitative orquantitative measure that defines the quality orperformance of a business, a process, or a processpath.

customer. A person or business that acquiresproducts or services from a business.

customer process. The actions or processesperformed by customers.

customer satisfaction. The goal of any business.Customer satisfaction occurs when a customerreceives as much as or more than expected from aproduct, service, or both.

data bus. On an ALOVC or an LLOVC, a logical set ofdata, starting at the beginning of a process path andcontinuing along the path, to reflect the most currentdata at any point in a relationship with a customer.

data dependency. Data that a process requires toproceed. An upstream data dependency is datarequired from the preceding process. A downstreamdata dependency is data required by the next process.

data flow. A packet of data in motion. It can consistof data groups, data entities, and data elements. It ismainly used as a hierarchical process decompositiontechnique, representing the processes a businessperforms and the data that flows between them.

electronic data interchange (EDI). Acomputer-to-computer connection between twocompanies. The transaction flow for EDI transactionsis regulated through international protocol.

enterprise. A company or business, usuallycomprised of several lines of business.

enterprise architecture. A business processarchitecture at the enterprise level as expressedthrough an ALOVC. It is at the logical, unconstrainedlevel and shows the essential process and data needsin sequential form.

entity. A thing or object of importance to a businessabout which the business wants to keep information.

entity-relationship (E-R) diagram. A data modelingtechnique that graphically depicts data entities andthe relationships that exist between them.

first touch, only touch. A principle of conductingbusiness with a customer. The design point for acustomer service oriented business, that provides forsatisfying the customer at the first contact point withthe business.

hand-off. The passing of a product, information, orother materials from one department or workstationto another.

hierarchical structure diagram (HSD). A simple,graphical decomposition showing the hierarchicalstructure of a process and its subprocesses, down tothe lowest level. An organization chart.

icon. A picture that represents the actual image orfigure.


information. Facts or objects that have meaning tohuman beings, as opposed to data, which requirescontext and interpretation in order to becomeinformation .

information flow diagram. A graphical representationof the physical characteristics of a static processmodel. It is mainly used as a hierarchicaldecomposition technique for manual activities andsystems functions.

information systems architecture (ISA). A logicalconstruct for defining and controlling the interfacesand the integration of all the components of aninformation system.

internal interface. An interface between two internalbusiness functions, departments, or jobs where adependency exists or a transfer takes place.

job. The physical implementation of businessprocesses, as expressed through manual activitiesand interfaces with customers, systems, and internalor external organizations.

job line of visibility chart (JLOVC). A businessprocess modeling technique that shows theeffectiveness and efficiency of one particular job thatyou are studying. You focus on how the process pathis or will be implemented, and who is or will beexecuting the manual activities. It also shows therelationship of each activity to customer processes,automated systems, and internal or externalorganizations.

line of business (LOB). A family of either, or both,products and services, having commoncharacteristics.

line of visibility (LOV). On an LOVC, a line betweenyour customer and internal processes where all pointsof contact (service encounters) between yourcustomer and your business are shown.

line of visibility chart (LOVC). The graphicalrepresentation of all aspects of your businessprocesses that are required to provide your customerwith a specific product or service, showing all pointsof contact with the customer.

logical line of visibility chart (LLOVC). A businessprocess modeling technique that shows theeffectiveness of the process path that you arestudying. Using this technique, you focus on what theprocess path is doing, not how it is or will beimplemented.

logical-to-physical transformation. The translation ofa logical process into its physical implementationcomponents, l ike manual activities or systemsfunctions.

logical transformation lists (LTLs). A technique fortransforming logical processes into physicalimplementation scenarios.

manual-automation interface. The interface betweena manual activity and an automated system.

measurement. The extent, quality, or size of anobject.

methodology. A collection of related techniques andformalisms based on a common philosophy to solve aseries of major tasks.

model. Graphical representations of observationsand predictions from different perspectives of how adesign could or should look; usually at various levelsof abstraction and detail.

modeling. Part of the design process used to createalternatives or what if scenarios before committing tothe final design.

physical line of visibility chart (PLOVC). A businessprocess modeling technique that shows theeffectiveness and efficiency of the process path thatyou are studying. Using this technique, you focus onhow the process path is or will be implemented.

process. A business function or operation thatachieves business results for a customer or client,with input from suppliers. A process transforms thenature, status, or composition of an input to producean output according to business rules and policies.

process path. A sequence of processes, activities, orjobs that complete a cycle and start and end with acustomer service encounter.

relationship. A descriptive association between twodata entities in a data model. Expresses the businessrules that govern the entities.

service encounter. Any point of contact with yourcustomer.

time line. A notation on the PLOVC and the JLOVCthat shows the time that elapses between individualactivities or for a whole process path or job. Timelines can show both actual and target measurements.

To Be. A chart or diagram showing how a businessprocess is to work in the future.

unconstrained. Pertaining to, or characteristic of, theALOVC and LLOVC techniques, or representative ofthe factors that define what a process is doing, nothow it is being done.

workflow. A sequence of activities (units of work). Amovement of units of work through a process.

190 Beyond BPR

List of Abbreviations

AIR assumption, issue, andrecommendation

ALOVC architecture line of visibil itychart

BLO branch loan officer

BMT Business Modeling Tool

BPM business process modeling

BPR business processreengineering

BT business transformation

CICS Customer Information ControlSystem

CMP crit ical measurement point

CRM Customer RelationshipManagement

CSF critical success factor

DLL dynamic l ink l ibrary

DSOM Distributed System ObjectModel

EDI electronic data interchange

E-R entity-relationship

FDL FlowMark definition language

GSP goals, strategies, and policies

GUI graphical user interface

HLLAPI high-level languageapplication programminginterface

HQ LS headquarters legal services

HQ MPO headquarters mortgagepayment office

HQ REA headquarters real estateadministrator

HQ SO headquarters signing officer

HSD hierarchical structurediagram

IBM International BusinessMachines Corporation

IMS Information ManagementSystem

ISA information systemsarchitecture

IT information technology

ITSO International TechnicalSupport Organization

JLOVC job line of visibility chart

LLOVC logical line of visibility chart

LOB line of business

LOV l ine of visibility

LOVC l ine of visibility chart

LOVEM-E Enhanced Line of VisibilityEngineering Methodology

LTL logical transformation list

NPT nonprogrammable terminal

OO object-oriented

PCX picture exchange files

PLOVC physical line of visibility chart

SOM System Object Model

TIFF Tag Image File Format

3GL Third-generation language

4GL Fourth-generation language


192 Beyond BPR

Index

Aabstraction 58activi ty 90ALOVC

components 59cross service encounter data bus 62customer band 61logical roles 62LOV 61process quality management bus 63service encounter support bus 61

structure 59success factors 64

application developmentobject-oriented 97process-based 95

verif ication 97workflow-based 96

architecture line of visibil ity chartSee ALOVC

As Isdocumenting 81

logical view 81physical view 82

BBMT

basic activities 102analyzing, improving, and monitoring the

process 103gathering information 102modeling business processes 102

complementary modeling techniques 111HSD 111LTL 113

componentscorresponding to FlowMark components 156

generating workflow scripts 109FDL 110

using 103export facil ity 107LOVCs 108

BMT business modelscharting do ′s and don′ ts 107Editor 105

band area 106drawing area 106menu bar 105status area 106symbol palette 105tool bar 105

objects 104assignable objects 104charts 104

BMT business models (continued)objects (continued)

HSDs 104logical objects 104organizations 104

BPRfrom theory to practice 177goal 182roadmap 80success factors 85understanding 176with FlowMark 172

Business Modeling ToolSee BMT

business processautomation of 10CRM example 22customer-supplier approach 15data component 50, 53logical 50, 53, 56, 58measurement 14, 63, 72, 82, 88, 102

basic types 14critical measurement points (CMPs) 63, 67critical success factors (CSFs) 63, 67goals, strategies, and policies (GSPs) 63, 67maturity rat ing 55, 56, 64, 72, 78

model 84, 91physical 50, 53, 56, 58process definition approach 14

business process modelingmethodologies 36, 49

criteria for choosing 79new process 21radical BPR 78redesign process 22, 79techniques 27

HSD 111LTL 113

tools 22, 36, 49, 88, 94, 96, 102ISA classification 36

business process reengineeringSee BPR

business transformation 51

Cchange 5, 88, 119, 175, 182common specification language 50, 51constraints 59, 82, 83CRM

approach 23customer requirements 24operational roles 24processes 24responsibil i t ies 24


CRM (continued)operational roles and responsibil it ies 186

delivery team 188feedback collector 188opportunity business manager 186opportunity identif ier 186opportunity noticer 186opportunity owner 186project team leader 188proposal solution architecture team 187proposal team leader 187qualify helper 186quality assurer 188resolution owner 188resource coordinator 188

overview 23processes 185

business partner management 186customer satisfaction management 185information management 185market management 185offering information management 185opportunity management 185relationship management 185service and support 185skil ls management 185solution design and delivery 185supplier management 186

sample transaction scenarios 24customer request for a customized solution 24

customerrise of 175satisfaction 13, 14, 50, 52, 53, 55, 71, 77, 81, 82,

84, 102, 176service encounter 50, 52, 53, 54, 61, 64, 65, 69,

75, 81, 83, 178Customer Relationship Management

See CRMcustomer-supplier relationship

accountabil i ty 10commitments 11, 12

estimates 19communications 12

completeness 177four phases 13, 176, 177linked 177

customer-supplier relationshipmissing phases 17

assessment 17negotiation 17

missing roles 17roles 19, 21supplier 21

Ddata entities

contact 62offering 62

data entities (continued)promise 62

division of labor 175DSOM 98

EEDI 59electronic data interchange

See EDIEnhanced Line of Visibility Engineering Methodology

See LOVEM-E

FFDL 109first touch, only touch 62, 64FlowMark

benefitsapplication integration 150flow independence 150parallel development of programs 150

Buildt ime 150, 154animation 164creating a model 157creating data structures 159creating program registrations 159defining program activit ies 162defining staff 161modeling with 155preparing application programs 165

componentscorresponding to LOVEM-E/BMT

components 156external format 167

export uti l i ty 167import uti l i ty 167importing BMT FDL 168

from LOVC to FlowMark Implementation 171Runtime 151, 155, 159

audit trail 166executing 165process monitor 167

FlowMark definition languageSee FDL

Hhierarchical systems diagram

See HSDHSD 104

Iinformation flow, goods flow, and control flow 70information system architecture

See ISAISA

building analogy 29architect ′s drawings 29

194 Beyond BPR

ISA (continued)building analogy (continued)

architect ′s plans 29bubble charts 29contractor ′s plans 30shop plans 30

framework 178data 27, 35function 27, 35motivat ion 27, 35network 27, 35people 27, 35rules 35t ime 27, 35value 36

JJLOVC

applications 77components 72

customer band 75internal/external organizations band 75LOV 75manual/automation interface l ine 76time line 76


job line of visibility chartSee JLOVC

Lline of business

See LOBline of visibility

See LOVline of visibility chart

See LOVCLLOVC

components 65customer band 65data bus 66logical business area band 66LOV 65


LOB 53logical line of visibility chart

See LLOVClogical transformation list

See LTLLOV 57LOVC

bus 65FDL 111structure 56, 65

bus 62customer band 57enterprise band 57

LOVC (continued)structure (continued)

line of visibility (LOV) 57to FlowMark Implementation 171types 58

ALOVC 59JLOVC 72LLOVC 64PLOVC 67

LOVEM-Ebenefits 51boundary between business process and

application system 178business activity 54business process 54components 52customer activity 54customer process 54major activit ies 80

assessment phase 80planning phase 80reengineering phase 80

success factors 52use 50

LTL 103

Oobject-oriented 98

Pphysical line of visibility chart

See PLOVCPLOVC

components 67customer band 69internal/external organizations band 70LOV 69manual/automatic interface l ine 70specific function/department/job band 70time line 70


processSee business process

process path managementand LOVEM-E 53data flow 54

SSOM 98supplier

accountabil i ty 19

Index 195

TTo Be

architecting 82logical v iew 82physical v iew 83

designing models 84

UUniversal Trust Company

headquarters real estate administrator 44enter approved mortgage details 44job description 44set up property appraisal 44verify mortgage approval 44

mortgage application process 42, 63ALOVC example 61approve mortgage application 42BMT example 104commit funds 43cycle time details 43debit mortgage account 43FlowMark example 155FlowMark import example 170LLOVC example 65, 66PLOVC example 69, 70prepare mortgage down payment 43provide mortgage data 42receive mortgage data 42set up mortgage account 43VisualAge Requirements Tool example 125

real estate administratorJLOVC example 72, 76

VVisualAge Requirements Tool

advantages 118associations 123

defines 123depends 123includes 123init iates 123interrogates 123modifies 123tr iggers 123uses 123

business facts 143business information 140

facts included 141information depended on and information that

depends on 141operation containing 141rules that modify, rules that interrogate, rules

that define 141settings 141

business objects 122business operation 126

incomplete business objects 128

VisualAge Requirements Tool (continued)business operation (continued)

information dependency diagram view 128operation containing 128operation diagram view 127rules classified as 128settings and icon view 127user role view 128

business rule 132classification 137operation containing 134rules used and rules that use 134settings 134synonyms 137transactions initiated, transactions that trigger,

and transactions defined 134business transaction 128

business operation 131event notif ication 130prompt 130query 130report 130user 131

data consolidation 144data dependency relationships 142positioning 124review requirements statements with users 145sample reports 145user environment 125user requirement statement 124uses 119

communicate user requirements 120determine user requirements 119map business requirements to implementation

elements 122provide basis for evolutionary change 121provide requirements helpful for cost

estimating 121provide requirements useful for planning

tests 121provide understandable requirements 120specify required system behavior 119

Wworkflow

and BPR 88application integrator 90fitting the pieces together 154from models to action 181model 151

activi ty 152block 152connector 153control flow 153data container 153data structure 153process 152process diagram 151program 154

196 Beyond BPR

workflow (continued)model (continued)

staff 154views 90

combining 93infrastructure view 92organization view 92process view 90

workflow managementSee workflow

workflow resource managercomponents

administrat ion 93, 95buildt ime 93, 94, 96runt ime 93, 94, 96

Index 197

ITSO Redbook Evaluation

International Technical Support OrganizationBusiness Process Reengineering and BeyondDecember 1995

Publication No. SG24-2590-00

Your feedback is very important to help us maintain the quality of ITSO redbooks. Please fill out thisquestionnaire and return it using one of the following methods:

• Mail it to the address on the back (postage paid in U.S. only)• Give it to an IBM marketing representative for mailing• Fax it to: Your International Access Code + 1 914 432 8246• Send a note to [email protected]

Please rate on a scale of 1 to 5 the subjects below.(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)

Overall Satisfaction ____

Organization of the bookAccuracy of the informationRelevance of the informationCompleteness of the informationValue of illustrations

____________________

Grammar/punctuation/spell ingEase of reading and understandingEase of finding informationLevel of technical detailPrint quality

____________________

Please answer the following questions:

a) Are you an employee of IBM or its subsidiaries: Yes____ No____

b) Do you work in the USA? Yes____ No____

c) Was this redbook published in time for your needs? Yes____ No____

d) Did this redbook meet your needs? Yes____ No____

If no, please explain:

What other topics would you like to see in this redbook?

What other redbooks would you like to see published?

Comments/Suggestions: ( THANK YOU FOR YOUR FEEDBACK! )

Name Address

Company or Organizat ion

Phone No.

Cut or FoldAlong Line

Cut or FoldAlong Line

ITSO Redbook EvaluationSG24-2590-00 IBM

Fold and Tape Please do not staple Fold and Tape

NO POSTAGENECESSARYIF MAILED IN THEUNITED STATES

BUSINESS REPLY MAILFIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK

POSTAGE WILL BE PAID BY ADDRESSEE

IBM International Technical Support OrganizationDepartment 471/E2650 Harry RoadSan Jose, CAUSA 95120-6099

Fold and Tape Please do not staple Fold and Tape

SG24-2590-00

IBM

Printed in U.S.A.

SG24-2590-00

Business Process Reengineering and Beyond · understanding the business processes, a methodology...

Documents

Transcript of Business Process Reengineering and Beyond · understanding the business processes, a methodology...