What tool can we use to diagram the process as

Modeling the behavior of business processes

Process diagrams, called “flow diagrams” by TOGAF, are used to model the sequence of activities within a process. Process modeling formalizes practices and describes the manner in which they should take place.

Flow diagrams represent process participants, activity sequences, information exchanged during a process, and trigger events. Processes can also detail the different checks, choices, and coordinations that exist within a sequence of activities.

Processes can be modeled to different degrees of detail according to the goal of the model in question. In the example shown in Figure 8.11, the model is extremely general. Chapter 12 goes into more detail on the techniques used to model business processes.

Process

A process diagram consists of activities, events, and gateways, which a sequence flow puts in a flow sequence. Activities, events, and gateways are summarized under the term flow object.

Figure 6.1 describes in the BPMN how the car rental company SpeedyCar creates a monthly statement for a customer. The monthly statement includes all drives of the selected customer.

Comment

In order to name the individual BPMN elements in the diagram, we used a lot of comments. Comments are indicated with an open square bracket in BPMN and can be linked with other model elements using a broken line—the association.

Start Event

The start event marks the start point of a flow. Events in BPMN can have a concrete characteristic that indicates the circumstances under which an event occurs, the trigger. Timer. In this example, the process starts with the start event end of month, with the time trigger. As soon as the end of the month is reached, the incoming event starts the process, creating monthly statement for a customer. A time event is triggered at a concrete point in time—for example, 8/2/2014, 02:14:00 A.M.—or by a recurring time event—for example, at the end of the month. Message. Message is another event trigger. For example, an incoming phone call or an incoming e-mail of the message trigger can start a process.

Token

As soon as a start event occurs, the process is instantiated and a token is generated for the outbound sequence flow. A token is some sort of virtual marble that rolls through the process. In contrast to a real marble, the token can proliferate or be destroyed. The instance of the defined process ends when the last token is resolved.

Parallel Gateway

In Figure 6.1, the token runs from the start event to the tasks, determine customer to be invoiced, create invoice, and post invoice, via the sequence flow. After the post invoice task, the sequence flow enters a parallel gateway. The gateway splits the sequence flow into two parallel lines, which doubles the token. Each sequence flow receives a token.

The BPMN offers two options to illustrate parallel flows: explicit, using a parallel gateway or implicit, using several sequence flows that exit an activity. In both cases, each outbound sequence flow receives a token and triggers the tasks, send invoice or collect direct debit (Figure 6.2).

The parallel gateway can split or synchronize parallel workflows. In the synchronization, several sequence flows lead into the gateway and only one leads out (Figure 6.3). The gateway waits until a token is available at every incoming flow. Only then are the tokens joined, and the flow continues.

In this example, the parallel activities, send invoice and collect direct debit, are synchronized in a parallel gateway. Only when the two tasks have been completed, does the flow continue.

End Event

In Figure 6.1, the token then proceeds to an end event, which marks the end of the process and destroys exactly one token. Because no other token is active, the create monthly statement for a customer process is completed.

Now, let's enhance the process: In addition to direct debit payment, credit card payment is also possible in future (Figure 6.4).

Exclusive Gateway

An exclusive gateway is used to express that exactly one alternative can be selected. Customers can pay either with credit card or direct debit, but not with both (Figure 6.4).

In an exclusive gateway, the token runs along the sequence flow whose condition is met first. As the name of the gateway already suggests, exactly one sequence flow is selected exclusively.

After direct debit or charge credit card, the sequence flow is merged with an exclusive gateway again. As soon as one of the two tasks is completed, the token migrates to the gateway and passes it without any delay.

As an alternative for the exclusive gateway, the sequence flow can also be merged in an activity. If several sequence flows end in an activity, each incoming token triggers the activity.

As soon as direct debit or charge credit card has been executed, the display invoice type activity starts (Figure 6.5).

Conditional Sequence Flow

Instead of using the exclusive gateway, you can also illustrate an alternative using the conditional sequence flow. It is identified with a small diamond directly at the activity. The behavior of the two notations is identical, if associated conditions are mutually exclusive. If the customer requests an e-mail delivery, as illustrated in the example of Figure 6.6, the create e-mail with invoice activity is executed.

If several conditions are true, all associated sequence flows receive a token. The flow is parallelized, depending on the conditions. This is the case if the customer has selected e-mail delivery and postal delivery.

Default Flow

