Business Process Implementation for IT Professionals phần 8 ppsx

Frequently, workflow design activities result in changes to the process map and its defined dialogs.. Once the workflow information has been programmed into the process specification too

Graphical (iconic) interfaces with multiple windows usually are defined in conjunction with drag-and-drop movement of data from one window to another The use of video also

is growing more common The design of specific interfaces is the province of human factors experts who specialize in the identification of effective means of human-machine interaction Although the display of those data is crucial to the success of the final implementation, the most that can be accomplished from an overall methodology

standpoint is to ensure that a specific spiral and associated steps are defined for that activity A thorough discussion of the approaches used in interface design is well beyond the scope of this presentation The emphasis instead is on the assurance that the data will be available to the human role performer when it is needed

17.5.1 Description

The human interface is the mechanism that permits the exchange of data between the human role performer and cluster store As such, it is associated with the cluster and not with an individual dialog If a dialog terminates but the cluster remains active with other dialogs, the data in the human interface could remain even though they were utilized in the terminated dialog That continuity facilitates the transfer of data between dialogs from

a human perspective as well as from an automated one The human role performer could control the availability of data, or the data could be controlled through an

automated means by suitable definition of the actions that read and write data to the interface

Unfortunately, the cluster orientation somewhat complicates the design of the interface because it requires that the designer accommodate any data that could be presented using any reasonable compound scenario Management of a large amount of data becomes a significant design factor in addition to the usual emphasis of the aesthetics of look and feel, which is the traditional approach Because of some of its inherent

limitations another complication is the use of Internet browser technology to provide the interface instead of a proprietary implementation using products such as Motif for a UNIX-based solution or Microsoft Windows for a PC-based solution

17.6.1 Description

The workflow specification utilizes the definition of the process and support dialogs to determine the tasks that are the unit of functionality for the workflow Tasks consist of

one or more dialogs, depending on the control and reporting requirements needed for the workflow Frequently, workflow design activities result in changes to the process map and its defined dialogs That occurs for the same reasons that the specification of the actions also results in the same types of changes The need to define the intent of the process using technical constructs frequently identifies areas where the process map does not provide sufficient guidance as to how the implementation should proceed In addition, alternative ways of providing the same result as specified by the process map occur with regularity Those alternatives can result in more efficient and effective

implementations, but they need to be reflected back to the process map so the business SMEs can be assured that nothing has been lost by the changes

To provide a complete workflow specification, information as to the available workforce, task scheduling, routing methods, and monitoring requirements also must be specified Examination of those needs also may indicate changes to the process map and dialogs Once the workflow information has been programmed into the process specification tool

of the workflow engine being utilized, simulation of the workflow is utilized to determine the operational characteristics of the workflow The results of that simulation almost always are different from those of the simulation performed on the business process This is because the definition of the workflow process contains a great deal more

information than is usually made a part of the process map For example, the simulation may reveal bottlenecks caused by staffing characteristics and not by the inherent

characteristics of the process flow

The workflow implementation also needs to be tested using the scenarios defined for the process That ensures that no inherent process functions have been compromised by the workflow representation and implementation If testing shows that problems do exist, they may be able to be corrected by changes in the workflow, or just as likely they may need changes to the process map

17.6.2 Prototype

A workflow prototype is used as part of the development of the workflow specification and to ensure that all the needed information is available The prototype uses stubs for the tasks if they are not available All other information needed by the workflow is

programmed into the workflow engine

The elements that are integrated during spiral 6 are:

§ The dialog infrastructure, including common support actions;

§ The cluster store;

§ The final human interface designs;

§ Implementation-specific actions that have been defined for the dialog;

§ The workflow engine and associated program;

§ The client platform;

§ The software components required by the actions;

§ The server platform(s);

§ The system software;

§ The network that connects the client and server platforms;

§ Other support software

Prior to the integration of those elements, the specified software components must be implemented if they are not already available It is anticipated that most of the

components will be available and that only a small number of them will need to be developed for a given project For the initial projects developed using this methodology, that assumption may not be true and a significant number of software components may need to be implemented

17.7.1 Description

Spiral 6 is used to assemble, demonstrate, and evaluate the operational characteristics

of the process implementation If problems are encountered, the malfunctioning

components are identified, and, depending on the cause, one or more spiral types are invoked and utilized to determine and implement the proper changes

