Why Business Process Automation?

Business process automation provides a number of business opportunities discussed in the following paragraphs. Even small businesses should be able to benefit from a process automation capability.

• Reliability. Process automation provides clear expression of who, what, when, and how participants must perform their assigned activities in order to achieve a process objective.

• Capability composition. Processes define how enterprise capabilities contribute and how they are networked to meet enterprise objectives.

• Sharing. Processes can engage shared capability services as subprocesses to deliver results. Sharing yields economies of scale from utilization of resources and implementation of improvements.

• Control. Processes can ensure control for efficiency, to meet requirements for compliance with policies and regulations, and to mitigate risks.

• Resource management. Processes that consume the same resources and manage the same business capabilities can be consolidated for economies of scale and workload management.

• Visibility. Information technology can greatly improve process visibility. Business process models expose the design of business processes. Runtime monitoring tools enable workloads and performance to be observed in real time. Operating statistics and audit trails support analysis of processes for process improvement and accountability.

• Optimization. Repeatable aspects of all business processes can be measured, and the impact of particular activities can be identified to determine where improvements are needed and to assess progress in implementation of changes.

• Exploitation of advanced technology. In recent years, mobile computing, such as smart phones and wireless tablets, has enabled participants to be engaged in a process as it happens from nearly anywhere, at any time, and relevant information can be accessed over the Internet.

• Modeling. Modeling supports consideration of process design improvement based on operational measurements along with many other factors such as best practices, risks, accountability, authorization, share ability, and enterprise-level optimization.

• Customer service. Business processes can be driven by customer inquiries, orders, or order status requests over the internet for rapid response to a global marketplace.

• Agility. Business process modeling enables definition and adaptation of processes to be quickly developed, and process automation supports rapid deployment with minimal need for training of participants and oversight of the transition.

Agile Enterprise Process Architecture

The agile enterprise relies heavily on business process automation to achieve the above business benefits and to integrate and coordinate the many efforts of a successful enterprise. Traditional enterprises focus on the operation of independent lines of business. A typical process or series of processes take an order through all of the operations to deliver the product and receive payment. All of the required capabilities are embedded in this value stream process, tailored to the needs of the particular line of business. Similar processes feed the mainstream process with materials and supports. These processes could be very efficient (at least for the technology of the times), but very inflexible.

The agile enterprise requires a process architecture that enables rapid development and adaptation and exploits current technology. The following paragraphs describe the characteristics of that architecture.

• Shared services. A shared capability is implemented with a process that is engaged as a service. Shared services may engage other shared services. The scope of a process is limited to support of the capability it provides.

• Closed-loop request-response. In general, shared services should be engaged synchronously, so the requestor remains responsible for obtaining a result and the requested service is not required to deliver a result dependent on the source of the request. These are represented as delegations in VDML.

• Asynchronous service. Some capability services will be initiated by an asynchronous input message. This may initiate a different value stream, or it may enable concurrent processing with a later return delivered asynchronously. These are represented as flows through stores in VDML.

• Choreography. Interactions for coordination of independent processes (between business entities or independent organization units) are designed and implemented as choreographies.

• Distinct business processes. Business processes must be visible and separate from applications and provide the process context for the use of applications.

• Service context. The context of a service must include a process occurrence identity and related data for reference in ancillary services such as status reporting, changes, and performance monitoring.

• Generic functionality. A service process should not include activities that depend on the source of the service request.

• Service unit. A service unit is the operational equivalent of a capability unit where a designated organization unit manages a bundle of services and related resources, administrative functions, and technical support to maintain and adapt the services and optimize the utilization of resources.

• Roles of roles. It must be possible to specify a participant in a process role in terms of a role in another context. For example, a role in an order entry process filled by a person in a sales person role in a customer relationship management (CRM) process.

• Input role assignment. It must be possible for a service to pass a role assignment to a service it engages. For example, the surgeon for a patient is intended to be the same doctor as the one providing bedside care.

• Reusable resource tracking. A process must support tracking and availability of reusable resources, particularly people and equipment that are in limited supply.

• Process integration. Process interfaces must support seamless integration of BPMN, CMMN, and DMN (decision model and notation). DMN is discussed in Chapter 5.

• Service registry. Processes must be engaged through a registry so that introduction of new versions can be properly managed.

• Runtime modification. It is desirable to enable modification of a specific occurrence of a process at runtime to resolve a problem. In the alternative, it should be possible to trigger an exception that will cause an orderly termination or restart of the process.

• Mobile device interface. A mobile device application should provide each participant and/or manager with easy interaction with relevant processes including process and participant status. Status optionally includes completed and pending activities.

• Participant alerts. A participant and/or manager should receive text messages or other forms of personal alerts when action is required or delayed. A participant or manager should be able to post a condition to receive an alert when the process occurrence meets the condition.

• Guidance. A process should support presentation of participant guidance based on the current circumstances of the process occurrence. This includes guidance on decisions and planning in adaptive or ad hoc processes (discussed later).

• Audit trail. The execution of a process must generate an audit trail/history of the process decisions and actions taken for future analysis and accountability.

• Electronic signatures. A process must support electronic signatures on records/documents created by, or approved by a participant, particularly if they involve management of assets.

