If your looking for BPM software then this blog provides you with all of the need to know questions you should be asking.

As a developer of BPM technology, I’m pretty familiar with the various questions customers ask and also the important ones which they often forget or haven’t even considered which are crucial to ensure you select the right solution.

So, for any of you that are in the market for BPM software then I’ll try and help you make the right decision by answering this question that I came across on Quora…

WHAT SHOULD BE THE ESSENTIAL QUESTIONS TO CONSIDER WHEN SELECTING BUSINESS PROCESS MANAGEMENT (BPM) SOFTWARE?

Many of these questions here are for you and your organisation to answer, some of them are for your vendor/integrator to answer. Sweeping generalisations, I apologise for in advance as some of the points merit a deeper discussion in a post of their own. Also, this list is not exhaustive so feel free to add your own to the comments below. So here it goes…

1. How much money do you have to spend and do you want to spend it on cloud or on-premise software?

ON-PREMISE BPM SOFTWARE

Traditional BPM software, and by that I mean on-premise or pre-cloud, wanted you to buy software licences up front, then pay for a project to deliver the solution, and then hit you with 20%+ annual maintenance on licence fees (in advance).

If you’re a large bank, telco or utility, you probably don’t have huge financial constraints and you probably buy enterprise licences for everything, and run it on-premise. The rest of the world operates slightly differently.

In the traditional world, you will be lucky if your finance department hasn’t fallen out with you by the time your system has gone live, having spent hundreds of thousands or millions (pick your currency) before you realise any benefit.

CLOUD BPM SOFTWARE

Cloud BPM lets you even out your costs, although there will likely still be an upfront configuration fee, higher if you can’t get in on the configuration act. You never own the software licence, so it doesn’t appear as an asset in your accounts, but at least, you haven’t had to fund licence fees and you can get a seat at the table.

If it’s in the cloud your project should happen more quickly too, you don’t have to worry about buying or installing servers ever again.

Cloud is attractive if you don’t want to manage hardware infrastructure, but it may limit your options. Many vendors are moving their traditional platforms to the cloud, some are cloud-native already. You may want to poke a stick at that though. Cloud and on-premise offerings may differ. If the platform is cloud native (built to use a compute and storage platform’s resources through APIs) then it will be quicker/easier/cheaper to scale up or down. If the vendor has simply deployed a full, single tenant stack onto a VM in a data centre, and wrapped a rental model around it, it will likely be more expensive and less flexible. A generalisation, I know.

Ask your vendor for a total cost of ownership model over 5 years – maybe difficult if it’s a cloud vendor, so do your own analysis and make sure you know what you’ re getting into.

2. What is the BPM platform’s modelling, customisation and execution environment?

BPM applications run an abstract model of a process, which you configure on the underlying platform’s configuration tools, generally speaking. The platform may come with solution-specific templates that you can alter, and it probably ought to come with ‘non-process’ features such as sending an email or hanging a user’s permissions, or setting a service level. But fundamentally, BPM applications run models defined within an underlying platform.

This is important because running a model means you’re operating further up the software stack closer to the end-user. You’ll have less code to maintain, applications are quicker to roll out and cheaper to change. When you change a process model and release it, the executing process changes behaviour. In theory, the BPM platform should de-risk this process of change. Worth a thorough investigation when you get to looking at specific tools.

There are standard ways of modelling a process (for example BPMN, which is an acquired skill) and there are proprietary ways. In my view standards are ok, but they limit innovation, so there is a constant drive from vendors to produce new features which then break the standards. For example, how do you build and layout a custom form? If you spend too much time worrying about tools at this level, you’ll be in danger of never making a decision. Just note that no software lives forever and look for something which reflects your internal skills and process challenge.

Running a model also means it should be easier for the platform to log and measure behaviour in a consistent way across all of your processes. Again, this is important if you want to work out how well your system/people/business logic are performing live. Not saying you can’t build metric gathering in other ways, inside apps and such like, but it’s one of the benefits of a dedicated platform.

Some BPM platforms avoid technical modelling because the vendor has decided that going through technical process modelling is one of the reasons why BPM projects are so expensive and time-consuming. The same vendor will have taken the view that as long as you have a domain expert or someone who understands the ‘sausage machine’ of your business, then just give them tools they can use to create a solution. This has been called by some a ‘low-code’ approach to BPM, but it really should be called ‘lower-code’. Coding in some form or another is rather hard to avoid when doing BPM solutions… see below.

