BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 23 May 2017
  5.  Subscribe via email
An article at BPTrends stated: "A recent survey of U.S. companies indicates that only 46% have a BPM system in place." Why do you think that number is still so low?
Accepted Answer Pending Moderation
1. A lot of orgs still really don't know what BPM is, even though they do it every day just not necessarily with any discipline or awareness.
2. Others are afraid of it, mostly, namely the acronym itself.
3. Vendors
4. Cost
Comment
Agree with all but #4. All endeavors have a cost but what counts is the ROI.

If consultants could pitch cost savings as opposed to expense, avoid making grand references to BPM (especially to specific BPMs where the prerequisites are to learn a language/notation).

Anything that shows a crossover of 18-24 months should be pitchable.

Long paybacks and a prospective client will quickly lose interest and if the payback is too short, they will also quickly lose interest (i.e. no free lunches).

Maybe another way to put it is:

Many companies an inability to account for the costs. They can't count the cost of doing nothing, and they can't count the returns on what they'd get if they deployed a BPM solution.

For similar reasons you see customer spend $1M on $40/hour, instead of spending $250k at $250/hour. Failure to account for the costs.
And there's the combination of those, serving double punches: vendors + cost (aka the BPMS-as-an-ERP monolithic approach), lateral vendors spreading FUD, etc
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Not knowing what sorts of companies were surveyed, I'd guess that many were SMBs - The cost of BPM implementations staggers most SMBs.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Leaving aside the debate about what that survey actually meant, how was conducted and by whom and what was the sample size...

46% BPM adoption is low... as compared to what?
When compared to most other countries, this is huge. The lower the labour cost, the lower incentive for companies to replace human effort with systems.
When compared to most other systems, this may be decent. ERPs are expensive and clunky. Tasklists are still on paper mostly. Anything in between is nowhere near 100% adoption.
When compared to B2C software, this is incredibly low. But also incredibly stupid to compare.
CEO, Co-founder, Profluo
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Companies are implementing BPM "the approach" and BPM "the technology" but when asked they wouldn't recognize it as "BPM"

BPM "the approach" - that is called doing business.... maybe called Operation Excellence if it is a "thing you focus on"

BPM "the technology" is embedded into the stuff they already have, but don't call BPM. They call it HR, Sales Automation, Call center, Workforce optimization... from companies like SAP, Salesforce, Oracle, Workday.

The analysts recognize this: Salesforce is a leader in Gartner MQ for low-code app building (1 May 2017)(1 May 2017) and also the mobile app development June 2016

Some software vendors recognize this. Pegasystems was a BPM vendor and is now a CRM vendor
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
46% is quite high, but.... I have expensive running shoes, a fitbit thing and a cool heat sweatband, but I haven't run a meter in my life.

"Having a BPMs implemented" is not the same as "Doing BPM"
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
BPM as the discipline in thinking what is needed is an easy explanation the real issue is it becomes an "IT" project and historically the same failure rate? Next generation no/low code DBPs in hands of business will change this and once business really understand "how" then the historical BPM issues will be forgotten.
Comment
  1. John Morris
  2. 1 year ago
  3. #3944
I don't believe that "code-anything" will ever be part of normal business skills and practices of anything but specialist management. COBOL was intended to be exactly that. There is too much irreduceable technical requirement for good software that cannot be added to executive's existing cognitive load.
John This very issue was core to our research and indeed was the dream in the 80s and Bill Gates stated holy grail in 2007 as they tried to copy us.....too late for any patents! Well we "discovered" the answer for business and believe me it works! Suggest you read this http://data.parliament.uk/writtenevidence/committeeevidence.svc/evidencedocument/public-administration-and-constitutional-affairs-committee/inquiry-into-government-accounts/written/38055.html high lights how and the real challenge...... User love it but current supplier chain does not want to know...it will seriously change their business....just one of many supressed disruptive technologies whose day might be close..... this gives more detail http://www.leadingedgeonly.com/providers/InnovationDetails.aspx?id=1147 Think about it business is actually quite simple once analysed to the basics......
@John . . The "cognitive load" on executives may be easing, now that it seems to be acceptable to have executives who have no first language and are only able to name a few of the letters of the alphabet.
  1. John Morris
  2. 1 year ago
  3. #3950
