¿Qué es y para qué vale modelar un proceso de negocio?

En los posts anteriores hemos recordado lo que es BPM,  lo que es un proceso de negocio y el ciclo de vida de gestión de un proceso de negocio. Como una actividad, que no una fase, del ciclo de vida, hablábamos de modelar procesos de negocio.
En este artículo vamos a intentar razonar para qué sirve realizar un modelado pero antes, recordemos brevemente qué es modelar en el ámbito del análisis de negocio, análisis de procesos y de la ingeniería de software. 
Podemos decir que modelar es "hacer una representación abstracta y simplificada de una realidad utilizando un lenguaje formal".
¿Qué significa eso?
Pues lo primero que significa es que el modelo siempre representa una realidad. Como tal representación debe ser fiel a esa realidad, es decir, lo que representa debe ser absolutamente cierto en el mundo real pero, al mismo tiempo es una abstracción y también una simplificación. Y el lenguaje formal significa que ese modelado utiliza unas convenciones acotadas de signos y palabras con un significado inequívoco y muy preciso.
¿Todavía parece un galimatías?
Veamos el caso de los procesos de negocio a ver si lo entendemos mejor.
Decíamos que un proceso de negocio era una relación de actividades, eventos y puntos de decisión que involucraban a un conjunto de actores y que coordinadamente generaban un resultado de valor para al menos un cliente.
Un proceso puede ser, por ejemplo, el tratamiento de una avería reportada por un cliente en que hay actividades como el registro de la avería, el diagnóstico, el envío de un técnico, los trabajos de resolución y el cierre del boletín de avería. Un punto de decisión puede ser si se envía realmente un técnico o no es necesario porque la avería ha cesado o porque la puede resolver el propio cliente guiado por teléfono; y un evento podría ser que el cliente volviese a llamar porque aún no se le ha resuelto la avería y no sabe nada. 
Esa sería la realidad. A la hora de modelar un proceso, el lenguaje formal dominante es BPMN (Business Process Model Notation) definido por el OMG (Object Managemet Group). En ese lenguaje, una actividad, por ejemplo, se representa por un cuadrado de esquinas redondeadas y un punto de decisión por un rombo.
El aspecto de un proceso modelado en BPMN es como el que se muestra en la figura:

Es más que evidente que la realidad no es el modelo, pero también es evidente que el modelo representa de una forma fiel, bien que abstracta y simplificada, el proceso real.
Espero que así, sí que se entienda que es modelar.
Ahora bien ¿para qué hacemos ese trabajo? ¿para qué esforzarnos en hacer esos 'dibujitos'? ¿tienen alguna utilidad?
La verdad es que sí, que tienen muchísima utilidad.
Si acudimos a la fuente que hemos utilizado en los últimos artículos, es decir, el libro 'Fundamentals of Business Process Management' de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, estos autores nos aportan dos razones.
En realidad, nos dicen que hay muchas razones pero se centran en dos. En primer lugar para entender el proceso. Esto ocurre sobre todo en la fase de descubrimiento del proceso o, lo que es lo mismo, el levantamiento del proceso AS-IS. Dibujar el modelo que corresponde al proceso actual, nos ayuda a entenderlo mejor, tanto si somos los analistas como, incluso, si somos los expertos de negocio. Y es que el propio proceso de modelado te obliga a hacer preguntas y a entender las respuestas para poder dibujarlo de forma que sea un reflejo fiel de la realidad. 
La segunda razón que aportan es que ayuda a comunicar el proceso a otros. En efecto, dado  que el lenguaje formal es inequívoco (y, además, relativamente simple), el traspaso de un modelo a otra persona le hace sencillo a ésta entenderlo. 
Me atrevería a aportar alguna razón más que los autores se dejan en el tintero. 
Así, y muy relacionado con el entendimiento, diría que el modelado obliga al rigor, ya que en lenguaje natural es fácil ser ambiguo y aun así pensar que lo estamos entendiendo. El tener que expresar el modelo en un lenguaje formal elimina ambigüedades. 
Diría que, además, aparte de para entender, un modelado ayuda a pensar. Ahora no estaría pensando en el levantamiento de AS-IS (descubrimiento) sino en el TO-BE (rediseño). Y la razón es la misma: el expresarlo en un modelo formal nos exige pensar con claridad (sin ambigüedades) en el proceso futuro.
El disponer de un modelado también nos ayuda a archivar el conocimiento para uso futuro.
Incluso, y aunque en menor medida de lo que quisiéramos, el expresar un proceso en un modelo formal, puede facilitar su automatización, ya que, al tratarse el lenguaje formal de un lenguaje inequívoco, es procesable por máquinas y podemos hacer generación automática de código.
Como se puede ver, modelar no es un ejercicio teórico o académico sino que existen muchas y muy buenas razones para llevarlo a cabo.