Business Process Implementation for IT Professionals phần 1 pps

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

Business Process Implementation for IT Professionals

Artech House © 1999 (599 pages)

An all-inclusive roadmap to help you convert business practices into applications to facilitate those same business practices

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

Business Process Implementation for IT

Professionals and Managers

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

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

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

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-t o-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 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

two-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

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

advantage of the opportunities that occur An additional complication is that the current rate of change is far greater than in Dickens’s time The concept of “Internet years” is very real The future cannot be ascertained with any certainty because it is a function of the unknown dynamics The temptation is to look for shortcuts, to follow the latest fast-talking pitch man who promises an easy answer to our problems, and to be satisfied with

a fast small reward rather than working toward large future gains

The author hopes that this book will be a factor in avoiding those temptations and, by addressing at least one important area of concern, will aid in coping with the unceasing change that pervades our profession The specific subject of interest is the revolution in need for enterprise automation and the most effective means for providing flexible workable solutions that will not rapidly become obsolete

1.2 Discussion organization

The formation of a business automation methodology is approached here through the use of a system engineering approach to specify the structural elements and their interrelationships The overall structure of this book is shown in Figure 1.1

Figure 1.1: Automation methodology determination structure

First, the major business drivers and associated requirements are identified and

examined Second, the major technology drivers that affect the enterprise are defined and discussed With those business and technical drivers as a base, a set of automation requirements and principles are specified Those requirements are then converted into a set of automation assets and an associated asset management system The asset management system ensures that the proper assets are available when needed The automation assets are utilized by the methodology to create specific elements of the enterprise automation environment The enterprise automation environment architecture

is based on workflow model

On the basis of that information, Part I defines the asset management system, Part II

identifies and models the automation assets, and Part III provides the overall

specification of an automation methodology that transforms the assets into elements of the enterprise automation environment The methodology design is directly dependent

on the automation requirements and principles, automation assets, and the enterprise automation environment architecture

1.3 Business requirements and drivers

In essence, only four high-level business requirements apply to the development of any product—software, hardware, text, graphics, or combinations thereof—in the current environment:

§ Decreased time to market;

§ Decreased resources expended (financial, personnel, equipment);

§ Increased quality;

§ Increased value to the customer (functionality, ease of use)

Every other need is in support of those four Of course, in providing that support, a fair number of details must be considered and appropriate decisions made It is the details that make these simple requirements so hard to achieve in practice Examples of the types of decisions that must be made are:

§ Do the requirements apply to each product individually, to an average across all offerings, or some combination?

§ How are specific conflicts between the requirements resolved?

Those and other questions and their resolution, which generally requires some form of compromise, do not invalidate the requirements They only serve to illustrate the types of considerations that must be addressed in translating them into realistic procedures

In addition to the four general product requirements, some requirements resulting from general enterprise philosophy usually must also be considered (e.g., premature

obsolescence of previously implemented software products should be avoided) in the determination of an automation methodology These are usually presented in the form or business rules discussed in Chapter 5

Although this discussion focuses on the business requirements, a number of business drivers also greatly affect the operation of the enterprise They include changes in regulatory and legal requirements, changes in the competitive landscape (e.g., mergers, bankruptcies, startups), and changes in executives and other key personnel As with the requirements already discussed, the drivers also greatly affect the way in which the enterprise must operate

1.4 Business structures

In the classical business structure of the recent past, the organization is hierarchical and the information processing function based The hier- archical organization model was based on the centuries-old military structure that emphasized command and control at each level of the organization That type of rigid structure evolved because it was the only model then known that was suitable for a large organization Because organizations tended to grow larger with the advent of industrialization, it was only natural that this type

of structure would dominate

The evolution of functionality-based information processing also occurred for similar historical reasons, although, of course, the evolution occurred much later When

computers were first applied to the hierarchical organization to reduce the amount of manual information processing, it was only natural that the automated information processing would mirror the specific functions of its manual predecessor Thus, the concept of the information system that performed some specific set of functionality such

as payroll, accounts payable, order entry, and inventory came about Each of those systems was independent of the others and was considered to be owned by the

organization that historically performed its function Because of the way they are

sometimes pictured, those systems are sometimes called vertical silos of automation (Figure 1.2) In the figure, the line that winds through the silos represents the path followed to fulfill a customer’s request The systems generally are utilized on an ad hoc basis as each organization becomes involved and provides its function

