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

Are BPM suites endangered?

Vote 0 Votes
A question that came up in my discussion with Neil Ward-Dutton, The state of the BPM value proposition--and of BPM suites, is the idea of an all-in-one tool for BPM no longer feasible?

10 Replies

| Add a Reply
  • If you can find a tool, any tool in the IT realm that does everything it claims to and do it well then I'd claim you've found the Holy Grail.

    Many of the larger BPM software houses have cobbled together their suites from mergers, or current offerings once their market research shows there's a demand for it, but the trouble with this is that the integration layers are so poor it's not seamless and a very bad user experience.

    If there was really an all-in-one suite it would have to be built from the ground up....but then it faces the same problem further down the line, eventually you'll need a bolt on to accommodate a new demand.

    Creating a one-stop shop solution has little value for those companies not mature enough to use every available feature (and lets face it, would you buy a swiss army knife just to be able eat a bowl of cereal or an Ikea spoon that does what you need it to ?)

    Vendors should concentrate on building modular systems that are truly ground-up implementations. Take the Apple approach, build the OS and foundation, then the ability to have BPM apps that serve a clients needs when they require it.

    Maybe then we'd be able to rigorously apply industry standards (like BPMN 2.0) because it would start to enforce quality control.

    Too utopian perhaps...

  • BPM Suite are under attack from various angles

    Platforms that allow you to build apps easily emerge - eg Force.com will replace the role of a BPM Suite for 'general purpose app development' eg Managing Expenses

    The ERP players already have capable BPM Suites built in are are looking to extend their footprint so clients can build beyond the areas of their core functionality

    So BPM Suites will become specialist niche players - such a high volume transaction processing, or the plumbing that stitches disparate systems together.

    BPM Suites have not had their "tornado" and despite many false dawns it is unlikely to happen. They need to hunker down and find a profitable niche.

  • Simple answer is No. There is still huge demand for BPM Suites as these tools are proven to deliver value solutions with ROIs of 6-12 months.

  • In a previous life I worked for a wannabe BPMS vendor (they are all wannabes before somebody there thinks I'm trying to single them out). That company, like all their competitors were faced with the analyst invoked 'race to the bottom'. You have to check the boxes to get the ratings, and at the end you have a suite that is meaningless to all but a handful of companies.

    Having a modular solution that can deliver the business process improvement needs of a mass of businesses does not require a BPM suite. We have all discussed a hundred times how a BPMS doesn't get the recognition of ERP or CRM as a defined 'thing', making it hard to sell. So BPMS will be fine, and it may have some good ROIs in tightly defined projects. But as Ian suggests, finding that niche is the best way to get those ROIs.

    Not to bash some of the great technology, but most of it is over the top for any solution outside Fortune 500 enterprise solutions. For example, who needs to slice and dice the BPM analytics of their accounts payable process to get it to run better? How many companies have hoards of employees doing this work?

    Much of a BPM suite therefore is overkill and will be a costly technical exercise to maintain and grow for the vendors. This will be the killer as cost cutting execs try and squeeze more profitability out of them.

  • The challenge in any of these discussions is to define "BPM". Are we talking about the applications that manage work and data flow or the ones that are deployed to end users? I agree on the workflow side that cobbled together offerings lack true integration and aren't going to set the world afire. Applications that provide building blocks onto which greater and greater value can be layered are the stuff of the future. Force.com is a great example.

  • To be fair, I didn't actually say that an all-in-one tool for BPM projects isn't feasible; I said that I expect that vendors marketing them as such will become fewer and fewer. I see more and more vendors focusing on selling their tools around specific "entry points": process instrumentation/intelligence, process automation, process architecture and so on.

  • The tooling is the easiest part of BPM. It's defining and gaining consensus on the definition of the process that is the real challenge. I rarely see much value in a "pure play BPM" tool without services to support the process models. Otherwise its just a design-time tool and most Business Analysts already have their favorite drawing tool (Visio).

  • Look at the vendors who offer BPM suites, not necessarily the span of the suites' functionality, then tell me if those vendors are endangered. I think not.

  • Short answer: yes.

    The idea of a single tool to handle the breadth of discovery, modeling, optimization, execution, and control required by real-world business process management (BPM) deployments is a bit of a stretch.

    What forward thinking organizations are looking for (and leading vendors are providing) is an integrated set of tools that offer a mix and match approach to assembling the “suite”. Not every organization is prepared for, or even has a real need for, every component in a BPM suite. And, facilitating communication between technical and business users by providing the right tools for each audience can drive excellence in discovery, design and execution that can be lost when a single environment is forced on all participants.

    Organizations that are looking to analyze and automate an existing, well known manual process problem may not need advanced simulation or optimization.

    Other organizations may want to focus on process discovery in order to build a process, or focus on an enterprise business portfolio to understand and build a business case for moving to BPM. Does this organization need this analytical tool to be the same tool that they will eventually use to build complex system to system, integration-centric BPM? I would propose no. In fact, forcing such complexity where it is not necessary can actually limit acceptance and use in real world implementations. Mr. Priestley makes a very good point, one of the key areas of integration is at the end user – I call these the consumer and participant levels. Having a common method for organizing, navigating, and using models, model analytics, as well as how you participate in automated processes, is key.

    The goal in my experience is to allow organizations to avoid waste – wasted time learning complex methodologies and notations, wasted time investing in building analytical models in an automation tool, and wasted time entering data for analytical models that end up as drawings and do not drive analytics and future execution or configuration. And yes, the favorite tool of many business process analysts is a drawing tool, not a modeling tool. A bit sad….

  • Modular design is more attractive to architects indeed (and probably industry analysts, too) but it's not the choice of most vendors because they make more money on all-in-one offerings.

    I can't see a move in vendors' preferences that would justify Neil's prediction. In fact it's quite opposite: big vendors that acquired pieces of BPMS technology are making them *less* modular after integrating into a stack. As an example, a BPM suite that supported a range of standard JEE servers when it was pure-play now supports only the JEE implementation of the vendor that has acquired the technology.

    BPMN 2.0 can become a game-changer in theory because now it's possible to exchange process models between different tools but again it's against vendors' interest.

    Of course it's the end users who decide at the end of the day but who has more influence on big customers - vendors or architects?

    So my prediction is opposite to Neil's - as BPMS goes mainstream we'd witness further consolidation of the market but these few remaining offerings would be all-in-one monsters.

    Look at current mainstream DBMSs - there are more-or-less standard SQL, standard J/ODBC to the basic functionality and that's it.

Add a Reply

Recently Commented On

Monthly Archives