What’s in your Business Model? You Better Make some Good Decisions!

According to Al-Debei and Avison, a business model is an "abstract representation of an organization” that achieves strategic goals and objectives. Other definitions include phrases such as " a recipe or context for creating value". However you define a business model, there must be a mechanism to execute the plan and achieve the objectives. Process modeling is the prevalent technique for designing the action plan of the recipe. Yet, there are limitations to value chain analysis and workflow diagramming. These artifacts, while useful at a high level, leave out the critical details that create the value and strategically differentiate the model from the competitors —especially the decisions the participants make to deliver or receive value. So increasingly the process, the decision and the event are the most common metaphors for modeling the business objectives. The global standard for visually modeling the process, decision and event is Business Process Modeling Notation (BPMN) and Decision Model and Notation (DMN). Business Model outcomes or the goals are measured with key performance indicators (KPIs) and metrics. The notations, the data, and associated KPI’s are the keys to building a functional, automated business model.

A business model is implemented through event-activated, decision-directed processes:

• A process is an orchestrated sequence of activities.
• An event is a time-based occurrence of something significant or of interest.
• A decision is a resolution of a question or a determination of a proposition.

The three are fundamentally different. Decisions are instantaneous choices while the process models the actions: a coordination of interactions, over time among participants. The event is observed either from incoming messages or transactions from customers and trading partners or from an analysis of external data. Often a decision determines the type and validity of the business event. Because they are different elements of a business model, it is useful to ascribe different characteristic KPI’s and Metrics to the process, decision and events.

Technically speaking, the process, designed in BPMN, is visualized as a series of tokens: markers that proceed through the pathways of the process. BPMN supports a series of workflow patterns that coordinate activities and interactions over time. When you use products that support BPMN, your technical team will have a rich tool set to solve the complex problems posed by the business model. The alternative is for infrastructure developers to develop their own approaches, a risky, expensive proposition.

Process is Important

Because BPMN models describe processes over time, instances can be long-running and must be hardened against failure. Orders, equipment maintenance, case work and other things can take weeks to complete. Naturally, businesses need to know the states of their processes. They need to be able to move them, correct them, stop them and restart them. Processes must be able to handle exceptions and recover from reasonable failures. Business also needs to know how well the process is running, what resources are consumed, what value is being created by the processes. These are process-specific KPI’s: how many, how fast, how much rework.

Decisions are Critical

At a fundamental level, the process should follow a path that is controlled by precise decisions that direct the best outcome for the circumstances. These decisions can select what should be done next, who should do the activity, and what information should guide the process. These are known as operational decisions. Decisions are the entry points for analytics and big data. The very nature of these analyses is to provide the information to make precise, tactical decisions.

This process, designed in the BPMN-based Signavio Process Editor depicts a process responding to an order. The decision, shown in the first box is: “Contract or Commercial Purchase?”

The decision, designed in decision model and notation (DMN), is a hierarchy of logic that is supported by decision tables. The evaluation of decision tables are based on various forms of directed graphs (basically a decision tree). The decision trees execute immediately. The logic in the decision tables and the values of the expressions decide the questions. This is where the intelligence of the business model resides, the mechanisms for choosing the correct alternatives: what to buy and sell, how to ship it, what to finance, how to avoid assuming too much risk, and what to do when a trading partner is bankrupt, or loses their credentials.

This decision, modeled in the Signavio Decision Manager depicts the selection of a contract or a direct commercial purchase. The decision directs the process in the model above.

The business model responds to events. Many business events are straight forward: customer purchases, employee onboarding, and budget depletion. Other business events can be complex: weather risk, asset depletion, public opinion.

When developing a business model, it is critical for business managers and stakeholders to think in terms of processes and how the decisions they make affect their operations. They should also think in terms of the business events and how well the processes respond to them. The visual models of BPMN and DMN represent maps of the reality that they are trying to create in for the business models. Events occur, business respond to them, the processes follow the directives. Business decisions are relatively new to the process modeling works; however, many businesses are providing equal weight to decisions.

For a free 30-day trial of the Signavio Process or Decision modeler please go here:

SOURCE: LinkedIn

What is BPMN? Simple introduction for any audience

7 Key Steps for Automating Document Workflows

First of all, document workflows are “an orchestrated and repeatable pattern of business activities enabled by the systematic organization of resources into processes that transform materials, provide services, or process information”.

Every organization uses document workflows to complete daily tasks. Automating document workflows with a BPMS can provide many benefits, but you may not know where to start.

In this post we will summarize 7 key steps to automate document workflows. You can use them as a check list to implement and centralize your business processes in your BPMS.

