Software Methods for Business Reengineering

Springer New York Berlin Heidelberg Barcelona Budapest Hong Kong London Milan Paris Santa Clara Singapore Tokyo

Alfs Berztiss

Software Methods for Business Reengineering With 29 Illustrations

, Springer

Alfs Berztiss

Department of Computer Science University of Pittsburgh 340 Alumni Hall Pittsburgh, PA 15260 USA

and Institute of DSV Stockholm University Electrum 230 S-16440 Kista Sweden

Library of Congress Cataloging-in-Publication Data Berztiss, AIfs T.

Software methods for business reengineering / Alfs Berztiss. p. cm.

Includes bibliographical references and index. ISBN-13: 978-1-4612-8458-1 e-ISBN-13: 978-1-4612-3980-2 DOl: 10.1007/978-1-4612-3980-2

1. Software engineering. 2. Organizational change-Data processing. I. Title. QA76.758.B47 1995 658.4'063-dc20 95-19289

Printed on acid-free paper.

© 1996 Springer-Verlag New York, Inc. Softcover reprint of the hardcover 1 st edition 1996

All rights reserved. This work may not be translated or copied in whole or in part without the written permission ofthe publisher (Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY 10010, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use of general descriptive names, trade names, trademarks, etc., in this publication, even if the former are not especially identified, is not to be taken as a sign that such names, as understood by the Trade Marks and Merchandise Marks Act, may accordingly be used freely by anyone.

Production managed by Frank Ganz; manufacturing supervised by Jacqui Ashri. Typeset by Best-set Typesetter Ltd., Hong Kong.

98765 4 3 2 1

Preface

Business reengineering is a term that is being heard more and more often, and lately with a negative connotation. Although much already has been written about it, both its nature and its purpose often are misunderstood, and the result is disenchantment. This is particularly noticeable in dis­cussions on the support that software engineering and information tech­nology are to provide for business reengineering. Either too much or too little hope is put on software. This book attempts to remedy the situation by introducing modern principles of process-oriented software develop­ment to management. Technical personnel in information systems depart­ments also will benefit from our survey, in which we aim to make software development more scientific without becoming too formal, and to outline a management view of business reengineering to developers of information systems. Thus, two classes of readers can benefit from this book­managers and information systems personnel. Ed Y ourdon addresses himself to the latter: "Not only do we need to be experts in people­ware ... , systems development methodologies, ... and software re­engineering, but we also need to know business process reengineering ... " [Cw93a].

Business reengineering is part of our transition to a postindustrial era. Some barely feel the revolutionary forces shaping the future; for others, the transition is traumatic. The knowledge revolution that charac­terizes our times is one of three major upheavals in human history­first came the transition to an agricultural age, then to the industrial age, and now to a postindustrial age. We cannot stop the revolution. All we can do is make the transition to a postindustrial society smooth and rapid, so that everybody comes to enjoy the benefits of the transition as early as possible.

Revolutions change the way we function. The knowledge revolution makes us take a fresh look at our organizations, their basic purpose, their structure, their management, their operation, and their interaction with other organizations. Such examination should result in a restructuring that allows an organization to perform its basic functions in a more

vi Preface

effective way. When the effectiveness of an organization is being at least doubled, we can speak of business reengineering.

Management is being bombarded with suggestions of how to improve an organization-total quality management, theory Z, cost centers, out­sourcing, intrapreneurship, a host of Japanese business practices with exotic names. All of these suggestions have· merit, and all should be considered when an organization is being put together. But first the organization has to be taken apart, redefined as a set of processes, and reassembled according to the new definition. For this radical reorgani­zation there is no simple recipe.

Although there is no recipe, there is a preferred approach. This is to base all reengineering activities on sound engineering principles. The discipline of software engineering, which over the past 20 years has evolved into a legitimate branch of engineering, can provide the analytical expertise for defining business processes, and the notations and tools to help transform process descriptions into support software systems. Ideally, software engineers in information systems (IS) departments would assume key roles in reengineering teams in which they would closely cooperate with personnel outside of IS. By being outside traditional departments, such as sales, marketing, and personnel, IS people can view their or­ganization with neutral eyes. More importantly, the IS people know much about the organization, but they must realize that there is much more that they do not know.

Moreover, the changes to be implemented will be much more radical than the changes ISO has had to deal with in the past. In fact, in order to deal with these changes, the processes of information systems have to be reengineered first. And herein lies a problem. Information technology is perceived as not having paid off. Partly this is due to information systems personnel being unprepared to carry out major changes, which partly is due to a reluctance by top management to authorize radical changes based on information technology. Management reluctance is under­standable-the fairly low level of technical preparedness of some American software developers is cause for concern [Y092]. Considerable opposition can therefore be expected to placing the ISO in a central position of the reengineering effort. Some will say that software people do not understand business; others will point to the expensive failure of this or that software project in the past. Actually, reality is not as bad as the perception. Software personnel can give excellent technical support to reengineering, and their effectiveness would be even greater if they were willing to become disciplined software engineers. This book defines some of the things they would have to know or be prepared to learn in order to achieve this.

Much of this book is a selective adaptation of a software requirements course I have given to industry and academic audiences in the Americas, Europe, Asia, and Australia. The course has evolved over 10 years or so,

Preface vii

but from the very start it had processes as the basis of study, where a process may be the handling of a purchase order, cash withdrawal from an ATM, the operation of a furnace, or the development of a software system itself. The decision to concentrate on processes turned out well, particularly when we began to consider requirements analysis in the context of business reengineering. Most importantly, we came to realize that a process can be designed and validated without regard to its ultimate implementation. This means that once the essential nature of a process has been established, the process can be implemented under a traditional organizational structure or a reengineered structure. In other words, the essence of a process is independent of the structure of the organization that supports the process. This realization defines our approach to business reengineering: Information technology, such as computer networks and CASE tools, provide essential support for the processes of an organization, but the technology is secondary to a thorough understanding of each process. Our aim is to show how to reach such understanding.

Part I of the book explores the nature of business reengineering, and Part II is a brief introduction to the principles and practice of software engineering. To some extent, these two parts are independent of each other. Although some effort was made to relate software engineering to business reengineering, we consider it important that the picture of soft­ware engineering presented in Part II be fairly complete, i.e., that it go beyond the role software engineering is to assume in business re­engineering. The essence of a reengineered organization is found in a set of processes that depend on an information base-Parts III through V establish how the processes and their supporting information base are to be defined. There we take a software engineering approach. Although not all of the examples relate specifically to business reengineering, they all deal with techniques that can be directly translated into reengineering practice. In Part VI, we return to the process of reengineering, but now with a software engineering attitude. Some chapters of the book deal with technical matters. This is how it should be. Business reengineering has a technical side, and my aim was to concentrate on the technicalities without becoming too engrossed in them. Readers not directly concerned with the technical side can merely skim through these chapters, but they should not skip them entirely-one of our purposes is to point out the need for greater technical competence. A reading guide contains pointers to literature that will enable readers to follow up on topics they find parti­cularly relevant or interesting.

Alfs Berztiss (alpha@cs.pitt.edu)

Contents

'Preface ............................................... '..... v

I. What is Business Reengineering

1. The Established and the Reengineered ..................... 3 Business reengineering is made necessary by the movement of our society into a postindustrial era. It is a radical transformation of an organization from a rigid structure defined by departments to a flexible structure defined by processes. Ten myths regarding reengineering are explored.

2. Business Reengineering is Not New ........................ 12 Serious beginnings of business reengineering are traced back to around 1973. Particular attention is given to the interpretation of business reengineering as the application of a decision-making paradigm to the design of organizations. Some guidelines for introducing this paradigm into an organization are listed.

3. The Purpose of Reengineering ............................ 17 The way a reengineered organization copes with the complexity and volatility of the postindustrial business world is expressed in the form of seven goals. The goals are discussed in some detail.

4. Steps in the Reengineering Effort .......................... 22 The reengineering of an organization is defined as a 16-step process. Some of the steps are the selection of executive and operational man­agers of reengineering, setting up educational services, specification of processes, a cost-benefit study of implementation plans, and automation of processes.

5. Making the Most of Human Resources ..................... 30 The wise use of human resources, particularly of the intellectual capital they represent, is an important aspect of business reengineering. Also, a reengineering effort should be adapted to the culture of an organization.

x Contents

This is related to teamwork, and two formats for group workshops are contrasted.

6. The Nature of a Process .................................. 37 A business process is defined as an ordered collection of business tasks that is to achieve a specific goal. A distinction is made between business activities that fit this definition and those that do not.

II. What is Software Engineering

7. Engineering Principles in Software Development ............. 45 The next six chapters are primarily addressed to managers to give them an appreciation of the nature of software engineering, but software developers will also benefit from this statement of goals. The aim of engineering is to utilize economically the materials and forces of nature. Software engineers do not deal with natural phenomena, but they still follow the same activities as conventional engineers. Many of these activities are relevant to business reengineering.

8. Classifications of Software A software application system can be considered as made up of an information component, a control component, and data transformers. The systems that support the operation of a reengineered organization follow this pattern, and will be called information-control systems.

59

9. Modularization and Requirements Engineering .............. 65 Software modules are defined, and their history is traced. Each module of a software system is to have a well-defined purpose, and its interaction with other modules is to be minimized. The same objectives hold in the definition of the business processes of a reengineered organization. The definition of modules is an important function of requirements engineering.

10. Software Quality Attributes ............................... 73 Software quality has many facets, including verifiability, robustness, maintainability, reusability, and understandability. One concern of requirements engineering is the ranking of these quality attributes in order of importance for the particular software system under considera-tion, keeping in mind that the most important quality attribute is user acceptance. Special emphasis is given to software performance estimation.

11. The Software Development Process ........................ 83 Disciplined system development has to follow a plan. We discuss how the waterfall model for system development, in which requirements determination is a distinct initial phase, is to be replaced by the spiral model or by specification-based prototyping in which requirements determination is to a large degree integrated with system design. The Software Engineering Institute process maturity levels are introduced.

Contents Xl

12. Software Cost and Risk Estimation Cost and risk estimation is a highly skilled activity that requires much experience. It is a crucial part of requirements analysis in that it deter­mines whether or not a system is to be developed at all.

III. Business Analysis

94

13. Analysis of Business Activities ............................ 103 Most of the processes with which a reengineered organization will be concerned already exist in some form in the organization. The processes are redefined as requirements documents. A more radical approach is to redesign an organization without any regard for what already exists.

14. Individual Interviews ..................................... 111 It is good practice to have some rudimentary requirements statement ready before employees of an enterprise are interviewed. Proper inter-view techniques are crucial to the elicttation of reliable information.

15. Group Sessions .......................................... 115 Group sessions can lead to many improvements of a given set of require­ments. These sessions should be supervised by trained moderators. Two types of sessions are considered, brainstorming and JAD (Joint Application Development).

16. Business Process Prototyping .............................. 122 A specification must express process requirements unambiguously, and a specification language must facilitate demonstration of whether the system defined by a specification will have a particular property or exhibit a particular behavior. A specification language should preferably be executable. It is then a prototyping language. Interaction of business domain specialists with the prototype is likely to suggest changes to process requirements.

IV. The Reengineering Blueprint

17. From Natural Language to Entities and Relationships ........ 129 The processes of an organization are dynamic, but they are supported by an information base that has a static structure. This and the next chapter deal with these two aspects of process definition. Most require­ments are initially expressed in natural language. The requirements analyst must try to make the natural language statements unambiguous and verifiable. From these statements the analyst develops a graphical representation of the information base for the processes, which in our case is an Entity-Relationship diagram.

18. State Transitions and Control Flows ........................ 138 The dynamic aspects of the reengineered enterprise are captured in state transition and data flow diagrams.

Xll Contents

19. Control Flows in Terms of Petri Nets ....................... 143 A process may have to interact with its environment, and the interaction can become very complicated. Also, all opportunities for parallel execution of parts of a process have to be indicated. Petri nets provide a visual representation of these aspects in an unambiguous way.

20. From ER Diagrams to Information Modules ................ 150 Modules should be identified with data types, where each data type consists of a set of entities and a collection of mappings. The description of an editorial office is converted into an ER diagram, and then into a data-type diagram. The latter defines a set of modules.

21. From Flow Diagrams to Process Modules ................... 157 The data types of information modules define the information base of an organization. The addition of behavioral aspects superimposes a set of processes on this static scheme. The example of the editorial office is continued with the drawing of a Petri net that shows how the office processes a submitted paper.

22. Validation of the Blueprint ............................... 163 The final form of the initial requirements document for a business process contains a data type-diagram, state transition diagrams, a process flow diagram, and a list of nonfunctional requirements. This document is examined by a carefully selected inspection team.

V. Information-Control Systems

23. Specification of Business Processes ......................... 171 Desirable properties of a language for the specification of business processes are examined. The most important property is the inde­pendent specification of the structural aspects of the information base, its behavioral aspects, and the actual business processes.

24. The Specification Language SF ............................ 176 The SF (Set-Function) language has been designed for the specification of information-control systems. An SF specification is derived from type, state transition, and data flow or Petri net diagrams. The SF language is shown to have a strong object orientation.

25. An SF Specification: An Editorial Office .................... 185 This specification derives from the diagrams in Chapters 18 and 19. As is usual in the specification of nontrivial systems, the diagrams change somewhat during the specification process.

26. A Case Study: Order Processing ........................... 196 Order processing is a very important business activity. This example illustrates the transition from an existing to a reengineered process.

Contents xiii

VI. Implementation of Reengineering

27. The Reengineering Process ............................... 207 The 16-step reengineering plan in Chapter 4 is reexamined with a software engineering attitude. The five chapters that then follow deal with the most important aspects of the reengineering process.

28. Determination of Priorities The actual reengineering of an organization starts with the definition of the organization in terms of processes, and specification of the processes. The costs, risks, and benefits associated with different processes and their implementation variants determine reengineering priorities. Of particular concern is the process that converts research and development findings into products for the market.

213

29. Legacy Software ......................................... 219 The existing software systems of an organization represent a major investment. Moreover, they are reasonably reliable. This legacy software is to be integrated into the process systems of the reengineered organ­ization, but only if the software does not impose heavy constraints on how the reengineering teams are to proceed.

30. The Communication Infrastructure ......................... 224 Most reengineered organizations depend on local area and wide area networks for communication. An imaginative use of these facilities can raise significantly the effectiveness of an organization.

31. User Interfaces .......................................... 230 Most of the software systems that support business processes interact with human participants in these processes. Although it is difficult to express user-friendliness in quantitative terms, benchmarking allows the quality of a user interface to be measured. Experimental data exist on the effectiveness of different modes of user-system communication.

32. Maintainability and Reusability ............................ 237 Maintenance of a process is corrective, adaptive, perfective, or preven-tive. Maintenance is facilitated if the need for future maintenance is anticipated at the time the process is designed. Software maintenance is sometimes considered as little different from software reuse. A special case of reuse is the adaptation of a product for international markets.

Appendices

A. Basic Mathematical Notations This appendix introduces some basic notations of set theory and logic. Its main purpose is to help in the reading of SF specifications.

249

xiv Contents

B. A Reading Guide ........................................ 255 The reading guide refers mainly to books in which some of the topics raised in the text are discussed in detail. For the most part, the organ­ization of the reading guide follows the order in which these topics are dealt with in the text.

References ................................................. 260

Index ............................................................. 269