As an aside, Microsoft Dynamics and Salesforce are not BPM platforms, although I have seen them sold as such. They are platforms with application code, which you can extend with more application code. There is no concept of a model in there from what I can tell. No doubt you can extend both with add-ons which do some form of BPM. So when you do have to get developer tools out to do something really specific, like calculate risk based on custom business logic, or integrate to a tricky internal system with a ropey API, the tools and the languages offered become important. Proprietary languages mean costly internal training (and low initial productivity) and high day rates. JavaScript skills are pretty easy to get your hands on, so are .NET/Java – look for these or similar and maybe check market day rates as part of your investigation into a specific platform.

3. Have you already optimised your business processes operationally, such as using a lean process methodology?

You could look at the OMG’s Process Maturity Model and self-assess. I know it’s a bit old, but in my view, it’s entirely valid and from it you can draw meaningful conclusions…

If you are at the “Initial” state (not all of your business processes will be at the same level of maturity) then BPM technology will have a quick benefit, but the learning curve will be steep. The more mature your processes are, the more capable you will be using the tech, by definition, so the investment is more justifiable.

So if you are at the “Initial” stage, it may be sensible to do something low cost, with a process discovery aim, before you start spending big bucks. You might find you never need to go large. I’ve seen home grown software apps which manage a business process effectively, without actually being a BPM platform. Many organisations are happy with that because they don’t have an ongoing need to do more. I’ve also seen badly implemented BPM solutions on expensive platforms, mainly due to the quality of upfront analysis.

I suppose what I am saying is, don’t just throw a BPM platform at a problem, without fully knowing how you’d like to solve it, or understanding the targeted benefits. If you are at the “Initial” stage, invest in something low cost and plan to throw it away. If you don’t have the budget or time to throw away, then think hard about the business case and how you’ll adopt the platform.

4. How big is the scope of your process challenge?

In other words, are you trying to automate a single function such as claims processing or complaints management, or are you trying to transform a significant division such as a supply chain, or a customer service function for a multi-play telecoms operator?

If it’s lower on the scope scale, then there is a plethora of tools you could choose from. The argument for a throwaway DIY software app build can also become attractive at the low end of the scope scale, but I’d generally advise against this, there are many low-cost BPM tools you can take advantage of and having less code in the world needing maintained is a good thing, except for contract developers.

If your scope is large and complex, your platform will need lots of pre-built connectors, domain specific reports, data migration tools and ready-made process models/templates to start from. SAP and Oracle operate at this scale, selling solutions for specific industries, although I’d have to take an expert’s view on whether you really are in BPM land here, or working with convoluted applications built on top of legacy code, sitting underneath a nice front-end. I have my suspicions, but prepare to get a fresh cheque book from your bank manager if you are going anywhere these guys.

Case Management is another area you might look at specifically – it’s a subset of BPM, it tends to be easier to configure and quicker to solution. A “case” being a user-defined collection of structured and unstructured data such as an application for a new product. The “management” part is the process which you take that case through. You might also find a BPM/Case Management tool which is specific to your industry, and not sold by any of the big vendors, so do your research.

5. What tools are there in your BPM platform which help mine your process data?

A fairly straightforward BPM cycle looks like this:;

• a) Define your requirements
• b) Implement your solution
• c) Roll out to end-users/customers/business partners
• d) Monitor and measure, then go back to stage a) and make improvements.

So stage d) is about mining information, interpreting it and making improvements. I’d be looking for demonstrations on this from the vendor. Although, don’t think you need to stick to a single vendor’s tools. Here’s a dedicated mining tool which we use when exporting timeline data from CaseBlocks, it helps give a visualisation of a process and lets you see individual cases travelling along their lifecycle Process Mining and Process Analysis.

If your platform of choice doesn’t have tools like this, then at least, make sure you can export the data and analyse it in other tools. This is just one example, so do your research.

6. Has the BPM platform been used to solve a similar challenge to yours before?

If so, can you speak to someone on the implementation team from the vendor or integrator, and someone on the client side? If the technology hasn’t been used in that way, that’s not necessarily a bad thing, BPM platforms are often general purpose toolkits after all, but you’d need to get a clear view of how it would be implemented to solve your problem.

Speaking to someone who has solved a similar problem might also help you understand tota cost of ownership over a reasonable period, such as 5 years and clearly, learning from the experience of others is a good strategy for reducing risk/costs.