If you follow these steps, you will fully automate your document workflows, eliminating papers, Excel spreadsheets and informal communications (emails, chats, etc.).

The 7 key steps to automate a typical document workflow of a small business are:

• Choosing the first workflow

It’s important to start with the right process. The chosen workflow must balance its complexity (document flow, users involved, etc.) and its importance to the organization.

Ideally, choose a process that is directly related to the organization’s value proposition to motivate the team and see immediate results.

But it should also be relatively simple to model, as it will be your first automated workflow and you don’t want to become discouraged or frustrated.

• Model it quickly

Recognize the main stages of the document workflow and don’t waste too much time on the details. The main thing here is to design a simple diagram using a precise -yet easily understandable- notation.

We recommend using BPMN (BPM Notation): an intuitive international standard. Plus, there is a lot of information available about this notation.

Flokzu works with BPMN and our setup wizard will guide you through the process when needed.

• Identify participants

* Identify key users and roles working on the process.

* Identify which user and role work on every step of the workflow.

* Identify which tasks do the users and roles do. This will define the access level of each participant: Reader, Editor, Owner, etc.

• Link related forms

* Identify what types of data (or fields) are relevant to the document workflow. Example: A vacation request approval workflow may involve a form for entering dates, details of the employee, etc.

* Define which form fields are visible, editable or required at every stage of the workflow.

* Identify which information or fields should be searchable to filter information or classify it.

• Attachments

* Define the files that can be attached along the document workflow.

* Define if it will be necessary to search through attachments.

• Select the right tool and automate

Depending on the requirements identified above, select the right tool that covers your needs.

There are different types of BPMS:

* Document oriented: best suited for administrative use in a small business.

* Production oriented: more suitable for industrial companies with integrated production machinery. Not recommended for document workflows.

* Integration oriented: suitable for less human interaction and multiple systems integrations. Not ideal for document workflows.

• Measuring

A month after having automated your document workflow (following the above steps), measure the results using at least these numbers:

* Processes initiated in certain period.

* Average time required to complete a process

* Time required for each stage. This allows you to detect possible bottlenecks.

After improving and optimizing the document workflow, implement it once again and repeat the measuring step one month later.

These improvement cycles should be completed quickly. That’s why advanced BPMSes enable each step without requiring additional programming or complex configurations. Any employee of the organization will be able to automate a document workflow without the help of IT or technical knowledge.

SOURCE: BPMLeader

BPM Explained - Part 2

Yesterday I tried to explain BPMN to those who don’t know what it is.  OK, they are probably saying, if BPMN is so great, why do I hear these complaints about it?  Yes, that’s a good question.

First, you need to understand exactly who is complaining.  If it’s a legacy tool vendor wedded to their proprietary (“much better!”) notation, well that speaks for itself.  Ditto if it’s a gray-haired process improvement consultant whose idea of a modern tool is a whiteboard that prints.  Which is most of them.  But even if you cross those guys off the list, there are normal end users who complain about it.

One complaint is there are too many shapes and symbols.  Actually, there are only three primary shapes, called flow nodes: activity, the rounded rectangle, denoting an action step in the process; gateway, the diamond, denoting conditional branching and merging in the flow; and event, the circle, denoting either the start or end of a process or subprocess, or possibly the process’s reaction to a signal that something happened.  Just three, much fewer than a legacy flowcharting notation.  In BPMN, the solid arrow, called sequence flow, must connect at both head and tail to one of these three shape types.

The problem is that the detailed behavior of the flow nodes is actually determined by their icons, markers, and border styles.  There are way too many of those, I will readily admit.  Only a small fraction of them are widely used and important to know; the rest you can simply ignore.  When I started my BPMN training many years ago, I identified a basic working set of shapes and symbols called the Level 1 palette, mostly carried over from traditional flowcharting.  The purpose was to eliminate the need to learn useless BPMN vocabulary that would never be used.  When BPMN 2.0 came out 4 years ago, they did a similar thing, officially this time, but for a different purpose.  The so-called Descriptive process modeling conformance class is essentially the Level 1 working set.  Its purpose, from OMG’s standpoint, was to limit the set of shapes and symbols a tool vendor must support in order to claim BPMN support.  So… if you are new to BPMN, just stick to the Level 1/Descriptive working set.  It will handle most everything you are trying to show, and good BPMN tools in fact let you restrict the palette to just those elements.

