Business Process Implementation for IT Professionals phần 4 potx

When all is said and done, specification and implementation of the leaf processes are the heart and soul of process engineering.. For example, consider a leaf process defined to satisfy

on the needs of the business, but it would not require any software support In a process that requires software support because of advancing technology, several generations of software, each with its own life cycle, could be employed without changing the process Alternatively, for competitive reasons, a process could undergo considerable change during its life with corresponding implications on the software that supports it In fact, one

of the goals of the new view of process support software is to allow a process to undergo considerable change without the need to greatly change the underlying support software, which is designed to be process independent Techniques for realizing that goal are examined in the discussion of software components in Chapter 14 as well as in Part III The model defines four main subcycles of the overall process life cycle: plan, design, operate, and manage The plan cycle is further divided into two additional subcycles: the

business events plan and the business structure plan Cycles are called cycles because

they may be visited over and over during the lifetime of the process They are not

considered phases in the sense that, once a phase has been completed, it is never again invoked for the same development instance

In the methodology discussion, the term spiral is used to indicate a repeatable set of

activities That is in keeping with generally used methodology terminology Using two different terms also helps differentiate between the life cycle model and the methodology that enables it

Each subcycle is discussed briefly to ensure that the definitions of all the assets in the subcycle, their major relationships, and their place in the overall enterprise process context are well understood Details of most of the assets of interest are contained in other chapters The purpose in this discussion is to understand the life cycle and its components as a whole

8.2.1 Plan cycle

The plan cycle is where the enterprise defines the business it is in and how it intends to support that business In many, if not most, businesses, the definition is informal and has grown and changed throughout the life of the enterprise with little or no attention Even businesses that devote a considerable amount of their resources to a planning function

of some type do not have a model for describing and quantifying their expected

interactions with customers or the structure by which they intend to meet the requests of those customers Most businesses have been quite successful over a long period of time without a defined approach That was possible because of the inherent constraints imposed by the hierarchical organization and function-based automation support Those conditions, to a great extent, mitigated the lack of formalized models

With the change to a relatively flat, process-based organization and client/server

distributed automation support, the lack of a planning model puts any enterprise at a considerable disadvantage That disadvantage is external with respect to competitors who are able to model and understand their business The disadvantage is also internal,

in that the efficiency of operation will be far less than it could or should be with a thought-out model For the remainder of this discussion, it is assumed that the enterprise has a formal planning structure of the type described here Although other approaches to the plan cycle can be defined and successfully utilized, a discussion of their structure and characteristics and how they would fit into the other subcycles is beyond the scope

well-of this presentation

The plan cycle is used to determine the definitions of the relevant business events and the enterprise operations processes It contains two basic types of structures: (1) those devoted to understanding what the customer intends to request of the enterprise and expect in return and (2) those devoted to how the enterprise intends to respond to those requests It would be expected that the two types of structures would be closely

interwoven and their specifications performed in concert

In practice, that is not the normal situation Both types of plan structures usually are defined and specified independently The customer interaction definitions are provided

by front-line or first-line supervisory personnel, who are intimately involved with the

customers and understand their needs and expectations The business structures, including high-level process definitions, generally are provided by executive personnel, who are far removed from “real” customers, and result from history, internal politics, and

in many cases a lack of understanding of how the needs of the customers are being met Considerable friction results from those two parts of the planning function being

independent degrees of freedom What should be a smooth response to a customer request or other business event becomes difficult when it is handled by a business structure not designed to accommodate it Process reengineering was supposed to fix that problem, but the existing organization structure proved to be extremely resistant to change

The organization can remove layers, it can downsize, it can change technology, it can emphasize process over function, but it usually retains the old organizational structure boundaries The engineering organization remains the engineering organization; the sales organization remains the sales organization; and the manufacturing organization remains the manufacturing organization Whether one organization or another is the best one to meet the needs of the customer is relegated to secondary importance There is turf to protect, careers to consider, and a general fear of the unknown When everything around you is changing, there is usually something that is made to be stable That “thing”

in current enterprises is the existing organizational structure

Because the disconnection between defining customer needs and structuring the

