eeehm...

 

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. 

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

[i]technology[/i]

since the mindshare of this word is completely blown out of proportions nowadays.

[i]Language[/i]

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)

[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".


2)

[b]TO GET MORE WORK DONE [/b]

-- 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.


3)

[b]TECHNOLOGY IS HARD [/b]

-- 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]".)


4)

[b]BUSINESS IS ABOUT WORK [/b]

-- 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)

[b]BPM IS THE TECHNOLOGY OF WORK [/b]

-- 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.)


6)

[b]OTHER TECHNOLOGIES MEDIATE IDEAS [/b]

-- 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.


7)

[b]MEDIATION BY CODE IS EXPENSIVE[/b]

-- 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]

.


8)

[b]THE SALES QUESTION [/b]

-- So if BPM is THE technology of the work of business,

[u]does it help to say this in a sales context[/u]

?

[list]
[*]
Is BPM adoption helped by calling out how important BPM is?
[/list]

[list]
[*]
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]

"
[/list][/quote]

[list]
[*]
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.
[/list][/quote]

9)

[b]BPM SOFTWARE MATURITY [/b]

-- 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.


10)

[b]LANGUAGE VERSUS TECHNOLOGY [/b]

-- 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.

[list]
[*]
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.)
[/list]

[list]
[*]
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.
[/list][/quote]

11)

[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.

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.

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][/quote]

[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]

[/b][/quote]. 


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.


 

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”.


Thanks,

AS

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]truck[/i]

, 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.