SG24-2590-00
International Technical Support Organization
Business Process Reengineering and Beyond
December 1995
IBM
SG24-2590-00
International Technical Support Organization
Business Process Reengineering and Beyond
December 1995
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 VisualAge
Requirements Tool for use with the OS/2 Operating System, and Version 2.1.0 of FlowMark for use with the OS/2
and AIX Operating Systems.
Warning
This book is based on a pre-GA version of a product and may not apply when the product becomes generally
available. It is recommended that, when the product becomes generally available, you destroy all copies of
this version of the book that you have in your possession.
Order publications through your IBM representative or the IBM branch office serving your locality. Publications
are 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 been
removed, comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. 471 Building 80-E2
650 Harry Road
San Jose, California 95120-6099
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way 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 is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Abstract
This document describes the major forces driving organizations to reexamine
their business processes. It looks at an IBM-developed framework for
understanding the business processes, a methodology for business process
reengineering (BPR) called IBM′s Line of Visibility Engineering Methodology
(LOVEM), and the following IBM technologies that support the reengineering
process through the capture of business rules and requirements: ProModeler
and VisualAge Requirements Tool. Also discussed is workflow management
technology as a logical extension to the BPR process, as achieved with IBM′ s
FlowMark product.
This document is written for consultants, information systems professionals, and
IBM account teams who are working in the area of business process
reengineering, requirements gathering, or workflow management. Some
knowledge of business process reengineering concepts and traditional
application development techniques would increase the value of this publication.
(199 pages)
Copyright IBM Corp. 1995 iii
iv Beyond BPR
Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
How This Document is Organized . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
ITSO Redbooks on the World Wide Web (WWW) . . . . . . . . . . . . . . . . . xvii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Part 1. Context Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Business Processes Overview . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2. The Changing Environment . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Forces Driving Corporate Change . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Constant Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 3. A Model for Business Processes . . . . . . . . . . . . . . . . . . . . 9
3.1 The Human Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 The Customer-Supplier Relationship . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Customer-Supplier Communications . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Traditional Process Definition Methods . . . . . . . . . . . . . . . . . . . . . 14
3.5 Process Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Business Process Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.7 Who Are the Customers? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8 Case Study Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8.1 Missing Roles and Phases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8.2 Connecting the Commitments . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8.3 Estimates versus Commitments . . . . . . . . . . . . . . . . . . . . . . 19
3.8.4 Structuring Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8.5 Roles and Organization Structure . . . . . . . . . . . . . . . . . . . . . 19
3.9 Designing Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.9.1 New Process Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.9.2 Redesigning Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.10 Business Process Definition: A New Tool . . . . . . . . . . . . . . . . . . 22
3.11 An IBM Business Process Reengineering Example: Customer
Relationship Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.11.1 CRM Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.11.2 CRM Project Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.11.3 Sample Transaction Scenarios . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 4. Information Systems Architecture . . . . . . . . . . . . . . . . . . . 27
4.1 The Architecture Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 Bubble Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2 Architect′ s Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.3 Architect′ s Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.4 Contractor′ s Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.5 Shop Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Copyright IBM Corp. 1995 v
4.2 Are Architectural Representations Generic? . . . . . . . . . . . . . . . . . . 31
4.3 Different Views of an Information System . . . . . . . . . . . . . . . . . . . 32
4.3.1 ISA Framework Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Value of the Information Systems Architecture Framework . . . . . . . . . 36
Chapter 5. A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1 Universal Trust Company Overview . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Mortgage Application Process . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1 Cycle Time Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3 Headquarters Real Estate Administrator . . . . . . . . . . . . . . . . . . . . 44
Part 2. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of
Visibility Engineering Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1 Introducing LOVEM-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.1 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Components of LOVEM-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.1 Process Path Management . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.2 Process Maturity Rating and Key Indicators . . . . . . . . . . . . . . . 55
6.2.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.4 Types of LOVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Architecture Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 59
6.3.2 ALOVC Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.4 Logical Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.4.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 65
6.4.2 LLOVC Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.5 Physical Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 67
6.5.2 PLOVC Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.6 Job Line of Visibility Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.6.1 Structure and Main Components . . . . . . . . . . . . . . . . . . . . . . 72
6.6.2 JLOVC Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.6.3 JLOVC Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.7 Reengineering Using the LOVCs . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.7.1 Criteria for Choosing Business Process Reengineering or Process
Redesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.7.2 Major Business Process Reengineering Roadmap . . . . . . . . . . . 80
6.7.3 Documenting As Is Processes . . . . . . . . . . . . . . . . . . . . . . . 81
6.7.4 Architecting To Be Processes . . . . . . . . . . . . . . . . . . . . . . . . 82
6.7.5 Designing To Be Process Models . . . . . . . . . . . . . . . . . . . . . 84
Chapter 7. Workflow Management . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.1 Application Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2 Business Reengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4 An Application Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.5 Three Dimensions of Workflow Definition . . . . . . . . . . . . . . . . . . . 90
7.5.1 The Process View: What Is Performed . . . . . . . . . . . . . . . . . . 90
7.5.2 The Organization View: Who Performs . . . . . . . . . . . . . . . . . . 92
7.5.3 The Infrastructure View: Which Resources Are Used . . . . . . . . . 92
7.6 Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
vi Beyond BPR
7.6.1 Buildtime Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.6.2 Runtime Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.6.3 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.7 Process-Based Application Development . . . . . . . . . . . . . . . . . . . 95
7.8 Workflow-Based Application Development . . . . . . . . . . . . . . . . . . . 96
7.8.1 Process Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.9 Object-Oriented Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Part 3. Tools for Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chapter 8. Business Modeling Tool . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1 Basic Activities of the Business Modeling Tool . . . . . . . . . . . . . . . 102
8.1.1 Gathering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.1.2 Modeling Business Processes . . . . . . . . . . . . . . . . . . . . . . 102
8.1.3 Analyzing, Improving, and Monitoring the Process . . . . . . . . . . 103
8.2 Using Business Modeling Tool . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.2.1 Business Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.2.2 Using the Export Facility . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.2.3 Using the LOVCs of BMT . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.3 Generating Workflow Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.3.1 FlowMark and the FlowMark Definition Language . . . . . . . . . . . 109
8.3.2 BMT Generation of FlowMark Definition Language . . . . . . . . . . 110
8.3.3 From LOVCs to FlowMark Definition Language . . . . . . . . . . . . 111
8.4 Complementary Modeling Techniques . . . . . . . . . . . . . . . . . . . . 111
8.4.1 BMT Hierarchical Structure Diagram . . . . . . . . . . . . . . . . . . 111
8.4.2 BMT Logical Transformation List . . . . . . . . . . . . . . . . . . . . . 113
Chapter 9. VisualAge Requirements Tool . . . . . . . . . . . . . . . . . . . . . 117
9.1 Introducing VisualAge Requirements Tool . . . . . . . . . . . . . . . . . . 118
9.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
9.1.2 Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.2 Business Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.3 Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.4 The User Requirement Statement . . . . . . . . . . . . . . . . . . . . . . . 124
9.5 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9.5.1 VisualAge Requirements Tool User Environment . . . . . . . . . . . 125
9.6 Business Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.7 Business Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.8 Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
9.9 Business Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.9.1 Data Dependency Relationships . . . . . . . . . . . . . . . . . . . . . 142
9.10 Business Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.11 Data Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.12 Review Requirements Statements with Users . . . . . . . . . . . . . . . 145
9.13 VisualAge Requirements Tool Reports . . . . . . . . . . . . . . . . . . . 145
Chapter 10. FlowMark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.1 FlowMark Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
10.1.1 Buildtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
10.1.2 Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.1.3 Workflow Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.1.4 How These Pieces Fit Together . . . . . . . . . . . . . . . . . . . . . 154
10.2 Modeling with Buildtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
10.2.1 Creating a FlowMark Model . . . . . . . . . . . . . . . . . . . . . . . 157
Contents vii
10.2.2 Creating Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . 159
10.2.3 Creating Program Registrations . . . . . . . . . . . . . . . . . . . . . 159
10.2.4 Defining Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.2.5 Defining Program Activities . . . . . . . . . . . . . . . . . . . . . . . 162
10.2.6 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
10.2.7 Preparing Application Programs . . . . . . . . . . . . . . . . . . . . 165
10.3 Executing with Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.3.1 Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
10.3.2 Process Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.4 External Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
10.4.1 Importing BMT FlowMark Definition Language . . . . . . . . . . . . 168
10.5 From LOVCs to FlowMark Implementation . . . . . . . . . . . . . . . . . 171
Part 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chapter 11. Closing Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
11.1 The Rise of the Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
11.2 Understanding Business Processes . . . . . . . . . . . . . . . . . . . . . 176
11.3 From Theory to Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.3.1 The Boundary Between Business Process and Application System 178
11.3.2 Business Processes and the Software Design Process . . . . . . . 178
11.3.3 From Models to Action . . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.3.4 Business Processes and Application Development . . . . . . . . . 181
11.3.5 The Goal: Dynamic Business Processes . . . . . . . . . . . . . . . 182
Appendix A. Customer Relationship Management Processes, Operational
Roles, and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A.1 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10. FlowMark Information Systems Architecture Classification . . . . . . . . 39
11. Process Path Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12. Generic LOVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13. Comparison of Levels of Abstraction and Levels of Detail . . . . . . . . . 58
14. Universal Trust Company Mortgage ALOVC . . . . . . . . . . . . . . . . . 60
15. Mortgage LLOVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
16. Universal Trust Company Mortgage PLOVC . . . . . . . . . . . . . . . . . 68
17. Mortgage JLOVC for the Headquarters Real Estate Administrator Job . 73
18. Data and Flow Independence . . . . . . . . . . . . . . . . . . . . . . . . . . 89
19. A Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
20. Staff Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
21. The Workflow Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
22. Process-Based Application Development . . . . . . . . . . . . . . . . . . . 97
23. Business Models Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
24. Mortgage Application Tree View . . . . . . . . . . . . . . . . . . . . . . . 105
25. Editor Window for JLOVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
26. Export Options Pop-Up Menu . . . . . . . . . . . . . . . . . . . . . . . . . 108
27. Hierarchical Structure Diagram Choices . . . . . . . . . . . . . . . . . . 112
28. Hierarchical Structure Diagram LOVC Example . . . . . . . . . . . . . . 112
29. Hierarchical Structure Diagram Activity Example . . . . . . . . . . . . . 113
30. Universal Trust Company Mortgage Application PLOVC . . . . . . . . . 125
31. VisualAge Requirements Tool Main Window . . . . . . . . . . . . . . . . 126
32. Operation Diagram View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
33. Info Request Business Transaction Settings Pop-up Menu . . . . . . . 129
34. Info Request Business Transaction Types . . . . . . . . . . . . . . . . . 130
35. Info Request Business Transaction User Role . . . . . . . . . . . . . . . 131
36. Info Request Business Transaction General Information . . . . . . . . . 132
37. Quotation Business Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
38. Quotation Business Rule Settings . . . . . . . . . . . . . . . . . . . . . . 134
39. Quotation Business Rule Action 1 . . . . . . . . . . . . . . . . . . . . . . 135
40. Quotation Business Rule Classification . . . . . . . . . . . . . . . . . . . 136
41. Customer, Prospect, and Product Business Information . . . . . . . . . 141
42. Business Information Type . . . . . . . . . . . . . . . . . . . . . . . . . . 142
43. Information Dependency Diagram View . . . . . . . . . . . . . . . . . . . 143
44. Business Information and Business Facts . . . . . . . . . . . . . . . . . 144
45. Sample Business Transaction Report . . . . . . . . . . . . . . . . . . . . 145
46. Sample Business Information Report . . . . . . . . . . . . . . . . . . . . 146
47. Sample Business Rule Report . . . . . . . . . . . . . . . . . . . . . . . . 146
48. Sample Fact Dictionary Report . . . . . . . . . . . . . . . . . . . . . . . . 147
49. FlowMark Diagram with Program Activities . . . . . . . . . . . . . . . . 157
Copyright IBM Corp. 1995 ix
50. FlowMark Diagram with Program Activities, Control Connectors, and
Data Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
51. Data Structure of Application Data . . . . . . . . . . . . . . . . . . . . . . 159
52. Program Settings of the Verify_Mtge_Apprvl_Pgm . . . . . . . . . . . . 160
53. OS/2 Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
54. Start Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
55. Transition Page of the Control Connector Setting . . . . . . . . . . . . . 163
56. Animation of the Mortgage Application in FlowMark Buildtime . . . . . 164
57. Runtime Process Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
58. Work List Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
59. Import Window in FlowMark . . . . . . . . . . . . . . . . . . . . . . . . . . 169
60. FlowMark Diagram of the Mortgage Application Imported From BMT . 170
61. Information Systems Architecture . . . . . . . . . . . . . . . . . . . . . . 179
62. Data and Process Models and Information Systems Architecture . . . 180
63. Business Process Models and Information Systems Architecture . . . 180
64. 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 any
programming interfaces that are provided by the Business Modeling Tool,
VisualAge Requirements Tool, or FlowMark. See the PUBLICATIONS section of
the IBM Programming Announcement for FlowMark for more information about
what publications are considered to be product documentation.
References in this publication to IBM products, programs or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not intended
to state or imply that only IBM′s product, program, or service may be used. Any
functionally equivalent program that does not infringe any of IBM′s intellectual
property rights may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer′s ability to evaluate and integrate them into the
customer′s operational environment. While each item may have been reviewed
by IBM for accuracy in a specific situation, there is no guarantee that the same
or similar results will be obtained elsewhere. Customers attempting to adapt
these techniques to their own environments do so at their own risk.
The following document contains examples of data and reports used in daily
business operations. To illustrate them as completely as possible, the examples
contain the names of individuals, companies, brands, and products. All of these
names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
AIX CICS
FlowMark IBM
LOVEM-E IMS
OS/2 SearchManager/2
System Object Model Time and Place
VisualAge VisualInfo
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 is
used by IBM Corporation under license.
Copyright IBM Corp. 1995 xiii
UNIX is a registered trademark in the United States and other
countries licensed exclusively through X/Open Company Limited.
Windows is a trademark of Microsoft Corporation.
Lotus Development Corporation
Other trademarks are trademarks of their respective companies.
xiv Beyond BPR
Preface
If business process reengineering (BPR) is as powerful a tool as it appears to
be, organizations must develop the capability to analyze and redesign their
business processes. Since many elements of the redesigned processes will be
implemented as computer application systems, new modeling and
communications techniques will be required to facilitate communication between
the business person and information technologists. This publication is intended
to help consultants, customer information systems management, and IBM
account teams understand the new methodologies and tools which must be
employed to document and understand the current processes and aid in the
design of new ones. The objectives of this document are to:
• Document the major forces driving organizations to reexamine their business
processes.
• Describe a framework for understanding business processes.
• Position business process reengineering and its outputs within the
framework for information systems architecture described by John Zachman.
• Describe a methodology for BPR, IBM′s Enhanced Line of Visibility
Engineering Methodology (LOVEM-E).
• Examine technologies that support the reengineering process and the
capture of business rules and facts for use in developing application
systems. A common business process, an application for mortgage
financing, is introduced to illustrate the use of these technologies in the BPR
process.
• Investigate workflow technology as a logical extension of a process-oriented
view of business processes and the BPR process. The mortgage financing
sample 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 development
of application systems.
Some knowledge of business process reengineering concepts and traditional
application development techniques would increase the value of this publication.
Copyright IBM Corp. 1995 xv
How This Document is Organized
The document is organized in four major parts:
Part 1, “Context Setting” on page 1
This part describes the volatile business environment that is causing
companies to examine the way they do business. This part is comprised of
the 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 Enhanced
Line of Visibility Methodology and workflow management. This part consists
of the following chapters:
• Chapter 6, “Business Process Reengineering Using IBM′s Enhanced
Line 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 the
process of documenting, capturing requirements, and implementing possible
reengineered alternatives. Three tools are discussed: Business Modeling
Tool, VisualAge Requirements Tool, and FlowMark. This part consists of the
following 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 recommend
reading this part if you are interested in a summary or overview of the ideas
in the book.
Related Publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this document.
• John A. Zachman, 1987. ″A Framework for Information Systems
Architecture.″ IBM Systems Journal, Vol. 26, no. 3.
• John F. Sowa and John A. Zachman, 1987. ″Extending and Formalizing the
Framework for Information Systems Architecture.″ IBM Systems Journal, Vol.
31, no. 3. G321-0108-00.
• William H. Davidson, 1993. ″Beyond Reengineering: The Three Phases of
Business Transformation.″ IBM Systems Journal, Vol. 32, no. 1.
G321-0110-00.
• Allan L. Scherr, 1993. ″A New Approach to Business Processes.″ IBM
Systems Journal, Vol. 32, no. 1. G321-0110-00.
xvi Beyond BPR
• Sumantra Ghoshal and Christopher A. Bartlett, ″Changing the Role of Top
Management: Beyond Structure to Process.″ Harvard Business Review,
January-February, 1995.
• Michael Hammer and James Champy, Reengineering the Corporation: A
Manifesto for Business Revolution. (New York: HarperCollins, 1993),
SR28-4952-00.
• Charles Handy, The Age of Unreason. (Boston: Harvard Business School
Press, 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 MKTTOOLS
as ITSOCAT TXT. This package is updated monthly.
How to Order ITSO Redbooks
IBM employees in the USA may order ITSO books and CD-ROMs using
PUBORD Customers in the USA may order by calling 1-800-879-2755 or by
faxing 1-800-445-9269. Most major credit cards are accepted. Outside the
USA, customers should contact their local IBM office. For guidance on
ordering, send a note to BOOKSHOP at DKIBMVM1 or E-mail to
bookshop@dk.ibm.com.
Customers may order hardcopy ITSO books individually or in customized
sets, called BOFs, which relate to specific functions of interest. IBM
employees and customers may also order ITSO books in online format on
CD-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 Web
home page. To access the ITSO Web pages, point your Web browser to the
following URL:
http://www.redbooks.ibm.com/redbooks
Preface xvii
IBM employees may access LIST3820s of redbooks as well. The internal
Redbooks home page may be found at the following URL:
http://w3.itsc.pok.ibm.com/redbooks/redbooks.html
Acknowledgments
This project was designed and managed by:
Paulette J.A. Soper
International Technical Support Organization, San Jose Center
The authors of this document are:
Allan Helton
IBM Canada Ltd.
Eric Zulaybar
IBM Philippines
Paulette J.A. Soper
International Technical Support Organization, San Jose Center
This publication is the result of a residency conducted at the International
Technical Support Organization, San Jose Center.
Thanks to the following people for the invaluable advice and guidance provided
in the production of this document:
Dr. J. Carlos Goti
IBM Corporation, Santa Teresa Lab
Terry Allard
IBM Corporation, Santa Teresa Lab
Alan Brown
IBM Canada Ltd., BPR Consulting Practice
Wolfgang Trautmann
IBM Canada Ltd., BPR Consulting Practice
Enrico Zapanta
IBM Canada Ltd., Systems Integration
Michael Breidthardt
German Software Division Lab
Gerhard Mueller
German Software Division Lab
Dr. Bernd Hoffmann
German Software Division Lab
Bernd Wiedmann
German Software Division Lab
xviii Beyond BPR
Dr. Peter Deichmann
German Software Division Lab
Karl Van Leuven
German Software Division Lab
Thomas Bilfinger
International Technical Support Organization, San Jose Center
Leif Trulsson
International Technical Support Organization, San Jose Center
Laura Nystrom
Editor
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 of
today′s global marketplace. Most of these publications agree an organization′ s
survival depends on delivering new products and services on an almost
continuous basis, with ever-improving quality, better service, and decreasing
prices. However, few organizations were designed for these new competitive
rules. The traditional hierarchical organization was proficient at controlling rapid
growth during a time of rising demand, but has not proven effective at producing
the innovation and responsiveness demanded by today′s customer.
Faced with an increasingly difficult competitive environment, many organizations
are reexamining their approach and developing new strategies which enable
them to compete more effectively. The development of these strategies is
beyond the scope of this document; our interest lies in the development of the
business processes through which an organization executes its new strategy. To
set the stage and get you thinking about business processes lets consider a
typical business process, order fulfillment.
Order fulfillment includes the activities which begin when a customer places an
order and ends when the goods are delivered and payment collected. Typically,
this process involves 10 or more steps performed by different individuals in
different departments. Someone in customer service receives the order, logs it
in, and checks it for completeness and accuracy. Then the order goes to
accounting where someone runs a credit check on the customer. Next, someone
in sales determines the price to charge. Then the order travels to inventory
control, where someone checks to see if the goods are on hand. If not, the order
gets routed to production scheduling, which issues a back order. Eventually,
warehouse operations develops a shipment schedule, shipping determines the
shipment method and picks the route and carrier. Product handling picks the
products from the warehouse, verifies the accuracy of the order, assembles the
picked items, and loads them. Shipping releases the goods to the carrier which
takes 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 from
the standard process, or the customer tries to change their order once it is
initiated, the chances of meeting customer expectations drop dramatically.
Process breakdowns occur because of the number of hand-offs and transitions
and, when they do, there is little accountability because, although there are
many groups involved in the process, often no single unit is responsible for
successful order fulfillment.
To respond to the realities of the new economy, leading companies are
restructuring around the business process, in our example, order fulfillment.
The formerly hierarchic organization is flattened, replaced by a number of
process teams responsible for the major organizational processes. Employees
have evolved into process team members who more likely report to a process
owner than a manager in the traditional sense. To provide the responsiveness,
flexibility and accountability demanded by today′s customer, these teams are
empowered to make their own decisions and encouraged to make changes
which improve their processes on a continuous basis.
Copyright IBM Corp. 1995 3
Business Process Reengineering (BPR) is the term often used to describe the
collection of techniques which are used to model existing and develop new
business processes and has been used successfully by a number of
organizations to restructure the way they perform work. Because of its success,
many organizations are beginning to rethink the role of organization structure
and conclude work should be organized around the business process.
Based on the experience of its early adopters, business process reengineering
offers a set of techniques which can assist organizations in redesigning core
processes 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 and
holding market share is undergoing major change. In former times, an
organization would position itself along one of three competitive dimensions:
quality, time to market, or cost; then it would optimize its position on that
dimension relative to its competition. The quality leader, for example, was not
expected 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 one
of these dimensions. Companies are beginning to offer higher quality at lower
prices, stealing market share from competitors that used to own either the
“quality” or “low cost” positions in their marketplace. “Time to market,” or the
time from when a product is first conceived to when it becomes available
commercially, has become a matter of survival rather than a basis for
competition. Success in the marketplace of today goes to those companies who
can deliver better products faster and cheaper. Lasting advantage is difficult to
achieve and once gained is often fleeting as competitors respond to the leader′ s
product or process improvements.
That sweeping change is underway is not in dispute. Is this continuous change
of the kind we have known for the last 50 years in which the past predicted the
future? Or are we in the throes of discontinuous change which challenges us to
develop new patterns of behavior and new approaches? Charles Handy, in his
book The Age of Unreason, believes there is little doubt we are experiencing
discontinuous change.
Handy goes on to suggest that a broad historical and economic change is under
way, in which organizations are restructuring to better cope with an environment
that is highly unpredictable. He suggests these major changes follow a
predictable 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 and
new options.
New structures: The existing pattern is broken up and rearranged to give
new talent scope and break up old clubs.
New goals and standards: The new organization sets itself new aims and
targets. 1
This pattern has a ring of truth for those of us employed by corporate
organizations which have restructured and are now involved in rethinking and
redesigning their organization structures and processes. But what is driving this
discontinuous change? Why now? In the next section we consider the primary
forces that are compelling companies to reorganize.
1 Handy, Charles, The Age of Unreason. (Boston: Harvard Business School Press, 1989), p.10.
Copyright IBM Corp. 1995 5
2.1 Forces Driving Corporate Change
Many writers have documented the forces driving change in organizations.
Among these, Hammer and Champy 2 have identified three pervasive forces:
customers, competition, and constant change.
2.1.1 Customers
For most of this century the idea of a mass market has allowed sellers to treat
their 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 choice
because the market was primarily national and the few competitors offered more
or less the same products and services. Henry Ford summed up the attitude of
mass market suppliers with his famous remark, “They can have any color car
they want as long as it′s black.”
Now however, the balance of power in the seller-customer relationship has
shifted. Sellers no longer have the upper hand; customers do. Customers now
tell suppliers what they want, when they want it, how they want it, and what they
will pay. The customer′s newfound power is precipitating profound change in
firms who have known only mass markets.
Now that they are unleashed, customers are demanding products designed for
their unique needs. The mass market has fragmented, with some markets now
consisting of only a single customer. Suppliers can no longer think in general
about the customer; they must think about a specific customer, the one they are
serving at a given point in time.
2.1.2 Competition
The nature of competition is also much different than it was in the mid-1980s. It
used to be straightforward: the company that could get to market first with an
acceptable product or service at the best price would get the sale. Markets
were national and there was generally a small number of competitors who knew
each other intimately.
All this has changed. Similar goods compete in different markets according to
local rules. In one market, competition may be based on price, in another
selection, and in a third, on a combination of quality and service. Falling trade
barriers have made the marketplace global, with strong competitors driving out
the weaker ones, and the best price, highest quality, or best service available
has become the standard for all competitors.
Size is no longer automatically an advantage. Startup companies can enter a
market with the next generation of product or service and garner significant
market share ahead of the existing suppliers. A particular kind of product, such
as computers, permits even small companies the reach previously enjoyed by
only 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 Change
It may seem circular to talk about how change itself is an important change
agent in reshaping organizations; after all, it is not as though the environment
was ever truly static. What is significant about the last 10 years is the change in
the nature and rate of change. Global markets, technology, shrinking product
life cycles, and niche competitors have all combined to make the environment
more dynamic than ever, forcing organizations to consider new ways of
structuring themselves to provide the required flexibility and responsiveness.
Hierarchic organizations were designed to provide control over rapid growth and
expansion in a period of rising incomes and strong demand. The hierarchic
organization was well suited for this because it was inherently scalable. When a
company needed to grow, it added workers at the bottom of the organization and
the required number of managers in the layers above. Change was discouraged
because it increased cost by rendering equipment obsolete, reducing managerial
control, increasing the complexity of individual jobs, and producing waste and
error.
Work in these organizations was based on division of both professional and
manual labor into narrow task-based specialties. Accountability was based on
the individual task rather than overall results. The customer was taken for
granted as workers focused inward to their manager and organization.
The shortcomings of hierarchic organizations have been well documented but, to
summarize, they are generally regarded as inflexible, unresponsive, lacking in
customer focus, obsessed with activity rather than results, and costly because of
the overhead associated with linking the task-based activities. It should be
obvious by now that these characteristics make it difficult for these organizations
to respond to the types of challenges outlined in this section.
New organization designs are starting to emerge and overcome these
shortcomings. In these new designs, work is organized around processes, not
activities. Team-based structures spanning functional units overcome barriers
between functional organizations. The members of these teams are frontline
employees who monitor their competitive environment continuously, obtaining
information from a variety of sources, including customers, suppliers, and
competitors. Team members are empowered not only to redesign old,
task-based processes, but also to continuously improve the redesigned
processes. This type of control requires less supervision, reduces organization
layers, and so improves responsiveness.
There is a growing conviction in the management literature that process
definition and improvement excellence is a core capability that organizations
must develop to succeed. Moreover, it is considered a necessary phase of
organizational transformation that can lead to the development of new
capabilities, products, and services. 3
In the next section we take a closer look at the nature of business processes and
their key characteristics. This provides the building blocks for understanding the
business process design technique and methodology discussed in Part 2,
“Roadmap” on page 47.
3 Davidson, William 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 new
organization style and the primary means by which the organization executes its
strategy and delivers value to its customers. Almost equally important, it is the
mechanism through which the organization gathers, analyzes, and conveys the
information necessary for continuous process improvement. But what exactly is
a business process? Hammer and Champy define a business process:
“As a collection of activities that takes one or more kinds of input and creates an
output that is of value to the customer.” 4
While this is a reasonable high-level definition of a business process, it is
important for us to have a more detailed understanding of business processes
as background for the business process modeling technique that will be
presented in Part 2, “Roadmap” on page 47.
In this chapter we take a detailed look at the nature of business processes. We
present a model described by Dr. Allan Scherr of IBM 5 that suggests that the
communications, and resulting commitments, generated by a customer-supplier
exchange 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: Customer
Relationship 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.
Copyright IBM Corp. 1995 9
3.1 The Human Element
Understanding the nature of business processes is important because they
extend the conventional concern for tasks, activities, and data and focus on the
dimension of people and their accountabilities—their roles, agreements, and
relationships. Business processes also provide business people with a useful
tool for gaining new insights into their operations and dealing with concerns
such 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 person
and the information technologist. They provide a common language that allows
business people to express the design of their business processes in a way
meaningful to them while providing clear direction for supporting information
technology.
Although automation of business processes is the primary use of information
technology in organizations, few computer applications are designed and built
with explicit consideration of the business process they will support. Most
computer applications are designed by focusing on the procedures and data.
The primary objective of the design process is to show the relationship between
procedural elements (both computer-based and manual) and the use of data.
The people who perform the business processes and, more importantly, those
for whom they are performed, usually customers, are often not explicitly
recognized or appear as data records, input-output mechanisms, or substitutes
for programs.
Designing business processes in this manner often does not fully define the
complete range of cases to which the process might need to respond. As we
discussed in Chapter 2, “The Changing Environment” on page 5, because
customer focus is so critical to success in the new economy, a key challenge is
to design business processes that support unforeseen or spontaneous customer
requirements. New process design approaches are needed that can recognize
the central role of the customer and the importance of the communications
between the customer and supplier during a business process.
3.2 The Customer-Supplier Relationship
Scherr′s process definition technique focuses on people and the accountabilities
that arise from their roles, agreements, and commitments. 6 The term
accountability is developed more fully in the following section but refers to what
an individual is held responsible for by others. Scherr thinks consideration of
accountabilities is vital and adds another dimension to understanding business
processes 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 an
understanding of where the accountability lies for fulfilling the commitments, in
addition to the procedures and data. This is essential for a clear understanding
of the business processes.
To illustrate this point consider two hypothetical organizations: one has
completely defined procedures but no accountabilities, such as a government
bureaucracy, and the other has well-defined accountabilities but undefined
procedures, such as a startup company. Figure 1 illustrates this relationship.
Figure 1. The Accountability-Procedure Scale
Scherr defines a business process as “a series of customer-supplier
relationships that produces specific results at specific points in time.” 7 The first
customer-supplier relationship is often between an actual paying customer and
an organization representative such as a salesperson or customer support
representative who then becomes a customer of suppliers within the
organization. This customer-supplier commitment chain continues to the depth
necessary to complete the transaction. Figure 2 on page 12 shows an example
of 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 to
business processes. In the following section, an individual customer-supplier
communication and its key role as the primary building block of business
processes are discussed.
3.3 Customer-Supplier Communications
Scherr describes the conduct of business as fundamentally the conveyance of
commitments. 8 A customer who places an order, a supplier who accepts the
order, and the supplier who provides a product the customer accepts and pays
for are all enacting different elements of commitment. Thus, an order is a
commitment 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 the
supplier does not deliver an accepted order, the failure is considered a broken
commitment. An examination of the following typical business transactions
indicates that commitment is the key element of the communication between
customer and supplier:
• Applying for a loan (asking for a commitment from the bank)
• Approving an engineering change request (agreeing that a change is to be
effected)
• Requesting a salary increase for an employee (seeking commitment from
management)
8 Ibid., p. 82.
12 Beyond BPR
• Offering a customer a product or service (committing to deliver if the offer is
accepted)
• Collecting a bill (receiving payment on previously agreed upon terms)
This approach establishes commitment as the basis for communications in the
customer supplier relationship. The communications between the two parties
can be divided into four phases:
1. The opening communication that begins the conversation, either a request
from the customer or an offer from the supplier.
2. The negotiation about the supplier′ s deliverable, the payment by the
customer, timing, and any other conditions. Technically, these are the
conditions of satisfaction for the agreement. Agreement is reached when the
supplier accepts the customer′s request or the customer accepts the
supplier′s offer. Obviously, either party can counter with a request or offer
before agreement is reached.
3. The performance or production and delivery by the supplier of the goods or
services that were agreed to in phase 2, specifically, the fulfillment of the
conditions of satisfaction by the supplier.
4. The assessment and acceptance of the result by the customer. At this point
the customer might express satisfaction with the result. The customer′s side
of the agreement on conditions of satisfaction are fulfilled in this phase.
Each of these actions represents the conveyance of a commitment. A complete
request would include a statement of the conditions of satisfaction desired by the
requester, including time for fulfillment. By making a request, the requester is
committing to accept what is being requested if the conditions of satisfaction are
met.
Accepting a request conveys the commitment to deliver the requested conditions
of satisfaction within a specified time. An offer is the commitment to deliver a
proposed set of conditions of satisfaction (including a time frame) if the offer is
accepted. If negotiation takes place, the conditions of satisfaction are usually
refined with each iteration. When one party agrees to the other party′s proposed
conditions of satisfaction, both parties become committed to a single statement
of the conditions for satisfaction.
When the supplier reports completion, the commitment being communicated is
an affirmation or assertion that the conditions of satisfaction have been met. If
the customer rejects the supplier′s work product, the supplier can rework,
replace, or redo the work product. Finally, at any point, either party can
withdraw.
Two additional factors are fundamental. First, when the supplier declares
completion, the work either has been completed on time or not. Second, during
the assessment phase, customer satisfaction with the transaction can be
determined. The arrangement for satisfaction feedback from the customer can
be included in the original conditions of satisfaction.
At the completion of a customer-supplier transaction, there are no surviving
commitments. In other words, all of the commitments created during the
transaction are satisfied or one of the parties has withdrawn. If there are
surviving commitments, then the transaction would be extended to include them.
Chapter 3. A Model for Business Processes 13
This customer-supplier protocol has the property of being complete: all possible
outcomes can be represented. Moreover, it can be scaled up to describe the
highest-level transactions of an enterprise and scaled down to describe the
specific actions taken by an individual. Because of these properties the
customer-supplier protocol forms the basic building block for defining business
processes.
3.4 Traditional Process Definition Methods
The major differences between this approach and the traditional (procedures and
data) process definition approach are:
• The explicit consideration of who performs the activities that make up the
process. The classic process definition technique focuses only on the
procedural aspects of the process and is described solely by its inputs and
outputs.
• In the classic approach, first the process requirements are defined, then the
activities necessary to meet the requirements. Since the requirements are
set when the process is defined, allowances are seldom made for additional
requirements negotiated during the execution of the process itself.
Therefore, conditions of satisfaction are usually fixed, established during the
definition of the process rather than during the performance of the process
itself.
• Measuring customer satisfaction with the customer-supplier approach is
much easier. In the classical approach, customer satisfaction is measured
using post-sales surveys, making it difficult to identify root causes of
dissatisfaction when they occur. Using the customer-supplier method,
measuring customer satisfaction is easy; it is effectively built-in and
determined on a transaction-by-transaction basis as part of the assessment
phase.
• When processes are defined around procedures and activities, the resulting
process structure is often arbitrary, more strongly reflecting organizational
history 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 the
same groupings and relationships.
When the customer-supplier approach is used to describe processes,
starting with customers and accountability, there is a higher degree of
consistency when different people look at the same process.
3.5 Process Measurement
When the customer-supplier approach is used to define processes, a consistent
set 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 of
the customer-supplier process. In any of these cases, the customer may not be
satisfied with the supplier′s performance. Customer satisfaction is considered
independent 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 also
possible 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 Definition
Using the customer-supplier approach, each one of the customer-supplier
relationships has its own conditions of satisfaction and four-phase (opening,
negotiation, performance, assessment) sequence. However, the relationships
are interdependent. For example, the customer′s original request (the order)
would not be accepted by the salesperson without confirmation from the
order-fulfillment manager that the ordered items could be shipped within the
time requested by the customer. The balance of the process might proceed as
follows:
• The customer gives an order (request) to the salesperson. Conditions of
satisfaction are item quantities, prices, and the date the items are required.
• The salesperson checks prices and, if correct, requests a delivery
commitment from the inventory manager.
• The inventory manager determines if the requested items can be supplied by
the requested time. This determination involves checking inventories and
the manufacturing plant. If there is insufficient inventory new manufacturing
Chapter 3. A Model for Business Processes 15
is scheduled. On the basis of these considerations, the inventory manager
accepts the salesperson′s request or makes a counteroffer.
• To schedule new manufacturing, required materials are checked and, if not
on hand or pending in the “pipeline,” a supplier is requested to provide
them.
• The salesperson conveys the acceptance or counteroffer to the customer,
and agreement is reached.
• The inventory is replenished by the manufacturing group if required. This
activity requires scheduling manufacturing, which, in turn, can require
obtaining materials from an outside supplier.
• The inventory manager packages the order and requests shipment through
the shipping company. If the delivery dates do not match the original
conditions of satisfaction, other shippers are consulted, and the customer
informed if appropriate.
• The completion report from the shipping company is a bill of lading signed
by the customer. It is forwarded back to the salesperson as a completion
report 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 business
processes using this approach is who is the customer. In some cases, the
customer is actually a customer who is paying for goods or services. However,
many processes never deal with an external paying customer. The better
question to ask when determining the customer of a process is: “Who must be
satisfied with the work product of this process?” Asking the question this way not
only identifies the external or internal customer, but also correctly identifies the
shareholders, employee, government regulator, external auditor, or labor union
as the customer of certain processes where appropriate.
A related problem is determining the customer in the case of a product or
service that does not yet exist. No customer can make a request for the product
or service, nor is anything offered. New product development processes
typically gather information from a variety of sources and develop a set of
product or service requirements that potential future customers might want in a
product or service. These requirements are assembled by an employee or
group who acts as a proxy or surrogate for the future customers. In this
instance, this group is the customer.
3.8 Case Study Lessons
This approach has been used in a number of case studies and two general
insights occur: omissions are identified and alternative business process
designs become clear. 9 The omissions usually involve missing roles, phases, or
incomplete conditions of satisfaction. Alternative business process designs
include the structures of both the accountabilities in an organization and the
customer-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 and
improve customer satisfaction.
3.8.1 Missing Roles and Phases
In most cases, the most obvious omission is the lack of a clearly defined
customer role. Or, worse yet, when some internal organizations describe their
processes, the organizations appear as customers to all of the surrounding
organizational entities. If there is no clear customer-supplier chain from the
outside customer to the internal organization, processes are being performed
without a context. Symptoms of this lack of context include unstated or assumed
conditions for satisfaction and imprecise or incomplete feedback on customer
satisfaction. A telltale sign of a process without an ultimate customer is the
absence of the four-phase process. Usually there is no request or offer opening
the process, the request does not match what the process ultimately delivers, or
the customer acceptance phase is missing.
The two most frequently omitted phases in existing business processes are
negotiation and assessment. In a typical example, work appears in an in-basket
and the system assumes the work will be performed according to predefined
process and performance standards and the customer will accept it. While
justified in certain instances, this reduces the role of the customer and limits the
conditions of satisfaction to those defined during the process definition.
Conditions of acceptance set during process design can be wasteful and
inflexible:
• There is no way to deal with exceptional, high-priority, or unplanned
requests.
• The easier-to-handle requests are sometimes delayed until the last minute.
• The harder-to-handle requests are sometimes rushed through the process
with 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 a
consequence of not explicitly setting customer expectations, it is difficult to
subsequently manage customer satisfaction. Obviously, without an assessment
phase there is no direct customer feedback.
3.8.2 Connecting the Commitments
Accountabilities and roles in an organization are not independent of one another.
The customer-supplier approach to process design makes it very clear when
there is a break in accountability within a business process. In an example to
which many will instantly relate, Scherr describes the operation of a North
American auto dealership as an example of a process in which there is a break
in accountability between the group in the dealership responsible for selling and
those responsible for servicing the car. It is usually left up to the customer to
ensure the car is maintained at the dealership where it was purchased. 10
Figure 4 on page 18 depicts this process.
10 Ibid., p. 91.
Chapter 3. A Model for Business Processes 17
Figure 4. The North American Car Dealership Process
The Japanese car dealership process is quite different from its North American
counterpart. In Japan, the customer representative is the interface to all of the
dealership′s offerings for the customer. This person, for example, suggests a
new car when the service history on the existing one indicates it should be
replaced and might also handle financing, insurance, and used cars for other
members of the customer′s family. The customer representative is accountable
for the customer′s complete relationship with the dealership over an extended
period 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 Commitments
Misunderstandings between customers and suppliers can often arise over the
difference between an estimate and a commitment. In the absence of
disclaimers to the contrary, the customer assumes an estimate to be a
commitment. This can later prove to be an invalid assumption and result in
customer dissatisfaction that could have been avoided had the customer-supplier
communication been more unequivocal.
3.8.4 Structuring Accountability
Accountability can be viewed as a supplier′s commitment to fulfill a customer′ s
conditions of satisfaction. The original customer in a business process has no
accountability in the process (except to pay the bill when due). The first supplier
in the chain is responsible for meeting the customer′s conditions of satisfaction.
This initial accountability can be completely delegated to secondary suppliers or
split between several suppliers. Regardless of how the accountability is
structured, it must be possible to identify those accountable at each stage of the
overall customer-supplier chain.
3.8.5 Roles and Organization Structure
When a business process is described as a series of customer-supplier
relationships it is simple to recognize the roles and associated responsibilities in
each of the relationships. Since roles are assigned to individuals, the job of any
given individual can be determined by identifying all the roles to which the
person has been assigned. Organizational entities, for example, the order
fulfillment team, are formed by those who play roles in the order fulfillment
process. Related job functions are easy to discern; they are those whose roles
Chapter 3. A Model for Business Processes 19
share a common process. Figure 6 on page 20 shows these relationships and
how they can be used to represent the structure of an organization.
Figure 6. Roles, Jobs and Process Teams
3.9 Designing Business Processes
Scherr suggests two general paths to process definition. The choice of which to
follow depends on whether the process exists and whether process definition
work has already begun using another approach. 11
11 Ibid., p. 96.
20 Beyond BPR
3.9.1 New Process Design
When no process exists or several smaller processes are to be integrated,
Scherr suggests starting with the question, “Who is the customer?” As discussed
earlier, the customer is the person or entity the process is intended to serve or
satisfy. Obviously, if paying customers are served they are at the beginning of
the customer-supplier chain. Within an enterprise, a department′s or division′ s
customers are usually in the management chain and in the organizations that
are served.
It is often difficult to identify the first customer in a chain of customer-supplier
relationships. One suggested technique is to identify the key interactions that
occur between the people involved in the process. Usually, when these
conversations are examined, the roles of those involved in the process emerge
and a first customer is identified.
Once the customer is identified, the next question is, “What requests does the
customer make of us?” or “What offers do we make to the customers?” In the
case of an internal organization, the question often focuses on the types of
requests from management that the internal organization has accepted.
Then, for each customer and request type, the roles (people) involved in relating
to the customer and fulfilling the request or offer are identified. In defining roles
it is usually better to initially identify too many rather than too few. It is easier to
combine roles than to split them up.
Once the roles are defined, the next step is to arrange them in a
customer-supplier chain. The easiest way to do this is usually to try scenarios
starting with the initial customer in the chain and “walking” the customer′ s
request or supplier′s offer through the entire chain. As this is done, the requests
exchanged in each customer-supplier pair in the chain are identified.
The final step is to detail the procedures followed to fulfill each role′s individual
accountabilities. This could involve both computer-based and manual
procedures. It is usually not valuable to extend the analysis to include the
procedures the initial customer uses to initiate the request. It is usually
sufficient to document the form and content of the expected request from the
customer. Similarly, suppliers at the end of the customer-supplier chain are
often considered “black boxes,” or an unknown. An internal supplier can be
viewed in the same manner. For example, a sales process that uses the credit
department to obtain credit ratings on prospective customers does not
necessarily need to analyze the process used by credit departments to obtain
credit information.
As the detailed procedures or activities are described, the actions to take when
exceptions occur are added. Decisions are made about whether the customer′ s
request will ever be countered with an offer, the response to a customer
withdrawal at different points, the circumstances under which withdrawal would
occur, 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 to
choose the appropriate course of action when and if the exception occurs.
Chapter 3. A Model for Business Processes 21
3.9.2 Redesigning Processes
If detailed procedural definitions already exist, it is relatively easy to incorporate
them into the customer-supplier chain. The first step is to arrange the
procedural definitions on the basis of the roles for whom they are performed.
For example, if there is a specific customer intake procedure, this would be
described as a customer activity. Finally, customer-supplier pairs can be added,
a step that usually reveals missing elements, unclear or unstated conditions of
satisfaction, 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 be
accomplished 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 will
cross process boundaries. If all of the processes of an enterprise are described
in this way, there can be a complete mapping to all of the elements of the
enterprise-wide data model. If no such model exists, defining the processes is a
good way to create it. In either case, the activities that use or generate data
elements are identified as the process details are defined.
3.10 Business Process Definition: A New Tool
By analyzing business processes, elements that can benefit from computer
automation can be seen clearly and the benefits quantified. Business process
definition allows the value of the application of information technology to
business to be identified and quantified in terms of real costs, process cycle
time, and customer satisfaction.
The addition of the customer-supplier communication and accountability to
classic process definition techniques is valuable. It provides a view of problems
with customer satisfaction, organizational efficiency, quality, employee
empowerment, and customer-supplier relations that other approaches do not
offer. This view is not intended to replace procedure and data-based
approaches; it is presented as an addition that provides new information which
can enhance the effectiveness of business processes and their supporting
application systems.
3.11 An IBM Business Process Reengineering Example: Customer
Relationship Management
Over the past few years IBM has aggressively restructured itself, dramatically
reducing the size of its workforce and expense structure. However, revenue
growth has proved elusive, and customer satisfaction, though improving, is not
yet satisfactory. To improve the effectiveness of its field marketing and service
personnel and operate on a more consistent basis worldwide, IBM has
embarked on an ambitious reengineering of its marketing and service processes
as part of a project known within IBM as the Customer Relationship
Management (CRM) Reengineering Project.
The CRM design is based on the business process model and the business
process modeling technique described in this document. Some of the highlights
of this reengineering effort include:
Core process. Because reengineering is time consuming, expensive, and
disruptive 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 a
core process to IBM. It will replace and consolidate all existing customer
fulfillment processes and systems in IBM′s worldwide operations but is
considered essential to achieving IBM′s vision for delivering value to its
customers.
Setting and meeting customer expectations. The process design is based on
a customer encounter, whether it is initiated by IBM or the customer. When
a customer makes a request of IBM, satisfaction usually depends on how
well IBM meets the expectations. If these expectations are clearly
understood and agreed upon by both IBM and the customer, IBM has a
higher likelihood of satisfying the customer. This initial encounter with IBM
may be only the first in a series of customer-supplier relationships, many of
which will occur internal to IBM as it marshals the resources to respond to
the original customer request. The business process must ensure that each
of these downstream customer-supplier encounters develops conditions of
satisfaction and is as rigorously managed as the one involving the paying
customer.
Customer feedback. The collection of feedback occurs in every phase of the
customer encounter: opening, negotiation, performance, and assessment.
Collecting performance data is important to managing customer expectations
and essential for process improvement.
3.11.1 CRM Project Overview
The purpose of the Customer Relationship Management (CRM) reengineering
project is to reshape the sales and support processes executed by IBM′ s
customer contact personnel (both direct employees and business partners) and
the staffs that support them. Once redesigned, these processes will be deployed
throughout IBM′s marketing and services organizations worldwide. The uniform
application of these processes will make IBM more consistently and predictably
responsive to both customers and other IBM professionals.
3.11.2 CRM Project Approach
The project will deliver a set of redesigned processes, an integrated set of
supporting applications, and changes to the IBM management system in two
major phases. CRM Phase 1 will establish a standard process and application
platform across all IBM marketing and services organization. Productivity
improvements will lead to reduced sales expenses, and general and
administrative expenses, and is expected to positively influence revenue growth
and customer satisfaction.
While the primary focus of CRM Phase 1 is to deploy standard practices and
applications, the project team is also working with the IBM product divisions to
determine the best approach to providing them with access to the valuable
market 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 include
the results of a customer fulfillment reengineering project and additional
relationship management reengineering work. Significant enhancements to the
CRM Phase 1 processes and applications will also be delivered in this phase.
Chapter 3. A Model for Business Processes 23
3.11.2.1 Customer Requirements
The CRM reengineering project is grounded in the changes customers are
asking of IBM. The IBM Consulting Group analyzed multiple sources of
customer data and feedback and found our customers cite seven broad
characteristics they value in a vendor and want IBM to improve upon. These
customer “imperatives” include:
• Fulfilling 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 on
customer-preferred buying behaviors. In today′s marketplace, customers want
their information technology suppliers to provide varying levels of service and
price depending on the customer′s situation and personal preference.
3.11.2.2 CRM Processes, Operational Roles, and Responsibilities
Please refer to Appendix A, “Customer Relationship Management Processes,
Operational Roles, and Responsibilities” on page 185 for these details.
3.11.3 Sample Transaction Scenarios
Perhaps the best way to understand the change IBM customers, employees, and
business partners will see as a result of the CRM process is to walk through a
few typical customer requests and transactions.
3.11.3.1 Customer Request for a Customized Solution
A customer with a Latin American transportation company has a logistics
application requirement. Though the enjoying an excellent relationship with this
customer, the client representative is not personally familiar with logistics
applications. In our current environment, the client representative might spend a
significant amount of time personally pursuing this opportunity despite not
knowing IBM′s offerings or skilled resource in the transportation area.
In the redesigned customer relationship process, the client representative
registers the opportunity in an opportunity management application. An
opportunity manager makes a preliminary assessment based on the market
segment plan, IBM offerings, available skilled resource, and other qualification
criteria, all available in the information warehouse. The opportunity manager
determines this is an attractive opportunity, assigns an opportunity owner who
has experience with logistics applications, and electronically informs the client
representative.
The opportunity owner contacts the customer, agreeing to take the lead for IBM
to address the customer′s logistics requirements and to remain as the primary
IBM contact on this project through successful implementation. Locating an
installed logistics solution in the worldwide reference database, the opportunity
owner was prepared to discuss it with the customer in just one day. The
opportunity owner could then quickly tailor the solution with other IBM offerings
found in the offering information database and customize the pricing, terms, and
conditions using the standard pricing and contract management applications. As
additional preparation for meeting with the customer, the opportunity owner
24 Beyond BPR
checks the customer profile information to become more familiar with the
customer′s business and relationship history with IBM. The customer is pleased
with the fast turnaround and the skilled resource that IBM applied to the problem
and signs the contract. In the meantime, the client representative was not tied
up looking for the right skills to respond to the logistics application and had time
to uncover a new fleet management opportunity within the same company.
Chapter 3. A Model for Business Processes 25
26 Beyond BPR
Chapter 4. Information Systems Architecture
In modern organizations, business processes and information systems form a
symbiotic relationship: many leading-edge business processes would be
impossible without computers and most of the justification for information
systems investment comes from their support of business processes. However,
the domains of business and computers are very different: business focuses on
entities, processes, locations, people, times, and purposes while computers
consist of data, the programs that manipulate the data, and a technology
infrastructure. For information systems to be usefully applied to problems in the
real world, there must be mechanisms to relate the two domains.
A number of modeling techniques have emerged over the years to bridge these
worlds, such as flowcharts, entity-relationship and process flow diagrams, and
data flow diagrams. But each of these techniques is specialized for a different
purpose. By concentrating on one aspect, the individual technique loses sight of
the overall information system and how it relates to the enterprise and the
surrounding environment. Flowcharts, for example, focus on the operations
performed by a computer and their sequence. Flowcharts are useful for showing
algorithms, but pay little attention to the data structure processed by the
algorithm; data is considered only as it is being operated on.
An architecture provides a means of describing and relating these different
views of an information system. The pioneering work in an architecture for
information systems was done by John Zachman of IBM who proposed, in 1987,
a framework for information systems architecture (ISA). 12 This initial work defined
an 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 the
people view as the challenge of allocating work and structuring authority and
responsibility in an organization. Similarly, time is the challenge of optimizing
the utilization of resources while satisfying commitments. Finally, motivation
considers the issue of organization objectives and strategies for achieving them.
In Chapter 6, “Business Process Reengineering Using IBM′s Enhanced Line of
Visibility Engineering Methodology” on page 49, we present a methodology for
business process engineering that generates models and documentation of
present and desired business processes. We consider business process models
a new and valuable tool for modeling an information system and an important
addition to the data and function-based models of traditional analysis. ISA is
valuable because the framework provides a means of linking these different
models into a consistent view of an information system.
In this chapter we look at the overall ISA framework in preparation for the
discussion of business engineering methods, models, and tools included in
Part 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.
Copyright IBM Corp. 1995 27
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 Concept
In considering the question, “What is an information systems architecture?”
Zachman draws on a thousand years of experience in the field of classical
architecture to develop the analogous information systems architecture
specifications and work products. The word architecture is a metaphor that
compares the construction of an information system to the construction of a
building. In constructing a building, a classical architect develops a number of
different work products, each designed to achieve a different purpose.
4.1.1 Bubble Charts
In the initial conceptual representation, developed through a dialog between the
prospective owner and the architect, the structure is represented as a number of
“bubbles,” with each bubble representing a room, its gross size, spatial
relationship, and other details. Collectively, bubble charts define the scope of
the project.
The bubble charts serve two purposes. First, they capture the owner′s vision for
the structure and serve as a basis for the architect′s actual design. Second,
they are the medium through which the architect conveys the understanding of
the owner′s concept in sufficient detail to convince the owner to proceed with the
project.
4.1.2 Architect′s Drawings
The architect′s drawings are a depiction of the final structure from the owner′ s
perspective and include floor plans, cutaway views, and pictorial representations
depicting the design of the final structure. These drawings enable the owner to
agree or disagree with the architect′s concept or suggest modifications to the
design. While these drawings can be very detailed, they are typically developed
only to the level of detail required for the owner to approve the design.
4.1.3 Architect′s Plans
The architect then translates the owner′s concept and requirements into a
product, the plans. The plans are the architect′ s representation of the final
structure as opposed to the owner′ s representation, which is depicted in the
drawings.
These plans are typically composed of a number of categories of detailed
representations including, for example, site work, the electrical system, masonry,
and structure. These plans comprise the architect′s final work product and
eventually become the official record of the finished structure.
The architect′s plans serve as the basis for negotiation with a general
contractor. They enable the owner to take the plans to a contractor and solicit
price quotations with reasonable assurance the delivered structure will be the
same as pictured in the architect′s drawings.
Chapter 4. Information Systems Architecture 29
4.1.4 Contractor′s Plans
The contractor then uses the architect′s plans to produce contractor′s plans,
which represent the builder′ s perspective. These plans break down the
architect′s plans into the component substructures to ease coordination of the
actual construction activities that the builders perform. At this point, the
contractor may also realize there is a technology constraint that restricts the
contractor′s ability to produce exactly what the architect designed. When this
occurs, the contractor must develop an alternate approach to delivering the
architect′s design and obtain agreement on the proposed change from all
affected parties.
4.1.5 Shop Plans
The subcontractor responsible for an individual substructure may produce
detailed drawings (shop plans) of a specific substructure component. These
drawings, while based on the contractor′s plans, are used only by the
subcontractor. An example of a shop plan might be the specification for a
component to be fabricated specifically for use in the project, either by the
subcontractor 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
Represent basic concepts for building
Illustrate gross size, shape, spatial relationships
Bubble charts Develop a mutual understanding between architect
and owner
Initiate the project
Represent the owner′s version of the final building
Show floor plans, cutaways, pictures
Architect′s drawings Manifest the agreement between architect and
owner on the building
Establish the contract
Finalize the building as seen by the architect
Translate the owner′s view into a product
Architect′s plans Include detailed drawings, multiple categories
Provide basis for negotiation with general
contractor
Finalize the building as seen by the builder
Represent the architect′s plans as constrained by
Contractor′s plans laws of nature and available technology
Describe “How to build it”
Direct construction activities
Illustrate subcontractor′s design of a part/section
Show a detailed stand-alone model
Shop plans
Specify what is to be constructed
Provide patterns
Building Realize the project
30 Beyond BPR
4.2 Are Architectural Representations Generic?
Zachman speculated this generalized view of the architectural representations
created to build a structure would apply equally well to other complex
engineering projects. He tested his hypothesis by analyzing the process of
manufacturing a military airplane and found conceptual equivalents in this
manufacturing activity to the architectural representations of the construction
industry. Encouraged by these findings, he postulated there is likely to be “an
analogous set of architectural representations produced during the process of
building any complex engineering product, including an information system.” 14
Zachman concludes each of the major participants, the owner, the architect, and
the builder, have their own, distinct conception of the product. The owner has in
mind a product that will serve some purpose. The architect translates this
perception of a product into the owner′s perspective. The architect then
translates this representation into a physical product, which is the architect′ s
representation. Finally, the builder applies the constraints of the laws of nature
and available technology to produce the product, using his or her own distinct
representation.
Zachman went on to observe that the three representations do not merely make
up a set of representations, each of which displays a level of detail greater than
the previous one. The architect′s representation (architect′s plans) are not just a
succeeding, increasing level of detail of the owner′s representation (architect′ s
drawings). They are different in nature, content, and terminology and represent
a 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 of
the owner′s representation (architect′s drawings). 15
Information systems representations analogous to the building example are
shown in Table 2.
Table 2. Architectural Representations Compared
Generic Building Information Systems
Description Representation Representation
Initial concept Bubble charts Scope
Owner′s
Architect′ s drawings Business model
representation
Architect′s
Architect′ s plans System model
representation
Builder′s
Contractor′ s plans Technology model
representation
Out-of-context
Shop plans Components
representation
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.
Chapter 4. Information Systems Architecture 31
4.3 Different Views of an Information System
The five different perspectives, planner, owner, designer, builder, and
subcontractor, of an information system make up one dimension of the ISA. The
second dimension is made up of six different views of the nature of the
information 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 the
thirty different perspectives of an information system pictured in figures shown in
Figure 7 on page 33.
32 Beyond BPR
Figure 7 (Part 1 of 2). Framework for Information Systems Architecture
Chapter 4. Information Systems Architecture 33
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 of
the thirty cells that make up the ISA framework. Instead we offer some insight
on what the framework represents and how you can use it to understand the
different facets of an information system.
As we have discussed above, the framework represents six different ways of
relating an information system to the real world, corresponding to the familiar
English question words, what, how, where, who, when, and why. By defining
columns for each of these views, the framework allows an individual view to be
isolated 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 of
the same underlying enterprise, they are all related.
Most of the enterprise modeling activity to date was focused in the data and
function columns. Networks of distributed systems brought some focus to the
network column, but few formal modeling techniques gained widespread
acceptance. With the arrival of workstation technology and client/server
systems, attention is once again focusing on the network column and the
importance of the data and logic placement decision in developing an
information systems architecture.
The new additions to ISA, people (who), time (when), and motivation (why), are
particularly germane to our discussion of business processes. Today, there is
no broad acceptance in the information processing community on modeling
techniques for these views of an information system. In the future, we believe
the business process modeling technique and tools described in Part 2,
“Roadmap” on page 47 of this document will represent the types of models that
will become the accepted means of describing the people, time, and motivation
dimensions of an information system.
4.3.1 ISA Framework Rules
Zachman provided the following rules to assist the reader in understanding ISA
and its application. 16
Rule 1: The columns have no order. Order implies priorities and creates a bias
toward one aspect at the expense of others. All columns are equally important
because all are abstractions of the same enterprise.
Rule 2: Each column has a simple, basic model. Each column represents an
abstraction from the real world for convenience of description. These models
include:
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 models
may be related to one another because they are all abstractions of the same
real-world enterprise, but each model represents a separate and unique
concept.
Rule 4: Each row represents a distinct perspective. This rule is most easily
demonstrated by the Business Model, System Model, and Technology Model
rows, which represent the owner′s, architect′s, and builder′s perspectives. Each
perspective is different because it deals with a different set of constraints. For
example, the owner deals with usability constraints, both aesthetic and
functional, and the architect deals with design constraints, the laws of physics or
nature, and the builder deals with construction constraints, the state of the art in
methods and technologies.
16 Zachman, John A. 1992. “Extending and Formalizing the Framework for Information Systems Architecture.” IBM Systems
Journal 31, no. 3:590-616.
Chapter 4. Information Systems Architecture 35
Rule 5: Each cell is unique. Since each column has a unique basic model that
makes each column unique and each row has a different perspective, each cell
in the framework is unique. Zachman likens ISA to a “periodic table” for
information entities, providing a classification scheme for information entities,
allowing different entities to be combined to provide different views of an
information system.
Because each cell is unique, different techniques and different graphic
representations are appropriate for different cells. This also accounts for the
large number of information systems design models and methodologies that
have emerged over the years.
Rule 6: Combining the cells in one row forms a complete model. The sum of all
cells in a given row is the most complete depiction of reality from the
perspective of that row. As new cells in a given row are defined each new cell
description must be consistent with the perspective of that row. Each cell in a
given row can be defined and is independent of any other cells in the row, yet
each 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 Framework
ISA provides value for this discussion because it offers a means of classifying
and understanding:
Models and methodologies
Tools
Models and methodologies: By classifying six different modeling domains (data,
function, network, people, time, and motivation), ISA provides a means of
classifying different models and the methodologies that produce them. ISA has
no bias toward one modeling approach or methodology over another because all
are abstractions of the same enterprise. Traditional programmers, for example,
tend to have a bias towards function. They usually begin by designing
algorithms that implement the function and leave the data as an afterthought.
They may even claim there is no need to expend resources on defining models
other than the function or process models.
Programmers from the data community prefer data modeling to be done first
because, 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 the
location of data and programs should drive the design.
Classifying tools: By examining the outputs of a modeling or application
development tool, a tool can be classified according to ISA by either the
perspective or modeling domain it supports. In Part 2, “Roadmap” on page 47,
we examine three tools that support the business process reengineering
process. 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 the
ISA classification for each of these tools.
36 Beyond BPR
Figure 8. Business Modeling Tool Information Systems Architecture Classification
Chapter 4. Information Systems Architecture 37
Figure 9. VisualAge Requirements Tool Information Systems Architecture Classification
38 Beyond BPR
Figure 10. FlowMark Information Systems Architecture Classification
Chapter 4. Information Systems Architecture 39
40 Beyond BPR
Chapter 5. A Case Study
This chapter describes an application that we use in the succeeding portions of
the book to illustrate a methodology and the technologies that allow us to do
BPR. The organization that we use in our case is the Universal Trust Company.
The line of business (LOB) that our case examines is mortgage application
processing. 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
Copyright IBM Corp. 1995 41
5.1 Universal Trust Company Overview
Universal Trust Company provides, among other financial services, consumer
mortgages to both new and existing mortgage customers. Lately, the company
has been aggressive in promoting its products and services, advertising its
offerings on a number of newspapers and television channels. To support the
advertising campaign, the company set up a help desk to answer customer
inquiries on offerings (for example, on rates and terms) at any time during
banking hours.
When a customer applies for a mortgage, the people on the help desk complete
a mortgage application. The application is then verified. Once verified, the
mortgage application is put through the approval process. Upon approval, funds
are committed. The terms and conditions document is then prepared and is
given to the customer for signature.
When the customer returns the signed mortgage document, a mortgage account
is set up. When the customer makes a mortgage payment, the mortgage
account is debited.
Updates about customers and prospects are also recorded when they contact
the company, or when the company contacts them.
5.2 Mortgage Application Process
This section contains the details of the mortgage application process. It covers
what information is needed in the different processes, and what office tools are
used.
Provide Mortgage Data
Customers request mortgage information by telephoning the branch loan officer
(BLO). The BLO enters prospect information into the mortgage system and
receives back the requested general mortgage information. The BLO then relays
the general mortgage information to the customer.
Receive Mortgage Data
To request a mortgage, the customer goes to the branch and completes a
mortgage application with the assistance of the BLO. The BLO enters the
mortgage application information into the mortgage system once the application
is completed. The completed mortgage application form is given to the
customer 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 the
mortgage filing cabinet and another copy is forwarded to the headquarters real
estate administrator (HQ REA). The HQ REA sets up the property appraisal, then
electronically sends the mortgage property information to the appraiser.
The appraiser completes the appraisal, then files one copy of the appraisal in
the 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 HQ
REA then files one copy of the property appraisal report in the HQ real estate
administration filing cabinet. If the mortgage application was rejected, the HQ
REA forwards the rejected mortgage application to the BLO. The BLO calls to
notify the customer of the mortgage rejection. If the mortgage application was
approved, 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 (HQ
SO) by the HQ REA. The HQ SO allocates funds for the mortgage. The HQ SO
sends one copy of the approved mortgage form back to the HQ REA. The HQ
REA 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 (HQ
LS) to prepare the mortgage documents. Then the HQ LS sends the mortgage
documents to the BLO. The BLO presents the mortgage documents to the
customer for signature.
Set Up Mortgage Account
When the BLO receives the signed mortgage documents from the customer, the
BLO forwards the documents to the HQ mortgage payment office (HQ MPO). The
HQ MPO sets up a mortgage account in the mortgage system and mails a
completed mortgage package to the customer.
Debit Mortgage Account
When the customer makes mortgage payments, the HQ MPO debits the
mortgage account in the mortgage system.
5.2.1 Cycle Time Details
It takes on the average ten days from the time the customer requests a
mortgage to the time the approved mortgage document is presented for
signature. Customers have mentioned that a maximum of seven days
turnaround time is required for the Universal Trust Company to be competitive in
the marketplace.
It takes on the average one day from the day the customer requests a mortgage
until the BLO forwards the application to the HQ REA. It takes another six days
to complete the mortgage appraisal process. Most appraisers take two days to
complete the appraisal.
The mortgage is verified on the same day as the appraisal is received and
rushed 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 the
HQ REA to receive the mortgage details and enter these in the system, and for
the HQ LS to prepare the mortgage documents and present these to the
customer for signature.
Once the signed mortgage documents are returned to the BLO (almost
immediately 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 make
the first mortgage payment.
5.3 Headquarters Real Estate Administrator
This section goes into the details of the activities of the headquarters real estate
administrator (HQ REA) in the mortgage application process. It includes some
notes about the HQ REA job.
Set Up Property Appraisal
Each application contains details about the property to be appraised, such as the
address and the listed price, plus the closing date. The applications are
prioritized by closing date and sorted by location. The property location is
determined and based on its location, the nearest appraisal office is assigned.
The appraisal request is sent via electronic mail. The turnaround time for the
appraisal is six working days.
Verify Mortgage Approval
The appraisal is reviewed and checked for completeness. If the appraisal is
incomplete, it is sent back to the appraiser. The credit data needs to be verified
as well. The application is manually updated with the appraisal and credit data.
Based on this information, the application is either approved or rejected. The
property appraisal report is then filed in the HQ administration file. If the
application is approved, it is copied and the master is sent to the BLO by
courier. 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 primarily
from the BLO inquiring on the status of the appraisals.
• Determining priority of appraisal takes ten minutes. Everything has a high
priority.
• Setting up an appraisal is extremely manual. A large map on the wall helps
but it is out-of-date and the information on it has to be verified with a file of
miscellaneous notes to determine the geographic location of the property.
Mortgage applications rarely include the zip code. One has to refer to the
zip code book and compare the notes and the map. This takes about two
hours.
• The appraisal office lists are all manual and not sorted alphabetically. It
takes about 50 minutes to find the appraisal office nearest the property
location.
• 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 to
ensure 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. There
is a sequence that needs to be followed when keying in the e-mail, and all
information in the application needs to be keyed in.
• Market and real estate knowledge is needed to review and check the
appraisal. There have been instances when there are wide variations
among the appraisals, depending on the appraiser. So occasionally, the HQ
REA sends the appraisals back to the appraiser for reassessment. The HQ
REA therefore does not like to start the credit check until after the appraisal
is 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 credit
department with the mortgage applications and waits or comes back at a
later time to ensure a one-day turnaround. It takes 10 minutes to verify the
credit.
• Once the credit rating is received from the credit department, the HQ REA
updates the mortgage application with the appraisal value and the credit
rating. 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 the
approved applications by rush courier to reach the branch for same-day
customer notification.
• It only takes 15 minutes to enter the information into the system. This
usually happens the following day after the funds are approved.
Chapter 5. A Case Study 45
46 Beyond BPR
Part 2. Roadmap
Copyright IBM Corp. 1995 47
48 Beyond BPR
Chapter 6. Business Process Reengineering Using IBM′s Enhanced
Line of Visibility Engineering Methodology
In the previous chapters, we examined the business environment today, realized
the importance of the customer, and recognized the need to reorganize our
businesses from hierarchical organizations into process organizations. This
chapter introduces a methodology, Enhanced Line of Visibility Engineering
Methodology (LOVEM-E), that allows you to view your business as a series of
processes that focus on the customer.
This chapter is the basis for the succeeding topics that cover the application
tools that you can use with this methodology.
In this chapter, we explain LOVEM-E, apply it to Universal Trust Company, and
present how the methodology is used in reengineering projects. This chapter
includes 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
Copyright IBM Corp. 1995 49
6.1 Introducing LOVEM-E
LOVEM-E is a business process engineering or reengineering methodology
designed for business and systems professionals. It addresses customer
satisfaction, market-driven quality, internal service levels, and total quality
management. The focus of LOVEM-E is the service encounters with customers
and clients. It puts emphasis on interfaces, such as, internal and external
hand-offs and dependencies, and interfaces to systems and automation.
LOVEM-E is based on the process path management concept. It uses a pictorial
language to demonstrate the processes of an enterprise. Symbols represent
logical and physical process and data components. Their arrangement
represents the sequence and order of a process path or workflow. In this way,
each service encounter, process or data component, problem, or opportunity can
be examined in the appropriate context of a process path, and the maturity level
for the overall process path can be established. LOVEM-E shows all the
elements of your business in relationship to one another.
LOVEM-E is also built on the realization that business and systems professionals
are jointly responsible for process design and management. Business process
design and ongoing business process management, according to services
marketing principles, must be shared between business and systems
professionals. LOVEM-E offers a common specification language that lets
business and systems professionals document, analyze, evaluate, rate, and
manage business processes and systems functions. In addition, employees and
management within your business, as well as your relationship with customers,
vendors, and suppliers can benefit from this common specification language.
6.1.1 Use
You 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 to
support:
− 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 leap
improvements to your organization and processes. LOVEM-E can help you
to:
• 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, call
flow 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 critical
measurement 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 business
process modeling (BPM), business process reengineering (BPR), or business
transformation (BT). It complements other BPM, BPR, and BT analysis and
design approaches.
6.1.2 Benefits
Below is a summary of the benefits of LOVEM-E:
• Easy-to-use:
− Uses a language business and systems professionals can easily
understand
− 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, and
training
• Tracks time and identifies critical milestones or measurement points
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility 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 of
business, or a major reengineering project.
Summary
LOVEM-E is a concise set of business process management and business
process reengineering techniques that you can apply in a wide range of
situations, from business process blueprinting for day-to-day operational
management to radical business process reengineering.
The focus is the service encounters with your customers and clients for
designing customer and client satisfaction into the processes. LOVEM-E also
has many other important focus areas, such as employee morale, cost and
cycle 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 a
process path or workflow from a customer′s and employee′s point-of-view,
you can quickly identify problems and opportunities; this often leads to
solutions. For example, you may discover that you are going through several
steps 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 to
effective workflow solutions and to solutions for document and folder
management or call flow management.
6.2 Components of LOVEM-E
This 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 Management
Businesses are usually organized in vertical process structures. In Figure 11 on
page 53 for example, the sell, order, supply, distribute, settle, deliver, and
support processes are organized vertically. Although vertical structures
contribute to internal excellence, the customer remains outside the system. As
52 Beyond BPR
business organizations recognize the importance of customer satisfaction, the
customer 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 a
customer service encounter. A process path starts from a customer process,
cuts across several functions of an organization as the customer encounter is
handled, and ends in another customer process as information, goods or
services are provided to the customer.
A process path can be defined at both the logical and the physical levels. At the
logical level, it is a sequence of processes. At the physical level, it is a
sequence of manual activities and system functions.
Typically, each process path has different process characteristics: for example, a
high-profit line of business (LOB) usually has many processes aimed at helping
the operation of the business. On the other hand, a low-profit LOB has to
manage expenses cautiously and tightly, thus not needing many processes.
Many modern businesses offer highly customized products and services that
have varying objectives, and thus varying number of processes. Managing these
different process paths with the focus on the customer calls for a new way of
looking at business: management across vertical processes, which is process
path management.
LOVEM-E is based on process path management. The design point of the
LOVEM-E is geared towards process path management and process path design
from the customer′s point of view. It uses a graphical language to demonstrate
the processes of an enterprise. Symbols represent logical and physical
processes, and data components. Each LOVC sequentially traces the different
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 53
processes and data involved in handling a customer encounter from the point
when it happens to the point when all activities needed to handle the customer
encounter have been completed and the customer is satisfied. In this way, each
service encounter, process and data component, problem, or opportunity can be
examined, and the maturity level for the process or process path can be
established. Designing and managing processes and process paths that fit the
needs of customers generate the customer satisfaction that ultimately brings
business success.
6.2.1.1 Data Flows
In process paths, data flows are data flowing from one process to another. The
data is required to handle the customer encounter. Data flows identify the data
that is generated from or required by the customer or internal processes.
6.2.1.2 Processes and Activities
A process can mean an entire line of business (LOB), such as the mortgage
LOB. Or a process can mean the smallest unit of work, such as entering data
into a data processing system or informing the customer that the mortgage
application has been approved.
To delineate the logical views of a business from the physical views, the term
process in LOVEM-E means a logical process that can be transformed into
several manual activities and system functions.
Processes are a series of actions or operations conducing to an end. These are
the operations that are performed to handle a customer encounter. Activities of
a process are the particular operations required to handle a customer
encounter. LOVEM-E contains two types of processes and activities:
Customer processes and activities. Customer processes are the collection of
activities that a customer performs when interacting with a business
organization. Inquiring about, requesting, or receiving information, goods, or
services are examples of customer processes. In LOVEM-E, these are found
in the logical charts.
Customer activities are the specific activities that are performed by
customers when interacting with a business organization. Signing
application forms, accepting appraisal time, and receiving approval notices
are examples of customer activities. In LOVEM-E, these are found in the
physical charts.
Customer processes and activities can initiate, end, or reside in the middle
of process paths.
Business processes and activities. Business processes are the collection of
activities that a business organization performs to handle the customer
processes. They show what the organization does in general terms. In
LOVEM-E, these are found in the logical charts.
Business activities are the actual actions and operations that the
organization performs to handle the customer process. In LOVEM-E, these
are 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 an
operation on the data, and send data flows to the next processes or
activities. In LOVCs, processes and activities are presented sequentially
from left to right.
54 Beyond BPR
6.2.2 Process Maturity Rating and Key Indicators
An important aspect of business process management is to determine the level of
maturity of a process or process path. To be able to rate the level of maturity
for a process or process path, certain rating criteria have to be established and
adhered to. When establishing the maturity criteria for a process or process
path, you have to differentiate between strategic and operational goals and key
indicators.
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 and
key 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 in
defect prevention within the next month
Data integrity Check the completeness, accuracy, and timeliness of data
passed to the billing department from the order entry and
distribution departments.
Base and target values should be set for each key indicator. While base values
can be measured and observed over a certain period of time, say three months,
target values should be set progressively more challenging, until the strategic
goal has been achieved.
It is advisable to put a checkpoint measurement plan in place for each key
indicator and associated goal, which defines what should be measured, how and
how often it should be measured, and who is responsible for taking and
interpreting the measurements.
Following are more examples of key indicators for individual organizational
units:
Leasing The number of payment schedules in error
Purchasing How long it takes from an initial request to when
an 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 an
advertisement in writing
Regional service centers Customer satisfaction with services
In this example, customer satisfaction cannot be determined until the other
processes are completed. That is why the key indicator customer satisfaction
should be used only in conjunction with key indicators for the other processes;
in other words, this key indicator depends on the key indicators of other
processes.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 55
Establishing key indicators and their associated checkpoints can also require
automating the taking of measurements.
Statistical methods and simple analytical aids can be used to evaluate and
present the measurement results. This enables objective decisions based on key
indicators, 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 help
of any of the four types of LOVCs. While the logical LOVCs, like the ALOVC and
LLOVC, are better suited for establishing a high-level rating and for setting
strategic goals and key indicators, the physical LOVCs, like the PLOVC and
JLOVC, are better suited for coming up with detailed ratings and for setting
operational goals and key indicators, since they contain all operational aspects
of the process path. An As Is or a To Be process maturity rating should be
associated with every LOVC blueprint.
Success Factor
Aligning strategic goals and key indicators across the entire process path
must be done before establishing process maturity levels and rating criteria.
6.2.3 Structure
Although there are several templates of LOVCs, all share a common structure
similar to Figure 12 on page 57. All LOVCs are made up of several horizontal
bands and lines. Bands show who is performing each process. Lines give
background information to the processes putting these processes in perspective
to the business. Following are the lines and the bands that can be found in all
the LOVCs:
56 Beyond BPR
Figure 12. Generic LOVC
6.2.3.1 The Customer Band
The customer band is the area where all customer processes and activities
reside. The customer band is at the top of an LOVC.
6.2.3.2 The Enterprise Bands
Below the customer band are the enterprise bands. These bands represent the
different functions, departments, jobs, or roles that perform processes of a
business organization and handle customer processes and activities. Several
enterprise 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 the
organization but are all seen by the customer as part of the organization.
6.2.3.3 The Line of Visibility
The line of visibility separates the customer band from the enterprise band. All
the data flows that go through this line are the customer encounters or the
moments of truth that happen between customers and organizations. This line of
visibility presents the image of the organization as viewed by its customers. No
matter how efficient a particular function, department, job, or role is, what is
visible to the customer is the total service provided by the organization, which is
the entire series of processes from beginning to end.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 57
6.2.4 Types of LOVCs
There 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 has
its own LOVC template. Users of the LOVCs would use one of these charts
depending on the level of abstraction or the level of detail that they would want
to cover. Figure 13 compares the different LOVCs based on their levels of
abstraction and levels of detail.
Figure 13. Comparison of Levels of Abstraction and Levels of Detail
6.2.4.1 Comparison of Logical and Physical Representations
Different process engineering and reengineering activities can be carried out at
various 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 your
business processes to get a stable framework for your design work. This would
be 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, or
other constraining elements.
At this logical level, you focus on why the process is needed and what the
process does, not how it is done. At this stage, you do not add any constraints
such as organization, time, people, tools, and so on to the process. To
graphically 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 a
logical process path design, you can start to add the various constraining factors
to 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 that
contribute 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 various
alternative 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 Chart
The architecture line of visibility chart (ALOVC) is the highest level of
abstraction. It is logical and unconstrained, and is used in developing an
organization′s architecture. It focuses only on the main customer processes, the
organization′s processes that support these, and the key data components that
are used. It depicts the strategies that an organization has embarked on when
doing business with its customers, and how it uses services and data to support
its strategies. It also shows what processes are critical to the organization and
are subject to quality planning.
6.3.1 Structure and Main Components
Figure 14 on page 60 is an examples of an ALOVC.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 59
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. The
interactions 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 most
frequent service encounters, which are customer inquiries and customer change
requests.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 61
These two process buses are repetitive and unpredictable processes that could
happen at any point during a relationship with your customer. They cross all the
other operational roles and processes, and can be invoked at any time by the
customer 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 timely
data, which is available through the cross service encounter data buses at any
point on the path.
Note: The term bus is borrowed from the electrical engineering, or computer
design, language, and signifies a continuum with concrete contact, or
entry and exit, points.
Logical Roles
Three bands show the three major logical roles found in any fulfillment
enterprise. These are:
• The marketer
The key contact with the customer. Usually, this contact initiates and
manages the contractual relationship.
• The fulfiller
The key contact responsible for fulfilling the promise made by the enterprise
to its customer, through the contract or order.
• The settler
The key contact responsible for managing the customer′s financial
obligations to the enterprise, or the enterprise′s financial obligations to the
customer 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 process
architecture to a separate data architecture.
Data or information is one of the most important assets of any enterprise. You
must understand and manage it at the architecture level as well as at any level
of 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 or
order 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. This
can be the traditional customer record data; but it can also be any
interpersonal relationship information about service encounters. It can also
include what the customers need and want over and above the current
contract, or any other information that helps delight the customer in future
service encounters.
Offering (or Product and Service) Data. Captures information about the
current and future products and services that might affect the existing
relationship and future relations with a customer. This bus can also capture
information about any competitive or complementary products and services
for this relationship.
Promise (or Contract and Order) Data. Captures information about the
current contracts and orders that your enterprise has with a customer. Any
other information that can help define, clarify, expand on contracts and
orders with a customer, or that is useful in future relations, can also be
captured through this bus.
Process Quality Management Bus
On this bus, you can show measurements to be taken for the process path, such
as critical measurement points, intervals between service encounters,
transaction volumes at specific instances on the path, or any other benchmark
measurements. These measurements should be tied to customer research in
order to achieve customer satisfaction. You can also show other business
parameters on this bus, such as critical success factors (CSFs), goals, strategies,
and policies (GSPs), and critical measurement points (CMPs).
6.3.2 ALOVC Example
Figure 14 on page 60 is an example of an ALOVC of the Universal Trust
Company.
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 banking
architecture. 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 by
sending the application data to the marketer, two other processes occur: the
verify application process and the approve application process.
The verify application process also updates the contact data bus and the promise
data bus. In addition, a critical measurement point is created on the process
quality management bus to capture the date application received information.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 63
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 then
commits the funds.
Success Factor
If senior management accepts the high-level business architecture (including
the business rules, policies, directions, and guiding principles), the chances
are better for a successful implementation of the reengineered process. The
chances are further increased if customers, partners, and all other interested
parties also accept the architecture.
Summary
The ALOVC is a convenient way to document a process architecture at the
enterprise level. It is a good start to a top-down business process
reengineering 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 Chart
The logical line of visibility chart (LLOVC) is the starting point for creating a
design of the different offerings or lines of business of an organization. It is a
way to develop models and blueprints of process paths for these lines of
business. It identifies only generic functions and processes, and shows which of
these processes require data. Because it is high-level and does not include
physical constraints (for example existing systems and geographic locations), it
provides a stable view of a process path.
64 Beyond BPR
6.4.1 Structure and Main Components
Unlike 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 the
LOV, but the internal processes can have as many bands and as much detail as
you 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 process
and 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.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 65
Logical Business Area Bands
There are several bands that represent logical business areas. They contain the
internal logical processes and data flows.
Between two business area bands, there are lines that represent internal
interfaces. 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 process
path requires.
6.4.2 LLOVC Examples
Figure 15 on page 65 illustrates an LLOVC of the mortgages process path of
Universal Trust Company. The top band above the line of visibility (LOV) shows
the 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 that
are involved in the process path:
• Sell
• Order
• Supply
• Distribute
• Settle.
Each band contains the most important logical processes that the logical
business area is responsible for. For example, the sell business area is
responsible for providing mortgage data, and the distribute business area is
responsible for preparing mortgage documents.
The processes are connected with data flows that are required in this process
path. For example, the order business area needs mortgage application data
from the customer before it can verify the mortgage application data. Similarly,
the settle business area needs payment data from the customer and mortgage
payment details from the internal process set up mortgage account before it can
debit the mortgage account.
At the bottom of the chart is an optional data bus that helps to highlight the
importance of some data for downstream use. For example, customer data is
updated by the provide mortgage data and verify mortgage application data
processes.
66 Beyond BPR
Success Factor
If the high-level design for a LOB is integrated in the overall business
architecture, and if senior management accepts it, the chances are better for
a successful implementation of the reengineered process.
Summary
The LLOVC is an important part of LOVEM-E because it has many different
business 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 Chart
The physical line of visibility chart (PLOVC) is a graphical representation of the
physical constraints of a process path. It sequentially organizes and shows in
detail all the important physical aspects of a process path. For one particular
process 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 blueprint
of the process path implemented under the constraints of the business.
6.5.1 Structure and Main Components
The 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.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 67
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 the
left-hand side of the chart in Figure 16 on page 68 are the descriptions for the
bands, which now represent specific business functions, departments, jobs, or
internal/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 or
system; it represents:
• What the customer sees
• A service encounter
• A moment of truth
• The company′s image.
Note: The service encounters occur at the LOV.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 69
Internal/External Organizations Band
One of the bands below the LOV can be designated as an internal or external
organizations band and contain internal organization units that do not belong to
this 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,or
hand-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 systems
and:
• 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 shown
below the manual/automation interface line. These can be connected
through information flows with systems or with computer data stores
below 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, in
hours, business or calendar days, weeks, months.
6.5.2 PLOVC Examples
Figure 16 on page 68 is an examples of the As Is PLOVC for the mortgages
process path of Universal Trust Company.
In Figure 16 on page 68, the top band above the LOV shows the customer
activities:
• 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 perform
the 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 control
flows that the job is responsible for; for example, the headquarters real estate
administrator is responsible for setting up the property appraisal, verifying
mortgage approval, and entering approved mortgage details in the mortgage
system. The appraiser is responsible only for appraising the mortgage property.
The activities are connected through information flows, goods flows, and control
flows that are required for this process path. For example, the branch loan
officer requires mortgage application information from the customer and payment
information from the mortgage system to perform the assist with mortgage
application completion activity, which sends the mortgage application information
in hardcopy to the customer and updates the mortgage system with customer
mortgage application information.
The customer returns the signed mortgage information document to the branch
loan officer, who then forwards the signed mortgage information document to the
headquarters real estate administrator and files a copy of the document in the
mortgage file cabinet.
The time line at the bottom of Figure 16 on page 68 shows that it requires seven
days from the initial customer request today until Universal Trust Company
provides the customer with the property appraisal results. Customer research
shows that it should require three days, maximum, which the company
designates as its target for reengineering.
Success Factor
Building various implementation alternatives can greatly enhance the
probability of arriving at the best design for customer satisfaction and
employee morale.
Customer satisfaction and employee morale are the two pillars of business
success.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 71
Summary
The PLOVC is an important technique for business process reengineering as
well as for making day-to-day decisions or operating and managing your
business. 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 job
levels
− Interfaces to systems
− Cycle time
− Critical measurement points
− Information and goods flow media, such as telephone, fax, truck, or
document
− 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 process
path and helps you to build To Be scenarios and blueprints.
• You work at the physical, or constrained, level, which provides a clear
picture of reality.
• It is not only a blueprinting and design technique but also an effective
way for communication and education.
6.6 Job Line of Visibility Chart
The job line of visibility chart (JLOVC) is the lowest level of abstraction. It
focuses on one job at a time and organizes and shows sequentially all the
physical aspects of that job. It focuses on a job′s manual activities and their
interfaces 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 or
a blueprint of a job at the physical level.
6.6.1 Structure and Main Components
The JLOVC template is very similar to the PLOVC; however, it has only one
internal 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
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 73
Figure 17 (Part 2 of 3). Mortgage JLOVC for the Headquarters Real Estate Administrator Job
74 Beyond BPR
Figure 17 (Part 3 of 3). Mortgage JLOVC for the Headquarters Real Estate Administrator Job
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.
Note: The service encounters occur at the LOV.
Internal/External Organizations Band
Directly below the LOV is an auxiliary band, showing all the interfacing internal
and external organizations (other than the customer) for the job: interfaces with
other internal departments or jobs, or external organizations.
The interface line between this band and the main band shows the
internal/external service encounters:
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 75
• 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 or
online systems:
• Customer activities
• Internal activities
• Internal/external organization units
• External systems.
Note: External systems that do not directly interface with the job can be shown
below the interface line. They can be connected through information
flows with the systems or with computer data stores below the interface
line.
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 Examples
Figure 17 on page 73 illustrates the As Is JLOVC of the headquarters real estate
administrator in the mortgage process path of Universal Trust Company.
In Figure 17 on page 73, the headquarters real estate administrator has no
contact with the customer but interfaces with three internal jobs: the branch
loan officer, the appraiser, and the headquarters signing officer.
The headquarters real estate administrator sets up the property appraisal after
receiving the signed mortgage information document from the branch loan
officer. Once the appraiser receives the mortgage property information through
electronic link, and the property has been appraised, a property appraisal
information report is faxed to the headquarters real estate administrator, who
then verifies the mortgage approval, sends the mortgage approval information
document to the bank loan officer and the approved mortgage details document
to the headquarters signing officer. The headquarters signing officer sends the
approved mortgage details document back to the headquarters real estate
administrator, who then and enters the approved mortgage details into the
mortgage system. If, however, the mortgage application is rejected, the
headquarters real estate administrator sends the mortgage rejection information
document to the branch loan officer. In either case, the property appraisal
information report is filed in the headquarters real estate administrator′s filing
cabinet
The time line indicates that it requires seven days from when the headquarters
real estate administrator receives the signed mortgage information until the
76 Beyond BPR
approved mortgage information is entered into the mortgage system. The
desired target is three days. Therefore, some reengineering of the job and its
interfaces is required.
6.6.3 JLOVC Applications
Because a JLOVC provides you with a very detailed blueprint of one job, it has a
number 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 can
greatly enhance the probability of arriving at the best design for customer
satisfaction and employee morale.
Customer satisfaction and employee morale are the two pillars of
business success!
Integrating all aspects of the job design in the process path design
minimizes the risk of problems with upstream and downstream
dependencies.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 77
Summary
The JLOVC helps you design individual jobs and assists in making day-to-day
decisions on the operations and management of one job. The most
important 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 with
physical 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 LOVCs
Business processes are often engineered or reengineered in the context of a
special project. Within the project, LOVEM-E can be used with other techniques
or technologies.
Your project plan will change depending on the objectives and type of process
reengineering. If the objective is to design a new process that replaces an
existing process, then you require a good understanding of the current process
design, and a solid understanding of the new design objectives. Typically BPR
projects are in one of the following two categories.
Radical BPR projects.
Radical BPR emphasizes breakthrough thinking, and is often driven by
external needs or opportunities that cannot be achieved simply by altering
the existing process. Radical BPR is done periodically when conditions
warrant the investment. In radical BPR, you de-emphasize the current way
of doing things, and concentrate on breakthrough diagrams.
Radical BPR projects offer the potential of dramatic improvements, but also
involve high risk and large investments. Although your project sponsor
might have asked for radical reengineering, you must pay attention along the
way to short term incremental opportunities for improvement. Uncovering
78 Beyond BPR
low risk and low cost opportunities ensures that your BPR project delivers
value early.
Once you implement a radically new process, the resulting blueprint must
become part of the incremental improvement process. With today′ s
accelerated product development cycles and shorter product life cycles,
reengineering is required more frequently. Therefore, organizations need a
solid base of process blueprints in place so that reengineering changes can
be made quickly and effectively.
Process redesign projects.
Process redesign projects are similar to radical BPR projects because they
involve investment in process engineering and enabling to implement the
change. However, you use a different approach for process redesign than
for radical BPR. In process redesign, you study the existing process
extensively, and alter it based on observation and feedback about the
process.
You use LOVEM-E to support both endeavors, but the individual techniques are
applied with different emphasis. In process redesign, the As Is blueprints form a
base that you use to alter and create the To Be blueprints. So you begin by
examining your As Is blueprints. Look for their weaknesses, then build your To
Be models.
However, in radical BPR, you design the To Be process from a new point of
view. Avoid referring to your As Is processes because these are the processes
you are moving away from. You do not want to be influenced by them, for your
creativity in developing new processes may become limited. So you approach
your To Be process from a clean slate. Find out what the essential tasks are
that will make your processes work, and from those develop To Be models.
You usually know before you start a project whether its objective is process
redesign or radical BPR. In some cases, however, it might become apparent
during an incremental design that the project needs radical reengineering. If
this happens, the process redesign team will suggest taking a radical BPR
approach to the project.
6.7.1 Criteria for Choosing Business Process Reengineering or Process
Redesign
Several criteria influence the type of reengineering you should use. The greater
the 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, competitive
pressure, or business performance
• Breakthrough opportunities, such as in technology and customer service
• Level of investment planned and required, such as in business objectives
and constraints
• Scope and authority of the process team, such as in level of representation
and access to decision makers.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 79
6.7.2 Major Business Process Reengineering Roadmap
LOVEM-E has a well-defined process describing the activities for reengineering
major 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 Processes
To understand the current business environment, you must conduct As Is
blueprinting sessions, creating blueprints of your current business, in enough
detail that you can draw the necessary conclusions. You can achieve this by
creating a set of high-level logical and physical LOVCs while focusing on your
customer expectations.
The time spent on As Is blueprinting should be minimal compared to the overall
reengineering effort. You can always come back to these blueprints and add
more detail when required.
Whether you have a large project with several action teams, or a smaller project
with just one team, each team member has to actively participate in creating the
blueprints. You cannot afford to have the facilitators and process analyst do all
the work, while other team members act as information resources and
reviewers.
With As Is blueprints, you analyze real or perceived problems based on
customer research information and your blueprints. If not already identified on
the blueprints, add the problem areas to the blueprints and document them with
backup 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 processes
through the eyes of your customer
− To assess your current business processes from the point of view of
customer 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.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 81
Step 2: Create a physical view.
• Objective
To document and understand the factors contributing to how the process
path 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 you
understand the existing process path and jobs
− Benchmark to understand the performance of the As Is process path
and 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, systems
interfaces, and so on
• Once you have created As Is blueprints of your business, you can use
them 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 Processes
The reengineering, or To Be, phase is the most critical phase for projects that
will radically change in the business. This phase is also the most difficult
because you are trying to create a vision of a radically different business that
breaks all of the current paradigms. The resulting blueprint should reflect a
quantum leap improvement in anticipated customer satisfaction and business
performance.
So you begin the creative part of the reengineering process. By brainstorming,
visioning, and using breakthrough thinking, you can create a number of totally
different business scenarios that do not resemble your As Is blueprints. From
these, you can create a set of different To Be models that represent alternative
future process paths and jobs. These alternative models need not be complete
or detailed, but should capture the most important service encounters with the
customer, major internal and external interfaces, hand-offs, dependencies, and
proposed opportunities for automation.
Once you have selected a model to implement, begin the actual detailed design
work. 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 form
of:
− 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 should
implement the new process path and associated jobs.
• Activities
At this physical level, you:
− Create multiple To Be models using high-level 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
− Experiment by modeling alternatives and what-if scenarios before
committing to a detailed design and blueprint (the time-consuming
part of the process)
− Add the times it could or should take to perform the new process
path or job to the time line. Place critical measurement points at
those places on the chart where you want measurements to be taken
for customer satisfaction or internal controls
− Create a detailed blueprint of the selected alternative, including
blueprints 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
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 83
− Documentation of the service encounters, activities, procedures,
information flows and media, process and cycle times, systems
interfaces, and so on.
Once you create the various models, you need a high-level business case for
each one showing the costs and benefits, and how and when your organization
could implement the various models. The To Be models and business cases are
then reviewed and one model is selected for detailed work.
6.7.5 Designing To Be Process Models
According to Hammer and Champy in Reengineering the Corporation, there are
no hard and fast rules for performing reengineering because reengineering is a
search for new models that can take many different forms. Which models will
not work is easy to determine. They are usually the models we currently live
with. Which models will work is more difficult to project, unless of course they
have already been tried. This difficult search leads us to two approaches we can
use 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. You
can draw on the successes of these organizations, especially those from the
same 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 can
be measured and benefits can be quantified.
Designing models for radical reengineering requires more work; however, we
know that the rewards are far greater with radical reengineering. New
processes may provide the competitive advantage that will set your organization
apart from the rest. Still, trailblazing with processes that have never been used
before entails more risk. It is also more difficult to measure the effects of radical
reengineering because the process yields benefits that are not immediately
obvious.
We do not claim that we have a proven formula for success. Success depends
heavily on the creativity, resourcefulness, and experience of the people
performing the reengineering. However, the graphical representations of
LOVEM-E do have implicit lessons for us to use to arrive at effective
reengineered processes. Let us examine what some of these lessons are:
• Combining tasks within a job band. If different people perform several
consecutive tasks within a job band, consider reducing, perhaps to one, the
number of people who perform the tasks. Reducing the number of hand-offs
within a department reduces wait time, resulting in immediate benefits to the
LOVEM-E time line. It also increases the familiarity of the worker with the
work performed because he or she is exposed to more aspects of the work.
In relation to the customer-supplier relationship mentioned in 3.2, “The
Customer-Supplier Relationship” on page 10, the worker can focus on what
will satisfy the customer and the conditions that will make the customer
continue negotiations.
• Combining tasks across job bands. When several consecutive tasks across
different job bands are combined, hand-offs between different jobs are
reduced. From practical experience, we know that hand-offs between jobs
are the most disruptive. Not only are geographies concerned, but
84 Beyond BPR
philosophies and orientations can differ between jobs. In LOVEM-E, between
customer encounters, the relationships of each band are the elements of the
entire process. Minimizing internal relationships or bands performing a
process often improves the quality and speed of delivery of goods and
services to the customer. Thus, combining tasks that span several jobs
results in new jobs with new philosophies and orientations that are more
focused on the customer.
It is not easy to combine tasks within jobs or across several jobs. The
immediate concern with this effort is the capacity of the worker. However, with
the explosion of information technology, the capacity of workers increases,
allowing them to perform much more than they could perform before. It also
enables workers to do more for customers. Thus proper use of information
technology greatly affects the capacity and ability of workers to provide improved
quality 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 to
perform processes faster. Use it to enable radical process changes.
Chapter 6. Business Process Reengineering Using IBM′s Enhanced Line of Visibility Engineering Methodology 85
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 an
automated, yet dynamic way. These business processes can be line of business
activities, for example, contracting for a purchase, the processing of an
insurance claim, managing a lawsuit from start to finish, the steps in application
development, or an enterprise-wide management function, such as installing a
software update.
“Workflow Management is a proactive computer system that manages the flow of
work among participants, according to a procedure consisting of a number of
tasks. It coordinates user and system participants, together with the appropriate
data resources, which may be accessible directly by the system or offline, to
achieve defined objectives by set deadlines. The coordination involves passing
tasks from participant to participant in correct sequence, ensuring that all fulfill
these required contributions, taking default actions when necessary.” 17
This chapter includes the following topics:
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.
Copyright IBM Corp. 1995 87
7.1 Application Structures
In many companies, valuable process definitions are buried deep within the logic
of application programs. Changing a business process means changing the
application programs, which can be a time-consuming and expensive
programming task. With workflow management, programs provide service to
processes and not vice versa. The application consists of a set of small
programs or other processes; the sequence of program execution is described
as processes to the workflow resource manager. The workflow resource
manager 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 Reengineering
Workflow-based applications are typically not created by revamping existing
applications. They are the result of business reengineering, “the fundamental
rethinking and radical redesign of business processes to achieve dramatic
improvements 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 can
be implemented and executed using a workflow management system. Business
reengineering is typically performed by exploiting business modeling tools, such
as those described in Part 3, “Tools for Productivity” on page 99.
7.3 Applications
More than two decades ago, applications were highly dependent upon how data
was organized on a disk. Changes in data organization required changes in all
affected programs. To overcome this so-called data dependency of applications,
database management systems were built. When database management
systems are used, applications become more flexible and less vulnerable to
changes in the data organization.
Similarly, many contemporary applications do not easily allow enterprises to
change their processes. Large application systems contain the code that directly
represents these processes so that changing the processes requires changing
the corresponding application systems. While the logic of a particular step of a
business process belongs to the proper application, the knowledge of
sequencing these steps and distributing them to the responsible organizational
units makes the application vulnerable with respect to changes of the underlying
business 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 applications
because the task of dispersing work is extracted from the application programs.
As a result, applications become more flexible and less vulnerable to changes in
the business processes supported by the applications.
A flow independent application consists of a workflow definition and a set of
programs that provide function and data services to the workflow definition. This
allows a new application and technology architecture: the application can be a
networked application, with the application programs running in a
geographically-dispersed network consisting of different types and classes of
computer systems. The binding of each activity to its supporting application
program occurs at the time of execution based on the definitions in the workflow.
This topology independence is another example of the flexibility offered by
workflow applications. Because the workflow resource manager does not
assume any inherent structure between the workflow activities and their
associated application programs, a workflow application can be implemented in
a client/server structure with the client providing information presentation
services and the server supporting the database, application processing, and
administration services. This relationship is shown in Figure 18.
Figure 18. Data and Flow Independence
Finally, application development productivity typically improves when
applications are developed using workflow management technology. The
process model is usually developed more quickly and the initial system
specification is often of higher quality because of the early involvement of the
system′s user in its development. Once the process model has been modeled
and defined with the workflow manager, the procedures and data required to
support the process can be developed. Because the process model is managed
by the workflow manager, application programs are typically smaller, less
complex, easier to test and therefore, faster to develop and deliver.
Chapter 7. Workflow Management 89
7.4 An Application Integrator
The workflow resource manager can also be used to link existing applications,
even if each was developed independently. Consider a situation where legacy
applications provide most of the desired function but a new business or legal
requirement arises that extends the legacy applications beyond their design
point. A workflow resource manager can provide a new process model that
combines the underlying legacy applications, hiding their invocation mechanisms
and automatically passing data from one application to the other.
Because the context and state of such an integrated application is persistent
data (for example, data stored in files or database management systems), the
history of the individual application executions, their order, and their local
context is tracked. In error situations that require compensation, the system
can, based on this persistent data, automatically schedule previously defined
compensation steps to correct an error condition.
The coupled applications can run under the control of various transaction
monitors, or as native operating system programs. They can be transactions, or
nonrecoverable units. They can run locally, or distributed in heterogeneous
environments. The workflow management system ties them together, displaying
the middleware facet of workflow management.
7.5 Three Dimensions of Workflow Definition
To define enterprise-wide processes involves identifying the actions and
activities of the process, the people, or means that perform the activities and the
resources used. The workflow resource manager must support the definition of
processes through the following three independent views:
• Processes view (what)
• Organizational view (who)
• Infrastructure view (which)
7.5.1 The Process View: What Is Performed
A process is described through a number of activities that need to be performed
to achieve the desired process outcome (see Figure 19 on page 91).
The activities can be performed by people or resources (where resources could
be a computer system). The activities are connected by arrows that describe the
potential flow through a process. The decision as to which path to follow is
described 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 M o d e l
A specific process performed according to a process model is called a process
instance (or process for short). It is possible to have many process instances of
the 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 or
resource. At an enterprise level this is the smallest piece of action described in
a process model. This activity can then be further divided into its component
functions to describe in detail all the actions a person or a computer system
performs.
This procedure is called refinement and allows a consistent transition from
enterprise processes into software structures or application programs, and then
into tasks, which can be performed by computer systems and people.
This description of a process shows the dynamic behavior or control view of a
process. To complete the description of a process, the data required by the
various 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. Activity
containers hold information handled during a process instance. Programs
executed as part of the process can access data stored in these containers in
addition to conventional files and databases.
Chapter 7. Workflow Management 91
7.5.2 The Organization View: Who Performs
As part of process modeling, people or resources performing the individual
activities are defined. This organizational view describes the structure of the
enterprise (for example, departments, projects, or process teams) and the
people performing the activities as they are related to the structure. The
information about the people includes their skills and the roles they can perform.
The organizational information includes rules like escalation (for example, when
a process exceeds a predefined threshold) and substitution (for example, when
one team member is unavailable). For each activity, the process modeler
defines who should perform the activity (see Figure 20). This is specified in
terms of organizational information, which at run time is resolved into a set of
people or resources. The association of activities and organizational information
is 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. For
example, intelligent use of the staff definition is a means for an enterprise to
structure their education plans and guide resource allocation, organization
changes, and hiring plans. When subsequently applied, the organizational
structure 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 Used
An activity (what) is performed by a person or on behalf of a person (who). The
infrastructure defines which computer system resources are available to perform
an activity, for example, which program is used and which machine runs the
program (that is, where the program is executed).
When a person starts an assigned activity, the appropriate information
technology resources are determined and allocated. This includes selecting the
proper programs, determining the right invocation mechanism, or transferring
data from one server to another. Some of these assignments are performed
dynamically, which allows balancing of work and systems.
92 Beyond BPR
7.5.3.1 Combining All Views
Taking the three views, processes, organizations, and infrastructure, the
workflow can be represented as the navigation through a three-dimensional
space defined by: what, who, which, which is shown in Figure 21. If a workflow
manager can clearly represent these three dimensions, it can likely provide
strong support for the workflows (or enterprise processes represented by
workflows) resulting from reengineering activities. When workflow application
systems are devised from document, image handling, or office systems, often the
three dimensions are not clearly separated. This can result in the need to define
and use document status to support navigation within process instances.
Figure 21. The Workflow Cube
7.6 Resource Manager
The functions supported by the workflow resource manager are delivered by the
following components:
• Buildtime
− Workflow definition
− Animation
− Simulation and capacity planning
− Import/export of process models
• Runtime
− Navigation
− Worklist handling
− Program invocation
− Auditing
− Monitoring
• Administration
Chapter 7. Workflow Management 93
7.6.1 Buildtime Support
Buildtime supports the definition of process models and the management of
organizational information. In addition, it provides the capability to animate and
simulate those models and organizational structures, and to import and export
them.
Process models are usually defined with a graphical editor that places activities
on the editor working area and connects them with arrows to represent control
and data flow. Some workflow resource managers also offer a workflow
definition language that provides an alternative to the graphical interface for
defining process models and a mechanism for the exchange of workflow
definitions between different workflow management systems and business
modeling tools.
To verify a workflow model, it can be visually animated, a stage in which the
modeler navigates through the model and examines the behavior of every single
navigation step. To predict the total behavior of a workflow management system
within an enterprise, it is necessary to simulate the execution of multiple
processes. This allows the modeler to detect resource constraints and
determine where improvements in the process model are required. Additionally,
simulation can also use data collected from prior process runs.
7.6.2 Runtime Support
Runtime 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, invoking
programs on behalf of users, and generating audit trail information. The server
does this for multiple instances of multiple processes. A client component
manages the user interface work area, the local work list, including
synchronization with the persistent worklist on the server, and executes
programs on a client′s workstation. It also provides application programming
interfaces (APIs), which allow programs to invoke process-relevant operations,
such as starting or terminating a process. A monitoring facility can be used to
display the status of every process started by the user.
Navigating a process graph and staff assignment is performed by the navigation
engine in the process server. It selects the next set of activities to be performed
by evaluating the control flow. For each selected activity, it determines the
people to perform the activity, and makes this information persistent in the data
base to provide recovery. The worklist function in the server maintains the
worklists of all users assigned to the specific server that allows a user to sign on
to the workflow resource manager at any supported workstation.
If desired, every action of the workflow resource manager can be recorded as it
is executed and stored to provide audit trail information. This record can then
be used to evaluate the effectiveness of the process and suggest areas for
improvement.
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 start
activities. If the selected activity is a computer program, it retrieves the proper
program registration information, determines the data to be made available in
data containers, launches the program, and determines the returned information
after 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 servers
responsible for supporting the involved users.
In the case of distributed work items, navigation through the process is
performed by the workflow resource manager where the process originates. If
staff resolution determines that a user is serviced by another workflow resource
manager server, the target server is responsible for the work item until it has
been completed by the user.
For distributed subprocesses the level of distribution is the process. The
originating server informs the target server about the process to be started and
passes the process input container to the target server. The process is
managed by the target server until it is complete. All relevant information is
then passed back to the originating server so that navigation can continue.
7.6.3 Administration
The administration of a workflow resource manager is divided into system
administration and process administration.
System administration deals with managing the basic resources of the workflow
resource 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 process
instances:
• Querying the status of the workflow resource manager servers (active
process instances, number of work items assigned)
• Reassigning work items for balancing work load
• Monitoring the status of exception situations.
7.7 Process-Based Application Development
The three major components of a process model consist of the flow of control
and data between its activities, the distribution of each activity to its responsible
organization unit, and the linkage of each activity to its supporting computer
program. The computer programs implement the basic functions of the
underlying business process and usually provide a distinct function such as
support for a single business rule or database access.
When the workflow paradigm is adopted as the fundamental application
structure, the business users of the new system are typically involved with the
analysis of the business process and identifying the support required by
computer systems. A business modeling tool allows them to describe business
processes without any data-processing terminology, and in terms relevant to
their area of expertise, like critical success factors, process goals, quality
measures, and required resources.
Chapter 7. Workflow Management 95
7.8 Workflow-Based Application Development
As shown in Figure 22 on page 97, developing workflow applications generally
starts with business modeling. A business modeling tool captures, for example,
information about the actions that build a process, the business objects that are
manipulated by the actions, possible sequencing of actions, and responsible
organization units. Thus workflow-relevant information can be derived
automatically and put into a workflow management system as a process
template. This process template is then refined into a complete process model
by using the buildtime component of the workflow management system.
When refining the process template into a process model, some actions captured
in the business modeling tool will be further refined in subprocesses while
others will become activities that are directly associated with programs. Some
of these programs will already exist and some need to be written. For newly
written programs, the workflow manager helps with different tools to build
programs that fit smoothly into the workflow manager′s runtime environment.
For example, visual builders can be exploited for composing programs from
parts, a program modeling tool supporting a contemporary methodology can be
used for the construction of more complicated programs, or a program can even
model regular activities. The workflow manager will then request from the user
the 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 into
process execution activities that are recorded in an audit log. Based on the
audit log, a process performance monitor provides a statistical analysis of the
performance of process instances. This process feedback information can be
used as the basis for process improvement activities or to initiate a new cycle of
process modeling.
Similarly, business objects captured by the business modeling tool can be
transformed into entities of a data modeling tool. These entities can be refined
into conceptual data models for the various business areas supported by the
targeted business processes. Because each local conceptual data model can be
perceived as the view of a business area in the enterprise data model, a view
integration tool supports the combination of business area data models into an
enterprise data model. Input and output containers of activities can be modeled
as views onto the organization data model. Based on the relationship between
the organization data model and a relational database, database definition
software can be generated, which retrieves and stores container instances in
relational databases.
96 Beyond BPR
Figure 22. Process-Based Application Development
7.8.1 Process Verification
The correct and efficient execution of processes is vital for the successful
operation of the enterprise. An animation tool allows the verification of process
logic. This is done by simulating the control flow, the data flow, and the flow
between the affected organization units of a single instance of one process
model.
If the process model is considered a correct representation of the process logic,
a simulation tool can help verify whether the process, as designed and
implemented, will meet its targets when stressed with volumes similar to
expected production volumes.
Once the process model is in production various execution measurements can
be monitored. The process performance monitor will collect and represent the
actual and the statistical behavior of the processes. The results can indicate the
necessity of ongoing reengineering work because of deviation from target
process goals.
7.9 Object-Oriented Technology
Enterprises today invest in object-oriented technology to improve the productivity
of 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 complementary
technologies: one can exploit the other in a variety of ways, resulting in
Chapter 7. Workflow Management 97
synergies that are equally valuable to both, but they can also coexist so that
each technology has its own area where it can be applied without the other.
Coexistence means the workflow resource manager executes programs written
in an object-oriented programming language. The workflow resource manager
starts programs through a variety of means. For example, the workflow resource
manager can invoke programs provided as executable files, scripts, or entry
points in dynamic link libraries (DLLs), CICS, IMS transactions, or message
queue applications. Because the way a program is constructed is irrelevant to
these invocation mechanisms, the workflow manager can start the corresponding
program regardless of whether they are written in a third generation language
(3GL), fourth generation language (4GL), or object-oriented (OO) programming
language.
If the encapsulation feature of object-oriented technology is used, the details of
the business process can be hidden in the object-oriented application′s classes
and methods. As a consequence, the business process becomes dependent on
the application′s process model and is not explicitly described and made
available to a broader community.
However, object-oriented technology can provide business object components
for application construction which can be directly integrated into the business
process by the workflow resource manager. The workflow resource manager
maintains the application′s process model and controls how, when, and by
whom the services provided by the various business objects are exploited. This
approach preserves the application development benefits of a workflow resource
manager 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 ability
to invoke SOM object methods directly. When extended by distributed SOM
(DSOM), the location of the SOM object becomes irrelevant to the workflow
resource manager.
A business object can communicate in an object-oriented manner with the
workflow resource manager in order to influence the navigation through the
business process to which the business object belongs. A workflow framework
that provides services as objects allows for that. Again, exploiting SOM
technology for this can be beneficial because of language neutrality and binary
compatibility.
98 Beyond BPR
Part 3. Tools for Productivity
Copyright IBM Corp. 1995 99
100 Beyond BPR
Chapter 8. Business Modeling Tool
We have covered the IBM LOVEM-E and workflow management concepts. In this
chapter, we present the IBM Business Modeling Tool (BMT), which captures the
LOVCs and other important information about your business processes. Using
some of this information, BMT also allows you to generate workflow scripts.
This chapter includes the following topics:
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
Copyright IBM Corp. 1995 101
8.1 Basic Activities of the Business Modeling Tool
To stay competitive, most companies need to improve customer service, reduce
cycle time, use resources efficiently, reduce costs, boost employee morale, and
encourage teamwork. One way to achieve these goals is for companies to
perfect their business processes.
BMT is a design and analysis tool based on LOVEM-E. Business consultants and
business analysts use BMT to help companies first analyze, then improve or
reengineer their business processes.
BMT shows companies how customers see and experience their business
processes, as a first step toward improving customer service. BMT helps to
visualize, document, and analyze a business process to reveal defects such as
extended cycle times, high costs, wasted resources, and insufficient employee
skills.
8.1.1 Gathering Information
First the information about a business process must be gathered. Then the
information, including roles of departments and activities involved, customer
satisfaction, control parameters, conditions, and generated goods, is put into
BMT charts and notebooks.
This information, also available in report form, shows key indicators such as
cycle times, costs, opportunities, problems, or goals. A complete set of charts
and reports can identify delays, bottlenecks, or other problem areas in a
process.
8.1.2 Modeling Business Processes
All LOVCs show customer processes or activities, a line of visibility, and
company departments or process stages. They can also show boundaries
between 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, the
bottom up, or both.
Top down approach:
The top down approach assumes that you already know which charts you need
to 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 the
process 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 the
elements you just added to the chart.
8.1.3 Analyzing, Improving, and Monitoring the Process
In a typical analysis of a business process, consultants or analysts first create
ALOVCs and LLOVCs for an overall view of what the company does.
Consultants also create logical transformation lists (LTLs) to transform
processes into activities. They then create As Is and To Be PLOVCs, in which
the processes and subprocesses of an ALOVC or LLOVC become real activities
and tasks performed in real departments. Finally, consultants create As Is and
To Be JLOVCs to analyze each individual job.
Throughout the entire reengineering exercise, the consultants build hierarchical
structure diagrams (HSDs) to view the structure of processes and activities.
At the end of the assessment phase, consultants confer with analysts and the
reengineering team to recommend possible ways to achieve short-term and
long-term goals. Company executives review the charts and reports, consider
the recommendations, and then decide what steps to take toward improving or
reengineering the process.
Business process reengineering does not end with the implementation of a
reengineered or an improved process; it is an ongoing procedure. To stay
competitive, a company must continue to measure key indicators and monitor its
processes systematically. Regular measurement and monitoring ensure that
current goals are met and new goals within reach.
Consultants also use the As Is charts of the new process to check against the
old To Be blueprint to show how the improved or reengineered process is
performing and where adjustments are required.
8.2 Using Business Modeling Tool
If you have used BMT before, there will be a file cabinet icon for each business
model. The first time you start BMT, there will only be the sample model
delivered with the product. Figure 23 on page 104 shows the mortgage
application model in the Business Models window.
Chapter 8. Business Modeling Tool 103
Figure 23. Business Models Window
8.2.1 Business Models
Business Models contains a variety of objects, arranged in a tree view.
Figure 24 on page 105 illustrates the mortgage application tree view with the
Charts object expanded. Business Models contains the following types of
objects:
Charts LLOVCs, PLOVCs, JLOVCs, and Other Charts
HSDs Decomposition diagrams of goals, activities, and critical
success factors, for example.
Organizations Elements of a process path that represent customer
procedures, business functions, business areas,
departments, and jobs on LOVCs. Organizations that you
define in notebooks appear as bands on LOVCs.
Logical objects Elements of a process path used in physical models, such
as customer activities, activities, information flows, and
systems.
Assignable objects Controls that you can assign to process path elements:
AIRs, critical success factors, goals, metrics, opportunity
areas, 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 which
you want to work.
2. Double-click on a specific object to open its notebook or double-click on a
chart 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 can
create all of the LOVCs of the Universal Trust Company that we studied in
Chapter 6, “Business Process Reengineering Using IBM′s Enhanced Line of
Visibility Engineering Methodology” on page 49. The Editor window consists of
the 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 saving
the chart, printing the current chart, cutting, pasting,
copying, undoing, enlarging or reducing the scale of a
chart, fitting the chart into one window, displaying the
chart at the default scale, and getting help.
Symbol palette The symbols displayed in the symbol palette are different
for each chart type. Exactly where on a chart you can
place a symbol also depends on the type of chart you are
using.
Chapter 8. Business Modeling Tool 105
Drawing area The drawing area is where you create and update charts
by 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 band
on the right side of the drawing area. Select Symbols from
the menu and the allowed symbols will be highlighted.
Status area This area contains several fields below the drawing area
that display status information for the user, such as what
has just happened or what to do next, scale of the current
chart, and type of chart.
Figure 25. Editor Window for JLOVC
Additional general information on the BMT Editor can be found in the discussion
of 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 Facility
BMT lets you share the charts you make with other graphics software. BMT
achieves this by providing an export feature that produces output files in four
common formats. These formats, shown in Figure 26 on page 108, are:
• OS/2 bitmap
• Windows bitmap
• TIFF
• PCX
• FlowMark FDL
• Spreadsheet
Chapter 8. Business Modeling Tool 107
Figure 26. Export Options Pop-Up M e n u
This feature is valuable for incorporating the charts you just made into
presentations. Support for TIFF, a popular imaging format, is also useful for
integrating your charts with imaging applications. This means that companies
with an imaging system installed can allow their staff to share BMT charts. The
IBM VisualInfo and the IBM Visual Document Library, two of IBM′s imaging and
document management software products, support TIFF.
8.2.3 Using the LOVCs of BMT
In 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 of
research has to be done and this takes some time. It may take several
iterations to capture the processes your organization has and to understand
how these processes handle information. More effort is required if your
processes span several roles, departments, or jobs. By storing your LOVC
in BMT, you preserve all your efforts as you build your As Is blueprint over
time.
BMT integrity checking also helps minimize errors in creating LOVCs. By
providing immediate feedback, rework is minimized, resulting in faster
development of the current business blueprint.
• Supporting reengineering efforts
Reengineering requires a fair amount of modeling. Several To Be models
are drawn by BMT to determine the best way of performing business
processes that satisfy the customer. Modeling in BMT can be performed
108 Beyond BPR
faster since charts can be replicated and modified to create alternative
models. Therefore, the total reengineering time is shortened.
BMT integrity checking also helps minimize modeling errors. By providing
immediate feedback, rework is minimized resulting in faster development of
reengineered business models.
• Using the IBM LOVEM-E blueprints as a common specification language
As mentioned previously, BMT allows you to create clear and consistent
LOVCs. By performing integrity checks when building charts, BMT helps you
avoid charts that are confusing and inconsistent.
BMT allows you to communicate the LOVCs using other software through the
export facility. By incorporating your LOVCs in other presentation software
you 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 imaging
softwares to access LOVCs. This lets more people in the organization view
and understand the company′s LOVCs.
8.3 Generating Workflow Scripts
In 6.1.1, “Use” on page 50, we also discussed that a reason for creating LOVCs
is to design workflow solutions. This section presents how BMT supports
designing of workflow solutions with LOVCs. A more detailed discussion on
workflow solutions is covered in Chapter 10, “FlowMark” on page 149.
In 7.8, “Workflow-Based Application Development” on page 96, we discussed
that developing workflow applications generally starts with business modeling.
In this case, after having created our LOVCs, BMT has already captured
information about the actions that build the processes, the business objects that
are manipulated by the actions, the sequence of the actions, and the responsible
organization units. BMT capitalizes on the information it has stored by providing
the facility to generate the FlowMark definition language (FDL). Thus,
workflow-relevant information can be derived automatically and put into
FlowMark as a process template.
8.3.1 FlowMark and the FlowMark Definition Language
FlowMark is the IBM workflow management solution that controls the execution
of business processes. FlowMark provides functions for the interactive definition
of process models, for their testing with graphical animation, for the execution of
workflows by automatically interpreting the process models, for helping end
users manage their work via work lists, and for the recording of execution-time
parameters for the purpose of analyzing processes after execution.
The process models defining the workflows are graphically represented by
FlowMark as networks of activities. Each activity is described by assigning a
role, the required program or tool to carry out the activity, and data to be
manipulated by the program. These attributes are stored in a FlowMark
database.
The FlowMark workflow manager provides an export utility program to retrieve
any of the definitions that you store in a FlowMark database and generates an
ASCII text file, in an external format called FlowMark definition language (FDL),
containing these definitions.
Chapter 8. Business Modeling Tool 109
Inversely, FlowMark provides an import utility to read FDL and create definitions
in its FlowMark database that define part or all of your workflow model. From
this, 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 Language
Since FlowMark executes actual business processes, BMT generates FDL from
physical charts. Only PLOVCs and JLOVCs can produce FDL.
To generate FDL, you have to create all the PLOVCs and JLOVCs of the process
path you are interested in. You should ensure that each activity and information
flow has at least an identifier and a name. When entering this information, you
can reuse already-defined objects by using the Find function if you are
employing the bottom up approach (see 8.1.2, “Modeling Business Processes”
on page 102). You also need to enter the band names representing the different
jobs in the PLOVCs and JLOVCs.
Having the information from the physical charts, BMT performs the following
when 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 and
JLOVCs
This is because PLOVCs can contain PLOVCs and JLOVCs, and JLOVCs can
contain JLOVCs.
3. Extracts the involved PLOVC and JLOVC objects to create corresponding FDL
scripts
4. Arranges the FDL scripts in the proper format
5. Saves the FDL script using the filename of the active PLOVC/JLOVC with the
fdl extension.
BMT checks the FDL script before generating it, to make the import procedure as
error free as possible. To produce a successful FDL generation, you should
have at least IDs and names in all your symbols, and program names (found in
the program tab) of the system symbols.
Also, when importing an FDL file, make sure that your BMT symbol names do
not have apostrophes in them. When you generate FDLs, BMT encapsulates the
names with single quotation marks. During the import procedure, when
FlowMark reads the names, it looks for the FDL single quotation marks before
and after the name and extracts the name within. If there is an apostrophe in
the name, the FDL would confuse FlowMark and result in an error. If there are
apostrophes in the names in the generated FDL, either remove them from the
BMT symbols and generate another FDL, or edit the generated FDL file and
delete the apostrophes in the name, leaving only the FDL single quotation marks
before and after the name.
In FlowMark, you need to access the FDL file generated by BMT and import it to
the FlowMark database. From there, you can now test and execute the process
model.
110 Beyond BPR
8.3.3 From LOVCs to FlowMark Definition Language
When reengineering, once you select your To Be model you can have certain
portions of your business processes implemented in a workflow. With the
PLOVCs and JLOVCs of these business processes you created, BMT generates
FDLs to be imported to the FlowMark database. From there you can immediately
test and execute your business process models.
This integration between BMT and FlowMark allows you to implement your
business processes immediately and at a lower cost. BMT automatically creates
FDL, an output format that FlowMark can read to build and run business process
models. No additional conversion of output needs to done. Therefore, your
business reengineering cycle time will be reduced, allowing your business
organization to provide enhanced products and services and improve customer
satisfaction at the earliest possible time. Also, no additional tools are
necessary. This minimizes your business reengineering costs.
8.4 Complementary Modeling Techniques
BMT currently supports the complementary modeling technique, the hierarchical
structure diagram (HSD) in an automated fashion, and allows for the manual
creation of logical transformation lists (LTLs) using the Other Charts object of the
Business Modeling Tool. This section shows how you can use HSDs in BMT.
8.4.1 BMT Hierarchical Structure Diagram
The hierarchical structure diagram (HSD) allows you to decompose certain
LOVEM-E symbols into greater detail. It provides a convenient way to
understand the components of a process or organization design. You can use it
at any level of abstraction or detail.
With BMT, you can use this tree structure to access any of the models or
blueprints directly, thus obtaining a graphical table of contents of your LOVEM-E
models 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 the
mortgage model.
Chapter 8. Business Modeling Tool 111
Figure 27. Hierarchical Structure Diagram Choices
HSD LOVCs have a tight coupling to their related LOVCs. For example, if you
start 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. For
example, 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 the
HSD 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 decomposition
and are not coupled to LOVCs. This is the same for HSD organization units,
because you can add bands (organizational units) from different organizational
levels to a PLOVC. HSD is used to do a functional decomposition of systems
into 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 better
perspective of the elements of the business processes of an organization.
8.4.2 BMT Logical Transformation List
The logical transformation list (LTL) forms a bridge between the logical and the
physical models. Using the LTL, you can build physical implementation
scenarios for logical processes on an ALOVC, LLOVC, or logical HSD. For
example, the logical process, enter order, can be implemented in many different
ways. 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 from
an order form, into an order file
• A combination of automated and manual procedures, such as typing the
order from an order form into an order system.
Chapter 8. Business Modeling Tool 113
The LTL is used for logical-to-physical transformation. It is an integral part of a
top-down design process. You start with logical models, which you transform
into various implementation scenarios before building physical models and final
blueprints. LTLs are created in the Other Charts object of the BMT editor.
• All manual
You can implement the logical process verify mortgage data completely
manually 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 following
system 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 manual
activities 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, list
the activities and the system functions that you need to perform the logical
process.
Once you decide which implementation scenario is the most suitable, you can
use the activities and system functions from the LTL to populate your physical
models.
114 Beyond BPR
Success Factor
The logical-to-physical transformation requires experience in business and
systems design. It also requires an understanding of what is feasible from a
technology, cultural, or financial point of view.
Summary
The LTL is used to transform logical processes into physical design
alternatives. These can be all manual, or all automated, or partly manual and
partly automated. Performing the logical-to-physical transformation requires
business and systems design skills. The BMT LTL capability has no formal
structure; it is simply a blank canvas to draw upon.
Chapter 8. Business Modeling Tool 115
116 Beyond BPR
Chapter 9. VisualAge Requirements Tool
VisualAge Requirements Tool is a tool that helps business users discover the
system functions they need to support their processes. Through a highly
intuitive visual representation scheme, VisualAge Requirements Tool lets
business and systems professionals jointly define system requirements from a
business perspective.
In previous chapters, we described a method for business process engineering,
LOVEM-E, and a tool, BMT, that supports the method′s documentation
requirements. You may have noticed that business process modeling focuses
primarily on activities, the people who perform them, and the time required to
complete a single iteration of the process. Analysis of the detailed functional
requirements of the activities that the process team performs is often considered
out of scope or reserved for a later stage in the reengineering project.
In this chapter, we explore VisualAge Requirements Tool and how it integrates
with LOVEM-E and BMT to rapidly develop specifications of the system-related
activities identified during business process modeling. This chapter consists of
the 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
Copyright IBM Corp. 1995 117
9.1 Introducing VisualAge Requirements Tool
VisualAge Requirements Tool provides a rich and extensive set of graphical
representations that you can select, modify, and manipulate.
You can view graphical representations that dynamically change as you change
the specification of the business object. You can use the mouse, or other
pointing device, to easily view and change the view of your business operations.
You can quickly browse views of business elements, scan complex graphs by
positioning and zooming, and tailor your views according to your immediate
needs.
VisualAge Requirements Tool helps you identify the elements of a business
operation and document their interconnections and then explore the behavior of
that business operation. It makes it easy to collect and enter key operational
data about your enterprise and presents that data in clear dynamic graphics for
you to study and validate.
To record and represent operational behavior, VisualAge Requirements Tool
uses new technologies in analysis, storage, and presentation that were not
available a few years ago. VisualAge Requirements Tool hides the computer
technology and presents descriptions of business behavior in your terms, using
business constructs.
You do not have to learn a special language to use VisualAge Requirements
Tool. You can identify, describe, and view business-user requirements in your
language, not a computer′s.
9.1.1 Advantages
VisualAge Requirements Tool provides the following advantages:
• Quick, easy creation of the business objects to prepare user requirement
statements. Objects are presented in easy-to-identify icons, attributes are
specified and displayed in easy-to-use online notebooks, and associations
are depicted graphically.
• Facilities to view different aspects of the information graphically.
• Instantaneous updating of all VisualAge Requirements Tool views. As soon
as you make a change in one VisualAge Requirements Tool view, it is
immediately propagated throughout the entire business operation. All views
always 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 system
decomposition, including very large systems and client/server functional
distribution.
• Classification of business rules to facilitate their discovery and retrieval.
• A business fact dictionary to manage names and structures of business
facts, which provide a large part of the business enterprise terminology.
• User-controlled completeness indicators, which can be queried to manage
your progress.
• An annotation facility for reviewers to comment on business elements.
• Powerful, but easy-to-formulate and easy-to-use, queries about all
associations.
118 Beyond BPR
• Management of connections to implementation elements for reuse and
impact analysis.
9.1.2 Uses
Business changes typically drive the need for changes in business operations
and the corresponding changes in user requirements. During the business
cycle, need for change is identified, requirements are specified, applications are
implemented, and then the modified operation is used in production.
VisualAge Requirements Tool helps you to quickly and accurately define user
requirements for the business operations and communicate those requirements
effectively to system developers. Additionally, system developers can use
VisualAge Requirements Tool data to better plan, develop, and test the business
operations. VisualAge Requirements Tool provides a basis for evolutionary
change and element reuse.
9.1.2.1 Help Users Determine Their Requirements
VisualAge Requirements Tool helps you determine what you want the system to
do with regard to business operations.
Although users are often dissatisfied with the systems that support them, they
cannot communicate their needs in a form comprehensible to system
developers. Users and developers have trouble communicating. This
breakdown in communication causes the development of systems that do not
meet the user′s expectations.
Users have a hard time specifying systems ahead of time because the insertion
of a new system in their business operations alters those business operations in
ways that are hard to anticipate, generating additional requirements and making
some of the system′s functions obsolete.
VisualAge Requirements Tool emphasizes function, or system behavior, rather
than the user interface. VisualAge Requirements Tool identifies the system′ s
services through the concept of business transactions and the behavior of those
services through the concepts of business rules and business information.
Once the requirements are specified, business users can use VisualAge
Requirements Tool to simulate the behavior of each of the specified services and
evaluate them from a business viewpoint.
With VisualAge Requirements Tool, you can represent and analyze system
behavior without prototyping. VisualAge Requirements Tool helps manage
completeness and consistency of the requirements, thus enhancing the
confidence level in the specification. Reviewers can easily view and comment
on VisualAge Requirements Tool specifications online. You can make changes
easily so reviewers can validate them quickly.
9.1.2.2 Help Users Specify Required System Behavior
The behavior of a business operation is a key element of user requirements, and
VisualAge Requirements Tool helps you specify this behavior.
The same information that you need to discover your requirements is used to
record those requirements. No time is lost restructuring the information needed
to discover and understand behavior requirements into the specification of
behavior.
Chapter 9. VisualAge Requirements Tool 119
The support of VisualAge Requirements Tool for user-managed completeness
lends confidence that the specifications represent what is really needed.
9.1.2.3 Help Users Communicate Their Requirements
VisualAge Requirements Tool provides you with a semiformal representation of
system behavior to use as the means of communicating with your colleagues
and system developers.
Once you understand the requirements, you have to express them in a
consistent manner for use by information technology analysts. Traditionally, in
the application development process this step is called analysis.
In application development, business users work in what is called the problem
domain, and system personnel work in the solution domain. These domains
have their own terminology and conventions. VisualAge Requirements Tool is
designed to work at the boundaries of these domains and uses
easy-to-understand terminology that both groups can comprehend. VisualAge
Requirements Tool users define business elements by introducing the
terminology of their choice to describe operational and behavioral aspects of
their requirements specification.
The same VisualAge Requirements Tool information used to describe the
business requirements is used to express the results of the analysis phase of
application development.
9.1.2.4 Give Developers Requirements They Can Understand
VisualAge Requirements Tool provides system developers with behavioral
requirements specifications that they can use for system analysis. The
information displayed by VisualAge Requirements Tool conveys analysis results
that meet various application development needs:
• VisualAge Requirements Tool provides the following elements for data
design:
− 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 procedural
program design:
− Identification of all required program functions (groups of business
transactions that are connected through business rules)
− Specification of the program functions (business rules and their data
retrieval and update requirements)
− Program function reuse (support for business rule uses business rule
associations).
• VisualAge Requirements Tool provides the following elements for
object-oriented design:
− Identification of use cases and user roles (business transactions and
their user role presentations)
120 Beyond BPR
− Identification of business object classes (business information), their
states (attribute and business rule defines associations), their
associations (depends associations), and methods (business rules).
− Identification of function sequencing classes (business transactions and
the sequence of business rules they trigger).
9.1.2.5 Give Developers Requirements Useful for Planning Tests
VisualAge Requirements Tool provides system developers with a behavioral
requirements specification they can use to develop functional verification test
plans.
During functional verification, system developers show system users (business
personnel) that the functions specified in the requirements statement are
satisfied by the proposed system update. VisualAge Requirements Tool provides
a clear way to show this evolution from requirements to system.
Every business transaction should have test cases that show every possible
behavior as determined by the specified business rules. Behavior is simple to
express because the results of an input transaction are the output transactions
that it produces and the effects on the system′s persistent memory (business
information). Business rules control both the output transactions and the effects
on business information.
For every input transaction, testers should create test cases that exercise every
condition dictated by the business rules. Test cases should ensure that the
appropriate business transactions are produced and the business information
reflects the appropriate changes.
9.1.2.6 Give Developers Requirements Helpful for Cost Estimating
VisualAge Requirements Tool provides system developers with a behavioral
requirements specification they can use to calculate function points and thus
develop an early cost estimate for the new system.
The elements in the VisualAge Requirements Tool model provide sufficient
information to calculate function points. The function point method derives a
single number that expresses the functional contents of a system. That number
is calculated by identifying all input and output (business transactions), data
accesses (business rules that use business information), and databases or files
(business information). An analyst gives each of these elements a complexity
factor, and the numbers are added up by category. The totals for each category
are multiplied by a weighting factor, and all numbers are added again to derive
the final function point estimation.
9.1.2.7 Provide Basis for System Evolutionary Changes
VisualAge Requirements Tool provides a basis for a business operation′ s
evolutionary changes involving both business and system personnel.
A business operation developed with VisualAge Requirements Tool to express
requirements is well positioned for future changes and evolution. New functions
are represented as new business transactions. Existing business rules may
already support those transactions. You can validate new behavior by
comparing it with existing behavior.
Chapter 9. VisualAge Requirements Tool 121
You can analyze affected business rules to identify changes in existing business
transactions. You can analyze functional changes at the business level to
evaluate the total impact on the business operation.
These activities, coupled with the function point calculations, provide a solid
base for making decisions relating to function and cost. You can do what-if
evaluations using the information presented by VisualAge Requirements Tool.
9.1.2.8 Map Business Requirements to Implementation Elements
Business transactions identify the need for interchange between the user and
the business operation. The actual implementation of the interchange can be
achieved in many different ways—through a business form, a computer screen,
or with a mouse interaction. VisualAge Requirements Tool provides the link
between the business requirement function and the implementation elements
that support them.
Requirements drive the function provided by the system. Implementation
elements are created to support requirement elements, and the elements must
correspond. For example:
• Business transactions might correspond to graphical user interfaces (GUIs),
screens of nonprogrammable terminals (NPTs), CICS transactions, IMS
transactions, 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 reuse
and impact analysis a reality for the business user and the system developer.
You can tell where business rules are implemented and quickly change them to
support the evolution of the business.
With VisualAge Requirements Tool, development effort to make parts reusable
pays off because parts are visible and easy to find.
9.2 Business Objects
VisualAge Requirements Tool uses only a few basic business elements to record
and display business operations. Collectively, these elements are business
objects. 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 a
business process that is manual, automated, or both. A
business operation is a functional grouping of business
objects. It can group other business operations, business
transactions, business rules, business information, and
business facts.
Examples: accounts receivable, accounts payable,
inventory processing, payroll, quality control
Business transaction The interactions between users and the business operation
under study. Users include people and other business
operations.
122 Beyond BPR
Examples: order quotation request, customer qualification
application, order quotation report
Business rule The behavior of a business operation. Business rules
detail what is done and under what conditions during
processing in a business operation. Business rules can be
classified by the activities that businesses perform to
handle 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 operation
reflecting external business objects.
Examples: customer, order, item
Business fact A discrete data element or a composite of various data
elements. A business fact can be included in other
business facts, as well as in business transactions and
business information. Business facts are relevant to all
business operations and are therefore stored centrally, in
the business fact dictionary.
Examples: customer number, customer address, item part
number
9.3 Associations
Business objects interact with each other in specific relationships called
associations.
Defines A business rule can specify, or define, constraints on business
information and business transactions.
Depends Business information can be contingent on, or depend on, other
business information.
Includes A business transaction and business information can
encompass, or include, a business fact. A business fact can
include 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, business
information.
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 specify
the behavior of your business operations. You can then iteratively view, detail,
and modify them to develop the user requirement statements you want.
Chapter 9. VisualAge Requirements Tool 123
9.4 The User Requirement Statement
The data you enter in VisualAge Requirements Tool makes up your user
requirement statement. VisualAge Requirements Tool provides a wide selection
of views to analyze, validate, and communicate your requirements.
9.5 Positioning
Let′s be a little more specific about the linkage between VisualAge
Requirements Tool, LOVEM-E, and BMT. One of the key work products from a
LOVEM-E project is the PLOVC. In 6.5, “Physical Line of Visibility Chart” on
page 67 we developed a PLOVC for Universal Trust Company′s mortgage
application process. You may have noticed a key characteristic of the PLOVC:
its manual/automation line. This line defines the interface between the manual
and automated activities of a process. System interfaces are shown on the
PLOVC as process blocks that straddle the manual/automation line. LOVEM-E
describes, in general terms, the function of the process block, but its focus is on
the overall process, not the details of an individual process block. This is where
VisualAge Requirements Tool fits. Still operating in the business domain, as
opposed to the systems domain, VisualAge Requirements Tool provides a small
number of versatile business objects that can be used to represent the functional
requirements of a process block.
The sample PLOVC in Figure 30 on page 125 shows the manual/automation line
and its relationship to system process blocks. The system process blocks form
the link between BMT and VisualAge Requirements Tool. In this section we
continue our work with Universal Trust Company′s mortgage application and
show how VisualAge Requirements Tool can be used to define the system
behavior 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 the
sections that follow were produced is beyond the scope of this section. For
detailed information on VisualAge Requirements Tool use, refer to VisualAge
Requirements Tool for OS/2 User′s Guide . The subsequent discussion assumes
an entry level knowledge of OS/2 GUI controls and their function.
9.5.1 VisualAge Requirements Tool User Environment
The VisualAge Requirements Tool main window is pictured in Figure 31 on
page 126. It contains the VisualAge Requirements Tool business objects (their
full names as used by VisualAge Requirements Tool, if different from those
shown, are enclosed in parentheses):
• Business operation
• Transaction (business transaction)
• Rule (business rule)
Chapter 9. VisualAge Requirements Tool 125
• 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; the
business operation template was used to create the mortgage application and
mortgage renewal business operation objects. The Fact Dictionary is an object
that serves as the storehouse for business facts included in VisualAge
Requirements Tool business operations, but more on this in a moment.
9.6 Business Operation
The Business Operation serves as the container for VisualAge Requirements
Tool business objects and typically encompasses a business area or process.
The Business Operation, along with the business objects it includes, make up
the user requirements statement. In this section, we use VisualAge
Requirements Tool to develop the system requirements for the mortgage
application business operation. The mortgage renewal business operation
shown in the main window is an example of the support for multiple business
operations that VisualAge Requirements Tool offers. A business operation can
be nested within another business operation, thus enabling VisualAge
Requirements Tool to be used to define requirements for large processes
consisting of a number of individual business operations.
Selecting the mortgage application business operation presents the user with the
Operation Diagram View pictured in Figure 32 on page 127. The Operation
Diagram is the complete picture of the business operation and shows all the
business 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 complex
business operation. VisualAge Requirements Tool provides two tools, Overview
and Zoom lens, which can be used separately or in conjunction to manage the
level of detail visible in the Operation Diagram. The user can select and size the
area of general interest with Overview, then use Zoom lens to enlarge and
center it within the window.
From the Operation menu in the Operation Diagram, the user can access other
views of the business operation. The other views available include the:
Settings and Icon view. Settings provides a notebook through which the user
can rename the business operation. The Icon view provides an icon view of
the business objects included in the business operation. The Icon view is
less useful than the Operation Diagram view because it does not show
associations that provide valuable information on the relationships between
the business objects.
Operation diagram view. Allows the user to open another view of this
business operation that can be useful for a user working with two different
parts of a business operation simultaneously.
Chapter 9. VisualAge Requirements Tool 127
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 the
business information included in the business operation. It identifies the
entities (business information) and their attributes (business facts) and the
relationships and constraints among entities.
User role view. This view is discussed in more detail in 9.7, “Business
Transactions.” It provides a view showing all the business transactions that
can be performed by a particular user. It can be used to check for
completeness; for example, it quickly reveals if any business transactions
required by a specific user are missing.
Incomplete business objects. VisualAge Requirements Tool business
transactions, rules, and information all have a completeness indicator to
indicate whether the business object is completely defined. VisualAge
Requirements Tool uses this indicator to generate a view showing
incomplete business objects that can be used to assess progress in
modeling a business operation.
Rules classified as. VisualAge Requirements Tool provides a business rules
classification scheme that can be used to categorize business rules. This
topic is covered in more detail below, but this menu option provides a means
to quickly identify business rules that share the same classification.
Operation containing. We mentioned above that VisualAge Requirements
Tool business operations can be nested within other business operations. In
our 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 which
the current business operation belongs.
9.7 Business Transactions
The business transaction is one of the fundamental concepts of VisualAge
Requirements Tool. The VisualAge Requirements Tool approach emphasizes
the function, or system behavior, a system must provide, rather than focusing
narrowly on user interface, process, or data design. The business transaction is
the means through which business users obtain their services and are used to
activate business rules which, in turn, can define, query, or change business
information. Transactions can originate from either an external event (for
example, a customer request for a quote) or a business rule (for example, check
credit limit).
In our mortgage application example, we use the info request business
transaction to illustrate the use of a business transaction and its relationship to
business rules and business information. Info request is a business transaction
initiated when either a customer or a prospect contacts Universal Trust for
information on its mortgage products.
The settings for info request are stored in a notebook and can be accessed
directly through the info request object or through a pop-up menu like the one
shown in Figure 33 on page 129.
128 Beyond BPR
Figure 33. Info Request Business Transaction Settings Pop-up M e n u
Figure 34 on page 130 shows the Type page of the info request business
transaction settings.
Chapter 9. VisualAge Requirements Tool 129
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 an
external event.
Query. A business transaction that requests information regarding the
current content of business information.
Report. A business transaction that produces output for its user. Report
transactions don′t alter the contents of business information.
Prompt. A combined input and output transaction that is used to collect
information from the user.
A Logged check box can also be set if instances of this transaction are to be
saved for future reference.
In the case of our info request transaction, a user has contacted the branch loan
officer and requested information on Universal Trust Company′s mortgage
products, so we assign the event notification transaction type to this transaction.
Figure 35 on page 131 shows the User page of the info request business
transaction.
130 Beyond BPR
Figure 35. Info Request Business Transaction User Role
This page records the user who created the transaction. Two choices are
available:
User. Indicates the business transaction receives input from the user of the
business operation.
Business Operation. Indicates the transaction sends output to a user.
The User Role captures the name, title or category of the user who either
creates the business transaction or is the destination of any output sent through
this business transaction and is used to produce the User Role Diagram. The
User Role Diagram allows the user to relate transactions to the users who
perform or initiate them. This is useful for not only ensuring transaction
coverage within a user role, but also for confirming there is an appropriate
match between transactions and user role. For example, a specific transaction
can 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 the
transaction may be necessary.
The Completed page of the info request business transaction notebook allows
the user to indicate completion status for this object and is used to generate
views of completed objects and those objects that require additional work to
Chapter 9. VisualAge Requirements Tool 131
complete. The notes panel allows reviewers and other users to add detailed
comments.
The General page shown in Figure 36 is the final page of the info request
settings notebook and contains the name of the business transaction and any
additional descriptive information the user would like to provide about the
transaction.
Figure 36. Info Request Business Transaction General Information
9.8 Business Rules
Business transactions capture the interactions between users and the business
operation, and business information maintains the current status of entities of
interest to the business operation. Business rules provide the link between
transactions and information and describe the behavior of the business
operation. Business rules detail what is done and under what conditions during
the normal running of the business operation.
VisualAge Requirements Tool business rules can:
• Use other rules. This is to support rule reuse by making repeated
specification 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 is
analogous to a user asking the system to process an order, look up a customer
record, or produce a report. Business information is the data necessary to fulfill
these requests. Business rules are a business user representation of the
function provided by the program modules, program procedures, or data
constraints 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 the
quotation business rule, which is shown enclosed by the small square.
Figure 37. Quotation Business Rule
The information and functions available through the quotation business rule
object through a pop-up menu are:
Chapter 9. VisualAge Requirements Tool 133
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 classification
are captured.
Transactions initiated, Transactions that trigger, and Transactions defined.
These options show views of transactions initiated by this rule, the
transaction that triggered this rule, and transactions defined by this rule (for
example, the contents of a report).
Information modified, interrogated, or defined. These views show the
business information affected by this business rule.
Rules used and Rules that use. These views show the forward and backward
relationships 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 and
General sections have been discussed before and are the same for business
rules, so we do not cover them here. Our interest lies in the Actions and
Classification 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 selecting
the New button, which adds a numbered tab to the bottom of the Actions page of
the notebook. However, because there are already two actions defined for the
Quotation business rule, we select tab 1 to open the first action, shown in
Figure 39 on page 135.
Figure 39. Quotation Business Rule Action 1
The business rule Actions are evaluated sequentially, beginning with the
Condition 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 whether
the customer requesting mortgage information is an existing customer. If true,
the Result indicates the following action will be taken:
Chapter 9. VisualAge Requirements Tool 135
1. Look up customer information in the CUSTOMER business information for
inclusion 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 is
not an existing customer and differs only from Action 1 in that customer
information 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 by
selecting the Up button, which advances the Action towards the first tab, or the
Down button, which moves the Action towards the last tab.
The Classification section of the business rule, which is shown in Figure 40, lets
a business rule be classified according to its primary activity. The Rule
Classification entry allows selection of one of twenty-five classification
categories. 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 in
Table 3 on page 137. The classification scheme is a series of generic activities
that businesses perform to handle their business objects effectively. The
activities are task areas or management and control areas, and they can be
automated or performed by people.
This business rule classification covers a complete set of task areas. All task
areas are carried out in a business enterprise against its business objects. In
some cases, the task is performed formally, possibly automated or otherwise
explicitly 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 you
can use different terms to classify a specific activity. You likely use different
terms 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.
Table 3. Business Rule Classification and Suggested Synonyms
On individual business objects
1. Make: build, create, assemble, compile, define, acquire
2. Move: transfer, position, receive, ship, store, disburse
3. Test: quality control, inspect, verify, audit, appraise
4. Maintain: repair, adjust, calibrate, update
5. Scrap: delete, reject, manage end-of-life, tear down, dismantle
6. Set-up: prepare, format
7. Catalog: describe, account for, identify, list
8. Unit costing: pricing
9. Keep history: log events, journaling
Track and control business objects and processes
10. Monitor: track, measure, evaluate, age
11. Schedule: dispatch, release, prioritize, expedite, allocate
12. Optimize: balance
13. Collect data: acquire information
14. Report status: show current situation
15. Report exceptions: show exceptions
16. Keep summarized history: maintain summarized versioned data
17. Report summarized history: show summarized versioned data
Plan and account for processes
18. Sourcing
19. Develop estimates: set standards, propose targets, set control
limits, establish quotas
20. Requirements planning
21. Budgeting: control expenses, monitor billing, supervise payroll
22. Load solutioning: load balancing, contract vendors
Long-range planning and strategy
23. Forecasting: trend analysis
24. Modeling: make statistical decisions
25. Strategic planning
A quick reference summary of each business rule classification category follows.
Each category is named, followed by a list of suggested synonyms, and briefly
described. Synonyms are optional; you can select from those suggested or
supply your own.
Activities on Individual Business Objects
1. Make: build, create, assemble, compile, define, acquire
Chapter 9. VisualAge Requirements Tool 137
The make category accounts for the basic interaction between the enterprise
and the business object. This interaction is the reason for the initial interest
of the enterprise in the business object. It is an expansion of the make
concept, 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, location
of the business object. Location can be expressed by building number,
department number, disk address, or any other reference. This activity is
required because most business objects must often be relocated or moved
during 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 in
the 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. Records
that represent physical business objects must be maintained or updated to
reflect 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 to
salvage a defective or unnecessary business object.
6. Set-up: prepare, format
The set-up category is not productive in itself, but the activities are
performed because they are necessary or because we expect benefits from
them in the future.
7. Catalog: describe, account for, identify, list
The catalog category is not as vital as some other categories, but it is
needed to track managed business objects. It represents the tasks required
to track individual business objects or batches of business objects to keep
basic facts about them.
8. Unit costing: pricing
The unit costing category represents the costing of business objects at
different points of their processing. Because costing requires a significant
resource 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, or
batches, of business objects. Information about particular events that
occurred in relation to the business object is kept and time stamped.
Historical data is maintained until the business object leaves the enterprise′ s
sphere of interest. These activities often are carried out informally through
notes 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 to
evaluate the state of a process or business object. It is a basic source for
reporting activities.
11. Schedule: dispatch, release, prioritize, expedite, allocate
The schedule category reflects the way management establishes and alters
the order in which business objects are processed. The information required
for these activities is obtained from reporting activities or external
communications.
12. Optimize: balance
The optimize category is a form of planning because real-world processes
are affected by schedule activities.
13. Collect data: acquire information
The collect data category represents all of the actions performed to supply
information about processes and business objects. It covers all of the
information transfer protocols, data files, and error-correcting cycles.
14. Report status: show current situation
The report status category presents current data about processes and
business objects for people or systems to use. Data is gathered through
collect data activities.
15. Report exceptions: show exceptions
The report exceptions category is similar to report status, except data is
presented 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 files
and accumulates it in historical form: year-to-date, month-to-date,
week-to-date, or other time brackets. The summarization can be based on
the business object type or physical attribute.
17. Report summarized history: show summarized versioned data
The report summarized history category produces reports from summarized
history files.
Activities to Plan and Account for Processes
18. Sourcing
The sourcing category covers decisions about which process is going to
handle business objects on hand. Typically, make or buy decisions fall in
this category, but it also includes deciding whether to rework existing stock
or 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 progress
of processes and business objects. The parameters are used by report
exceptions.
20. Requirements planning
The requirements planning category determines the time frames, kinds, and
quantities of resources needed to satisfy demand for business objects.
Chapter 9. VisualAge Requirements Tool 139
21. Budgeting: control expenses, monitor billing, supervise payroll
The budgeting category determines the cost and control of the expenses of a
process in relation to a given business object. It also covers billing for the
value added to the business objects.
22. Load solutioning: load balancing, contract vendors
The load solutioning category addresses the optimization of process
utilization based on the sourcing decisions made through sourcing. This is a
high-level optimize, applying to individual processes, because it applies to
process lines or larger operational units.
Activities to Accomplish Long-Range Planning
23. Forecasting: trend analysis
The forecasting category determines trends across processes and business
objects and forecasts future requirements.
24. Modeling: make statistical decisions
The modeling category implements process object models to resolve what-if
questions and perform sensitivity analysis. Support for decisions is based on
model outputs.
25. Strategic planning
The strategic planning category sets direction based on information or
forecasts about the overall environment, either external or internal to the
enterprise.
9.9 Business Information
Business information is another of the major business object types in VisualAge
Requirements Tool. They represent the external entities or things of interest to
the business or organization which, collectively, maintain the knowledge
required to operate the business. In data modeling terms, business information
is much like the entity found in entity-relationship modeling. In fact, as we′ll see
below, VisualAge Requirements Tool can produce a data dependency diagram
that is similar to an entity-relationship diagram except it is presented at a higher
level of detail.
VisualAge Requirements Tool divides business information into two
subcategories that are generally equivalent to master and transaction files. A
descriptor is equivalent to the master file concept and is the business
information category responsible for maintaining current information which
reflects the ongoing flow of transactions through the system. A transaction log is
analogous to a transaction file and keeps a journal of past transactions. Not all
transactions need logs (for example, queries may not) but they often need to be
remembered for future reference. Transaction logs are needed as an extra
service by systems to track their own business transactions.
The Universal Trust Company info request transaction introduced above uses
three 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 business
information object are:
Settings: In addition to the status and general attributes found on all
VisualAge Requirements Tool business objects, Settings is used to indicate
the category of business information (descriptor or transaction log).
Information depended upon and Information that depends on: These views
show the constraints that exist between this and other business information.
Rules that modify, Rules that interrogate, Rules that define: Provide views
that show the business rules responsible for modifying (updating),
interrogating (inquiring), and defining (creating) business information. These
views 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 business
information.
Facts included: Provides a view of the business facts (attributes) which this
business information (entity) includes.
Operation containing: Indication of which business operation (business
process) contains this business information.
Chapter 9. VisualAge Requirements Tool 141
Figure 42 on page 142 shows the customer business information settings which
indicates customer is a descriptor business information object.
Figure 42. Business Information Type
9.9.1 Data Dependency Relationships
Our Universal Trust Company mortgage application example contains four
different business information objects, Product, Prospect, Customer, and
Mortgage. In Figure 43 on page 143 the VisualAge Requirements Tool
Information Dependency diagram illustrates the relationship between these
different types of business information. This diagram is similar in form to the
entity-relationship (E-R) diagrams generated in formal data modeling but without
the depth of relationship detail and formal representation of E-R diagrams.
142 Beyond BPR
Figure 43. Information Dependency Diagram View
9.10 Business Facts
In constructing a VisualAge Requirements Tool business operation model the
initial focus is on business transactions and business information. Once these
are identified the analysis of the business information can move to a lower level
and identify the pertinent facts relevant to the business transaction and entity. In
VisualAge Requirements Tool these facts (or attributes) are called business
facts. Business facts are created and stored in the Fact Dictionary and then
added to individual business information objects as the understanding of the
relationships between business transactions, information, and facts grows.
Figure 44 on page 144 shows the business facts included in the customer
business information object. Business facts are added to the customer business
information object by dragging the business fact icons from the Fact Dictionary to
the Facts Included view for the customer business information.
Chapter 9. VisualAge Requirements Tool 143
Figure 44. Business Information and Business Facts
9.11 Data Consolidation
Before reviewing the requirements with users, the business rule classification
data 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 transactions
and 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 listed
transactions?
2. Use the Operation diagram to verify all business rules are triggered by a
transaction.
3. Use the transaction flow diagram to review the behavior of business
transactions.
4. Iterate these steps until you are satisfied.
9.12 Review Requirements Statements with Users
The final step, at least in each iteration of the requirements specification, is to
use VisualAge Requirements Tool to display, describe, and discuss the
requirements with the users of the system being specified. The VisualAge
Requirements Tool presentation is highly intuitive and grasped quickly by users,
encouraging their participation in critiquing, improving, and validating the
requirements. Changes can be made to the specifications as the users review
the material. Once validated, the requirements specification is ready to be used
in implementation. A sample of VisualAge Requirements Tool reports that can
be used to support implementation projects is shown in the following section.
9.13 VisualAge Requirements Tool Reports
Figure 45, Figure 46 on page 146, Figure 47 on page 146, and Figure 48 on
page 147 contain samples of the reports produced by VisualAge Requirements
Tool.
Figure 45. Sample Business Transaction Report
Chapter 9. VisualAge Requirements Tool 145
Figure 46. Sample Business Information Report
Figure 47. Sample Business Rule Report
146 Beyond BPR
Figure 48. Sample Fact Dictionary Report
Chapter 9. VisualAge Requirements Tool 147
148 Beyond BPR
Chapter 10. FlowMark
In Chapter 7, “Workflow Management” on page 87 we discussed workflow
management concepts. This chapter introduces FlowMark, IBM′s workflow
management solution.
In this chapter, we explain the two components of FlowMark: Buildtime and
Runtime. We will also explore how the Universal Trust Company Mortgage
Application can be implemented in FlowMark and discuss how FlowMark fits in
the 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
Copyright IBM Corp. 1995 149
10.1 FlowMark Description
As business processes become more and more complex, planning and
managing all the activities and resources involved in getting a job done become
more challenging. Tracking the flow of work through an enterprise requires time
and diverse skills and knowledge.
These challenges can be reduced by using a well-documented workflow model
to automate your business processes. Automating your processes can save your
organization time and money by presenting the right activity to the right person
at the right time, supported by the information and the programs to perform the
activity. You can build into your workflow models the business regulations that
you want to enforce. FlowMark provides you benefits in the following areas:
Application integration. FlowMark supports several types of applications. It
can execute programs residing in workstation or host systems. It can run
applications on OS/2, Windows, AIX, CICS, IMS, and TSO. It can also
integrate with Lotus Notes, Lotus cc:Mail, Search Manager/2, Easel, Time
and Place/2, VisualInfo, and 3270 host applications using HLLAPI. Because
FlowMark can drive several types of applications, you can share data
between these applications. Therefore, you can put together solutions that
make the best use of different technologies, resulting in efficient and
cost-effective solutions.
Flow independence. With FlowMark, changes in an organization′s process
do not affect the applications. Applications are not tightly bound to the
sequence in which they are performed. When processes change, the right
applications can easily be reassigned to the right activities of the new
process. You therefore shorten application development time during process
changes.
Parallel development of programs. FlowMark handles the passing of data
from one application to another and the sequencing of program execution.
Because of this, applications can be written with focus on the results, instead
of on the interface with other applications. Therefore, applications can be
developed in parallel as they have become more independent of each other.
This leads to shorter application development cycles, especially when
implementing new application systems.
The FlowMark workflow manager helps you automate your business processes.
It integrates the tasks performed by computer applications with the everyday
tasks of staff members. FlowMark accomplishes this using its two major
components.
10.1.1 Buildtime
FlowMark Buildtime contains folders for modeling processes and administering
the system. Only modelers and system administrators need a Buildtime
workstation. 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. The
product 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 same
activity in parallel.
A convenient graphical interface is provided for specifying this information.
Process models can be animated with sample data to verify their completeness
and viability. Once this has been done, Buildtime process models become ready
for translation (conversion) into Runtime process templates, from which
executable copies can be made.
10.1.2 Runtime
FlowMark Runtime contains folders for controlling processes and using work
lists. Most users need a Runtime workstation. Using FlowMark Runtime, you
can:
• 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 a
process template by translating a Buildtime process model. Each such copy is
called a process instance, and each step is called instantiation.
Once an authorized person starts a process instance, Runtime maintains the
work lists of the staff to whom activities are assigned. Each staff member′s work
list receives assigned activities of running process instances. When the staff
member starts an activity, FlowMark starts the program specified in the process
model and can pass it any necessary data. The staff member then generally
interacts 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 staff
members to whom it is assigned. Authorized people can intervene to suspend,
resume, stop, and restart process instances.
10.1.3 Workflow Model
A workflow model is a complete representation of a process, comprising a
process diagram and the settings that define the logic behind the components of
the diagram.
Using the settings notebooks and other dialogs provided by FlowMark Buildtime,
you create workflow models from these components. You can then convert the
workflow models into process templates for use in FlowMark Runtime. The
components of the FlowMark diagram are the following:
Process diagram. Whereas a process document uses words to describe the
sequence of working procedures, a process diagram uses symbols to
represent the activities that make up the process. The possible ways that
work and data can flow through a model are represented graphically by
arrows called connectors.
A workflow model consists of several elements:
• Processes
• Activities
• Blocks
Chapter 10. F l o w M a r k 151
• Connectors
• Containers for data
• Conditions
• Programs
• Staff
Process. A process is a sequence of activities that must be completed to
accomplish a task. The process is the top-level element of a FlowMark
workflow model. Multiple instances of a FlowMark process can run in
parallel.
Activity. An activity is a step within a process. It represents a piece of work
that the assigned person can complete by starting a program or another
process. A FlowMark workflow model consists of the following types of
activities:
Program activity Has a program assigned to perform it. The program is
invoked when the activity is started. In a fully
automated workflow, the program performs the activity
without human intervention. Otherwise, the user must
start the activity by selecting it from a Runtime work
list. Output from the program can be used in the exit
condition for the program activity and for the transition
conditions to other activities.
Process activity Has a process assigned to perform it. The process is
invoked when the activity is started. A process activity
represents a way to reuse a set of activities that are
common to different processes. Output from the
process can be used in the exit condition for the
process activity and for the transition conditions to
other activities.
Block. A block is a modeling construct used in a process diagram for one or
more of the following purposes:
• Reducing the complexity of a process diagram. You can group several
activities and nested blocks together under one block symbol to keep the
process diagram uncluttered.
• Looping through a series of activities. If you specify an exit condition for
the block, the activities in the block are executed repeatedly until the exit
condition evaluates to true.
• Implementing bundles. By following the restrictions for bundles, you can
replicate a single activity as many times as are necessary to process
data input to the block at run time.
Bundle A bundle is a special kind of block that supports
multiple instantiations of a single program or process
activity at run time. Use of this modeling construct
enables your workflow model to cope with situations
where an indeterminate number of activities are
required at run time.
The activity that is replicated is called the pattern
activity, and each instance of it is called a bundle
activity. The number of bundle activities created at run
time is determined by a special program activity called
the planning activity. A special executable program
152 Beyond BPR
EXMPOBCL.EXE is supplied with the FlowMark
workflow manager for use in planning activity.
Control Flow. The flow of control through a running process determines the
sequence in which activities are executed. The FlowMark workflow manager
navigates a path through the process that is determined by the evaluation to
true of start conditions, exit conditions, and transition conditions.
Connector. Connectors link activities in a workflow model. Using
connectors, you define the sequence of activities and the transmission of
data between activities. The activity from which a connector originates is
called the origin activity. The activity to which the connector points is called
the target activity. Connectors are not required in a workflow model in which
all activities should become ready to start when the process is started and
no 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 workflow
model. Several control connectors can be associated
with an activity. A control connector has a condition
associated with it that directs the flow. This is called a
transition condition.
Default connector Specifies where control should flow when the transition
condition of no other control connector leaving an
activity evaluates to true. Default connectors enable
your workflow model to cope with exceptional events.
Data connector Specifies the flow of data in a workflow model. A data
connector originates from an activity or a block and
has an activity or a block as its target. You can specify
that output data is to go to one target or to multiple
targets. A target can have more than one incoming
data connector.
Data Container. In a FlowMark workflow model, storage is allocated for the
input 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 data
containers called source and sink. Source represents the input container for
a process or block, and sink represents the output container.
Each data container is defined by a data structure. Data connectors
represent the transfer of data from output containers to input containers.
When a data connector joins an output container with an input container, and
the data structures of the two containers match exactly, the FlowMark
workflow manager maps the data automatically. Otherwise, you must map
individual members of the output data structure onto members of the input
data structure.
Data Structure. A data structure is an ordered list of variables, called
members, that have a name and a data type. The maximum size of a data
structure is 256 member items. Data types are string, long, floating point,
and structure. The FlowMark workflow manager supports one-dimensional
arrays 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 control
in a process. In FlowMark workflow models, you define logical expressions
that are evaluated by FlowMark Runtime to determine when an activity may
Chapter 10. F l o w M a r k 153
start, end, and pass control to the next activity. Here are the types of
conditions:
Start condition The condition that determines when an activity with
incoming control connectors can start. The start
condition can specify that all incoming control
connectors must evaluate to true, or that at least one
of them must evaluate to true. Whatever the start
condition, all incoming connectors must be evaluated
before the activity can start. If an activity has no
incoming control connectors, it becomes ready when
the process or block containing it starts.
Exit condition A logical expression that, if specified, must evaluate to
true for control to pass from an activity or block.
Transition condition A logical expression associated with a control
connector. If specified, it must evaluate to true for
control to flow along the connector.
Program. In the FlowMark workflow manager, program means a
computer-based application program that supports the work to be done in an
activity. Program activities reference executable programs using the logical
names associated with the programs in FlowMark program registrations.
The program registration can contain run time parameters for the executable
program.
Staff. Each activity in a process is assigned to one or more staff members
defined in the FlowMark database. Whether an activity is started manually
by the user or automatically by the FlowMark workflow manager, and
whether 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 your
enterprise to the FlowMark database. For each person defined, you can
specify a level, an organization, and multiple roles. These attributes can be
used at run time to dynamically assign activities to people with suitable
attributes.
10.1.4 How These Pieces Fit Together
You create your workflow model in FlowMark Buildtime. You draw a diagram of
your process using the symbols for activities and blocks. The process can
consist of just one activity or of many activities and blocks.
You can leave all the activities in the process detached from each other, in
which case they all become ready to start simultaneously. If the order in which
activities start is important in your process, you can control this by linking them
with control connectors. When the process is running, the conditions you define
on these connectors are used to determine which activities are started and
which are not.
You can also link activities and blocks with data connectors, if the data used by
or resulting from one activity is required by a subsequent one.
You assign people and programs to the activities. You can be very flexible in
your staff assignments. Instead of assigning an activity to a specific person, you
can assign it to a group of people who meet specific criteria at run time. Any
one of them can start the activity.
154 Beyond BPR
The program registrations that you assign to activities and any input and output
data structure definitions that the activities require must be known to the
FlowMark database before you create your model.
After you have created your model and tested it, you translate it into a form that
can be used by end users of FlowMark Runtime. When someone starts an
instance of the translated process, the FlowMark workflow manager navigates
through the process and automates the sequencing of activities.
You can make changes to or even erase your workflow model after you have
translated it, and the template and instances of it used in Runtime are not
affected. If you want a changed version of your model to be used in Runtime,
you must translate the changed version.
10.2 Modeling with Buildtime
FlowMark deals with actual activities. These are the programs that will run to
complete the workflow. Therefore, our starting point in our case is the physical
charts, namely the PLOVCs and the JLOVCs of our Universal Trust Company
mortgage example.
First, identify all the To Be models that were generated from your business
process reengineering. In real life you want to assess To Be models, not As Is
models. Your want to see how efficient and cost effective each model is. You
also want to project what impact each model has to your customers. But in this
exercise, for simplicity let us assume that you want to assess implementing an
imaging system in the As Is Mortgage LOB from forward mortgage application
(AC3) activity to set up mortgage account (AC13). This imaging system will
complement 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 the
activities of a process that will be implemented as a workflow must have some
form of automation. Processes are usually made up of automated and manual
activities. In FlowMark, automated activities are performed by associating these
to programs. So during execution, when the workflow manager encounters an
automated activity, the automated activity calls a program and that program
executes.
Manual activities on the other hand are associated with checklist programs.
These checklist programs provide the user a list of activities that need to be
checked to reflect what manual activities have been performed. This is so
FlowMark can inform the user that all preceding activities have been performed
and the manual activity can now begin. Also, this is a way for FlowMark to get
feedback on the results of the manual activities so that you can use that
information later in the workflow. So during execution, when the workflow
manager encounters a manual activity, it calls a checklist program. FlowMark
provides a checklist program, EXMPOMAN.EXE, that you can use. However, you
can develop a more sophisticated checklist program if you wish.
In the mortgage application example, implementing an imaging system to all the
activities from AC3 through AC13 results in a fully automated workflow
implementation.
Chapter 10. F l o w M a r k 155
Some LOVEM-E/BMT components have corresponding FlowMark components.
Table 4 on page 156 shows the correspondence between LOVEM-E/BMT
components and FlowMark components.
LOVEM-E (BMT) Components FlowMark Components
Activity and task Program activity
PLOV and JLOV Process activity
Loop Block activity
Information flow Control and data connectors
Function, department or job Staff definition
Start condition Start or transition condition
Exit condition Exit or transition condition
Description Documentation of a program or a
process activity
PA, OA, GSP, AIR, CSF, MR, key Documentation of a program or a
indicator process activity
Table 4. Correspondence between BMT and FlowMark Components
Because the activities from AC3 through AC13 had been entered in BMT, you
need 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 PLOVC
containing PLOVCs and JLOVCs, and JLOVCs containing more JLOVCs (see
Figure 29 on page 113), then you have to map all the activities in all the PLOVCs
and JLOVCs that apply to FlowMark program activities.
In our mortgage example, if we intend to implement our programs down to the
task level for the headquarters real estate administrator job, then we should map
the PLOV activities set up property appraisal (AC4) and verify mortgage approval
(AC6) to FlowMark process activities, and then map their JLOVC activities to
FlowMark program activities. But for simplicity we do not include the activities
of our JLOVCs in this exercise.
Therefore, our interest is only in the activities from AC3 through AC13 in the
PLOVC found in Figure 16 on page 68. It involves the following 11 activities:
AC3—Forward mortgage application
AC4—Set up property appraisal
AC5—Appraise mortgage property
AC6—Verify mortgage approval
AC7—Notify of mortgage rejection
AC8—Notify of mortgage acceptance
AC9—Sign off funds for mortgage
AC10—Enter approved mortgage details
AC11—Prepare mortgage documents
AC12—Present mortgage documents
AC13—Set up mortgage account
156 Beyond BPR
10.2.1 Creating a FlowMark Model
This section assumes you installed the FlowMark workflow manager. Log on to
FlowMark Buildtime and map these activities to FlowMark program activities.
Go to the Buildtime Processes Folder and create a new process. Then open that
process and put the program activities in the diagram. For detailed instructions
on drawing a diagram in FlowMark, refer to the discussion of drawing the
diagram of a new or existing process in the FlowMark V2.1 Modeling Workflow
manual. Figure 49 shows how AC3 through AC13 are mapped into FlowMark
program activities. AC2 assist mortgage application completion appears on the
FlowMark 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 the
diagram. Customer processes are external to FlowMark workflows. FlowMark
encompasses only the business processes. FlowMark can enhance the interface
to the customer, though. It can provide information that the customer needs and
provide this in well-designed printouts for the customer to keep. Or it can run
interactive transaction programs which the customer can interface with.
Systems are imbedded in the FlowMark program activities. You first create a
program registration in the FlowMark Program Folder. Open the program
registration and define what the program is, what data it needs, what data it
generates, where it resides, what platforms it runs on, what parameters to pass,
and how it should run. Then, in the program activities, you define which
program registration needs to be called.
Now connect the program activities you just created in FlowMark with control
connectors and data connectors. Control connectors specify what sequence the
Chapter 10. F l o w M a r k 157
program activities will follow. Data connectors specify where the data will flow.
Figure 50 on page 158 shows program activities AC3 through AC13 with control
and 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 is
because our document storage will be part of our imaging system, not FlowMark.
You now have program activities with control and data connectors. You can now
define what the actual programs that will be called are, what data the program
activities 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 a
diagram.
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 of
the model.
Having laid down your model first, it is easy to determine what components
need to be defined.
158 Beyond BPR
10.2.2 Creating Data Structures
Now you need to define what data your workflow will use. You need input data
for program activities and output data for program activities. The input data
structure can be the same or different from the output data structure. In this
exercise, since we concentrate more on processes than on data, we leave it up
to you to design your own data structures for the mortgage application. Once
you have done this, go to the Data Structures Folder and create your data
structures for the mortgage application. For detailed instructions on creating
data structures, refer to the discussion of defining a data structure object in
FlowMark V2.1 Modeling Workflow. Figure 51 shows an example of an
application data structure.
Figure 51. Data Structure of Application Data
10.2.3 Creating Program Registrations
Now you need to define what programs FlowMark will use. Each program
activity must reference a program registration. Go to the Program Folder and
create your program registrations. In FlowMark Buildtime, the actual programs
need not exist at the moment. But in FlowMark Runtime, the actual programs
must be ready for execution. For detailed instructions on creating program
registrations, refer to the discussion of creating a program registration in
FlowMark V2.1 Modeling Workflow. Figure 52 on page 160 shows an example of
a program registration that uses application data.
Chapter 10. F l o w M a r k 159
Figure 52. Program Settings of the Verify_Mtge_Apprvl_Pgm
Notice that the check box Same data structure for programming activity is
checked. This ensures that the data structures you will define in the program
activity setting are the same as those you define here.
The actual application that will execute In FlowMark Runtime is defined in one of
the platform pages. FlowMark allows you to run application programs in three
platforms: OS/2, AIX, and Windows. For each program registration, select which
platform you want your application program to run on and enter the name and
the location (path) of your program.
If you want to execute an application program in OS/2 or Windows that will
require user intervention, select the Visible and Start in foreground options in the
platform tab of the program settings. This will ensure that when the application
program executes, it becomes noticeable to the user in his workstation.
Figure 53 on page 161 shows an example of the program VERIF.EXE defined in
the 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 program
registrations. This is because you need to enter your data structures in your
program registration settings.
10.2.4 Defining Staff
FlowMark provides ways of logically defining who can run workflow programs. It
does 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 the
people you are authorizing. You can authorize by role, level, or organization.
Define roles, levels, and organizations in their respective folders in the Staff
Folder.
The People Folder defines the FlowMark users. It is there where you can add
the roles, levels, and organizations they belong to. It is also there where you
authorize FlowMark functions to each user.
You do not need to perform your staff definitions if you will be testing on a
stand-alone environment. This is because you can perform all your testing using
the administrator user ID. But if you will test your applications using several
clients and you want to log on to them at the same time, then you need to create
your staff definitions.
Chapter 10. F l o w M a r k 161
10.2.5 Defining Program Activities
Now you can put everything together in the FlowMark mortgage application
model. Go back to the Buildtime process model and access the diagram of the
mortgage application. For each program activity, add the program, data
structure, and staff you have defined earlier.
You can define programs to execute automatically in the program activity
settings. You do this by selecting the option automatic in the start tab. This is
useful for programs that do not require human intervention in your workflow.
Figure 54 shows an example of the start tab for the verify mortgage approval
program activity and how it is set to start automatically. Once a mortgage
application has been approved or denied, this program activity can automatically
execute to check the status of the application and route the image of the
application to the right people based on the status.
Figure 54. Start Tab
The program activities verify mortgage approval and sign off funds for mortgage
need further discussion since there are multiple data flows flowing out of them.
There is a transition definition in the control settings of control connectors that
allow you to state what condition needs to be fulfilled so that control will be
passed on to the next program activity. If this is left blank, control automatically
passes to the next program activity.
So when you have two or more control connectors coming out of a program
activity, and you want control to be passed to all the program activities attached
to 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 run
simultaneously, producing parallel flows. This is what happens after the sign off
funds for mortgage program activity.
When you have two control connectors coming out of a program activity and you
want control to be passed to either one or the other program activity depending
on some data value (an OR condition), then you need to specify the transition
condition of each of the control connectors. In the case of verify mortgage
approval, the control is passed either to notify of mortgage rejection or to notify
of mortgage approval, and the data that has to be checked is status (see
Figure 51 on page 159). Therefore, in the transition page of the control
connector leading to notify of mortgage rejection, you can put Status =
REJECTED. In the transition page of the control connector leading to notify of
mortgage approval, you can put Status = APPROVED. Since there is another
control connector leading to sign off funds for mortgage and you want control to
be passed to this if the application is approved, you can put in the transition
page of the control connector Status = APPROVED. Figure 55 shows the
transition 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 text
representing variables should be exactly the same as the name of the variable in
the data structure definition. If they are not exactly the same, FlowMark cannot
recognize the transition variable and the control of the workflow model becomes
unpredictable.
Chapter 10. F l o w M a r k 163
10.2.6 Animation
Now you can test your mortgage application model by animating it. The
animation facility of FlowMark provides another means to verify and debug a
process model by simulating a process instance. You can explore various paths
forward and backward through the process step by step at any time during
development. You can simulate the different behavior of people and programs.
It helps you visualize how your workflow model will behave when you move it to
FlowMark Runtime.
You also see the data structures you use as FlowMark displays the data
containers of every process activity that is running. You can test your workflow
by entering values in the data containers and seeing how your workflow runs
with these values.
Figure 56 shows the mortgage application model during animation.
Figure 56. Animation of the Mortgage Application in FlowMark Buildtime
For detailed instructions on animating workflow models, refer to the discussion
of using the animation facility in FlowMark V2.1 Modeling Workflow.
164 Beyond BPR
10.2.7 Preparing Application Programs
Once you are satisfied with the behavior of your FlowMark workflow model, you
are ready to translate the model to a form that FlowMark Runtime can use. But
before you do, make sure that your application programs have been defined in
the program registration and are ready for execution. If they have not been
defined, the translation of your FlowMark model will fail. If they are not ready for
execution, your workflow model will fail when FlowMark Runtime calls these
programs.
Prepare simple application programs that are easy to develop yet provide a
good feel of how the final application will look. Since at this point you are only
prototyping the application, you should balance development speed with
application functionality. REXX, an IBM programming language, is highly
recommended. It is similar to Basic and is therefore easy to learn and use. Yet
it can create GUI interfaces allowing you to prototype functionally rich
applications.
10.3 Executing with Runtime
Once you translate your mortgage application model in FlowMark Buildtime and
prepare the programs that the workflow model will call, you can log on to
FlowMark Runtime. Open the Runtime Processes to see what workflow process
templates you can activate. When you activate a process template, it creates a
process instance. When you activate a process instance the workflow behind the
process template begins execution. Figure 57 shows an example of a Runtime
Process 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 same
process template. This means that you can run parallel process instances, all of
which come from the same workflow model. Therefore, you can perform parallel
testing by entering different data in each process instance to test how the
workflow will respond. During production, each process instance can represent
ongoing transactions of different customers.
Chapter 10. F l o w M a r k 165
In the Work List folder, you can see all the activities you are authorized to work
on. When you activate an activity or when the program activity in FlowMark
Buildtime has been defined to start automatically, the application program
defined for this activity will run. Figure 58 on page 166 shows an example of a
Work List folder with two running activities.
Figure 58. Work List Folder
In FlowMark Buildtime, you may have defined prototype application programs in
your workflow model to get an initial feel of how your workflow model will
behave. These are the programs you will work with when you execute activities
in the Work List folder.
When you are satisfied with the behavior of your workflow model in FlowMark
Runtime, you can simply substitute your prototype applications with more
sophisticated applications. In FlowMark Buildtime, you may have to redefine the
programs in the Program folder, then translate the workflow model again in the
Buildtime 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 to
any 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 shown
with the finished status in the Runtime Processes folder.
See FlowMark V2.1 Managing Your Workflow for details on the functions of
FlowMark Runtime.
10.3.1 Audit Trail
FlowMark Runtime produces an audit trail when a process model is executed. It
keeps a full record of the activities performed and the performance of the
processes. This can be used to track results, and to help to find and eliminate
bottlenecks 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 instances
and 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 if
the day has changed.
10.3.2 Process Monitor
FlowMark Runtime includes a process monitor that shows you the status of a
running process instance as a diagram. You select the process you want to
monitor 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. It
shows all the activities in your process, the flow of control between the activities,
and which paths have been navigated through the particular instance of your
process.
10.4 External Format
Any of the definitions that you store in a FlowMark database can be described in
an ASCII text file in an external format called FlowMark definition language
(FDL). The FlowMark workflow manager provides two utility programs to help
you use process, program, data structure, block, and staff definitions in FDL
format.
The export utility. The export utility enables you to export definitions from a
FlowMark 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 FlowMark
workflow 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 your
workflow model
The import utility. The import utility enables you to import definitions from
an FDL text file into a FlowMark database to define part or all of your
workflow model. Using the import utility provided with the FlowMark
workflow manager, you can transfer workflow definitions from FDL files into
your database. You can import workflow information into a FlowMark
database to:
• Restore workflow information stored in an FDL source file to your
FlowMark database
• Import workflow information defined externally to the FlowMark workflow
manager using FDL
Chapter 10. F l o w M a r k 167
• Merge workflow information from two different databases to create a new
database.
You can also use these utilities to create documents containing information
about 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 from
definitions in your database and then reimport the file. In some cases, this
can be a quicker way of creating and changing workflow models than using
the graphical interface.
• Write programs that produce FDL definitions you can use in your workflow
models.
10.4.1 Importing BMT FlowMark Definition Language
In 8.3, “Generating Workflow Scripts” on page 109 we discussed BMT generation
of FDL. Our interest in this section is to import the FDL that was generated by
BMT.
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 components
in BMT, you define the FlowMark components that will be generated in the FDL.
Importing FDL to FlowMark is straightforward. The procedure is outlined in the
discussion of invoking the import utility from the Buildtime folder in FlowMark
V2.1 Modeling Workflow. Since BMT has already checked the FDL script before
generating it, you should not experience any major problems importing this to
FlowMark. However, you should check all the object names in the FDL and
make sure they conform with the syntax of names that FlowMark imposes. The
syntax of names can be found in FlowMark V2.1 Modeling Workflow.
When importing FDL, FlowMark first scans the FDL to see that the definitions you
are going to import in the database do not conflict with definitions already
existing in the database. FlowMark provides you several options when this
happens:
• 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 be
imported 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 are
important in your current FlowMark database, and what definitions you are going
to import from your FDL.
If you generate the Universal Trust Company mortgage application PLOVC in
BMT, you will get the entire Mortgage PLOVC. Edit the FDL to include only the
activities from AC3 through AC13, and import this FDL to FlowMark. If you view
the process diagram, you will see a workflow model that looks like Figure 60 on
page 170.
Chapter 10. F l o w M a r k 169
Figure 60. FlowMark Diagram of the Mortgage Application Imported From BMT
Notice that FlowMark lays out the program activities vertically. However, the
program activities, the control connectors, and the data connectors are exactly
the same as those you created earlier in Figure 50 on page 158.
The amount of staff and program definitions the imported workflow model will
have in FlowMark will depend on how much information you defined in BMT. It
is always good for you to check these folders to ensure that these definitions are
complete.
However, BMT does not pass data definitions because the data structure
definitions of FlowMark are far more sophisticated than that of BMT. Because
the 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 the
workflow models that you import from BMT.
170 Beyond BPR
10.5 From LOVCs to FlowMark Implementation
In a reengineering project, after the LOV As Is charts have been established and
the To Be models have been drawn in BMT, FlowMark can be used in verifying
the To Be models. Start from To Be PLOVCs and JLOVCs. Using FlowMark′ s
strong affiliation with BMT, the task of migrating from these BMT charts to
FlowMark′s Buildtime process diagrams becomes very fast and easy.
You can test each alternative model through the animation facility of FlowMark
Buildtime if you want to assess these immediately. Or you can develop simple,
easy to develop yet functionally rich application prototypes (in REXX for
example) and execute these in FlowMark Runtime to delve into more substantial
testing of your alternative models. Either way, FlowMark helps you to assess
immediately your alternative To Be models, resulting in a shorter reengineering
cycle.
Even though you are not going to implement workflow, FlowMark can help you
visualize the sequence of activities of your entire LOB process. You can
simulate all your automated and manual processes, and test how they will
behave given different inputs. You can even test your application programs in
different operating systems to find out which operating system works best for
you. FlowMark therefore provides you the flexibility to change the environment
and conditions that your applications will run in, allowing you to find the most
effective way to implement your applications.
Once you have selected a To Be model to implement, you have to decide if you
will implement your LOB using workflow technology. FlowMark provides benefits
in the following areas:
• Application integration
• Flow independence
• Parallel development of programs.
Before you implement your applications in FlowMark Runtime, you should define
in your workflow model your production applications. Once that is done, you can
immediately implement your workflow model in production.
FlowMark therefore allows you to take off quickly from your business model
designs. It extracts these models from the BMT FDLs and converts them into
running models for your evaluation. When you have selected a model, FlowMark
translates this model to an executable form. By simply associating the selected
model to running applications, you can implement your process model in
production right away. FlowMark shortens your reengineering cycle, allowing
you to provide improved customer service with a well-studied solution at the
earliest possible time.
Chapter 10. F l o w M a r k 171
Summary
Business process reengineering is the prescription of how the company
performs a particular LOB in an optimal manner. FlowMark allow a company
to provide the right piece of work at the right time to the right person
supported by the right application. Furthermore, the auditing features of
FlowMark allow the monitoring of the execution of each process instance and
the checking of the appropriateness of the overall performance of a business
process according to the company′s goals. This can result in either constant
improvement of a process or reinitiating business process reengineering of
particular processes.
172 Beyond BPR
Part 4. Conclusions
Copyright IBM Corp. 1995 173
174 Beyond BPR
Chapter 11. Closing Thoughts
There is strong evidence the modern organization, which traces its origin to the
early days of the twentieth century in North America and spread to Europe and
Japan after World War II, is undergoing a dramatic transformation.
This style of organization, which had its origins in the work of Adam Smith who
first described the idea of division of labor as an organizing principle, was later
refined by Frederick Taylor, Henry Ford, and Alfred Sloan. Frederick Taylor
applied division of labor to the British factory early in the twentieth century and
Henry Ford adapted it to the assembly line. Sloan′s contribution came in the
1920′s when, as the head of General Motors, he brought the division of labor to
management as a means of controlling the complex and rapidly expanding
General Motors empire.
In these types of organizations, management′s role was to ensure the workers′
tasks were well defined, measured, and controlled. Managers regarded their
subordinates as little more than a factor of production and tried to make them
behave in the same manner as the machines they supported. The managers
designed systems, procedures, and policies that would ensure all employees
conformed to the company way. The goal was to make the middle managers′
and workers′ activities more predictable and thus more controllable. Change
was discouraged because it made machinery obsolete, forced costly
changeovers, and reduced managerial control.
This organization style, which still prevails in many of our corporate and
government organizations, was designed to manage growth in the stable
environment characteristic of the post-World War II era. However, this era is
drawing to a close and organizations designed to ensure control and conformity
face a difficult transition if they are to deliver the creativity and initiative that the
new, global economy demands. But what is driving this change, and why now?
11.1 The Rise of the Customer
For most of this century, the supplier held the balance of power in the
customer-supplier relationship. Now, as the economy globalizes, power is
shifting to the customer. It is no longer sufficient for an organization to deliver
an innovative product, or a low-cost product, or a high-quality product; today′ s
consumers have grown accustomed to receiving all three in the products they
buy.
This evokes a second major change. As customers become increasingly
selective about their purchases, competition among those supplying these
customers intensifies. Any product or process advantages a supplier achieves
over its competitors typically proves fleeting and is quickly nullified by a
competitive response.
Finally, this change in the customer, and the response from the organizations
that serve them, has produced a third major characteristic of the new economy.
That is, lasting competitive advantage can only be achieved by organizations
that can cope with continuous change. If satisfying a customer′s needs is the
primary organizing principle and there are a number of capable suppliers, to
succeed, an organization must structure itself to deliver ever-increasing value to
Copyright IBM Corp. 1995 175
its chosen customers. As many commentators have pointed out, successful
organizations are those that operate in such close association with their
customers and marketplace that new customer needs and desires are sensed
almost before the customer articulates them. These organizations then use a
highly developed process capability to translate these vaguely articulated needs
into new products or services.
While we developed our scenario from the perspective of a commercial
organization competing in a marketplace, the same pressures face government
agencies today. As the electorate becomes more discriminating and has its
expectations of quality and choice raised by the private sector, it expects higher
quality and more responsive government service. When combined with the calls
for government to control and reduce their deficits, there is growing pressure on
government to streamline its service delivery.
These pressures are forcing many organizations to rethink their strategy and
leading many to conclude they must reengineer and transform their
organizations to remain competitive in the new economy. This decision to
reengineer 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 an
organization, if radical transformation involving major organizational processes
is undertaken, it must be initiated, driven, and actively supported by senior
management. Once senior management sets the new strategy, the focus of the
transformation effort shifts to the development, or reengineering, of new
business processes that execute the new strategic direction.
11.2 Understanding Business Processes
As we discussed in this document, conducting business is fundamentally the
conveying and managing of commitments between an organization and its
customers. If we assume a customer is satisfied when the product or service
delivered matches what was committed, it follows that managing the contents of
the customer-supplier communications becomes a significant focus area for
understanding and reengineering business processes.
These moments of truth are the communication between customer and supplier
that begin with an opening phase, during which the customer identifies their
requirements, and continue with a negotiation phase where the customer and
supplier agree on the details of the supplier′s work product, the timing of its
delivery, payment, and any other conditions. This negotiation phase can take
place in a single conversation or over an extended period, but it is essential it
occur because it establishes the conditions of satisfaction that, if fulfilled, result
in customer satisfaction. It is also important because it provides the basis, after
the performance phase, for an assessment phase in which the customer accepts
or rejects the work product and valuable information about the success or failure
of the process is collected.
While the most obvious customer-supplier communication takes place between
an 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 the
organization to fulfill the commitments made to the paying customer. These
internal activities exhibit the same four phases of customer-supplier
communication—opening, negotiation, performance, and assessment—as the
customer-supplier exchange with the paying customer. A complex product or
service can involve linking a number of these customer-supplier communications
in order to fulfill the commitments made to the external customer.
A final characteristic of the customer-supplier communications approach that
makes it valuable for understanding business processes is that a complete
customer-supplier communication can represent all possible outcomes of a
transaction. Many traditional process definition techniques decide the outcomes
of the process during the initial definition of the process, making it difficult for
the process to respond to unforeseen or special circumstances and leading to
the classic response of a bureaucracy: “We don′t have a procedure to handle
your case.” The negotiation phase provides the flexibility to determine
conditions of satisfaction on a case-by-case basis, empowering employees to
respond effectively in customer moments of truth and providing an
information-gathering opportunity valuable for future process improvement.
These three deceptively simple concepts are the key building blocks for an
understanding 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-supplier
communication can be linked with other customer-supplier pairs to the depth
necessary to complete even complex activities.
Completeness of customer-supplier communications. All possible outcomes
of the communication can be identified and documented.
11.3 From Theory to Practice
Because the building block of a business process is an individual
customer-supplier relationship and a complete business process consists of a
linked series of these relationships, a business process can be documented by
defining the details of its individual customer-supplier relationships. LOVEM-E
provides this support through a business process engineering method. The
method is based on a graphical process description language that can be used
by business professionals and analysts to document and design an
organization′s processes.
Using the LOVEM-E symbols and diagrams, the customer-supplier relationship is
modeled as a set of adjacent bands on a LOVEM-E diagram. The model can be
expanded to the depth necessary to represent the customer-supplier
relationships with a special band reserved for the customer-supplier relationship
involving the external, paying customer. This relationship occurs through what
is known as the line of visibility, a LOVEM-E device which focuses attention on
the importance of the customer view of the business process.
Through its graphical representations, known collectively as line of visibility
charts (LOVC), LOVEM-E can be used to show the relationship between an
organization 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 specific
emphasis 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 is
required by the customer contact to ensure customer satisfaction.
Process cycle time and critical measurement points allow the capture and
display of critical process measurements on the LOVCs where they can be
compared with target measurements that are internally developed or
represent benchmarking data of key competitors.
Process path costing for a business process can be generated from data
captured in LOVCs and used to compare the costs of one business
process design with alternative designs.
Job skill requirements are established by documenting the skill required to
perform a job function in a process design. By defining skill requirements
through the JLOVC, business process designers can identify areas where
employees require more training or job designs need to be restructured to
improve workload balance.
Manual/automation interface where the manual aspects of the business
processes interface with automated systems.
11.3.1 The Boundary Between Business Process and Application System
While LOVEM-E is not a systems development methodology, its outputs can
provide a context for the development of application systems that support
reengineered business processes. Through the manual/automation line it
highlights clearly the interface between the manual activities of the process and
the application systems that support it. Using LOVEM-E can provide both
business people and systems developers with valuable insight into the business
requirements that new systems must support. LOVEM-E blueprints can be used
to:
• 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 enable
reuse and reconfiguration.
11.3.2 Business Processes and the Software Design Process
Before describing the relationship of business process models and workflow
management, it is worth digressing to position business process models
alongside the data and process models that are typically used to development
application systems.
Earlier in the document we used the ISA framework to position business process
models with traditional data and process models. The ISA framework suggests
an 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 world
phenomena to their representation in computers and application systems. For
example, ISA suggests there are three major models useful for describing an
information system:
• Business model
• System model
• Technology model
Each of these models, in turn, can be viewed from six different perspectives or
views:
• Data
• Function
• Network
• People
• Time
• Motivation
Combining the three models with the six views produces the framework shown
in Figure 61.
Figure 61. Information Systems Architecture
The data and process models that are traditionally used to design and build
application systems map into the ISA framework in the fashion shown in
Figure 62 on page 180.
Chapter 11. Closing Thoughts 179
Figure 62. Data and Process Models and Information Systems Architecture
In this document we have suggested that business process models, while not yet
as formalized as data and process models, are a valuable addition to application
systems models because they provide additional insight into application system
requirements 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, and
motivation perspectives of an information system would be valuable in producing
application systems that more closely model the real world. The ISA framework
makes clear that traditional process and data models, by only dealing with the
data and function views from the technology and system model perspective,
cannot capture all the details of something as complex as a modern business
process.
While it is early in the evolution of business process models, and no
diagramming standards exist, we expect this will be an area of increasing
activity and, over time, we expect to see formal business process diagramming
standards emerge that should permit tighter integration between business
process and data and process models.
11.3.3 From Models to Action
Workflow management is an exciting technology that is complementary to the
business process modeling process. Some of the more advanced business
process reengineering methods, such as LOVEM-E, provide computer-based
business tools that enhance the documentation process and enforce consistency
in the design of the business process. Enforcing consistency can produce a
model that is sufficiently detailed to support migration of the business process
model directly to workflow management software. The workflow manager can
then execute the model and orchestrate the resources necessary to complete
the process, such as application programs, data, and people.
A workflow management application maintains the process flow and dispersal of
work separately from the software that implements the business rules and data
access. Because the process model is maintained and executed by the workflow
manager, an application can be implemented in a modular fashion in which
different components of the application are spread across different machines in
a heterogeneous environment. The workflow manager uses the definitions in its
workflow to dynamically call applications at run time, providing an application
developer and system administrator with great flexibility in locating and
changing application components.
Workflow application development can also be highly productive. Using
graphical construction and test techniques, the process model can be developed
and tested quickly, which simplifies the development of application components
that enforce business rules and manage persistent data. Because these
components typically consist of small, distinct pieces of software with
well-defined interfaces, they lend themselves to rapid reconfiguration and easy
maintenance.
Once installed, a workflow application can use process metrics established
during the reengineering phase to record process performance information. This
information can be further analyzed by process designers and yield valuable
insight into further process improvement opportunities.
11.3.4 Business Processes and Application Development
Although a detailed discussion of the transition from business process models to
application system design models is beyond the scope of this document, we
want to share a few general observations on the role of business process
models in the application development process.
Chapter 11. Closing Thoughts 181
Business processes provide a context for application systems. Because
business process support is the primary justification for investment in
information technology in most enterprises, formally recognizing the role of
business processes in the application development process is a valuable
extension to traditional information systems modeling approaches.
Documentation is aimed at business users. Because business professionals
are the primary audience for business process analysis and design, the
documentation is oriented towards a business, rather than systems,
professional. In spite of this original orientation we believe business process
models can offer valuable insight into system requirements for systems
designers.
Function modeling. Business process modeling tools do not provide detailed
function models. It can be valuable to extend a business process
reengineering project to include function modeling at the level of the
business professional to provide a more complete set of models for systems
design.
The business process to workflow link. With the advent of linkages between
business process modeling and workflow management tools there are new
opportunities to tightly integrate business processes with application
systems.
Business process models are implementation independent. There is no
implementation decision implicit in business process models; they produce
outputs that can be useful in data design, procedural program design, and
object-oriented design.
11.3.5 The Goal: Dynamic Business Processes
We have emphasized throughout this document that organizations are entering a
period of discontinuous change that will challenge their ability to respond. The
ability to both reengineer and continuously improve business processes will be
critical to maintaining competitiveness in the new business environment.
With a strong process management capability, an organization can use
reengineered processes not only to implement today′s strategy but also to
compete with a weapon that shapes future strategy. A number of leading
companies are already competing using a superior process capability as a basis
for the development and delivery of new products. As Figure 64 on page 183
suggests, there is evidence a strong process capability is a necessary precursor
for the mass customization organization whose process capability is so
advanced it can create new products that are tailored to individual customers.
182 Beyond BPR
Figure 64. New Dimensions of Competition
This new competitive strategy, in which an organization′s strength is rooted in its
process management skill, will become characteristic of successful
organizations in the years to come. We hope the tools and techniques outlined
in this document can serve as a starting point for transforming your organization
into one positioned to prosper in the new, global economy.
Chapter 11. Closing Thoughts 183
184 Beyond BPR
Appendix A. Customer Relationship Management Processes,
Operational Roles, and Responsibilities
This appendix describes the processes, operational roles, and responsibilities
that make up the Customer Relationship Management (CRM) process.
A.1 Processes
The CRM process consists of the following subprocesses:
Market Management, the set of activities that enables a business entity to
make informed and sound judgements regarding the market segments it
chooses to pursue, the solutions it needs to deliver to customers within
those segments, the resources it needs to allocate, and the return on
investment it should expect.
Relationship Management, the set of activities that IBM and business partner
personnel use to understand our customers, share that understanding with
those who need it, identify opportunities based on customer understanding,
respond to customer requests, and manage all of our contacts with
customers so that expectations and commitments are met.
Opportunity Management, the set of activities that evaluates the relative
attractiveness of opportunities by qualifying, comparing, ranking and
ultimately selecting the ones to pursue. Through a link to skills management
the 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 review
and understand an opportunity, define a solution, create a proposal, build,
test and deliver the solution as well as generate a bill and administer the
contract.
Customer Satisfaction Management, which includes building a strategy for
meeting customer expectations and increasing customer satisfaction with
IBM, understanding the root cause of dissatisfaction, resolving customer
issues, and measuring our success by collecting customer feedback.
Skills Management, which ensures that market-valued skills are available by
building the skills to support the market segment plans. It provides an
inventory of those skills in order to deliver the right skill, at the right cost, to
the right place, at the right time.
Offering Information Management, which collects the information about all
hardware, software, services, and solutions developed throughout the
extended IBM enterprise, and distributes it to all customers, business
partners and IBMers who request information about IBM′s offerings.
Information Management, which builds an information warehouse through
understanding information requirements, identifying sources of information,
sharing the information, and improving the process for acquiring the
information.
Copyright IBM Corp. 1995 185
Supplier Management, the process that identifies, selects, and builds
partnerships with suppliers that support and enhance our ability to satisfy
our customers.
Business Partner Management, the process that identifies, selects, and builds
strong working relationships with business partners, who support and
enhance our ability to satisfy our customers.
A.2 Operational Roles and Responsibilities
The CRM process includes the following roles and responsibilities:
Opportunity Noticer, who can be anyone in IBM. The objective is not only to
make known all opportunities found during the course of business, but also
to allow anybody having information on any lead to ensure it is registered.
However, for a detected opportunity to be registered, another role is
required, 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 customer
relationship throughout the life of the opportunity. This includes
responsibility for customer satisfaction, and for IBM quality and profit. The
opportunity owner determines if additional assistance is needed to evaluate
the opportunity and can request it from a qualify helper, located through the
resource coordinator.
In qualifying the opportunity, the opportunity owner must answer these
questions:
• 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 the
opportunity?
• 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 specific
opportunity. This is an optional role. The qualify helper provides subject
matter expertise needed to determine the viability of the opportunity.
Opportunity Business Manager, who evaluates the entire portfolio of
opportunities that can exist within the business unit, unlike the opportunity
owner, who views only one opportunity at a time. The opportunity business
manager is responsible for ranking opportunities according to how they can
achieve 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 segment
business plan
• The strategic value of the opportunity considering worldwide unit
interests
• 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 after
the opportunity business manager has evaluated, ranked, and determined
resource availability for the entire portfolio of potential opportunities. The
opportunity business manager then notifies the opportunity owner of the
decision. The opportunity owner then presents the decision to the customer.
Proposal Team Leader, who defines exactly what the offering to the customer
will be. The proposal team leader builds the proposal plan and owns its
contents. As owner of the proposal content, the team leader establishes
plans 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 the
solution′s:
• Components
Hardware
Software
Services
Financing
Maintenance
• Terms and conditions
• Milestones
• Financing.
The responsibilities of the proposal team leader can be fulfilled by the
opportunity owner if the proposed solution is simple.
Proposal Solution Architecture Team, which develops the solution
architecture and ensures its technical feasibility and integrity. The team is
responsible 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 the
customer. 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 Responsibilities 187
The solution team can consist of one person or many, depending on the
expertise needed during the development of the proposed solution.
Quality Assurer, who ensures both the customer′s and IBM′s business
requirements are met and is responsible for improving the quality of the
solution′s implementation.
The quality assurer looks at the delivery plan for the solution, and the
solution itself, and the level of risk posed by the solution and asks these
questions:
• 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 first
activity for the delivery team is developing the project management plan for
the solution. This plan is reviewed with quality assurance to ensure we meet
the customer′s conditions of satisfaction including certain milestones.
The delivery team is directly responsible for meeting three major milestones
for 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 is
responsible 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 skill
human resource, identifying, selecting, and assigning people to business
opportunities.
Feedback Collector, who collects data from customers on their relationships
with IBM, on our products and services, and on our customer encounters.
This data can be collected through telephone, mailings, face to face, or
electronically. The feedback collector captures and categorizes answers and
issues requests and comments. The feedback collector also identifies
changes in the customer profiles and makes appropriate updates.
Resolution Owner, an individual who has been assigned a customer issue to
be resolved within a predetermined period. The resolution owner is
responsible for managing the customer′s satisfaction, perceptions,
expectations, and reactions. The resolution owner is expected to develop an
action plan that meets the customer′s expectations and to track that action
plan.
188 Beyond BPR
Glossary
activity. A manual process component, usually customer satisfaction. The goal of any business.
associated with a job. It receives information, acts Customer satisfaction occurs when a customer
upon it, and sends it to a downstream activity, a receives as much as or more than expected from a
system, a customer, or other external or internal product, service, or both.
interface.
data bus. On an ALOVC or an LLOVC, a logical set of
architecture line of visibility chart (ALOVC). The data, starting at the beginning of a process path and
graphical representation of the essential customer continuing along the path, to reflect the most current
and enterprise processes and key data needs and data at any point in a relationship with a customer.
their main characteristics arranged in a sequence.
data dependency. Data that a process requires to
As Is. The depiction of the current business proceed. An upstream data dependency is data
processes or environment. required from the preceding process. A downstream
data dependency is data required by the next process.
band. The horizontal section on an LOVC that
contains the processes or activities of a major logical data flow. A packet of data in motion. It can consist
process or function, like marketing or order, or a of data groups, data entities, and data elements. It is
physical organization, like a department or a job. mainly used as a hierarchical process decomposition
technique, representing the processes a business
bus. A term borrowed from electrical engineering (or performs and the data that flows between them.
computer design) that signifies a continuum with
concrete contact (entry and exit) points. In this electronic data interchange (EDI). A
manual, it represents a continuum of repetitive and computer-to-computer connection between two
unpredictable processes, a set of sequential data companies. The transaction flow for EDI transactions
stores, or a continuum for capturing critical process is regulated through international protocol.
quality measurement points.
enterprise. A company or business, usually
business process. See process comprised of several lines of business.
business process reengineering (BPR). A disciplined enterprise architecture. A business process
approach to radically changing business processes. architecture at the enterprise level as expressed
through an ALOVC. It is at the logical, unconstrained
client/server. An information systems structure that level and shows the essential process and data needs
splits (distributes) the applications, data, or services in sequential form.
between two or more systems.
entity. A thing or object of importance to a business
constrained. Pertaining to, or characteristic of, the about which the business wants to keep information.
PLOVC and JLOVC techniques, or representative of
the factors that define h o w a process or job is entity-relationship (E-R) diagram. A data modeling
performed (for example, time, organization, and technique that graphically depicts data entities and
technology are constraining factors). the relationships that exist between them.
critical measurement point (CMP). Any point on the first touch, only touch. A principle of conducting
process path or within a job that is of critical business with a customer. The design point for a
importance, and where a measurement should be customer service oriented business, that provides for
taken. Measurements can be in units of time or satisfying the customer at the first contact point with
quantity. the business.
critical success factor (CSF). A qualitative or hand-off. The passing of a product, information, or
quantitative measure that defines the quality or other materials from one department or workstation
performance of a business, a process, or a process to another.
path.
hierarchical structure diagram (HSD). A simple,
customer. A person or business that acquires graphical decomposition showing the hierarchical
products or services from a business. structure of a process and its subprocesses, down to
the lowest level. An organization chart.
customer process. The actions or processes
performed by customers. icon. A picture that represents the actual image or
figure.
Copyright IBM Corp. 1995 189
information. Facts or objects that have meaning to logical transformation lists (LTLs). A technique for
human beings, as opposed to data, which requires transforming logical processes into physical
context and interpretation in order to become implementation scenarios.
information.
manual-automation interface. The interface between
information flow diagram. A graphical representation a manual activity and an automated system.
of the physical characteristics of a static process
model. It is mainly used as a hierarchical measurement. The extent, quality, or size of an
decomposition technique for manual activities and object.
systems functions.
methodology. A collection of related techniques and
information systems architecture (ISA). A logical formalisms based on a common philosophy to solve a
construct for defining and controlling the interfaces series of major tasks.
and the integration of all the components of an
information system. model. Graphical representations of observations
and predictions from different perspectives of how a
internal interface. An interface between two internal design could or should look; usually at various levels
business functions, departments, or jobs where a of abstraction and detail.
dependency exists or a transfer takes place.
modeling. Part of the design process used to create
job. The physical implementation of business alternatives or what if scenarios before committing to
processes, as expressed through manual activities the final design.
and interfaces with customers, systems, and internal
or external organizations. physical line of visibility chart (PLOVC). A business
process modeling technique that shows the
job line of visibility chart (JLOVC). A business effectiveness and efficiency of the process path that
process modeling technique that shows the you are studying. Using this technique, you focus on
effectiveness and efficiency of one particular job that h o w the process path is or will be implemented.
you are studying. You focus on h o w the process path
is or will be implemented, and who is or will be process. A business function or operation that
executing the manual activities. It also shows the achieves business results for a customer or client,
relationship of each activity to customer processes, with input from suppliers. A process transforms the
automated systems, and internal or external nature, status, or composition of an input to produce
organizations. an output according to business rules and policies.
line of business (LOB). A family of either, or both, process path. A sequence of processes, activities, or
products and services, having common jobs that complete a cycle and start and end with a
characteristics. customer service encounter.
line of visibility (LOV). On an LOVC, a line between relationship. A descriptive association between two
your customer and internal processes where all points data entities in a data model. Expresses the business
of contact (service encounters) between your rules that govern the entities.
customer and your business are shown.
service encounter. Any point of contact with your
line of visibility chart (LOVC). The graphical customer.
representation of all aspects of your business
processes that are required to provide your customer time line. A notation on the PLOVC and the JLOVC
with a specific product or service, showing all points that shows the time that elapses between individual
of contact with the customer. activities or for a whole process path or job. Time
lines can show both actual and target measurements.
logical line of visibility chart (LLOVC). A business
process modeling technique that shows the To Be. A chart or diagram showing how a business
effectiveness of the process path that you are process is to work in the future.
studying. Using this technique, you focus on what the
process path is doing, not h o w it is or will be unconstrained. Pertaining to, or characteristic of, the
implemented. ALOVC and LLOVC techniques, or representative of
the factors that define what a process is doing, not
logical-to-physical transformation. The translation of h o w it is being done.
a logical process into its physical implementation
components, like manual activities or systems workflow. A sequence of activities (units of work). A
functions. movement of units of work through a process.
190 Beyond BPR
List of Abbreviations
AIR assumption, issue, and HQ REA headquarters real estate
recommendation administrator
ALOVC architecture line of visibility HQ SO headquarters signing officer
chart
HSD hierarchical structure
BLO branch loan officer diagram
BMT Business Modeling Tool IBM International Business
Machines Corporation
BPM business process modeling
IMS Information Management
BPR business process
System
reengineering
ISA information systems
BT business transformation
architecture
CICS Customer Information Control
IT information technology
System
ITSO International Technical
CMP critical measurement point
Support Organization
CRM Customer Relationship
JLOVC job line of visibility chart
Management
LLOVC logical line of visibility chart
CSF critical success factor
LOB line of business
DLL dynamic link library
LOV line of visibility
DSOM Distributed System Object
Model LOVC line of visibility chart
EDI electronic data interchange LOVEM-E Enhanced Line of Visibility
Engineering Methodology
E-R entity-relationship
LTL logical transformation list
FDL FlowMark definition language
NPT nonprogrammable terminal
GSP goals, strategies, and policies
OO object-oriented
GUI graphical user interface
PCX picture exchange files
HLLAPI high-level language
application programming PLOVC physical line of visibility chart
interface
SOM System Object Model
HQ LS headquarters legal services
TIFF Tag Image File Format
HQ MPO headquarters mortgage
3GL Third-generation language
payment office
4GL Fourth-generation language
Copyright IBM Corp. 1995 191
192 Beyond BPR
Index
BMT business models (continued)
A objects (continued)
abstraction 58 HSDs 104
activity 90 logical objects 104
ALOVC organizations 104
components 59 BPR
cross service encounter data bus 62 from theory to practice 177
customer band 61 goal 182
logical roles 62 roadmap 80
LOV 61 success factors 85
process quality management bus 63 understanding 176
service encounter support bus 61 with FlowMark 172
structure 59 Business Modeling Tool
success factors 64 See BMT
application development business process
object-oriented 97 automation of 10
process-based 95 CRM example 22
verification 97 customer-supplier approach 15
workflow-based 96 data component 50, 53
architecture line of visibility chart logical 50, 53, 56, 58
See ALOVC measurement 14, 63, 72, 82, 88, 102
As Is basic types 14
documenting 81 critical measurement points (CMPs) 63, 67
logical view 81 critical success factors (CSFs) 63, 67
physical view 82 goals, strategies, and policies (GSPs) 63, 67
maturity rating 55, 56, 64, 72, 78
model 84, 91
B physical 50, 53, 56, 58
BMT
process definition approach 14
basic activities 102
business process modeling
analyzing, improving, and monitoring the
methodologies 36, 49
process 103
criteria for choosing 79
gathering information 102
new process 21
modeling business processes 102
radical BPR 78
complementary modeling techniques 111
redesign process 22, 79
HSD 111
techniques 27
LTL 113
HSD 111
components
LTL 113
corresponding to FlowMark components 156
tools 22, 36, 49, 88, 94, 96, 102
generating workflow scripts 109
ISA classification 36
FDL 110
business process reengineering
using 103
See BPR
export facility 107
business transformation 51
LOVCs 108
BMT business models
charting do′s and don′ts 107 C
Editor 105 change 5, 88, 119, 175, 182
band area 106 common specification language 50, 51
drawing area 106 constraints 59, 82, 83
menu bar 105 CRM
status area 106 approach 23
symbol palette 105 customer requirements 24
tool bar 105 operational roles 24
objects 104 processes 24
assignable objects 104 responsibilities 24
charts 104
Copyright IBM Corp. 1995 193
CRM (continued) data entities (continued)
operational roles and responsibilities 186 promise 62
delivery team 188 division of labor 175
feedback collector 188 DSOM 98
opportunity business manager 186
opportunity identifier 186
opportunity noticer 186 E
opportunity owner 186 EDI 59
project team leader 188 electronic data interchange
proposal solution architecture team 187 See EDI
proposal team leader 187 Enhanced Line of Visibility Engineering Methodology
qualify helper 186 See LOVEM-E
quality assurer 188
resolution owner 188
resource coordinator 188
F
FDL 109
o v e r v i e w 23
first touch, only touch 62, 64
processes 185
FlowMark
business partner management 186
benefits
customer satisfaction management 185
application integration 150
information management 185
flow independence 150
market management 185
parallel development of programs 150
offering information management 185
Buildtime 150, 154
opportunity management 185
animation 164
relationship management 185
creating a model 157
service and support 185
creating data structures 159
skills management 185
creating program registrations 159
solution design and delivery 185
defining program activities 162
supplier management 186
defining staff 161
sample transaction scenarios 24
modeling with 155
customer request for a customized solution 24
preparing application programs 165
customer
components
rise of 175
corresponding to LOVEM-E/BMT
satisfaction 13, 14, 50, 52, 53, 55, 71, 77, 81, 82,
components 156
84, 102, 176
external format 167
service encounter 50, 52, 53, 54, 61, 64, 65, 69,
export utility 167
75, 81, 83, 178
import utility 167
Customer Relationship Management
importing BMT FDL 168
See CRM
from LOVC to FlowMark Implementation 171
customer-supplier relationship
Runtime 151, 155, 159
accountability 10
audit trail 166
commitments 11, 12
executing 165
estimates 19
process monitor 167
communications 12
FlowMark definition language
completeness 177
See FDL
four phases 13, 176, 177
linked 177
customer-supplier relationship
missing phases 17
H
hierarchical systems diagram
assessment 17
See HSD
negotiation 17
HSD 104
missing roles 17
roles 19, 21
supplier 21 I
information flow, goods flow, and control flow 70
information system architecture
D See ISA
data entities
ISA
contact 62
building analogy 29
offering 62
architect′s drawings 29
194 Beyond BPR
ISA (continued) LOVC (continued)
building analogy (continued) structure (continued)
architect′s plans 29 line of visibility (LOV) 57
bubble charts 29 to FlowMark Implementation 171
contractor′s plans 30 types 58
shop plans 30 ALOVC 59
framework 178 JLOVC 72
data 27, 35 LLOVC 64
function 27, 35 PLOVC 67
motivation 27, 35 LOVEM-E
network 27, 35 benefits 51
people 27, 35 boundary between business process and
rules 35 application system 178
time 27, 35 business activity 54
value 36 business process 54
components 52
customer activity 54
J customer process 54
JLOVC major activities 80
applications 77 assessment phase 80
components 72 planning phase 80
customer band 75 reengineering phase 80
internal/external organizations band 75 success factors 52
LOV 75 use 50
manual/automation interface line 76 LTL 103
time line 76
structure 72
success factors 77 O
job line of visibility chart object-oriented 98
See JLOVC
P
L physical line of visibility chart
line of business See PLOVC
See LOB PLOVC
line of visibility components 67
See LOV customer band 69
line of visibility chart internal/external organizations band 70
See LOVC LOV 69
LLOVC manual/automatic interface line 70
components 65 specific function/department/job band 70
customer band 65 time line 70
data bus 66 structure 67
logical business area band 66 success factors 71
LOV 65 process
structure 65 See business process
success factors 67 process path management
LOB 53 and LOVEM-E 53
logical line of visibility chart data flow 54
See LLOVC
logical transformation list
See LTL S
LOV 57 SOM 98
LOVC supplier
bus 65 accountability 19
FDL 111
structure 56, 65
bus 62
customer band 57
enterprise band 57
Index 195
VisualAge Requirements Tool (continued)
T business operation (continued)
To Be information dependency diagram view 128
architecting 82 operation containing 128
logical vie w 82 operation diagram view 127
physical view 83 rules classified as 128
designing models 84 settings and icon view 127
user role view 128
business rule 132
U classification 137
Universal Trust Company
operation containing 134
headquarters real estate administrator 44
rules used and rules that use 134
enter approved mortgage details 44
settings 134
job description 44
synonyms 137
set up property appraisal 44
transactions initiated, transactions that trigger,
verify mortgage approval 44
and transactions defined 134
mortgage application process 42, 63
business transaction 128
ALOVC example 61
business operation 131
approve mortgage application 42
event notification 130
BMT example 104
p r o m p t 130
commit funds 43
query 130
cycle time details 43
report 130
debit mortgage account 43
user 131
FlowMark example 155
data consolidation 144
FlowMark import example 170
data dependency relationships 142
LLOVC example 65, 66
positioning 124
PLOVC example 69, 70
review requirements statements with users 145
prepare mortgage down payment 43
sample reports 145
provide mortgage data 42
user environment 125
receive mortgage data 42
user requirement statement 124
set up mortgage account 43
uses 119
VisualAge Requirements Tool example 125
communicate user requirements 120
real estate administrator
determine user requirements 119
JLOVC example 72, 76
map business requirements to implementation
elements 122
V provide basis for evolutionary change 121
VisualAge Requirements Tool provide requirements helpful for cost
advantages 118 estimating 121
associations 123 provide requirements useful for planning
defines 123 tests 121
depends 123 provide understandable requirements 120
includes 123 specify required system behavior 119
initiates 123
interrogates 123
modifies 123
W
workflow
triggers 123
and BPR 88
uses 123
application integrator 90
business facts 143
fitting the pieces together 154
business information 140
from models to action 181
facts included 141
model 151
information depended on and information that
activity 152
depends on 141
block 152
operation containing 141
connector 153
rules that modify, rules that interrogate, rules
control flow 153
that define 141
data container 153
settings 141
data structure 153
business objects 122
process 152
business operation 126
process diagram 151
incomplete business objects 128
p r o g r a m 154
196 Beyond BPR
workflow (continued)
model (continued)
staff 154
views 90
combining 93
infrastructure v iew 92
organization v iew 92
process v iew 90
workflow management
See workflow
workflow resource manager
components
administration 93, 95
buildtime 93, 94, 96
runtime 93, 94, 96
Index 197
ITSO Redbook Evaluation
International Technical Support Organization
Business Process Reengineering and Beyond
December 1995
Publication No. SG24-2590-00
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please fill out this
questionnaire 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 REDBOOK@VNET.IBM.COM
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 book ____ Grammar/punctuation/spelling ____
Accuracy of the information ____ Ease of reading and understanding ____
Relevance of the information ____ Ease of finding information ____
Completeness of the information ____ Level of technical detail ____
Value of illustrations ____ Print 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 Organization
Phone No.
IBM
ITSO Redbook Evaluation Cut or Fold
Along Line
SG24-2590-00
Fold and Tape Please do not staple Fold and Tape
NO POSTAGE
NECESSARY
IF MAILED IN THE
UNITED STATES
BUSINESS REPLY MAIL
FIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK
POSTAGE WILL BE PAID BY ADDRESSEE
IBM International Technical Support Organization
Department 471/E2
650 Harry Road
San Jose, CA
USA 95120-6099
Fold and Tape Please do not staple Fold and Tape
Cut or Fold
SG24-2590-00 Along Line
IBM
Printed in U.S.A.
SG24-2590-00