Business Process Implementation for IT Professionals phần 7 pps

The workflow representation or model is different from the business process models discussed in Chapter 5 because workflows must incorporate the technical and workforce information neede

Glass, R L., “Reuse: What’s Wrong With This Picture,” IEEE Software, Vol 15,No 2, 1998,

pp 57–59

Gustavsson, A., “Software Component Management and Reuse Component Repositories,”

Proc 4th Internatl Workshop Software Configuration Management, Baltimore, May 1993, pp

123–126

Heinninger, S., K Lappala, and A Raghavendran, “An Organizational Learning Approach to

Domain Analysis,” Proc 17th Internatl Conf Software Engineering, Seattle, Apr 23–30,

1995, pp 95–104

Jacobson, I., G Martin, and P Jonsson, Software Reuse: Architecture, Process and

Organization for Business Success, Reading, MA: Addison-Wesley, 1997

Kotula, J., “Using Patterns to Create Component Documentation,” IEEE Software, Vol 15,

No 2, 1998, pp 84–92

McClure, C., Software Reuse Techniques: Adding Reuse to the System Development

Process, Englewood Cliffs, NJ: Prentice-Hall, 1997

Rada, R., and J Moore, “Sharing Standards: Standardizing Reuse,” Communications of the ACM, Vol 40, No 3, 1997, pp 19–23

Radding, D., “Benefits of Reuse” Information Week , Mar 31, 1997, pp 1A–6A

Rosenbaum, S., and B du Castel, “Managing Software Reuse—An Experience Report,” Proc 17th Internatl Conf Software Engineering, Seattle, Apr 23–30, 1995, pp 105–111

Sen, A., “The Role of Opportunism in the Software Design Reuse Process,” IEEE Trans Software Engineering, Vol 23, Issue 7, 1997, pp 418–436

Voas, J M., “Certifying Off-the-Shelf Software Components,” Computer, Vol 31, No 6, 1998,

pp 53–59

Chapter 15: Workflow modeling

Workflows are the last automation assets that need to be examined as background for the specification of a process implementation methodology Essentially, a workflow is another representation of a business process The workflow representation or model is different from the business process models discussed in Chapter 5 because workflows must incorporate the technical and workforce information needed for implementation and deployment To differentiate the different process representations, the original

representation is referred to here as the business process, while the workflow

representation is called a workflow

technology has been relatively slow That situation is beginning to change as the

emphasis shifts from process development to process implementation

Defining a process is not very useful unless some means exists to monitor and track the operation of the process and determine how well it is working That is true for mostly manual processes as well as highly automated ones Although manual monitoring and tracking can be utilized, they are not very efficient and the tendency is always to

eliminate that function when time gets short Utilizing the automated means for

monitoring and tracking that workflow provides can greatly assist in evolving to an efficient and effective process

15.1.2 Standards

The Workflow Management Coalition (WfMC) was formed in 1993 by a number of vendors who produced products addressing various aspects of workflow technology The purpose was to promote interoperability among heterogeneous workflow management systems A workflow management system consists of workflow products configured in a manner that enables implementation of one or more specified business processes Currently, the WfMC remains the only standards body involved with workflow products and services It currently produces standards that address the following areas:

§ Application program interfaces (APIs) for consistent access to workflow management system services and functions;

§ Specifications for formats and protocols between workflow management systems themselves and between workflow management systems and applications;

§ Workflow definition interchange specifications to allow the interchange of workflow specification among multiple workflow management systems The standards activities are still in an early stage, with only a small portion of the needed standards addressed in a manner that can provide needed guidance to product vendors and workflow implementers Nevertheless, the existence of a standards body is an important indication of the viability and strength of the technology

Because the WfMC standards generally are concerned with the partitioning of workflow functionality and the interfaces between different functions, further discussion of that aspect of the standards is deferred until Section 15.5 when configuration models are discussed

15.2 Model views

To facilitate the discussion and present the diversity of information required to

understand the use of workflow technology in the implementation of business processes, this chapter utilizes several different models Each model is oriented toward a specific aspect of workflow design and operation The following basic models are considered:

§ The dynamic model illustrates the basic operation of a workflow in performing

a business process

§ The design model represents a business process suitable for implementation

and deployment The parts of the design model are the workflow map, data access, and control

§ The configuration model defines the interaction of the different components of