• Context tree. A participant and/or manager should have access (with appropriate authorization) to the context tree of a process occurrence to examine the source and circumstances of the current request.

A number of these features are not necessarily supported by current business process systems, but all systems should support the basic structure of shared services and process design. The other features should be included as they become available.

Process Modeling

The design and refinement of business processes is fundamental to management of an enterprise. We discuss process modeling here because it is important for business leaders at all levels to have a general understanding of the nature of process modeling and be prepared to discuss process models when investigating business problems or considering business changes.

VDML provides models suitable for the conceptual design and understanding of business operations. However, a VDML capability method is a statistical representation of the activities that apply capabilities, the flow of deliverables, and the creation of value, so it does not include operational detail required to process individual business transactions. VDML does represent the flow of deliverables (business items), whereas BPMN focuses on flow of control rather than statistical flow of deliverables (similar but different).

For example, a VDML process may represent an activity that receives inputs from two deliverable flows where the business items are matched and directed to one of two output deliverable flows. VDML may not address a possible exception where the input deliverables do not match, and it may define the percent of deliverables that flow to the alternative outputs, but it may not define the criteria used to determine which individual output flow is selected. We will discuss the possible complexity of VDML to BPMN transformation later in this chapter.

The operational equivalent of a VDML activity diagram may be determined by a transformation to BPMN or CMMN models, it may be embedded in the operational detail of a software product or legacy system, or it may be fully ad hoc, depending on individual expertise and represented in the abstract by a VDML capability method.

When an operational problem occurs, VDML may support analysis of the cause and possible source of the problem, but operational managers also must be able to understand and assess the processes of concern at an operational level of detail that is the focus of the operational workers and where the corrective actions must occur.

The architectural features discussed above apply to most operational business processes in the agile enterprise. This section will provide an introduction to modeling business processes with BPMN and CMMN. The discussion focuses on each of four types of business process models:

• Prescriptive processes. A prescriptive process can be specified in detail to define how each request is processed. That does not mean that each is processed in exactly the same way, but explicit decisions determine where different activities are required, where iterations occur, where exceptions are handled, and where the sequence of activities is affected by events. These are the repeatable processes modeled with BPMN, and such processes are automated with a system that manages the execution and tracking of each occurrence.

• Adaptive processes. The specific activities, events, and sequences of adaptive processes are not predictable, but they have patterns of activities and decisions that are typical of occurrences of a type of request. These have been called case management processes because the typical application involves a “case” and a “case file” that defines the current situation. These are modeled with CMMN and are implemented by a system that manages the case file, the emerging plan, the interactions of participants, and the tracking of status and events.

• Cooperative processes. A cooperative process is an interaction between two or more participants that are effectively independent business entities. The shared protocol is called a choreography. There is no shared system to manage the interactions, guide decisions, track the status, and make assignments. The participants are not concerned with the internal processes of other participants, only the observed behavior of participation. Each participant operates under a shared specification that defines the required actions of each participant and the interactions between them. The modeling specification for choreography is part of the BMPN modeling specification.

• Ad hoc collaborations. Conceptually, every ad hoc collaboration is different. These are collaborations that may only occur once, or they have significantly different issues and circumstances to address. Managers and executives are often participants in such collaborations. Although they are unpredictable, there are some common characteristics of any collaboration that can be supported with automation, and automation can be provided by implementation of a small but useful CMMN model.

These four types are each discussed in greater detail in the following sections.

Prescriptive Process Modeling With BPMN

BPMN has been widely accepted as a business process modeling notation (ie, a form of expression) for prescriptive business processes—those that tell participants what to do and when. The following section provides and overview of BPMN that will enable managers to participate in process design and understand the specification of processes that drive the enterprise.

BPMN Example

Fig. 4.1 provides examples of the use of some BPMN elements. Participants in the overall process are designated by the separated boxes (pools) with the names of the participants at the top. The dashed arrows represent exchanges of messages. The focus of the diagram is on the process of the Seller. The Seller process (contained in the Seller pool) is started by a message from the Buyer. The Seller is partitioned into “lanes” representing different internal responsibilities. The Order Management organization (lane) edits the order, notifies the Buyer of acceptance or rejection, and obtains payment through the Biller after the order is shipped. The Warehouse (lane) fills and ships the order using the Carrier. Messages are exchanged between the Seller and the other participants. The Seller process ends if the order is rejected or after the Seller receives payment from the Biller.

Fig. 4.1 indicates exchanges between participants that can be expressed in a choreography, but here the sequence of exchange is defined by the internal process of the Seller. A choreography would define the interaction independent of the internal processes of all participants.

BPMN Notation

BPMN has 13 basic graphical shapes, as shown in Fig. 4.2. The figure also shows examples of frequently used variations on some of the basic shapes. Each of these shapes and some of their variations are discussed briefly in the following sections. For the most part, the general nature of an element is indicated by the external shape of the icon. More specific characteristics are depicted by the content of the icon.

Event

A event causes a process flow to start or stop. There are three basic types: a start event designated with a simple circle, an end event designated by a bold circle, and an intermediate event designated by a double circle. A default process start is an empty circle, and a default process end is an empty bold circle. Icons appearing within the circle define specialized types of events—for example, an envelope designates a message, a clock designates a timer, a lightning bolt designates an error. A message can start, delay, or end a process. A timer can start or delay a process. An error (or exception) can interrupt or end an activity or a process. There are other less commonly occurring events.

