Procesos documentales versus procesos empresariales: NO es lo mismo

En muchos RFQs y pliegos de licitación estamos asistiendo a una tendencia generalizada de solicitar un software de gestión electrónica de documentos de archivo (SGEDA) provisto de una herramienta de modelado y simulación de procesos (BPM) en la creencia de que se trataría de una única plataforma “mágica” capaz de diseñar e instrumentar cualquier proceso de negocio junto con sus formularios y evidencias documentales.

Sin embargo, esta idea está basada en la creencia engañosa de que un modelo de proceso empresarial es susceptible de ser transformado de forma cuasi-automática en una aplicación con workflow capaz de implementar cualquier proceso abstracto en actividades concretas de gestión electrónica de documentos. Antes de dar nuestras recomendaciones, hagamos una revisión teórica del asunto.

¿Qué es un modelo de procesos?

Un modelo es una representación de una realidad compleja. Modelar es desarrollar una descripción lo más exacta posible de un sistema y de las actividades llevadas a cabo en él.

Cuando un proceso es modelado, con ayuda de una representación gráfica o diagrama de proceso, pueden apreciarse con facilidad las interrelaciones existentes entre las distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, así como identificar los subprocesos comprendidos. Al mismo tiempo, los problemas existentes pueden ponerse de manifiesto dando la oportunidad de realizar acciones de corrección o mejora.

Diagramar es establecer una representación visual de los procesos y subprocesos, lo que permite obtener una información preliminar sobre la amplitud de los mismos, sus tiempos y los de sus actividades. La representación gráfica facilita el análisis y la distinción entre actividades que aportan valor añadido de las que no lo hacen, sean estas necesarias o innecesarias.

Niveles de abstracción de los procesos

Según el nivel de abstracción con el que se describen los procesos, podemos establecer una pirámide invertida, siendo los procesos documentales el grupo de procesos menos numeroso y más específico, mientras que los procesos empresariales se definen en términos mucho más genéricos y alejados de la propia lógica de la gestión documental.

Veamos 3 ejemplos, con niveles de abstracción decrecientes:

• Un proceso de descarga de un buque que arriba a un puerto con miles de contenedores que se deben declarar, revisar, legalizar y remitir a los destinatarios de los bienes;
• Un proceso de aprobación de un crédito financiero, que requiere no sólo la evaluación de una documentación que aporta el solicitante, sino también el análisis del riesgo involucrado en la operación y la asignación de un cupo de riesgo en caso de aprobación.
• Un proceso de radicación, registro y distribución de documentos que se reciben en una ventanilla de correspondencia y que deben terminar clasificados dentro de un expediente conforme a los requisitos legales del archivo.

En el primer caso, se tendrán que describir los cientos de actividades necesarias para llevar a cabo la descarga, la legalización y entrega de las mercancías, siendo las actividades propias de la gestión documental sólo una parte menor y discontinua de este macro-proceso.

En el segundo caso, aunque el grueso de los elementos evaluables son documentos que podrían estar almacenados en un software de gestión documental, también existen trámites que deberán surtirse fuera de esta herramienta (p.ej. el cálculo del riesgo) o incluso en reuniones o eventos que no podrán ser realizados en línea.

El tercer caso es un proceso documental típico que deberá ser implementado en un sistema de gestión electrónica de documentos, quedando pocas actividades fuera del control de esta herramienta.

En consecuencia, a la hora de seleccionar la herramienta óptima para modelar los procesos, se tendrá que analizar su nivel de abstracción, el cual determinará el porcentaje de actividades susceptibles de ser instrumentadas y automatizadas mediante un SGEDA.

Herramientas de automatización de procesos

Dependiendo de las metodologías y estrategias empleadas, podemos diferenciar 3 tipos:

• Orientadas a proceso: se centran en las diferentes tareas a completar para llevar a cabo un proceso completo. En general, se trata de sistemas BPM que no están especializados en la gestión documental profesional, sino en la automatización global de cualquier proceso, incluyendo los procesos de mayor nivel de abstracción.
• Orientados a recursos: se centran en la utilización y distribución de los recursos que son necesarios para llevar a cabo la realización del proceso. Por ello, su nivel de abstracción es menor y suelen especializarse en ciertos aspectos relevantes del proceso. En esta categoría podríamos incluir cualquier software de gestión de recursos, como los ERPs, sistemas de gestión comercial como CRMs, SGEDAs, etc.
• Orientados a datos: se centran en la definición de los datos y en las transformaciones que sufren estos a lo largo del proceso. Son la visión más específica del proceso, con menor capacidad de generalización, pero una mayor precisión operativa por cada proceso específico. En esta categoría entraría cualquier software desarrollado a medida y, por tanto, no suelen disponer de capacidad de diagramación y modelado.

Lenguajes y notaciones de modelado de procesos

Como hemos visto, no todas las herramientas disponen de sistemas para la diagramación e instrumentación de los procesos. Aquellos sistemas con mayor capacidad de abstracción aportan algún tipo de mecanismo de modelado, normalmente basado en estándares.

Existen otros más tradicionales, pero los lenguajes y notaciones que se están convirtiendo en estándares de facto son los siguientes:

