BPM Babylonia – Comparing BPA and BPMS is like comparing apples and oranges

Ricardo Passchier on April 2, 2009

Recently, Terry Schurter described the BPM State of the Nation 2009. Terry touched an interesting subject – the disparity between BPM definitions in the marketplace, especially where it concerns BPM software. The BPM software market is very diffuse, a phenomenon which I encounter almost daily in my line of work when talking to prospects or customers. Analysts have tried to categorize the different types of software but many organizations find it hard to figure out the differences. We are all familiar with the two-, three- and four-letter abbreviations: BPA, ECM, BPMS, ERP, SOA and BI. All support business processes one way or another. Which does what? I will look into two of these abbreviations causing plenty of Babylonian confusion.

First and foremost, is BPM a management discipline or a technology? Depending on the context it can be both. When we define BPM as an approach to methodically design, implement, execute, control and improve business processes than we can argue it is a management discipline. In addition, there is technology to support this discipline in all of its stages. Due to their modeling capabilities, two types of technology are often confused:

Business Process Analysis (BPA) tools such as IDS Scheer's ARIS;
Business Process Management Suites (BPMS) such as Pegasystems, Lombardi, Software AG, Savvion and Metastorm.

The primary purpose of Business Process Analysis (BPA) tools is to visualize, analyze and improve business processes. BPA tools help translate every day business complexity into structured models (scope: from business to model). They provide insight into an enterprise's structure – i.e. how strategy, products and services, processes, roles, information and systems are related and influence one another. By creating a single point of truth, BPA tools strive to improve the communication between various stakeholders in a company, safeguard corporate knowledge and support decision-making and change management. Most notable user groups are business managers, process owners, quality managers, business analysts, risk & compliance officers and enterprise architects. BPA tools have rich semantics in order to fulfill a broad information need. They enable users to visualize and analyze the enterprise from different point of views, e.g. from a performance-, risk & compliance- or architecture perspective.

Business Process Management Suites (BPMS) on the other hand serve a different purpose and target a different audience. While they do offer modeling capabilities, their primary purpose is to automate, execute and monitor business processes based on technical models (scope: from model to execution). Notable user groups are business- and information analysts, process engineers, software developers and system administrators. BPMS do not offer such rich semantics as BPA tools in the sense that their metamodel does not comprise concepts for performance management, risk & compliance management or architecture management. Then again, these concepts are not required to automate processes.

In my opinion, BPA tools and BPMS cover two different aspects of the wide BPM spectrum and therefore complement one another perfectly – as illustrated by the enclosed figure. As the market matures, their worlds converge more and more. However, to date, BPA and BPMS remain two separate worlds. Comparing them is like comparing apples and oranges.

Bookmark

Notify Moderator

5 Replies

SA

Site Administrator on April 3, 2009

Max J. Pucher - Chief Architect ISIS Papyrus - said:
I absoutely agree. The problem is however that the abstract world modeled in ARIS has nothgin to do with reality and can typcially not implemented. If you model a company all the way in ARIS, by the time your done it is obsolete and by the time you implemented it the economic environment has changed. ARIS is not only selling an illusion it is creating one as well.

That is the reason for all the different BPM products, when in fact a business needs a consolidated BPM, ECM, CRM with BI links for operational goal achievement.

If anything needs to be modelled it is a business (not process) architecture and the orgnization (ok with ARIS) but then it must be deployable, usable and maintable in production. That is impossible with ARIS.

Process is about dynamics (agility if you want) and a flowchart is everything else but dynamic.

Like

Sign in
or register to reply.

Notify Moderator
Ricardo Passchier Author on April 6, 2009

My point is primarily to explain the differences between BPA tools and BPM suites and to take away some of the confusion that exists in the marketplace. I am not stating that choosing either one of them is the best choice when pursuing BPM.

Looking at BPA tools, modeling is not a purpose in itself, but serves a greater objective. I have mentioned a number of them: improving communication between various stakeholders to have a common understanding of reality, safeguarding corporate knowledge, supporting decision-making and change management. BPA tools especially add value since most of them comprise so much more than only process architecture nowadays with performance- and compliance aspects becoming increasingly more important.

By stating that a business architecture (including processes, roles and business rules) must be deployable, usable and maintainable in production you are assuming that all processes can be automated. However, for many companies, establishing a - fully automated - closed-loop is utopia in my experience.

I cannot but agree that a typical pitfall with BPA tools is to try and model the whole world and yes, once you’re done everything has changed. I prefer a more opportunistic or project-based approach where you first take on the business-critical processes and incrementally build up your architecture provided that proper governance has been established.

To keep track of reality you would need some form of measurement, since there will always be disparity between processes as documented, implemented and executed. Process intelligence, for instance, helps reconstruct the actual process behavior and compare it to the original design.

All in all, each type of technology mentioned has a right of its own and can perfectly co-exist. Companies have to be aware though of their purpose and target audience when selecting one or the other. You know what they say: “A fool with a tool is still a fool.”

Like

Sign in
or register to reply.

Notify Moderator
SA

Site Administrator on April 6, 2009

Garth Knudson said:
Ricardo,

I appreciate your attempt to explain the differences between BPA and BPM. I have run into these questions all over the world while I introduce BPM and BizFlow. In a nutshell, BPA defines and creates models, but stops short at process execution. BPM transforms models into apps by combining workflow, rules and electronic forms (data capture and validation). BPM takes analysis and optimization to the next level through process monitoring and optimization. BPA is for creating plans. BPM is for building apps.

Like

Sign in
or register to reply.

Notify Moderator
Miko Matsumura on July 25, 2009

I wanted to comment on this post.

I realize that this post is originally dated in 09/04/02--but I feel that it is still a very contemporary view on the subject.

From the Software AG perspective, I have learned this distinction in many customers, where time and again the concept of real business users with real business processes comes into the picture. The depth to which ARIS community members can understand and model specific vertical processes is demonstrably far outside the scope of more technical solutions.

So from my perspective, the distinction between BPA and BPMS is very much one of human interface and the roles played in the BPM world.

I've been thinking about this topic because I've been asked "doesn't Software AG already have BPM tools?" and I think it's important to help people understand that BPM is an art and a way of conducting business that consists of many possible technical implementations and best practices.

Although I've stated things in an all-embracing way, above, I persist in believing that one of the properties of a "particularly good" implementation of BPM involves the way in which business people (who tend to favor BPA) interact with technical people (who tend to look at a variety of things but notably BPMS).

So I wanted to draw attention to this very insightful post by Ricardo and reignite this thread of discussion.

Thanks,

Miko Matsumura

Software AG executive

Like

Sign in
or register to reply.

Notify Moderator
Cierra Luke on April 27, 2015

Hi,

I totally agree with your point of view and acknowledge your work in one of my presentations in our company. Thankyou for sharing this idea in this manner. There is no doubt in the fact that comparison of BPA and BPMS is like comparing apples and oranges.

Regards Cierra

Like

Sign in
or register to reply.

Notify Moderator