In addition to being a business and process analyst I have a mainly technical profile, and sometimes I have to attend meetings where bitter disputes take place about the technical choices in terms of architecture, products, BPMS, document management, portals, which bind to problems of analysis of existing processes.

These meetings are usually attended by people with very diverse backgrounds and profiles, ranging from technical and business to quality managers, unit managers, process expert (when the company has them), and technical staff, IT managers and architects. Architects, who after all will be responsible for “creating” the specific solutions that will sustain the processes, prepare reports, etc… or in other words: the applications that the user will actually contact.

I have always wondered that each company is different. No two companies are alike and each is doing the same things but in a diametrically opposite form. There are ones, where business users have control of the project, while in others, IT departments are those who make decisions. And sometimes, I can see how the company’s decisions are based solely on technology.

Well, I’ll repeat it again, I am basically a technician, but you have to be aware of basing your decisions solely on technology, and do a little self-criticism: this is a mistake. In my opinion, there are two points that  a technician has to remember when working on a BPM project.

1º The most important thing is the business, that is all that matters; informatics is simply (or should be)  supporting the business to facilitate the operations and save costs.

2º Who really should lead and propel a BPM project is the business people, while the technical side of the company should give proper support to their business needs.

The most important thing is being able to make it easier for users and improve their ability to be more efficient and effective; or in general terms: facilitate the business.

However, the opposite tends to happen. Once we finally have adopted an architecture and a way of working, we end up adapting the business to the technology and to the chosen way of working. This is counter-productive, since in the end of the idea behind ​​BPM is to optimize our business processes. But if we are mainly conditioned by and looking at the technology, there is no room left to optimize the business processes.

The IT department obviously has much to contribute, and even can signal restrictions, caused by in-house rules and by the limitations of the products (let’s face it, these are not perfect…) but always under the guideline to “facilitate” the business.

Sometimes you can witness discussions about whether BPM projects should be led from the technical area ,or vice versa, should be directed from the “business area”. Well I think there is a third answer possible. Based on my experience, I would choose option C: both “areas” should lead the BPM project.

And if you don’t agree, then let’s think for a moment: Imagine having the entire IT department against carrying out the project, because they see a lot of problems arising… How are we going to be able to take the project forward if the ones that are going to have to implement it, are against it?

Or look at it from another perspective: Suppose that the impulse comes from the IT guys but business users do not understand what those “IT guys” want to do. They may think the IT guys are playing, and that affects them directly in their work. In that case, people who will use the platforms do not want to participate, or even worse, the people who must deliver the business knowledge are against sharing their knowledge… What will happen then? … (see my previous post).

Obviously there are always actions to mitigate both cases. If the problem lies in IT, we can outsource and minimize exposure of our computer equipment. However, if the problem lies with the business, you can always more or less take pro-active action by the higher courts.

What would be the best option? The two together boost the project, perhaps at the behest of some senior manager, but always with a little help of  the “left hand”. I think this senior manager should make clear to both the technical and the business users, what the importance of the project is, what are the objectives, the project causes and the underlying motivations. So that both business and technical users combine their energies and both successfully complete the business goal.

Follow