The initial transversal of spiral 6 is utilized to create an assembly prototype that behaves

in an operational sense exactly like the final system Some components may be stubbed because they have not yet been implemented or the use of an operational system is deemed to be critical in this phase However, the characteristics of the implemented software components are maintained by the stubs (e.g., delays, data types) Subsequent iterations of the spiral are used to fine tune the system characteristics and determine if changes are warranted Fine tuning in this context includes the following:

§ Launch criteria changes;

§ Error handling and recovery procedure changes;

§ Minor modifications of the screen or other aspects of the human interface design;

§ Rehoming of specific action transactions;

§ Addition of statistical or management actions;

§ Changes in the specific dialogs that are coresident on the workstation Any of those tuning changes requires the appropriate spiral(s) to be invoked to maintain the integrity of the development and ensure that the appropriate information is

maintained for later use in the operations-oriented improvement spiral

17.7.2 Prototype

The assembly prototype defined for spiral 6 has a structure and functionality that are as close to the deployed process as can be obtained without producing the final deployable implementation This prototype is the last chance for the stakeholders to correct any problems before deployment While it is relatively expensive to correct a problem found

in this spiral compared with fixing problems detected in earlier spirals, it is much less expensive than performing corrections in the field

Because the assembly prototype and the final deployable product are relatively close in structure and function, enumerating the differences and similarities between them helps place each in perspective The assembly prototype has the following characteristics relative to the deployable product:

§ It runs on the same hardware and software platforms as the deployable product

§ Distribution of functionality among servers is the same as the deployable product

§ For all specified software components currently available, the actual

components are used

§ For all other components, stubs with the same interface characteristics are used

§ The network protocols are the same as those that will be used in the

§ All human interfaces are completely implemented

§ The workflow implementation is fully operational

§ Complete documentation may not be available

The assembly prototype also can be the vehicle for initial acceptance testing, training of users, and capacity testing The use of the previously defined scenario set is the basis for acceptance testing

Once the assembly prototype has been evaluated and accepted by the users, there is no opportunity to make additional changes until actual deployment Thus, it is important to ensure that the assembly prototype is evaluated and tested in as many ways as

possible

17.8 Spiral 7: Improvement

The purpose of spiral 7 is to:

§ Deploy the implementation by provisioning all the necessary components on those platforms that have been identified as participating in the

implementation;

§ Finalize and implement the support functions such as documentation, network

or service management, and security;

§ Determine the procedures by which the implementation will be made available

to the affected users (mostly the responsibility of the project management methodology);

§ Monitor the operation of the implemented process by using the capabilities of the workflow engine and, depending on the results, identify and implement changes that can improve the operation of the implementation

The improvement spiral is also used as the initial mechanism to address changes to the process that arise because of business needs that occur independently of the process operation That would include such items as regulatory changes, new product offerings, competitive responses, and changes to the organizational structure of the enterprise because of acquisitions or divestitures

17.8.1 Description

The deployment functions of spiral 7 require significant cooperation with the project management methodology because it is that methodology that is responsible for the scheduling of the deployment and the notification of availability to selected users It is also responsible for the dissemination of any documentation to the end users, operations personnel, and the help desk, if one is to be utilized

The monitoring and evaluation function generally is accomplished through the

information obtained by the workflow engine during its normal operation The data obtained include timing of all the workflow tasks and components as well as any specific data selected by the workflow designers The operational data can be used in

conjunction with the simulation results obtained during the associated development spirals to determine what improvements are possible or feasible Improvements may be identified that will not be implemented because they are too costly in absolute terms or for the improvements that would be obtained

When process changes are required because of business needs not directly related to the operation of the process, the invocation of the spirals needed to effect the change is considered to be through the operation of the improvement spiral That is done because the needed changes may not require alterations to the process map or dialogs that would be assumed if the initial development entry point was used That assumption also provides the desirable continuity between the development and maintenance phases of the implementation It is useful to assume that both phases utilize the same fundamental methodology

17.8.2 Prototype

The prototype is the operational process implementation As such, it is not a true

prototype, but to the extent that it needs to be monitored and changed, it can be viewed

in somewhat the same light as the prototypes associated with the other spirals

17.9 Summary

Each spiral covers a major aspect of a process implementation The spirals are

