We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What is the single most important factor in assuring BPM's success?

Vote 0 Votes
Clearly, there are many ways BPM can fail, but what would you say is the single most important factor in assuring BPM's success in an organization?

32 Replies

| Add a Reply
  • Education (and involvement).

    Any other factor is irrelevant.

    You can't do anything, let alone BPM, without it. If you can't teach, educate and involve at every level or are unwilling to then don't begin until you're mature enough to realise this.

  • Most will say 'buy in' and support from high levels, but even with that, you still need support and 'buy in' from line managers. They are the champions of the system, they are the ones that make sure the users embrace it, and they are the ones that actually ensure things get done. Without committment from this level failure is almost a cert....

  • Alignment with the priorities and goals of the business. If you dont have this, how would you measure success?

  • Andrew beat me to it - I was going to say 'buy in' from upper management, but the best way to accomplish this is to have a real 'champion' on the project. A 'champion' is a well respected person with the pull of management.

  • A BPMN process modeling tool in the cloud. Definitely.

  • Wow....I had to add this preface to my response so as not to be accused of copying the party line. The fact that we all hit this so immediately is a real testament to it's validity. My original post follows:

    Having now participated in the design, development, and implementation of hundreds of BPM solutions for customers the world over, one answer pops to the top for me. Buy-In at every level!!!! Those solutions that went exceedingly well, were quickly adopted, and reaped the most immediate rewards and successes all started with a team dedicated to achieve a clear mandate.

    From my first meeting with the client team I could tell we were destined for a showcase solution. It was obvious in the enthusiasm. It was obvious in the attention paid to the learning process while I was mentoring them along in their lifecycle training. It was obvious via the spontaneous visit(s) from executives who would normally leave such details to their report's, or their report's report's as is often the case.

    The notion of executive sponsorship is not a myth. Ignore it and you MIGHT luck into success. Nurture, validate, and foster it and you are almost ASSURED a winner will bolt from the starting gate.

  • @Emiel I would argue that a BPMN process modelling tool could well be one of the reasons of failure - and probably is for many complex processes

    • That is why concepts such as ACM have such good and strong arguments...They work for complex processes because they empower users to do their work.

      Process modelling is great for simpler processes, but for high value, complex business goals, then modelling and fixing a process to a model will end in failure...

    • Andrew,

      I was really serious ;-)

      It is absolute education and coaching on all process-touching levels (now I am serious).

      • Phew.....Problem is I have met and have read many comments that actualy would take your statement as truth, not as a dig... :)

        • Yes, I know them too. For them I have a little riddle ;-)

          What is the similarity between the Mona Lisa and a process model in BPMN 2.0?

          The lovers think it is art, most people don’t understand it and in the end it is just a painting on the wall.

  • How easy to use the system is. You can educate and get buy in until your face is blue, but if it is easier to send an email or visit a colleague's desk, than your BPM system will never be successful. People will just circumvent the system until eventually it is not even being utilized-becoming a failure. Success is dependent on a lot more than just the implementation phase, so even gaining initial adoption through education and buy in does not guarantee long term success.

    • Samantha,

      I don't think education on a bpm system is meant by most of us.

      It sounds a little soft, but I always take my customers on a journey what it means to be process oriented. And I'll try that for all levels in the organisation.

      Copied from a previous post:

      "And as I am a great fan of 'power to the people' instead if dictator-bpm I always start with some education and coaching to make employees process aware. And from then on I try to get the into customer-promise-process mode.

      I don't care if they call their work a process. I would be happy if they know what can be changed on operational level to create the process results within it's goals and when they are aware that sometimes things must be repaired in more structural way."

      And people are always very surprised that processes are not hust "blocks with arrows between them" but that it takes a lot more to manage your organization by process.

      And being aware of that, most of the time they take the right decisions on how to start with 'process'. For example buying a BPMN tool in the cloud ;-)

      • Thank you for the reply Emiel, you have made some great points for consideration. Education is certainly key, it is consistently surprising how little people know about their own processes.

        • Samantha I couldn't agree more. In design sessions I often ask how many people in this room know the process we are here to discuss, model, and implement? Every hand is raised. Then I split them up into several groups and ask each group to diagram the process. Mass chaos often ensues because they soon realize that no one in their group ultimately understands the process from end-to-end. Tremendous learning results as they then try to collaborate, as a team, to create the "perfect" process.

          If I have challenged four groups I ultimately end up with five or six different suggested diagrams. The important result of this exercise is that it forces them to develop the "big picture view" that each participant has never pondered because they have really just been focused on their part...not the whole.

  • The biggest mistake is to think that you are creating a BPM system to *prevent* people from doing the wrong thing. The biggest problem is a process that is too constrained that people have to work outside of the system.

    The most important factor is to realize that the BPM system is not a replacement for good management. The system should focus on making it easy to do the right thing, and not about making it impossible to do the wrong thing. Business is richer and more varied than our reductionist policy makers believe. Sometimes workers *have* to break the rules -- this is the "break the glass" scenario where you can get around a constraint, but you have to explain yourself later to an authority. Human organization routinely bend and break rules as needed by special situations. A BPM designer must avoid the simplistic assumption that such rules must be literally and permanently enforced by the system.


  • I'd say the most important thing is to get the automation of some process working quickly and then iterate. Don't try to be complete in your analysis of the company and its processes before you take one process and make it better. The benefits of automating processes will become more concrete and the opportunities for automating and improving other processes will jump out at you once you have one. However, it is easy to get yourself into analysis paralysis if you find yourself continually saying things like: "if we do this then it means we should also do that", "and we can also ...", "which means we should also ...". It is a slippery slope, but find yourself a nice spot a few steps down the slope and find a stopping point for your analysis, so you can actually make something real happen.

  • Emiel - I love your sense of humour "A BPMN process modeling tool in the cloud. Definitely."

  • My 2p / 2c: "collaboration".
    Most of the commenters here have hit on education/mentoring and also sponsorship.
    In my experience the precursor to success in both of these endeavours (which in turn enable BPM project success) is entering into them in a collaborative, open spirit - not preaching or dictating but inviting the team to explore opportunities, problems, priorities and solutions together.
    Sounds a bit hippy but it seems to be important.

  • Funny thread. Glad to see there's such a sense of humor here.

    I'll add something no one else has mentioned.

    Define success (ahead of time). Then measure it. Then, promote it. Once you're successful and you have the numbers everyone's agreed upon that make the initiative successful you'll get (more) executive buy-in. Driven from top down, you will have the buy-in first, but still make sure you can measure and publicize meaningful results.

    Pick a first project in which it's easy to measure some meaningful success. To me, that's the definition of low-hanging fruit.

    IMO, over time, you'll enrich what you measure, and be able to give different constituencies different measurable business benefits on the same architecture. People will be able to explore their processes, and the data collected around them... wait, am I shifting the conversation to big data? Sorry about that :-)

    Software AG (so, I'm likely vendor biased)

  • Take 2.

    Ok, so after submitting, I'd want to say it a little differently...

    How do you know if it's successful?

    Know what makes it successful.

    All the education, all the collaboration, all the ease-of-use... that won't matter if you can't first agree what makes the initiative a success, and second agree how to measure the success criteria.


  • I really love the "bit hippy" approach of NWD. My personal success factors are to well identify, delimit and share the BPM project core objectives. Today BPMS and tomorrow iBPMS are so rich in capabilities that driving a project into the wrong direction could be more than a temptation. So remain focused on the end of the race and concentrate the products capabilities on that is the route that should be followed, at least in a first implementation. Enrichments can and must follow it.

  • Perhaps it's learning from the failures.

  • I see still a lot of comments about implementing a BPMS instead of BPM. If you really think BPM = BPMS, then implementing BPM would be very easy. Just click setup.exe (or even in the cloud) and you are ready.

    To me that is just a great chance of failure and get employees to hate 'process'.

    "We have a great tool implemented, but nobody knows what it has to do with BPM and if it really helps to become more process oriented"

    Not every company is helped by BPMS, so if your thinking of buying one, don't forget to ask for the free CS add-on!

    • Was about to comment the same thing, lots of 'vendor' based chats about systems but not much on BPM methods. Again, if their hype cycle is to be believed, Gartner reckons it's another decade before the method adoption in the enterprise hits mainstream and yet people expect success purely based on using BPMS.

      Seriously, if you gave your product to a child would you expect them to successfully implement it, no matter how easy it is to use ? I don't see an illiterate man knocking out a blockbuster without knowing how to read, write and understand literature, so don't expect the business to knock out efficient processes and business architecture using your tools without understanding BPM.

  • SaaS enablement & integration.

  • user-pic

    Here's an odd one. Give your organization a tool to model their processes, set up some conventions, and give basic training. Then wait for a critical mass, some champions and the evolution will do the job for you. Avoid early buy-in and high expectations. Guerrilla warfare is more effective for such initiatives than fighting a conventional multi-front war with other horizontal big spenders like BI, MDM, SOA, etc.

  • Seeing all the comments above about systems,methods and people I think the 1 factor to BPM success is for once and for all defining what BPM is!

    I got a comment from a director once " If you are paid to think, something is wrong"
    I am not sure if anyone has experienced this but it just means that they want to do the same thing over and over again and expect different results. And I was the Process Analyst!

    IMO to ensure BPM (if I can call it that) is a success, the number 1 thing would be to ensure the improvement activites (project, program) is closely tied to the value the business is providing to the customer.

    BPM has become a product of marketing processes as the most important when in fact the overall business is the most important. No one can go on and on about something that is failing and still be allowed to speak. For every 1 project that has success, there are so many that fail. Instead of analysing why those failed, thinking a solution exists, why not stop altogether and instead focus on the value the company is providing and streamlining that.

Add a Reply

Recently Commented On

Monthly Archives