Events can define when a process is interrupted. When a process is interrupted, it may return an error or execute compensating activities to compensate for work already completed or messages sent.

Activity

An activity is where work is done. The default is a task, which denotes that there is no more detailed specification of the activity. A subprocess, designated with a plus sign (+) in a small box, indicates that the activity is performed by a more detailed process. The detailed process may be embedded and the activity can be expanded to show the detail, or the subprocess can be global (independent), meaning that it exists outside the current process and is shareable with other processes. Other activity specializations represent activities with repeated or concurrent executions.

Gateway

A gateway is a point in the process where flows converge or diverge. The default gateway (empty diamond) is an exclusive or. It provides for inputs from alternative paths to proceed on a single output path. If there are multiple output paths, only one can become active as specified by conditions on the outgoing paths. The exclusive or may also be designated with an X in the diamond. An and gateway is designated by a plus sign (+) in the diamond. It requires all inputs (from concurrent paths) to be active before it proceeds, and multiple outputs proceed concurrently, creating parallel paths. It may be called a fork for multiple outputs or a join for multiple inputs. There are other less frequently used gateway types designated with other icons. The complex gateway is designated with an asterisk (⁎). It indicates that the action depends on a complex computation.

Sequence Flow

The solid arrow designates the control sequence flow of execution of activities, events, and gateways. The arrow enables the execution of a target activity, event, or gateway when the activity, event, or gateway at the start of the arrow is completed. Where there are alternative paths, as from an exclusive-or gateway, the default path may be designated by a hash mark across the arrow.

Message Flow

A message flow is designated by a dashed arrow. A message flow comes into or goes out of a business entity (ie, a pool, discussed in a moment). Messages may be exchanged between processes or between a process and another system. The agreed-upon specification of the sequence of message flows should be expressed in choreography.

Message

A message represents communication to or from an external business entity. It is communicated in a store and forward mode, so the recipient need not be immediately available.

Association

A document or other object may be associated with the process elements using a dashed line or arrow. The arrowhead is optional and may be used to indicate whether the object is an input or output to the associated process element.

Pool

A pool designates a business entity responsible for the process contained in the pool. Processes are bounded by the boundary of the pool. Actions that cross pool outside boundaries must be represented with message flows. In Fig. 4.1, Buyer, Seller, Carrier, and Biller are pools because they represent independent organizations. The Buyer, Carrier, and Biller pools are shown as empty because the focus of the diagram is on the Seller process, but the diagram implies that they have processes that send and receive messages, even though details of the processes are not known from the perspective of this diagram.

Lane

A lane is a segment of a pool that represents the role of an organization or person that is responsible for the process elements contained in the lane. In Fig. 4.1, Order Management and Warehouse are lanes within the Seller pool. They represent roles within the Seller organization. The Seller has overall responsibility for the process. The Warehouse has responsibility for the activities in its lane—Fill Order and Ship Order—and Order Management has responsibility for the activities in its lane.

Data Object

A data object is a unit of information that may be produced or used by a process element within a pool. The data are not retained beyond the scope of a process, but they are accessible by a subprocess.

Data Store

A data store holds data items beyond the scope of a process. This provides for asynchronous communication (store and forward) to other process(es) within the enterprise without the need for messages. BPMN assumes that exchanges within a pool are synchronous, and exchanges of messages between pools, representing independent business entities, are asynchronous. BPMN can also represent asynchronous communication within an enterprise when different processes place and retrieve data items in a data store.

Group

A group is a graphical representation of a shared characteristic of the process elements it contains. A group is not expected to have functional significance to the process flow but is used essentially for documentation.

Text Annotation

A text annotation is information added to a diagram to clarify the intent. It is documentation only. It is usually linked to a model element with an association line.

Attributes

BPMN also defines attributes associated with the graphical elements. Attributes are additional data that do not appear in the diagrams but would typically be accessed in a BPMN tool by selecting the graphical element to obtain a popup window with a list of attributes.

BPMN Choreography: Cooperative Process

A cooperative process does not have a shared control mechanism that directs the sequence of activities. Participants in a cooperative process are each responsible for determining when and what to contribute based upon a shared specification—a choreography. In VDML, a cooperative collaboration between business entities is specified as a business network.

In a cooperative process, the tasks are transfers of information or deliverables between the participants. Initiation of the next task depends on the internal processes of each party and their support for the shared choreography specification. Choreography assumes asynchronous communication with messages. The exchanges are asynchronous because the participants are independent entities that are not always prepared to immediately respond to a communication.

Without choreography, BPMN can still express the exchange of messages between pools of autonomous business entities. However, the possible sequence of message exchanges must be inferred from the internal actions of the participants. This gets complicated, quickly, particularly if there are more than two participants.

Choreography explicitly defines the “protocol of engagement,” independent of the internal processes of the participants. It is a specification they can all agree with and rely upon for a successful engagement. In addition, it leaves the internal processes of each participant private, and they are free to change their processes as long as they continue to comply with the choreography.

Choreography Notation