connected in such a way that the effect of a change, regardless of the spiral in which it occurs, can easily be determined for all spirals That prevents a change from causing an undetected (until deployment) problem in another area of the implementation Each

spiral also incorporates the same general approach, which helps to integrate the different spirals into a unified methodology

Every spiral will be traversed many times during an implementation Although an initial order is defined for discussion purposes, the actual order will differ considerably over the course of the development In fact, there is no specific order to the spirals after the initial startup of the implementation Revisiting any spiral does not mean that a problem has occurred It only means that additional information needs to be incorporated in the

implementation For staff experienced with other types of methodologies, that can be a difficult transition to make

Each step in the methodology is examined in detail in the next nine chapters To some extent, the overall operation of the methodology as defined by the spirals is hidden

during those presentations To maintain as clear an understanding as possible, the

reader should remain cognizant of the placement of each step in the methodology as its functions and requirements are defined

Selected bibliography

Boehm, B W., et al., “Software Requirements Negotiation and Renegotiation Aids: A

Theory-W Based Spiral Approach,” Proc 17th Internatl Conf Software Engineering, Seattle, Apr

23–30, 1995, pp 243–253

Boehm, B W., “A Spiral Method of Software Development and Enhancement,” IEEE

Computer, Vol 21, No 1, 1988, pp 61–72

Viravan, C., “Lessons Learned From Applying the Spiral Model in the Software Requirements

Analysis Phase,” Proc 3rd IEEE Internatl Symp Requirements Engineering, Annapolis, MD,

If multiple processes are to be considered simultaneously because they are closely

related, each process is still handled independently The connection between the

processes is the identification of common identical (or nearly identical) sets of process steps and interconnection points

Determination of the requirements is accomplished from a business perspective The focus is on the process, which is represented by the process map and its associated information, including information flows, scenarios, business rules, and operational characteristics The operational characteristics include the following items:

For simplicity, references to the process map are assumed to also include that

associated information The process map is used as the main communication vehicle with the business stakeholders to ensure that the process accomplishes the intended business goals and objectives Although some amount of work in that area may have been performed before step 1 is invoked, the rigorous analysis process and creation of

an affiliated prototype as part of the step activities help to derive considerable additional information about the process and its component steps

The technical perspective focuses on the ability of the process map to be translated into

a structure that is implementable using available technology The analysis is started in step 1 and continues throughout the methodology If, during any phase of this analysis, it

is determined that the implementation is impractical or impossible, step 1 must be

revisited and the process map changed appropriately

If the business process already exists and is in operation in the enterprise, it is usually suggested that the current operation of the process be documented in an “as-is” process map before starting the process reengineering or development of the “to-be” process map The to-be map documents the process as the enterprise wants it to operate If several as-is processes exist because relatively independent organizations of the

enterprise have developed local versions of the process, it usually is not worth the effort

to document all those variations In that situation and the case in which the process is new, the implementation starts with the to-be map The discussion that follows assumes that the to-be map is being developed, although many of the concepts could be applied

to the as-is map if it is useful to perform that exercise

18.2 Preconditions

The information and resources that must be available prior to invoking step 1 depend on the entry path utilized:

§ Initial entry point: Process definition (high level); organizational commitment;

resource allocation (SME time);

§ From step 2, “Identify dialogs”: Detailed process map; set of scenarios; initial

dialog determination; process prototype; questions or problems concerning process;

§ From step 3, “Specify actions”: Detailed process map; set of scenarios; dialog

determination; process prototype; initial action specification; action

prototype; questions or problems concerning process;

§ From step 6, “Determine workflow”: Detailed process map; set of scenarios;

dialog determination; process prototype; initial action specification; action

prototype; initial workflow specification; workflow prototype; questions or

problems concerning process;

§ From step 8, “Deployment and operation”: Operational process

implementation; process measurements and statistics; all implementation information

18.3 Description

This description of step 1 assumes that the step was entered from the initial entry point because that requires the most effort and associated activities If that is not the case, the process map already exists, usually along with a considerable amount of other

information, and is expected to be altered in some fashion When that type of entry occurs, the existing process map information is valid, but it must focus more on the specific difficulties that caused the step to be revisited That may require fewer or

different personnel at the sessions than indicated in Section 18.3.1 In addition, the activities should accommodate the additional information available That may lift some restrictions given for the initial development of the process map (e.g., the restriction against discussion of existing system functionality)