7. How confident are you that you know your own processes?

Can you describe them to a process developer, can you configure them to create a finished application, and can you estimate the effort to build and deploy?

I remember meeting the CIO of an Australian energy utility company who didn’t trust his own staff to work out what the core processes of his customer service function needed to be, and they were in the middle of rolling out a BPM platform. Big organisations waste money on BPM initiatives all the time. Simply google the UK government’s wasted spend on the Universal Credit system or Scotland’s “NHS 24” GBP £50m overrun – these are large complex business process challenges with leading companies working on them, yet they still fail.

If you are confident that your team understands how to do all this, or equally confident in the integrator and product combination you have chosen, then fine. Regardless, manage risk from day 1 and break your project down into small chunks with regular deliverables. I’m a fan of user stories to articulate requirements, not a huge fan of ‘going agile’ when resources aren’t unlimited.

If your team lacks the experience of doing this before, then a realistic choice is a platform which allows you to configure processes as you go (i.e. while in production) and using a non-technical metaphor. If that platform also brings domain knowledge in the form of pre-configured process models you’ll be in good shape. On such a platform, you need to be sure that when you change a process model definition, previously run process instances or ones that are currently in flight, are handled gracefully. That bit is tricky so make sure you poke a stick at it.

8. Do you have plans to simulate your processes?

If you do, good luck. Your requirements will have changed by the time you’ve done your simulation. I’m not saying simulation is bad, in some cases, it’s mandatory, like planning a new road network. But I do wonder about its applicability to the real world of BPM. Another generalisation, happy to be educated.

Far better that you have great tools in your BPM platform to look at service levels on time/resource sensitive activity within specific processes or process stages, or tools which can report on staff utilisation so that you can monitor when staffing is under pressure and plan ahead.

9. Are your processes volatile?

“Volatile” meaning subject to change regularly, where regularly is daily. The change may not happen in your system daily, but business logic may be changing in the real world at a rapid rate. Regulation, competitors, new business opportunities, internal innovation are all reasons for change.

If your processes are volatile, but you still need to run processes ina live system, then the platform you choose needs to have the ability to quickly change functional behaviour. This tests the platforms modelling, test & release capability. Drill into this during any demo and using a variety of scenarios.

If you find that your processes need to be dynamic at the point of demand, i.e. only known when they are executed, then you might be suited to a case management tool. You might also look at the learning ability of the platform, has it got some analytic capability to make dynamic decisions in live? Maybe you don’t need that, but it’s the holy grail of BPM. You’ll have seen the word “adaptive” in your research, so drill into what exactly your vendor means by that.

In my view many processes start off volatile, then approach a steady state, so you won’t need to tinker forever. If a big change comes along then just deal with it at the time by a combination of creating new processes, phasing out old ones and adding new features. If your BPM platform comes with a crystal ball, it would certainly help.

10. Do you expect to have multiple software end-points in your solution?

Maybe you have a back-office user, plus a mobile user, plus a field user, a consumer website, plus an existing legacy system, all needing to be made ‘process-aware’. If you do, then your platform of choice ought to be on a web stack and API based, and more than likely offer a RESTful API – yes, some standards are good standards.
Having a nice API means you can build custom apps on the periphery, but all sharing the same sense of process as the rest of the platform. Perhaps your BPM platform will give you a mobile development toolkit along with everything else.

You may run into instability issues if your end solution needs to be distributed, and the BPM platform has some funky home grown architecture and API model. Drill into this with your vendor.

11. How do you migrate legacy process data into the new platform, and how you get it out if you decide to move on to a new solution?

In other words, what barriers exist on entry and exit?

Process data is combined of process models and process instances. For business continuity it would be great to be able to put all your legacy data into your shiny new platform, so you should ask your vendor for an explanation. And when you want to export process data how does that work? This is especially important when you go for cloud BPM given you may want the flexibility to change vendors quickly.

Process modelling standards should make all that possible, in theory, but I don’t have the experience of seeing this working. There may be more pragmatic approaches where you have an intermediary stage of translating process instances into a simple form before moving between systems, potentially losing your process models on the way. Again, explore this point with your vendor.

As I mentioned before, this list is not exhaustive and I’m sure there are many more questions to ask so if you can think of any more then be sure to leave them in a comment below.

Happy BPM Shopping!