What is Business Process Management?

What is BPM?

All businesses have processes. Processes are typically differentiated from projects because processes are predictable and repeatable. They are the building blocks of operating a business.

While many organizations have similar fundamental processes, the unique parts of their processes, dictated by their specific business methods, form the basis of the organization’s competitive advantage and often their “culture.” A process can be defined as a series of steps leading to identified outcomes. Common business processes are often named with descriptions like Opportunity-to-Order, Order-to-Cash, or Employee Onboarding. The sequence of work and steps performed can vary from instance to instance based on inputs, decisions, timing, dates, etc. However, regardless of the value of these variables, to properly define a process one must know all the possible paths and outcomes in advance i.e., predictability.

Business Process Management is a management discipline with the key goals of discovering, modeling, analyzing and optimizing business processes. While some BPM solution providers might include business process automation – a BPM engine or automation platform – as part of BPM, Trisotech defines process automation as a separate discipline. As a methodology, BPM can be thought of as similar to (and sometimes encompassing) other methodologies like continuous improvement (CI) or total quality management (TCM).

Why is BPM Used?

Once a predictable process has been defined through process discovery, it can be optimized – often called process improvement – and performed over and over in a standard way i.e., repeatability. By the act of discovering and defining a process, the resulting process documentation becomes a valuable organizational asset. The use of BPM can improve business operations’ performance and agility, lower costs and add value to customer products and services. Often cited specific benefits include higher efficiency and productivity, reduced costs, increased revenue, better agility, operational consistency, greater customer service focus, better regulatory compliance, increased security, and higher operational visibility.

Business Process Management Software in healthcare

BPM in Healthcare

Utilizing Business Process Management in Healthcare provides a huge array of opportunities to deliver better patient care and services, reduce errors, improve profitability, and ensure regulatory compliance at every level.

More info on healthcare

Process-driven healthcare organizations can create standardized clinical guidelines that facilitate consistent organizational policy, patient diagnosis, treatment, and reporting for both individuals and populations. Business processes can also provide real-time feedback and recommendations to providers, be embedded in most patient encounter systems, and integrate the use of standards like FHIR® and CDS Hooks.

Business processes are not just valuable in the clinical setting, however. They are also extensively used in healthcare insurance and patient services settings. Examples of these types of processes include claims processing, pharmaceutical and durable medical equipment (DME) pre-authorizations and patient, provider, and facility scheduling.

Business Process Management Software in finance

BPM in Finance

Business Process Management is helping to fuel the disruptive FINTECH industry as well as assisting existing financial institutions and service providers in transforming the way they do business to remain competitive.

More info on Finance

End-to-end business processes are facilitating the digital transformation revolution that has put the customer in the center of a 360 degree organizational view. That in turn has led to the optimization of existing operations and customer-centric policies and procedures. Standardized processes lead to higher operational visibility as well as better and more easily audited regulatory compliance.

BPM is driving better risk assessment and management, underwriting decisions, lending automation, servicing automation, insurance claims processing, and many other financial activities. By using predictable and repeatable business processes the financial industry is experiencing higher growth rates, greater profitability, more rapid digital adoption, higher rates of compliance, improved efficiency, and better security than ever before.

Trisotech BPM Solutions
What is Business Process Management Software from Trisotech?

Digital Enterprise Suite

Trisotech provides 100% browser-based business process management discovery and modeling tools in cloud-hosted or on-premise environments. The process discovery tool – the Discovery Accelerator – helps business people describe the Who, What, When, Where, and Why of how their processes work through simple interactive screens and/or existing written policies, guidelines, business rules or other documents. These business observations can then be turned into an initial workflow starter diagram with the click of a single button.

Business processing modeling software from Trisotech – the Workflow Modeler – is used to produce a visual workflow using the international standard BPMN (Business Process Management Notation) via an intuitive drag-and-drop visual interface. These model diagrams provide comprehensive documentation, analysis, collaboration, and reporting features recognized as the gold standard in the process modeling industry and can be used directly by the Trisotech business process automation software. Using Trisotech’s BPM tools and combining the Workflow Modeler business process mapping software with the Trisotech Business Automation platform gives customers an unrivaled, powerful, and comprehensive low code/no code application development capability.

Improve your Business Processes to drive Business Automation using Trisotech

Free Trial

Business Process Management Software


View all

New and improved features:
Bug fixes:

How Rijkswaterstaat used Trisotech Digital Enterprise Suite to Build a Digital Solution for the Netherlands’ Environmental Act

How Rijkswaterstaat used Trisotech Digital Enterprise Suite to Build a Digital Solution for the Netherlands’ Environmental Act

Download Article



View all

Sandy Kemsley's Blog - Building Incentives Into Processes
Sandy Kemsley

Building Incentives Into Processes

By Sandy Kemsley

Read Time: 6 Minutes

Building Incentives Into Processes