18.3.1 Facilitated sessions

With those caveats in place, the step description continues The initial development of the process map is usually performed in a series of facilitated sessions The sessions should include the following participants:

§ A set of business SMEs who collectively can address all aspects of the process;

§ A facilitator familiar with the process approach to requirements gathering;

§ A methodologist knowledgeable in the entire PRIME methodology who can determine if the sessions are producing acceptable results;

§ Technical SMEs who will implement the defined process Because not all

of the information discussed will be documented, it is necessary to have

a set of development personnel who can get a feel for the process and what it is intended to accomplish

Several rules should be followed during the sessions to obtain a version of the map that truly represents the desired process There are others, but only the major principles that need to be followed are listed here

1 Specify only the activities that are desired, not the means of current implementations Statements such as “then system X is used to obtain data Q” are not allowed It easily could be that system X is the

problem, and its functioning should not be allowed to influence the process specification Connection of the process to available functionality occurs later in the implementation

2 For the same reasons, do not make references to CRT screen layouts

or data formats They tend to unduly influence the process specification process; as in the case of legacy systems, they may be a problem, not the solution

3 Develop high-level scenarios prior to the process map so they can be used in the development of the map Although scenarios developed after the map is formulated still have significant value, more value is obtained if they are available prior to the start of map development

Scenarios help determine the scope and general characteristics of the process, which can greatly facilitate the process specification

activities

4 Eliminate protracted discussions about inconsequential items There is

a tendency to argue over names and wording The problem should be noted and the session continued Because they are easier, these types of discussions often substitute for ones with real content

5 The same SMEs should participate throughout the process

development Substitutions cause a lack of continuity and can be the source of inefficiency and unnecessary controversy This rule is sometimes difficult to enforce, but it needs to be forcefully addressed

6 The map must be available in readable form as its development

progresses That can be accomplished via paper or projection Pattern recognition is an important part of the map development, and the current state of the map is necessary to provide the means of that type

of informal analysis

7 Develop the map as a flat, one-level diagram Do not utilize a

decomposition procedure, such that there is a series of maps, each with increasing detail Although the flat-map principle is controversial, the author feels that the advantages far outweigh the disadvantages (e.g., map size)

§ Specification of a high-level map with supersteps that represent other steps in a lower level map can hide a significant amount of the detail necessary to determine

if the process map adequately represents the process

§ It facilitates use of the human ability for pattern recognition

§ Coordinating all the maps needed for a given process can require a significant amount of configuration management time

§ Deciding the appropriate number of levels can evoke considerable discussion and is an unnecessary distraction

§ Maintaining a consistent level of abstraction throughout the map is facilitated

§ It is easier to apply the analysis rules outlined in this and later chapters

Depending on complexity, development of the process map can take several weeks It is not desirable to force the sessions to an early conclusion, because the result represents the basic requirements of the resultant implementation (both manual and automated functions)

Once the process map had been specified to the satisfaction of the business SMEs, the map (requirements) is considered to be sufficiently complete and stable so that the design and implementation effort may continue It is, of course, almost certain that changes to the requirements will become evident at subsequent spirals and steps in the methodology When that occurs, step 1 will be revisited, so the changes can be

accommodated and agreed to by all stakeholders

18.3.2 Process map structure

To facilitate the following discussion, a continuing example is used based on the process map shown in Figure 18.1 The map provides an adequate degree of complexity while not overburdening the reader with detail

Figure 18.1: Example of a process map

The process map represents the process by defining the functionality or activities of a set

of discrete steps The steps are placed in precedence order by connecting lines that indicate the allowable paths through the process The steps are placed on the map in rows; each row represents a role that has been assigned to perform the activities of that step A step cannot be in two rows (roles) simultaneously An organization may also be assigned to the rows as shown, but that is an optional designation and is not needed for the proper functioning of the step

In many cases, the order of the steps is somewhat artificial and could be changed without affecting the operation of the process From an implementation perspective, such changes sometimes are necessary for efficiency or because of the availability of

information

As a part of the map structure, each step must have the associated information flows defined The flows represent the information needed to perform the defined activities of the step and should conform to the models and principles presented in Chapter 11 The direction of each flow must be indicated, along with the datastore that is the source or sink for that information The datastore could also be cluster store when the data are not persistent Incorporation of information flows into the map is illustrated in Figure 18.2