enterprise to provide for those needs is unlikely to change, the best approach is to develop frameworks and procedures designed to accommodate the two different views and mitigate any resultant friction and conflict That is the approach taken in this

presentation and in the methodology presentation in Part III Experience has shown that such harmonization has worked well when put into practice Sections 8.2.1.1 and 8.2.1.2 discuss the plan cycle areas and their major interrelationships

8.2.1.1 Business events

Business events are occurrences that elicit some type of response from the enterprise The purpose of predefining expected events is to determine how to produce an effective response An effective response is one that satisfies the requester (if the event is a request), is cost effective for the enterprise, and is consistent with the enterprise view of its purpose Business events can be external or internal They can be caused by

customers, suppliers, employees, or other individuals associated in some way with the enterprise (including those with criminal intent) Business events also can arise from nonhuman sources, such as storms and earthquakes

To illustrate the usefulness of explicitly defining business events, consider the following example An enterprise is in the retail shoe business and a customer requests the

custom manufacture of a shoe This event could be handled by the enterprise in a variety

of ways:

§ The request could be rejected outright if the enterprise does not want

to be in the custom shoe business and has no knowledge of

organizations that perform that type of work

§ As a service to the customer, the requester could be referred to

another enterprise that manufactures custom shoes with no further

involvement on the part of the retail establishment

§ The order could be taken by the retail shoe business, sent to another enterprise for manufacture, and returned to the retail business, which would then deliver it to the customer

§ The retail shoe business could manufacture the shoe itself using its

own facilities and resources

The possible responses to the same business event are listed in the order of the

business’s increasing involvement in the event There is no right or wrong response to this event Each response is possible depending on what business the enterprise

believes it is in, what its resources are, and how it presumes its customers should be

treated However, if there is no attempt to predefine expected business events, the business will not have the opportunity to make this type decision explicitly That could result in, among other problems, lost revenue opportunities, inefficient use of resources, and unhappy customers

The major automation asset used in the plan cycle is the scenario Scenarios represent detailed business events that the enterprise expects to occur in the course of business and that it wants to be able to effectively and efficiently address Scenarios provide a framework on which to model and examine the definitions and consequences of

business events that the enterprise is prepared to handle Scenarios are described in detail in Chapter 9

In addition to providing a structure on which to model business events, scenarios are also useful to distinguish planned business events from those that actually occur during the operation of the business As would be expected, planned business events are

referred to as scenarios, while actual ones are referred to as business events Although

that may seem a small point, considerable confusion occurs when the same term is used

in the planning sense and in the operational sense

Scenarios are grouped by “story,” and many scenarios can have the same story

Individual scenarios are differentiated by the context, or specific set of circumstances associated with the scenario The context for each scenario in a story group must be different As an example, several scenarios can have the story “a customer places an order.” Individual scenarios with that story have different contexts For example, the context could be formed by attributes that indicate the customer’s size, credit rating, frequency of ordering, and size of order Each unique set of values for those attributes would be a different context and hence a different scenario

Depending on the specific need, scenario story groups or individual scenarios could be used in the individual subcycles of the process life cycle

measurement of the internal efficiency of the business Unfortunately, in most cases, a formal business model does not exist, or it is at such a high level that no real use can be derived from it In that case, the necessary models still can be defined, but they may not

be as tightly coupled as would be desirable

Process class model If a business model does not exist or does not contain a process

class model, a process class model must be created That is accomplished by defining the overall business operations process and then decomposing it into subprocesses The decomposition continues until processes are obtained that can be implemented through manual and automated operations and deployed so that individuals can utilize them in performing their job assignments

Such a procedure is illustrated in Figure 8.2 The root process is decomposed into branch processes, which are then further decomposed as necessary until the leaf

processes are reached The leaf processes eventually are implemented and deployed The root process and the branch processes are utilized only to arrive at the

implementable leaf processes The resultant structure defines part of the class model The remaining part of the class model is determined by the relationships among the leaf processes

Figure 8.2: Decomposition of the business process

