Resolved
1 votes
In your experience, what are the biggest and most persistent mistakes that you see companies continue to make with BPM?
Thursday, May 08 2014, 09:55 AM
Like
1
Share this post:
Responses (15)
  • Accepted Answer

    Thursday, May 08 2014, 10:22 AM - #Permalink
    Resolved
    5 votes
    May I submit two? 1) "BPMS without BPM": let's automate all our processes! 2) "BPM without BPMS": let's document all our processes!
    Like
    1
    • Lloyd Dugan
      more than a month ago
      Far more the first than the second. Unfortunately, on many of the posts in this very forum, this failure to distinguish BPM as a discipline vs a technology platform is all too often on display.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 10:50 AM - #Permalink
    Resolved
    2 votes
    They manage BPM as an IT project, at best as several IT projects.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 11:31 AM - #Permalink
    Resolved
    1 votes
    Thinking "ERP" not BPM! (See my comments here Who is to Blame for Most ERP Train Wrecks? At BPM Guru http://lnkd.in/bsbpayw ) Not thinking "big" in “small bites” as a long term evolutionary transformation project for the whole organisation.
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, May 08 2014, 12:46 PM - #Permalink
    Resolved
    1 votes
    Not being clear about that the project is trying to achieve and then using the correct approach and tools so get the best result.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 12:50 PM - #Permalink
    Resolved
    2 votes
    Gosh -- so many choices, so little time! How about: operating under the assumption that they know how their processes actually work, and never checking to see if they're right! It's amazing just how differently managers and executives view the work their people perform than the people themselves do.So you have to start by triangulating in on the truth -- only then can you begin to figure out what changes you want to make!
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 12:56 PM - #Permalink
    Resolved
    3 votes
    Believe that they have to model ALL their processes as the first step toward BPM. Consider that a BPM tool is the main success factor. Implement integration not business processes. Ignore architecture. Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 01:11 PM - #Permalink
    Resolved
    2 votes
    One big mistake I see frequently is made when an organization thinks that "no code" means "no technical skills" required in order to build and deploy workflow-driven apps. The business sees an easy drag and drop, point and click interface and assume the whole project requires about as much skill as using Outlook. They assign their lowliest analyst, skimp on training, assign them complex projects with subtle behaviors, and are then surprised when the whole effort goes nowhere. Keith likes to say (and forgive me if I'm misconstruing) that building processes is just like writing code—I don't agree with that idea specifically, but his point is well taken. It doesn't matter how simple is the tool itself: complex problems demand a certain amount of skill on the part of the problem solver.
    The reply is currently minimized Show
  • Accepted Answer

    BPM Mentor
    BPM Mentor
    Offline
    Thursday, May 08 2014, 01:38 PM - #Permalink
    Resolved
    3 votes
    The most frequent mistake I experience is companies expressing solutions instead of requirements. And analysts blindly following the prescribed without a real assessment of the impact.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 02:23 PM - #Permalink
    Resolved
    3 votes
    Oh how tempting to make a list. But there is one biggie. People treat BPM like it is Lean. Or Six Sigma. Portray themselves as Process Improvement gurus and impose a solution. The greatest benefit of BPM is that it isn't a pre-computer methodology. The software delivers us real-time data. Lots of it. We know how many Yesses and Nos in a switch. We know utilisation. We know latency. We can see bottlenecks, happy paths, wasted resource. So we don't need to be a guru. We don't need to get it right out of the box. We can put in a minimum viable process and run it, again and again. We can build data on the bits that are working and the bits that are not We can get feedback from the people running it, from the customers and everyone else involved. Then we can have a much better discussion on the shape of the final solution. When someone says they need added resource here or can save here, you can show them the figures. When someone says it can't be done in this timespan, show them why it can, or what is stopping it. And everyone can look at the map and see new ways of streamlining it, not just the expert. That creates a much better process than even the best guru could do without data. This Lean Startup re-iteration thinking continues after the first flush of improvement too. BPM shouldn't be just a fit and forget project. It should be always on. It should go through a rapid Six Sigma "take the biggest problem and reduce it" reiteration. This helps it evolve as the customer needs change and the process it defines changes with it. That means the method must change from guru to trainer. To involve the team and teach them how to make it work, not just treat them as a client.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 08 2014, 04:28 PM - #Permalink
    Resolved
    1 votes
    Approach by procedures without a frame and alignment with the business strategy, which normally results in modeling of work instructions, or to automate, or to do some kind of structural analysis design. Thus, it often loses the opportunity of business transformation and of introduction of one culture of measurement of process benefits to the corporate objectives, that BPM should introduce into the organizations.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 09 2014, 05:35 AM - #Permalink
    Resolved
    4 votes
    Treat it as a project instead of understanding that BPM is daily business.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 09 2014, 12:12 PM - #Permalink
    Resolved
    3 votes
    "How many ways can I fail in my BPM project, let me count the ways"...apologies to Elizabeth Barrett Browning. The usual suspects have nailed every dimension. Any new readers on the subject of BPM could make a nice check list of things not to do (an 'anti-checklist' maybe). Allow me to "like" @Emiel's comment that it's an error to treat BPM as a project, "instead of understanding that BPM is daily business". This statement captures in the simplest possible terms the idea that BPM == business and business == BPM. The ramifications are kind of amazing when you think about it. In the same way that every single business executive learns the fundamentals of accounting at some point in their career, in the future, every single executive will learn the basics of the technology and management of process modeling and process execution. (This won't happen for a while because the technology is still developing.)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 13 2014, 04:29 AM - #Permalink
    Resolved
    2 votes
    I'd add time to market to the discussion. As we all know, business processes tend to change quite quickly and frequently. Therefore companies must deliver solutions (using BPMS) quickly. When it takes e.g. 3-6 months to be done, there's very high chance that business won't need it anymore. Same applies to constant optimisation of business processes. A right approach and proper tool will allow to respond to changing business requirements almost instantly.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, May 13 2014, 11:40 AM - #Permalink
    Resolved
    1 votes
    I voted with Emiel - Treat it as a project instead of understanding that BPM is daily business. But I'll add another one - not thinking early enough about user adoption and change management across a wide range of groups.
    The reply is currently minimized Show
  • Accepted Answer

    Amy Barth
    Amy Barth
    Offline
    Tuesday, May 13 2014, 12:28 PM - #Permalink
    Resolved
    1 votes
    My experience is with government projects. The biggest problem I've seen is inflexibility spurred by not understanding what BPM can do and how it may be doing the same thing as a requirement, but in a different way. Earning client buy-in was the primary effort with lots of show and tell over a (too) long period of time. Also, the "sales" team promised more than the product could provide, and so the client was rightly frustrated when BPM product could not do what they thought it could do.
    Like
    1
    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
275 Replies
23/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