a workflow management system Each component eventually is realized by one or more products The parts of the configuration model are the

reference model, the logical model, and the physical model

Although the three models are discussed separately to avoid unnecessary complexity, they are closely related and the definitions of all the models must be compatible for the resultant implementation to function properly The interrelationships are not discussed explicitly because of the complexity involved However, it should be evident from the discussion how the models interact

As will be seen, some of the models use concepts and models from previous chapters as

an integral part of their definition That also illustrates the close relationships among all the models that have been presented

15.3 Dynamic model

The basic dynamics of a workflow implementation are shown in Figure 15.1 The four major components of this model are:

Figure 15.1: Workflow dynamics

§ A workflow instance that contains the data relevant to a given invocation of the workflow;

§ Tasks, each of which performs some specific aspect of process functionality;

§ Business rules that determine when and where the next task is performed;

§ A monitor that determines if the workflow is progressing according to the

specified parameters

When a business event occurs, a workflow instance is created The purpose of the instance is to contain the status and instance-specific data that will be associated with the handling of the business event Initially, the workflow instance contains very little information As the solution to the business event progresses, additional information is added A workflow instance exists until the final response to the defining business event

is provided At that time, the characterization of the workflow is complete and can be used for statistical purposes in the management of the process

The workflow instance is known by a number of different names, including folder,

container, courier, and token In addition, the implementations may vary considerably,

ranging from a single structure to a complex set of structures To avoid confusion, the

generic term of workflow instance is used throughout this discussion During a review of

the characteristics of different products, it is necessary to understand that a diversity in naming conventions and implementation methods exists

The information in the workflow instance is examined by the business rules defined for the workflow Depending on the instructions contained in the rules and the data elements and values contained in the workflow instance, a specific task is scheduled and routed to

a role performer assigned to that task After the task is performed, the workflow instance information is updated and the procedure continues until the business event is satisfied When a workflow instance requests a specific task to perform a function, an instance of that task is formed that is then associated with the workflow instance In that way, all the work necessary to respond to a given business event can be connected with that

particular business event, even if the same task is needed for many different workflows

or multiple instances of the same workflow

The operation of the workflow is continuously monitored to ensure that it is performing satisfactorily If a problem is encountered, the instance data are updated appropriately For example, if the monitor discovers that an assigned task has not been completed within the time period indicated by the business rules, the instance information is

updated to reflect that fact When the business rules are next used to examine the instance information, they then may cause a task to be executed that notifies a

supervisor of the problem If allowed by the business rules, it is possible to have multiple tasks simultaneously executing in the same workflow

As part of its function, the monitor also collects statistics on the defined metrics of all the instances of the given workflow process, including the associated task instances Those statistics are used to determine how effectively the process implementation (work flow) is functioning and what, if any, changes should be considered That statistical function operates across all instances of the workflow, as contrasted with the monitoring function, which operates within a single instance

The dynamics of the workflow are incorporated in a workflow engine that is part of the overall workflow management system The engine provides the means for creating the workflow instance, interpreting the business rules, executing the tasks, and monitoring the overall operation of the workflow Because of the differences in commercial products, the specifics of individual workflow engines are not discussed here Instead, the

discussion of workflow engines emphasizes the modeling efforts needed to utilize any workflow engine

15.4 Design model

The workflow design model is an operational representation of the business process

being implemented It consists of three parts The workflow map shows the relative

sequences of the tasks that will be utilized by the workflow Other information is

considered as part of the map and must be keyed to the diagram, including:

§ The rules that determine which tasks will be selected for execution;

§ The transactions called by each task and the location of the functionality

needed by each transaction;

§ The workforce units that will perform the roles used to perform the tasks The characteristics of the workforce units are not considered part of the map

information

The data access model part of the design model indicates what data are contained in the

workflow instance and what data are contained in databases external to the workflow system Both types of data are accessible by the tasks

Finally, the control model determines how the workflow progresses

of a sequence of process steps, a sequence of tasks is utilized

Figure 15.2: Workflow map structure

As defined in Chapter 13, a task usually consists of one or more dialogs assigned to the same role A task can be implemented via a custom development, a purchased product,

a legacy system, or a combination of those methods

Instead of the information flows used in the business process representation, the need to interact with databases and processing functionality is indicated by the use of

transactions The location of the functionality accessed by each transaction also must be indicated Without that information, the workflow cannot be implemented Transactions result from the specification of the actions for each of the dialogs in a task