In case of an exclusive gateway or a conditional sequence flow, you can specify a default flow, additionally. It receives a token if none of the conditions specified is true. You can use the default flow to prevent that the flow gets caught in a branch (deadlock; Figure 6.7).

Hierarchization of Processes

In order to not have to model a complex process across entire walls (in the literal sense), you can subdivide processes. In Figure 6.8, send invoice is shown as a subprocess. The “+” sign indicates that the send invoice subprocess was modeled in collapsed form. If you expanded the subprocess, the modeling for the subprocess would be visible in BPMN as part of the parent process.

Data Objects

Processes and business objects are closely intermeshed in business processes. A process works with business objects, that is, it can create, change, or destroy this information, or available objects. In BPMN, business objects are modeled as data objects. Provided that an activity was modeled using an inbound data object, it is not executed until the data object is available.

State

In Figure 6.9, the invoice data object in the created state enters the send invoice activity and uses it, which is indicated by the data association connector. The activity then changes the data object by setting the state to sent.

Pool

Business processes often involve roles. Pools are used to subdivide a process according to different organizations. Examples include customers, enterprises, or suppliers. Figure 6.10, process damage report, includes three pools: driver, SpeedyCar, and the person responsible for booking. Black box. If the flow within a pool is not relevant, the pool can be displayed as a black box—like for the person responsible for booking. The internal flow is hidden in this case.

Message Flows

Every pool is responsible for its process and can communicate with other pools via message flows. The driver sends SpeedyCar a damage report message. The incoming message starts the process in the SpeedyCar pool.

Lane

With lanes, you can structure an organization by groups or roles, for example. In this example, SpeedyCar includes the car pool and call center agent lanes. Lanes communicate with other lanes within the same pool using sequence flows.

After this brief introductory example, let's now discuss the advanced concepts of BPMN.

5.6.7 Extended event-driven process diagram

Event-driven process diagram (EPC) defines the procedural organization of the company as well as the links between the objects of the data, function and organizational view. A procedural sequence of functions is illustrated by means of process chains. In the diagram, the start and end events of every function are specified.

Events are triggers for functions or can be results of functions. The changed state of an information object can refer to the first occurrence of this information object. The event-driven representation of process chains links the data and function views and is thus allocated to the control view within the ARIS architecture where events are graphically represented by hexagons (refer Figure 5.23). The name consists of the information object (‘order’) and the change of status of this information object (‘received’). As events define which state or condition starts a function and which state defines the end of a function, start and end nodes of these EPCs are always events. One event can be the starting point of several functions but a function can also result in several events. A connector is represented by a circle is used to illustrate these splits/joins and processing loops in an EPC. These links are not only graphic connectors but also the logical links between the objects they connect.

What Did Not Work

Pure BPMN collaboration or BPMN process diagrams are not sufficient to provide all of the information needed for a successful business process implementation. The integrated enterprise information model does not yet support complete model-driven implementation. With existing BPM tools fewer than 50% of the information models (e.g., with ARIS Netweaver for SAP, SAP Solution Manager,44 SAP Business Workflow, iGrafx, or SAP BPM) can be implemented. The reason for this deficiency is that existing tools focus on specific tiers, views, levels, model types, or information objects, and have missing or limited interfaces between the different conceptual spaces in which they reside, considering only narrow aspects of the total problem, such as focusing on automation or on transformational work, without fully capturing other forms of work.

2.1 Simple PFDs

Simple PFDs consist of simplified process diagrams and process descriptions only. Most of process data is still partly lacking such as material balance, which is obviously complicating FEs assessment at this stage. For this purpose Hassim et al., (2010) developed a simple method based on precalculatedFEs database for different process modules such as different types of columns, reactors, compressor etc. The database was created by analyzing the number of potential leak sources in standard process modules, which represent typical operations in chemical plants. Spreadsheet was used to computerize the method. First, user needs to specify the standard modules present in the process. The streams (feeds and outlets) associated with each module need to be identified first. Next, user gives data on the stream phases and the chemicals present in each stream based on process descriptions. Vapor pressure at 20 oC of the chemicals is entered manually or can be imported from simulator databank. Based on stream phase and vapour pressure data, the stream's service type (gas/vapour, light liquid or heavy liquid) is determined by the program. Basically the liquid is classified as light liquid if majority (formulated as more than half of the chemical substances in the mixture) of chemicals have vapor pressure > 0.3 kPa. Otherwise it is considered as heavy liquid.