Fig. 4.3 illustrates a trivial choreography. A rounded box is a choreography task and represents the delivery of a message. The bands at the top and bottom designate the sender and receiver. The sender band is white and the receiver band is gray. The solid arrows indicate the flow of control—the task to be executed next. Note that the sender of a task (white band) must be the previous task recipient (gray band) to represent a dependent action.

The message flow, indicated with a dashed arrow from a sender or to a receiver and an optional “envelope” icon, represents communication of information or a deliverable. The message (envelope) that initiates a task is white, and a subsequent message in the same task is gray. The envelope graphic is typically not needed since the white band indicates the source of a message directed to a gray band recipient.

The example diagram includes an exclusive-or gateway indicating that the previous task (Order Taker) must choose between the two output paths. The gateway does not operate directly since all decisions must actually be made by the participating parties—there is no shared entity directing activities. The sender must make the decision internally. Other BPMN gateway types can also be applied.

Order Placer and Order Taker are roles in the choreography representing participating entities. The choreography starts with a message containing an order from the Order Placer to the Order Taker. The Order Placer is the service user since it initiates the exchange and sets the context with the order content. The Order Taker receives the order and either accepts it or rejects it. The gateway (diamond-shaped) element indicates alternative paths.

Some services are accessed through a simple request-and-response exchange. The service user requests information and the information is returned, and there is no need to specify further interaction. This may be represented by a single choreography task with requester and provider messages; the return message is shown as a gray envelope.

A choreography specification defines only the interactions between the parties and not how the parties perform their responsibilities, internally. Each party is free to define their internal processes as they like as long as they comply with the requirements established by the choreography. Of course, the content of the exchange or other agreements between the parties defines obligations of each as a result of the exchange, such as an obligation of the provider to deliver a product and the obligation of the requester to pay for it. This example choreography is quite trivial, but more complex choreographies may involve additional exchanges and participation of multiple parties that are coordinated to accomplish a shared result.

In addition to flow arrows, messages, and gateways, choreography also uses some other graphical elements defined for BPMN, above: events (circles), pools (named box but without content), and text annotation (dotted line to open box with text). A choreography task (with a heavy border) may call a choreography subprocess. A subprocess will have start and end events. Additional detail on these and other BPMN elements is a subject for a more advanced study.

Additional Cooperative Process Views

BPMN defines two additional types of process views that are based on the representation of related directed and coordinated processes: collaboration and conversation are discussed briefly here.

Collaboration is an unfortunate term since it is only used in reference to display involving message exchanges between pools, whereas a VDML collaboration is any interaction between persons, organizations, and/or machines for a shared purpose. A BPMN collaboration display may show (1) only messages exchanged between pools, (2) a choreography describing messages exchanged between pools, (3) messages exchanged between pools with processes receiving or sending messages from within one or more of the pools, (4) a pool, with or without an internal process shown, exchanging messages with a choreography, or (5) pools with processes sending and receiving messages through a chorography that defines the sequencing of the message exchanges.

Fig. 4.4 illustrates one form of collaboration view: messages communicated between a black-box pool (Order Placer) and the elements of another pool (Order Taker). This collaboration shows the Order Taker process that corresponds to the choreography of Fig. 4.3. This collaboration display could be extended to show message icons on the message flows with message names.

A BPMN conversation is an abstraction of a choreography. Fig. 4.4 shows a BPMN collaboration view of the choreography of Fig. 4.3 and the conversation of Fig. 4.5. A choreography of greater scope might show conversations between the Order Taker and a Transportation Carrier and the Order Placer and the Transportation Carrier. The conversation view is useful for an overview of a complex network of multiple participants.

Internal Choreographies

It is important to note that although the examples have involved business-to-business interactions, choreography can be applied to interactions within an enterprise as well. Two departments may have processes that involve interactions over a period of time as the work progresses.

As noted earlier, simple request-response interactions don’t require explicit choreography, but conceptually they have a choreography as well. Essentially, every relationship between processes has a choreography, though it usually is implicit.

Often a process interacts with the same person several times, as defined by the role assignment. This sequence of interactions with the person can be described as a choreography, and this specification may be useful for understanding the responsibilities of the person assigned to the role. Often, what at first appears to be a simple request-response relationship evolves to a more complex interaction, particularly if the request is not immediately followed by a response.

Choreography essentially defines the restrictions participants must observe to achieve a mutually beneficial outcome from a relationship. In the next chapter, we will discuss business rules that are used to specify other forms of restriction on business operations.

Adaptive Process Modeling With CMMN

Over the years, with a focus on repeatable processes and automation, most of the rote, human activities of repeatable processes have been automated. The human activities that remain may be characterized as the work of knowledge workers—people who make decisions of how their work must be done and collaborate with others to plan and coordinate efforts. These are adaptive processes that vary depending on the particular situation as it evolves. Here we will describe these as case management processes where a case is “a situation requiring investigation or action” [Merriam-Webster]. CMMN has been recently adopted by Object Management Group (OMG) and is the only standard language for modeling adaptive processes.

Case management is a paradigm shift from design and optimization of repeatable processes that are the traditional focus of BPM. Adaptive processes are not repeatable but can be guided by best practices along with suggestions or alerts derived from changes in the state of a case. Many of the activities of adaptive processes occur frequently, but they may occur at different times in the overall process, they may involve different factors, and the actual occurrences and sequences of activities will vary. In addition, records that define the history and current state of the undertaking are central to the determination of actions to be taken. Nevertheless, repeatable processes and case management processes must work together to support the work of the enterprise.

