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

How often does a company have more than one BPM suite?

Vote 0 Votes
From @GregChase: How often does a company have more than one BPM suite? Often there's what IT bought, then there's several others the business uses. Is this a big problem, and if so, how does it need to be resolved?

9 Replies

| Add a Reply
  • More often than you think and a vendor will admit. BPMS solutions are often thought about as a point solution to fix a particular problem and because organisations are divided into silos a Change/ BPM project in one division may never be communicated to others so that they reap the benefits.

    CIO, COO and CTO strategy is non-existent despite a lot of analyst hype saying that 'BPM is the top of the agenda' and they are mostly uninterested in what a division does with it's change budget on a local level, so you get pockets of instances of 'X' BPMS deployed to fix or automate a complaint process and 'Y' BPMS to sort a application process.

    And that's when user frustration kicks in when they have to initiate so many different systems from the desktop environment and the value of implementing a BPMS is eroded.

    Lack. Of. Strategy.

  • 80% of the companies I work with have at least 2 major BPM suites. 40% have 3 major BPM suites. There is more questions around rationalizing the platforms and deciding whether to reduce to 1 or 2. In addition, what is the criteria and measurement framework to guide the rationalization.

  • Often. There is a dichotomy in process that confuses the marketplace and frustrates the end users. I watched a major corporation send out an RFP for BPM when they already had two, Nimbus and Provision. And it wasn't workflow. Making it probably too simple, there are three areas of BPM that need to be satisfied:

    - Process and data architecture (system-system)
    - Automaton of process (workflow of all types)
    - Intelligent operations platforms (human-human and human-system)

    There isn't a single product that does all of this well, despite claims to the contrary. The one that gets dropped is the last of the three, because we've never considered process to be personalized before.

    Tom Molyneux wrote a piece today on that very topic: http://successfulworkplace.com/2013/01/17/working-with-smarter-peopl/

  • Often, for several reasons:
    1. mergers
    2. in decentralized companies, different divisions / fiefs can make their own decisions.
    3. different projects may have different needs for which different BPMs vendors are a great fit. It is surprising how often this happens despite some feeling BPMS is "commoditized".
    4. relationship ebb and flow (one vendor is in favor for a while, then another, then back the first)
    5. Earlier selections often don't stay current - the vendor falls behind on innovation, or upgrades, or gets acquired and shut down. Or misses the next wave of innovation. So the company is forced to look elsewhere.
    6. Some "BPM" vendors aren't really BPM vendors. So eventually the company ends up buying another software package when they realize this.
    7. licensing fit. For one process, per-user pricing is a bargain. for another process, per-user pricing is prohibitively expensive. ditto for cpu-based pricing. And for ELAs.

    Having said all this, BPM is hardly the only space this happens in. I've seen multiple ERP systems, multiple CRM, multiple word processors, you name it. Having more than one of some category of software isn't all bad news. Harder to be held hostage to one vendor at negotiation time.

  • Scott F. really got it right. The one thing I'd add though is that BPM solutions proliferate because they often work much better in a bottom-up scenario than they do when imposed from the top down. BPM is all about rapid deployment of highly customized solutions, whereas centrally directed efforts tend to produce generic solutions, and none too quickly at that. So business units are motivated to adopt products on their own, regardless of what's going on up in corporate or in other units. And that's not necessarily a bad thing: each group has its own objectives, and needs the freedom to reach them using whatever tools they can leverage.

  • Almost always. There are BPM capabilities built into many common development platforms and enterprise solutions. There are many different styles of BPM, which are tuned to particular domains. For example, Finance might use the BPM that is in the ERP system, while sales is using the BPM in the CRM system.

    Also, BPM means not only the orchestrating engine, but also the modeling and design tools, as well as analytic tools, and again those can come from different vendors.

    That is why interoperability is so important.

  • Just to add to the list we've got going... I think the space is evolving faster than the procurement cycles at many clients. In my experience, many clients don’t want to go shopping for a new BPM solution every year. As a result, what you called BPM the last time you went shopping may not look anything like what is called BPM today. Just take a look at the 2008 Gartner Magic Quadrant for BPM.

    Add to that the amount of vendor consolidation that has taken place (Scott's point #1), and the choices have changed pretty substantially over the last few years. Even more so than ERP, CRM, etc.

    I think an interesting question is this – would we measure the success of a BPM project in the same way today as we would have 5 years ago? 2 years ago?

Add a Reply

Recently Commented On

Monthly Archives