Máquinas de Estados Finitos: Mejores que los diagramas de flujo
Los diagramas de proceso en Docuo tienen una forma característica: Círculos y flechas. ¿Te has preguntado alguna vez de dónde viene esta forma de describir el workflow?. Su nombre es «Máquinas de Estados Finitos» y son una alternativa a los diagramas de flujo para representar procesos de negocio.
En este blog post (ya te adelantamos que es un poco friki) te contamos su historia y las ventajas e inconvenientes frente al otro tipo habitual de diagramas que se utilizan para representar procesos: Los diagramas de flujo.
El origen de los diagramas de flujo
Los diagramas de flujo han demostrado ser flexibles y adaptables para trazar, describir y explicar una amplia gama de procesos.
El desarrollo del diagrama de flujo como herramienta lógica se remonta a la década de 1920, cuando Frank y Lillian Gilbreth lo presentaron a los miembros de la Sociedad Americana de Ingenieros Mecánicos (ASME) en 1921.
La metodología no tardó en ganarse el favor de la comunidad de ingenieros y en los años 30 ya se utilizaba para ayudar a los empresarios a simplificar su trabajo. En los años 40, empresas estadounidenses como Procter & Gamble aplicaban los principios para definir procesos. Otras utilizaban la técnica para trazar el tratamiento de la información modelando múltiples documentos y sus relaciones.
Los diagramas de flujo para los negocios y la programación
En 1947, la ASME adoptó un conjunto de símbolos de diagramas de flujo lógicos y los matemáticos Herman Goldstine y John von Neumann desarrollaron diagramas de flujo de programación para los problemas de planificación y codificación de un instrumento informático electrónico. Los diagramas de flujo siguieron siendo una herramienta esencial de los programadores informáticos para describir algoritmos hasta la década de 1970, cuando los cambios tecnológicos provocaron un declive de su popularidad.
Sin embargo, los diagramas de flujo están lejos de haber desaparecido. Siguen utilizándose ampliamente para desarrollar una comprensión de alto nivel de los flujos de procesos. Por supuesto, no sólo en el ámbito del software; es probable que muchos de nosotros hayamos esbozado un diagrama de flujo aproximado para ilustrarnos a nosotros mismos o a otros cómo debe funcionar un proceso empresarial.
Desde este punto de vista, los organigramas suelen modelar cómo las personas toman decisiones en un determinado flujo de procesos.
Los diagramas de flujo son perfectos para representar las decisiones que debe tomar un usuario, pero no siempre describen el proceso empresarial.
Como consecuencia, cuando las acciones del usuario se vuelven complejas o el proceso requiere la cooperación de varias personas, el proceso empresarial global se vuelve más difícil de detectar en el diagrama de flujo. A medida que el esquema se complica y se centra más en las decisiones, se vuelve menos representativo del proceso.
A fin de cuentas, los organigramas que representan flujos de trabajo empresariales resultan útiles para formar a nuevas personas en la toma de decisiones, pero no tanto para analizar o modelizar el propio proceso empresarial de forma coherente y fiable.
¿Qué son las máquinas de estados finitos?
Los diagramas de máquinas de estados finitos (Finite-State Machines o FSM por sus siglas en inglés), también conocidos como Autómatas Finitos, fueron utilizados por primera vez por neurofisiólogos (Warren McCulloch y Walter Pitts), biólogos, matemáticos, ingenieros y algunos de los primeros informáticos (G.H. Mealy y E.F. Moore). Todos ellos compartían el interés común de intentar modelizar el proceso del pensamiento humano, ya fuera en el cerebro o replicándolo con un ordenador. Se trata de la teoría de autómatas, presentada por primera vez en 1943 y definida con mayor precisión en los años cincuenta.
Expresado de forma sencilla, en lugar de centrarse en la toma de decisiones, hay dos cuestiones principales que representar en un diagrama FSM. En primer lugar, ¿en cuántos estados diferentes puede encontrarse una máquina (o proceso) determinada a lo largo de todo su ciclo de vida? Y en segundo lugar, ¿de qué maneras puede la máquina pasar de un estado determinado a otro?
En lugar de enumerar las decisiones de un usuario, las Máquinas de Estados Finitos se centran en los posibles estados de un proceso, y en cómo es posible cambiar de un estado a otro.
En comparación con los diagramas de flujo, que utilizan hasta nueve símbolos lógicos ISO/ANSI, los diagramas FSM sólo necesitan dos: círculos, que representan el estado de una máquina, y flechas, que denotan una transición de máquina.
Un círculo representa un estado en el que puede encontrarse la máquina en un momento dado. Una flecha que va del estado A al estado B representa una acción que puede cambiar la máquina al estado B, siempre que su estado actual sea A. Los estados suelen nombrarse como descriptores de estado («hambriento», «saciado») y las transiciones suelen nombrarse como descriptores de acción («comer») o eventos («han pasado 5 horas»):
El estado inicial en el que arranca la máquina no tiene ninguna transición de entrada. Los estados finales (puede haber muchos) no tienen transiciones de salida y son el final del ciclo de vida del proceso o máquina. En los diagramas FSM, los estados inicial y final se representan con un círculo doble, mientras que los estados normales se representan con un círculo simple.
¿Por qué son mejores para el Workflow?
Con una metodología basada en máquinas de estados finitos, las organizaciones disponen de una forma mejor de modelar, analizar y representar los procesos empresariales que requieren una gran cantidad de toma de decisiones o colaboración entre un equipo de personas.
Esto se debe a que los flujos de trabajo definidos por FSM sitúan los procesos en primer plano. Definen cómo debe alcanzarse un objetivo determinado en el contexto de la organización y en cuántos estados diferentes puede encontrarse la información durante ese proceso. Como resultado, el proceso que se describe mediante FSM es independiente de las funciones de las personas.
Digamos que utilizamos un diagrama FSM para definir el flujo de trabajo de una propuesta de venta. Ésta sólo puede estar en uno de un número definido de estados o condiciones a la vez. Los estados pueden ser «en proceso de redacción», «revisión por la dirección», «enviada al cliente», «aceptada» o «rechazada». Las transiciones definen las acciones que cambian el estado del documento. Las acciones que hacen pasar el documento de un estado a otro serían: «envío al gestor», «cambios necesarios», «envío al solicitante», «el solicitante acepta» y «el solicitante rechaza»:
Una vez descrito un proceso mediante un diagrama FSM, resulta sencillo para las personas familiarizadas con el flujo de trabajo asumir la responsabilidad de ejecutar las transiciones de un estado a otro.
Los flujos de trabajo definidos mediante FSM también simplifican la definición de los procesos empresariales en comparación con los diagramas de flujo, ya que los procesos empresariales suelen tener un número menor de estados de información que de puntos de toma de decisiones. A continuación se muestra una comparación de otro flujo de trabajo de propuesta de ventas con algunos puntos de decisión adicionales representados mediante las dos técnicas:
Cómo utilizar FSM para diseñar workflows empresariales
Aplicar esta metodología a la gestión de procesos en una organización, ya sean internos o con la participación de clientes o proveedores, es relativamente sencillo.
En primer lugar, hay muchos tipos de documentos y procesos que pueden definirse en toda la organización. Sin embargo, hay que tener en cuenta que no todos los documentos tienen el potencial de estar en todos los estados, o de ser objeto de todas las acciones. Por ejemplo, es poco probable que desees que los documentos relacionados con las ventas alcancen estados relativos a procesos de recursos humanos.
Los flujos de trabajo deben diseñarse para cada área funcional de la empresa. De este modo se evita la complejidad no deseada y que la gestión de documentos y los flujos de trabajo se extienda entre departamentos. Dividir todo el espectro de procesos y segmentarlos por departamentos -ventas, RRHH, finanzas, etc.- o por tipos, como contratos, propuestas e incidencias, es una buena forma de avanzar.
A la hora de diseñar un workflow documental, es esencial identificar todos los estados posibles en los que puede encontrarse un documento y las acciones que permiten a los documentos pasar de un estado a otro.
Dentro de cada departamento se pueden diseñar flujos de trabajo para distintos tipos de documentos. En ventas a empresas, es probable que tenga que gestionar propuestas generadas en respuesta a solicitudes de propuestas. Un flujo de trabajo dedicado a la gestión de ofertas o presupuestos empresariales puede tener en cuenta las necesidades específicas de la gestión de documentos de este tipo.
Las ofertas son la savia vital de las ventas. Garantizar que se redactan mediante un proceso coherente y que produce repetidamente propuestas de alta calidad está al alcance de todos utilizando un workflow basado en FSM.
Software y automatización de procesos de oficina
Cuando se diseñan flujos de trabajo y se automatiza la gestión de documentos con software, una aplicación basada en FSM adecuada y bien pensada debe ofrecer una verdadera facilidad de uso. Por ejemplo, es deseable que los flujos de trabajo de gestión de documentos sean sencillos de definir para los usuarios con «arrastrar y soltar». No deberían ser necesarios conocimientos de programación ni personalización por parte del proveedor, un valor añadido que suele aumentar el plazo y el coste de implantación.
Recuerda que es poco probable que el diseño inicial del flujo de procesos sea perfecto. Sin embargo, con un sistema sencillo y ágil, el diseño y la configuración deberían ser sencillos, lo que permitiría depurar, refinar y optimizar los flujos de procesos para todos los fines imaginables en cuestión de minutos.
Por otra parte, una vez definido un proceso mediante un diagrama FSM,
Las acciones asociadas a cada transición suelen ser sencillas y repetitivas. Por tanto, son perfectas para automatizarlas mediante software.
Por ejemplo, si tenemos una propuesta de venta en estado «solicitado» y disponemos de una plantilla de documento de propuesta, una vez introducidos los datos básicos: nombre del cliente, dirección, descripción del proyecto y costes, el software debería ser capaz de generar automáticamente el documento utilizando la plantilla y enviarlo al cliente (utilizando una plantilla de correo electrónico) siempre que ejecutemos la transición «enviar al cliente» y el estado cambie a «enviado al cliente».
Al automatizar todas las acciones repetitivas posibles, la tecnología de software de automatización de procesos de oficina ahorra mucho tiempo.
Otras funciones de automatización deben incluir la autoejecución de cualquier transición en función de determinadas condiciones. Por ejemplo, cuando un proceso ha pasado X días en un estado determinado, o cuando se cumple una condición dada. De este modo, los usuarios no tienen que preocuparse de estas tareas y sólo tienen que interactuar con el software cuando es necesaria la intervención humana.
Retención documental y los estados finales del FSM
Cuando se crea un diagrama FSM para un flujo de negocio, se mapean los estados finales de cada proceso. Esto es exactamente lo que se necesita para establecer una política de conservación de registros adecuada para la organización (un requisito común en la gestión de registros).
El software suele permitir la eliminación automática de documentos una vez que han estado en un estado final durante un número determinado de días, meses o años. Esto es útil para situaciones de cumplimiento de la normativa en las que algunos documentos deben conservarse, archivarse y posteriormente eliminarse siguiendo normas estrictas de acuerdo con requisitos legales.
Versiones, revisiones y otras herramientas
Se pueden crear fácilmente flujos de trabajo de gestión de documentos que incorporen múltiples iteraciones y ciclos de revisión antes de ser enviados al destinatario. Los flujos de trabajo que tienen que ver con la gestión de procesos más que de documentos también son fáciles de configurar. Pensemos en un departamento de atención al cliente que necesita gestionar las incidencias desde el primer contacto con el cliente hasta la resolución de la incidencia. El ciclo de vida del ticket puede representarse fácilmente mediante un diagrama FSM y gestionarse y automatizarse mediante software.
La incorporación de herramientas adicionales, como la búsqueda de metadatos, un motor de PDF, la firma digital y el correo electrónico automatizado, aumentan la potencia del sistema y ayudan a evitar que se pierdan pasos importantes en la gestión de documentos y flujos de trabajo empresariales.
Con el sistema en la nube, capacidades adicionales como el almacenamiento de documentos empresariales, el uso compartido seguro de archivos y el cambio del estado de un documento con un solo clic en dispositivos móviles, completan la capacidad de gestionar documentos a lo largo de todo su ciclo de vida y definir flujos de trabajo de forma que satisfagan las demandas de las empresas actuales.