With prescriptive (BPMN) processes, the balance between rote activities and knowledge worker activities has evolved to processes where work that requires a knowledge worker is assigned with general activity requirements and details are worked out by the knowledge worker. There are five problems with this approach:

(1) The process makes assumptions about the overall sequence of activities of the process that restricts best judgment,

(2) The interactions and coordination between participating knowledge workers are constrained,

(3) The specific actions of the knowledge worker are not captured to support analysis of better practices or resolution of problems,

(4) The process may not achieve timely response to changes in the situation,

(5) The knowledge worker may not have the benefit of relevant information including the insights of others, applicable regulations, or critical facts of the situation.

Adaptive processes address these issues.

(1) The sequence of activities can be adapted to the particular situation.

(2) Participants are expected to collaborate on planning and corrective action as the situation evolves.

(3) Plans, events, and activities are recorded as they happen, and knowledge workers can update their plans and accomplishments as they happen.

(4) A shared record of the situation (a case file) is updated by participants and external events so that critical events can be automatically recognized and appropriate participants notified.

(5) The system can define constraints and suggest actions based on the current situation to reduce omissions and expedite appropriate actions.

Modeling is key to successful automation support for adaptive processes. Knowledge workers cannot specify all of the detailed plans, monitor every change in the situation, and check for every circumstance that may affect decisions. The knowledge worker needs predefined plan building blocks—activities, process fragments, triggers, and guidance—that can be quickly assembled and adapted to the particular situation and revised as the situation evolves.

CMMN is an OMG specification for modeling adaptive processes. A particular CMMN case model focuses on a type of case where there are commonly occurring stages, plan elements, or plan fragments. A case model includes specifications for a case file (the record of the current situation and actions taken), triggers for important circumstances that may occur and reusable planning elements and patterns for the type of case. CMMN can engage directed, repeatable processes where applicable, and directed, repeatable processes can engage case management when knowledge work is required.

CMMN Notation

The CMMN specification includes a graphical notation for modeling adaptive processes. This section describes the primary graphic elements in Fig. 4.6 and “decorations” (icons) in Fig. 4.7, that qualify the primary graphics.

While these graphics are designed for modeling a type of case, it is expected that they will also be used by participants at runtime for planning and monitoring an active process and the process history. Therefore, modelers must keep in mind the level of process sophistication they can expect from the users of a model.

Primary Graphic Elements

The following paragraphs will discuss the primary graphic elements of CMMN in Fig. 4.6.

Case plan model. A case plan model contains the plan of a case. It is essentially a top-level stage, and it is the outer boundary of a case. The elements that can occur in the plan may be referenced in general as plan items.

Case file item. A case file Item is a unit of information that is stored in the case file. The information may be in any electronic form and may be a link to information in an external source. The content of structured items may be referenced by rules. There may be multiple versions of an item, but only the current version will be referenced by the case plan.

Stage. A stage (angled corners) is a group of plan items that occur together to achieve a particular purpose within a case. The plan items are only active if the Stage is active, and they will no longer be active when the Stage is completed. Stages can occur within a stage as for a hierarchy of activities in a project plan. Typically stages will occur in sequence, but they may also occur in parallel.

Plan fragment. A plan fragment is a set of plan items that often occur together in the case type being modeled. The fragment can be trivial or complex. Once placed in the plan, the plan items become part of the plan without any effect of the plan fragment boundary. The items in the fragment can then be changed to suit the particular circumstances.

Task. A task is a unit of work. A human task can be blocking—it waits for the human to complete the work (hand in the upper left corner). A nonblocking task has no outputs (person in the upper left corner). A case task will engage another case (folder in the upper left corner). A process task will be used to engage a conventional process, for example, BPMN (chevron in the upper left corner).

Sentry. A sentry enables entry to (white-fill diamond) or exit from (black-fill diamond) a plan item based on a rule. The rule has an on-part that identifies a triggering event, and an if-part that is evaluated when the on-part event occurs. The if-part must evaluate to true for the sentry to enable the plan-item entry or exit.

Milestone. A milestone is used to indicate progress and is achieved when specified conditions are met.

Event listener. An event listener (empty circle) is sensitive to changes that can happen in the case file or can happen to stages, tasks or milestones. Event listener is further refined as a timer event listener (circle with a clock) or user event listener (circle with a person). The start time of a timer event listener is dependent on a case file or plan item (stage, task, or milestone) condition. The duration of a timer event listener is dependent on a date and time, a duration specification, or a start-end interval specification. A user event listener is triggered by a user action. The user must be in one of the specified roles.

Connector. The dotted line of a connector indicates a plan item at the start of the arrow that must be completed for a subsequent plan item to become enabled. When connected to an entry sentry, the completion of the source plan item is the trigger for evaluation of the sentry.

Graphical Decorations

Graphical decorator icons are used to define specialized characteristics of graphical elements. Fig. 4.7 shows the decorator icons and graphical elements to which they can be applied. The first three (columns) appear on the border of planning items; the last four appear inside the lower border.

