1. Peter Schooff
  2. BPM Discussions
  3. Thursday, July 28 2016, 09:52 AM
  4.  Subscribe via email

From John Morris: By definition in BPM technology the artifacts of the work of business are first class-citizens of that technology. All other technologies are either complementary to BPM (e.g. business rules) or precursor to BPM (a coding framework) or hard-coded BPM (e.g. some processes in ERP). One technology vendor calls BPM “the language of business”. Here is their Youtube video that explores the definitions of BPM!

So do you think it would help BPM adoption to refer to BPM as the 'technology of the business' or the 'language of the business'?
Emiel Kelly Accepted Answer



Executing of processes for cases, Monitoring cases, improving processes.  To me that's all busines things. 


Sure technology can make it easier, but iI vote  for "Language of Business" 


Although... calling BPM a language sounds weird to me. BPM is just what happens in companies. Every day. 
Sharing my adventures in Process World via Procesje.nl
Fair enough distinction; one could still talk about "accounting software technology" as opposed to specific instantiations.
  1. John Morris
  2. 1 year ago
I thought we were talking about BPM, not BPMs ;-)
  1. Emiel Kelly
  2. 1 year ago
"Sounds weird" is probably a common reaction. So how to we break through for change? Accounting is just "numbers" -- and just happens every day. But we have accounting software where debits and credits and charts of accounts are first class citizens of the software. You don't have to program them . . .
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Peter Whibley Accepted Answer

No because it sets expectations that are unlikely to be fullfilled. It also encourages consideration of the BPMs in large scale transformational projects where I think the real future of the BPMs lies in the delivery of small sacle, rapid, tactical process solutions.
Peter, I agree with you about where BPM is likely to be successful. Expectations too are such a trap. I would argue though that these are separate questions from the fundamental nature of the technology . . .
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Bogdan Nafornita Accepted Answer

Both are inaccurate, but purely as a marketing tactic I'd opt for
since the mindshare of this word is completely blown out of proportions nowadays.

seems overly abstract - I'm sure business people are more likely to buy technology than semantics.
Managing Founder, profluo.com
LOL even thinking of trying to sell "semantics"! But I am very curious as to why "both are inaccurate"?
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
David Chassels Accepted Answer

NO...BPM is the way to think in understanding how people (and machines) create outcomes and new data/ information; all preparation to be ready to "digitize". The real challenge is just how is the supporting software going to deliver that Adaptive solution.

This must now be where the focus needs to be. The rise of no/low code is step in the right direction but must cover all requirements in one easily understood build and change environment. Be under no illusion this will be very disruptive and will hit big vendors and their ecosystems hard....long overdue putting interests of customers first.....!
I think you touch on a core message..is BPM a technology? I have always seen as a discipline a way to think that was created for IT. Now to deliver needs supporting software but I have resisted calling that BPM. I think the Adaptive tag already defined with 2 core requirements, easy change and adaptive UIs that recognise who and the need for that specific use which of course links direct to people thus BPM thinking is supported?

We see data exchanger as you describe as a process engine that orchestrates data as required. Time is important element and events triggers etc readily supported. Change is also relatively simple as code does not change and implemented via the graphical designer build environment. Just click and new configuration "declared" to process engine inside the database and ready to run...version control ensures smooth transition to the new.
Big vendors will find hard to have that blank pad....and wow big write off of all those acquired components...all part of disruptive price?
  1. David Chassels
  2. 1 year ago
Re: "The rise of no/low code is step in the right direction but must cover all requirements in one easily understood build and change environment".

Great point . . .

"Build" is relatively easy, i.e. drag/drop/link then attach roles, data collection forms, rule sets and press a button.

Except that constructs like "wait" nodes in a flowgraph may need fancy interoperability.

e,g. Your "wait" node typically needs a cycle timer so it does not try to 'fire" constantly, it has to consult a rule set, the rule set will be waiting for data import via a data exchanger from some local or remote app or device (i.e. the shipper advises that the assembly you ordered has shipped).

Why a data exchanger? - because the remote app/device may be not be able to export in a format that your "BPMs" can read, you may have to map the remote's data element naming conventions to naming conventions that your BPMs can easily read and. above all, few database designers are willing to allow direct "pokes", hence the need for and practical value of a general purpose data exchanger.

"Change environment" is not a piece of cake, either.

I may have 500 instances of a template, all at different steps and we discover that one of the sub-assemblies has a potential problem that might increase service costs in the field.

We typically won't want to take work that is in an advanced state (far beyond the problematic sub-assembly), rewind to where we can pull out the sub-assembly and continue from there using the new template. A lot less work is needed, on the other hand, for instances that have not yet progressed to the bad sub-assembly sub-template.