Then, from the service type, the rate of FEs for each module stream is calculated by using the data from the precalculated emissions database. Since at this stage mass balance data is not yet available, the fugitive emission from each stream is assumed to be represented by the most toxic chemical ('worst chemical') in the stream. The 'worst' chemical of each stream is determined by comparing the exposure limit (EL) values of the chemicals in the stream's mixture. The chemical with the lowest EL value is indicated as the 'worst' chemical. For this purpose the EL values are either retrieved from a database or given by the user. The fugitive emission rates of streams are summed up for each 'worst' chemical throughout the process.

Analyze

In many cases the team members have a good idea of the cause of the problems in the process they analyze. They gather data to establish baselines and then want to jump to implementing a solution. In some cases this is reasonable. The waiters in our example probably know what takes time and know how they could save some. In more complex cases, however, it is not so obvious.

Once you have some measurement data there are many ways to analyze what might be causing a problem. Some of them involve defining the process in more detail. Others involve applying statistical tools to the data.

Assuming you have developed a detailed process diagram you can establish measures for each activity on your diagram. It is also useful to consider how each activity adds value to the entire process. In essence, any given task can be classified into one of three categories:

The activity adds value that the customer, whether internal or the ultimate customer, is willing to pay for.

The activity is necessary to produce a value-added activity.

The activity does not add value.

You can always check with the customer to determine which activities add value. You normally would not ask the customer to consider the activities as such, but what they add to the final product or service. This consideration takes us back to the issue of how we choose measures. You could ask, for example, if the customer likes the flowers and the white jackets the bus people wear. If the customer tells you it is a matter of indifference how the bus people dress you might consider what the purchase and cleaning of the jackets add to the customer’s bill and consider if it might be worth dropping that aspect of the service package.

It is usually easy to identify the activities that add features that customers can identify and value. Those that do not fall in that category are usually placed in Category 2. In fact, some activities do need to be done so that other Category 1 activities can be done. Each needs to be challenged, however. Often, processes that have been done for a while end up supporting activities that are no longer really required. In all surveys at SF Seafood the customers indicated that napkin rings were of no value to them. Clearly, the placing of napkins in rings when setting the table was an activity that could be eliminated. It took time, cost money, and did not add any value to the customer’s dining experience.

Consider a company that installed an email system that allowed salespeople to report their results each day online. For some unknown reason the company had installed the email system, but never eliminated the requirement that the salespeople complete a Form 2B and submit it on the 30th of each month. In fact, Form 2B only provided information that the sales managers were already obtaining via the daily emails. Completing Form 2B was a value-reducing activity. Worse, sales managers continued to log the forms to ensure that each salesperson turned them in on time. It is always wise to consider eliminating activities that do not add value. Moreover, if an activity is value reducing one should check to be sure that no one is measuring that activity.

The analysis of waiter problems at SF Seafood seems straightforward. In fact, those familiar with a small lunchtime restaurant might be surprised that it takes as much time as it does at SF Seafood. It might seem obvious that if the waiter simply went straight to the PC after taking an order and entering it, it would only consume a minute at the most. Similarly, it might seem obvious if the waiter went to the hot table as soon as he or she saw a flashing light that delivery of the food could not take more than another minute. That would get the total delivery time under 3 min. Were there one waiter per table they could probably come close to that. Unfortunately, in SF Seafood each waiter is expected to cover from five to seven tables depending on the hour. Some waiters are scheduled to begin work when the restaurant opens and there are only a few customers. Then more are added as the numbers grow toward the maximum number between 7:30 and 9:30 in the evening. Equally importantly, waiters not only take orders they serve drinks and attend to customers who may want help choosing a wine or other drinks, coffee, or desserts. Moreover, as every waiter learns, if you always do only one task at a time you can never get everything done that needs doing. If you are already going to the kitchen to get one meal, getting two is better. If you are already taking an order, taking orders from two tables, one after the other before placing either order, saves time.

One obvious way to analyze the process is to assign times to each of the tasks a waiter must do and multiply by the number of tables the waiter is trying to serve. It may be obvious that a waiter should avoid being overstretched by only serving four tables rather than five. Or, perhaps, a change that involves the bus people helping the waiters move meals from the hot table to customer tables may save time. If that’s a possibility, then we would need to determine exactly what bus people do and what would remain undone if bus people began to do more to help waiters.