Around 2011, I started looking at how business processes that involved people were becoming more flexible and collaborative, since many of the predictable parts of the process were being automated, which left the messier ad hoc problem solving to people. What I noticed is that there were problems with the adoption of systems used to handle these more flexible tasks. In some cases, the processes weren’t designed for the flexibility required for collaboration, because organizational culture tended to lock down worker environments rather than allowing them to adapt to the situation at hand. Also causing adoption problems was that workers had few incentives to focus on business goals when they were just rewarded for getting their bit of the work off their desk as quickly as possible.

In this time of process disruption, when we have the opportunity to retool all of our processes, how do we align our intelligent automation systems with incentives and business goals?

Remote work changes how work is done, and intelligent process automation is helping by sending people the right work at the right time, letting them collaborate with their colleagues, all while maintaining security and compliance. This changes how work is managed, since old-style offices that relied on a manager walking around to make sure that everyone looks busy just aren’t a good fit with remote work. And it changes how employee performance is measured: if your employees are rewarded on results rather than the number of widgets that they process, you don’t need to be watching them every minute.

adding incentives into your processes

I’ve written previously about the need for both vertical alignment, so that each of your top-level business goals can be directly traced to one or more operational activities, and horizontal alignment across the entire customer journey process. When workers are performing knowledge work, the performance metrics need to take into account that knowledge work is best when it is goal-driven, collaborative and adaptable. Measuring how well a worker performs a task that contributes to a business goal is much more important than measuring how many minutes they spent in each desktop application each day. This means understanding how their actions roll up to business goals, whether they are using a reasonable degree of collaboration to perform their actions, and whether they are using “outside the box” problem solving techniques or even changing the entire business process to adapt to an unusual circumstance.

Your intelligent automation systems need to not only provide this type of flexible environment for knowledge workers, but also measure how they’re using it to improve the quality of their decisions and work.

Sandy Kemsley's Blog - Building Incentives Into Processes - trusting their employees to perform quality work, especially for remote workers

In general, I recommend against over-monitoring workers’ behaviors, which can create false incentives. Some companies have been sold on the idea that measuring each click and keystroke is more important than trusting their employees to perform quality work, especially for remote workers; this is almost always an indicator that there’s a misalignment between business goals and employee metrics. To quote Peter Drucker, “what is measured, improves”, so if you measure keystrokes and time spent in different applications as a proxy for productivity, that’s what people will spend their time on even if it doesn’t contribute to business goals. Instead, measure the goals achieved by workers, such as problems resolved, time to resolution, and customer satisfaction with the result. This doesn’t mean that you’re not concerned with efficiency and productivity, but you also need to be measuring the quality of decision making and problem solving as it relates to higher-level business goals and customer satisfaction.

All of this may require changes to organizational culture. If you have a strictly hierarchical and rule-following management style in your company, people are less likely to collaborate and use their own judgement in solving problems. Work may be driven by rigid processes that don’t allow people to solve problems in the most effective way.

I wrote a paper back in 2014 on how incentives need to change for knowledge workers, which included the observation that although most companies and management understand that dynamic, goal-driven processes can result in big improvements, they just don’t have the organizational culture to support that type of work. Even if executives think that they want collaboration across silos, managers’ rewards may be based on efficiency performance targets, which means that the managers will enforce more transactional incentives for their teams.

It’s accepted by now that intelligent process automation needs to be designed with agility and to allow collaboration directly within their work platform as part of the process. An agile operating model allows processes to change on the turn of a dime, and a collaborative operating model assumes that people will work together to get things done.

When you’re designing metrics for these agile, collaborative processes, consider what should be measured at the team level as well as the individual level to reward people for working together on problems. If your management is worried that this will mean that people spend too much time socializing and not enough time solving problems, then your metrics are wrong. If you have metrics that are driven by higher-level business goals, then people will collaborate with others when it’s the best thing to solve a problem, not just because they’re feeling social. Having vertical alignment between business goals and individual metrics ensures that everyone, right from the CEO down to the front-line workers, are responsible in some way for achieving the business goals.

The key to designing metrics and incentives is to figure out the problems that the workers are there to solve, which are often tied in some way to customer satisfaction, then use that to derive performance metrics and employee incentives. Don’t forget that incentives can be both financial and non-financial. Some of the measurements will end up on people’s performance reviews and may contribute to a pay raise or promotion, but others are about personal satisfaction in doing a job well, or in helping others to achieve their goals.

Read Sandy Kemsley’s blog post: Making experience matter by building the right incentives into processes

Are you looking to align automation with incentives and business goals for your organization?

Request your personalized demo of the Digital Enterprise Suite today.

Request Demo
Blog Articles

Sandy Kemsley

View all

All Blog Articles

Read our experts’ blog

View all

Bruce Silver's Blog - BPMN 101: What Is a Process?
Bruce Silver

BPMN 101: What Is a Process?

By Bruce Silver

Read Time: 6 Minutes

It’s now 10 years since finalization of BPMN 2.0, the acknowledged standard business process description language. BPMN has been widely adopted, by tool vendors and end users alike, but there are still some folks just discovering for the first time. Because of BPMN’s outward similarity to traditional swimlane flowcharts, many of those users think they understand BPMN but are making some fundamental mistakes. This month’s post attempts to set things straight by explaining the basic concepts of BPMN. Even experienced process modelers may be unaware of some of them.

