Automatización práctica de procesos

Capítulo 1. Introducción Introducción

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¡Empecemos! Este capítulo trata sobre:

• Qué entiendo por automatización de procesos

• Retos técnicos específicos en la automatización de procesos

• Qué puede hacer un motor de flujo de trabajo y por qué aporta mucho valor

• Cómo pueden colaborar las empresas y las TI al automatizar los procesos

• En qué se diferencian las herramientas modernas de las herramientas BPM y SOA del pasado

Automatización de procesos

En esencia, un proceso (o flujo de trabajo) se refiere simplemente a una serie de tareas que deben realizarse para lograr un resultado deseado.

Los procesos están en todas partes. Como desarrollador, pienso en mi proceso de desarrollo personal como la capacidad de gestionar determinadas tareas que van desde una incidencia hasta un cambio de código que luego se lanza a producción. Como empleado, pienso en optimizar mi proceso en torno a la gestión de correos electrónicos, lo que implica técnicas para priorizarlos rápidamente y mantener mi bandeja de entrada vacía. Como propietario de una empresa, pienso en los procesos empresariales de principio a fin, como cumplir los pedidos de los clientes, lo que se conoce como "order to cash". Y como desarrollador backend, también podría pensar en llamadas remotas en mi código, ya que éstas implican una serie de tareas -especialmente si consideras tareas de reintento o limpieza, porque un sistema distribuido puede fallar en cualquier momento-.

Los procesos pueden automatizarse a distintos niveles. La principal distinción es si un humano controla el proceso, si lo controla un ordenador o si el proceso está totalmente automatizado. He aquí algunos ejemplos que ponen de relieve estos distintos niveles de automatización.

Después del instituto, ayudé a organizar las entregas de comidas sobre ruedas a ancianos en sus domicilios. Había un proceso diario para gestionar los pedidos de comidas, agregar una lista de pedidos que iban a la cocina, empaquetar las comidas y, por último, asegurarse de que todos los pedidos estuvieran etiquetados correctamente para que se entregaran a los destinatarios correctos. Además, estaba el propio servicio de entrega. Cuando empecé, el proceso se realizaba totalmente en papel y llevaba toda una mañana. Cambié eso, aprovechando Microsoft Excel para automatizar algunas tareas. Esto redujo el tiempo de procesamiento a unos 30 minutos, por lo que era mucho más eficiente. Pero seguía habiendo actividades físicas, como empaquetar y etiquetar los alimentos y conducir hasta las casas de los destinatarios.

Y lo que es más importante, el proceso seguía estando controlado por humanos, ya que mi trabajo consistía en pulsar los botones adecuados y presentarme en la cocina en el momento oportuno con las listas apropiadas. Sólo algunas tareas estaban apoyadas por software.

Durante mi última visita al hospital, charlé con el personal sobre cómo funcionaba la preparación de las comidas. Los pacientes debían rellenar una tarjeta de papel para marcar alergias y preferencias de comida, y esta información se tecleaba en un ordenador. Luego, el sistema informático se encargaba de transportar esa información al lugar adecuado en el momento oportuno, y debía hacerse de forma automática. Las personas seguían desempeñando un papel en el proceso, pero no lo dirigían. Se trataba de un proceso controlado por ordenador, pero no totalmente automatizado.

Si llevas este ejemplo aún más lejos, hoy en día existen robots de cocina. Si añadieras estos robots al proceso, sería posible encargar al ordenador no sólo la automatización del flujo de control, sino también las tareas de cocción. Esto acerca el proceso a un proceso totalmente automatizado.

Como puedes ver, hay una distinción importante entre la automatización del flujo de control entre tareas y la automatización de las propias tareas:

Automatización del flujo de control

Las interacciones entre tareas están automatizadas, pero las propias tareas pueden no estarlo. Si el trabajo lo realizan seres humanos, el ordenador controla el proceso y los involucra siempre que es necesario, por ejemplo utilizando interfaces de usuario de listas de tareas. Esto se conoce como gestión humana de tareas. En el ejemplo anterior, eran los humanos los que cocinaban la comida. Esto contrasta con un proceso completamente manual que funciona porque las personas controlan el flujo de tareas, pasándose papeles o correos electrónicos.

Automatización de las tareas

Las propias tareas de están automatizadas. En el ejemplo anterior, serían los robots que cocinan la comida.

Si combina la automatización tanto del flujo de control como de las tareas, acabas teniendo procesos totalmente automatizados, también conocidos como procesamiento directo (STP). Estos procesos sólo requieren intervención manual si ocurre algo más allá de las operaciones normales previstas.

Aunque, por supuesto, existe una tendencia general a automatizar los procesos en la medida de lo posible, hay razones específicas que motivan la automatización:

Alto número de repeticiones

El esfuerzo dedicado a la automatización sólo merece la pena si el ahorro potencial supera el coste del desarrollo. Los procesos con un alto volumen de ejecuciones son excelentes candidatos para la automatización.

Normalización

Los procesos deben estar estructurados y ser repetibles para poder automatizarlos fácilmente. Aunque es posible cierto grado de variación y flexibilidad con los procesos automatizados, ello aumenta el esfuerzo necesario para la automatización y debilita algunas de sus ventajas.

Conformidad

Para algunas industrias o procesos específicos existen normas estrictas en torno a la auditabilidad, o incluso normas que obligan a seguir un procedimiento documentado de forma repetible y revisable. La automatización puede conseguirlo y proporcionar datos relevantes y de alta calidad de inmediato.

Necesidad de calidad

Algunos procesos deben producir resultados de calidad constante. Por ejemplo, puedes prometer una determinada velocidad de entrega para los pedidos de los clientes. Esto es más fácil de conseguir y mantener con un proceso automatizado.

Riqueza de información

Los procesos que llevan mucha información digitalizada son más adecuados para la automatización.