Planning table. The planning table icon appears on the top border of relevant planning items. When opened, a planning table defines the sub-set of plan items, essentially, a menu, that can be considered by a user when planning at runtime. The items that appear in the planning table are restricted by rules to those items that are appropriate to the current case context and the role of the person accessing the planning table. The plan items are described as discretionary since their use in the plan is subject to the discretion of the user. Discretionary items are shown with dotted-line boundaries. The context for planning based on a planning table is a stage or human task associated with the planning table. A planning table may contain links to other planning tables to form a menu hierarchy.

Entry criterion. An entry sentry appears on the border of a plan item and controls entry based on a rule. The rule is evaluated when the on-part becomes true (eg, the incoming connector becomes active) and the if-part evaluates to “true.” Multiple connectors to one sentry requires an “and” event when all become enabled. Multiple connectors to different sentries requires an “or” entry event—any connector can trigger evaluation of its entry sentry.

Exit criterion. An exit sentry appears on the border of a plan item and determines when an exit can occur from the plan item. If the sentry if-part evaluates to “false,” then exit from the plan item will be delayed until the sentry enables exit.

Auto complete. A stage (including a case plan) by default requires a person to enable exit from the stage allowing for additional plan items to be added prior to completion. If auto complete is set to “true,” then the stage will go to completion whenever all of its plan items are completed.

Manual activation. If an associated plan item is enabled, a manual activation rule defines if an associated plan item requires activation by a human. The default is “true” (manual activation is required).

Required. If a required rule is “true,” a plan item must complete before its containing stage is allowed to complete. The default is “false.”

Repetition. A repetition rule indicates if an associated plan item is allowed to repeat. If the rule evaluates to “true,” then the plan item will repeat (a new occurrence is created) each time its sentry enables entry. The default is “false.”

The Case File

The case file contains, directly or indirectly, all of the information relevant to a case, including the case plan. The case file has a hierarchical structure composed of Case File Item Definition elements. These either contain the item of interest or may provide a link to the item of interest.

The case file is updated as the case evolves. Updates may occur from tasks in the case or from external sources. The case file is then the basis for occurrence of events of interest to the case—event listener and sentry rules refer to case file items. Of course, changes to case file items that are externally referenced cannot be referenced in event rules.

Case Modeling Challenges

CMMN is a new specification, and, at this writing, there is limited application experience. The CMMN specification defines modeling requirements and only implies the runtime functionality of a CMMN implementation. Consequently, there may be considerable differences between runtime implementations.

In addition, CMMN modeling is a new discipline. Certainly there are similarities to BPMN models, but the CMMN model developer must think differently about the possible evolution of a case and the roles of participants.

In the following paragraphs, we will consider potential features of runtime implementations and modeling practices.

Runtime Features

Runtime features will depend on the innovation of implementers, but here are some to be considered.

Mobile technology. Access to mobile technology, such as smart phones and tablets, is fairly obvious, but case management should take full advantage of voice, video, text, email, and mobile applications. Mobile technology must not only connect participants to the case management system, but it must connect them to each other. They must be encouraged to collaborate.

Integrated forms. Forms must be designed for the requirements of the case type. Participants must understand that filling out a form updates progress on the case and communicates information to other participants. Forms must be designed to be quickly and easily completed. Known fields must be prepopulated. Traditional forms that capture everything must be broken apart to forms appropriate to particular aspects, so they can be completed and submitted without waiting to get more information.

Collaboration support. Participants need to know each other's status, not only their status on the case but also their availability for discussion. The result of collaboration between some of the participants should be communicated to the others. The conclusion to an email thread might be recorded as a result with a reference to the email thread. It should be possible to send a text message to multiple participants—more like a case team Twitter. Users must perceive the case management system as something that helps them do their job, not as a burden.

Web access. Tasks should be supported with relevant information. A user should be presented with key information from the case, along with a menu of links to information of potential interest from the case and from the Web. It should be possible to easily incorporate relevant links into the case file record.

Ad hoc listeners. Users must be able to define listeners (generates an event when a condition becomes true as personal reminders or alerts to others). This means that it must be easy to compose a listener condition. Potentially the user should be able to compose a condition by identifying a case file item type to trigger action on arrival or change and selecting from fields on that form or others for required values.

Inter-case coordination. Multiple cases can be related. This may be because one case engages another because a larger process engages multiple subcases, or there are other relationships with shared subject matter. Case listeners are driven by the case file, so a case listener cannot be driven by updates to a different case file. One approach is to have cases share a case file, but this may not be practical or possible for various reasons. Consequently, it should be possible to incorporate a case file item from another case. In order to make this information also available in the case record, the system should retrieve the target item when it becomes referenced by a listener and, subsequently, whenever it changes. This requires that the source case honor an event subscription request (discussed in Chapter 8).

Approval/concurrence. Certain actions in a case will require that a second participant concur or approve of an action. This should be an attribute of the task that requires approval and a subsequent approval task. The case file item requiring approval should not be updated until approved. The draft item might be held as a draft item pending approval. The participant that creates the item to be approved should retain control of the item until an approver has been identified and has given approval.

