Docstoc

Business Process Reengineering and Beyond

Document Sample
Business Process Reengineering and Beyond Powered By Docstoc
					                                               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

				
DOCUMENT INFO
Shared By:
Stats:
views:172
posted:3/14/2011
language:English
pages:224
Description: business processes