The Real Problem of BPM

Or: How to obtain a process definition ?

Before establishing a business process in a complex organization can be successful, we will have to overcome many obstacles. Especially if our intention is to initiate or adopt a BPM solution in a company where there is no BPM culture.

The challenges we face are many: what methodology; which BPMS will give us IT support; what  technical solutions do we have to use, reuse, or even develop ourselves to be able to overcome the usual conservative trend in the organizations; which  measurement or KPI to use to establish our control point; and how to manage errors and exceptions that may arise throughout our process?

But sometimes these challenges take a back seat to the problem of defining a process. Any technical decision we make is irrelevant if in fact we do not have a process: we can not establish our KPIs, nor have any items to monitor, if we are unable to define our business process and put this to paper, pdf, excel or any other medium.

This is where sometimes lies the biggest problem obtaining these processes. The situation is aggravated especially if the organization is not used to these terms. We sometimes encounter surreal situations in which we hear phrases like “No, we have no process for billing “… Interestingly, the company is still afloat without issuing bills… At this very moment, it is where the work of a good analyst begins, whose mission is not to invent or define all processes that increase productivity for themselves and to save millions in costs, but simply (in a first phase at least ) must model the process that is running the organization at that time. Not to change anything, but just to “investigate” and “discover” these processes. And on multiple occasions, and here the real problems begin, try to “extract” these processes out of business users, i.e. those that have the true process knowledge.

Sometimes it is sheer ignorance about terminology. Of course, they have a billing process, just not what they call the process, but it is clear that from a customer request until the client receives the invoice, a number of steps, actions and tasks must be done and these succession of steps is that we call process.

This ignorance is the easier hurdle to overcome, simply just a quick instruction to understand what is called the process and task … but once it is understood, here appear the biggest problem of all … fear!

Fear, because someone wants to know what we do and that is dangerous, because if someone knows how we do our work may mean that we are no longer essential, and there may appear words like replacement or dismissal. So the analyst must overcome this fear that turned him into the enemy of the user. You are sometimes no longer “process analysts psychiatrists” but simply trying to convince the users that the purpose of your work is not firing anyone (in fact, sometimes even the opposite can be achieved with BPM).

If successful in one way or another, and someone describes what is done from the beginning of the billing request until the client has paid, that is quite an achievement already. But then another problem arises, because besides asking who is responsible for performing each task (role), since especially those roles that seem to have some responsibility (review, approval, etc. )…. suddenly are ill-defined.

And the question is why? The answer is simple, the BPM analyst will be responsible to put a name”officially” to each work of the employees, so implicitly or explicitly this means one has to assume certain responsibilities. This undeniably frightens the users really, because you could ask them about responsibilities for the implementation deadlines, for the work quality, or any other reason.

To this are added the discussions that will start when the analyst begins with questions about exceptions that may occur during the execution of processes, error paths produced with the failure of an assignment, compensation mechanisms, etc …

This phase can consume more than a third of the time designated to the complete design process, and assuming that this in turn is a third of the entire BPM project, one can suddenly imagine the amount of time and the importance of this phase. A phase, however, that especially the little versed  people in BPM tend to look down on and therefore assign a smaller time frame than they should…

By Alberto del Rio @ Decide Soluciones from: http://www.bpmleader.com/2012/02/15/the-real-problem-of-the-bpm/