Resolved
2 votes

As I believe scalability is the key to capitalizing on BPM success, along with this scalability question I asked a few weeks ago, what do you think is often the biggest barrier to BPM scalability in an organization?

Tuesday, July 28 2015, 09:48 AM
Share this post:
Responses (10)
  • Accepted Answer

    Tuesday, July 28 2015, 11:40 AM - #Permalink
    Resolved
    4 votes

    In short: Buy-In. We are working with a large financial institution automating a number of their processes. Everytime we touch a new department or involve new staff they have to be treated as a new customer and the selling process begins all over again. Without the same level of Buy-In at each touch point there will be significant resistance to scaling the effort across the enterprise.

    • Patrick Lujan
      more than a month ago
      That's endemic to all efforts and is the very first rule to all of them - senior sponsorship. No stakeholder(s), no go.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 28 2015, 12:10 PM - #Permalink
    Resolved
    4 votes

    I agree with buy-in or even, "sticky buy-in" where the process-centric thinking sustains versus being filed away as the always new business pressures mount. The constant fire fighting in organizations; the doing more with less situation can really hinder adoption, CPI, etc.

    my 2 cents

    • Patrick Lujan
      more than a month ago
      "the doing more with less situation can really hinder adoption," /sites I've been in where it's a team of a half dozen or less?

      I know a Global 10 financial where a guy clocked 127 hrs one week on PeopleSoft into about a dozen different buckets.
    The reply is currently minimized Show
  • Accepted Answer

    Maria Paz
    Maria Paz
    Offline
    Tuesday, July 28 2015, 12:53 PM - #Permalink
    Resolved
    4 votes

    In my opinion, the biggest barrier to BPM scalibility is poor knowledge management.

    Let me explain myself: knowledge management is all about taking advantage of the konwledge that already exists within an organization (and its processes) and using that knowledge to train new employees, make decisions and all sorts of actions that benefit the company.

    That way we don't have to reinvent the wheel every time we want to do something. If we learn to use that knowledge and manage it properly, we can escalate. But if we don't use knowledge management, we won't know which processes are repetitive and hence best to automate.

    Knowledge management allows us to produce more with the same resources, in less time and more efficiently. And don't forget that knowledge management requires of document management.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 28 2015, 01:27 PM - #Permalink
    Resolved
    4 votes

    that was too easy, Peter! :-)

    of course it's about buy-in when scaling within organizations, but .... (you knew this was coming) low buy-in is actually a symptom.

    I could think of reasons that are actually drivers of a low buy-in:

    1/ a BPM initiative that creates too much planning overhead - BPM steering committees, process maturity frameworks, project managment, consulting disclaimers etc --> this sends to the organization the signal of yet another expensive, passing, management fad;

    2/ focus on the wrong first processes - either too heavy (prone to failure) or too easy (prone to irrelevance);

    3/ too little attention to the entarch design - BPM is being done in isolation to the overall enterprise landscape;

    4/ vendor lock-ins - the customer uses that tool because it was part of a larger licensing package, not because it's the right tool for the job;

    5/ a solution that does not sufficiently involve the actual front people - the ones that are operating the solution first-hand.

    I'm all out, but I'm sure there's more.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 28 2015, 03:13 PM - #Permalink
    Resolved
    3 votes

    Barriers to BPM scaleability? For sure there are all good answers here, but I submit that the answer we need is one concerning BPM specifically.

    Otherwise, we've just added to the mountain of literature on good project management, good project selling and good project governance. And we have nothing to take the bank specifically about BPM-as-a-unique-and-powerful-technology. (@Patrick and @Bogdan go in the direction of being BPM-specific.)

    My answer in the first version of @Peter's BPM forum scaleability question was that BPM is a fundamentally different and powerful technology. And that BPM opens a door to a new way of focusing on business.

    Specifically managers begin to see their role as being in the "process manufacturing business".

    From this fresh managerial mindset then will come a demand for the technology products that are purpose-built for building processes.

    And then scaleability is only a question of organizing.

    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 28 2015, 03:36 PM - #Permalink
    Resolved
    5 votes

    Having a proper foundation (this word is borrowed from Gary), of course. Even with a strong buy-in a dog-house can’t be transformed into a nice apartment block.

    See the 3th law of BPM in [ref1].

    Thanks,
    AS

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, July 28 2015, 04:40 PM - #Permalink
    Resolved
    3 votes

    Could the mess of legacy tarnish the potential of scaling BPM across the organisation. The silo mentality could be a real barrier as scaling BPM can cross silos even challenge old style management. The BPM thinking breaks down business activity into relativity.small yet very focused areas of activity reflecting how people actually work together in relatively small groups. This creates the challenge to convince the business that the required connectivity is possible across the whole organisation. This approach to next generation enterprise software will require old "IT" to change until then therein lies the biggest barrier....?

    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 29 2015, 05:04 AM - #Permalink
    Resolved
    5 votes

    I have to disagree with several of the responses, for a change, since complaining about the lack of ‘buy-in’ doesn’t answer the question. In fact, as Bogdan points out, an organisation might have good reasons to resist scaling BPM across the organisation. If the answer to Peter’s question is ‘because they don’t want it!’ then perhaps we should think about why not.

    I believe the biggest barrier to scaling BPM across the organisation is that BPM as it is usually imagined, practiced and embodied in software products and IT systems is simply too heavyweight to be broadly relevant. Instead, only rare situations will provide a sufficient return on the huge investment that is usually required to implement any kind of BPM.

    The way forward is to recognise that there are, say,Four kinds of business process software. To scale across the organisation, we have to be able to scale solutions down to be useful for smaller lower-budget problems, as well as mega-projects and consultant armies that implement traditional BPM. Otherwise, trying to get widespread BPM adoption in an organisation remains as wrong headed as trying to replace every little spreadsheet in the organisation with a relational database would be. (AndThere’s more than one kind of database.)

    Scaling BPM across and down obviously isn’t principally about software tools, though. A more important challenge for the BPM community (even if it is fifteen years late), is to move on from old-fashioned and discredited waterfall IT project delivery approaches. We need some kind of agile BPM. I therefore would love to see a question about that on this forum:

    How can BPM apply and benefit from the principles of theManifesto for Agile Software Development?

    • David Chassels
      more than a month ago
      Well said fact is there is a need for that new approach in the supporting software which removes complexity in build of any requirement and driven by business. Time for buyers to truly understand how this will deliver and remove smoke and mirrors from vendor PR...and analysts to work exclusively for end users not be paid by vendors!
    • Dr Alexander Samarin
      more than a month ago
      BPM is already agile in accordance with its 10th law.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, July 29 2015, 05:46 AM - #Permalink
    Resolved
    4 votes

    I like Neil Ward-Dutton's thought on the matter. He said basically this: there are about 15% of organization that have an appetit to change in their DNA. And they are yours (addressing to BPM vendors and consultants). But the rest 85% won't buy it whatever you do.

    I'm afraid Neil is right. I've seen too many times the dream that successful BPM project would lead to another larger project until the whole organization would fit into the BPM scope didn't come true.

    What can be done about it?

    Several things, if talking statistically:

    - Digital disruption changes the percentage above to more favourable.

    - We (the BPM industry) must make another breakthrough. BPM makes process change 10 times easier comparing to ERP but it's not enough for the majority. We must make another qualitative leap in terms of ease of use and implementation speed. BPM+ACM blend, social+gamification, perfect mobile UX, subscription+IDE in a browser - we are moving in all these directions but we aren't there yet.

    - BPM consultants and implementation partners should realize that BPM is more a social endeavor than technological. Some BPM professionals today position themselves as change management specialist first and foremost and I believe it makes a lot of sense.

    Yet within a given organization, little can be done if you hit the cultural barrier. Because as someone rightfully said, "culture is a read-only attribute".

    Like
    1
    • Bogdan Nafornita
      more than a month ago
      great comment, Anatoly. I am actually kicking off a change management project where the sponsor is really convinced about the value of a process-driven approach. But I will work on behalf of the customer (not of the vendor) to get his processes right.
    • Anatoly Belaychuk
      more than a month ago
      Good luck on this, Bogdan! Passionate executive and knowledegeable leader is a killing team!
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 30 2015, 03:41 PM - #Permalink
    Resolved
    2 votes

    Many good thoughts here, but to add an orthogonal idea: user interface. Process implementers seem to spend far too little time on their e-forms and other UI elements (see my blog post, "Your Users Hate Your E-Forms"). If the UI is subpar, adoption will suffer. If adoption is poor, expansion is unlikely and scalability is, well, moot.

    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
278 Replies
29/09/2016
David Chassels
270 Replies
29/09/2016
Emiel Kelly
223 Replies
29/09/2016
Bogdan Nafornita
210 Replies
29/09/2016
E Scott Menter
182 Replies
28/09/2016