Are BPM solutions worth the investment in money, time and effort?

Question

This is more an architecture related question than a programming one, but I think it might be useful to developers given that I have been wondering this myself for some time.

I have no experience with Business Process Management tools use or implementation. (The closest thing I have used is BizTalk server, but I know that it is not really a full BPM product, but a document based integration platform with some process orchestration features).

Recently, several of our clients have been asking for BPM-based development projects, and most of the time I discover that some BPM vendor has been giving them some of those 'look how amazing is my product' demos, where they show 'how easily' you can modify your business process flow just by 'dragging and dropping' shapes around and those kind of things.

Obviously, vendors don't say anything about how you first need to have running your well designed processes on the BPM so you can actually make that kind of magic happen.

My clients suddenly see a new light thinking that BPM technology will finally fix the typical problems common to almost any IT department: applications that are hard to maintain, missing deadlines when implementing changes to support new business needs, etc.

None of them have finished implementing BPM, so I have no a real world reference to know what is such think like.

I honestly believe that many of those problems only should need solutions based on development process improvement, better analysis of future needs and better project management skills. Heck, even better programmers and designers.

So, my question is:

What should an organization have in place before trying to implement a BPM platform in order to succeed?

---

EDIT: Is really SOA what enables a BPM strategy to succeed?

Answer 1

I think your clients highly overestimate how much value theyll get from a BPM product. It doesnt do wonders to their development cycle or anything like that

No silver bullet!

On the other hand there is value to be gained from using BPM. My point of view (and my extreme bias) is towards SOA (as in processes, architechtures. Not vendorsoftware, webservices and buzzwording).

If you analyse and that way understand your business and what gives you value and your IT enables you to "easily" reuse exiting data and services and your BPM lowers the difference between your buisness and IT well you could gain value.

It's not easy to make all these changes though

(hmmm, I sound like a consultant now, don't i?)

just my 0,123cents!

Addition:

---

Most vendors associate their BPM products along with an ESB. Neither gives you SOA per se, but could help you if it is soa you are looking for.

In bea and ibm's reference architectures the BPM is a facilitator for "orchestrating" more fine-grained services into more complex processes.

As I see it, and it's quite supported by the name - Business process modeling - processes is what gives you the advantage/bottomline value. The BPM should help you "easily" cross from business to IT. On the other hand any healthy business knows its main processes and the BPM need is based on their process optimization evaluations right? :)

Apart from the processes you need to have an idea of what you want to gain from implementing the process in the BPM and some KPIs as to what gives you value helps you there.

On the pragmatic side I see a "middle-out" approach as the way to go if you are somewhere in between "i-know-nothing-but-i-heard-bpm-is-the-way" and "my-process-analysis-tells-me-i-can-gain-10%-higher-topline-if-i-perform-this-process-4%-more-accurate-and-10%-faster". Make sure you dont go all in on proof-of-concept and invest Mega$$ on expensive vendor stuff. Try out fx Jboss BPM(I havent tried it). Try to implement one or two of your processes and think about how to integrate it with your current workflows.

Often the big problem with implementing SOA (and along with that BPM) is the fact that to gain the real benefit you need to optimize the whole process and by that the way of think of the "man-on-the-ground" and that only happens if the initiative is pervasive in all the business. Bottom to top.

</ramble>

Answer 2

From my own experience with BPM, I bitterly say BPM solutions are still in their infancy stages. Vendors promise their customers with heaven if they implement SOA, and "projects that usually take months to implement will take only weeks!". Theoretically, this could be right, but the tools vendors offer are still lame and offer nothing but more work to do, and more expensive maintenance!

Do not believe all what the vendors tell you. They need to make a living, even if they have to bullshit their customers.

Answer 3

"What should an organization have in place before trying to implement a BPM platform in order to succeed?"

• Executive buy-in and support!
• Process-centric view of the business.
• Good business process analysis skills / experience.

Answer 4

Like everything, some parts are true, some parts are.. well.. not completely explained.

For instance if in one process, the interaction is between two different roles, where they just have to mark a checkbox for approval, it is easy ( in some tools ) to add by drag and drop a new activity where the HR director should approve if the cost > 1mdd ( just to say something )

The goal here is BPM suites to give the final user the opportunity to change this kind of process on the fly easily or at least to react to some urgent demands on the market or in the enterprise. This much is true ( in some BPM suites )

But, if the change requires an automatic activity to check SAP ( or your CRM, or an external webservice ) to verify if there is mmmhhh *put_some_resource_here* and then approve, that's a totally different history. THAT CANNOT BE DONE by the final user. The proper codification validation and etceterization must be performed by IT team.

The goal here is to make the business process that are on the paper actually get implemented and the flow be easily understood by the business owners. They can see the flow of their processs in a graphical tool and understand it with out much IT interaction.

They can also suggest modifications and in some scenarios like the above modify it them selves ( or have IT modify the flow within a day )

Also, most BPM tools offer Dashboards and out of the box performance reports of how the process is working close to real time.

This is the value offered by BPM suites.

I agree, No silver bullet, but this is a good approach to narrow the gap between running implementations ( known only by IT staff some times ) and requested requirements ( known only by business owners some times too :S )

What should an organization have in place before trying to implement a BPM platform in order to succeed?

They definitely should have support from the high executives first.

Then identify a small but significant, well defined business process.

Then learn along with the IT team what its BPM suite has to offer.

Then proceed with the next business process ( just a little bigger this time )

The worst way to go? Attempt to implement the core of the business as the first BPM project. That WILL fail always.

Answer 5

Having implemented several BPM processes (of varying successes) at my company here are a few lessons I've learnt the hard way.

1) Map the process before thinking of the technology - sounds obvious but regardless of the how the solution will be implemented this will need to be done. Get the people who know about technology/process and people who know about the business in a room (at the same time!) with a flip chart and pen and map it out. Identify the people who touch the process, the data you are trying to capture and the outputs for the process. Even for the simplest of workflows you will need to do these sessions again and again. Start with an overview and gradually flesh it out. Maybe even introduce some reengineering and try to cut/merge some of the steps the business currently take. Developers/techies can contribute a lot in these early stages as they see 'process' far easier than most. At the end of this analysis you will have a documented process that you can use as part of your RFT for vendors. Get them to build it as part of their pitch.

2) Owned by the business - BPM is not an IT tool. The board need to be behind and push BPM. It can be assumed that nobody embraces change so BPM is something to be pushed onto the users. Strong (verging on evangelical) project sponsorship from senior staff is an absolute minimum for the success of the project.

3) Get something out there quickly - People really don't know what they want until they start pushing buttons. If a process is growing into a monster and you begin to feel analysis paralysis, then pull it back and offer the absolute minimum you can get away with. Even if the process does nothing but show a simple checklist presented to people at the right time is a great start for a v1.0 BPM process. The business will soon tell you what they wish the process would do - even in a priority order too!

Answer 6

RE the BPM/SOA question. I don't believe BPM are necessarily dependent on SOA, although SOA may be a good enabler.

What they do have in common:

• Neither is a Silver Bullet if you are not prepared to address you business problems first
• Both are extremely dependent on Business and Executive buy in
• If you design and implement it badly it will be a money sink