Esta cita, muchas veces atribuida a Edwards Deming, pero en realidad originaria del menos conocido Charles Box, 5 describe la difícil situación
en la que se encuentran los modeladores. Existen una gran cantidad de maneras de modelar el comportamiento deseado, con cualquier nivel de precisión.
Punto Clave: Mucha gente asume que hay siempre un modelo correcto (y de alguna manera el resto son erróneos), sin embargo, rara vez hay un único mo‐ delo correcto. Por otra parte, los modelos pueden ser inválidos (en el sentido de un mal uso de la notación).
Además, usualmente hay muchos más potenciales detalles que capturar que los que son necesarios. Si se tuviese que modelar cómo se prepara una taza de té, una sola Actividad podría ser suficiente. Alternativamente, se podría describir la necesidad de primero hacer hervir el agua, poner una bolsa de té en una taza y opcionalmente agregar leche. Pero si se quisiera preparar té para varias personas utilizando una tetera y hojas de té, o se debiera incluir los pasos para llenar la caldera, o agregar azúcar. El modelador siempre debe tomar decisiones sobre qué incluir y qué no. Por lo que es necesario mantener una perspectiva sobre los usos del mo- delo y por quién será interpretado.
Si el público (aquellos que leerán e interpretaran el modelo) no están in- teresados en los detalles, entonces no se incluirán en los modelos. En otras situaciones, como cuando el modelo soportará la ejecución en una Suite BPM o cuando el objetivo es la simulación, entonces un alto nivel de detalle es requerido.
<
5 A pesar de que esto se encuentra fuera del alcance del estándar BPMN, es de interés para los
modeladores pues tienden a asumir que de algún modo BPMN los ayudará a decidir cuales pro- cesos existen en un dominio dado.
6 Charles Box lo utilize por primera vez como título en un capítulo de un libro en 1979 — Cita:
Box, G.E.P., Robustness in the Strategy of Scientific Model Building, in Robustness in Statistics, R.L. Launer y G.N. Wilkinson, Editors. 1979, Academic Press: New York.
Al comienzo de uno de los talleres se realiza un sencillo ejercicio. Se pide a los participantes que sugieran todas las ideas que quisieran represen- tar en los modelos de proceso. No transcurre mucho antes de completar un par de pizarras—actividades, flujos, entradas, salidas, responsabili- dades, costos, locaciones, calidad, reglas, interacciones, escalabilidad. Al preguntar a los delegados si quisieran que todas estas dimensiones apa- rezcan en un solo proceso, inmediatamente se dieron cuenta de que es cuestión de remover elementos de los modelos para hacerlos útiles.
Punto Clave: El modelador está constantemente tomando decisiones de modelado acerca del propósito del modelo y del público al que está dirigido. 6
Una historia anecdótica lo dejará en claro. Durante los días de Reinge- niería de Procesos de Negocio (BPR a veces referenciado a Reducciones de Personas Mayores), uno de los principales gigantes de la industria quími- ca contrató a una de las firmas líderes en consultoría para que los ayu- dara con la reingeniería de sus procesos de venta en Norteamérica. Lue- go de varios meses de trabajo, se realizó una presentación para la reu- nión de directorio (pues este era un proyecto de gran importancia). Uno de los costados del salón de reuniones estaba cubierto por un diagrama de flujo de ochenta pies (el modelo tal cual ocurre). En la otra pared, un diagrama de flujo del proceso a ser. El entonces Presidente permitió a los Socios de Consultoría culminar su presentación antes de realizar una simple pregunta. “¿Es ese un buen proceso? Y de ser así, por favor, explíqueme porqué.” Y es ahí que surge la base del problema. El detalle dado era totalmente inapropiado para el público al que se estaba apun- tando.
Aquí hay algunos aspectos de un buen modelo:8
• Selectivo—ningún modelo puede representar todo, debe repre- sentar selectivamente los aspectos que son más relevantes de la tarea en cuestión.
• Exacto—El modelo debe codificar exactamente el estado actual del negocio y no una noción parcial o errónea.
• Cuidadosamente completo—El modelo debe ser lo más simple posible, pero no más simple que eso.9
• Comprensible—Una vez que se percibe el modelo se debería estar en condiciones de encontrarle sentido, no debería ser muy compli- cado o resultar poco familiar para comprender.
<
7 Algunos modeladores parecen sentir que la notación debería proporcionar solo una forma de
representar cualquier problema particular. Esto va en contra de la realidad y esperar que un único modelo posible para un escenario dado es irrealista. Todos los modelos son un compromi- so. Habitualmente BPMN proporciona un grupo de funcionalidades para facilitar los diferentes propósitos y estilos de modelado.
Clemens continúa haciendo referencia a algunos de los inconvenientes de la evolución y adaptabilidad entorno al modelo. “Como todos los modelos son, en algún punto, imprecisos, irrelevantes, erróneos, sensibles al paso del tiempo, etc., deben estar abiertos a revisiones recursivas para reflejar nuevos datos, el creciente nivel de comprensión, o la evolución de nues- tras necesidades”.
Al final, los modelos deben ser útiles. Clemens continúa diciendo, “La utilidad es la suma de las propiedades descriptas antes y el grado en que estas se combinan para promover la comprensión y una acción efectiva. Es Importante notar que cuanto más preciso, o más completo, o más ele- gante sea el modelo no significa que sea más útil. Todos los modelos son incompletos. Todos los modelos tiene compromisos. El arte de los que realizan los modelos radica en hacer esa compensación de manera astuta, de forma tal que haga el modelo más útil para el problema en cuestión.”
Punto Clave: Con el propósito de ser útiles, los modelos representan selectivamente algunos elementos del mundo real. El modelador excluye diferentes di‐ mensiones del dominio (para lograr las metas de modelado).
8 Marshal Clemens de la empresa de consultoría, Idiagram, ofrece una excelente guía sobre las
características que los modelos deben exhibir. No analiza BPMN, pero muchos de los puntos son aún relevantes. http://www.idiagram.com/ideas/models.html
9 Aquí está parafraseando a Einstein.
¿Cuántos procesos, en dónde encajan?
La tentación siempre es comenzar directamente a modelar. Sin embargo, un enfoque más detenido normalmente paga importantes dividendos. El problema real es que así como las personas comienzan a describir la manera en que suceden las cosas en un área de su organización, asumen que es todo un gran y único proceso. Lo vemos usualmente en los talle- res. Los estudiantes intentan conectar todo en una descripción de proce- so amorfa que captura toda posible alternativa.
Punto Clave: Habitualmente, es difícil modelar un proceso de extremo a extremo pa‐ ra un problema de negocio en particular. Y aunque esto fuese posible, sería un desafío hacer ese modelo flexible y adaptable.
Por lo general, es mucho mejor partir el dominio del problema en un número discreto de “partes”, que al trabajar juntas resuelven el problema. Por lo tanto la cuestión se reduce a cómo elegir las partes apropiadas. Al buscar técnicas, se encuentran muy pocas.
Para una discusión más amplia sobre los diferentes enfoques para orga- nizar, definir modelos, véase el Apéndice “Técnicas para la Arquitectura de Procesos" en la página 186. Allí se plantean un conjunto de enfoques que, entre ellos, proporcionan una traducción desde el nivel de estrategia del negocio directo a una arquitectura de procesos robusta (independien- temente de la estructura de reportes de la organización). Estas técnicas
podrían extenderse potencialmente a una pila de servicios de TI (como parte de una Arquitectura Orientada a Servicios).
El punto es que BPMN es “agnóstico a metodologías”. Las organizaciones suelen tener una metodología preferida para capturar y desarrollar sus procesos de negocio. No es el papel de BPMN dictar cómo la información de procesos de negocio es recolectada o cómo son llevados a cabo los proyectos. Por lo cual, BPMN soporta múltiples metodologías (siendo tan simples o tan complejas como se necesite que sean). No se especifica el nivel de detalle para los modelos—el modelador, la herramienta de mode- lado, u la organización toman esta decisión. De hecho, como se verá ge- neralmente en el modelado de procesos; habitualmente existen diferentes maneras de modelar la misma situación, con cualquier número de dife- rentes niveles de detalle.
Punto Clave: BPMN no proporciona consejos acerca de cómo estructurar un dominio o lograr una arquitectura apropiada para un área dada. Sin embargo, proporciona funciones que pueden soportar muchos métodos diferen‐ tes.