La automatización de procesos puede lograrse por distintos medios, como se examina más adelante en "Limitaciones de otras opciones de implementación", pero hay software especial dedicado a la automatización de procesos. Como se menciona en el Prefacio, este libro se centrará en esas herramientas, y examinará especialmente los motores de flujo de trabajo.

Nota

Automatizar procesos no significa necesariamente desarrollar software o utilizar algún tipo de motor de flujo de trabajo. Puede ser tan sencillo como aprovechar herramientas como Microsoft Office, Slack o Zapier para automatizar tareas desencadenadas por determinados eventos. Por ejemplo, cada vez que introduzco una nueva charla sobre una conferencia en mi hoja de cálculo personal, se desencadenan un par de tareas automatizadas para publicarla en mi página de inicio, en la tabla de eventos de la empresa, en nuestro canal de Slack de relaciones con los desarrolladores, etc. Este tipo de automatización es relativamente fácil de poner en práctica, incluso por personas que no sean de TI en régimen de autoservicio, pero, por supuesto, tiene una potencia limitada.

En el resto de este libro no me centraré en estas herramientas ofimáticas de automatización del flujo de trabajo. En su lugar, exploraremos la automatización de procesos desde una perspectiva de desarrollo y arquitectura de software.

Para ayudarte a entender cómo automatizar procesos con un motor de flujo de trabajo, pasemos rápidamente a una historia que ilustra el tipo de problemas reales de los desarrolladores que puede resolver.

Integraciones del Salvaje Oeste

Imagina que Ash es un desarrollador backend al que se le encarga construir un pequeño sistema backend para cobrar pagos con tarjeta de crédito. No suena demasiado complejo, ¿verdad? Ash empieza de inmediato y diseña una bonita arquitectura. En conversaciones con la gente que se encarga de la tramitación de pedidos, están de acuerdo en que proporcionar una API REST para el servicio de tramitación de pedidos es la opción más fácil para seguir adelante. Así que Ash sigue adelante y empieza a codificarlo.

A mitad de camino, entra un colega y mira la pizarra de Ash, donde está plasmada la belleza de la arquitectura. El colega dice casualmente: "Ah, estás utilizando ese servicio externo de tarjetas de crédito. Yo también solía trabajar con él. Entonces teníamos muchos problemas con las fugas en las conexiones y los cortes; ¿ha mejorado?".

Esta pregunta coge a Ash por sorpresa. ¿Este caro servicio SaaS es defectuoso? ¡Eso significa que el bonito y sencillo código de Ash es demasiado ingenuo! Pero no te preocupes, Ash añade algo de código para reintentar la llamada cuando el servicio no esté disponible. Después de charlar un poco más, el colega revela que su servicio sufría cortes que a veces duraban horas. Así que Ash tiene que pensar en una forma de reintentar durante un periodo de tiempo más largo. Pero, ¡maldita sea, esto implica manejar estados y utilizar un programador! Así que Ash decide no abordar esto de inmediato, sino simplemente añadir un problema al trabajo pendiente con la esperanza de que el equipo de cumplimiento de pedidos pueda resolverlo. Por ahora, el código de Ash simplemente lanza una excepción cuando el servicio de tarjeta de crédito no está disponible, cruzando los dedos para que todo salga bien.

A las dos semanas de empezar la producción, se acerca otro colega del departamento de tramitación de pedidos, junto con el director general. ¿Qué demonios pasa? Resulta que el sistema de Ash genera un montón de errores de "servicio de tarjeta de crédito no disponible", y el director general no está contento con la cantidad de pedidos que no se están cumpliendo: este problema ha supuesto una pérdida de ingresos. Ash intenta actuar de inmediato y pide al equipo de cumplimiento de pedidos que intente reintentar los pagos, pero tienen que solucionar otros problemas urgentes y son reacios a asumir responsabilidades que debería gestionar el servicio de Ash (y tienen toda la razón en ser reacios, como leerás en el Capítulo 7).

Ash promete arreglar la situación y poner algo en directo lo antes posible. De vuelta a su escritorio, Ash crea una tabla de base de datos llamada payment con una columna llamada status. Cada solicitud de pago se inserta allí, con un estado de open. Además, Ash añade un programador sencillo que comprueba los pagos abiertos cada par de segundos y los procesa. Ahora el servicio puede hacer reintentos de estado durante periodos de tiempo más largos. Esto es genial. Ash llama a la gente de cumplimiento de pedidos y discuten los cambios necesarios en la API, ya que ahora los pagos se procesan de forma asíncrona. La API REST original devolverá respuestas HTTP 202 (Aceptado), y el servicio de Ash puede devolver la llamada al servicio de cumplimiento, enviarle algún mensaje o dejar que sondee periódicamente el estado del pago. Los equipos están de acuerdo en que el sondeo es una solución rápida, por lo que Ash sólo tiene que proporcionar otro punto final REST que permita consultar el estado del pago.

El cambio se implanta en la producción y Ash se alegra de haber resuelto las preocupaciones del director general. Pero, por desgracia, la paz no dura demasiado. Una caravana de personas llega a la oficina de Ash, incluido el director de operaciones. Le dicen a Ash que no se puede enviar ningún pedido porque no se están aceptando pagos. ¿Qué? Ash toma nota mentalmente de añadir algún tipo de monitoreo para evitar verse sorprendido por estas situaciones en el futuro, y echa un vistazo a la base de datos. Oh, no, hay una gran cantidad de pagos pendientes acumulándose. Indagando un poco en los registros, Ash descubre que el programador fue interrumpido por un caso excepcional y se bloqueó. Maldita sea.