15.4.2 Data access model

The data access model defines how data are stored and accessed It is illustrated in

Figure 15.3 and shows how tasks can utilize data from either the workflow instance or databases external to the workflow management system As will be discussed, not all the data in a workflow instance can be accessed by the tasks Some data are available only

to the workflow control mechanism In general, that is not a problem because the tasks performing process functionality do not usually require data of that type

Figure 15.3: Data access structure

As shown in Figure 15.3, a task can obtain data from either the workflow instance or an external database Data also can be transferred between tasks using either construct In general, it is better to keep the information in a workflow instance relatively small That avoids the need for routing the same information to a number of potential role

performers Depending on the number of potential role performers, a large amount of data in a workflow instance can require considerable network and processing resources

The use of pointers in the workflow instance to locate required data in an external

database usually is the best method of transferring large amounts of data between tasks The first task stores the data on a database outside the workflow management system but stores key pointers to those data in the workflow instance

The second task uses the key pointers passed to it in the workflow instance to retrieve the application data it needs from the external application database As will be shown, any data needed by the workflow management system business rules to make decisions must be placed in the workflow instance If desired, task functionality can be defined that transfers data between external databases and the workflow instance

To help in the determination as to where to place needed data, the classification of workflow instance data is presented along with a brief explanation of the data involved

15.4.2.1 Internal control data

The internal control data identify the state of individual workflow processes or task instances and may support other internal status information The data may not be

accessible to the tasks, but some of the information content may be provided in

response to specific commands (e.g., query process status, give performance metrics) Multiple workflow engines used to implement a given process also can exchange this type of information between them

15.4.2.2 Workflow-relevant data

Workflow-relevant data are used by a workflow management system to determine

particular transition conditions and may affect the choice of the next task to be executed Such data potentially are accessible to workflow tasks for operations on the data and thus may need to be transferred between tasks Multiple workflow engines used to implement a given process may also exchange this type of information between them The transfer may (potentially) require name mapping or data conversion

15.4.2.3 Workflow application data

Workflow application data are not used by the workflow management system and are relevant only to the tasks executed during the workflow They may convey data utilized in task processing, instructions to the task as to how to proceed, or instance priority As with workflow-relevant data, they may need to be transferred (or transformed) between workflow engines in a multiple-engine environment

15.4.3 Control model

The workflow control model consists of the business rules responsible for determining the sequencing, scheduling, routing, queuing, and monitoring of the tasks in the workflow process Each area is briefly described, and examples of rules for the continuing

example are provided at the end of this section

predecessor task completes Such rules can get somewhat complex for large maps

One of the more interesting differences between the business process map and the associated workflow process map is the amount of parallelism that can be obtained The business process map is very sequential, while the workflow map can have many tasks that are able to execute in parallel Whether it is desirable to take advantage of that situation is up to the workflow designer and depends on a number of factors, including the size and sophistication of the workforce

15.4.3.2 Scheduling

Scheduling is the determination as to when the next task in the sequence should be executed That can vary from immediately to weeks or even months in the future The schedule can be static or dynamically determined from the workflow instance data or an external event calendar Although most of the time, subsequent tasks can be executed immediately, there are a number of situations in which the execution must wait until a predetermined time Such situations would include the availability of equipment or other resources, a time negotiated between the service provider and the customer, and the desirability of performing certain tasks, such as switching electric lines when electric usage is light (e.g., at 2 A.M.)

§ Route to the same individual who performed the previous task in the given workflow instance;

§ Route to a specific named individual;

§ Route to a list of named individuals;

§ Route to any individual in a given geographical location;

§ Route to any individual who can perform the specified role;

§ Route to an individual who can perform the specified role and who has the shortest queue or who is next in line for a new task (round- robin);

§ Any combination of those

Although most products allow an individual who is assigned a task to reroute it to another permissible performer, the workflow designer may restrict that ability to prevent misuse

15.4.3.4 Queuing

The queue of tasks available to a given individual can have several characteristics, depending on the capabilities of the products utilized and the rules established by the workflow designer Queues may be defined to be first in/first out (FIFO) or last in/first out (LIFO) for all tasks arranged by priority in one of those categories In this type of queue, the task performer would not be able to select the next task The task would be

presented automatically when the performer is available using the defined rules This