Figure 1.2: Vertical silos of automation

The hierarchical organization and its silo-based, centralized automation support began to change because of numerous technical and social pressures

§ Relatively inexpensive desktop computers, which could store large quantities

of information and perform tracking and scheduling tasks with ease,

became widely available Desktop computers made it possible for one

person to manage a much larger number of subordinates and functions

than could be performed using manual techniques The need for middle

layers (management) in the hierarchical structure was greatly reduced

§ The onset of true global competition, with subsequent pressure on the cost

and quality per unit of produced goods and services, made it necessary for the enterprise to become much more efficient in terms of its cost of

producing a unit of output

§ The cost of a full-time employee was rapidly escalating, not because of large increases in remuneration but because of the cost of the benefit programs (mostly health care), which were rising much faster than the rate of

inflation

§ Due to new laws and other legal considerations, it was becoming increasingly difficult and expensive to eliminate full-time workers either permanently or temporarily during cycles of decreased activity

§ Companies were becoming global with locations throughout the world That

required an effective method of interaction between many geographical

diverse locations with differing customs and business practices

All those factors made it imperative that large enterprises reinvent themselves to become competitive on a global basis It was either that or simply go out of business

The reinvention of large (and many medium-size) businesses is still proceeding and probably will not reach some sort of new equilibrium until well into the twenty-first

century Enough change has occurred, however, that we can discuss the major trends that are occurring in three broad areas: the organizational (management) structure of the enterprise, the operational structure of the enterprise, and the application of technology (automation) to the operation of the business While the last trend is of most importance

to the thrust of this presentation, it is necessary to place it in the context of the other two

to fully understand the consequences and opportunities that are beginning to arise The organization of the enterprise is changing in three basic ways The first change, as mentioned previously, is that the number of layers in the organization is being greatly reduced This “flat” organization requires methods of both informal and formal

communications as well as automated support that is different from that of organizations with a hierarchical structure

The second change, which follows directly from the first, is that the number of employees

is also being greatly reduced More, in fact, than the workload would ordinarily allow

That is being mitigated by the formation of self-directed and other types of work teams that perform a large number of management and administrative tasks formerly performed

by the displaced middle managers in addition to the work performed for the benefit of the customer The availability of automation to assist individual team members as well as the team as a whole has contributed significantly to the ability of the team to provide the required productivity Because of the closeness of the team to the customer and work performed, there probably is some improvement in overall efficiency, although the final verdict on this type of structure is still a long way off

The second and by far the most important mitigation for a reduced work force is the use

of consultants and outsourcers to perform work previously accomplished by employees Although their cost may be initially greater than before, exposure to increasing benefits cost is avoided along with social and regulatory restrictions on reducing the work force when necessary

Those changes in organizational structure and staffing require a corresponding change

in the way the enterprise must operate The reduction in the number of hierarchical levels and employees can no longer support functional partitioning with the large number

of interfaces that must be managed and maintained Reducing the number of interfaces requires that cross-functional views of the organization be taken

That leads to the third fundamental enterprise change The operational emphasis of the enterprise becomes one of process rather than organization The emphasis on

organization produced processes that were implicitly defined and functionality that mirrored the organization partitions An emphasis on process requires that the

functionality be defined to support the process In fact, the current emphasis on process reengineering does not result from a desire to take the current processes and make them better, as would be expected from the name Process reengineering is, in reality, a way to make a transition from an organization- or function-based view of the enterprise

to a process-based view It is more enterprise reengineering than process reengineering

In a process approach, the satisfaction of the customer request, is obtained through the use of a process specifically defined to handle that type of request (and perhaps others

of the same general type) The process approach to handling customer requests is illustrated in Figure 1.3 Notice that the process is a continuous end-to-end definition of the required activities needed to handle the request That is significantly different from the functional organization that has a discontinuity at every function boundary The effectiveness of the process view is enforced by the managed entity being the process rather than the individual organization function

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 and-control structure The transition is the fundamental business reason that a new approach to automation is required The reasons for the transition and some of the major consequences are discussed in Section 1.6 The resultant impact on automation needs

command-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 some aspect of the enterprise operation Although process reengineering seemingly focuses on process, in many cases it focuses on a single organization or