Ash deja a un lado el único pago envenenado que interrumpió todo el proceso, reinicia el programador y ve que los pagos se están procesando de nuevo. Aliviado, Ash promete vigilar más de cerca las cosas y crea un pequeño script para mirar periódicamente la tabla y enviar una alerta por correo electrónico cuando ocurra algo inusual. Ash también decide añadir a ese script algunas estrategias de mitigación para el caso excepcional. ¡Estupendo!

Después de todas estas estresantes semanas, Ash planea irse de vacaciones. Pero resulta que al jefe no le hace mucha gracia que Ash se vaya porque nadie, excepto él, entiende realmente la pila de herramientas que acaban de construir. Peor aún, el jefe saca en su lugar una lista de requisitos adicionales para el servicio de pago, ya que algunos empresarios han oído hablar del escaso servicio de tarjetas de crédito y quieren informes más detallados sobre la disponibilidad y los tiempos de respuesta. También quieren saber si se está cumpliendo el acuerdo de nivel de servicio (SLA) acordado y quieren monitorizarlo en tiempo real. Cielos, ahora Ash tiene que añadir la generación de informes a una base de datos que no parecía necesaria en un principio. La Figura 1-1 muestra el desorden resultante en toda su belleza.

Figura 1-1. La integración del Salvaje Oeste en juego: el caos habitual que se encuentra en la mayoría de las empresas

Por desgracia, Ash acaba de utilizar un enfoque demasiado común para automatizar procesos que yo llamo integración del Salvaje Oeste. Es un enfoque ad hoc para crear sistemas sin ningún tipo de gobernanza. Es muy probable que un sistema así no sirva bien a la empresa en su conjunto.

Aquí tienes más sabores de la integración del Salvaje Oeste:

Integración mediante base de datos

Un servicio accede directamente a la base de datos de otro servicio para comunicarse, a menudo sin que el otro servicio lo sepa.

Integraciones ingenuas punto a punto

Dos componentes se comunican directamente entre sí, a menudo mediante REST, SOAP o protocolos de mensajería, sin aclarar adecuadamente todos los aspectos en torno a la comunicación remota.

Activadores de bases de datos

Se invoca una lógica adicional cada vez que escribes algo en la base de datos.

Cadenas de herramientas frágiles

Por ejemplo, mover archivos de texto separados por comas (CSV) mediante FTP.

Ash tuvo que escribir mucho código para funciones que son capacidades integradas de un motor de flujo de trabajo: mantener el estado actual, programar reintentos, informar sobre el estado actual y operar procesos de larga duración. En lugar de escribir tu propio código, deberías aprovechar las herramientas existentes. En realidad, no ganas nada desarrollando tu propia solución. Aunque creas que tu proyecto no necesita la complejidad adicional de un motor de flujo de trabajo, siempre deberías pensártelo dos veces.

Consejo

Codificar procesos sin un motor de flujo de trabajo suele dar lugar a un código complejo; la gestión del estado acaba codificándose en los propios componentes. Esto dificulta la comprensión de la lógica empresarial y del proceso empresarial implementado en ese código.

La historia de Ash también podría conducir fácilmente al desarrollo de un motor de flujo de trabajo propio. Estas soluciones específicas de la empresa suponen un gran esfuerzo de desarrollo y mantenimiento, y seguirán estando por detrás de lo que pueden ofrecer las herramientas existentes.

Motores de flujo de trabajo y modelos de procesos ejecutables

Entonces, ¿cuál es la alternativa a la lógica de flujo de trabajo codificada o a un motor de flujo de trabajo casero? Puedes utilizar una herramienta existente, como uno de los productos incluidos en la lista curada del sitio web de este libro.

Un motor de flujo de trabajo automatiza el control de un proceso. Te permite definir y desplegar un plano de tu proceso, la definición del proceso, expresada en un determinado lenguaje de modelado. Con esa definición de proceso desplegada, puedes iniciar instancias del proceso, y el motor de flujo de trabajo hace un seguimiento de su estado.

La Figura 1-2 muestra un proceso para el ejemplo de pago introducido anteriormente. El proceso comienza cuando se requiere un pago, como indica el primer círculo del modelo de proceso (el llamado evento de inicio, que marca el comienzo de un proceso). A continuación, pasa por la única tarea, denominada tarea de servicio, indicada por las ruedas dentadas. Esta tarea de servicio implementará la llamada REST al servicio externo de la tarjeta de crédito. Aprenderás cómo hacerlo en el Capítulo 2. Por ahora, imagina simplemente que escribes algún código de programación normal para hacer esto, lo que yo llamo código cola. Después de esa tarea, el proceso termina en el evento final, el círculo con el borde grueso.

Figura 1-2. Un proceso muy sencillo, que ya puede gestionar muchos requisitos en el ejemplo de la tarjeta de crédito

La Figura 1-3 visualiza con algo de pseudocódigo cómo puedes utilizar este modelo de proceso para implementar los pagos. En primer lugar, escribirás algún código que reaccione ante algo del mundo exterior -por ejemplo, una llamada al punto final REST para cobrar pagos-. A continuación, este código utilizará la API del motor de flujo de trabajo para iniciar una nueva instancia de proceso. El motor de flujo de trabajo conserva esta instancia de proceso; la Figura 1-3 lo visualiza a través de una base de datos relacional. Más adelante en este libro leerás sobre diferentes arquitecturas del motor, opciones de persistencia y escenarios de implementación.

Figura 1-3. Motor de flujo de trabajo

A continuación, escribirás un código de cola para realizar el cargo en la tarjeta de crédito. Este código actúa como una llamada de retorno y se ejecutará cuando la instancia de proceso avance hacia la tarea de cobrar la tarjeta de crédito, lo que ocurrirá automáticamente después de que se inicie la instancia de proceso. Lo ideal es que el pago con tarjeta de crédito se procese inmediatamente y que la instancia de proceso finalice después. Tu punto final REST podría incluso devolver una respuesta síncrona a su cliente. Pero en caso de interrupción del servicio de tarjeta de crédito, el motor de flujo de trabajo puede esperar con seguridad en la tarea para cobrar la tarjeta de crédito y activar reintentos.