This is not the place to go into such details further. Imagine if we had included the kitchen in our analysis and needed to analyze all the steps that went into the preparation of a meal, and tried to decide if it would make a difference if the salad chef was more efficient, or if the oven was set 2° higher. Or, imagine we were analyzing a production line with hundreds of activities that needed to be coordinated, some of which could be rearranged. The larger and more complex the process the more problems we need to consider. In some cases statistical tools become an invaluable way of sorting out the seemingly overwhelming confusion about which activities are really making the most difference in the final outcome.

Six Sigma project managers usually recommend a systematic analysis process. You begin with a comprehensive look for possible causes. Then you examine the possible causes in more detail, gather data as appropriate, and apply statistical tools, such as regression analysis and scatter diagrams. In the most complex cases you are forced to design experiments and vary or control one or another aspect of the problem while gathering data. In the end you usually come back to the 80/20 rule. There may be many causes, but one or two causes (20%) usually account for 80% of the problem. Those are the causes that one initially focuses on to make the process more efficient.

Some Six Sigma practitioners talk about problem analysis as a three-stage process:

Open. Brainstorm to identify as many possible causes as possible.

Narrow. Use tools or vote to reduce the number of possible causes to a reasonable number.

Close. Design measures, gather data, and analyze them to determine which causes in fact cause most of the deviation from the mean.

One popular tool used by many Six Sigma teams when they are trying to identify all possible causes is a cause-effect or fishbone diagram. In effect, it is another kind of tree diagram that one examines to whatever depth is appropriate. We have illustrated a cause-effect diagram for the waiting task in Figure 12.6.

The cause-effect diagram in Figure 12.6 is hardly exhaustive, but it provides an idea of how one identifies a cause, defines it further, and yet further still if possible. The actual diagram for SF Seafood was much more complex than this. Also, there are some overlapping categories. For example, families with more than two kids are likely to also want to rearrange tables. Moreover, these same tables are the ones that could really benefit from extra help from a bus person.

In the end the SF Seafood team gathered data on several causes. The team voted on the causes that were really costing the most time. They used a method in which each team member indicated which problem they thought was the worst cause of time delays, the next worst, and the third worst. The results were as follows:

One of the issues raised by this analysis was the control and placement of families. This is normally done by the maître d’. An experiment was developed, and after 2 weeks, it was determined that waiters who did not have families in their areas definitely provide faster average service. It was also determined that a waiter with six tables who got two groups with more than two kids each was likely to go over the 18-min upper limit. As a result the team decided to change the definition of the process. The new process included a new subprocess—customer seating—and it included the maître d’s placement of customers within the various waiters’ areas.

At this point a Six Sigma team usually gathers a lot of data to validate the effect of the different causes identified by the team and to determine their relative salience if possible. We will not consider the various data-gathering techniques or the statistical techniques used by teams to examine the data. In the case of the SF Seafood team the data confirmed the list that the team previously generated.

How can I answer this question?

In Chapter 2, we provided two basic product development process diagrams and illustrated how the persona lifecycle affects or integrates with each. What does your product development process look like? If you can, sketch your product design and development process as a diagram and consider the following questions:

Do you involve users in the design, development, and marketing of your products? If so, how?

At which stages in your process and in what ways is user information collected and considered?

When it comes to integrating knowledge and insights about users into the products you create, what processes do your colleagues believe are working well? Which processes are failing, and in what ways?

How do you measure the success of various processes in your organization?.

How wedded is your organization to the existing design and development process? Are there any well-known frustrations related to the current processes? Does your organization tend to defend itself from new methods, or has your organization already identified problems with the status quo and decided to make some significant changes?

Business Process Modeling Notation

BPMN defines a graphical syntax for drawing flowchart-like process diagrams. It is intended to be primarily business facing, not a description of a technical realization. It does not specify how to execute a process on a computer: it assumes that BPMN models will be mapped to whatever execution environment is required. The BPMN specification provides a sample mapping to BPEL, and in future, mappings to various forthcoming W3C standards are anticipated. BPMN began life as part of the Business Process Modeling Initiative, but progress on the standard moved to the OMG in mid-2005. Various drafts of Version 1 of the standard have been available for some time, and work has now started on Version 2.