The definition of the leaf processes that will best support the business is one of the two most important activities in a management-by-process approach The other activity is implementation of those leaf processes When all is said and done, specification and implementation of the leaf processes are the heart and soul of process engineering With any decomposition procedure, there is always a question as to how many levels are needed and what the termination criteria should be In the case of business processes, it

is strictly an issue of management of complexity and resources Process decomposition should continue until the leaf processes are of such a number and complexity that the enterprise feels comfortable about its ability to define each of the processes in detail Another important question in process decomposition is the information that should be included in the initial definition of each process At a minimum, the name; description; relevant business events, products, and services; business rules; and resources utilized should be included in this high-level model

For example, consider a leaf process defined to satisfy some maintenance business events The process initially could be documented as shown in Table 8.1 Eventually, as detail is added in Chapters 13 and 15 and Part III, other models of the leaf process are specified and introduced during the appropriate discussions

Table 8.1: Example of Leaf Process Documentation

Process

of the maintenance process is to keep the equipment in good

operating order and to minimize the time a given piece of equipment is unavailable The

maintenance process must also provide for the timely repair and testing of

Table 8.1: Example of Leaf Process Documentation

Process

inoperable equipment

maintenance process utilizes dedicated resources (people and facilities) It has a fixed yearly budget for all

aspects

maintenance process is not responsible for repair in the aftermath

of a disaster, such as a fire

or flood The maintenance process is responsible for initial setup and certification of new

equipment Except in emergencies,

it cannot completely shut down another process or result in a significant increase in manufacturin

g costs

inoperable equipment Arrival of new equipment Time for equipment maintenance

Table 8.1: Example of Leaf Process Documentation

Process

repair New equipment certification Scheduled equipment maintenance

Organization charts The most often created model of an enterprise is not the process

model but the organization chart Almost every business with more than a few

employees has one An organization chart defines the partitions of the business (usually

called organizations), the responsibilities (usually called functions) of the organizations,

and the reporting relationships of the organizations The organization chart is a static model that is suited to the hierarchical structures of the past It cannot show how the enterprise organizations would respond to a business event

Usually, responses to business events generally were documented informally or through written practices or procedures Usually, the process by which an event was handled was “just known.” For example, “First the order goes to the order department, then it goes to the engineering department, then it goes to the manufacturing department, and finally it goes to the shipping department.” Other departments may be involved for billing, purchasing, and so on, and their roles in responding to the order usually are defined in the same informal way

Those major partitions of an enterprise probably are not going to change significantly Almost always, too much history and politics are involved How, then, is the enterprise going to formally model its response to expected business events without eliminating the organization chart? The current and most obvious answer is to define each major

partition as a process The billing organization gives rise to the billing process, the shipping organization defines a shipping process, and so on This type of partitioning occurs quite often, even if the enterprise pretends that it is entirely process based and defines and decomposes high-level processes in the manner presented in Figure 8.2 Decomposing those high-level processes seems to result in a one-to-one relationship between a leaf process and an organizational unit

The major problem with that one-to-one relationship is that an organization-based

process may not be the most appropriate one to handle a set of expected business events That is especially true for those events that need more than one organization to

be involved in the response (the usual case) It is also possible, even with the best of intentions, to arrive at leaf processes that are inappropriate for the set of business events that must be serviced That can result from inexperienced staff performing the

decomposition or from lack of knowledge concerning the vision and the goals of the enterprise What happens in that case is that the vertical automation silos (discussed in Chapter 1) resulting from the traditional organization- or function-based approach are replaced with horizontal silos based on an organization approach to process definition The horizontal silos are, in essence, the vertical silos rotated 90 degrees Figure 8.3 illustrates this rotation for the vertical silos of Figure 1.2 In either case, because of the lack of integration, the silos inhibit the development of the needed end-to-end processes Fortunately, there is a relatively easy method of mitigating problems with leaf process definitions, regardless of how they occurred That method is discussed in Part III

Figure 8.3: Horizontal silos of automation

Business rules The general definition and structure for business rules were described

in Chapter 5 Business rules as applied to processes are of particular interest in the context of the process life cycle In that context, business rules are defined to be