Figure 18.2: Step information flows

In Figure 18.2, the information flows are shown by the thick lines at a 45-degree angle to the step, and the arrows indicate the direction of the flow The numbers indicate the identification of the flow The datastore names have been omitted for clarity Even with that omission, the diagram is getting quite crowded and difficult to read, which is why it is suggested that the information flows be documented separately from the map

If too many information flows are defined for a step, the step should be partitioned to reduce the complexity As a rule of thumb, if there are more than four different data flows, the step should be split Such a split will not change the implementation but should make it easier to understand the process from the business perspective In the example map, there are no places where that needs to be addressed Once the information flows have been determined, it is possible to analyze the complete structure to determine its consistency

18.3.3 Consistency checks

Two checks are part of the initial consistency examination The first is to determine if the outputs of each step are used later in the process and if not, where and why they are needed The second check is to determine if all the information needed in a step is available when that step is reached The first check is relatively easy to perform on a static basis using a dataflow (information flow) diagram The second check requires the use of scenarios and animation techniques and must be performed on a dynamic basis (addressed in Section 18.4)

The output information analysis is accomplished by reordering the steps according to the availability of the information in the information flows If information is available from sources other than previous process steps, it will not alter the map structure for the purposes of this analysis The resultant step reordering for the example is shown in

Figure 18.3 and is a form of the classical dataflow diagram (precedence is based on data availability)

Figure 18.3: Diagram of step information flow

Figure 18.3 illustrates some problems that might become evident during this analysis Process steps 2 and 12 do not appear to have successor steps from an information perspective, and there is no indication that they are end steps Other potential problems, which are not illustrated in the figure, could be steps in an order different from that shown

on the original process map or steps that are precedence connected but should not be There may not be a problem associated with any of those constructs, but they do

indicate areas that need to be investigated On the basis of a reexamination of the specified information flows and discussions with the SMEs as to the intent of the steps in question, any questionable areas should be considered and changes made as

necessary

In this case, it is discovered that some information flows are indeed missing and that process step 2 should precede step 6, and step 4 (not 12, as might be assumed at first glance) should precede step 11 from an information perspective The information flows that were added may have been inadvertently left out, or an activity necessary for the step may have been omitted along with its needed information flow(s) Note that step 12 still does not have a successor step That may be because IF6 is used in another

process and is not needed in this process The step information precedence diagram is then updated by adding the three missing information flows That results in the diagram

in Figure 18.4, which would then be used for any additional analysis The added flows also would be reflected in the original process map, which is the basis for the ongoing implementation That is shown in Figure 18.5, where asterisks indicate added flows

Figure 18.4: Updated step information flow diagram

Figure 18.5: Revised process map

In addition to the information flow changes, some steps in the original process map also may be reordered to agree with the information flow reordering, if the SMEs deem that doing so is appropriate (e.g., step 3 performed before step 2, as permitted by the

information flows) For the purpose of the example, it is assumed that the original order

of the steps remains

This type of analysis may need to be repeated several times during the map

specification Any change may give rise to other changes, and long cascades of changes are not uncommon during step 1 (or other steps of the methodology)

18.4 Prototype

A process prototype is utilized as an aid to verify the business requirements represented

by the process map The prototype is an embodiment of the map along with the

information flows and operational characteristics Although the scenarios will be used in conjunction with the prototype, they are not considered a direct part of it The

embodiment can be simply a map drawn on paper and paper copies of the other

information The use of a design tool for the embodiment facilitates use of the prototype,

as will be evident as the discussion continues

The prototype is used for three different activities during map development The first is to animate the process through utilization of the scenarios For each scenario of interest, the process is initiated and the path through the process is determined by the scenario The path through the scenario is simply the step sequence required to address the scenario Each step in the scenario is checked to ensure that the sequence is logically correct (e.g., no missing steps or premature termination) and that each step has the necessary information to perform its intended function The time and cost of the path also can be calculated if those values are available for the steps

As an example of the information flow analysis, assume that a scenario produces a path for the example process shown in Figure 18.6 All the steps have the needed information flows available when they are reached Now assume that another scenario produces the path shown in Figure 18.7 Checking for information flow availability indicates that IF8 used by step 10 is not available That occurs for the scenario being employed because step 6 was not reached previous to step 10 and it is that step that produces IF8 The resultant examination of the reasons for the inconsistency can reach several

