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: Simplicity in Design.

With so many business process management (BPM) software suites on the market how can you be sure which is right for your organisation? In truth, they're probably all useful, but some do offer certain solutions and key points that others don't.

Brief introductions.
So today we shall be looking at a comparison between Aquima and ARIS.
ARIS (Architecture of Integrated Information Systems) is a complex approach to enterprise modelling. It offers methods to analyse processes and take a holistic view of process design, management and application processing. It is similar in functionality and could be considered complementary to Aquima, each provides you with a similar end result and model/application but the methods to design them are vastly different.

Process development and management.
The major difference between ARIS and Aquima is the simplicity of designing processes.
ARIS uses a coded approach to designing the processes, while Aquima states that "if you can handle Excel, Powerpoint and Visio you can create an application." Both use a visual representation of the process for easy understanding and design, however.
With ARIS this means that you could get even more functionality from the software if you can code to the level required, allowing the highest level applications to be created to specification.
While for Aquima this means that there is an easy to use process design environment available to every level of the organisation, though possibly lacking the power of ARIS.

This in turn also defines how models/applications can be edited and developed.
With ARIS it is possible to develop the model/application and then edit it, however, it requires an incredible amount of foresight and all the initial coding skills.
With Aquima it is possible to prototype a model/application almost immediately. This provides two benefits: one is that you can engage short-term testing straight away and get real feedback immediately, the second is that it provides a more complete and hassle-free design process.

Designing, deriving and everything else.
From there we can also compare how the models/applications are initially derived and designed.
With ARIS you are required to have all of the information (or as much as possible) when starting the design as you need to work on a process-by-process method. This provides some benefits in the consolidation and accuracy of information available and used. However, it will have a longer set-up time and be more complex.
Aquima is almost the opposite in that you create the models/applications more by specification than by processes. Of course, as part of the design, the processes are a part of the development. But initially all you need is a specification- an idea- and you're ready to create. However, it doesn't require the levels of information management you would need with ARIS.

International customer base.
Equally, the customer base of both is important as a comparative note.
ARIS is quite well-known and has both a national and international customer base, while Aquima is still developing a mature international customer base.
This can be important for many reasons. In the case of introducing a new business process management software suite into the organisation, what are the current employees going to expect? Something like ARIS or something new and exciting?
Also, the intergration from organisation to organisation is going to be different with different systems.
Though, this is not to say that you shouldn't use Aquima as it is likely unknown to many- just that it is one of the many points on which they differ. Instead of one of the many more points in which they are similar.

Brief conclusions.
In conclusion, (as mentioned above) Aquima and ARIS are mostly complementary and share many relevant and useful features. While Aquima is a more "hands on", easy to use and easier to design software it could lack the specified functionality of ARIS. However, the same could be said of ARIS in that while it has a lot of power, functionality and high-level possibilites- it can be inherently hard to use for those with no coding experience.

Thank you for your time!

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