I guess the big vendors are going to need to take a hard look at their products - if they have been manufacturing bullock carts and discover, going forward, that they need to ship airplanes, they might be better off starting with a blank pad of paper.
So true about "very disruptive"! And the need to put the interests of customers first! As the "how" of "outcomes", and even comparing to low-code, I would claim that BPM is formally unique. BPM is "technology" where what people often want to build in low-code are already available as first class citizens of BPM. Does this make sense?
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
John Morris Accepted Answer

Is BPM "just another technology"?

I have wrestled with this question as a sales person selling BPM and BPM-related solutions.

[b]WHY BPM?[/b]
-- To sell one has to ask "
[u]why is there the possibility of a deal[/u]
"? And the answer is "to help us do more work with the same resources".

-- In fact ALL technology is about getting more work done with the same resources. Technology (or that subset "tools") is about
[u]force multiplication of human power[/u]
, either muscle or brain.

-- And because work is complex, it's difficult to build technologies. Try building a steam engine or a computer program "from scratch"! (Carl Sagan famously said "[url="https://www.youtube.com/watch?v=7s664NsLeFM"]If you wish to make an apple pie from scratch, you must first invent the universe[/url]".)

-- Let's think about business. Business or any service is about organizing effort for a purpose. That's work. So work is what business is all about. There is nothing about business which is not purposive work, with work defined as the application of energy to transform material from one form to another.