conclusions, depending on the specific conditions involved IF8 may be used by step 10 only if it is available, and the lack of that information flow does not indicate a problem

Figure 18.6: Consistent information animation result

Figure 18.7: Inconsistent information animation result

The analysis also might show that IF8 is required and that the path from step 12 to step

7 is wrong That requires the process map to be altered in some fashion to fix the

problem For the purposes of this discussion, it is not necessary to speculate how the map may need to be changed; for the continuing example, it is assumed that IF8 is optional

Any problems are corrected through changes to the process map and the animation performed again Changes to the process map should be made in accordance with the flow of activities described in Section 18.5 That helps ensure that the changes do not have any unintended consequences Also, as shown in the description of the activities, animation is an integral part of process map development

The second use of the process prototype is simulation Simulation differs considerably from animation in its focus and the results obtained While animation considers scenarios one by one, simulation considers an aggregate of all scenarios on a statistical basis That usually is accomplished through the use of a discreet event simulation tool

Probabilities are assigned to each decision, and the process is initiated according to the statistics of the assumed load The result is aggregate step utilizations, queue lengths,

average path execution times, and costs (if the information is available) The purpose of animation is to determine if the process is meeting the needs of the business events that cause it to be invoked The purpose of simulation is to determine the operational

characteristics of the process according to the assumed load Simulations also should be

a part of process map development

The third use of the prototype is to convey to the business stakeholders (other than the SMEs involved in the process map development) the intended operation and

characteristics of the process Although this activity is important in showing progress toward the availability of an acceptable implementation, it also is important at this time to get the initial backing of the stakeholders It is the stakeholders who eventually

determine the success or failure of the process implementation In addition, they can offer valuable insights throughout the implementation The business stakeholders need

to be involved with every prototype developed during the methodology spirals, even if the involvement is only for a brief demonstration

18.5 Activities

There are 13 individual activities in this step, arranged according to the sequence

diagram in Figure 18.8 The activities in step 1 can begin as soon as a process has been identified Any process that is currently being processed using this step cannot

simultaneously be processed by any other step of the methodology That is necessary to keep a reasonable degree of stability in the implementation procedures

Figure 18.8: Activity sequence diagram

Any problems discovered during any of the activities must be res olved by altering the process map or scenarios involved After that is accomplished, the activities must again

be performed in the sequence indicated This is a form of regression testing that ensures that a change to fix one problem does not inadvertently cause a different problem In most cases, the additional work involved is relatively small, but the increase in quality is quite large

The following are brief descriptions of the individual activities needed to produce the results expected from step 1 in the methodology

1 Hold facilitated sessions to obtain an as-is process map if needed If only

one process is involved, then this could be an excellent source for

identifying problems and resolving them through a reengineered process

If there are multiple current versions of the process because each

individual organization or geographical location using the process

performs it in a different way, this may not be a feasible activity and

should be skipped

2 Hold facilitated sessions to obtain an initial or revised to-be process map

This activity is the core of step 1, and the quality of the final result

depends on how well it is accomplished The facilitator should be an

expert in process design and the PRIME methodology in addition to

being an experienced facilitator The abstraction level of the map should

be such that the process can easily be explained to a business-oriented

individual unfamiliar with the process The map should not contain any implementation details, such as applications or systems that will provide some of the needed automation functionality The emphasis of these sessions should be on specification of the process steps and their relative sequencing Following activities apply some rules and guidelines

to the map steps and begin the analysis that ensures the process design

is feasible and implementable

3 Identify or revise scenarios to be handled by the process The scenarios

help determine the design of the process and are used throughout the implementation to ensure that the implementation can adequately address the needs or all the scenarios Scenarios are the major way of testing the results of each methodology step as well as the final

implementation The development of the scenarios should be specified in parallel with the development of the process map

4 Identify roles and role characteristics as necessary using the principles outlined in Chapter 10 For each role utilized in the process, identify the

characteristics required to perform that role and the characteristics of the user population targeted to perform that role It is possible that there will

be multiple user populations identified for a single role In that case, the characteristics of each population must be carried forward The

characteristics will be utilized in the design of any necessary human interfaces for the dialog Different interfaces may be defined and

implemented for each user population (e.g., expert and casual

performers of a role)

