In your experience, what is the key thing that holds BPM back in most organizations?
Because BPM (at least when you see it as something an organization can implement) in general means nothing; it doesn't solve any problem.
All the ideas of BPM world should be tied to the processes and problems of YOUR organization. Otherwise it just stays cool theory that isn't connected to daily practice.
Talking about daily practice; that's just what BPM is, isnt it?
From my experience, companies that are new to BPM are easily drawn to the values it delivers (optimization, tracking…) but fail to foresee some constraints.
For example, when it comes to practice and implementation with a BPMS, managers and other stakeholders sometime discover lately that a process brings some level of rigidity. This discovery sometimes instills some fear of losing agility which can in turn slow down BPM adoption.
This situation can be avoided with proper planning, education and clear internal communication around BPM projects. An important difference can be made with change management: one has to realize that the balance of upcoming change is positive even if there are some small losses.
BPM is seen as one out of many improvement tools and not as a fundamental (culturally) base where IMO any other tool could actually benefit from.
So, it's all about perception, urge and proof: What does BPM mean to you!? And: We're way too busy reinventing wheels here. And: I haven't seen any proof of "modelling processes" add any value to the business (because it doesn't)...
In my understanding the "main thing that holds BPM back" to organisations are:
1- Fear of changes (culture, objectives, power, etc);
2- Many people that are clinging to power, do not willing to "share" this power;
3- Difference between concerns and objectives of organisation (profit) , society (needed for consume) and investors (large and fast monetary returns).
Lack of imagination. It's surprising, to me at least, how difficult it can be for organizations to grasp the difference between an application and the platform on which such an application is implemented. As a result, intuitive leaps that are fairly obvious to the BPM community (hey, this thing works great for processing invoices, I wonder if it could also be used for managing clinical trials?) can be pretty opaque to the business itself. We rely on IT to make these types of connections, but (a) it's not uncommon, especially with respect to BPM in the cloud, for IT to be out of the picture more or less altogether, or (b) IT itself is neither organized nor incented to leverage BPM in this manner.
Thus, the business loses a huge chunk of the value it paid for when it acquired a BPM solution in the first place: the opportunity to reuse the technology to drive applications across the organization. It can be an odd feeling, as a vendor, to watch that happen. It's as though GM ran a TV ad saying, "Hey, did you know that the car you drive to work in every morning can also be used to pick up your kids from school?"
Main (and valid) reasons:
In my opinion, BPM has conquered a specialized field. The challenge now is to broaden the discipline's limits and become a common strategy to maximize efficiency.
The clearest proof of these reasons is the emergence of cloud-based tools and apps that will hopefully help democratizing BPM.
There is no doubt about the need for the digitised people driven software. For business users the BPM discipline is readily understood BUT IT has over decades really screwed up support for change to the point business just does not believe in BPM resulting in the required applications reflecting their needs in the ever changing world of businesses operations.
So how can this be addressed? Business users need to understand and thus have confidence just how the BPM software will truly support them at work. The current complexity in components required to actually deliver working solutions will never be understood by business users. However as indicated in the recent discussions about the build now taking in a graphical model in business logic language opens a door that will truly push BPM up the agenda throughout organisations.
Time for real research by the analyst community to do real independent research in "how" not just what is delivered by BPM supporting software.
People. People hold themselves and projects, including BPM, back. Why? Money and politics. The two are inextricably intertwined. Only when an executive sponsor high enough in the feeding change with the power to singularly pull the trigger AND the tenacity to see it through do things get done. The vast majority of the time, though, that doesn't happen.
Sure, most clients' projects realize some amount of functionality in some period of time and some expense, but rarely as quickly, cheaply or easily as they potentially could have.
BPM sits in a difficult spot in the bimodal IT world - it tries to reconcile the structured, rigorous, methodological approach to enterprise legacy systems and complex business interactions with the webby, agile, lightweight, ADHD-like approach of consumer SaaS / mobile apps.
Needless to say, it's a dark, stinky spot. Don't want to push this metaphor any further :-) (I already used that word a lot in here!)
On one side, the enterprise architects assert that it fully lives up to its promise only after significant development and integration efforts (which the low/no-code crowd usually ignores as they focus only on happy path designs in their glamorous BPM demos). On the other side, the business users claim it's too difficult to make it work by themselves (which the citizen developer movement tends to ignore, again focusing on tree-hugging, one-trick pony, apps).
And both camps are horribly right.
BPM sits in a similar dark, stinky spot when it tries to reconcile the service it provides. It (uncomfortably) fits somewhere between management consulting (which lacks the tech chops to deliver something more elaborate than a slide deck and a business plan in Excel) and IT development (which lacks the business acumen, the business insights and the end-user perspective required to deliver a down-to-earth, no fuss, business solution that, you know, can be managed by business itself).
Interestingly, these two perspectives are not only the source of the greatest frustrations (as seen in the answers above) but also the source of the greatest opportunity for the BPM practitioner community.
On the bright side, there are interesting, converging, efforts on both sides to... solve this.
(Phew, I almost said it.)
The question about what's holding back BPM is like a Rorschach Blot test for BPM champions!
Every comment above provides a unique perspective concerning what may be holding back BPM, depending I think on the interests of the writer.
And the spectrum of responses can be sorted according to a focus on technology versus more of a focus on business.
From my experience, all these answers are great answers, and they are all interrelated.
We explored an aspect of this question in the earlier Forum discussion concerning the possibility of a business case for BPM.
And that perspective is that it's always difficult to make a business case for "infrastructure".
The problem is that BPM, like all technology, is infrastructure.
(Many of the comments above are in some way reflections of the infrastructure sales challenge.)
It's interesting to compare the adoption of BPM technology to the adoption of another important, general business technology, namely accounting.
It took a long, long time for accounting to be adopted and refined as a common tool used to by all business people.
Fortunately, BPM technology should be adopted much faster because of the age we live in. And the increasing sophistication of BPM technology, especially concerning the modeling / round-tripping problem, will make adopting BPM technology easier.
But the final piece of the puzzle has been alluded to in multiple comments above, and that concerns leadership, specifically both business and technology leadership.
The way out of the infrastructure business case problem usually involves leadership.
And there's a big prize to be won for business leaders who step up for the use of BPM technology!
Because "BPM technology is the technology of work", by definition.
BPM technology is the technology that makes concepts of work "first-class citizens" of the technology, for direct management by managers.
All other technologies are used for the same thing (automating work) -- but only indirectly!
BPM technology is the technology which by definition directly concerns the work of business.
As such the use and mastery of BPM technology should be of direct and daily concern to all business leaders, in the same way that accounting is also of direct and daily concern of all business leaders. BPM technology is the enabling technology of work that is needed to realize so many of today's business opportunities, including business opportunities of digitization and servitization of business models and related to the Internet of Things (IoT).
This claim about the centrality and importance of BPM technology should be non-controversial.
But we are a long way from acknowledging that BPM technology (along with other irreduceable technologies of work, including business rules and data models) should be as important to daily business life of every executive, as accounting debits and credits and cash flow.
BPM technology is reaching a tipping point of technical capability.
Wider adoption is now a business and sales opportunity.
The problem is formulated in the 4th law of BPM and its corollaries (see ref1) – because BPM is a vendor-driven market then the whole BPM is not optimised for consumers. For example:
A proper BPM deployment requires:
Sorry, Bogdan, you need a real enterprise architect to lead for this.
Perhaps a contributing factor is these companies counter-productive habit of obsessively restricting access to things like process models, whose value increases the more people use them. After all, how many companies use a Collaboration Portal to make their process models available to all employees?
Oh look, now we have another question about this :)