BPM pitfalls

In the last few years I've been working extensively with BPM (technology, analysis, industry development). I don't want to go right now into the discussion of whether BPM is a method, a technology, etc... more on that later. I'd just like to share some real life experiences on actual BPM systems implementation.

I started by implementing BPM systems in a low level view, working a lot with APIs, integration with applications, low level requirements. On top of that, I went through the mindshift people had to endure when analyzing these types of systems, and finally watching the real benefit they take from it.

My conclusions? There are a lot of small details, I'll go through them in the following posts, but for now a general overview of three major topics

1. BPM blends with an application

What is the point in implementing a BPM system if it is not supporting any line-of-business application? Just to make the process standard? You can do that without a system. Gather your collaborators, discover your processes, draw them on a paper (or in Visio or some open source tool if you're really into the technology thing)... because that is the first thing to give you the benefits of using processes. Having them drawn on a piece of paper and sticking it on the wall, so everyone is aware of what they should do, is enough to get you a 12% increase in productivity. Just drawing it (actually this is because by now you "know" the process; it is clear to everyone)!
So the real benefit of a "BPM system" is when it becomes an integral part of the system that already supports your business. When it allows you to measure, extend, prioritize the tasks that are already done in those systems by your collaborators. Having the two systems running in parallel might bring a benefit... but having it integrated really changes the way they work. If you're thinking on starting a BPM implementation think about how your system will integrate with your application. What will happen if you change your application? Will the process be inconsistent? What is the lifecycle of the application? Does the lifecycle of the process matches the application's? Will they go live at the same time?

2. Long lived processes are your biggest concern
How much time will your processes last? One support case might take a couple of hours, one installation of landline/DSL/internet/cable tv might last a couple of days, one insurance claim may last months. Suppose you break a leg on a car accident and call your insurer; what if after 3 years you still have problems in your leg? Won't the process to handle your claim still be alive? What about new laws that just came in; what about new fraud detection rules, what about new insurance companies conventions that determine that every claim of a particular kind should be handled in a specific way. Those changes need to be brought into your process. «That's ok» you might say, «the good thing in processes is that they are visually modeled, every tool allows you to change that model easily».
The thing is, on short-lived processes you can just create a new version of the model and deploy it. But on those processes that last for months or years you just cannot do that, you need to upgrade the current model, not a new version. And when you do that what will you do with all those instances that were already running in production (since the day you first called your insurance company)? This is a major challenge that is not usually addressed when we're starting our BPM effort. One that will become a major burden when you need to consider it.

3. Reporting/monitoring is the ultimate outcome
What's the purpose of using BPM? It's not about knowing the process (for that you might just use a pencil remember?). It's about monitoring it so you can optimize it, therefore reducing costs.
So you should make sure the process you  are designing is actually measurable. That you can look at the statistics your tool provides you and make the correct judgments. The problem is that this will many times lead you into making a process that is targeted for the reports your tool supports; lead you into making a process that is not business or technically the best design. But if you do it right, you might end up with imperceivable reports just because you added too many levels of subprocesses, or implemented a multi-role process as multiple separate processes to facilitate the integrations with the application or external systems.
My point it, you'll loose something on most occasions... my advise is that you should design the correct process and choose tools that allow you to build your own custom reports over the processes. That way you'll be focused on building the right process for the right occasion. And you'll still be able to analyze it properly

What about you? what were your major challenges in BPM systems?