function within an enterprise (e.g., accounts payable) and, except at a very rudimentary level, does not require much in the way of a process orientation

In this discussion, the emphasis is on the process management philosophy The

determination of suitable processes, while of considerable importance, is relegated to the automation methodology That ensures that the selected processes can be efficiently incorporated into the enterprise automation system

enterprise are affected by a process-oriented approach, it is necessary to examine some

of the organization, financial, and software implications of the process paradigm

Although the organizational and financial implications may not immediately seem

pertinent, in reality, they have an enormous impact on how the automation needs are defined and obtained That impact will become clearer as the discussion proceeds

in the new approach Workflow techniques that form an important part of process

implementation and facilitate this type of organization are discussed in Chapters 15 and

24

1.5.1.2 Financial

Although the discussion thus far has referred to some underlying financial pressures, there is a need to address additional financial considerations related to the changes themselves The financial aspects are divided into two parts: those dealing with the effects that result from any change and those dealing with the effects of a specific shift to

a process paradigm Additional financial implications of the process approach are

examined in Chapter 6

The major financial result of any radical change is the premature obsolescence of those assets that supported the old paradigm and the corresponding need to obtain assets that support the new way of operating The enterprise must be prepared to write off a

significant amount of assets and commit the resources necessary to obtain new assets The assets can exist in many parts of the organization and include such diverse items as buildings, equipment, office supplies, forms, intellectual property, and support software Although all costs of change must be considered, it is the last item, software, that is of particular significance in this discussion As discussed previously, software that does not fit the new enterprise directions usually is referred to as a legacy system, and its

disposition as well as the acquisition of replacement software can be quite costly to the enterprise

The financial aspects of changing specifically to a process orientation are associated mostly with the determination of the total cost of ownership of an asset used in the implementation of a process That requires that the cost of the asset over its entire life cycle, including acquisition, operations, and disposal be estimated a priori The financial and accounting structures of the enterprise must accommodate that approach, which can

be complicated by the projected use of the asset in multiple processes and involve both capital and expense components In addition, because processes themselves can be

considered assets, the cost of a process over its asset management needs to be

ascertained and a determination made as to the propriety of utilizing that process The accounting function in many enterprises, because of government reporting

regulations and organization culture, can prevent many of the financial aspects of the process approach from being effectively implemented That can be implicitly done in a number of ways:

§ The need for considerable upfront investment can be frustrated An

emphasis on cost rather than investment can stop the procurement of assets needed to define and implement the processes

§ Internal controls can be established that prevent a process from being able to be efficiently implemented

Although many functions of the enterprise can impede the transition to a process

paradigm, the accounting function, because of its history and orientation, must be

especially considered This discussion is not meant to disparage the 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 and at a high degree of efficiency should also be addressed by an appropriate process Because the management process is an enterprise process, it is subject to all the characteristics of any process

Although this type of recursion can be conceptually difficult, in practice it offers few problems as long as there is a reasonable separation of functions within the enterprise The management process must be considered as just another process to be managed, and the same measurements and corrective actions that are defined for any process can

be applied These processes can also make effective use of automation in their

implementation

1.6 Technology requirements and drivers

The state of the art is changing so rapidly that any technology presentation will be

obsolete almost as soon as it is completed In the current environment—to put it

bluntly—nothing is stable, everything is flexible, the choices are enormous, and few products from different vendors interoperate In addition, the applications are more complex, and the time-to-market need is more critical Those conditions are not likely to change in the foreseeable future Any approach to enterprise automation must directly consider this environment in addition to the classical functionality requirements The only way to accommodate all those additional pressures and still produce a product that always meets the needs of the customer when it is deployed is to define and utilize anappropriate automation methodology specifically oriented toward process

implementation The required methodology must provide structures and activities that explicitly consider the conditions of the current environment and take advantage of the opportunities they offer while mitigating the difficulties

As would be expected, a considerable number of technologies affect the automation requirements of the enterprise A comprehensive treatment is far beyond the scope of the current presentation Many of those technologies are addressed in later chapters, where they are utilized in the formation of an automation methodology From an overall enterprise perspective, however, it is necessary first to consider the major technology-oriented pressures and constraints under which the enterprise must function:

§ The Internet (and associated technologies);

§ Digital convergence;

§ Commercial off-the-shelf (COTS) products;