Why BPM Projects Fail and how to avoid it

BPM is the need of many big and growing organizations to run the complex and long running operational procedures in an automatic way or with little manual intervention.

Although it is an agreed fact and many Oragnizationtions do not deny the need of BPM in their IT Architecture but they are still continuing their Operations without BPM, and there are many reasons why they are still doing in this way. However, the most common reason among them is that they are scared to fail or they have already failed in the past.

Why should your BPM Project fail?

One can literally write a Bible on this topic as this topic is very wide and equally deep. After communicating with multiple clients on different BPM Products this blog is a small effort to put those experiences in one page. At Least putting those reasons in one place should give one idea about the areas where to put attention.

As we know software development is a continuous optimization process, we don't make perfect software in one go and hence iterations are necessary. Same is applicable to BPM Projects.


Companies are really enthusiastic when they decide to go with the BPM Project. Their Business Team comes with the set of abstract requirements on what Project should deliver, Functional Analysts try to enrich the abstract requirements. Architects and Technical Team give their touch to those requirements and Draft out concrete requirements on the paper. The Development Team starts with great motivation to deliver the Best software. And after some review process, Project goes through various Test Phases before it actually can be used in Production to do some meaningful stuff and help the business Team to run operations effectively. Now from here the real challenge begins, if BPM Project can do well in this phase then they will serve in Production for many years.

BPM projects are prone to fail due to multiple reasons in Project lifecycle.

1. Infrastructure and ecosystem can not handle the Load.

    One of the top ignored areas is how much our Landscape should grow in order to cater our Business requirement. This estimate should have some sound basis. It is always safer to keep some buffer for rainy days.

2. BPM failed in Development or a Spaghetti recipe is on the way.

    You can't teach a fish to climb a tree but monkeys can do well and they can climb even higher with a speed. Make sure that you have got the right people around you to do the job rather than having high expectations from the existing Team.

3. Rolling out new versions of software is becoming challenging.

    It is really important to pay close attention before you roll out the initial version of long running processes. As software development is a continuous optimization process, one has to take into consideration the ease of Maintaining software in future, rolling out hot fixes and new requirements should not create new challenges. Rolling out new versions of BPM software is the same way as carrying out Car repair without shutting down its engine.  A topic called "BPM process migration"  needs to be thoughtfully carried out. 

4. BPM Product is not solving the problems which it was intended to.

    After a couple of Software Iterations management might come with the result that implementation is not solving our business problems rather to solve original Business Problems we are creating more problems. This might sound funny but poorly designed systems tend to create more problems rather than solving Business Problems. It is important to not lose focus for Business Problem in the initial design phase of a Software, it might be possible that Problem can be solved without BPM Product.

5. Operational Challenges 

   Operations Team is finding it extremely challenging to deal with day to day BPM Product issues along with Functional errors. Here an appropriate training  to Operations team on how to handle systems efficiently should help

At the end success of a BPM Project depends on Teams doing diffrent type of job. Their co-ordination, communcation and sharing feedback among each other is very necessary for a success of BPM Project.

Milestone workflow pattern using AMX BPM

WHAT?

 The Milestone workflow pattern is a BPM Process behaviour in which an activity is only enebled when the process instance is reached in specific state (milestone), in case process instance progresses beyond this state, then the task is no more enabled.

 An interesting graphical animation, simulating the behaviour of such use case can be found here.

WHY?

 There are lot of real life industry use cases which needs to have this pattern implemented in TIBCO AMX BPM, which is preferred BPM Product by many clients today. We can consider an example BPM Process use case in Aviation Industry which has to do with Flight Management. 

 In this use case there is requirement that check-in's are allowed only during specific time, i.e. once a process instance reached certain milestone, check-in's should be allowed and prior to 45 minutes of closing of gates

HOW?

 AMX BPM Provides lot of implementation alternatives to implement this use case using TIBCO Business Studio. However to make this use case and its implementation understandable, I will try keep the suggested solution as simple as possible.

 In the simplest approach as shown below in the Diagram:

1. A signal can be thrown to start check-ins.
2. As soon this signal is caught before allowing check-ins a Time comparison should be done if check-ins should be allowed are not. Based on the results process instances continues execution. 

Note: In case if you are intrested in actual sample implementation or you have a problem implementing or even you feel there is better approach for the beginners then it would be helpful if you can drop a message. 

We strongly believe that collaboration makes internet better place.