constraints on the enterprise processes or their relationships Business rules can be defined that apply to all enterprise business processes, a set of processes, or only one process Business rules can be defined at any level of process decomposition or

specification, including implementation Business rules can assume different forms and contain different information, depending on the level at which they are defined and the particular process(es) to which they are applied

Business rules also can be applied to different aspects of a process and its

implementation, including the flow control of the process, the functionality required by the process, the data used in the process, and the assignment of human performers to the process

Process maps Once the leaf processes have been defined, considerable detail must be

added to their specification to allow for their eventual implementation A model that can accommodate that detail in a structured way and serve as a framework for the necessary analysis and testing must be defined Because of the difficulty in working with the strictly text-based representation model utilized in the decomposition procedure, the new leaf process model is usually a combination of graphical, text, and data formats in a well-defined configuration For simplicity, at the risk of introducing some confusion, this

discussion of process representation and analysis utilizes the word process to mean a

leaf process Because only leaf processes are implemented, that should not cause undue confusion

Detail is added to the process specification in several ways throughout the

implementation period, which starts with the availability of the leaf process(es) definitions and ends with product deployment and operation Because the detail-adding activities are under control of the implementation methodology, most of this discussion is given as

a part of the methodology presentation Only enough of the procedures are covered to provide an understanding and motivation for the overall life cycle and its individual components

The detail that is added to the process specification during the business structure cycle

is designed to accomplish two basic results: The first is to determine and specify, at a relatively high level, the functions, information flows, and skill definitions necessary to implement the process The second is to determine if any of the automation assets have been previously defined so they can be reused The structure and detail level of the process model must be such that reuse of any previously defined functions, information flows, and skill definitions is facilitated There are guidelines for determining the proper size and complexity of those assets so that reuse is maximized The guidelines are discussed during the methodology discussion The ability to reuse assets specified at the process level can result in significant savings in implementation and deployment costs One representation model that seems to allow processes to be detailed and examined effectively from the business perspective is the process map The format of the graphical portion of a process map is shown in Figure 8.4 It consists of process steps arranged

according to their assigned roles and precedence order If desired, organization

information also can be included, although it is not strictly required

Figure 8.4: Example of a process map

Process steps can be either functions or decisions Process steps can occur in parallel, although the map usually tends to be highly sequential for two reasons:

§ Business function subject matter experts (SMEs), using explicit or

implicit scenarios, tend to think in a sequential manner when determining the functions and decisions that can be utilized to realize

a specific process

§ The sequential format simplifies the use of the map in determining if

the map assets can support the handling of associated business events as defined in appropriate scenario groups and individual scenarios

Although the process map realization has certain characteristics that are not an inherent property of the process it represents (e.g., very sequential functionality), those artifacts

do not matter as long as the map is successful in showing that the scenarios are capable

of being satisfied through the defined functionality The representation artifacts can be removed later during the design/build activities

Roles are shown as horizontal segments on the process map The purpose of roles is to define the skill sets necessary for performing a given part of an implemented process The definition and utilization of roles are examined in Chapter 10 Optionally,

organization units that contain those roles also may be incorporated in the same format

as the roles Incorporating organizations does provide an additional comfort level to many SMEs and their management, but it is not necessary and, indeed, may prove to be

an unwanted distraction

The process map framework requires that additional information be specified for each process step, including the following:

§ A comprehensive description of the process step (function or decision)

in addition to a descriptive name of some sort;

§ Specification of any particular approach or algorithm that must be used

in an implementation;

§ The information needed by the process step;

§ The information produced by the process step;

§ Operational data as known (e.g., throughput, number of performers, physical locations)

The additional specifications generally are documented in a separate text format so that the graphical map format does not become too cluttered How the two formats are related and utilized is a tool implementation issue and is not discussed further at this

time The difference between information and data as specified in the process map is

discussed in Chapter 11

Connections between process maps During the development of a given process

map, the determination of the relationships that need to be established between its process steps and the process steps of other maps needs to be made That usually is performed at two levels, depending on the amount of information available concerning other maps Level 1 simply specifies that there is a relationship between a process step (input or output) and another process The existence of a relationship should be