Acabamos de tocar las dos capacidades más importantes de un motor de flujo de trabajo:

• Persiste el estado, que permite la espera.

• Programa cosas, como los reintentos.

Dependiendo de la herramienta, puede que el código de cola tenga que escribirse en un lenguaje de programación específico. Pero algunos productos permiten lenguajes de programación arbitrarios, así que si decides limpiar tu implementación del Salvaje Oeste, probablemente podrás reutilizar grandes partes de tu código y limitarte a aprovechar el motor de flujo de trabajo para la gestión de estados y la programación.

Por supuesto, muchos procesos van mucho más allá de ese sencillo ejemplo. Al recuperar pagos, el modelo de proceso podría resolver más problemas empresariales. Por ejemplo, el proceso podría reaccionar ante tarjetas de crédito caducadas y esperar a que el cliente actualice su información de pago, como se visualiza en la Figura 1-4.

Figura 1-4. El proceso de pago puede complicarse rápidamente

Hasta ahora, el proceso de pago es más bien un proceso de integración, que no es el uso más típico para la automatización de procesos. Me gusta empezar con él porque ayuda al público técnico a comprender las capacidades básicas del motor de flujo de trabajo, pero examinaremos un proceso empresarial más típico en la siguiente sección.

Un escenario empresarial

Veamos un proyecto típico (pero imaginario). ShipByButton Inc. (SBB) es una startup tecnológica. Proporciona un pequeño botón de hardware. Cada vez que se pulsa, se pide un artículo concreto. Por ejemplo, podrías poner este botón junto a tu detergente, y cuando veas que el detergente está casi vacío, sólo tienes que pulsar el botón, y entonces se pedirá y se te enviará una caja de detergente (si esto te recuerda al botón Amazon Dash, puede que sea simple coincidencia ;-)).

SBB quiere automatizar su proceso empresarial principal, que es la realización de pedidos. En "Un proyecto típico" se ofrece un análisis detallado de las distintas funciones y su colaboración . Por ahora, digamos que SBB empieza dibujando el proceso en relación con los pasos físicos implicados, y va bajando hasta el nivel de detalle que puede automatizarse utilizando un motor de flujo de trabajo. Se benefician del hecho de que el lenguaje de modelado de procesos, BPMN, es universal independientemente del nivel en que se aplique.

El modelo de proceso resultante se muestra en la Figura 1-5.

Figura 1-5. Proceso empresarial de principio a fin susceptible de automatización

Esto es, por supuesto, un poco simplificado, ya que en la vida real tienes más casos excepcionales; por ejemplo, si no se puede recuperar el pago o no hay existencias de la mercancía.

Puedes ver que este proceso depende de otros servicios, por ejemplo la primera tarea que invoca al servicio de pago. Este es un escenario típico cuando se aplican microservicios, como aprenderás más adelante en este libro.

Nota

El modelado de los procesos empresariales a menudo conduce a un subproducto interesante: conocimientos inesperados. En el caso de un cliente cercano a SBB, descubrimos que la "gente del negocio" no sabía exactamente lo que hacía la "gente del almacén". El modelo visual de procesos no sólo ayudó a identificar este problema, sino también a resolverlo.

Procesos de larga duración

La automatización de procesos tiene un amplio alcance. Aunque a menudo se trata de procesos empresariales de extremo a extremo, como la tramitación de pedidos, la apertura de cuentas o la liquidación de reclamaciones, también puede ayudar en casos de uso mucho más técnicos en torno a la orquestación y la integración, como se señala en el ejemplo de la tarjeta de crédito.

Sin embargo, todos estos ejemplos tienen algo en común: implican procesos de larga duración. Es decir, procesos que tardan minutos, horas, semanas o meses en completarse. Los motores de flujo de trabajo destacan en la gestión de procesos de larga duración.

Estos procesos implican esperar a que ocurra algo; por ejemplo, a que otros componentes respondan, o simplemente a que los humanos hagan algún trabajo. Esta es la razón por la que los motores de flujo de trabajo necesitan gestionar el estado duradero, como se ha mencionado anteriormente.

Otra forma de verlo es que se requiere un comportamiento de larga duración siempre que la lógica cruce los límites. Cuando digo límites, esto puede significar cosas muy distintas. Si llamas a un servicio remoto, cruzas el límite de tu programa local, tu SO local y tu máquina local. Esto te hace responsable de los problemas relacionados con la disponibilidad del servicio o la latencia añadida. Si invocas a otro componente o recurso, también cruzas el límite de la transacción técnica. Si integras componentes de otros equipos, cruzas límites organizativos, lo que significa que tienes que colaborar más con esas personas. Si involucras servicios externos, como los de una agencia de tarjetas de crédito, cruzas el límite de tu propia empresa. Y si implicas a personas, cruzas el límite entre tareas automatizables y no automatizables.

Gestionar estos límites no sólo requiere capacidades de larga duración, sino que también exige que pienses detenidamente en la secuencia de tareas. Los escenarios de fracaso y la estrategia empresarial adecuada para manejarlos requieren un debate serio. Y podrías enfrentarte a requisitos normativos en torno a la seguridad de los datos, el cumplimiento o la auditoría. Estos requisitos motivan aún más las visualizaciones gráficas de procesos, que se tratarán en profundidad en el Capítulo 11; éstas permiten a la gente técnica consultar con la gente no técnica adecuada para resolver cualquier reto.

Los sistemas modernos tienen cada vez más límites, ya que hay una tendencia creciente a alejarse de los sistemas monolíticos y acercarse a componentes de grano fino, como servicios, microservicios o funciones. Y los sistemas a menudo se ensamblan a partir de una mezcla salvaje de aplicaciones internas y servicios consumidos en la nube.

