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 mistakes do businesses still make with BPM?

Vote 0 Votes
Big or small, what mistakes do companies still persistently make that prevents them from realizing the full benefits of BPM?

10 Replies

| Add a Reply
  • The biggest mistake IMO is to use an agile BPM and turn it into an IT project right from the start. Many times programmatic integrations with external systems are coded right from the start. Business process systems are agile. But when you integrate custom coded integrations too soon, then you can't leverage the agility of the BPM system any more. Custom coded integrations are not easily changeable.

    Better is to focus on the people first. First coordinate the people, automate the handovers and escalations. Business people can do that with today's BPM systems. As long as the process only deals with handovers and escalations, it's easy to change.

    After that process has matured and it is stable, then custom build integrations with other systems make more sense.

    So my advice is to consider 2 separate phases when automating a business process: First coordinate the people. Make the most of the BPM system flexibility. And when that is clear and stable, only then build custom coded integrations. You will save many precious developer cycles.

  • I am constantly seeing the tendency of firms to look at point solutions from various vendors as 'plugging holes' in their various process automation needs rather than understanding BPM as a strategic focus. This tactical reactionary approach means fragmented user experience and IT/Business Analyst nightmares. Software vendors heavily promote embedded 'workflow' as part of their offering but that tends to lead decision makers to focus to narrow and not at the strategic level. Many get frustrated after they have spent serious money on implementation to find that their 'workflow' doesn't have much flexibility or capability they expected.

  • (1) Believing vendor sales hype
    (2) Biting off more than they can chew in terms of program size and software complexity against maturity and knowledge
    (3) Not knowing just what they are aiming more and where they are starting from
    (4) Forgetting that BPM is not a one-off activity

  • It is a business project not an IT one.

    Asking your people at the coal face how the "process" actually works and then how it should work.

    Failure to do research on the supporting technologies……include reading ebizq The Insider's Guide to Next-Generation BPM …!

    Recognising that if you can't understand the technology in business language do not buy it......

  • "Forgetting they are doing BPM."

    You think that sounded silly? Well if you really look at the not-so successful BPM projects, I wont be shocked if you find out that all the BPM talk happened at the beginning of the initiative.....and then somewhere along the line it became just another software project.

    Scan through the views of all those smart folks above and you will see why 'forgetting' could by far be the single biggest problem.

  • As long as silos exists and their is a hierarchal architecture, more often than not BPM fails because it doesn't sit well with everything happening at the top. Coupled with the notion that BPM is a "technological solution" and BPMS selection coming before training staff in BPMN and you got a recipe for disaster right off.

  • 1) Projects are too large and complex (how do you eat an elephant?)
    2) Using agile and not understanding how to use it
    3) Using Agile and not getting detailed requirements and the design before entering sprints. Just because the book says so!
    4) Not allowing enough time for business involvement throughout the project lifecycle

  • One of the most insidious problems is known as "Naive Intervention".


    The process model that you make is necessarily simpler than reality. The problem appears when we make decisions based on those simplified models. There may be a satisfying narrative about why a particular change might improve productivity, but never forget that it is just based on a model.

    Because the model is a simplification, conclusions based on the model are not necessarily correct. Here is the ironic part: because a somewhat formal method has been used, this incorrect conclusion can gain the air of unwarranted respectability. This is the unintended consequence of formalizing the unformalizable.

    This really has nothing to do with technical limitations. It is instead a cognitive limitation.

    How to avoid? Assume that most of your conclusions will only be partly correct. Go ahead and make a change, but don't assume that it is correct. Make lots of changes, and watch carefully the results. And then, go back to the changes that worked well. It is not about predicting the single best practice, but instead experimenting with lots and identifying what worked.

  • Ironically: too much process. If you treat a BPM roll-out like a full-fledged SDLC delivery, you will strangle it at birth with the umbilical cord of its own red tape. The strength of BPM is its ability to create rapid prototypes you can deploy and improve.

    Automate. Refine. Repeat.

  • "Considering BPM as a Magic Box" - which will streamline and organize their messed up organisation and at the same time providing all solutions for their nightmares and day dreams -> as they have paid a price for the product.

    What 'believe is : BPM is all about continuous process improvement, which also involves in bridging the gap between the Business and the IT fraternity helping them to talk and communicate on the same platform. Changes don't happen overnight. The business also has to spent ample amount of time and research to exploit the features best suited for the betterment of the enterprise. The time you invest in understanding BPM is the RoI you get. Not the phrase "The price you pay for the BPM, is the RoI you get"

Add a Reply

Recently Commented On

Monthly Archives