Case displays. Participants as well as others will need to view the current plan and history of a case. This requires displays at different levels of granularity and abstraction. For example, a display of stages without detail or detail of activities within a stage, or activities of a particular participant or activities affecting a particular case file item.

Dependencies. When a user adds planning items to a plan, each planning item may need to be connected with other planning items. The system should highlight where it may be appropriate to add connectors and assist the user in making the connections. For example, a task will often need a deliverable completed by an earlier task. A listener is not meaningful if not connected to a task to be initiated.

Rule-based guidance and constraints. It should be possible to associate a rule-based facility to selected tasks to provide guidance or validation for certain actions. The rules might be applied when the task is enabled or when it is committed. The rules may include not only case file facts but also questions to be answered by the participant. The action might also require approval by another participant who might also need the guidance. The guidance should become part of the case file record to define the circumstances when a decision was made.

Personal libraries. Participants, particularly case managers, should be able to maintain personal libraries of planning items by case type. These should not enable them to do things that they otherwise are not authorized to do, but this will not only enable users to improve usability and gain their support, but it may be a valuable source of improvements to the case model.

Modeling Practices

The primary goal of the model developer must be to make it easy for users to do what they want to do that is not otherwise prohibited by their authorization, regulations, or adverse consequences. The CMMN modeling language is quite complex; the model developer must find ways to hide this complexity from the participants and, hopefully, make interactions with the case intuitively obvious.

Stages. A first step in case model design will be to identify stages that are meaningful to participants. This will define the basic framework for the case model, and it will also be used for others to check progress on the case. Stages may be associated with subteam activities that occur either sequentially or concurrently—this can help simplify the model for each of the subteams. Stages also should be the primary context for planning tables.

Definition of Roles. The developer must identify who (roles) may participate, how they may contribute, and the scope of their authority. This information will be important throughout the modeling effort and may evolve as the case possibilities become better understood.

Planning table design. Planning tables must consider not only the current case context, but the role of the participant that will be using the planning table. The purpose is not to restrict the participant, but to provide the right information and avoid presenting too much information. The planning table is a table of contents. It should start as an indented list, and then, a description of each selection should be added. This can be done in word processing. The description will help sort out both what the selection is for and what it should add to the plan.

Adaptable fragments. Plan fragments should not only be specific segments that may occur but most-common patterns that can be adapted to the particular circumstances. This makes larger fragments useful and reduces the work of planning the routine case. In some cases, a fragment may define the stages of an entire case to be supplemented or adapted by participants.

Ad hoc tasks. Participants will occasionally need to add tasks to the plan that were not anticipated by the model developer. There should be a set of relatively undefined tasks that the participant can select and adapt to the particular circumstances.

Adaptable listeners. Similar to ad hoc tasks, a participant may want to post a particular listener that is not typical of the case. The participant should be able to adapt a partially configured listener condition.

Case examples. Case examples are important food for thought. The current case workers should be asked for examples of unusual or difficult cases and how they were resolved. The model developer must then consider how each of these could be assisted with case management. Then the solutions should be reviewed with case workers.

Possible outcomes. Possible outcomes are a source of exceptional circumstances. Working backward from each outcome, the developer should explore the potential circumstances that could have precipitated the outcome. There may also be guidance, constraints, or listeners that could have avoided or mitigated adverse outcomes.

Case history. Case files should be examined for new patterns that could better be addressed by the addition or modification of plan fragments. Adaptations of fragments, use of ad hoc tasks, and adapted listeners require particular attention.

Agile development. Developers and their managers must expect that case model development is an iterative process. Developers must iteratively develop and refine the model with feedback from peers and users. New models or significant changes must be introduced with caution for fear of turning-off users, so they only use the system as little as possible. Feedback from users must be considered seriously and promptly.

Business manager role. It may be appropriate to include a special role in a case for the responsible business manager. This is not the same as the case manager. The business manager will want to know about the progress or delays in the case. That manager may have fragments with listeners for particular progress and timer listeners for delays in progress. When there are particular concerns about a case, that manager will want to post special listeners to keep track.

Guidance and constraints. A developer should look for actions or decisions that are either complex or time-consuming or have potentially adverse consequences. The tasks where such actions or decisions are to be made should engage a rule-based guidance component. This will require an appropriate extension to the standard CMMN modeling capability.

Prescriptive Processes

Fig. 4.8 illustrates a fragment of a VDML activity network. A shipment and associated invoice are received into stores since they are coming from an independent business as an asynchronous exchange. One shipment may arrive before the invoice and another may arrive after the invoice. The Authorize Invoice Payment activity is to match invoice to shipment and either authorize payment or reject the invoice if it does not properly match a shipment. The input deliverable flows will each be one deliverable per unit of production. The output deliverable flows are alternative outputs, so the sum will be 100% of production.

Fig. 4.9 illustrates a possible transformation of the VDML fragment of Fig. 4.8 to a BPMN process fragment. This BPMN process fragment must address the possible payment for individual shipments. The invoice is received by the first activity. If the invoice arrives after the shipment, then the first gateway is satisfied (the shipment has been received). The second gateway is satisfied if the invoice has been received and the shipment is received within the time allowed, so control proceeds to the authorize payment activity.