Procesos empresariales, procesos de integración y flujos de trabajo

En resumen, puedes automatizar procesos empresariales y procesos de integración. La frontera entre estas categorías no suele ser nítida, ya que la mayoría de los casos de uso de la integración tienen una motivación empresarial. Por eso, en este libro no se tratan los "procesos de integración" como una categoría aparte. En cambio, "¿Modelo o código?" te mostrará que muchos detalles técnicos acaban en el código de programación normal, no en un modelo de procesos, y "Extracción de la lógica (de integración) en subprocesos" te explicará que puedes extraer algunas partes del modelo de procesos en modelos hijos. Esto te permite trasladar los detalles técnicos a otro nivel de granularidad, lo que ayuda a que el proceso empresarial siga siendo comprensible.

Además, habrás observado que utilizo los términos proceso y flujo de trabajo. A decir verdad, no existe una interpretación común y consensuada de la diferencia entre automatización de procesos y automatización del flujo de trabajo. Muchas personas utilizan estos términos indistintamente. Otros no, y sostienen que los procesos empresariales son más estratégicos y los flujos de trabajo son artefactos más tácticos; por tanto, sólo los flujos de trabajo pueden modelarse y ejecutarse en un motor de flujos de trabajo. Del mismo modo, los modelos de procesos también pueden llamarse modelos de flujos de trabajo; algunas normas utilizan un término y otras el otro. Ninguno de los dos es correcto o incorrecto.

A menudo recomiendo ajustar la terminología a lo que funcione bien en tu entorno. Sin embargo, para este libro tuve que elegir, y simplemente opté por aquello con lo que me siento más cómodo. Como regla general

• La automatización de los procesos empresariales es lo que quieres conseguir. Es el objetivo. Es lo que preocupa a los empresarios. Utilizaré el término proceso (o proceso empresarial) en la mayoría de los casos.

• Utilizo el término flujo de trabajo siempre que hablo de las herramientas, que se refieren a cómo se automatizan realmente los procesos. Así, por ejemplo, hablaré de un motor de flujo de trabajo, aunque éste automatice modelos de procesos.

En la vida real, a veces ajusto estas reglas. Por ejemplo, cuando hablo con gente técnica sobre la implementación, puede que prefiera los términos flujo de trabajo, motor de flujo de trabajo, o a veces incluso motor de orquestación o Saga, dependiendo del contexto (entenderás estos últimos términos cuando hayas avanzado más en este libro).

Colaboración empresa-TI

La colaboración entre las partes interesadas del negocio y los profesionales de TI es crucial para el éxito de las empresas modernas. Las partes interesadas de la empresa comprenden la organización, el mercado, el producto, la estrategia y el argumento comercial de cada proyecto. Pueden canalizar todo eso en requisitos, características y prioridades. Los informáticos, por su parte, comprenden el panorama informático y la organización existentes, las limitaciones y las oportunidades, así como el esfuerzo y la disponibilidad. Sólo colaborando pueden ganar ambas "partes".

Por desgracia, los distintos papeles suelen hablar idiomas diferentes. No literalmente -ambos pueden comunicarse en inglés-, sino en la forma de expresar y entender las cosas.

Poner el proceso empresarial en el centro de esta comunicación ayuda. Facilita mucho la comprensión de los requisitos en el contexto de un panorama más amplio y evita los malentendidos que pueden producirse cuando se discuten las características de forma aislada.

Los modelos visuales de procesos facilitan esta conversación, sobre todo si pueden entenderlos la empresa y el departamento de TI. Todos los talleres de requisitos eficientes que he visto estaban llenos de gente de la empresa y de TI.

Un ejemplo común es que la gente de negocios subestima la complejidad de los requisitos, pero al mismo tiempo pasa por alto picos fáciles. Un diálogo típico es el siguiente

Negocio: "¿Por qué implementar este pequeño botón supone tanto esfuerzo?"

TI: "¡Porque tenemos que deshacer un nudo gigantesco en el software heredado para hacerlo posible! ¿Por qué no podemos hacer un cambio aquí y conseguir el mismo resultado?".

Negocio: "¿Qué, espera, podemos cambiar eso de ahí? Pensábamos que era imposible".

Con la mentalidad adecuada y una buena cultura de colaboración, no sólo avanzarás más rápido, sino que acabarás con mejores soluciones y personas más felices. La automatización de procesos y, especialmente, los modelos visuales de procesos te ayudarán. El Capítulo 10 lo explicará con mucho más detalle.

Los motores empresariales y el valor de la automatización de procesos

Las organizaciones aplican la automatización de procesos para:

• Construye mejores experiencias de cliente.

• Llegar más rápido al mercado (con procesos, productos o modelos de negocio modificados o completamente nuevos).

• Aumenta la agilidad empresarial.

• Impulsa el ahorro de costes operativos.

Esto puede conseguirse gracias a las promesas que conlleva la perspectiva de la automatización de procesos: aumentar la visibilidad, la eficacia, la rentabilidad, la calidad, la confianza, la agilidad empresarial y la escala. Veamos brevemente algunas de ellas.

Los procesos empresariales proporcionan visibilidad directa a las partes interesadas del negocio. Por ejemplo, a una persona de negocios le interesa la secuencia de tareas, como asegurarse de que el pago se cobra antes del envío, o saber cuál es la estrategia para gestionar los pagos fallidos. Esta información es necesaria para comprender realmente cómo funciona y rinde el negocio en la actualidad. Los datos que proporcionan las plataformas de automatización de procesos conducen a perspectivas procesables, que son la base de las optimizaciones de procesos.