An activity represents work that is performed during a process, denoted in BPMN as a rectangle with rounded corners. Activities can be nested with the details of subactivities hidden. Compound activities are identified by adding a “+” icon to the activity symbol. BPMN also uses the term “Task” for atomic activities that have no lower level breakdown. Various other icons can be added to the basic activity shape to indicate other types of activity, such as looping, transactional, compensating, ad hoc (the sequencing of any internal activities is not defined), multiple instance (several instances of the activity can be performed in parallel), and so on. With some restrictions, these can be combined to indicate such things as a looping ad hoc compensation activity.

Events represent something that happens during a process and are denoted by circular symbols. There are three main subtypes: start events have a single-line circle, intermediate events have a double-line circle, and end events have a thick line circle. Icons can be added within the circle to give a more precise indication of the type of event, such as message, timer, error, and so on.

Splitting and joining in flows can be shown using a diamond-shaped gateway symbol. The symbol can carry an additional icon to indicate the nature of the split or join. Variants include exclusive-or (the default if no icon is shown), and, inclusive-or, and complex (where the split or join conditions are determined by expressions).

Activities, events, and gateways are linked by connecting objects, which come in three varieties. Sequence flows show the order (sequence) in which activities will be performed during a process and are denoted as solid lines with a filled arrowhead. Sequence flows can also carry additional markings to indicate that a flow is conditional, or is a default flow. Message flows show the interchange of messages between participants in a business process and are denoted as dashed lines with unfilled arrowheads. Associations are used to connect data, text, and so on with flow objects and are denoted as dotted lines with an optional open arrowhead. One use of these is to show the inputs and outputs of activities. Figure 15.42 shows a typical BPMN process diagram.

The process in Figure 15.42 starts with the receipt of a loan application (shown as a message). After the loan assessment activity the control flow passes to one of the three following activities. Each of these is a compound activity: the internal details are not shown here. The final exclusive-or gateway joins the split paths together and the process ends. In the referral case, there is a time event associated with the applicant review. If the review is not completed within the given period it is escalated to be dealt with by a supervisor. The escalated review process also has branching in the flow, but rather than using gateways, the subprocess uses decisions on sequence flows and implicit joining of flows. The escalated review subprocess also shows reuse of the definition of the compound activities for loan approval and loan rejection.

The current version of the BPMN standard has been criticized for a lack of clarity in some areas. Some aspects, such as the detailed rules for the processing of flow tokens at gateways, are not fully specified. In other areas, BPMN offers alternative notations for some constructs, such as splitting flows following an activity, but gives little or no guidance on when one approach should be preferred over another or whether subtle semantic differences exist between the alternatives. However, such issues will no doubt be addressed in future versions of the standard.

Models and Diagrams

In this book we will use two broad classes of diagrams: organization diagrams and process diagrams. In this chapter we will focus on the basic notation used for organization diagrams.

As we have suggested, many different groups are involved in business process modeling. Predictably, different groups use different types of diagrams. Even within a relatively well-defined community, like workflow software vendors, a dozen different notations are used. Some of the notations are different from one another, stressing different ways to view organizations or processes. Some notations differ on such trivial matters as whether a process should be represented as a rectangle or a rectangle with rounded corners.

The key thing to think about in selecting any notation is who is going to use it. We assume that the diagrams described in this book will be used by business managers, business analysts, and process practitioners of various kinds. They may also be used by software developers, but software developers are not our primary audience. Hence we have constrained the types of things we describe in diagrams to the things most managers are interested in, and omitted notation that is only used to describe software conventions. Furthermore, although we recommend the use of software diagramming tools for some purposes, we assume that many managers will create diagrams of their organizations and processes on drawing pads, blackboards, or relatively simple diagramming tools, like Visio or PowerPoint. Hence we have made every effort to use simple, easy-to-understand conventions.

Our goal was to arrive at a way of describing organizations and business processes that is as easy to understand as possible, while still making it possible to describe all the basics that need to be described. In this chapter, as we describe the notation, we will not consider how it might be implemented in a software tool. Several tools, however, implement notations similar to the one we use and thus in later chapters we will show how software tools can be used in process redesign to simplify the creation of organization and business process diagrams. At this point, however, we only want to provide readers with the basic notational elements necessary to draw models of their organizations and business processes. We will begin by explaining the basic elements of an organization diagram. Then, we will proceed to show how this type of diagram can be used to define an organization’s value chains, specific value chains, stakeholders, and high-level organizational concerns.