However, the invoice may arrive before the shipment, so the first gateway directs control to the Wait for Shipment activity. This activity completes if it receives an event for shipment received; otherwise, a timer expires for failure of the shipment to arrive and the invoice is rejected. When the shipment arrives, it is matched to the invoice and the content is validated. If there is a proper match, payment is authorized, otherwise it is rejected.

The additional detail is a result of explicit handling of individual shipments whereas the VDML representation only addresses statistical measurements. The duration of the VDML Authorize Invoice Payment activity is different for the alternative outputs. For the Authorize payment output, it is the statistical average of shipment received first and the amount of time waited for a shipment received later. For the Reject Invoice output, it is the average of the Authorize Payment duration for unmatched invoices and the expired time for shipments not received. The allocation of deliverables to the two outputs of the VDML activity are the percentages of production that are the “Authorize” versus “Reject” outputs of the process.

Adaptive Processes

A VDML representation of an adaptive process will include activities that, when they occur, will be somewhat predictable. Many activities may have relatively predictable measurements, but they will only affect the value stream measurements based on their frequency of occurrence. For example, measurements of activity durations will be more relevant to costs than to duration of the overall process since it is so unpredictable. Some activities will be dependent on deliverables from other activities, so there is some predictability of when they can occur.

Consider a collaboration for medical diagnosis in Fig. 4.10. The duration of each activity may be relatively predictable, but sometimes, some activities (here the three activities to obtain blood analysis) may not occur at all. An average duration for the examination can be computed based on the durations and percentage of flows out of the Examine activity, but the variance is substantial. An overall duration can be observed for the collaboration and associated with the value measurement for the collaboration rather than the individual activities.

In other cases, for example, a hospital stay, some activities, or groups of activities may be recurring, such as repeated blood tests or medication administration. These may be described in terms of duration and frequency of occurrence.

On the other hand, roles can be identified and assigned pending the need to perform the activities for those roles. The VDML model could be a collection of unordered activities and process fragments with associated roles along with a percent of occurrence (eg, percent of patients served by the activity). The repetition of an occurrence (if a patient is examined for vital signs every few hours) may be used to compute total occurrences based on the average patient length of stay.

This unordered collection can be refined in two ways: (1) dependencies should be shown when an activity requires a deliverable from another activity and (2) most cases pass through stages where only some of the activities are relevant to each stage. Stages may correspond to activities in a capability method where those activities each delegate to a collaboration of the activities within the corresponding stage.

Such a model is still of value from a top management perspective. The average cost of a type of case can be the basis for setting priorities for research into improved technology, methods, or case planning. The variance of measurements and occurrence of certain activities can be a basis for consideration of improvements. Measurements of other values of concern to customers will still be important and can be traced back to relevant activities.

The VDML model cannot provide more predictability than the CMMN case model, but the measurements and their variance can provide important insights not apparent from looking at a CMMN model. This also can provide a basis for managers to identify particular operating measurements for early identification of problem cases.

Business Collaboration Management

BPM is a management discipline that focuses on the design of repeatable business processes and continuous improvement of the speed, cost, and quality of business processes. BPM emerged when much of the work of an enterprise was repetitive, human work—repeatable processes. BPM emphasizes the definition and documentation of repeatable business processes to optimize performance and as a basis for analysis and improvement. This includes both manual and automated business processes. BPMN has become the generally accepted standard language for specification of repeatable business processes.

The future of BPM is not clear. Advances in technology and business design are outside the scope of traditional BPM, and there is a need to redefine BPM to bring a broader perspective and new discipline to defining and modeling the way the business works.

As we discussed in Chapter 2, an enterprise can be characterized as a network of collaborations—people and machines working together for a shared purpose. In VDML, the detail of collaborations can include roles of participants, performing activities, exchanging deliverables, contributing value and exchanging deliverables with other collaborations. VDML represents an abstraction of collaborations appropriate for management-level analysis and decision-making. From this perspective, we propose BCM as the next generation of BPM.

BCM should link the conceptual business design supported by VDML to the operational design—the operational collaborations along with resource management and organizational alignment. In operational design, specific requirements must be defined for individual business transactions including activities, events, decisions, iterations, and exception-handling along with management of personnel, facilities, methods, and resources.

In this section we will assess the current challenges of BPM, propose a mission for BCM, describe the scope of BCM, assess the business value, and identify management challenges.

▪ Summary and Moving Forward

This chapter has focused on business process design, or more generally, design of business collaborations to include adaptive and ad hoc collaborations not previously addressed by BPM. This expanded scope along with advances in technology and the recognition of the enterprise as a network of collaborations, has highlighted the need for a next generation BPM to have a much stronger role in the operational design of the enterprise.

The next generation of BPM must complement the conceptual business design supported by VDML with operational, detailed design required for actual operation of the enterprise. We have discussed the design of collaborations of different types and in various contexts to provide a deeper understanding of the challenges and opportunities. Finally, we have proposed the development of a BCM practice to address this broader scope and fill the gap between the management-level, conceptual business design and the actual operation of the business.

In the next chapter, we will discuss business rules. At a detailed level, rules determine process flow of control and data integrity. However, rules must also be the mechanism for implementation of policies, the computation of guidance, problem analysis and business decisions, and, in some cases, the mechanism for generating a process. Rules make critical aspects of business processes more visible and manageable from a business perspective.