Business Process Management


As I mentioned in a prior post, a Business Event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities. Business events are a recent ‘buzz’ or focus in the BPM world. With respect to event process modeling, I believe there are two categories of events:

  • External Business Events:  EBE’s, in combination with business rules, provide channels for messages in BPMN business process. For example, a purchase order has been issued through an X11 file, critical equipment has been recalled by the manufacturer, and sensor data has reached a limit.  
  • Internal Business Events: IBE’s can arise, from the IT infrastructure and a business process is particularly adept at handling these.

IBE’s and EBE’s form the global cloud of events .

IBE’s and EBE’s can be seen indirectly in the OMG’s Business Motivation Model. The OMG’s BMM is an essential link between business planning and modeling and business processes management. It utilizes a set of integrated concepts to define the elements of a business plan. These elements support a variety of approaches for creating and maintaining a business motivation model for the enterprise. As seen in the figure below, a business motivation model is parameterized in terms of means, ends, influencers, and assessments. It includes reference elements and business vocabulary. BMM is particularly strong where business change drives supporting processes.

 

Business Movivation Model
Business Motivation Model

As its name suggests, motivation is key to the business motivation model and is deeply tied to the mission of the organization. With the BMM you can chart connections between vision and goals and objectives, and link mission into strategy for approaching these goals and tactics for achieving the objectives.

IBE’s and EBE’s arise from the influencers portion of the model. Internal influencers can assessed to be strength or weaknesses and an internal event, such as reaching or missing a key performance indicator, can be one of these. External influences (which are counted as opportunities or threats) are analyzed as parts of the business plan. Obviously, the external events we mentioned above might be an influencer.

Event Based Architectures and Complex Event Processing (CEP) is an increasingly important part of today’s advanced enterprise architectures.  The event-driven process is one of the seven important process usage patterns. Organizations use the pattern to interact and respond to a growing volume of business events and transactions on a daily basis. To create an effective event-driven process you will need a new form of analysis.

Event analysis is an emerging area of business process modeling that develops support for the decision-based processing of enterprise-significant events. It is also increasingly an important part of strategies for the evolving internet of things and important aspects of advanced architectures in High-Consequence Systems Architectures, including C2 applications such as situational awareness.

Chandy and Schulte define   ”A business event is an event that is meaningful for conducting commercial, industrial, and governmental or trade activities.”  The event we refer to here is not the various BPMN events of the circular kind . We are referring to events that occur outside the walls of the organization. An event is Boolean, in nature, it either happened (True) or not at all (False) The event is meaningful because it might affect a business process as an external message or channel that one or more processes must consume, activate and respond.

Do not confuse the business event with complex event processing (CEP). CEP is approach to deselecting events that reveal the event with a SQL-like language.

Consequently, we have a new metaphor that is important in business process modeling: the business event. The table below lists the important distinctions between the three business metaphors.

 

Business Event

Business Process

Business Decision

Unpredictable or random in nature (an external stimulus)

Stateful in Nature

Stateless In Nature

Is monitored by environment and filtered, sorted and correlated by rules

Sequence of activities conducted by participants

Logic, computations and business data, create actions and outcomes.

Based on observation

Sequence of activities and monitoring and control for participants

Actions, direction, control for events and processes

Improvements in observations, risk management, agility and understanding

Improvements in process metrics

More consistent policies, tighter control of business strategies (BMM)

Representation is evolving

Visual BPMN

Visual Logic

  Two important aspects of the EVA are components that detect and respond. At Innovations, we have been working with the business event in a numbers of products and engagements. We utilize business rules on the response side in a numbers of ways.   

 
 
 
 
 

 

As Sandy Kimsley pointed out in her links; Ken Swensen responded to the question, is BPM Dead?  In all of our discussions of technology, business processes, business rules, business events, it is easy to lose focus on the basic meaning of business process management.

So, it is useful to review the differences between function- and process-orientation within organizations. Most organizations that use BPM intend to become process-centric. Organizations with a strong process focus are distinguished by having a pervasive, cultural process orientation. Big, complex organizations consider the process focus as very important, and this structure is very common in insurance, healthcare, and financial services. A functional organization orientation, on the other hand, is more prevalent in small enterprises and is well-suited to the way they operate business.

A functional organization is an organization that delivers a deep capability in a limited number of functions. These might include highly specialized product and skills where expertise or availability is limited. Obviously, a functional focus works for them,

Each of these focuses-functional versus process-centricity-has its advantages and disadvantages. In his commendable work on business process management, James Chang created the table below that summarizes the differences between organizations adopting each focus. A functional organization allows an easier balance of work among workers with functional excellence because they all have similar skills. This organizational style outlines simple, comprehensible ways that each task should be performed and assigns this to the appropriate proponent.

 

Functional Organization

Process Organization

Work Unit

Department

Team

Key Figure