Las empresas se preocupan por la eficacia y rentabilidad de sus procesos automatizados, así como por la calidad y la confianza. Un minorista online puede querer reducir el tiempo de ciclo de su proceso de cumplimiento de pedidos, lo que significa que un cliente recibirá un paquete lo más rápido posible después de pulsar el botón de pedido. Y, por supuesto, los minoristas tampoco quieren que ningún pedido se pierda en el sistema, dejándoles no sólo una venta perdida, sino también un cliente insatisfecho.

Algunos modelos de negocio se basan incluso en la posibilidad de automatizar totalmente los procesos; es crucial para que las empresas ganen dinero, o den respuestas con la rapidez esperada, o escalen su negocio.

La agilidad empresarial es otro motor importante. El ritmo de las TI es demasiado rápido para anticiparse realmente a cualquier tendencia de forma adecuada, por lo que es importante que las empresas construyan sistemas que puedan reaccionar a los cambios. Como me dijo recientemente el director de sistemas de información de una compañía de seguros: "No sabemos lo que necesitaremos mañana. Pero sí sabemos que necesitaremos algo. Así que tenemos que ser capaces de movernos con rapidez". Concentrarse en construir sistemas y arquitecturas de forma que sea fácil adoptar cambios es crucial para la supervivencia de muchas empresas. La automatización de procesos es una pieza importante, ya que facilita lacomprensión de cómo se aplican actualmente los procesos, la participación en debates sobre los cambios y su aplicación.

No son las herramientas de automatización de procesos de tus padres

Si la automatización de procesos y los motores de flujo de trabajo son una solución tan estupenda para determinados problemas, ¿por qué no los aplica todo el mundo? Por supuesto, algunas personas simplemente no los conocen. Pero lo más frecuente es que la gente haya tenido malas experiencias con malas herramientas en el pasado, o que sólo tenga una vaga asociación con términos como flujo de trabajo o automatización de procesos y piense que se relacionan con flujos de documentos de la vieja escuela o suites de herramientas propietarias, que no considera útiles. Alerta de spoiler: ¡esto es un error!

Para superar estos conceptos erróneos es bueno conocer la historia y los fracasos del pasado. Esto te permitirá liberar tu mente para adoptar una forma moderna de pensar sobre la automatización de procesos.

Breve historia de la automatización de procesos

Las raíces de la tecnología de automatización de procesos dedicados se remontan aproximadamente a 1990, cuando los procesos basados en papel empezaron a guiarse por sistemas de gestión de documentos. En estos sistemas, un documento físico o digital era el "testigo" (un concepto que trataremos con más detalle en el Capítulo 3), y los flujos de trabajo se definían en torno a ese documento. Así, por ejemplo, el formulario de solicitud para abrir una cuenta bancaria se escaneaba y se trasladaba automáticamente a las personas que necesitaban trabajar en él.

Todavía puedes detectar estos sistemas basados en documentos en la vida real. Hace poco vi cómo se utilizaba una herramienta con un montón de documentos PDF fantasma que se creaban sólo para poder poner en marcha instancias de flujo de trabajo que no se basaban en un documento físico real.

Esta categoría de sistemas evolucionó hasta convertirse en herramientas de gestión del flujo de trabajo humano, centradas en la gestión de las tareas humanas. Alcanzaron su apogeo hacia el año 2000. Con ellas, no necesitabas documentos para iniciar un flujo de trabajo. Aun así, estos sistemas se construyeron para coordinar a los humanos, no para integrar software.

Después, también hacia el año 2000, surgió la arquitectura orientada a servicios (SOA) como alternativa a los grandes ecosistemas monolíticos en los que las herramientas tradicionales de integración de aplicaciones empresariales (EAI) realizaban integraciones punto a punto. La idea era dividir la funcionalidad en servicios que se ofrecen de forma más o menos estandarizada a la empresa, para que otros puedan consumirlos fácilmente. Una idea fundamental de SOA era reutilizar estos servicios y reducir así los esfuerzos de desarrollo. Surgieron herramientas híbridas: herramientas que tenían sus raíces en SOA pero añadían capacidades de tareas humanas, y productos de flujo de trabajo humano que añadían capacidades de integración.

Más o menos al mismo tiempo, la gestión de procesos empresariales (BPM) fue ganando terreno como disciplina, teniendo en cuenta no sólo estos aspectos técnicos y de herramientas, sino también las lecciones sobre la creación de organizaciones escalables y la reingeniería de procesos empresariales (BPR).

Estos avances se resumen en la Figura 1-6.

Figura 1-6. Desarrollo histórico de las disciplinas

La automatización de procesos fue un tema muy publicitado en la era BPM y SOA. Por desgracia, hubo algunos fallos importantes que provocaron muchas decepciones, por las siguientes razones: El BPM estaba demasiado alejado de los desarrolladores, y las herramientas estaban demasiado orientadas a los proveedores, demasiado centralizadas y demasiado centradas en el código bajo. Me explico.

BPM en la torre de marfil

El BPM como disciplina incluye métodos para descubrir, modelar, analizar, medir, mejorar, optimizar y automatizar los procesos empresariales. En ese sentido, es un tema muy amplio. Por desgracia, muchas iniciativas de BPM estaban demasiado desvinculadas de TI. Durante mucho tiempo, la gente que hacía BPM trabajaba en silos, sin tener en cuenta cómo se automatizaban realmente los procesos dentro de la infraestructura de TI dada. Esto dio lugar a modelos de procesos que no podían funcionar en la vida real, y sin embargo estos modelos se entregaron a los departamentos de TI para que "simplemente" los implantaran. Como era de esperar, esto no funcionó muy bien.

SOA centralizada y el ESB