5 Decompose steps assigned to more than one role If multiple roles (as

opposed to the same role with different performer characteristics) are identified as performers of a single process step, decompose that step into smaller steps until only one role is identified for each step Update the process map as required

6 Decompose steps with more than four information flows A process step

with more that four individual process flows (in and out) usually is not consistent with the abstraction level at which the map should be

developed The step should be partitioned until each partition has four or fewer information flows, unless there is a valid reason that the step requires a larger number of flows In that case, the reason should be documented as a part of the step ancillary information

7 Reorder steps according to the availability of information The reor-

dering diagram exposes potential inconsistencies with the step ordering and information flow specifications Take into consideration any

documented temporal or state constraints on the sequential execution of specific process steps (e.g., a particular process step cannot start until after 5:00 P.M on any given workday, even though its information requirements have been satisfied, because it is performed by the night clerk role) Update the process map as necessary

8 Construct or update the process prototype The prototype can be a

designated printed process map that is executed manually, or it can be implemented through the use of a suitable automation tool The same holds true for the scenarios They can exist in paper form or through the use of an automated tool It is desirable that a single automated tool be available for scenarios and maps to facilitate the animation procedures It also would facilitate the comparison of different animation runs

9 Test prototype using animation and scenarios Using each identified

scenario, animate the process map Ensure that the scenarios are sufficient to produce a visit to each of the steps in the map Also ensure that the process produces the desired effect for each scenario

Determine any changes to the map or scenarios that need to be made

10 Use prototype for simulation if considered useful If the process requires

simulation to determine its suitability, develop the simulation parameters from the information available and program the selected discrete event simulator Simulation may be indicated if the process is extremely time

sensitive and the statistics of the business events involved are known or can be reasonably estimated Even if the process is simulated at the

process map level, it can be used only as an initial indicator because the implementation of the process can significantly alter the results, either

positively or negatively

11 Demonstrate the prototype to stakeholders Arrange a session with the

stakeholders to observe the action of the initial or revised prototype and determine the conformity of the prototype operation to the needs of the business and the individual stakeholders

12 Obtain required approvals If approvals are needed to continue beyond

step 1, they need to be obtained before continuing The process

prototype, the opinions of the stakeholders, and the hard deliverables

from this step (process map, scenarios, animation results, and simulation results if performed) should be sufficient to demonstrate the suitability of the process definition and the ability to proceed

13 Enter process map specifications into repository All information obtained

as a result of step 1 should be entered into a corporate repository where

it is available for future needs Because maintenance is considered an

integral part of the methodology, this information may be needed for a

considerable length of time, and it may be useful to individuals other than those involved in the initial implementation

18.6 Linkages to other steps

Step 1 is the first step invoked when the PRIME methodology is utilized in the

development of a process implementation It also must be reinvoked whenever there is a projected change in the process map In addition, the process prototype needs to be updated and the changes in the affected processes verified with the users The change can occur as the result of information obtained in another PRIME step or because of a change in the business environment

The transition from this step almost always will be to step 2 After step 1 has been completed and the process prototype has been specified to the satisfaction of all

involved stakeholders, it is necessary to consider the dialog definitions, either for the first time or on an updated basis

Step 1 also may serve as the transition step from any spirals and possibly all other steps using the concept of implicit spirals Any problems uncovered during the invocation of subsequent steps may be refl ected as changes to process definitions It is also possible that process changes may have to be recommended as implementation constraints are uncovered Process changes generally result in an updated process prototype and need stakeholder validation of the changes

18.7 Postconditions

In general, steps are terminated in one of two ways The first way is when a condition is found that requires another step to be invoked before the current step can continue Such precompletion exit is not an abnormal termination, as might be suggested It actually is quite normal and merely a recognition that not all the necessary information is available With this type of termination, the current step is reinvoked when the condition causing the termination has been removed Reasons for a precompletion termination are specified in the appropriate activities of the step

Because defining/refining the process map is the first step of the methodology, it cannot terminate before completion except to stop the entire implementation Although that is always a possibility for any step, it does not have to be explicitly considered as part of the discussion If a problem is found during the activities of the step that prevents

continuing, a transfer can be made to the beginning of the step but not to another step Step 1 is the only step that cannot have a precompletion termination

The second type of termination occurs when the step completes and produces the desired output That type of exit is not a guarantee that the step will never be reinvoked