Functional Executive

Process Owner

Benefits

Ÿ  Functional excellence

Ÿ  Easier work balancing because workers have similar skills

Ÿ  Clear management direction on how work should be performed

Ÿ Responsive to market requirements

Ÿ Improved communication and collaboration between different  functional tasks

Ÿ Performance measurements aligned with process goals

Weaknesses

Ÿ Barrier to communication between different functions

Ÿ Poor handover between functions that affects customer service

Ÿ Lack of end-to-end focus to optimize organizational performance

Ÿ Duplication of functional expertise

Ÿ Inconsistency of functional performance between processes

Ÿ Increased operational complexity

Strategic Value

Ÿ Supports cost leadership strategy

Ÿ Supports differentiation strategy,

Work Management

Ÿ Functional Quality Focus

Ÿ Cross Functional Coordination

 Table 1 Benefits and Drawbacks of the Functional Versus Process orientation in organizations (Business Process Management Systems, Chang ).

Conversely, a process organization enjoys improved communication and collaboration and may thus be extremely responsive to market requirements. Further, performance is easily measured across the process organization, as it is stated in terms of process goals. However, process organizations suffer from lack of or poorer quality communication between the different functions relative to their functional counterparts. There is reduced end-to-end focus, as opposed to the functional structure. Moreover, there may be considerable duplication of functional expertise, inconsistent functional performance between processes, and increased operational complexity. This may make the structure of the process-based organization redundant and bulky.

- Tom Debevoise

I have been looking at Microsoft Visio 2010 and I would recommend it to anyone seeking a simple process modeling requirements tool. Ultimately, when your ‘requirements’ phase in process modeling is complete, the business analysts must move away from Visio and into the business process management suite.

There are many, many users of Visio who are ‘process focused’. Moreover, there has been a significant investment in process modeling using Visio. When teams, who have not used an execution-oriented framework such as PMF, move these models into execution there will be issues. Visio 2010 Premium will help a bit by doing a very competent job at supporting early (learning and requirements) efforts in process modeling. The ‘check diagram’ function checks the proper syntax of the BPMN shapes. For instance in the diagram below, there are two errors: a message is flowing the wrong way and there is a ‘hanging’ activity.

Wrong

Wrong

After you correct the issues the errors disappear.

noerrors

Casewise, Orbis and others provide Visio ‘bridges’.  Yet, all these will change when other vendors will seek to capitalize on Visio 2010’s new BPMN features. This tool also supports moving process onto SharePoint 2010. Overall, I commend the Microsoft Visio BPMN team for their efforts.

Certainly, combining business process modeling with a business rules approach can create comprehensive, agile solutions that support a business model. Yet, it is not always easy to understand the role of these visual modeling approaches.

Technically, the BPM/Business Rules approach places process logic with the BPM suite and decision logic  in the business rules management system (BRMS). The process logic in a BPM suite sequences and controls activities and launches and cancels processes. Control is achieved with timers and exception handlers. Processes can be designed to recover from errors, restart processes and coordinate activities. The BRMS effectively designs, organizes and executes the logic behind a process decision. An effective BRMS can handle any depth and complexity of decision logic, including computationally complex logic and dense logic.

Clearly, Business Process Modeling Notation (BPMN) and BRMS are important functions for managing a business process. Moreover, processes and decisions can be reused interchangeably.

Assigning the correct problem domain or requirements to Process or Business Decision Logic is not always clear.

Business Process Modeling Notation is the global standard for describing business processes, yet there are no visual standards for business rules. That said, perhaps we can compare Innovations’ Visual Rules notation with analogous shapes in BPMN and discover some of the differences and similarities between modeling business processes and modeling decision logic.

Decisions and Gateways

Probably, the foundation element in Visual Rules is the Decision Shape:

Visual Rules Decision

It is used whenever a rule needs to make a distinction between two or more different situations. In general the Decision shape runs down a sequence of choices.  You can also configure the Decision to evaluate multiple conditions. The equivalent shapes in BPMN are the exclusive and inclusive data-based gateways:

BPMN data-based exclusive   BPMN data-based Inclusive

The outcome of the two gateways is the same as the Visual Rules decision shape: decide among conditions in the flow of the process or rule flow. In Visual Rules, the branch of a decision can end abruptly with and assignment or ‘action’. It has been graphically designed to be concise. A Visual Rules decision set in a rule flow can span many dozens (or even hundreds) of decisions. The equivalent BPMN diagram would be unwieldy.

The objective of Visual Rules is to model business rules that decide with data, while a process mainly coordinates the activities of participants (departments, users and systems). So Visual Rules has no equivalent for the parallel or complex gateway in BPMN. Part of that process coordination might require the same logic as a decision with data. For instance, process attributes might direct a transaction to accounts payable or elevate an approval based of the size of the transaction. Hence, the overlap. Processes manage the concurrency of activities. The parallel gateway can ‘launch’ activities in parallel (split) and wait or merge the activities when they are done. I have never encountered the need to evaluate business rules decisions in parallel.