En un momento de desafortunada sincronización, SOA chocó con los tiempos álgidos de tecnologías muy complejas como el Protocolo Simple de Acceso a Objetos (SOAP), que dificultaba a cualquier equipo de desarrollo ofrecer o consumir cualquier otro servicio. Esto abrió el espacio a los vendedores de herramientas. Como las iniciativas SOA solíanorganizarse y gobernarse de forma muy centralizada, hizo que los grandes vendedores entraran en el juego, y vendieron un middleware muy caro que se colocó en el corazón de muchas empresas con un enfoque descendente. La herramienta se denominaba bus de servicios empresariales (ESB); era un sistema de mensajería en su núcleo, con múltiples herramientas a su alrededor para conectar servicios o transformar datos.

Si echamos la vista atrás y vemos SOA desde la perspectiva actual, es fácil destacar algunas de sus deficiencias:

Centralizado

Las herramientas SOA y ESB solían instalarse como sistemas centralizados y eran gestionadas por sus propios equipos. Esto provocaba situaciones en las que no sólo tenías que implementar y desplegar tu propio servicio, sino también interactuar con el equipo SOA para desplegar configuración adicional en estas herramientas, lo que causaba mucha fricción.

Ajeno al proceso de desarrollo

Las herramientas rompían el flujo de trabajo de desarrollo, imposibilitando las pruebas automatizadas o las canalizaciones de integración continua/entrega continua (CI/CD). Muchas de las herramientas ni siquiera permitían pruebas o implementaciones automatizadas.

Impulsado por el vendedor

Los vendedores se adelantaron al sector y vendieron productos antes de que existieran las buenas prácticas, lo que obligó a muchas empresas a adoptar prácticas que sencillamente no funcionaban.

Infraestructura mixta y lógica empresarial

La lógica empresarial importante a menudo acababa en procedimientos de enrutamiento que se implementaban en el middleware, dejándolo sin una propiedad o responsabilidad claras. Diferentes equipos implementaban diversos aspectos de la lógica que mejor pertenecían a un solo lugar.

Pero, ¿qué relación tiene esto con la automatización de procesos? ¡Buena pregunta! SOA suele venir de la mano de las suites BPM.

Suites BPM equivocadas

Las suites BPM eran herramientas independientes que incluían un motor de flujo de trabajo en su núcleo, con herramientas a su alrededor. Al igual que los ESB, estas suites estaban impulsadas por los proveedores. Se desplegaban como herramientas centralizadas que se introducían de arriba abajo. En estos entornos, un equipo central se encargaba de la plataforma, y a menudo este equipo era el único grupo capaz de realizar la implementación. Esta dependencia de equipos únicos provocó muchos problemas.

Merece la pena mencionar que las suites BPM surgieron en una época en la que la mayoría de las empresas aún ejecutaban software en hardware físico, por lo que las vías de implementación automatizada no existían.

Las limitaciones del código bajo

Las suites BPM llegaron con la promesa del código cero, que más tarde se rebautizó como código bajo. La idea es tan sencilla como atractiva para las partes interesadas de la empresa: desarrollar procesos sin que intervenga TI, de modo que una persona sin conocimientos técnicos pueda crear un modelo de proceso ejecutable sin escribir código de programación.

Los enfoques de bajo código implican herramientas pesadas que permiten a estos no desarrolladores construir procesos arrastrando y soltando elementos preconstruidos. Los sofisticados asistentes permiten a los usuarios configurarlos, por lo que es posible construir soluciones sin escribir ningún código fuente.

Este enfoque sigue siendo vendido como deseable por las empresas de asesoría y los proveedores de BPM, y el enfoque de bajo código tiene, en efecto, sus ventajas. Actualmente hay escasez de desarrolladores, por lo que muchas empresas sencillamente no disponen de los recursos necesarios para realizar proyectos de software adecuados como les gustaría. Las personas menos expertas en tecnología (denominadas desarrolladores ciudadanos por Gartner) empiezan a trabajar en proyectos de software y necesitan estos enfoques de bajo código.

Pero aunque un enfoque de bajo código puede funcionar para procesos relativamente sencillos, definitivamente se queda corto cuando se trata de procesos empresariales complejos o escenarios de integración. Lo que he comprobado con regularidad es que los productos de bajo código no cumplen lo que prometen, y los desarrolladores ciudadanos menos expertos en tecnología no pueden implantar por sí mismos los procesos básicos. Como resultado, las empresas tienen que volver a sus departamentos de TI y pedirles que asignen desarrolladores de software profesionales para terminar el trabajo. Estos desarrolladores de software tienen que aprender un método de desarrollo de aplicaciones propietario y específico del proveedor. Desarrollar esta habilidad lleva mucho tiempo, y a menudo es una experiencia frustrante. Como resultado, faltan desarrolladores de software suficientemente cualificados dentro de la organización, lo que obliga a las empresas a buscar recursos externos.

Esos recursos externos son integradores de sistemas que se asocian con el proveedor de BPM y proporcionan consultores certificados por ese proveedor. Esos consultores tienden a no estar tan cualificados como prometían, son demasiado caros o simplemente no están disponibles, a menudo todo al mismo tiempo.

Además:

• No puedes utilizar las buenas prácticas del sector para desarrollar soluciones de software, como las pruebas automatizadas o los marcos que podrías necesitar para la integración o las interfaces de usuario. Sólo puedes hacer lo que el proveedor ha previsto, ya que es difícil o incluso imposible salirse del camino preconcebido.

• A menudo se te bloquea el acceso al código abierto o al conocimiento impulsado por la comunidad y a las mejoras de las herramientas. Por ejemplo, en lugar de poder coger un ejemplo de código de GitHub, tienes que ver un videotutorial sobre cómo utilizar el asistente propietario para guiarte por la interfaz de bajo código.

• Las herramientas suelen ser muy pesadas y no se ejecutan fácilmente en arquitecturas modernas virtualizadas o nativas de la nube.

Esta desafortunada dinámica hizo que muchas empresas renunciaran a las herramientas de automatización de procesos, aunque no todos los enfoques implican este tipo de software propietario o desarrollo de bajo código.

