Resolved
3 votes

In your experience, what is the key thing that holds BPM back in most organizations?

Tuesday, October 20 2015, 09:48 AM
Share this post:
Responses (16)
  • Accepted Answer

    Tim Bryce
    Tim Bryce
    Offline
    Tuesday, October 20 2015, 10:13 AM - #Permalink
    Resolved
    2 votes

    An organization that thinks systems begin and end with programming. They cannot think big, only small. This is like carpenters trying to do the work of the architect. Sadly, it never works.

    References:

    1. http://timbryce.com/
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 10:27 AM - #Permalink
    Resolved
    3 votes

    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?

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 10:42 AM - #Permalink
    Resolved
    3 votes

    I wrote a series of posts about this (barriers to BPM) over on our blog. Often it comes down to leadership, empowered to knock those barriers down.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 11:07 AM - #Permalink
    Resolved
    2 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 11:08 AM - #Permalink
    Resolved
    4 votes

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

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 11:10 AM - #Permalink
    Resolved
    3 votes

    Hi all!

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

    Rgds, M

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 12:05 PM - #Permalink
    Resolved
    2 votes

    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?"

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 12:34 PM - #Permalink
    Resolved
    4 votes
    Besides all the previously said, that's true, I find the inability to materialize the promise of continuous improvement through BPM. I mean, if you cannot model, deploy, test, adjust and deploy again in minutes (not hours, not days, NOT WEEKS!); then you won't get several improvement cycles. You'll have just one, the first. Taking that into account, I see BPM massive adoption in companies who haven't already done it, if and only if, the BPM Suite allows fast improvement cycles. Because of this SaaS and fast tools are powerfully emerging (see Flokzu; Pipefy; Effektif).
    The reply is currently minimized Show
  • Accepted Answer

    Maria Paz
    Maria Paz
    Offline
    Tuesday, October 20 2015, 12:57 PM - #Permalink
    Resolved
    3 votes

    Main (and valid) reasons:

    • Consultancy and implementation costs
    • Too complex
    • Requires management time

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 05:35 PM - #Permalink
    Resolved
    2 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, October 20 2015, 07:59 PM - #Permalink
    Resolved
    3 votes

    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.

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 21 2015, 04:21 AM - #Permalink
    Resolved
    4 votes

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

    • John Morris
      more than a month ago
      Someone needs to compile a "Sayings of Chairman Nafornita". I count at least three QOTW candidates in today's offering.

      On the serious side, for BPM practitioners and business champions alike, there's an exciting and optimistic message here. The message is that the "timing is right", specifically about how trends are converging to a place of significant and real progress concerning the successful use of business process technology.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 21 2015, 11:18 AM - #Permalink
    Resolved
    1 votes

    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!

    Why?

    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.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 21 2015, 04:04 PM - #Permalink
    Resolved
    5 votes

    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:

    1. BPM discipline (no commonly-agreed one),
    2. BPM-suite tools (monoliths of monoliths) and
    3. BPM practice (no tool-independent repeatable techniques)

    A proper BPM deployment requires:

    • right process architecture
    • well-thought enterprise-wide deployment of a BPM-suite
    • breaking development practices coming with the BPM-suite
    • creating your own enterprise quick process-centric solutions delivery
    • architect/implement the rest of enterprise IT around BPM

    Sorry, Bogdan, you need a real enterprise architect to lead for this.

    Thanks,

    AS

    • John Morris
      more than a month ago
      I already "liked" @Bogdan's note. Can I like @Alexander's too?

      Regarding the 4th Law of BPM, and the persistent vendor-centricity of BPM technology, it can be compared to a world (fortunately imaginary) where every accounting software package has differing conceptions of accounting fundamentals. The problems boggle the mind - not to mention the lack of respect by business leaders . . .
    • Bogdan Nafornita
      more than a month ago
      Hey Alexander, I never said you don't need a real enterprise architect to deliver BPM.

      I hope I was clear that I am NOT a fan of the no-code / citizen developer movement. :-)
    • Dr Alexander Samarin
      more than a month ago
      Bogdan, your third paragraph gives an impression that enterprise architects are strongly associated with “significant development and integration efforts” which is not correct because a proper architecture enables agility.

      RE “no-code / citizen developer movement” – agree, it is better to use a coherent combination of various techniques than focus only one of them (like in the chess game – a novice player use only the queen while a grandmaster understands how to “play” all chess mates in the right direction and in the right sequence).
    • Dr Alexander Samarin
      more than a month ago
      John, the excellent example!
    • Bogdan Nafornita
      more than a month ago
      Alexander, I am having in mind a real-life example, where I have to integrate an agile BPM concept with a sort-of financial accounting system that is so old (think FoxPro!) that is simply unable to communicate well with any system. While I dream of being able to replace that system with a nice SoA component and stick a nice canonical data model in its mouth, I have to face the fact that it can't be changed yet due to reasons outside my control / influence. So I have to rely on some temporary constructs to get it done - ugly, but works.

      I'd love to see an agile, no-code, proposal to my challenge :-)))

      Reality is what happens to us while we're busy making other plans.

      I know my reality stinks, but hey, anyone can cook, right? ;-)
    • Dr Alexander Samarin
      more than a month ago
      Taming monoliths is a typical integration problem. Potential techniques are:
      - data assets APIs (start with R/O APIs and, maybe you will be allowed to write)
      - business API (when you externalise also all business logic)
      - externalisation of some events (e.g. compare two snapshots and derive changes)
      - business processes over and around monoliths

      Thanks,
      AS
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, October 22 2015, 09:55 AM - #Permalink
    Resolved
    3 votes
    What’s holding BPM back? A failure of nerve.
     
    Because BPM is the world’s most important technology for the automation of work. And it goes without saying that the automation of work is the primary purpose of technology.
     
    BPM is the only technology that explicitly and directly concerns the work of business and government. With all other technologies our intentions to automate are mediated. The cost of that mediation is enormous.
     
    With BPM on the other hand, the artifacts of the management of work are first-class citizens of our technology, enabling us to just “plan and do” in real time.
     
    Mature BPM technology is revolutionary in its impact on what we can accomplish with our work.
     
    If we don’t understand this, or don’t believe this, then we can’t sell BPM.
     
    • Dr Alexander Samarin
      more than a month ago
      RE "BPM is the world’s most important technology for the automation of work" - maybe "coordination" is better than "automation" ?
    • John Morris
      more than a month ago
      Dr. Alexander, good comment, and "coordination" could be better than "automation".

      You have explored this a lot in your writings. The question though is deceptively simple -- and the shows up in considering what the IoT is, for example. One aspect of this question is that of the identity of the actor - if it the actor is human, then "coordination". If non-human, "automation". But at different levels of organization for work, one can specify different actors, including possibly "compound actors" which may consist of work teams, including their tools. In such cases, I can't say which word should be used, and why one would be better than another.
    • Dr Alexander Samarin
      more than a month ago
      Thanks John for highlighting this difference. My understanding is that coordination is "the organization of the different elements of a complex body or activity so as to enable them to work together effectively" and those elements may have different origins. I can imagine that a non-human active actor may coordinate other non-human and human passive actors.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, October 30 2015, 04:25 AM - #Permalink
    Resolved
    2 votes

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

    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
25/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
220 Replies
23/09/2016
Bogdan Nafornita
209 Replies
25/09/2016
E Scott Menter
182 Replies
23/09/2016