Subprocesses and Rule Calls

Now let’s reverse the comparison. In BPMN an important shape is the subprocess:

BPMN Subprocess

In Visual Rules the nearest equivalents are the call of a flow rule and the call of a decision table:

Visual Rules Call Rule Flow  Visual Rules Call Decision Table

In BPMN, a subprocess can be self-contained within a participant lane or it can be a reference. In Visual Rules the call to other Flow Rules and Decision Tables enable reuse of logic in decision-supported business rules. You can organize your logic with the call to decision tables and other flow rules. Sets of decisions can be federated, organized according to a topic or business area, or divided into areas of expertise.

The BPMN subprocess might seem similar, yet it is mostly a way to organize and control activities within a process, and reduce the amount of needed notation. For instance, a process might need to post transactions to three operational systems. Grouping these into a subprocess permits the transaction to be treated and compensated as a single process. The subprocess can be timed-out with a timer event attached to the boundary.

Loops and Loops

Speaking of subprocesses, Visual Rules also supports loops with the shape:

Visual Rules Loops

There are three kinds of loops supported in Visual Rules: Looping while a condition exists; for a number of times with a counter; and for records in a list. There are (sort-of) equivalents in BPMN:

Standard Loop:

BPMN Loop and Multi Instance:BPMN Multi Instance

Again, as with other BPMN shapes, the similarities between the Visual Rules loops and BPMN loops  are overlapping yet divergent. Visual Rules loops traverse arrays and vectors of records and apply business rules. These loopsare important for developing complex algorithms. BPMN subprocess loops organize process logic. Also, the BPMN multi instance loop can start multiple process threads.

Exceptions and Others

Visual Rules can raise and handle exceptions such as database errors, math errors, general business exceptions and others. The Visual Rules shapes for these are (raise and handle):

Visual Rules Raise Error  Visual Rules Handle Errors

In BPMN the exceptions, known as errors, are shown as:

BPMN Error

Without delving into the details of BPMN, there are throwing and catching error events. Generally, BPMN exceptions are connected to the boundaries of subprocess.

There are other parallels we can draw. I hope you can see these shapes have overlapping , yet divergent, purposes. In fact, with enough, albeit brute-force effort, there is very little logic that cannot be implemented in either BPMN or Visual Rules. The question is: what is the correct tool for the correct problem area?

BPMN versus Visual Rules: Teams Address the Problem with the Proper Tool

 

I believe these are the salient features of the different problem domains.

A Business decision is mostly stateless and time-invariant. Visual Rules is adept at documenting and implementing complex decisions with clear, visual documentation. Moreover, business analysts can easily learn how to create and manage these decisions in Visual Rules. Next, Visual Rules is designed to complex logical decision: having thousands of branches, loops and decision tables. The Visual Rules Modeler is designed to permit detailed use-case testing, with data. You can debug and ’step’ through complex decisions.

Process logic is mostly concerned with coordinating and managing time-varying objectives and concomitant exceptions and states. BPM/BPMN is adept at managing process instances. Many BPMN shapes, such as the Timer, Error and Compensation Events have been designed to handle unforeseen process errors. BPMN is designed to model and document an enterprises business process. Most BPM tools can ‘play-back’ a process model for process verification. BPMN documents interactions among participants.

It is difficult to manage computationally complex and logically dense logic with BPMN. BPMN lacks the compact, organizational capabilities of a BRMS. Similarly, the BRMS lacks the process automation abilities in a BPMN engine. Because the objectives are different, it is expedient to separate process logic from and business decision logic.

Technology is Important, Peoples and Organizations are More important

Recently, I asked Sandy Kimsley of Column 2 to provide a reference for a great quote she made about BPM/Business Rules. I thought it went something like this: “The Business Rules folks want the BPM tool to call the rules engine then go away and the BPM folks want to never call the rules engine” or something like that.  When I asked her about this she said “I recall saying that the BPM people would build a huge decision tree in BPM rather than call BR, and the BR people just want the BPMS to have one step, which calls the BRMS.”

More to the point, the groups that manage processes and decision logics are very often different. A business process can cross different systems, department and organizations. Decisions are usually the responsibility of one organization (even if many provide the data).

In the business rules world, we often say that it is easier to change decision logic than it is to change process logic. This is conjecturing rather that stating facts.  Today’s BPMS is as adept at managing change as the BRMS. Another favorite saying of the Business Rules community is that business rules change faster that the process. Again this is more conjecture. Both these opinions miss the central point. The team responsible for business rules is almost always different than the team managing the business process. The objective of today’s BPMS and  BRMS is to end loose, verbal or documented requirements gathering and cede control to the owners of the requirements. One group of Subject Matter Experts (SME) uses BPMN to create processes. Another creates and manages the business rules.  BPMN is a visual tool set that empowers process managers and subject experts. The Visual Rules’  BRMS is a visual tool set that empowers decision modelers and experts.