type of queue is known as a push queue, because it pushes work to the performer

In another case, the queue might be able to be viewed by a prospective performer, who could select any task deemed appropriate For knowledge workers, this is probably the

most used method This type of queue is a pull queue, because the performer pulls work

from the queue as needed

Any form of queue could be used with an automated task performer, although the push queue probably is utilized most often, because it eliminates the need for the task logic to determine which task is to be selected

15.4.3.5 Calendaring

Calendaring is the definition of events based on calendar units (days, weeks, months, years) Examples of calendar events are employee work schedules, server availability, due dates, deadlines, holidays, and special sale periods Sequencing, scheduling, and routing operations are able to use calendar events in making the necessary decisions A monitor function, discussed in Section 15.4.3.6, also can utilize those events to

determine if problems exist with the operation of the workflow instance

15.4.3.6 Monitoring

Using the specified rules, the monitoring function examines the values of the metrics defined for the workflow Depending on the conditions established in the rules, tasks that indicate that some condition has occurred may be initiated or a database may be

updated with appropriate information that can be utilized later for reports or queries

Metrics Some common metrics are as follows:

§ Total time expended for the instance to present;

§ Elapsed real time total for the instance;

§ Elapsed real time in each task in the instance;

§ Elapsed real time in each queue;

§ Elapsed active time in each task;

§ Elapsed active time in each queue;

§ Task throughput per unit time;

§ Resource utilization per unit time;

§ Queue length for each work station;

§ Number of each priority item in each queue

Active time is time that counts against the workflow instance For example, some

workflows do not count traveling time assessed against the workflow instance This type

of metric is important when contractual obligations (service-level agreements)

differentiate between real and assessed time

Alerts and alarms Based on the values of the metrics and the threshold defined for

them, alerts and alarms determine if an alert task (no action required), an alarm task (action required), or a recovery task should be scheduled and routed to locations

specified by the routing rules

Statistical information Statistics are developed for each metric, including those for

each instance, all workflows of a given type, all tasks, and all task performers

Queries and reports Queries and reports request and receive information related to

any of the measured values given previously for an individual workflow instance,

including:

§ Total time expended to present;

§ Time until defined calendar or schedule event;

§ Total cost expended to present;

§ Any of the available statistics

The time period over which the information is needed must be specified

15.5 Configuration model

The configuration of a workflow management system refers to the way in which the components of the system are defined and interconnected The three parts of this model are:

§ The reference model, which defines the system components and their

interfaces;

§ The logical model, which indicates how the components will be utilized to

accommodate a given workflow specification;

§ The physical model, which indicates how the components given by the logical model will be implemented using selected products in the environment in

which they must function

The structure of each model is defined in later sections Additional information as to how the models are developed in response to a given workflow process specification is provided in Chapter 24, which deals with the workflow aspects of the process

implementation methodology

15.5.1 Reference model

As a part of its standards activities, the WfMC has developed a workflow reference model that defines the elements of a workflow management system and the interfaces between them Figure 15.4 is a pictorial description of the WfMC workflow reference model, which consists of five components:

§ Process definition;

§ Workflow enactment service;

§ Administration and monitoring;

§ Workflow client applications;

15.5.1.2 Workflow enactment service

The workflow enactment service provides the run-time environment in which one or more workflow processes are executed It consists of one or more workflow engines that cooperate in the implementation of a given process The model assumes that the

engines of an enactment service are all from the same vendor and are allowed to

communicate using proprietary protocols If engines (and hence enactment services) from multiple vendors are used to implement a process, the reference model requires them to communicate via a standard protocol The characteristics of a workflow engine are described in Section 15.5.3

The enactment service is distinct from the application and end-user tools used to

process items of work As such, it must provide interfaces to those components to provide a complete workflow management system

As can be seen from Figure 15.4, the workflow enactment service is the main component

of the model All the defined interfaces are between it and the other components There are no direct interfaces between components of the model other than the ones shown

15.5.1.3 Administration and monitoring

The administration and monitoring component contains the logic for administering and monitoring the status and operation of the workflow Queries and online status

information (dashboard display) would be a part of this component Process and

workforce changes would not be functions of this component but would be contained in the process modeling component

15.5.1.4 Workflow client application