It is only an indication that for a specific invocation, all the information necessary to produce the defined step output is available Depending on the results of steps that follow, the current step may be revisited (possibly many times) The postconditions presented in this section are those that are necessary for the step to complete and terminate This definition of postconditions is true for all steps in the methodology but is not explicitly indicated in the discussions in the remaining chapters The postconditions for step 1 are presented in the following list

§ All step activities have been considered at least once For an update, only the affected steps and activities need to be addressed

§ The process prototype is available

§ A robust set of scenarios is available

§ Appropriate animation (and simulation, if indicated) of the process prototype has been performed using the scenarios

§ The business stakeholders have been involved as needed

§ All relevant information has been entered into the appropriate repository and updates verified

§ Any necessary approvals have been obtained

At the conclusion of step 1, all affected stakeholders must agree that the process, as it currently defined and represented, is the best that can be accomplished prior to utilizing the other methodology spirals to provide additional details and analysis The information may indicate that further refinement of the process and its representation is necessary

Selected bibliography

Batson, R G., and T K Williams, “Process Simulation in Quality and BPR Teams,” Proc 52nd Annual Quality Congress, Philadelphia, May 4–6, 1998, pp 368–374

Damelio, R., The Basics of Process Mapping, Quality Resources, 1997

Galloway, D., Mapping Work Processes, Milwaukee: ASQC Quality Press, 1994

Hunt, V D., Process Mapping: How to Reengineer Your Business Processes, New York:

John Wiley & Sons, 1996

Chapter 19: Step 2: Identify dialogs

19.1 Purpose

Step 2 performs a series of partitions of the process map The partitions are designed to identify the largest sets of process steps that can be integrated and performed in a continuous time period That is important in determining independent implementation units, workflow tasks, and needed reusable components The results of each partitioning step should be discussed with the SMEs in an extension of the facilitated sessions used

to develop the process map That ensures that the partitioning results are consistent with the intent of the process map developers and that any problems that result can be quickly identified and corrected

19.2 Preconditions

The following preconditions are required before work on the activities of step 2 can be initiated It also is assumed that any result from a previously executed step or spiral can

be used to provide guidance or background information in addition to those items

explicitly listed in this section Although this step is labeled as step 2 and always follows step 1, it is possible (and likely) for this step to be reinvoked after other steps have been executed Information developed in prior steps may be of use in the reinvocation of this step

§ Process prototype;

§ Scenario definitions;

§ Process step operational information;

§ Other applicable information gathered during process definition

All that information should be available from a repository used to contain all the

information identified during the development of the process and any preceding process specifications

19.3 Description

The purpose of partitioning is to identify groups of process steps that can be

independently implemented and utilized That results in smaller and more efficient software implementations and forms the foundation for a significant amount of reuse

These independent units are called dialogs

A partition consists of a set of steps from the process of interest There are five types of partitions that are sequentially produced The final set of partitions is dialogs A

connection between partitions is said to be a transition

Each partition is produced according to a set of rules Some rules are applicable to all partitions, while others are specific to individual partition types The following list contains those rules that must be followed by all partitions

§ A partition contains one or more process steps In rare instances it can

contain all of the steps in a process if all of the other rules are followed

§ A partition cannot contain noncontiguous steps Only one step in a partition is allowed to have an input that does not come directly from an output of

another step in the partition Multiple such steps are allowed if they have

the same external input

§ A partition must contain the maximum number of steps that does not violate

any of the other applicable rules

§ Partitions cannot overlap A process step can be part of one and only one

partition of a given type

§ All steps of the map must be included in some partition of each type

§ An output from a partition can occur at the output of any step in the partition

§ A partition may have multiple outputs

§ All partition transitions must be specified and documented (e.g., parallel

execution, and, exclusive or)

19.3.1 Organization partitions

All the partitioning examples in this chapter are based on the process map depicted in Figure 18.5 The organization partitioning is optional It identifies groups of contiguous process steps in a process map that are performed by a single organization Each of

those groups is called an organization partition, and the procedure is illustrated in Figure 19.1 Organization partitions conform to the rules for all partitions and a specific rule that states that organizational partitions cannot cross organization boundaries The inputs and outputs from each partition are transitions to other organizations Each organization

partition is identified by the letter O and a unique arbitrary number As further

partitionings are performed, the identifier is kept to indicate the derivation of the final partitions