Tuesday, 14 September 2010

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

No comments:

Post a Comment