Sandy Kimsley’s had a post on the topic of BPM certification and in the ensuing comments pre-heckled my Business Rules Forum discussion of the OCEB exam.

I want to share my response to her heckle. I like to quote Robert Beer, the great English Tibetian artist: “The difference between the accumulation of knowledge and wisdom may be enormous, ‘There are Learners and there are the learned; memory maketh one, philosophy the other‘. Knowledge is communicable, wisdom is not.”

I believe Dumas was responsible for the inner quotation.

I often work in the Federal Government and the Project Management certification exam (http://www.pmi.org) has proliferated and become a standard requirement for project manager roles. Yet, certification does not assure good project management. Neither will OCEB certification assure good business process management or good business process modeling. Ergo: the warning in my quotation.

The real value of BPM certification is that it will offer the best comprehensive review of the Business Process Management and Modeling literature and practices available today. To prepare for exam students will need to read study and retain an enormously valuable body of knowledge.

The gap between learning and wisdom is not an excuse to forsake learning by any means. (Imagine a wise practioner that is not learned.) The idea that OCEB certification will not lead to good Business Process Management is specious.

During media coverage of the Olympics There was an enlightening interview between Tom Browkaw and Henry Paulson.

That post is available here: (The transcript is here) The interview is worth a listen (with your Business Process Hat on). it certainally presents a macro-picture of the global economic environment.

As the OMG BPMN Members complete version 2.0, the BPM world will be poised to create an updated  global financial architecture. The spec will create tools for choreographing the multitude of financial processes.  Choreography describes how semi-independent and collaborating entities work together in a process, each of which may have their own internal processes. So, financial institutions and the global regulatory bodies will benefit from these concepts. These should operate in a continuously monitored environment. Also, choreography can help to keep these entities loosely coupled and agile. The choreography of a financial process focuses on the responsibilities and interactions (as governed by the regulatory concerns) that ultimately provide value without necessarily requiring any coordinating authority.

Given the objectives of the BASEL II accords and other regulatory frameworks, BPM and Business Rules should become the backbone of a better choreographed architecture.

I have created a short video on the role of Business Rules and Business Process Management.

The video is linked to the graphic below:

Click for the video

You can also view the youTube video here.

A PDF of The presentation is available (user registration required) here.

Enjoy:

I created a short video on my viewpoints on the Process Participant.

Click for the video

You can also view the youTube video here.

A PDF of The presentation is available (user registration required) here.

Enjoy:

As you can see in my link list, our new book The Microguide to Process Modeling in BPMN is available on Amazon. In chapter three, we developed a list of BPMN shapes that can be confusing or hide details.

In the book we argue for the a clear depiction of process models in BPMN. These shapes, while usefull for very technical requirements, will not help this goal.
Some BPMN shapes might not be very useful in a busines-orientedc scenario. For example, there is a multievent shape for an event triggered by any event type. Because it can be misinterpreted, we do not recommend that you use this type of notation. This is also true with the complex merge gateway. It allows any type of split to merge with one generic shape.

Multi Event

Indicates that multiple events trigger these shapes. We are not talking about starting a process with a multi-event, this pattern is usefull. It is the various intermediate and ends we are concerned with. The implementation relies on a runtime engine to execute script or code, therefore the behavior is completely hidden from the diagram. This is useful if you like to write code, but not as useful if you want to effectively communicate with a diagram. Try using the exclusive event-driven gateway with specific event shapes instead.

Complex Merge

Indicates that there are multiple ways to merge flow paths on this shape. While this may seem like a nice shortcut to solve your merge problems, it may introduce interpretation errors and unpredictable merge behavior. Instead, stick to the rule “if you split with it, merge with it.” You can also try using a subprocess shape to merge paths that don’t seem to match up.

Empty Gateway

According to the BPMN specification, this shape is identical to the exclusive gateway. We don’t recommend using it because you are inviting interpretation errors. Being more explicit is always better for accurate communication.

Event Driven Gateway

This is an older version of the event-driven gateway. There are rules restricting this shape so that all attached intermediate events must be identical. The newer 1.1 version (pentagon instead of six-sided star) allows for any intermediate event combination to be attached.

Link Start Event

Signals that the process starts from another page. This does not make sense because if it’s already started it cannot start here. Use the intermediate (catching) Link event instead.
Link End Event

Signals that the process ends here but can continue on another page. This doesn’t make sense because if the process ends, it cannot continue. Use the intermediate Link event instead (throwing).

Excerpts with permission for ‘MicroGuide to Process Modeling’ by Tom Debevoise and Rick Geneva.

Next Page »