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!
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.
Both are inaccurate, but purely as a marketing tactic I'd opt for technology since the mindshare of this word is completely blown out of proportions nowadays.
Language seems overly abstract - I'm sure business people are more likely to buy technology than semantics.
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.....!
Is BPM "just another technology"?
I have wrestled with this question as a sales person selling BPM and BPM-related solutions.
1) WHY BPM? -- To sell one has to ask "why is there the possibility of a deal"? And the answer is "to help us do more work with the same resources".
2) TO GET MORE WORK DONE -- In fact ALL technology is about getting more work done with the same resources. Technology (or that subset "tools") is about force multiplication of human power, either muscle or brain.
3) TECHNOLOGY IS HARD -- 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 "If you wish to make an apple pie from scratch, you must first invent the universe".)
4) BUSINESS IS ABOUT WORK -- 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.
5) BPM IS THE TECHNOLOGY OF WORK -- Which brings us to BPM. BPM is THE technology of work, because by definition in BPM and only in BPM the technological artefacts of work are first class citizens of that technology. 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.)
7) MEDIATION BY CODE IS EXPENSIVE -- The cost of programming ideas into usable software is huge! And the cost starts with inception and continues with evolution and maintenance. And evolving business models built on code is "a wicked problem". Not using BPM is to be "anti-agile".
8) THE SALES QUESTION -- So if BPM is THE technology of the work of business, does it help to say this in a sales context?
9) BPM SOFTWARE MATURITY -- The challenge to date has been the immaturity of BPM technology. The round-tripping problem, only recently diminishing as an issue, and which inserts programming into a BPM solution, is enormously expensive. And results in a loss of business enthusiasm.
10) LANGUAGE VERSUS TECHNOLOGY -- Signavio's pioneering video on the "language of business" 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.
11) THE FUTURE -- BPM is not just another technology. 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.
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 language of the business. 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 understand 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.
Good comments about whether the abstractions of language or technology are useful in encouraging BPM adoption.
Note however that "adoption" shouldn't be limited to questions of selling to users!
Adoption is also about what vendors think about themselves, and what leading edge cadres (e.g. enterprise architects) think about BPM.
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 "BPM is the language of business".
I go one step further and claim that this language is not mere rhetoric, but technological fact. Concepts of work are first class citizens of real BPM technology, based on science, math and software engineering.
If one accepts this, then BPM can no longer just be "another technology", even a "great technology".
Modern BPM becomes THE technology of business, because it is THE technology of work. And business is all about work.
Executable BPM, especially BPM without a roundtrip problem, is new and powerful. This means new opportunity.
Let's not hide our light.
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.
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”.
I understood Peter's question as: how would BPM sell better? with a tech pitch or with a language pitch? All in the context of fixing BPM's notoriously low adoption.
For me, I don't care if it's a space ship. If it sells better as a truck, I would call it a truck 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.