Los diagramas BPMN son una herramienta de comunicación muy útil para documentar procesos y requisitos. Pero cuando la gente empieza a utilizarlos es difícil evitar la tentación de convertirlos en “listas de instrucciones”. Veamos por qué.
Lo primero que tenemos que hacer es entender qué es un proceso. Una posible definición es que un proceso es un conjunto de actividades realizadas en un orden pre-establecido y rutinario, con la finalidad de convertir unos elementos de entrada en un resultado concreto y reproducible. Es decir, un proceso es cualquier conjunto de tareas repetitivas que producen siempre el mismo resultado.
Los procesos, para que sean eficaces, tienen que estar diseñados de forma que pueda realizarlos cualquier persona, independientemente de su formación, capacidad técnica, experiencia de vida o manías y costumbres. Por eso, los procesos descritos de una forma rígida y exhaustiva terminan generando un montón de problemas. Sólo son útiles para la persona que los diseña.
Por ejemplo, si escribimos el destinatario de una carta en el sobre y el proceso dice que la dirección se tiene que escribir con una “coma” entre el nombre de la calle y el número del portal, la probabilidad de que se cumpla es tan alta como el número de personas que tengan esa costumbre. Los que no la tengan, omitirán de forma natural la coma. Y es que hay muchos hábitos al escribir una dirección, como separar el número con un espacio, una coma o un guión. Lo importante es que da lo mismo. Lo importate es que la dirección se entienda. El diseñador del proceso se ha olvidado de lo importante: que la carta llegue a su destino y se ha centrado en micro-gestionar los detalles.
La forma correcta de especificar el proceso anterior sería: “escribir la dirección del destinatario, que contendrá al menos los siguientes elementos: nombre, dirección, portal, piso, localidad, código postal y provincia, si fuera distinta de la localidad”. Ya está. Que cada uno escriba la dirección como le dé la gana. Lo que debe garantizar el proceso es que no salga ninguna carta sin dirección y que esta se ajuste a unos mínimos de información que la hagan correcta.
¿Significa esto que no podemos imponer un “formato” de dirección”? Sí, sí que podemos. Lo anterior es un ejemplo didáctico para ilustrar un detalle, la conveniencia de definir los procesos como “resultados”, no como “procedimientos técnicos”. ¿Y cual es la diferencia? En esencia, que un procedimiento es la descripción paso a paso de como realizar una tarea, mientras que un proceso es la descripción del resultado de la tarea. Un procedimiento es «así escribo yo las direcciones», mientras que el proceso sería «así es como debe quedar una dirección válida».
Muchos alumnos y compañeros, sobre todo los relacionados con el mundo de la informática, me comentan que entonces un procedimiento se parece mucho a un método de programación. En efecto, los métodos de una clase son algo muy parecido a los procedimientos. La verdad es que nosotros indicamos en el proceso los sucesivos “métodos” de trabajo que se realizan, pero no debe preocuparnos cómo funcionan internamente, de forma que cada persona lo ejecute de acuerdo a su “implementación personal”.
Si lo hacemos de esta forma, el resultado es una enorme flexibilidad en la ejecución del trabajo, una mayor delegación de responsabilidad y confianza en la gente y una mayor satisfacción, ya que cada persona tiene un ámbito de realización de su trabajo en el que puede tomar decisiones.
Además, definir procesos orientados a resultados es más fácil y es coherente con la estrategia de muchas metodologías, como el PMBoK, que tratan de efectuar la división del trabajo en estructuras orientadas a resultados como el WBS. Un buen truco para elaborar un proceso en BPMN es hacer primero un análisis del proceso con un WBS y luego trasladar las unidades de trabajo terminales que han aparecido en ese diagrama al BPMN.