communicated to the developers of the other map involved (if they are a different set of

individuals), but detailed coordination is not necessary at this level The communication also should be made to any stakeholders (concerned individuals) of both maps

Level 2 requires identification of the specific process step in the related process map and the exact nature of the relation (e.g., precedence order of the two steps) This requires agreement from the developers of the related map who must reflect the same

relationship in their map Eventually, all process step relationships must be defined on a process step–to–process step basis, whether the two process steps are in the same map

Process understanding While the development of the process map is oriented toward

arriving at a representation of the process that can serve as the basis for an

implementation, there is another important consequence of the map specification

activities That consequence is the fostering of a much improved understanding (from what is usually available when a process is first defined) of the function and the purpose

of the process as well as its projected use in the enterprise Although it is an implicit product of the map specification, this improved understanding probably has as much (if not more) impact on the final implementation of the process as the map structure itself During the design/build cycle, it is relatively easy to find and correct any structural problems with the map (e.g., steps that should be decomposed or missing information flow) It generally is much harder to find and correct fundamental misunderstandings concerning the function and the use of the process in the enterprise (e.g., because of some natural affinity, parts of the process should be placed in other processes)

by-Detection of such later types of problems is best accomplished during the development

of the process map representation, hence the emphasis on process understanding during development of the map

Process prototypes Construction of the process map is extremely useful in producing

a greater understanding of the use and the context of the process and determining the process requirements for function, information, and skills However, to be useful as an implementation vehicle, the process map must be tested as rigorously as resources permit to determine if it is constructed in accordance with the definition and the purpose

of the original process

The testing is accomplished by utilizing all the scenarios that in any fashion require the functionality of the process map under test If possible, for scenarios requiring multiple processes, it is also desirable to test the process in the context of the other processes so that the connections between them also can be tested That does not have to be done at the time of initial process map testing, but it does have to be performed at some time before the completion of the design/build cycle

Before testing starts, the process map is converted into a process prototype If tool support is not available, that simply means that a wall-size copy of the process map is printed and declared to be the prototype The process prototype engine in that case is human (The author has been an engine of this sort many times and frankly enjoys the experience.) If tool support is available, the process map definition is made available to the tool that contains the process prototype engine The specific mechanism used depends on the tool and the environment being used

The process prototype is one of a number of prototypes that are defined and used throughout the life cycle of the process Each prototype is used to test a different aspect

or level of a process representation It is only through the prototypes that the detail

required for process implementation can be tested for compliance with the definition of the original process and its associated business events

Testing is initiated by selecting a scenario that is of critical importance Using either a human or an automated prototype engine, the sequence of process steps that result from applying the conditions of the scenario to the process map is identified There can

be several possible outcomes from that activity Some of those outcomes are outlined in the following list, along with an indication of the action that needs to be taken In actual practice, there are many possible results and even more actions that can be taken, depending on the specifics of the problem and the process

§ Result: A sequence of process steps occurs, ending with a normal

termination point, that provides the desired outcome Action: None

required The scenario test has been successful

§ Result: A sequence of process steps occurs, ending with a normal

termination point, that does not provide the desired outcome Action:

Change the process map so the desired outcome occurs That may involve changing the definition of a process step, adding process

steps, or changing the relationships between process steps

§ Result: A sequence of process steps occurs, ending with an internal process step for which there is no reasonable successor Action:

Change the process map so the desired outcome occurs That may involve changing the definition of the terminating process step or

previous process steps, adding process steps, or changing the

relationships between process steps

§ Result: The scenario is not detailed enough to be able to identify the path that should be taken for at least one decision point Action:

Change the scenario so that the decision point is explicitly defined

This will also usually involve the creation of another scenario that will indicate that the opposite decision point should be taken

Once the scenario run is successful, the next most critical scenario is selected and the procedure repeated That continues until several of the most important scenarios run successfully The actual number of possible scenarios is extremely large, and only a fraction can be utilized in this procedure The main purpose of the process prototype testing is not to test the process exhaustively (not a tractable activity) but only to obtain confidence that the process representation is reasonable Achieving such confidence does not mean the process map will not change in the future (it undoubtedly will) due to many other possible factors Successful runs of a number of critical scenarios at this stage of definition mean only that the process has been successfully represented in a form that can be communicated to all enterprise personnel who need a working