Let’s start at the beginning. What exactly is a process? Dictionary.com defines it as “a systematic series of actions directed to some end”. Some key ideas there:

BPMN is consistent with those ideas, but many swimlane flowcharts are not.

A BPMN process is a sequence of activities leading from some defined triggering event to one or more possible end states. All possible sequences leading from the start event to some end state are defined by the process model. Let me repeat that. A process model does not describe one possible path from start to end but all possible paths. That’s because a BPMN process is something performed repeatedly – not continuously – in the course of business. Each repetition, or process instance, has a definite start and end. That’s why not everything that BPM architecture calls a “process” qualifies as a BPMN process.

BPMN actually originated in 2002 as a business-oriented diagramming language for defining automated processes. To gain acceptance by business, it adopted the basic look of swimlane flowcharts, popular since the 1980s but just for documentation and analysis, not for automation. It was not until BPMN 2.0 that the diagrams were properly executable on an automation engine, but even today the vast majority of BPMN usage remains for documentation and analysis not automation. Nevertheless, the basic concepts of BPMN are rooted in process automation, in fact, a particular style of process automation called orchestration. A BPMN process is an orchestration.

In a BPMN process, the world is divided into three parts:

These concepts come from the BPMN spec. One important concept that comes from traditional business process management, not from the BPMN spec, is that the sequence of activities contained in a process should describe an end-to-end customer-facing transaction, cutting across departments and roles within the organization that provides the process. In other words, an order handling process should begin on receipt of the order and complete with fulfillment and billing (or equivalent accounting) for the order. Order entry, fulfillment, shipping, and billing should not be separate processes, but part of a single cross-functional process in which the process instance represents a single order. The reason is that BPM as a management discipline believes that business should be measured and managed from the perspective of these end-to-end processes rather than siloed departmental functions. BPMN supports this idea, but the spec technically does not require it.

Sometimes a single business process must be modeled as multiple BPMN processes, but this is not because they are performed by different units within the organization. The reason this could happen is if there is not a one-to-one correspondence between the instances of the processes. Within a BPMN process the instance of each activity must have one-to-one correspondence with the process instance. For example, in a process where the instance is an order, the instance of each activity must be an order. That means an activity that updates prices every month cannot be contained in the order process, since its instance is performed once a month not once an order. It requires a separate process that runs monthly.

Representing all the steps of an end-to-end process in a single diagram takes a lot of space, more than fits on a single printed page. BPMN allows a sequence of activities to be represented as a subprocess, shown in two ways: collapsed, as a single activity shape in one diagram, and expanded, as a flow from start to end in a second diagram with a child-to-parent relationship to the first. Thus an end-to-end BPMN model is in general not a single diagram but a hierarchy of diagrams, with a single top-level diagram hyperlinked to child- and grandchild-level diagrams detailing each subprocess. Where traditional flowcharting had to create separate high-level and detail-level models, difficult to keep in sync as the process evolves, BPMN provides both high-level and detail-level views within the context of a single model.

While the BPMN spec describes many different types of start events, in practice a process starts in one of only three ways:

Thus it is possible to interpret how the process starts simply by the trigger icon in the start event.

The ability to understand the process behavior in detail simply by inspecting the diagram, unfortunately, was not top of mind in the BPMN 2.0 task force in 2010. They were solely focused on making the diagrams executable on an automation engine. But to most BPMN users today, precise description based on the diagram alone is much more important. That requires additional conventions on top of the concepts and rules of the spec. The ones I use are called Method and Style. Much of the need for BPMN Method and Style arises from the fact that the process behavior – which path out of a gateway is taken, for example – depends on the values of data objects. But BPMN 2.0 removed data objects from the modeler domain and moved them to the Java programmer domain, so they are not used in non-executable models. To compensate for this, Method and Style’s conventions assign meaning to things that are actually used in non-executable diagrams, such as the labels on end events and gateways or the icon of a start event.

For example, in Method and Style the label of an end event of a process or subprocess indicates its end state, meaning how did it end, either successfully or in some exception state. Each distinct end state is represented by an end event, so the count of end events represents the count of distinct ways it could end. Method and Style says a subprocess with multiple end states MUST be followed by an XOR gateway with an identical number of gates, each labeled to match the end state label. This indicates the path taken by each instance. So if an instance reaches the subprocess end state Report approved it follows the gateway path Report approved, and if it reaches the end state Report rejected it follows the gateway path Report rejected. Conventions like this allow common understanding of the process flow without defining data objects.

BPMN Method and Style provides a list of style rules intended to make the process behavior precisely described from the printed diagram alone. To reinforce these rules, some BPMN tools, including Trisotech Workflow Modeler, include Method and Style validation. In my BPMN Method and Style training, this has proven extremely valuable in raising the quality of BPMN models. You should check it out.

Blog Articles

Bruce Silver

View all