Le workflow dans l’entreprise
L’approche labyrinthique
Quand on voit le serveur ou la serveuse introduire notre commande dans son terminal POS, on peut se faire une idée, en général, d’un logiciel vertical, avec une utilisation spécifique et une incidence très réduite dans les processus de la société. Le restaurant fera probablement le total des ventes à la fin de la journée, et disposera peut-être d’une interface pour se communiquer avec une autre application de comptabilité. En général, pas grand-chose en plus. Et c’est bien que ce soit comme ça, simple, efficace, sans fioritures.
Cambiamos de sector
Nous sommes maintenant dans le centre de gestion d’une usine. Un programme est chargé de contrôler les processus de l’usine. Il doit établir une communication avec les ressources humaines et leurs horaires de travail, car il faut toujours s’occuper des machines.
La disponibilité des matières premières doit également être contrôlée, car l’absence d’une seule d’entre elles aurait pour conséquence l’arrêt de la production.
En temps réel, le logiciel doit contacter les fournisseurs pour les informer sur les projections. À l’arrivée de chaque lot, un processus de vérification et de transformation doit être suivi avant qu’il soit incorporé dans la chaîne de production… arrêtons-nous là.
IIl y a une certaine approche pour construire le logiciel chargé de gérer le scénario décrit ci-dessus: faire le programme de haut en bas, peu importe sa complexité. Nous ouvrirons la porte à ce logiciel pour lui permettre de communiquer avec tout dépôt de données ou toute application externe. Tous ceux qui travaillent dans ce secteur savent que c’est vraiment compliqué. Dans un premier temps, sans aller trop loin, nous avons trouvé quelques faiblesses:
- Logiciels rigides
- Difficile d’apporter des changements
- Les développeurs doivent bien connaître l’entreprise, l’ensemble de celle-ci dans toutes ses phases
Pourquoi appelle-t-on cette approche labyrinthique?
Prenons un exemple. Jusqu’à présent, une des pièces que le fournisseur nous fournit (dans notre exemple) demandait «x» heures de manœuvre avant d’être incorporée dans la chaîne de montage. Et elle a dû être assemblée avec une autre pièce provenant d’un autre fournisseur. Mais il s’avère maintenant que la pièce entière vient sans besoin de manipulation. Il bouleverse complètement le mode de fabrication et son délai. Comment régler ce problème dans les logiciels monolithiques traditionnels? Eh bien, tout dépend de la méthode utilisée, il faudra trouver les zones de code qui sont impliquées dans ces processus et y apporter des modifications, recompiler, redistribuer et attendre que tout se passe bien. À mesure que la complexité de ces logiciels augmente, les changements deviennent compliqués, labyrinthiques.
Un mathématicien dans une usine
Carl Adam Petri
Né en 1926 à Leipzig, fils de mathématicien, d’un tempérament affable, on dit qu’à l’âge de 13 ans, il a créé les réseaux qui porteront son nom pour les modèles de réactions chimiques. Il a été éduqué dans des universités techniques et sa grande contribution mathématique ne serait pas liée aux abstractions ou aux théorèmes des mathématiques pures, mais plutôt à l’application mathématique de quelque chose qui est fondamental dans tout processus, industrie, activité, société: l’interaction, la simultanéité, la collaboration entre les processus. Son premier principe directeur: la concomitance doit être le point de départ de la conception d’un système, et non pas être ajoutée plus tard comme réflexion, c’est-à-dire que la vie est complexe. Dans toute activité (un processus industriel ou toute autre activité), de nombreux acteurs et forces convergent et interagissent en même temps. Un processus dépend d’un autre et celui-ci d’un troisième. Cette situation peut conduire à une concurrence pour une ressource (race conditions) ou même à des blocages (deadlocks). Puisque le logiciel que nous développons est en fait une abstraction codée de ces réalités, on ne peut pas l’empêcher d’être face aux mêmes problèmes. Eh bien, notre admiré Carl (Adam Petri) a proposé dans sa thèse de doctorat dans les années 1960 une description formelle de la façon dont les systèmes complexes interagissent.
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.
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
El software que Flash Data ha licenciado, adapta y desarrolla se basa en Workflow Engine, del cual tiene licencia para utilización del código. Algunas características serían:
AntWay Workflow
Ahora bien, sobre dicha estupenda plataforma en Flash Data hemos hecho lo siguiente: crear la plataforma AntWay, la cual permite acercar el mundo del workflow al del BPM debido a sus características centralizadas. Así con AntWay disponemos de:
