El Workflow en la empresa

tpv-workflow-explication

La aproximación laberíntica


Cuando vemos al camarero introducir nuestra consumición en su terminal TPV podemos hacernos una idea de, en general, un software vertical, de uso muy concreto y de afectación muy reducida en los procesos de la empresa. Probablemente el restaurante sume al final del día las ventas, y quizás tenga algún interfaz para comunicarse con otra aplicación contable.

Normalmente no mucho más. Y está bien que sea así, sencillo, eficaz, sin florituras.

Cambiamos de sector


Nos encontramos ahora en centro de dirección de una fábrica. Un programa se encarga de controlar los procesos fabriles. Necesita comunicarse con los recursos humanos y sus turnos, pues las máquinas deben estar siempre atendidas.

La disponibilidad de las materias primas también debe vigilarse, pues si falta una sola de ellas se interrumpiría la fabricación.

En tiempo real el software debe contactar con los proveedores para informar de las previsiones. Cuando llega cada partida se tiene que seguir un proceso de verificación y transformación antes de incorporarla en la línea de producción… vamos a parar aquí.

Hay un determinado enfoque para construir el software encargado de gestionar el escenario anterior: hacer el programa de arriba abajo, por complejo que sea. Abriremos puertas a dicho
software para que se comunique con cualquier repositorio de datos o aplicaciones externas al mismo. Todos los del oficio sabemos que esto es francamente complicado. En principio, sin
profundizar demasiado, encontramos algunas debilidades:

  • Software rígido
  • Difícil introducir cambios
  • Los programadores deben conocer muy bien el negocio, todo el negocio en todas sus fases

¿Por qué llamamos a esta aproximación laberíntica?


Pongamos un ejemplo. Hasta ahora, una de las piezas que el proveedor nos suministra (en nuestro ejemplo) necesitaba una manipulación de x horas antes de incorporarla en la cadena de montaje. Y además debía ensamblarse con otra pieza de un proveedor distinto. Pero ahora resulta que viene la pieza completa sin necesidad de manipulación. Cambia por completo el recorrido de la fabricación y sus tiempos. ¿Cómo arreglamos esto en un software monolítico tradicional? Depende de cómo esté hecho, habrá que buscar las zonas de código que tienen que ver con estos procesos e introducir cambios, recompilar, redistribuir y esperar que todo esté bien. Conforme aumenta la complejidad de dicho software los cambios resultan ser complicados, laberínticos.

Un matemático en una fábrica.

Carl Adam Petri


Nacido en 1926 en Leipzig, hijo de matemático, de carácter afable, se dice que con 13 años creó las redes que llevarían su nombre para modelos reacciones químicas. Se formó en universidades técnicas y su gran aportación matemática no se relacionaría con abstracciones o teoremas de matemática pura, sino más bien con la aplicación matemática a algo fundamental en cualquier proceso, industria, actividad, sociedad: la interacción, la concurrencia, la colaboración entre procesos. Su primer principio guiador: La concurrencia debe ser el punto de inicio para diseñar un sistema, y no añadida posteriormente como reflexión Es decir, la vida es compleja. En cualquier actividad (un proceso industrial o una actividad cualquiera) muchos actores y fuerzas concurren e interaccionan a la vez. Un proceso depende de otro y este de un tercero. Esto puede llevar a competencia por un recurso (race conditions) o incluso al bloqueo total (deadlocks). Como el software que creamos es en realidad una  abstracción en código de dichas realidades, no podemos evitar que se enfrente a los mismos problemas. Pues bien, nuestro admirado Carl (Adam Petri) propuso en su tesis doctoral en los  años sesenta una descripción formal de cómo interactúan sistemas complejos

adam-petri-workflow

Con estos artefactos se pueden modelar conceptos complejos de forma sencilla: paralelismo, cooperación o competición. Se representan estados y transiciones. Estos últimos pueden bifurcarse o fusionarse. Gracias a la conceptualización de las Redes de Petri se pudieron formalizar situaciones complejas de tal forma que los problemas pudieran saltar a la vista.

