Pensions Defined contribution plan

Un FI no es un diagrama de flujo computacional, en consecuencia, debe evi- tarse toda forma de condiciones, como los rombos típicos de los flujogramas antiguos (del tipo if then else, si sucede esto entonces haga aquello, si no haga esto otro). No incluye condiciones, representadas por un rombo como el de la figura 5-12. Cualquier decisión es una actividad más y tiene como salida el curso normal de los eventos. Tampoco incluye ciclos iterativos, de aquel tipo en que una bifurcación vuelve hacia arriba del flujo. Es suficiente con una nota y normalmente ni siquiera eso es necesario, porque los flujo- gramas de información son autoexplicativos en ese aspecto.

¿Por qué? Porque estamos describiendo actividades que realizan seres humanos, con una variedad y riqueza infinitas. En cada paso hay que dejar la posibilidad de que las personas decidan variantes que no consideró el analis- ta que dibujó el flujo (si utilizó rombos, entonces deja generalmente dos salidas y en la vida real hay muchas más). Además, los símbolos y condicio- nes computacionales tienden a alejar a los usuarios.

Así como el flujograma de información está dirigido a personas, el diagrama de flujo está destinado a la lógica del computador, un flujo digital estricto, tal como se aprecia en la figura 5-12.

Figura 5-12. Diagrama de flujo

El diagrama de flujo69 está orientado a la codificación en un lenguaje com- putacional. Por lo tanto, incorpora condiciones del tipo if then else, retornos,

loops y otras funciones propias del programa de computador. Es diferente a

un flujograma de información. Este tipo de representación es la base de

BPMN (la notación de BPM)

Cuando el diagrama de flujo se usa para describir procesos de personas, re- sultan diagramas como el de la figura 5-13 (no crea que al verlo más grande lo entenderá mejor).

Figura 5-13. Diagrama de flujo de procesos de un laboratorio

69 _{Se atribuye a Frank Gilbreth, colaborador de F. W. Taylor, haber propuesto los primeros}

“diagramas” y a John von Neumann transformarlo en un diagrama de flujo para guiar la construcción de un programa de computador. Es decir, describir un algoritmo extremada- mente técnico.

El diagrama de la figura 5-13 tiene todos los elementos del diagrama de flu- jo computacional: rombos, flechas, loops, mucho texto, no hay un hilo con- ductor y sí muchas cajas donde no queda claro si son procesos, actividades o tareas. Entenderlo es una labor de extrema intelectualidad, mientras lo visual e intuitivo está ausente. Para ser justo, también sería difícil construir softwa- re con ese tipo de diagrama.

Evitar el uso de rombos en los FI

¿Por qué no usar un rombo? Las razones para abandonar el uso del rombo en los flujogramas de información —que existen para ser una guía del traba- jo de las personas— son variadas:

 Rompe la secuencia del proceso y obliga a detenerse, en otras palabras, impide que la persona se concentre en el hacer correcto.

 Nunca perteneció a los flujos que sirven para guiar el trabajo de las

personas. Es un símbolo empleado durante la revolución industrial y

luego en las disciplinas tecnológicas para indicar comportamientos mecánicos, eléctricos, electrónicos o de software, nunca debería haberse aplicado a los seres humanos. Es evidente, en el mundo del mecanicismo está todo estructurado y las alternativas son las definidas. En el mundo de los seres humanos está el comportamiento caótico y las infinitas op- ciones que brinda la creatividad.

 Es dicotómico, generalmente presenta sólo dos salidas cuando en la ma- yoría de los casos la realidad es que las opciones pueden ser muchas (ver práctica elaborar el procedimiento donde las alternativas de excepción en caso de una situación de no encontrar el producto en bodega son alre- dedor de veinte).

 Incentiva lo indeseado, porque “deja la caída”, da el mismo espacio vi- sual a lo indeseado que a lo deseado, así lo indeseado pasa a tomar la misma presencia que lo deseado. Esto explica lo peligroso de los malos modelos en la sociedad, tal como algunos personajes de la farándula. Lo indeseado son aquí errores, documentos no aprobados, productos que no se encuentran, etc.

 Incrementa exponencialmente la complejidad del flujo, hasta hacer que sea imposible de seguirlo. Es lógico, la cantidad de contingencias en un proceso son prácticamente infinitas.

 Dificulta la participación de los operadores del proceso y evita tener una guía clara.

¿Cómo se evitan los rombos?

 En el caso de contingencias, simplemente incluyendo esas posibilidades en el procedimiento.

 En el caso de variantes o etapas diferentes, incluyéndola en el mapa de procesos y elaborando flujogramas de información distintos.

5.10. Relación del FI con la técnica UML

Uno de los aspectos metodológicos y de investigación más interesantes de este libro es el hecho de buscar un punto de encuentro entre dos técnicas de amplio uso: los flujogramas de información y UML (Unified Modeling Lan- guaje o Lenguaje Unificado de Modelamiento), aunque la idea queda mejor expresada como: Modelamiento Visual del Software, expresión que se está utilizando cada vez más en español.

Desde el modelamiento y diseño de procesos surgirán muchos requerimien- tos para el área tecnológica. La forma de definir y comunicar esos requeri- mientos tradicionalmente ha sido anárquica, sin embargo, con UML se profe- sionaliza el levantamiento de requerimientos gracias a una serie de modelos visuales bien apoyados por herramientas computacionales.

El punto de encuentro entre los FI y UML está en las actividades con apoyo de sistema computacional del flujograma de información, las cuales darán origen a los casos de uso de UML.

Mayor detalle en el libro Modelando una solución de software, también se puede observar un ejemplo en el libro Rediseño de procesos.

5.11. Relación del FI con la notación BPMN

La diagramación BPMN emplea una forma de diagramas de flujo que detalla la interacción entre roles y las reglas de negocio que guían la acción.

En cualquier proceso la recomendación metodológica es modelar primero en forma visual con los flujogramas de información y las listas de tareas y lue- go, a partir de esa información que todos los involucrados comprenden, co- menzar a elaborar los diagramas de BPMN.

Gestión de procesos 169