knowledge of how the implemented process will function That can be demonstrated through the use of the map and scenarios of interest

The scenarios used in the testing of the process map are saved and will be used again when other representations of the process are defined during the design/build and operate cycles of the process life cycle By using the same scenarios, the reactions of the process representations can be compared That greatly assists in the determination

of the correctness of a representation Additional scenarios can, of course, be added to the test suite at any time during the implementation

Regardless of how it is accomplished, the result of a scenario run against the process map is a process step sequence called a process scenario trace Examples of scenario traces for the process map in Figure 8.4 are shown in Figures 8.5 and 8.6 Exactly how the sequence is identified, displayed, and documented is a function of the tool or human procedures utilized The exact formats are not critical but need to be defined, with an efficient transfer of information as the main goal

Figure 8.5: First example of process trace

Figure 8.6: Second example of process trace

When it is successful, the process trace produced by the scenario becomes part of the definition of the scenario (That is explained further in Chapter 9.) Process scenario traces can be used in a number of different ways in addition to the determination of the success or failure of the application of the scenario, including initial cost estimates, initial performance estimates, and initial resource estimates for handling the business event represented by the scenario Statistics for a scenario group also can be obtained The information may show a need to modify the process map if the statistics indicate an unfavorable result (e.g., too expensive for the expected return)

representations are intended to accommodate the detailed technical information

necessary for eventual implementation in the enterprise environment

As initially specified in the process map, there is no guarantee that the process is

implementable Environment, technology, and financial constraints may not allow the process to be effectively implemented without changes to the process map or the original process specification Implementation-oriented process representations, which are defined during the design/build cycle, can more effectively indicate when the process cannot be effectively implemented and determine how the process map or specification should be altered

Because the process map format looks similar to a process implementation (build) representation—a workflow diagram—there can be a great temptation to truncate or eliminate the design portion of the design/build cycle and implement the process map directly as a workflow For the purpose of this immediate discussion, a workflow can be viewed as an implementation of a process that utilizes a set of tasks that are sequenced and scheduled by a manager programmed with the appropriate commands (A more comprehensive treatment is presented in Chapters 15 and 24.) A workflow is typically depicted by a diagram showing tasks interconnected with arrows Who wouldn’t want to skip the cost and time consumed in the design activity? Encouragement to perform the direct conversion from process map to implemented workflow comes not only from cost conscious management but also from tool vendors who claim that their products are capable of making the conversion effortless

As tempting as it might appear, the direct conversion almost always fails for a number of

reasons related to the fact that the process map is not a workflow diagram, although the

two graphs appear similar superficially

§ The process map format lacks information essential to designing a

workflow (e.g., detailed functionality, data, and workforce descriptions)

§ The purpose of the process map format is to gain a business-oriented

understanding of the process and the functions, information, and skills

involved It is not intended to be directly implemented

o The process steps are significantly more sequential than necessary Implementing them this way will reduce efficiency considerably

o The process steps generally are at the wrong level for implementation as workflow services or tasks

o The process steps generally are at the wrong level to determine if human or automated implementation is appropriate

o The process steps generally are at the wrong level to achieve significant function (software) reuse

The activities defined for the design/build cycle are always necessary to achieve an effective process implementation If they are not accomplished explicitly and efficiently

as part of the cycle, they will be performed inefficiently as part of some other activity or cycle To paraphrase a familiar saying, “The work that needs to be done is the work that needs to be done.”

8.2.2.1 Logical design

The process map serves as a vehicle to capture, explore, analyze, and specify the needs

of a process from a business point of view To translate that information into a form more suited as the basis for eventual implementation, a more technically oriented

representation of the process must be created and utilized The initial representation is called the logical design The logical design comprises different parts, each emphasizing

a different aspect of the information needed by the implementors It is not necessary for the purposes of this discussion to define the logical design in detail That will be left to the methodology design chapters in Part III