The workflow client application is the component that presents end users with their assigned tasks according to the business rules (push, pull, and other custom rules) It may automatically invoke functions that present the tasks to the user along with related data It allows the user to take appropriate actions before passing the case back to the workflow enactment service and indicating its current state (e.g., completed, error

condition, reassigned to another performer)

The workflow client application may be supplied as part of a workflow management system, or it may be a custom product written specially for a given application

15.5.1.5 Invoked applications

There is a requirement for workflow systems to deal with a range of invoked applications

In may be necessary, for example, to invoke an e-mail or other communications service, image and document management services, scheduler, calendar, or process-specific legacy applications Those applications would be executed directly by the workflow engine without having to utilize a workflow client

15.5.2 Logical model

There are many ways that a business process can be implemented and deployed using workflow techniques and products The purpose of the logical model is to depict the specific components that are used to implement the process of interest The issues and procedures involved in producing a design for a specific logical model are not considered

in this section, only the need for the model and its structure

To develop a suitable workflow design for a given business process, it is necessary to understand and incorporate the characteristics of the process as well as the capabilities and characteristics of the workflow management system products being utilized If, for example, there is a need to utilize multiple workflow engines, any product considered for the function must be able to provide that ability

Figure 15.5 illustrates the example of using a help-desk process One enactment service consists of four cooperating workflow engines (all assumed to be from the same vendor

so multiple enactment services are not needed) The engines are used to support the user roles as follows:

§ One engine is assigned to the east help desk;

§ One engine is assigned to the west help desk;

§ One engine is assigned to the clerks regardless of location;

§ One engine is assigned to all of the other users (service technicians,

marketing representatives, and experts)

Figure 15.5: Logical configuration model

Each help desk engine needs to communicate with the miscellaneous engine and the clerk engine, but they do not have to communicate between them; once assigned, users cannot migrate between engines

The scheduler needs to be accessed by three of the four engines The clerk process fragment does not require any scheduling The clients of the same three engines need to access the test and diagnostic legacy applications If those applications are accessed by

a task defined outside the client, they also should be shown as a part of the logical diagram, because they would have to be made available to the workstations running the clients and associated tasks

Supervisors and managers are considered to be a part of the group to which they are assigned

15.5.3 Physical model

Once the logical architecture has been determined, the physical architecture can be designed The development of the physical architecture is similar for most types of system development Although some aspects are unique to workflow, the procedure and information contained do not differ materially

Essentially, the physical architecture starts with the logical architecture components along with the automated activities, human interface modules, custom worklist

management modules, and any external interfaces to existing components (applications) needed External interfaces could include those utilized for calendaring, task scheduling, and work force management Also included in the physical architecture specification is the network topology that supports the distributed environment, including protocols, server configuration and characteristics, and data location and conversion

Specific products also are assigned at this step but are omitted in this discussion

because of the desire not to be tied to any vendor’s products Figure 15.6 illustrates a possible physical configuration for the logical model developed in Section 15.5.2 The physical configuration should be detailed enough to serve as an implementation and deployment guide

Figure 15.6: Physical configuration model

Because the details of the physical configuration depend on the infrastructure

components and configuration used by a given enterprise, it is not possible to consider the physical configuration in any more detail The most important aspect of the physical configuration is that it is developed from the characteristics of the logical configuration model

process However, business processes cannot be converted directly to workflows A considerable amount of design is necessary to produce the different models described in this chapter That aspect requires a robust implementation methodology

In some cases, not all of an asset model is directly incorporated into the methodology That occurs because (1) to form a coherent asset model, the defining structure needs to

be broader than is strictly needed by the methodology (e.g., roles, scenarios), and (2) some of the assets have a significant implication for the enterprise beyond that of the methodology (e.g., C/S structure) The reader should not be surprised or confused by this condition

Other automation assets used by the enterprise are only indirectly utilized by the

methodology Those assets are concerned mainly with the infrastructure and include such areas as security, communications, and network operations To keep this book

focused on the topic of process implementation, it was not possible to address those assets in detail However, the development of a robust infrastructure is critical to the automation environment, and those assets need the same degree of concentration given

to the assets needed by the process implementation methodology

Although not always explicitly specified, all the automation assets used in the

methodology must be considered to be “real” enterprise assets and managed using the functions as described in Part II Without that degree of attention, the availability of the assets is unreliable and the ability of the automation methodology to produce effective process implementations is compromised

