Business Process Implementation for IT Professionals by Robert B. Walford ISBN: 0890064806 Artech House © 1999 (599 pages) An all-inclusive roadmap to help you convert business practices into applications to facilitate those same business practices. Table of Contents Business Process Implementation for IT Professionals and Managers Foreword Preface Chapter 1 - Introduction Part I - Automation asset management Chapter 2 - Automation asset system Chapter 3 - Life cycle management Chapter 4 - Repository utilization Chapter 5 - Business rules Chapter 6 - Financial management Chapter 7 - Planning and strategy Part II - Automation assets Chapter 8 - Process modeling Chapter 9 - Scenario modeling Chapter 10 - Role modeling Chapter 11 - Information modeling Chapter 12 - Client/server modeling Chapter 13 - Dialog and action modeling Chapter 14 - Software component modeling Chapter 15 - Workflow modeling Part III - Automation methodology Chapter 16 - Overview of process implementation methodology Chapter 17 - Spirals Chapter 18 - Step 1: Define/refine process map Chapter 19 - Step 2: Identify dialogs Chapter 20 - Step 3: Specify actions Chapter 21 - Step 4: Map actions Chapter 22 - Step 4(a): Provision software components Chapter 23 - Step 5: Design human interface Chapter 24 - Step 6: Determine workflow Chapter 25 - Step 7: Assemble and test Chapter 26 - Step 8: Deploy and operate Chapter 27 - Retrospective Glossary - List of Acronyms Index List of Figures List of Tables Business Process Implementation for IT Professionals and Managers Robert B. Walford Library of Congress Cataloging-in-Publication Data Walford, Robert B. Business process implementation for IT professionals and managers / Robert B. Walford. p. cm. — (Artech House software engineering library) Includes bibliographical references and index. ISBN 0-89006-480-6 (alk. paper) 1. Management information systems. I. Title. II. Series. T58.6.W324 1999 658.4’038—DC21 99-18034 CIP British Library Cataloguing in Publication Data Walford, Robert B. Business process implementation for IT professionals and managers. — (Artech House software engineering library) 1. Management information systems 2. Data transmission systems 3. Business — Communication systems I. Title 658.05’46 ISBN 0-89006-480-6 Cover design by Lynda Fishbourne © 1999 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 0-89006-480-6 Library of Congress Catalog Card Number: 99-18034 10 9 8 7 6 5 4 3 2 1 This book is dedicated to my colleagues Truman Mila and Mark Feblowitz, who breathed life into the PRIME methodology through their innovative application of systems and software engineering. About the Author Robert B. Walford received the B.S. degree in Electrical Engineering from the Illinois Institute of Technology and the M.S. and Ph.D. degrees in Electrical Engineering from the University of Southern California. He has over 30 years of diverse experience in engineering, telecommunications, and information processing, including hardware design, software design, and technical and general management. He has held engineering and management positions with several commercial organizations, including the Hughes Aircraft Company, Bell Laboratories, EMI Medical, Florists’ Transworld Delivery (FTD), GTE Data Services, and GTE Telephone Operations. He also performed as an independent consultant in factory automation for General Motors and was the owner of Tri-Ware Digital, Inc., an original equipment manufacturer (OEM) that developed and marketed a comprehensive minicomputer- based accounting and management system for small businesses. Dr. Walford’s current position is Manager of Advanced Information Management Technology for GTE Telephone Operations. Areas of responsibility include computing infrastructure specification, application architecture, technology planning, and project management. Specific technologies of interest are component architectures, knowledge management, business rules, and decision support. His academic experience includes the teaching of circuit design and mathematics courses as an assistant professor of electrical engineering at the University of Southern California. He was also an adjunct professor in the Computer Science and Engineering Department of the University of South Florida, teaching graduate and undergraduate courses in software engineering and data communications. He also served as an engineering accreditation visitor for the Accreditation Board for Engineering and Technology (ABET) and was responsible for examining and evaluating the computer engineering curriculum in a number of universities as part of their periodic accreditation process. As a participant in the initial international standards efforts for intelligent networks, Dr. Walford originated the four-layer reference model, which is at the core of current intelligent network standards. For that work, he received a Warner Award, the highest recognition that GTE Corporation gives for technical achievement. In addition to Business Process Implementation for IT Professionals and Managers, he is the author of three books on information networks and systems published by Addison- Wesley in 1990: Information Systems and Business Dynamics, Network System Architecture, and Information Networks: A Design and Implementation Methodology. He also has authored and presented numerous talks and articles on management, telecommunications, and software engineering topics. Dr. Walford is a registered professional engineer in Florida, Illinois, and California and a certified public accountant. He is a senior member of the Institute of Electrical and Electronic Engineers and a member of the National Society of Professional Engineers, the Florida Engineering Society, and the American Institute of Certified Public Accountants. Foreword I think this book must have been written by a collusion of half a dozen different Robert Walfords. One Robert Walford is a subject matter expert (SME) in several areas of expertise, especially telecommunications-related domains, his broad knowledge being the result of a long tenure in the industry. As an SME, Bob has been a resource to numerous business process definition and reengineering projects, providing reliable content to their documents, models, and decision-making processes. Another Robert Walford, Bob the methodology practitioner, has been a participant as well as a guide and coach to teams following various prescribed organizational methodologies. The lead author of this book is, undoubtedly, Bob the methodologist, whose experience as a user and a facilitator of several methodologies has been brought to bear on the design of new methodologies, striving for and encapsulating best practices. This Bob has reflected on the reasons, both technical and organizational, for successes and failures of process modeling and implementation projects. He has a compulsion and a passion for imparting clear concepts and their coherent integration, for separating the generic from the idiosyncratic, and for culling the essential from the incidental. Bob the methodologist has worked closely with Dr. Bob, as his colleagues sometimes call him, whose doctorate in computer science equips him to avoid superficiality and ensure firm theoretical foundations. Another author, Professor Bob, teacher of information technology and related subjects at the university, has made the book’s presentation eminently lucid and digestible. The approach taken in the book is heavily influenced by Bob the professional engineer, whose perspective complements those of Dr. Bob and Professor Bob. Engineer Bob is concerned with the principles and techniques that engineers use to build things that work. For example, Bob the professional engineer designed and built a front porch onto his house, which is located in a hurricane-vulnerable area. Not only did he follow current practices, standards, and codes, but he added his own engineering calculations to ensure the structural integrity of the product. I am confident that porch will be left standing after any hurricane, even if the rest of the neighborhood is leveled. Engineer Bob wants the implemented business processes to get the job done, despite the constraints and hazards of the enterprise environment. A systems engineering approach is therefore advocated. A systems engineering approach defines customer needs and required functionality early in the development cycle and follows a structured development process in which technology components are combined to end up with working systems that meet the requirements. A systems engineering approach is eclectic in that it integrates several relevant disciplines and specialty groups into a team effort. Besides expertise embodied in the components, the structured development process must include provisions to handle, from concept to production to operation and ultimately replacement or disposal, cost and schedule; training and support, quality assurance, testing, and performance; and system integration, deployment, and disposal. If asked, Dr. Walford might call himself Bob the technologist. He has been an ardent observer of information technology trends, tracking, assessing, and, when appropriate, championing adoption of new technologies in the corporation. He writes about some of those topics in this book. As you will see, Bob the technologist does not believe in silver bullets, panaceas, or overnight cures. But we can depend on him for insight, prudence, and commonsense guidance. It is hoped that understanding where the author is coming from will help readers know where they are going. But enough about Bob(s)! A concise statement of the theme of the book is the assertion (in Chapter 1) that “management by process itself requires a process.” A process for managing processes, that is, a methodology, has as one of its dimensions a set of coordinated modeling activities and guidelines (presented in Part III). Another dimension of the methodology is a conceptual framework for capturing specifications of information systems (Part II). The products of the methodologists’ labors, primarily the populated models, are viewed as assets having a life cycle, with the life cycle supported by such things as repository technology, financial management, and business rules, among other things (Part I). Preceding the three parts of the book is an introduction that articulates prerequisites, principles, and perspectives. In particular, there is cogent reflection on the significant business and technology factors that motivate management by process, rationale for the utilization of a conceptual modeling approach, and justification for the emphasis on an asset management paradigm. The preceding paragraph, which essentially summarizes the book in reverse, discloses that the book goes well beyond the explication of a single methodology. There is ample discussion of the basic ideas that underlie the methodology—concepts, theories, rationale, and pragmatics—which apply not only to this particular methodology but also provide insights into the subject of process-oriented methodology in general. A number of pertinent topics are woven into various parts of the book and expounded in a lucid and instructive manner. Take business rules, for example, a subject fairly new but highly relevant to business process automation. Business rules are characterized as statements that define or constrain the operation of an enterprise. Business rules are always present where business processes live, and business rules induce some of the key requirements on enterprise systems. However, adequate techniques have yet to be developed for eliciting, acquiring, analyzing, implementing, and monitoring business rules. Some business rule deployment tools have appeared in the marketplace, but they are targeted at a narrow set of business rule types. The author clarifies the business rule concepts, explains the need for a broader definition, and relates business rules to process-driven methodologies. Business rules are characterized as an asset that must be managed from process definition to implementation. Through the use of business rules and business rules technology, the objective is the capability to rapidly deploy or redeploy the corresponding business logic. Another example of a well-chosen infusion of significant material is workflow. The methodology proposes that the implementation of a business process can best be achieved by mapping processes to workflow systems, based on the details of the specified tasks, actions, interfaces, and so on. A workflow system is a platform that performs the work of a business process by providing mechanisms for specifying, scheduling, coordinating, and monitoring the workflow instances that are created in response to business events. Making a workflow system part of the architecture for target implementations reduces the need to reprogram those generic capabilities for every developed system. Although the state of workflow technology, as for business rules, is not yet mature, an activity for determining workflow is included in the methodology as an indication of the trend toward using workflow technology to implement business processes. In contrast, the systems we have inherited as our legacy are not built on workflow platforms; it is proposed here that adopting workflow technologies will reduce some of the problems of creating new systems (our new legacies) and will facilitate integration and evolution. Besides business rules and workflow, it is clear that many more concepts and technologies impinge on process implementation methodology: knowledge management, document management, and integration architectures, just to mention a few. At several points in the book, the author appears poised to cover those topics, but there are limits to what one book can cover. We could not expect more from a single volume. I believe there is a substantial body of professionals, both technical and nontechnical, as well as teachers and students, who should read this book to reap the benefits of the assembled knowledge and views. I see the book as a key resource, inhabiting an environment where process implementation methodology is a defined area of expertise and where a group of appropriately trained individuals is a center of excellence to provide necessary technical and organization skills. Thus, the book contents alone are not enough. There must also be an explicit intention to act and to back the associated activities with the necessary resources. There must be a commitment to the belief that the process implementation methodology is one of the most important business processes in the organization. In fact, I would venture to say that the ability of an enterprise to perform the methodological aspects of its operations will, in the coming years, become more important than a majority of its other business processes. As technology domains mature and technology components (e.g., software applications and services provided over networks) become more specialized and standardized, a primary differentiator between enterprises may be the quality of the process implementation methodology rather than of the business processes specific to the domain. That could be considered a somewhat radical view, namely, that the critical success factor of a telecommunications company, for example, could depend at least as much on process implementation methodology as on telecommunications expertise. To give credence to that contention, we have to ask: Where will the professionals come from to carry out the methodologies? Where will they get the training they need? What knowledge and expertise are needed for success? Some progress is being made by recent advances in university curricula, in courses on systems analysis, requirements engineering, and the like. Other skills such as facilitation and project management also are important and available. Dr. Walford folds such material into this book, demonstrating a predilection for a multidisciplinary approach, which is precisely what is needed. In addition to needing a new generation of professionals to carry out the new order of things, mechanisms for organizational change will be needed. The fact that methodologies are higher-order processes, that is, processes about processes, makes them both powerful and paradoxical. From one perspective, a methodology is carried out by agents who take on an external, apparently dispassionate view of the enterprise, and they build models from an apparently objective viewpoint; the operations they perform are on other business processes. On the other hand, the methodology is just another process (caution is always advised when the word just is used). The process happens to be performed by agents who often are stakeholders internal to the current or future configuration of the enterprise. So a participant in a methodology wears two hats: that of the designer of the new enterprise and the other of a potential occupant of the new organization. Obviously, there are some natural conflicts between self-interest and organizational altruism. The fact that a methodology is a higher-order process is therefore a challenge to overcome. Consider, as well, that the introduction of a new methodology is an implementation of an even higher order business process. That infinite regress is, in principle, troublesome, but in practice we have not reached the point where there are any significant consequences. One of the main reasons for developing a methodology is to bridge the gap between business development and information technology. Historically, the relationship between the two has been ill-defined, not atypical of the nature of relationships between customers and application vendors. Business involves business judgment and decision making, for which the most natural forms of communication have been informal media such as conversations, text, and real-world scenes. Implementors use more formal, rigorous representations as they consider system designs and get closer to procedures that execute on computers. Business is learning to be more rigorous in its process descriptions, and IT is learning to reciprocate by utilizing methods that tolerate some ambiguity and incompleteness (rather than, for example, forcing specifications into molds for the sake of direct implementation). The progression from the more freeform, unstructured languages to the more formal, structured ones is one of the obstacles the methodology is supposed to overcome by gradually transitioning from one to the other. The methodology in this book addresses that issue (often called the requirements gap) to a significant degree. It is a prescription for how the two camps can interact on a constructive basis. In conclusion, it is an admirable task indeed for the many Robert Walfords to have assembled and so plainly presented the material in this book, which is both deep in concept and broad in scope. Sol Greenspan Preface The King is dead; long live the King! That famous cry sums up most aspects of modern business practice. The previously existing competitive environment, scope, internal structures, and automation support needs of an enterprise have disappeared and been replaced by other sets of conditions and requirements. In time, those needs, too, will disappear and be replaced by yet another set and much more quickly than before. The concept of “Internet years” applies to most aspects of modern life. To stay viable, an enterprise must learn to live with the new king and begin to prepare itself for the next one, who inevitably will arrive when least expected. From an information technology (IT) perspective, we recently have converted from a centralized mainframe environment to one with a distributed client/server structure. Even before the latter environment began to stabilize, the rapid emergence of the Internet has created the need for yet another version with its own needs and constraints. This swift succession is likely to continue into the foreseeable future as technology advances and customers demand the services and products enabled by the new capabilities. Adding value in this environment requires that a “stretch view” along with innovative approaches to enterprise automation be used. That will result in some possibly controversial directions, but there is no hope of keeping up with the rapid pace without utilizing paths other than the existing ones. The basic unit of the enterprise, from an automation perspective, is considered to be a process rather than a particular function of the enterprise. This approach is taken not only because a process orientation is being used for much of the current work in organizational dynamics (e.g., process reengineering) but because it is a more natural construct for determining and defining automation functionality that meets the needs of the enterprise. When we consider a process approach, it rapidly becomes evident that the specification of a process is just the beginning. A considerable amount of effort must be applied to the transformation of processes from the business environment in which they are defined to the technical environment in which they must be implemented and deployed. Different process models are needed to make the transformation effective. This book specifically addresses an issue usually missed in the discussion of process engineering and management: the need for eventual implementation and deployment of the business processes. There are many publications concerned with the need for an enterprise to be process oriented and that provide approaches to the specification of so-called optimum processes through some type or business reengineering. However, little consideration has been given to how to actually implement those processes using manual or automated functions and to successfully deploy them in the enterprise. Thus, many enterprise process engineering activities have failed. The central purpose of this book is to fill that void through the specification of a process implementation methodology. The process orientation of the methodology gives rise to its name: process implementation methodology (PRIME). Unfortunately, the mere specification of a series of steps is not enough to provide a workable methodology. If such were the case, many such methodologies probably would be available. An effective methodology must fit into the current and projected enterprise business and technical environments. It also must provide a means to solve the four generic business problems: decrease costs, reduce time to market, increase quality, and provide greater value for the customer. PRIME provides a way to meet all those requirements while staying focused on process implementation. The development of PRIME rests on three supporting concepts: systems engineering, automation assets, and modeling. A systems engineering approach permits the many needed technology and business concepts to be considered as an integrated whole rather than as isolated entities. An automation asset view ensures that the entities utilized in process specification and implementation are correctly managed and their inherent value to the enterprise understood. Extensive modeling is used throughout the presentation to define and structure the discussions and permit a relatively rigorous examination of the principles, concepts, and entities involved. In many current instances, the specification of enterprise automation emphasizes technology and products with only a passing mention of an associated methodology. Technology and products, no matter how well conceived and designed, cannot be effectively employed without methodology. Even when methodologies are utilized, they involve previous methodologies that were developed for centralized computing architectures and that are no longer appropriate. Many current methodologies are based on either data or control specifications and were first defined in the mid-1970s, when the software development and deployment environment was considerably different from what it is now. Although the existing methodologies have been adapted over the years to some extent, their basic approach has not changed, and they still are unable to accommodate the needs of a process orientation efficiently. In addition, these existing methodologies have a number of other disadvantages when they are applied to the emerging environment: For example, they do not take advantage of reuse; they are hard to adapt to a distributed deployment environment (e.g., client/server configurations); they do not adequately consider the human interfaces; they do not involve the stakeholders as an integral part of the development process; they inherently require a long time-to-market cycle for new products; and they produce products that are difficult to maintain. The PRIME methodology addresses all those issues and includes their resolution as an integral part of the methodology activities rather than as an add-on or afterthought. For that reason, PRIME provides the first fundamental advance in automation software specification and development methodologies in several years. The term development as used in connection with the PRIME methodology is intended to cover custom implementation as well as the selection of already existing software such as commercial off-the-shelf (COTS) products, legacy systems, or components specifically designed to be reusable. PRIME can accommodate centralized, client/server, and Internet-based architectures, either alone or in combination. The comprehensive scope of this book provides a significant value independent of the specification of an effective process implementation methodology. It permits consideration of many needed topics in their appropriate context. That also allows a presentation based on principles that are relatively independent of specific technologies and products, thus increasing the effective life of the information in the book. Many of the presentations touch on issues currently being aggressively debated within the industry. The models of the components involved constitute a suitable framework through which the divergent views can be examined and understood. The information in this book is presented in three parts, with an introductory chapter on the current business and technical environments and associated drivers with which an enterprise must deal. Each part constitutes a major aspect of the methodology specification. This organization is necessary to manage adequately the complexity of the information and provide a presentation that will serve the needs of many different types of readers. Chapter 1, the introductory chapter, is concerned with defining the business and technical environments in which the automation software must exist and be utilized. It introduces the major pressures that are forcing the enterprise to change how it conducts business and, as a result, how support software is obtained and utilized. Without a minimal understanding of those topics, it is not possible to follow and understand the reasons for—and the details of—the design and construction of the methodology. The presentation is useful in and of itself as a guide to the confusing set of forces causing the current upheaval in the business environment. However, the main purpose of Chapter 1 is to motivate the remainder of the discussion. Part I is concerned with the concept of automation assets and their management. The concept of automation assets provides the framework for the definition and analysis of the entities needed in the specification of the methodology. It also allows their interactions to be defined and considered in a structured and natural way. The asset management system is modeled using five interacting components: life cycle management, financial management, business rules, repositories, and the automation assets themselves. The common characteristics developed in Part I are applied to all automation assets considered in Part II. Part II is concerned with the modeling of the automation assets needed for the definition of PRIME, consistent with the direction and requirements of asset management. A key presentation is concerned with the reuse of software components. Reuse of the various elements involved in the specification and development of software has been a constant focus since early computers. Until now, that has never been successfully accomplished except for a few isolated and rather specialized instances. An approach to a feasible method of achieving reuse success is presented in this discussion and incorporated as an integral part of the PRIME methodology. Part III contains the design and specification of PRIME using the information developed in Parts I and II. PRIME is based on an adaptation of the spiral approach to design and implementation. In that type of approach, the basic steps of a methodology are reinvoked over and over with an increase in detail and structure after each iteration or spiral. While it is possible to design a methodology with only one spiral that includes all the methodology steps, several problems are associated with that approach: The complexity of its application to a development of significant size is difficult to manage; parallel activities are not possible; and iteration over a subset of activities is not easily defined. For those reasons, PRIME utilizes multiple overlapping spiral types within the overall spiral definition. That allows iteration over all the steps or a subset, as desired. Seven explicit spirals are defined in the methodology. Implicit spirals also can be defined among any set of steps as needed during a specific development. It is important to note that this book is not intended to be a cookbook. Although it does contain a comprehensive and relatively complete discussion of the principles involved in process implementation and could be used as described, it commonly will be used as just a starting point. Every enterprise is different and will need different aspects and details of the material presented. Certain aspects will be emphasized more than others. Any of the definitions, models, and procedures contained in this book can be altered to meet specific requirements. However, the systems engineering and automation asset perspectives must be maintained so the result preserves the necessary consistency and focus. The information presented in this book has been designed to assist software engineering professionals involved in the implementation of processes. There are more than sufficient details and explanations to enable readers to (1) understand the underlying reasons for the design of PRIME and (2) adapt the methodology to their organization without encountering a large number of unexpected problems. The information presented will enable individuals involved in any aspect of business process utilization to understand the consequences of their results and provide for a smooth implementation path. Although there are no study questions at the end of the chapters, this book is also appropriate for classroom use in advanced courses in software engineering or management information systems. A condensed course could be taught in one semester, but exploring the technical requirements in depth probably would take a two- semester sequence. Either way, student assignments would consist of example designs and investigation of possible alternatives to the suggested activities and steps of the methodology. As in actual practice, there are few simple answers to most of the questions that can be formulated. An instructor must, therefore, look to the validity of the approach and conclusions reached to determine the degree of absorption of the material. I would like to express great appreciation to Blayne Maring, former GTE assistant vice president—architecture, and Charlie Troxel, director of enterprise computing strategies at GTE, for providing the environment and encouragement that allowed the development and refinement of this innovative methodology. Girish Pathak, vice president and director of the operations system laboratory at GTE Laboratories, and Mary Reiner, director of enterprise systems, are also due a considerable amount of appreciation for their efforts on my behalf. Thanks and recognition are also richly deserved by the many associates who worked on the development and validation of the methodology during some aspect of its development. They include Truman Mila and Mark Feblowitz, to whom this book is dedicated, as well as Carl Pulvermacher, Nancy Amburgey, Ken Dilbeck, and David Wang, who participated in the pilot application of the methodology. Thanks are also due to Mark Lapham and Jeff Gilliam of Anderson Consulting, who contributed to the early development sessions. I also would like to thank the many colleagues who participated in the early trials and initial production use of the methodology. Their patience, humor, and helpful suggestions for improvement were of invaluable help in making the methodology a success. Robert B. Walford April 1999 Chapter 1: Introduction Overview Our world has become almost totally dependent on software for its proper functioning. From the control of airplanes to the control of large enterprises, the need to rapidly develop and utilize reliable and cost-efficient software is of utmost importance. The development of software to control devices seems to be progressing at a relatively steady pace. The new Boeing 777 aircraft, for example, is almost entirely controlled by a fly-by-wire structure that is enabled through the use of complex distributed software. In addition, most of the testing of the aircraft was done entirely through computer simulation techniques that provided significant savings while enabling on-time delivery of a more thoroughly tested product. That same level of progress does not seem to apply to the use of software that supports the operation of our large enterprises. There are still many project failures and expensive overruns. The cost and the time required for development and testing keep increasing, as does the backlog of new software projects. Viable future directions that could remedy the problem seem uncertain and distant. This chapter examines the current conditions under which large (and not so large) enterprises must operate. It presents the basis on which a partial resolution to the software development difficulties that pervade modern business can be found. As such, it provides the high-level justification and context for the use of a process-oriented approach to business automation. The discussion is at a relatively high level but contains sufficient detail to show the interrelationships among a large number of complex business, social, and technical issues. It is those interrelationships that provide the clue to the software difficulties of the enterprise as well as the direction for their solution. 1.1 Environment “It was the best of times; it was the worst of times.” That, of course, is the opening from A Tale of Two Cities, the classic novel by Charles Dickens that is set in the late eighteenth century. Why is the quote appropriate for a technical book set in the late twentieth century? Dickens lived in a time of great social upheaval and wanted to explore the effects of that condition on the citizens and institutions of his country. His stage was the novel, a story of fiction. We also live in a time of great social change, compounded by the modern addition of business and technical change. We also need to explore the effects of that change on ourselves and on the enterprises in which we work. The stage is a nonfiction technical presentation—this book. Regardless of the vehicle, the need to explore and understand our environment and come to a reasonable accommodation with it remains the same. Throughout this presentation, the underlying theme is change and how best to react to it. If we react well and take advantage of the opportunities, it will indeed be “the best of times.” If we react poorly, it will be “the worst of times.” Unfortunately, like the characters in Dickens’s novel, we are trying to live and survive in a world where we have only imperfect knowledge of the dynamics, and it is difficult to know how to identify and take [...]... Vol 30, No 1, 19 97, pp 50–56 Bollig, S., and D Xiao, “Throwing Off the Shackles of a Legacy System,” Computer, Vol 31, No 6, 19 98, pp 10 4 10 9 Bork, A., and D R Britton, Jr., “The Web Is Not Yet Suitable for Learning,” Computer, Vol 31, No 6, 19 98, pp 11 5 11 6 Born, G., Process Management to Quality Improvement: The Way to Design, Document and Reengineer Business, New York: John Wiley & Sons, 19 94 Cast,... models, an entity model and a class model The entity model considers the definition and structure associated with an individual entity The entity class model considers all entities of the same type It provides a structure that organizes the entities in a manner that facilitates the creation, management, and use of the entities All the entities modeled in Part II have both entity models and entity class... needed, it does not change the need for a process orientation and an associated automation methodology 1. 6.2 Digital convergence Much current and most future product technology is based on a digital format The common digital representation structure allows computer, television, radio, telephone, and other major technologies to be integrated and viewed in the same uniform way A bit is a bit is a bit It can... Issue 985, Dec 15 , 19 97, pp 77, 90, 98 Covell, A., “Digital Convergence: The Water’s Fine,” Network Computing, June 15 , 19 98, p 32 Davenport, T H., Process Innovation: Reengineering Work Through Information Technology, Cambridge: Harvard Business School Press, 19 92 Dollar, D., and E N Wolff, Competitiveness, Convergence, and International Specialization, Cambridge: MIT Press, 19 93 Feblowitz, M D., and... Figure 1. 3: Process approach to request satisfaction 1. 5 Management by process The impact on the enterprise considering the need for a process approach is a transition to a management-by -process philosophy instead of the classical hierarchical commandand-control structure The transition is the fundamental business reason that a new approach to automation is required The reasons for the transition and... accounting function It is absolutely necessary for the continued viability of the enterprise The intent is to point out that all of the enterprise must change for the process orientation to succeed 1. 5.2 The process of process In this type of discussion, it is easy to forget that management by process itself requires a process The management activities necessary to ensure that the enterprise is functioning correctly... Wiley & Sons, 19 89 Voas, J M., “The Challenges of Using COTS Software in Component-Based Development,” Computer, Vol 31, No 6, 19 98, pp 44–45 Walford, R B., Information Systems and Business Dynamics, Reading, MA: Addison-Wesley, 19 90 Yoffie, D B., ed., Competing in the Age of Digital Convergence, Cambridge: Harvard Business School Press, 19 97 Young, L H., “The Process is the Thing,” Electronic Business, ... Section 1. 6 The resultant impact on automation needs is presented in Section 1. 7 Although management by process is considered by many to be synonymous with process reengineering, it actually is considerably greater in scope Management by process encompasses a basic philosophy on how to manage the enterprise Process reengineering is merely the action of trying to determine a more efficient process for performing... Technique for COTS Impact Analysis,” GTE Laboratories Tech Report, TR-03 51- 12-96 -16 3, 19 97 Flynn, D J., and O F Diaz, Information Modelling: An International Perspective, Englewood Cliffs, NJ: Prentice Hall, 19 96 Hammer, M., Beyond Reengineering: How the Process- Centered Organization Is Changing Our Work and Our Lives, New York: Harper Business Press, 19 97 Lindquist, U., and E Johnson, “A Map of Security... available (and we are quite far from that condition), the effort would not succeed without a different attitude toward software development Supporting processes with automation software requires that the enterprise adapt an integration philosophy instead of a closed-system model In addition, the manual activities and the automated activities must work in concert to implement the process From a software . Tables Business Process Implementation for IT Professionals and Managers Robert B. Walford Library of Congress Cataloging-in-Publication Data Walford, Robert B. Business process implementation. applications to facilitate those same business practices. Table of Contents Business Process Implementation for IT Professionals and Managers Foreword Preface Chapter 1 - Introduction. paper) 1. Management information systems. I. Title. II. Series. T58.6.W324 19 99 658.4’038—DC 21 99 -18 034 CIP British Library Cataloguing in Publication Data Walford, Robert B. Business process