Lenguaje Unificado de Modelado (UML):

Es uno de los lenguajes de modelado de procesos más conocidos y utilizados en la actualidad. Está respaldado por el OMG (Object Management Group, www.omg.org). El UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Además, ofrece un estándar para describir un “plano” del sistema (modelo), incluyendo aspectos conceptuales y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un “lenguaje de modelado” para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.

Business Process Modeling Notation (BPMN):

La “Notación para el Modelado de Procesos de Negocio”, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). BPMN es actualmente mantenida por el OMG, en su versión actual 2.0.

El principal objetivo de BPMN es proveer una notación estándar que sea fácilmente legíble y entendible por parte de todos los interesados del negocio (stakeholders). Entre ellos, los analistas de negocio (quienes definen y redefinen los procesos), los desarrolladores (responsables de implementar los procesos) y los gerentes y administradores del negocio (quienes monitorizan y gestionan los procesos).

En síntesis, BPMN2 tiene la finalidad de servir como lenguaje común para cerrar la brecha de comunicación que frecuentemente se presenta entre el diseño de los procesos de negocio y su implementación. En los últimos tiempos, este lenguaje sirve de base para desarrollar herramientas de automatización que son capaces de leer procesos descritos en BPMN2 y traducirlos a instrucciones concretas, que normalmente se codifican en otro tipo de formatos propietarios.

Redes de Petri:

Una red de Petri está formada por lugares, transiciones, arcos dirigidos y marcas o fichas que ocupan posiciones dentro de los lugares. Las reglas son: los arcos conectan un lugar a una transición así como una transición a un lugar. No puede haber arcos entre lugares ni entre transiciones. Las transiciones se disparan, es decir consumen marcas de una posición de inicio y producen marcas en una posición de llegada. Una transición está habilitada si tiene marcas en todas sus posiciones de entrada.

Son una generalización de la teoría de máquinas de estados (autómatas) que permite expresar un sistema con eventos concurrentes.

Más allá del lenguaje elegido, lo importante es la capacidad de compartir modelos entre grupos de personas y roles diferentes, así como la opción de compartir procesos entre aplicaciones diferentes.

Errores comunes en la automatización de procesos

1. No es lo mismo diagramar procesos que automatizarlos. Cuanto más concreto sea el proceso que se quiera automatizar, más compleja será la implementación necesaria, debido a la necesidad de considerar en un software el flujo de datos, actores y situaciones diversas que pueden darse.
2. Las herramientas para automatizar cualquier tipo de procesos (denominadas BPMs), por su mismo propósito universal, no pueden tener un enfoque exclusivo hacia la automatización documental. Su énfasis es sobre todo hacia la integración de tecnologías de información.
3. El lenguaje BPMN2 es una de las opciones más populares para el modelado de cualquier tipo de proceso, con independencia de su nivel de abstracción. Por tanto, es posible utilizar BPMN2 tanto para describir un macro-proceso general (el ejemplo de descarga del buque), como para diagramar un proceso documental muy concreto (el ejemplo de la ventanilla de correspondencia).
4. Hay que encontrar un equilibrio. Un sistema BPM no es un SGEDA y viceversa. Aunque ambos tengan sus mecanismos para el modelado e instrumentación de procesos, sus resultados no serán nunca equivalentes. Es necesario establecer un balance entre las necesidades de modelar y simular procesos y los requisitos para el manejo, clasificación y automatización documental en las organizaciones modernas.

Recomendaciones para la selección de herramientas de automatización de procesos

1)  Si desea una herramienta para modelar, simular y mejorar sus procesos empresariales, sin distinguir por tipología o nivel de abstracción, su herramienta óptima en un sistema BPM. Estos sistemas están especializados en el modelado, análisis y optimización de cualquier tipo de procesos y disponen de mecanismos muy sofisticados para la integración con otros softwares de gestión, como ERPs, CRMs y SGEDAs.

2) Si busca una herramienta para gestionar sus documentos, conformar expedientes y cumplir con la normatividad vigente en gestión documental y archivos, su herramienta es un SGEDA que tenga preferiblemente un mecanismo para modelar y parametrizar sus flujos documentales. Pero no espere que un SGEDA pueda gestionar cualquier tipo de proceso empresarial, porque su misión es automatizar sus documentos.

3) Si busca una herramienta para gestionar procesos empresariales y procesos documentales, probablemente su mejor opción sea integrar un sistema BPM con un SGEDA. Existen métodos basados en servicios web y estándares como CMIS que pueden ayudar en este tipo de integración.

Abox ECM dispone de un editor de workflows documentales con un amplio repertorio de funcionalidades de automatización documental, de forma que sea posible modelar cualquier proceso documental en un plazo muy reducido y con unos esfuerzos limitados. Es posible intercambiar los modelos generados, mediante lenguaje BPMN2 con otros sistemas de información, de forma que sea posible complementar una visión general del proceso con el enfoque concreto y tecnológico del SGEDA.

En el siguiente enlace encontramos una experiencia de integración entre abox ECM y el software BIZAGI, donde se hace evidente las ventajas de esta aproximación para combinar las fortalezas de ambas herramientas.