In general, there is no deterministic way to convert from a process map representation of the process to a logical design representation The logical design results from a true design effort Design requires a knowledge of the relevant design principles, a detailed understanding of the methodology involved, an awareness of the specific requirements

of the process, and experience developing logical designs Although the development of the logical design requires knowledgeable human intelligence, a number of guidelines and rules of thumb can facilitate the process

The logical design representation uses a different model structure and is more detailed than the process map representation Therefore, in many instances it is difficult to show

an explicit relationship between process map elements and logical design elements That can cause some concern to staff involved in the development who are familiar only with decomposition techniques for adding detail With decomposition, there is always an explicit relationship between the elements at one level and the elements at a more detailed level The lack of an explicit relationship also causes concern to management personnel who want to ensure that if a change is necessary to a logical design element it

is also reflected in the process map If that consistency is not maintained, the oriented staff and the technically oriented staff will not have similar views of the

business-underlying process That causes great difficulties for process-based enterprise

management and must be avoided at all costs

However, the fact that there may be no explicit relationship between elements of the process map and those of the logical design does not mean that consistency between the two cannot be maintained It does mean that some attention must be placed on maintaining referential integrity between elements of the two representations

Maintaining referential integrity, in general, requires the use of a repository and

associated tools A repository is necessary for a number of other reasons, as explained

in Chapter 4, so that is not an unreasonable requirement In addition, management controls must be in place to require, if necessary, a reexamination and update of the relevant portions of a process map when the logical design with which it is associated changes Of course, the same is true for a process map change The logical design associated with the area of change also must be examined and modified as appropriate

It is possible for the process map to change without affecting the logical design and for the logical design to change without affecting the process map Although such an

occurrence does not appear likely, it does happen in practice because of the rather loose coupling between the two representations It is that loose coupling that provides a number of significant advantages over the usual decomposition techniques

The logical design has five major purposes:

1 To incorporate information that is not available as part of the process map, for example, a user interface (UI) design;

2 To add additional detail to the information contained in the map,

including further specification of the control, data, and functionality required;

3 To represent the process in a format that will provide a more efficient implementation than the process map format will permit;

4 To allow previously defined and implemented functionality to be

reused in realizing the process, greatly increasing the implementation productivity;

5 To factor technical and financial influences into the implementations, which will affect the functions defined to be automated and those that will be accomplished by humans

As a process representation, the logical design must be tested through the use of the scenarios using a procedure similar to that described for testing process maps Because the development of the logical design is not deterministic, that is the only way to ensure that the logical design is a valid representation of the process

8.2.2.2 Physical design

Once the logical design has been developed and tested, an implementable form of the design must be developed That is generally referred to as the physical design The physical design must accommodate the enterprise technical and business environment and specific computing architecture In addition, the physical design also must be able to

be directly transformed into an efficient and effective product resident in the enterprise computing environment To provide for those two needs, the structure of the physical design representation of the process must be somewhat different from the structure of the logical design representation That should not be surprising, given the discussion of the differences between the process map and the logical design representations

To maximize flexibility and reuse of existing functionality, the physical design architecture considered is based on workflow technology The physical design architecture is

considered in two parts: one that is process independent and one that is process

dependent The process-dependent part is known as a workflow, while the independent part consists of software components A workflow implementation utilizes

process-functionality units called tasks A task consists of one or more reusable software

components and provides a part of the functionality needed for completion of the

application An example for an invoicing application would be a function to determine tax amount

The individual tasks necessary to respond to a given business event are sequenced, scheduled, and then routed (assigned) to a specific task performer by a workflow

manager or, alternatively, a workflow engine The workflow engine uses data defined during the logical and physical design process to determine how to reach the desired response to an individual business event Much of that information is contained in a workflow map, which is a representation of the business process By changing the map

and other input data to the workflow engine, the response to a specific type of business event can be altered without necessarily changing the operation of any task The

workflow engine programming is designed to emulate the process

As in the case of the process map and logical design, the physical design also is a representation of the process As such, the physical design must be tested by using the scenarios in a fashion similar to that described for process maps and the logical design

