Como consultor en el desarrollo de software, es muy común ser asignado a proyectos en los que participan consultores de otras empresas formando de esta manera equipos de trabajo interdisciplinarios y multiempresa; unos se encargan de la administración y metodología del proyecto, otros más del análisis, diseño, modelación, desarrollo, documentación y pruebas, por mencionar solo algunas de las diferentes tareas involucradas. Fue de esta manera que fui asignado a participar en un proyecto en el que había que automatizar el flujo de un proceso administrativo de una empresa dedicada a la comercialización, industria perteneciente al sector conocido como retail.
Así que me integré al equipo, que estaba conformado por tres diferentes empresas y fui asignado a la fase de desarrollo. Solo requería tener conocimientos básicos de programación orientada a objetos y experiencia en el análisis, diseño y desarrollo de sistemas. La herramienta que se iba a utilizar para este desarrollo se llamaba Fuego. En mi vida había oído hablar de esta herramienta, por supuesto que no se requería experiencia, se dedicaría un periodo inicial para capacitar a los desarrolladores antes de iniciar formalmente el proyecto. Así fue como conocí el concepto BPM. Fuego, es mas que una herramienta de desarrollo, es un ambiente de trabajo. Este ambiente de trabajo, se puede dividir a su vez en dos: el ambiente de producción y el ambiente de desarrollo y configuración. Estos están basados en aplicaciones comunes a los ambientes de sistemas: navegadores, servidores web, servidores de bases de datos y servicios de directorio, por mencionar algunos. Algunas aplicaciones propias de Fuego complementan el ambiente de producción y desarrollo: motor de orquestación, portal de trabajo, administrador de componentes, administrador de la organización, diseñador de procesos, consola de ejecución y el analizador de procesos.
Aunque pudieran parecer una gran cantidad de aplicaciones, realmente no es tan complicado preparar el ambiente de operación y desarrollo, inclusive el de desarrollo se puede preparar en un solo equipo para poder trabajar en forma independiente y aislada para posteriormente poder desplegar el proceso en el ambiente de producción.
Recuerdo que en alguna ocasión me tocó programar aplicaciones del tipo “flujo de trabajo” utilizando lenguajes de programación convencionales. Esto representó un reto algo diferente al de cualquier otro tipo de desarrollo, pero nada que impidiera alcanzar finalmente el éxito y la automatización del proceso correspondiente. Sin embargo, los BPMS están específicamente diseñados para automatizar en forma sencilla este tipo de procesos.
La clave del éxito de este tipo de ambientes de desarrollo es el denominado “diseñador de procesos”, la herramienta central del BPMS. Al mismo tiempo, representa el mayor de los retos que los programadores de lenguajes tradicionales enfrentan al pretender automatizar un proceso. En este caso, la clave es “modelar el proceso” tal como se desarrolla en la práctica; lo que implica primero, identificar los diferentes pasos que el proceso incluye para posteriormente, apoyado en una serie de íconos para el modelado, representarlo gráficamente en el diseñador, considerando los participantes en el proceso y los conectores que comunican las actividades o pasos.
Aunque esta representación gráfica del proceso esta diseñada para que cualquier analista de negocio e inclusive ejecutivo participante del proceso lo pueda entender, la construcción o modelado del proceso requiere de un nivel de abstracción adicional al requerido simplemente para su entendimiento. Un elemento fundamental a considerar al momento de modelar es lo que se denomina una “instancia”. Las instancias son las ejecuciones individuales de un proceso. Cada vez que se inicia un proceso, se crea una instancia y el sistema mantendrá un estricto control de ésta mientras fluye por cada una de las actividades hasta llegar al punto final. Paralelamente, el sistema almacena la información de la instancia en la base de datos para poder conocer el detalle particular de su flujo, en función de la actividad particular en la que se encuentre. Todavía hay un par de factores más a considerar en el modelado de un proceso: la transformación o característica que agrega cada una de las actividades a la instancia y la descomposición de una instancia en dos o más partes para poder realizar procesos paralelos que permitan posteriormente la reintegración de la instancia en una actividad posterior.
Considerar todos estos factores para poder modelar un proceso, resulta ser una tarea no muy fácil cuando no se tiene experiencia y se esta acostumbrado al proceso tradicional de desarrollo de aplicaciones. Por instinto uno quiere aplicar sus conocimientos de programación al modelado de procesos, lo cual solo crea gran frustración y largas horas de reproceso.
Desde mi punto de vista, esto requiere de un cambio de paradigma en el proceso de conceptualización y análisis cuando se utilizan herramientas BPMS. Para contextualizar, equivale al cambio de paradigma que los programadores de la vieja guardia tuvimos que hacer cuando pasamos de la programación estructurada a la programación orientada a objetos. Se dice en forma muy sencilla, pero este cambio de paradigma resulta bastante difícil de realizar. Sin embargo, cuando una persona que aprende a programar, lo hace inicialmente bajo el paradigma de objetos, se le facilita ya que no está acostumbrada a un paradigma alterno. Lo mismo aplica en el caso de los BPM, los consultores que normalmente no realizan las tareas de análisis, diseño y codificación de sistemas, se les facilita un poco más el entender el concepto de modelado de procesos.
Una vez superada esta primera fase del proceso, la modelación, sigue la fase con la que los programadores estamos más familiarizados, la codificación. Cada una de las actividades modeladas, lleva intrínsicamente una cierta funcionalidad, la cual es posible expandir utilizando un lenguaje script, fácil de usar y que permite configurar las actividades a la necesidad particular del negocio. Algunas de las características comunes de configurar en las actividades son por ejemplo: el tiempo máximo que puede permanecer una instancia en la actividad, y el manejo de excepciones y envío de notificaciones a otros integrantes del proceso entre las más importantes. Con el lenguaje script se puede conseguir funcionalidad adicional como: presentación de mensajes en pantalla, acceso a la base de datos, manejo de variables, expresiones condicionales, bucles y manejo de sentencias de entrada para obtener información de parte del operador.
Cuando la funcionalidad requerida en cualquiera de las actividades va mucho mas allá de lo que se puede lograr con el lenguaje script, se puede desarrollar un componente que posteriormente se puede mandar ejecutar desde cualquier actividad. Los componentes permiten realizar formatos de captura de información mucho más complicados en forma relativamente sencilla para solicitar información al operador e ir automatizando el proceso según sus requerimientos particulares.
Otra característica interesante que se puede obtener de los componentes es la posibilidad de interactuar con otros sistemas para intercambiar información o lanzar procedimientos externos para conseguir automatizar en mayor medida el proceso. Por ejemplo, se puede capturar información desde una de estas pantallas (incluyendo sus procesos de validación) y posteriormente ejecutar un sistema “legacy” el cual requiere de la información recién capturada, la que le es enviada de forma transparente. Este tipo de actividades, consiguen que los operadores o participantes del proceso, interactúen con un solo sistema sin necesidad de tener que usar diferentes aplicaciones e interfaces para conseguir cerrar el flujo del proceso. Esta característica es una de las más poderosas que se pueden obtener de un BPM y que precisamente cumple con el objetivo fundamental de este tipo de sistemas: la administración de los procesos de negocio. Antes de realizar el proceso de despliegue en producción, la herramienta permite realizar tareas de depuración para poder ir siguiendo el flujo de una instancia e ir evaluando las diferentes variables que intervienen en el proceso, facilitando sustancialmente la liberación de procesos libres de errores. Cuando pudiera parecer que la automatización del proceso ha terminado, ésta solo ha iniciado en realidad. Cuando un proceso esta en producción, la fase más importante es precisamente la de evaluación para entonces detectar mejoras, cuellos de botella y la justificación de reingenierías de proceso.
El ambiente colaborativo bajo el que operan este tipo de desarrollos, intranets y/o extranets, ofrece interfaces nítidas y claras para todos los involucrados, fáciles de operar y con una curva de aprendizaje muy corta que permite en muy poco tiempo poder administrar eficientemente los procesos. Desarrollar una aplicación que permita realizar todas estas tareas y controles utilizando lenguajes de programación tradicionales resulta en proyectos muy costosos, de muy difícil mantenimiento, poco susceptibles de poder ser mejorados en función de la experiencia y que normalmente se quedan cortos en cuanto al alcance inicialmente programado.
Los ambientes de desarrollo y producción de los sistemas BPM ofrecen una extraordinaria alternativa para la automatización y mejora de procesos, se convierten en herramientas de vital importancia en la operación de las empresas ya que permiten adecuar y adaptar los procesos en forma rápida a los dinámicos cambios del medio ambiente de negocios que vivimos hoy en día.
Conclusión
El esfuerzo requerido para establecer un BPMS, la capacitación de consultores para la automatización de procesos, así como el cambio de paradigma que este tipo de herramientas exige a sus diseñadores y desarrolladores, bien vale la pena realizarlo ya que los resultados que se pueden obtener son sencillamente espectaculares y no se pueden obtener con ninguna otra herramienta disponible hoy en día en el mercado.
Acerca del autor El Ing. Ernesto Méndez Solís es consultor independiente especializado en administración y liderazgo de proyectos de desarrollo de software. Ha trabajado para varias empresas relacionadas con el desarrollo de software como: Siga Desarrollos, Arthur Andersen e Interfaces. emendezsolis@infosel.net.mx
- Log in to post comments