The asset models developed in Chapters 8 through 15 have been demonstrated to work effectively with the methodology However, it certainly is possible to define alternative models to address unique or unusual circumstances Space constraints do not permit that possibility to be explored here, but enough information has been presented

concerning the motivation and reasons behind the model structure to facilitate that type

of activity

Finally, the author again would like to state his conviction that the automation

environment is one of the most critical elements in the ability of the enterprise to

compete in the future Not only must it improve the efficiency of enterprise operation, it must provide the ability to obtain competitive advantage Without a clear understanding

of the assets utilized in this environment and a means to ensure that they are used to the best advantage of the enterprise, the automation environment will not be able to provide the required support

Selected bibliography

Cichocki, A., et al., Workflow and Process Automation: Concepts and Technology, Boston:

Kluwer Academic Publishing, 1998

Engelhardt, A., and C Wargitsch, “Scaling Workflow Applications With Component and

Internet Technology: Organizational and Architectural Concepts,” Proc 31st Hawaii Internatl Conf System Sciences, Wailea, HI, Jan 6–9, 1998, pp 374–383

Koulopolous, T M., The Workflow Imperative: Building Real World Business Solutions, New

York: John Wiley & Sons, 1997

Jablonski, S., and C Bussler, Workflow Management: Modeling Concepts, Architecture and Implementation, Boston: International Thompson Computer Press, 1996

Jackson, M., and G Twaddle, Business Process Implementation: Building Workflow Systems,

Reading, MA: Addison-Wesley, 1997

Ngu, A H H., et al., “Modeling Workflow Using Tasks and Transactions,” Proc 7th Internatl Conf Database and Expert Systems Applications, Zurich, Sept 9–10, 1996,pp 451–456

Workflow Management Coalition, Workflow Handbook 1997, ed by P Lawrence, New York:

John Wiley & Sons, 1997

Part III: Automation methodology

With the conclusion of Parts I and II of this book, the fundamental concepts and models needed to permit the specification of a comprehensive methodology for

the implementation of business processes are now in place Part III develops and details the specification of a process implementation methodology (PRIME) In a sense, Part III

is an anticlimax since most of the difficult work has been done during the investigation of the automation assets utilized by the methodology What remains is the integration of

those components into a unified design that can be implemented in a timely and

cost-effective manner

It probably is evident from the discussions of some of the individual assets that PRIME is not a conventional methodology It contains a number of unique approaches and

constructs designed to address the issues inherent in the current business and technical environment From the preceding chapters, it should be clear that the current difficulties

of software development and deployment will not be solved by conventional approaches That has been amply demonstrated over the years by the large number of projects that have failed to deliver what they promised They overran projected costs, completion times, or did not provide customers with what was needed Requirements usually were vague and kept changing Development staff turned over, and valuable information that was not documented was lost General management and project management that did not understand the intricacies and special needs of software development in general and business software in particular tried to apply techniques that simply were not adequate for the task

The basic problem is not the particular architecture, technology, tools, equipment, or even management style utilized Other than not being process oriented, the problem is the implementation methodology employed Currently available methodologies contain structural problems and are deficient in one or more (usually all) of the following areas:

§ They do not adequately ensure that the requirements have been incorporated into the completed product

§ They leave too much to the discretion of the developers

§ They have inadequate checks and balances

§ They do not adequately address geographical distribution of equipment and function (with or without Internet techniques)

§ They are not adequately integrated with the infrastructure components and

services

§ They do not provide for the continuous involvement of the customer to ensure usefulness of the completed implementation

§ They do not address the integration of manual and automated tasks, which

must cooperate in the satisfaction of a business event

§ They are not adequately coupled to the structure of the resultant automation functionality

§ They do not incorporate a reuse approach

Assuming that management realizes that a process orientation is necessary to address the fundamental requirement problems, it is still necessary to overcome the difficulties of the available methodologies That can be accomplished only by the design of an entirely new methodology that has as its specific purpose the effective implementation of

business processes in a manner that addresses the listed deficiencies

The PRIME approach addresses all the difficulties of the current methodologies but admittedly introduces constructs that require a technology and culture stretch Because

of the rapid advances in technology occurring on a large number of fronts, the

technology aspect is not an insurmountable problem for even the near future Also,

“workarounds” can be utilized until the needed technology becomes available The major problem is cultural All areas of the enterprise, from executive management to the accountants to the software developers, have to learn a new way of working The