I sometimes hear the opposite complaint, that BPMN does not have a standard way to visualize important information, like systems, organizational units, task completion times, or resource costs, available in their current process modeling tool.  Actually, many BPMN tools do have ways to include these things, but each in their own tool-specific way.  BPMN just describes the process logic, that is, how the process starts and ends and the order of the steps.  It doesn’t describe the internal details of a task, like its data or user interface, or decision logic, or systems involved, or important simulation parameters.  Its scope is quite limited.  There are some emerging standards for those other things that will eventually link up with BPMN, but they are not yet widely adopted.  Anyway, it’s important to distinguish the information a BPMN tool can support from information that is part of BPMN itself.

Finally, some people don’t like the fact that BPMN has rules.  A tool validating models against those rules might determine, for instance, that the way you’ve been modeling something for years is invalid in BPMN.  You can ignore that, of course, but remember the goal of BPMN is clear communication of the process logic.  A diagram that violates the rules of the specification probably does not do that very well.  Like any new language, BPMN asks that you take a little time to learn it.  It’s actually not that hard.

SOURCE: Bruce Silver

BPMN Explained

On Twitter someone posted to me: “Have you ever seen a short overview of BPMN that makes sense to people who have never heard of it?”  Hmmm… Probably not.  So here is my attempt.

Business Process Modeling Notation, or BPMN, is a process diagramming language.  It describes, in a picture, the steps in a business process from start to end, an essential starting point whether you are simply documenting the process, analyzing it for possible improvement, or defining business requirements for an IT solution to a process problem. Dozens of process diagramming languages have existed since the 1980s at least, so what’s so special about BPMN?

First, BPMN is an open industry standard, under the auspices of the Object Management Group.  It is not owned by a particular tool or consulting company.  A wide variety of tools support it, and the meaning of the business process diagram is independent of the tool used to create it. With BPMN you don’t need to standardize on a single tool for everyone in the organization, since they all share a common process modeling language.

Second, unlike flowcharts created in a tool like Visio or Powerpoint, the meaning of each BPMN shape and symbol is quite precise – it’s defined in a specification – and in principle independent of the personal interpretation of the person who drew it.  I say “in principle” because it is possible to violate the rules of the BPMN specification, just like it is possible to write an English sentence that violates accepted rules of grammar or spelling.  Nothing drastic happens in that case, but the diagram’s effectiveness at communication is decreased.

Third, BPMN is a language shared by business and IT, the first process modeling language able to make that claim.  When BPMN was first developed about 10 years ago, the only available process modeling standards at that time – UML activity diagrams and IDEF, among others – were rejected as “IT standards” that would not be accepted by business users.  To business users, a process diagram looked like a swimlane flowchart, widely used by BPM practitioners but lacking precise definition in a specification.  BPMN adopted the basic look and feel of a swimlane flowchart, and added to it the precision and expressiveness required by IT.  In fact, that precision and expressiveness is sufficient to drive a process automation engine in a BPM Suite (BPMS).  The fact that the visual language used by the business to describe a proposed To-Be process is the same as the language used by developers to build that process in a BPMS has opened up a new era of business-empowered process solutions in which business and IT collaborate closely throughout a faster and more agile process improvement cycle.

Even if you have no intention to create an automated process solution in a BPMS, BPMN diagrams can reveal information critical to process documentation and analysis that is missing in traditional swimlane flowcharts: exactly how the process starts and ends, what each instance of the process represents, how various exceptions are handled, and the interactions between the process and the customer, external service providers, and other processes.  The rules of the BPMN specification do not require these elements, but use of best-practice modeling conventions in conjunction with a structured methodology can ensure they are included.  My book BPMN Method and Style and my BPMessentials training of the same name are based on such an approach.

So yes, there is a cost to adopting BPMN, whether you are moving from casual tooling like Powerpoint or Visio flowcharts or from a powerful but proprietary language like ARIS EPC.  There is a new diagram vocabulary to learn, diagramming rules, as well as the aforementioned conventions and methodology such as Method and Style.  But the benefits of speaking a common process language are tremendous.  The investment in process discovery and analysis is far more than the cost of a tool or the time required to draw the diagrams.  It involves hundreds of man-hours of meetings, information gathering from stakeholders, workshops, and presentations to management.  The process diagram is a distillation of all that time and effort.  If it cannot be shared across the whole project team – business and IT – or to other project teams across the enterprise, now or in the future, you are throwing away much of that investment.  BPMN provides a way to share it, without requiring everyone to standardize on a single tool.

SOURCE: Bruce Silver

8 Common Challenges of Business Process Analysis

Oracle Business Process Management

Just in Time Process Modeling