Consejo

En lugar de sustituir el desarrollo de software por la automatización de procesos de bajo código, ¡hay que centrarse en unir el desarrollo de software y la automatización de procesos!

Es importante comprender que la agilidad no se consigue implantando procesos sin la ayuda de desarrolladores, sino utilizando modelos gráficos que las distintas partes interesadas puedan comprender y discutir.

En cuanto puedas combinar la automatización de procesos con las prácticas "normales" de desarrollo de software, ganarás en eficacia y calidad de desarrollo, permitirás que los desarrolladores normales trabajen en estas tareas y dispondrás de todo un universo de soluciones existentes para ayudarte con todo tipo de problemas. Además, los proveedores de flujos de trabajo pueden preconfigurar la compatibilidad con determinadas integraciones, lo que ayuda a reducir el esfuerzo necesario para crear soluciones.

Más allá de las suites BPM de la vieja escuela

La buena noticia es que ahora hay disponibles muchos motores de flujo de trabajo realmente útiles y ligeros que se integran bien con las prácticas típicas de desarrollo y resuelven problemas comunes.

Esta nueva generación de herramientas suelen ser de código abierto o se ofrecen como servicios en la nube. Se dirigen a los desarrolladores y les ayudan a superar los retos descritos anteriormente en este capítulo. Aportan un valor real y están ayudando a nuestra industria a avanzar.

La historia de Camunda

Siempre me gusta respaldar todo este desarrollo con la historia de la empresa que cofundé: Camunda, un proveedor que -como se dice ahora en marketing- reinventó la automatización de procesos. Como se menciona en el Prefacio, este libro no será un vehículo de marketing para la empresa, pero su historia puede ayudarte a comprender el desarrollo del mercado.

Empecé Camunda junto con mi cofundador en 2008, como empresa de servicios de consultoría en torno a la automatización de procesos. Realizábamos muchos talleres y cursos de formación y, por tanto, teníamos miles de contactos con clientes.

Esto chocó con la época de auge de las antiguas ideas y herramientas BPM y SOA. Pudimos observar varias herramientas en uso en distintas empresas. El tema común era que no funcionaban, y no era demasiado difícil averiguar las razones. Ya las he descrito antes en este capítulo: estas herramientas eran centralizadas, complejas, de código bajo,impulsadas por el proveedor.

Así que empezamos a experimentar con los frameworks de código abierto disponibles en aquel momento. Estaban mucho más cerca de los desarrolladores, pero tampoco daban la talla, principalmente porque eran demasiado básicos, carecían de funciones importantes y requerían demasiado esfuerzo para crear tus propias herramientas en torno a ellos.

Al mismo tiempo, colaboramos en el desarrollo de la norma Business Process Model and Notation (BPMN), que define un lenguaje de modelado de procesos visual pero también directamente ejecutable.

Y vimos una gran oportunidad: crear un motor de flujo de trabajo de código abierto que fuera fácil de desarrollar y fomentara la colaboración entre la empresa y los informáticos mediante el uso de BPMN.

Validamos esa idea con los clientes, y pronto tomamos la decisión de pivotar con la empresa: en 2013 transformamos Camunda de una consultora en un proveedor de automatización de procesos de código abierto. Nuestra herramienta era totalmente opuesta a las suites BPM de código bajo habituales entonces.

En la actualidad, Camunda está creciendo rápidamente y cuenta con cientos de clientes de pago e innumerables usuarios de la comunidad. Muchas grandes organizaciones confían en nuestra visión, e incluso están sustituyendo herramientas de grandes proveedores en sus empresas. Aceleramos el crecimiento a nivel mundial, ya que las herramientas de automatización de procesos son muy necesarias. Esto se ve impulsado por la digitalización y los programas de automatización, así como por la tendencia a avanzar hacia componentes y microservicios de grano más fino, que luego deben coordinarse. En resumen: nos va muy bien.

Técnicamente, el motor de flujo de trabajo de Camunda está diseñado como se diseñaban las aplicaciones en 2013. Básicamente es una biblioteca, construida en Java, que utiliza una base de datos relacional para almacenar el estado. El motor puede incrustarse en tu propia aplicación Java o ejecutarse de forma independiente, proporcionando una API REST. Y, por supuesto, hay un par de herramientas adicionales para modelar u operar procesos.

Esta arquitectura ha servido muy bien a Camunda y puede hacer frente a la mayoría de los requisitos actuales de rendimiento y escalabilidad. Sin embargo, hace un par de años desarrollamos un nuevo motor de flujo de trabajo en una arquitectura completamente diferente, que hoy en día se describe mejor como nativa de la nube. Este motor de flujo de trabajo se desarrolla en paralelo y respalda la oferta de servicios gestionados dentro de Camunda Cloud. Como escala infinitamente, esto permite el uso de un motor de flujo de trabajo en aún más escenarios, que es una visión que hemos tenido en mente durante mucho tiempo.

Conclusión

Como se ha mostrado en este capítulo, la automatización de procesos es una pieza central de los esfuerzos de digitalización. Esto hace que los motores de flujo de trabajo sean un elemento vital en las arquitecturas modernas. Afortunadamente, hoy disponemos de una gran tecnología, que es muy diferente de las suites BPM de la vieja escuela. No sólo es fácil de desarrollar, sino también muy eficaz y escalable.

Los motores de flujo de trabajo resuelven los problemas relacionados con la gestión de estados y te permiten modelar y ejecutar modelos gráficos de procesos para automatizar el flujo de control de los procesos. Esto te ayuda a evitar la integración del Salvaje Oeste y fomenta la colaboración empresa-TI al automatizar los procesos. Aquí has visto un primer ejemplo de modelo de proceso, ejecutado directamente en un motor de flujo de trabajo; esto es algo que se explicará con más detalle en el próximo capítulo.