Bravo David esp. on UK Sport (your link is worth a visit). Your sense that there are non-technology roadblocks, even incomprehensible roadblocks, to rapid good quality enterprise software construction, is telling. As they say "you can lead a horse to water (but you can't make it drink)".
I'm acquainted with some health care records projects hitting $ 70 mm+ -- which don't really work. How is this possible? I think it goes beyond bad governance and rentierism. It's almost a cognitive hurdle. My experience with RAD revealed this too me. If your app-dev software enables 10X productivity, that productivity leap stresses the organization -- to generate good ideas faster. The "executive wait state" is removed. Golf schedules are disrupted. The regular cadence or homeostasis which enables people to survive, is threatened.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
“only 46% have a BPM system in place.” – it does mean that BPM-as-discipline is in place as well!

A company may have a BPM system in place, but such a system is often used for some marginal application(s). Unfortunately, many of modern BPM-suite tools are not “good enterprise” citizens for the following reasons:
- tool gurus can implement anything but the result is not maintainable by other people
- tool specialists try to implement everything within their tool (monolith mentality)
- tools are architected as “programmable monolith”
- tools (actually vendors) are trying to swallow every tool including APaaS (or low-code)

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
This is the hell of a question, thanks Peter!

The honest answer should be: because of poor benefit-cost ratio. Definitely not because they didn't hear about it - the BPM is on all radars for more than decade. Not because of costs alone.

Of course there are many great references with impressive ROI (whatever it means for a particular customer) but most of them pick up the low-hanging fruits only.
- It's hard to get the initial momentum - costs are high not only in terms of software but in terms of necessary skills.
- It's hard to expand the BPM initiatives because of the law of diminishing return.
- It's hard to sustain - the successful BPM teams are tend to be torn apart by various enterprise needs.

I have a hypothesis why BPM is so tough for most organizations: to be successful with BPM, one must change both the technology AND the way technology is implemented.

I'm talking about agility here: it ain't BPM if it isn't agile. Start low, fail fast, MVP, voice of the customer, contiunuos integration - it all sounds great and it IS great but how does it fit into typical corporation's financial policies? A little bit better than in no way I guess. Finance dictates fixed budget, fixed budget dictates stone-cut reqs - bye-bye BPM!