One of the persistent criticisms of BPM is that the process definitions are too rigid to accommodate the realities of modern business.  This can deter organizations from properly evaluating how BPM can help them.  The reality is that most BPM tools offer a range of options for building highly flexible and adaptable processes.  In this article, we will briefly explore some of these.

Researchers have proposed various approaches to this which can generally be grouped into two categories, Late Modeling and Late Binding.  With Late Modeling, some portions of the process are not specified until runtime, allowing each instance to potentially be different.  InConcert supported this from the mid 90’s but hasn’t been sold for several years.  It was a powerful, but challenging capability that was widely used by their customers.  We know of no current commercial product which supports this to the same extent.  With Late Binding, sub-process calls are not statically defined, but are expressions of some sort.  Several current products, including IBM Business Process Manager support this.  This allows variability at a fixed number of points in the process.  Perhaps one reason this is not more widely supported is that it is outside of the BPMN specification.  However, there is another approach which is available in most current products and fully within the BPMN specification.

Before proposing a solution, let’s dig a little deeper into the reasons flexibility is desirable in business process models.  Reichart and Weber in a recent book Enabling Flexibility in Process-Aware Information Systems, provide an extensive analysis of different forms of flexibility and business motivations for each.  They define four categories of flexibility.  We will look quickly at each.

Variability, where different process instances have relatively minor and predictable variations.   In the simplest cases, variability is handled with gateways and including all variants in a single process.  This becomes unmanageable as the number of variants increases.  Late binding of sub-process specifications can support more variability by substituting alternate implementations of the variable portions of the process while maintain a simpler overall process structure.

Looseness where the goal is known, but the course of action to achieve it cannot be predicted.   While the required sequence of steps cannot be known in advance, the set of possible actions probably is known.  A library of sub-processes can be made available, with the selection of the next one either by a person or some rules logic.  Potentially each process instance follows a unique path, but all are assembled from the same set of components.

Adaptation where active process instances need to respond to events occurring during their lifecycle.   To handle variability, we used late binding of sub-processes at known locations.  To support adaptation, we recommend event driven triggering of sub-processes combined with late binding.  Each process instance responds to the actual events which affect it.

Evolution where the business process changes, and active processes must be updated to the new process.  Support of evolution is most important in longer running processes.  Since the new processes were not known when some instances started, they could not have planned for them specifically, but if the process definition consists of a sequence of deferred sub-processes, new versions can be substituted.  As a practical matter, there will be limits on compatibility of new versions with the interfaces of old versions, but it is possible to deploy new process definitions into running process.

All of these scenarios can be implemented within the BPMN specification using capabilities found in nearly all current BPM products.  Intermediate Send Message Events, followed by Intermediate Receive Message Events can replace Call Process activities.  The message is received by a Start Message Event in a process with a corresponding send message end event.  The behavior is similar to a sub-process call, but is more flexible.  The invoked sub-process can be specified by the message content and new versions of the sub-process can be deployed and immediately invoked from any running instance of the main process.  The future behavior of running processes can be changed without directly modifying those processes.   This is equivalent to late binding of sub-process calls.

We have successfully used this approach to solve most of the scenarios described above.  We will provide some simple examples to illustrate some of these.
This process fragment:

Combined with this process:

Behaves similarly to a BPMN Call Activity.  Execution is transferred to the second process and returned to the original when it completes.  However, it also offers options not available with a standard Call Activity.  The most obvious and useful is that message correlation allows runtime selection from multiple versions of the “sub-process”.  This potentially includes new versions which were defined while the top level process was running.   This simple pattern satisfies most requirements for Variability and Evolution as described above.

To achieve Looseness, we can expand the pattern slightly by putting the invocation in a loop with a user or system step to determine the next action.

These two patterns, along with the Event Sub-Process can provide the flexibility required in many business situations.  That doesn’t imply that we should always use these instead of the standard sub-process mechanisms.  To achieve flexibility, we are using much looser coupling between process components.  This can make monitoring, reporting and failure analysis significantly more complicated.  You should always balance the benefits of flexibility against its costs.  There are many situations where use of these modeling techniques allows solution of problems which statically defined processes cannot. Adding these to your set of modeling tools will significantly expand the range of business applications where you will be able to use BPM.  We encourage you to experiment with these to evaluate how they can help you better accommodate your organization’s needs.

SOURCE: bpminstitute.org

BPMN Tutorial - Part 3 - Animating Scenarios in BPMN Processes

BPMN Tutorial - Part 2 - Collaborations

BPMN Tutorial - Part 1 - Simple BPMN Workflow (Business Process Modeling)

BPMN Tutorial - 5 Minute Basics of BPMN