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

When should a company upgrade vs. completely overhaul its BPM suite?

Vote 0 Votes
From this Samantha McCollough Q&A with Steve Weissman, when does a company know it's time to upgrade vs. completely overhaul its BPM suite?

5 Replies

| Add a Reply
  • With a large percentage of customers still in the first few years of their BPM roll-outs, it may be a little early for them to consider this question. Still, we've gone into enough sites where we're replacing an incumbent solution that this issue is clearly being faced in some quarters.

    Still, most times it won't pay to fully replace a solution that is up and working, even if you don't want to stick with that platform going forward. So you bring in the new product for your de novo development, and leave the old one in place. When the time is right, you can consider migrating your existing processes to the new platform; more often, though, you end up retiring that software only when the process it supports has been put to rest as well.

  • We've actually been helping customer upgrade their BPM suites for years, but then our customer base is, in general, pretty mature in BPM. Sometimes customers wait years before upgrading, which avoids work and cost in the short term, but creates a bigger unknown/project in the long term. A specialist BPM provider can be a big help with things like this. (For example, we've built a bunch of tooling and process to support what we're doing).


  • Great questions like these have an awful lot of "it depends". I'll just comment on one to add to the thread: product architecture.

    Every so many years, vendors need to bite the bullet and perform their own architecture reinvention and rebuild--something quite disruptive and expensive to their software suite, but that buys them another 5 years of leadership or at least relevancy. When they ignore that need and kick that can downhill, their product suite falls behind in modern features, or gets weighed down with "bolted on" features or inelegant integrations with acquired products. Anyone who's spent years in IT has seen this with ERP, CRM, middleware, app servers--all types of products, and BPM is no exception.

    So, my point with this one consideration is the following: go for the upgrade if the incremental change keeps your business in its groove. If your vendor is overdue their own rebuild, and your business is consequently impeded from efficient ways of maintaining your own industry leadership or relevancy, it's time to overhaul.

  • I think Jason's last paragraph sums it up succinctly.

    However sometimes a business' process maturity will outstrip the suite it's implemented, it might not be anything to do with vendor product, or simply that the product was bought to complete a gap with no foresight to future requirements and the vendor roadmap just doesn't fulfill the future need. Note, this is not the fault of the vendor at all, it's simply not a product path they wish to take (and hence avoid the bolt-on mess like most)

    Personally, what we need to see though is examples of this exposed rather than discussed behind closed doors, open case studies which highlight limitations from experience, pains of migrating from one suite to another. Perhaps lessons rather than theory would serve both vendor and customer.

  • Those who adopted early BPM Solutions that remain static and they have the right mind set then hopefully they will be ready and embrace the next generation enterprise level solutions. These technologies should remove coding yet deliver exactly what the business users need AND allow ready change as they require. This becomes future proof investment unlike the BPM support technology of the past which will need overhauled to remain competitive and efficient.

Add a Reply

Recently Commented On

Monthly Archives