BPM: 10 Reasons for Common BPM Failures.

Business process management software is like any other software- it can be prone to a degree of failure if users are not sure of certain features or if perceived benefits are not made clear. In the case of BPM software suites this is usually because they're seen as overly complicated, drawn-out and slow-running applications that will not meet business needs.

Which, to a certain degree, is true- unless you have a flexible process driven or a dynamic human driven organisation it won't have too much of an effect. But if you do (and it's likely you will) have one of these types of organisations BPM software could be very useful.
Therefore, for your reference, below we have listed ten of the most commonly encountered reasons that BPM software suites fail to meet expectations.

BPM is too much marketing- not enough science!
You wouldn't think that any product could be marketed too much...but in the case of BPM packages this is almost always the case. As BPM packages can have a number of varied connotations (covered below) there is a great amount of confusion over what does what, which will be useful and whether any of them will be useful for you. Often organisations will choose the largest vendor as the safest bet will always be taken, even in the case of more perceived value, which is not always the best choice as many marketeers don't fully represent such diverse software.

Unreasonable goals and unrealistic expectations.
Anyone who has ever designed anything knows how annoying it can be when someone simply takes the idea of producing something as a trivial task. Or asking for something when the person quite evidently has no idea what it is. This is sometimes reflected in BPM packages as it is a common belief that "one size fits all" applies- that each process is the same- and that they will all be treated equally.
Quite the reverse is actually true, every process and specification is a unique aspect of a particular organisation and to make best use of this you must take that into account. Therefore, partially due to hype and also partially due to inexperience- this software is not always the best understood or used.

Lack of undestanding of the process landscape.
The process landscape of every organisation is inherently different and while this is a very valid point. Often vendors can get away with trial-running one process to create the illusion that BPM packages can do it all. Which, in some cases, they can- however, in the case of a highly complicated or dynamically driven process landscape BPM packages will be of more use.
Understanding your needs is an essential part of every purchase, but more so in this case as you could easily disregard a brilliant software package under some really bad advice you were given so someone meets a sales target. The easiest way to solve this problem is undertake a process analysis and then research the software you need/want.

BPM is disruptive as it makes agreements difficult.
The common consensus of opinion is that BPM software suites are bulky in comparison to their CRM and ERP equivelants. While this is true to some degree, as there is a lot of process management involved, it can also be avoided with accurate project planning to begin with.
All too common is the approach of starting with the most complex process first- but remember, all large processes are just culminations of smaller processes which are made from basic processes. To fully understand how transparent your processes can be you have to return to the first step, the very first thing you would do in a given situation and work upwards from there.
Were you to there would be a great deal of agreements as every process would be more transparent, and thereby, to a large degree, easier to understand.

BPM is a boardroom issue.
Introducing change is often like trying to yacht up a waterfall- if it's not downright impossible it's near as can be.
In this case, many organisations (having not seen the perceived benefits) simply disregard BPM packages for the fact they're not proven.
This is an issue that can only be sorted with a great deal of time, effort and use on the BPM side of the argument to show that these software packages can be- and already are- viable options for an organisation to undertake when it is large enough to utilise them.

The tools and processes are still too technical!
This is a given with the nature of processes and can be the dealbreaker more often than not as you will have a group of people to run it, a group to design it and then a whole heap of communication problems in-between. Worse still is that you will be faced with the fact that you need someone to understand the processes in the first place.
Although, while a negative outlook, some positives can come from this in that (much like the process analysis above) if you prepare and work hard on making sure this doesn't happen- it's going to be an incredibly successful and well invested idea.

There's a noticeable gap between process design and execution.
Decorating your lounge and seeing the finished room are two different things. You have an idea of what you want it to look like, what colours you want and what flooring you're going to use...but once it's done, well, you might just reconsider some of it.
BPM packages are no different in that you have an idea of how you want the processes and whatnot to be designed, implemented and used but every second you wait between design and execution is lowering effectiveness. This is mostly because if you design a process and then don't like it- you have to redo it. Re-implement it. And the whole process starts over and over and over again. It becomes tiresome and puts a wedge between you and this nice new software you have just paid for.
The most effective BPM packages are those that operate in real time and allow you to see the changes straight away, or, at the very least, within minutes.

General purpose software suites have missing links.
Most of the time you will find that software packages fail when they are taken out of the hands of the machine, and into the hands of people. This is because almost-every software package has some degree of human interaction. Even if it's just clicking a dialog box to get the software to load a new component or something- there's that human touch.
BPM packages (and general use ones in particular) will always require someone to do something even if it's just to accept or to decline something. This is because you can't automate and code every instance, even the most airtight algorithims and calculations are only guaranteed 99.9% of the time as there is always the possibility for error. For something to be overlooked. While you could just make the entire process entirely automated that just leaves the back door wide open for mistakes, errors and overall more costs to put things right.