-- Which brings us to BPM. BPM is THE technology of work, because by definition
[u]in BPM and only in BPM the technological artefacts of work are first class citizens of that technology[/u]
. There are other irreducible technologies which are complementary to BPM of course, such as business rules, business data, business analytics technologies, etc. (We could explore distinctions between different kinds of "work", especially between "process" and "project", and "case management" or "unstructured tasks". They are all still categories of work. I'm using BPM in the most general sense as a proxy for modeling and executing automation artefacts in support of work.)

-- But otherwise, all software is written to assist us with work -- except one isn't working with directly with the artefacts of work if one isn't using BPM. One must code (originally in Assembler, then Fortran and COBOL, then C and Java, and now Javascript and C# and PHP and Ruby etc.), which
[u]mediates between idea and usable artefact[/u]
. And even with "frameworks", there is still mediation between idea and useful technology.

-- The
[u]cost of programming ideas into usable software is huge[/u]
! And the cost starts with inception and continues with evolution and maintenance. And evolving business models built on code is "a wicked problem".
[u]Not using BPM is to be "anti-agile"[/u]

-- So if BPM is THE technology of the work of business,
[u]does it help to say this in a sales context[/u]

Is BPM adoption helped by calling out how important BPM is?

Is BPM adoption helped by noting that "[quote][u]you can work directly with your business ideas[/u]
" and "
[u]reach your goals faster[/u]
"? And then later, "
[u]change and evolve more easily?[/u]
For organizations that want to win, absolutely. This is a message that resonates. And will work. But you have to be able to show why this works. And [quote][u]how business analysts and managers can work together in new fast-cycle partnerships[/u]
. There's a big social/managerial component here too.

-- The challenge to date has been the immaturity of BPM technology.
[u]The round-tripping problem[/u]
, only recently diminishing as an issue, and which inserts programming into a BPM solution,
[u]is enormously expensive[/u]
. And results in a loss of business enthusiasm.

-- Signavio's pioneering video on the "
[u]language of business[/u]
" is entirely complementary to the idea of BPM being the technology of the work-of-business. And the idea of "the language of business" is probably easier to communicate.

At the same time, only claiming "the language of business" can be seen as rhetoric or sales claim. And to leave BPM at language is to miss out on the real power of BPM "inside the box". (In fairness to Signavio, the purpose of their video is achieved by the focus on just the concept of language.)

Starting from language, but then [quote][u]showing that BPM in is very practical[/u]
 and that BPM really is the technology of the work-of-business takes us beyond rhetoric.

[b]THE FUTURE [/b]
[u]BPM is not just another technology[/u]
. Like accounting is the expression of ideas of finance and money, BPM is the expression in technology of the ideas of work. As BPM is adopted, it will become part of business culture, just as accounting is part of business culture.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Walter Bril Accepted Answer

Pfew... BPM means different things to different people, depending on their (commercial) interest or focus I'd say. But I second Emiel here; I'd rather go for
[i]language of the business[/i]
. As in the end it is about business and not the means, although means can influence the business (model).

If my business is crafting and selling wooden shoes, it helps a lot to
[i]understand [/i]
the business. As soon as I understand the business, I'm in a better shape to understand what means I need to support that business: Do I need an axe to cut trees or a chainsaw. As soon as BPM becomes the technology of the business, there is a danger that we get priorities wrong. We buy chainsaws for small trees say: I didin't understand the business and have wasted too much money on wrong means, e.g., technology.
Having used both axes and chainsaws, your example resonates -- or should I say "vibrates" -- with me. Referring though to your initial statement about BPM meaning different things to different people, consider the comparison to accounting. Sure accounting means different things, but there is a core accounting body of knowledge which is in fact a technology.

I guess I'm claiming that "BPM exists" and that "BPM is centrally important", not merely song-of-the month on the technology pop-chart. : )
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
John Morris Accepted Answer

Good comments about whether the abstractions of language or technology are useful in encouraging BPM adoption.

[b]Note however that [quote][u]"adoption" shouldn't be limited to questions of selling to users[/u]

[b]Adoption is [quote][u]also about what vendors think about themselves[/u]
, and what leading edge cadres (e.g. enterprise architects) think about BPM.[/b][/quote]

I think Signavio has done an important and interesting thing, which is to make such a bold and really "over the top" claim, such that "
[u]BPM is the language of business[/u]

I go one step further and claim that
[u]this language is not mere rhetoric, but technological fact[/u]
. Concepts of work are
[u]first class citizens[/u]
of real BPM technology, 
[b][quote][u]based on science, math and software engineering[/u]

If one accepts this, then BPM can no longer just be "another technology", even a "great technology".

[b]Modern BPM becomes THE technology of business, because it is THE technology of work. [/b]
And business is all about work.

Executable BPM, especially BPM without a roundtrip problem, is new and powerful. This means new opportunity.

Following the usual [url="https://en.wikipedia.org/wiki/Diffusion_of_innovations"]adoption process[/url] outlined from [url="https://en.wikipedia.org/wiki/Everett_Rogers"]Everett Rogers[/url] (later taken up by Geoffrey Moore), visionairies and early adopters want to know about "the new".
[u]They need the new[/u]

Let's not hide our light.

  1. more than a month ago
  2. BPM Discussions
  3. # 7

Thought provoking . . .

Not the “work-of-business” - because BPM does not do a good job on work that is totally unstructured – we can say there is “no” difference between individual actions with no apparent logical connection between these actions and structured work to avoid having one way of dealing with structured work and another way of dealing with unstructured work, but if particular industry/application/workers mostly perform work that is unstructured, this means you are carrying around a lot of overhead by pushing “BPM”. Fortunately, most work is a mix of logically-connected steps and ad hoc steps so we CAN say BPM is A core component to most “work-of-business”.

Not the “language of business’ - because the language of business is preparing mission statements, inventorying business assets, making lists of candidate initiatives, preparing ROIs for these, selecting the more promising initiatives, setting strategy/goals/objectives, allocating resources, monitoring progress, tweaking strategy/goals/objectives on the basis of progress/lack of progress. BPM does not address some of the actions I have listed. At the operational level, BPM is good for documenting processes, modeling processes, improving processes, rolling out "best practices" templated to run-time environments.

The best pitch in my view is "Case Management" with background BPM - hospitals, insurance, law enforcement relate to Case but you get blank stares in other industry areas.

See "Is it time to rename 'Business Process Management' to 'Business Performance Management'?

The problem is 'Business Performance Management' is taken and it's a crowded field.

The players in the business performance management sector seem to put very little focus on operational issues - their bpm seems to be all about scorecards, KPIs

My experience is that corporations who do not bridge the gap between operations and strategy often end up staring at the wrong KPIs.
  1. http://wp.me/pzzpB-MB
Sure, re "BPM technology in the most general sense is suitable for any style of work, including unstructured work"

. . . . because one way of developing a "best practices" flowgraph would be to perform only ad hoc interventions, data mine the Cases and, when you see a pattern, build a flowgraph that logically connects a series of steps.
Thought provoking indeed! Thanks Walter! And for a deep exploration of both "technology-of" and "language-of".

In response I'd claim that BPM technology in the most general sense is suitable for any style of work, including unstructured work. The fact that there are some types of work that don't make sense to automate yet, because the technology is not fully capable yet, doesn't undermine this claim.

Behind BPM technology is logic, graph theory, and systems theory, and potentially even linguistics. When Signavio says "language of business" I suspect this is a non-trivial claim. The vendors that succeed in the coming years with BPM will do so on the basis of seeing BPM as not just another technology.
  1. John Morris
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8

I agree with Walter B. that BPM means different things to different people (actually roles). For the success of BPM, it is mandatory to develop such viewpoints, but they must be aligned.

Thus, it is necessary to have a root or central or systems-approach-based “meaning” of BPM. It seems that this community is responsible to develop it.

So, my version “BPM is a management discipline based on explicit coordination of work”.


Walter, great note on 3-tier scheduling (worth clicking thru to). I can't help but think that DMN is going to make a big impact here, over time. Scheduling and escalations can be very complex. For any vendor, having scheduling and escalation demos "on the shelf" is very important -- because ad hoc models for this important area of activity very quickly end up looking like spaghetti. Then the business people tune out of your POC.
  1. John Morris
  2. 1 year ago

Works for me, providing the term "coordination of work" includes 3-tier scheduling.

See a 2014 article "Three-Tier Scheduling and why you need it for ACM/BPM"

Thanks John.

Discipline is a coherent set of governing rules . And management discipline is a discipline for the better management of the enterprise functioning in support of the enterprise goals.

I think, it is sufficient for now considering that we are still at alchemy-like situation (although, in the middle ages, the alchemy was considered as a separate science). Next step will be making BPM-as-applied-science.
Bravo "alignment" -- we'll all be much further along if we are singing from a common song book.

As for "BPM as management discipline" etc., can we go further?

Can we go to "BPM-as-science", from which "BPM-as-management-discipline" is derived? (The fact that "reality is rich" and that any model doesn't capture all or even most of reality doesn't undermine this proposition. Logic is quite capable of being "fuzzy".)
  1. John Morris
  2. 1 year ago
Sure Karl, your "3-tier scheduling" is in the collection of coordination techniques - see http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Bogdan Nafornita Accepted Answer

I understood Peter's question as: 
[i]how would BPM sell better? with a tech pitch or with a language pitch? [/i]
All in the context of fixing BPM's notoriously low adoption.

For me, I don't care if it's a 
[i]space ship[/i]
. If it sells better as a 
, I would call it a 
[i]truck [/i]
so I can relate to my target customer.

Judging from the answers above, could BPM's low adoption be caused also by our strange collective attraction to continuously re-define it, re-name it, re-kill it, re-vive it.

I'm wondering if a regular customer can follow everything was said above. And adoption is driven by regular customers, not the Fortune 500 CIOs.
Managing Founder, profluo.com
Walter, seriously interesting comparison of CPM and BPM.

And your note highlights the components of the question. There's the methodology (CPM is about project management), there's the science (has CPM been described formally in math and logic?), the software engineering (there is CPM software, but how generalized are CPM software engines?) and there is use case and usage (construction project managers want to track durations).

Consider that project management is an end case of business process; alternatively business process is a generalized project management with repetition.

The same math can be used to describe both, and software products will focus more on one than the other in terms of engineering.

This is why we are still at the alchemy/craft stage of business process automation. We are building cathedrals with toothpicks. The math is waiting (and in some cases has been implemented) but our discourse is lagging.

The result when math, engineering and practices are aligned will be executives and managers "think", and then business analysts "draw" and then staff "use". No style restrictions. If it makes business sense, you can do it. Revolutionary. Demanding. Worthwhile.
  1. John Morris
  2. 1 year ago
@John.. What about CPM (Critical Path Method) and its similarity to BPM?

I consider CPM to be an antecedent of BPM (i.e. nodes/arcs, logical connections, merge constraints, milestones, roles) - the major lacking in CPM was branching decision boxes.

What is missing in BPM (most software offerings) is durations at tasks and we all know that we don't want./ need durations in BPM because your wait times between tasks can be highly variable..

I don't see anyone in the construction industry planning or monitoring/controlling a once-through project without using CPM.

I would imagine it to be very easy for a sales rep to sign up a customer for CPM.
Bogdan you've hit the nail on the head re: notoriously low adoption.

The question though can be more general than just selling to customers. Adoption is also about vendors.

So what do vendors think about what they sell? If BPM is "just another technology", we start with one hand tied behind our back. We now have lots of competition in many categories! And because BPM also makes demands on business, the net is that BPM loses.

There's another way, which you've highlighted in part by your note on the question of BPM's identity crisis (as you say we "continuously re-define it, re-name it, re-kill it, re-vive it").

This "other path" starts with the realization that BPM is fundamentally different than other technologies. Different in terms of real science and different in terms of real use.

I am continually inspired by the history of accounting, which is comparable in many ways to BPM technology.

There's a big opportunity for vendors and champions who are ready to sell the idea of BPM, as well as solutions.

And customers in the visionary and early adopter phase of multiple technology adoption curves are waiting for this leadership.
  1. John Morris
  2. 1 year ago
@Emiel: what? the truck? :-)

@Alex: absolutely agree, from an architectural standpoint it is the ideal delivery methodology (and it is what we're doing: a trunk of meta-processes with customized branches for every single "app", plus that every customized branch may add features to the trunk if we believe it pushes the platform towards our vision). But purely from a sales point of view, I would call it whatever suits my customer (as long as I'm not lying, cheating or over-committing)
  1. Bogdan Nafornita
  2. 1 year ago
Sure that "adoption is driven by regular customers," and because all regular customers are different then it is necessary to have one master or centric or meta or systems-approach viewpoint, many related viewpoints for some popular roles and a "small" procedure for adjusting one or few of those available viewpoints to a particular "regular" customer.
Yes, Yes, Yes.

I want it!
  1. Emiel Kelly
  2. 1 year ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.