commitment to that change must be obtained from all levels of the organization, from senior management to the individual software engineers Senior management must provide the leadership needed, including overseeing the changes in the strategic

planning process that are required to accommodate the difference in approach The inherent problems in accomplishing such change and obtaining the needed commitment should not be underestimated

If those difficulties can be overcome (and they can), the result of utilizing the PRIME methodology will be implemented processes and associated automation software that meet the needs of the users, that utilize state-of-the-art technology appropriately, that provide results in a timely and cost-effective fashion, and that can be easily changed to accommodate business and technological improvements

Unfortunately, the discussion in Chapters 16 through 27 is essentially a circle No matter where the start is positioned, the entire circle must be traversed before all the concepts and their interactions become clear The author has tried to keep the discussion in as logical a sequence as possible However, the reader should be aware of the inherent circle properties and not become frustrated when a concept is utilized before it can be sufficiently motivated or detailed The problem is self-correcting as the discussion

progresses

Chapter List

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 work flow

Chapter 25: Step 7: Assemble and test

Chapter 26: Step 8: Deploy and operate

independently of the process implementation Its architecture and design are determined

by the services provided, the technology utilized, and the resources available

An explicit differentiation must be made between an implementation methodology and a project management methodology Unfortunately, the two types of methodologies quite often are confused That results in a significant amount of uncertainty as to what is included in an implementation methodology and what are the required skill sets of the personnel involved

An implementation methodology specifies how the conversion of requirements to an implementation should be accomplished It defines the procedures, models, structures, and information flows utilized in the conversions as well as their relationships and when and how they are to be utilized A project management methodology produces a project plan that includes estimates for resources and elapsed time It also may identify the individuals needed to implement the plan After the conversion has started, a project methodology determines if the conversion is proceeding according to the initial estimates

and indicates the types of corrections to make if there is significant deviation from the plan

A project management methodology without an attendant implementation methodology

is devoid of meaning because there literally is nothing to manage In a similar way, an implementation methodology needs an associated project management methodology to ensure that the conversion is utilizing enterprise resources in an effective way The definition and utilization of the two types of methodologies should be separate and distinct because they focus on different problems and the personnel involved require different skill sets

The methodology developed in this presentation is an implementation methodology It focuses on the conversion from requirements to implementation and does not explicitly consider management aspects, such as resource estimation However, where

appropriate, some management topics are discussed when they add to the

understanding of the procedures involved Management topics are explicitly identified as such, in keeping with the desire to keep the two types of methodology separate

It is assumed that both methodologies utilize the same repository That ensures that the project management methodology is able to track the progress and estimate resource utilization of a given implementation and can determine at any step if changes should be made in the development Such information would be placed in the repository and cause the implementation parameters to change accordingly The repository also would be used to contain the results of “what-if” alternatives (e.g., manual function versus

automated function implementation) requested through the project management

methodology Each what -if alternative would use the implementation methodology as needed but would be identified as a separate result associated with the original

development

The specification and design of PRIME are a combination of art and engineering The art addresses the decisions as to the specification of the underlying concepts and models The engineering addresses the detailing of the models and the means to ensure that all the components interoperate as needed Both the art and engineering aspects must work in harmony to provide a methodology that meets the requirements and produces the required results Although it is possible from an intellectual perspective to separate those two aspects, in practice it is difficult because they are closely intertwined Thus, no attempt is made during the development of the methodology to identify when one or the other is being applied The readers are invited to judge for themselves if the

differentiation is of interest

16.1 Automation system

In previous chapters, the term enterprise automation environment was used to represent

the totality of the deployed and operational computing environment, including the

automation software (applications and infrastructure) and the computing and network equipment employed in the enterprise Because PRIME is one mechanism by which the automation environment software is structured, it is necessary to define further the environment and the associated elements used in its creation, which, for convenience,

are referred to as the automation system

The automation system is defined by the model shown in Figure 16.1 The primary input

to the model is the business requirements as represented by the business process Secondary inputs are (1) enterprise standards that will affect some aspect of the

development or deployed process and (2) stakeholder needs, which represent the interests of the different classes of individuals interacting with the deployed process The output is the implemented and deployed business process the users employ in

performing their work The deployed processes consist of the business functionality and associated workflow management that use the enterprise computing infrastructure for common support services (e.g., security, communications) The set of all such deployed

processes is the enterprise automation environment