8.2.3 Operate cycle

The operational process implementation is the representation of the process that is used

to respond to real-life business events As a process representation, it also should be tested through the use of scenarios before being placed in an operational status,

although a separate prototype obviously does not have to be defined on which to

perform the tests

The implementation representation structure is based on the physical design

representation discussed in Section 8.2.2.2 The implementation format must allow a great degree of flexibility With that flexibility, process updates required by the changing business climate can be made quickly and accurately In addition, of course, the

implementation must be an accurate reflection of the intent of the process The

implementation consists of five major parts: tasks, workflow manager or engine, workflow definition, workflow instance, and operational statistics

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 that business event Initially, the workflow instance contains 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 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 tasks necessary for a specific workflow instance are sequenced, scheduled, routed, and monitored by a workflow engine That engine is a software product capable of interpreting workflow business rules that specify how the available tasks are to be

utilized in responding to a particular business event

When a workflow instance requires a service or task to perform a function, an instance of that service or task is formed that is then associated with that 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 functionality is needed for many different business events or multiple occurrences of the same business event

As part of its function, the workflow engine collects statistics on the defined metrics of the workflow instances, including the associated service or task instances The statistics are used in the manage cycle to determine how effectively the process implementation is functioning and what, if any, changes should be considered

8.2.4 Manage cycle

Once the workflow (process implementation) has been deployed and becomes

operational, it must be continuously examined and adjusted to ensure that the current workflow representation continues to represent the intent of the process properly

Statistical data produced by the workflow engine are analyzed along with information produced by other means, including customer comments or complaints, employee observations, operational expenses, and equipment costs

The analysis usually is performed by the same SMEs (or others with similar knowledge if the original individuals are not available) who helped formulate the various process representations during the first development cycle If the analysis indicates that changes should be made, the proper subcycle is invoked and a determination as to how the

representation(s) of that subcycle should be altered to meet the new needs The change process then proceeds in the same way as the original design effort

The management of an operational process implementation as part of a comprehensive implementation methodology is presented in Chapter 26, which discusses the analysis and other activities that ensure that the process remains effective

8.3 Quality considerations

Current industry-accepted approaches to ensuring that a quality product or service is delivered to the customer all revolve around a process-based paradigm Because of past problems in trying to define quality (which is more or less an impossible task), the

currently accepted approach is to examine the process that produces the product or service and determine if it is defined, consistent, and effective Each of the three major approaches to making that determination utilizes somewhat different criteria and

emphasizes different areas, but they probably have more similarities than differences Although an indication of the role of process in current approaches to quality is

appropriate to the scope of this discussion, a detailed examination of individual quality approaches would not add a great deal to the presentation Comprehensive

examinations of each of those approaches can be obtained through other publications (see the bibliography at the end of this chapter) Only those characteristics and

definitions of the major process-oriented quality methods that are necessary to indicate how process is considered are listed Table 8.2 contains brief descriptions of the three major approaches: ISO9000, Malcolm Baldridge, and the Software Maturity Model The first two methods are intended to examine general enterprise processes, while the third

is specifically intended for the software development process

Table 8.2: Major Process-Based Quality Approaches

Approach Purpose Developer Overall

Structure

Standards Organizatio

n (ISO)

Relies on a series of detailed audits to determine

if the processes utilized in a number of specified enterprise areas, including the production

of products and

services, are documented; perform

in the way the documentation indicates; are effectively monitored

so that

Table 8.2: Major Process-Based Quality Approaches

Approach Purpose Developer Overall

Structure

problems are detected; and have a mechanism for change Malcolm

Baldridge

Department

of Commerce

Similar to ISO9000 except that more emphasis

is placed

on the compariso

n of different organizatio

ns rather than compliance

to a standardiz

ed checklist The compariso

n emphasis

is necessary

to select the winners Software Maturity

Model

Self- assessment

Software Engineering Institute

Utilizes a five-layer model that indicates how sophisticat

ed the software developme

nt process

of an enterprise

is The layers are

in the order

of increasing maturity and are defined as follows Layer 1, ad