Top down approaches are prone to failure.
As processes will naturally exist in many organisations already you have a range of options of where to start using your BPM package. Although, to start by designing or altering processes (and process landscapes) would ultimately doom you to failure. As while these packages are all-inclusive they will always make use of business services (such as SOA-compliant services).
Be wary of these services and try to take them into account as best you can as otherwise you will be wasting your time, resources and effort trying to use a top down approach which won't work. Or, even it does, not as well as it could in other ways.

BPM in combination with SOA results in excessive communication.
When you have SOA-compliant services to create all manner of end-user documents you can find yourself caught between a rock and a hard place. On the one hand, you have an incredible amount of utility and functionality as you've exponentially increased your capabilties. On the other, nothing will continue to work as it should as minor changes ripple outwards and make odd things happen later down the line.
There is but two ways to solve this problem; you can either invest your time in only using as many SOA-compliant services as you literally need, or you can purchase a rule-based BPM package (such as Aquima) which would solve the problem nicely.

And there we have it.
Hopefully this post has proved insightful and you've learned something about BPM packages that you didn't know/consider before- in any case, thank you for reading!

All information presented here is © copyright Carkean Solutions Ltd., 2010 - Not to be used without our permission - The views expressed here are the views of an individual not the corporation

Aquima: On Level Ground.

The last time we made a comparison like this we were talking about Aquima and ARIS which were quite different in approach. One is coded, the other is rule-based. One has extensive functionality, one has specialised tools. Today we're talking about two systems that couldn't be more similar- Aquima and Pegasystems. Incredibly similar in both functionality and expectations this should provide a unique insight into where Aquima performs best (even in similar markets).

Pegasystems
Pegasystems is a rule-driven business process management (BPM) suite that helps users to build, plan and manage processes throughout their entire lifecycle. SmartBPM blends process and practice rules to rapidly implement (and alter) solutions in response to changing needs or demands. Behind this is the PegaRules system which provides the rule-based functionality that the whole Pegasystems package thrives on, which allows it to optimise everyday business processes for use with the suite.

Similar yet different.
On the surface Pegasystems and Aquima seem to do exactly the same thing as both incorporate a front-end application with a constant running engine, not to mention they both use rule-based functionality and they're both easy to use with no coding whatsoever- but this is where the similarities end.
While, yes, the core of the software is similar, Aquima is better used where you require flexibility and a dynamic approach where human interaction is key. On the other hand Pegasystems is better used when you require a solution for process heavy environments, where a singular variable will change but the rest of the process will stay (for the most part) the same.

Customer base and progress.
Much like with the previous comparison Pegasystems once again out performs Aquima on the customer base and integration fronts. Both are successful, dynamic and fast-growing organisations but Pegasystems has a better front for marketing and promotion. Plus they have more initial users- but at the same time Aquima is arguably a more cost-effective solution.
Both points are more a reflection of how Aquima is still in its infancy and hasn't yet been adopted by the wider range of users, but as a new and exciting product this is only a matter of time.

Functionality, features and versatility.
In terms of their overall functionality and how each is used there are two major differences:

• Aquima has a unique look and feel with a Microsoft Office-esque layout which means even the most basic users have an idea of where things are. This helps and brings down the learning curve by a large degree which is often a problem, more with new software, in that it can be hard to learn to use and therefore discouraging.
• Pegasystems is still considered a technical piece of software and therefore (sometimes) to have a steep learning curve, however, that said, it does have a different approach to other BPM software suites. It is entirely possible, and likely, seasoned users will be able to approach it and utilise it for maximum effect- while new users have a hill to climb as it were.

In both cases they are suited to different approaches and can be used in relatively the same manner.
While, as mentioned above, the only real defining factor between the two is whether you have a process heavy or a dynamic organisation. In which case you will choose either Pegasystems or Aquima, respectively. As only then will you be utilising the full potential of either software package.

Pegasystems does have a very useful feature of providing pre-built standardised templates which provide information for how you can develop your own applications. However, in spite of this, the use of SmartBPM requires additional software to be installed before you can model processes.

In conclusion much like the last comparison we can see that each BPM software suite contributes a different set of advantages to users.

Thank you for reading!
Feel free to leave any comments and feedback you may have.

All information presented here is © copyright Carkean Solutions Ltd., 2010 - Not to be used without our permission - The views expressed here are the views of an individual not the corporation