Tomemos por ejemplo el problema de la cena de los filósofos. Donde un grupo de comensales compiten por una serie de recursos (tenedores), exponiéndose a dejar a unos a otros sin cenar, incluso a todos ellos a la vez, cuando, en vez de eso, podrían colaborar para, mediante turnos, cenar todos.

Resumiendo, las Redes de Petri son una conceptualización matemática de modelado de transiciones, usadas en la ciencia de computación muchas veces a nivel teórico. Son susceptibles de ser representadas con fórmulas matemáticas. Pero un nuevo actor estaba por aparecer:

BPM


¿Cómo aplicar los conceptos de las Redes de Petri a los problemas concretos de la Empresa?

Un grupo de interés crea Business Process Management Notation, un Sistema de notación XML para explicar los procesos, estados, flujos, interactuaciones, pero no del mundo teóricomatemático, sino los específicos del mundo de las Empresas (BPM).

Estos conceptos, una vez formalizados y descritos pueden servir como lenguaje común para que todos los actores interesados (stakeholders) se pongan de acuerdo en “dibujar” la Empresa (sus flujos de trabajo).

Existe un grave inconveniente en el uso de software BPM en una organización. Normalmente se tiene que activar “de golpe”, y eso puede ser intimidante. Es una especie de “matrimonio” que puede salir bien… o no. SAP es un buen ejemplo de lo que estamos hablando. Desde
luego, como casi todas las bodas, casarse con un software que “dibuje” nuestra Empresa no es barato.

conceptos-workflow

Por comparar ambos (workflow vs. BPM) digamos que, el Workflow:

  • Coordina tareas y roles de un proceso

Mientras que el software BPM

  • Coordina la organización

Software de Flujos de Trabajo: Workflow


¿Y si se pudiera implementar la metodología BPM poco a poco, departamento a departamento, proceso a proceso?

Eso sí, teniendo una visión global desde el inicio, pero sin tomar decisiones irremediables o difícilmente remediables (matrimonio). ¿Existe dicha metodología / software / panacea?

Si existe, ¿por qué no he oído hablar de ella antes?

Un software de workflows es un derivado, una especialización de las Redes Petri aplicado a actividades, normalmente corporativas. Presenta, entre otras, muchas ventajas:

  • Ya en la fase de diseño del workflow se obliga a todas las partes a racionalizar los procesos, se consigue eficacia, limpieza, se elimina la redundancia, se optimizan los flujos.
  • Cuando los programadores se enfrentan a “picar” código tienen las ideas mucho más claras de cuáles son las responsabilidades de cada parte del programa. Eso contribuye a evitar el problema del laberinto mencionado al principio.
  • Y durante el ciclo de vida del programa es más fácil introducir cambios sin romper nada. Se sabe qué porción de software tocar y cómo afecta a otras partes del sistema.

¿Y por qué no son más famosos? Porque bastante tenemos con sacar el código día a día, semana a semana, para aprender una tecnología que, aunque facilita las cosas a todos, en principio nos obliga a invertir mucho tiempo en su aprendizaje. Ahora bien, esa inversión ya la hemos realizado en Flash Data en su beneficio.

Ponga un workflow en su vida, los desarrolladores que se relacionan con nuestra tecnología de workflows confirman que su trabajo es más sencillo, de mejor calidad, más ordenado. De hecho, tal como está hecho, es posible que con no muchos cambios (idealmente con ninguno) el software existente en su organización pueda utilizar este enfoque.

workflow-engine

AntWay Workflows


Diseñador HTML5 del workflow
Control de versiones del workflow
Soporte de workflows paralelos
Herramienta de monitorización centralizada
Orquestación de los distintos workflows de la Empresa
Importar/Exportar XML
Localización, timers, etc
Utilización de la mayoría de bases de datos del mercado
Servicio de notificaciones de los estados del workflow

Pero, como indica su nombre, el objetivo final de esta plataforma no es que AntWay se convierta en un super-policía dirigiendo el tráfico. Estamos trabajando para implementar los algoritmos de colonia de hormigas. Estos son métodos multi-agente inspirados en la conducta real de las hormigas en la naturaleza y cómo, sin un director o gendarme, basándose en comunicación a través de feromonas, consiguen la ruta óptima para encontrar comida, llevarla a su hormiguero, e informar a sus congéneres.