This isn't an ultimate stopper indeed - there are techniques that allow to be both agile and financially controllable - yet this is what doubles BPM challenge.
Comment
Amen.
The main challenge of BPM is that each BPM vendor, each BPM consultant, each BPM “body-of-knowledge” and each BPM client (i.e. enterprise) understands BPM differently. (The 1st law of BPM from http://improving-bpm-systems.blogspot.ch/2015/07/laws-of-bpm-business-process-management.html )
Alexander, isn't it the same with e.g. ERP or CRM or project management? Is BPM that much different?
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
@Bogdan's point about NA labour cost versus #BPM cost is excellent. But I'll take up the challenge and question the survey (I looked and didn't actually find it). 46% adoption seems very high, except in the F1000 sector that the survey may be covering. Following along from the original "reluctance question" though, BPM is new technology, and it takes a while for a culture to slide along the technology adoption curve (see Geoffrey Moore and Everett Rogers). The BPM body of knowledge (both methodolology and technology) is comparable to accounting knowledge. It needs codification and socialization and specialized cadres for diffusion. It took hundreds of years for accounting to get where it is today, and where all managers know and work with accounting every day, but then most actual accounting work is performed by specialists either at the bookkeeper level or the chartered accountant policy level. A similar social process is required for wider adoption of BPM. And channels are an important leverage point in the process. For those daunted by the phrase "hundreds of years", I don't think it will take so long. The secret? It's not about low-code, but business semantics. Just like accounting. In accounting, balancing books is important (i.e. making sure journal entries are correct, analogous to coding), but until one shows the value of cash management (a higher-order semantic construct), the promise of accounting has not been realized. So BPM adoption is not just about poor ROI, it's about an entirely new language of business semantics. That's not a comfort zone for many people. To be positive though, consider another comparison: the "quality-is-free" movement introduced a new language of business, one which has been widely and successfully adopted.
Comment
Excellent posting again John. But why all these words in bold font in all your messages.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
I think all organizations deal with processes. It's if they recognize it as BPM or not. I also think there have been partial BPM successes that may not be compelling enough because processes are not linked to customer, partner and employee journey disciplines to a level that is necessary to win the day. Just my two cents.
References
  1. http://jimsinur.blogspot.com/2015/01/the-dangerous-disconnect-between.html
  2. http://jimsinur.blogspot.com/2014/03/the-digital-organization-is-obsessed.html
  3. http://jimsinur.blogspot.com/2015/05/dangers-in-first-steps-of-digital.html
  4. http://jimsinur.blogspot.com/2016/09/journey-experience-mapping-isnt-just.html
  5. http://jimsinur.blogspot.com/2015/02/a-dramatic-shift-in-customer-experience.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Change is hard. However simple or complex the change is, organizations fight it unless there is a compelling vision of the new life will be easy and the village is all singing from the same sheet of music. Implementing discipline that changes habits already formed is incredibly challenging especially when you cut across business lines which BPM implementations tend to do. Consequently, my view is that to improve the adoption, we have to make capturing the business assets/process and encapsulating the IP easier, and the technology needs to achieve a better entry point- easier first implementations followed by faster encapsulation of the IP into the technology. Probably technology needs to be more prebaked with vertical industry capability but not so concrete change is difficult. Having said that I would now echo Jim Sinur's comments.
Comment
Like "pre baked"....yes we discovered all business logic can be provided built ready to configure and for any business application without vertical "restraints". The use of declarative technique from the graphical build to the database change is readily supported as no coding or compiling needed. So quick and inexpensive I think will seriously challenge future of SaaS as these adaptive processes become custom business assets
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
I would dare to go as far and say that in actuality the acceptance of BPM - both as a technology and a discipline has actually decreased, even. In accordance to some of the contributors on top, I also would correlate that to mostly economical reasons (LoE/time, costs but also external, macro-economical shocks many economies have been subject to, during the last couple of years).
We have been seeing in that sense an important shift - away from holistic EPM and BPM projects, iBPMS and ACM implementations - towards narrower vertical solutions, low code and low complexity efforts. In short, there seems to be current tendency in the market to favor simpler, quicker and cheaper solutions, tackling short term goals as opposed to more complex and strategic BPM endeavors.
Interestingly, that has forced vendors and solution providers to "SaaS productize" a series of pre-made solutions that are in turn based on their respective BPM technologies, ready for consumption (usually rent) by the end users.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
Emiel Kelly Makes a great point in his usual style.

I actually think 46% is quite a good number. Most people would be doing BPM without knowing the term BPM. :p

SaaS is making BPM technology even more accessible to end user companies. Someone might be using Zoho or KiSSFLOW without realizing they are using BPM software.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
BPM is such a wide range of approaches, that the question is very difficult to answer in knowledgeable way. Most organizations have a lot of it-systems. I don't know any It-system development project not using some of the BPM approaches such as describing work flows or user cases etc. Also many of the improvement projects need changes in it-systems.

Using BPM as a business philosophy is more challenging. In most organizations the leaders come from management disciplines such as legal, financial or marketing. These people train them selves MBA- programs where they learn how to deal with economical, marketing and human aspects of the business. Very seldom they get any advise how to build systems for the organization. IT systems and also other system approaches such as logistics are left to the specialists.

There is also tendency in BPM to dive into the details because of it's IT-origin. It-systems are technical systems so every detail counts. Details make the complex business even more complex such as EA-approaches. Business is a social system. ´The dynamics of social system is very different from technical system. Detailed planning/designing destroys the understanding of the big picture, which is needed in business management. The real issue for BPM is how to simplify the complex business so that it can be understood by people who have no It or technical background.

br. Kai
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
There exists definite psychological barrier and prejudice against BPM, both among management and workers, in perceiving BPM as too mechanical and "soulless" technology. It is important in this respect to stress crucial "human" dimension of BPM, which saves workers from enormous time losses on boring routine tasks and unlocks incredible potential for improvisation and creativity.

Of course, all these factors will reveal into reality only in case when both a company and BPM implementation team share positive values and determination for improvement. Too often, reluctance in regard to new technologies in general and BPM in particular simply manifests a desire to avoid changes, escape continuous learning and reorganization of familiar working environment.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Accepted Answer Pending Moderation
Some random thoughts as a reaction to what was written. Not the most important maybe, but anyway.
At least part of the answers to the question can be found also by trying to find answers on related questions. F.e.: why aren't we all using low code platforms? So besides bpm platforms looking at hpaPaas also. https://medium.com/softwareimprovementgroup/low-code-wave-of-the-future-or-blast-from-the-past-7fcd618371b2
provides some answers.
One of the points mentioned is vendor dependency. Having bpmn and dmn as vendor-independent standards does of course not cover this risc. Another one is that the citizen developer is a myth. Business people "programming" themselves have been a 4GL ideal, but the ideal has never been realized. Same for hpaPaas. What is a realistic idea however is that hpaPaas/bpm systems make it easier for business and it to communicate. And for it to make their application easier overseeable and thus maintainable for themselves (developer speaking here). Bpmn and dmn are easier to understand than processes and rules in the code of a certain programming language. When there is a problem it's easier to talk with business people having bpmn / dmn / for my part erd on the screen in the middle than an editor with code or a datadictionary.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 16
  • Page :
  • 1


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