La Gestión de Procesos de Negocio o BPM es un área de gestión que aspira a la mejora continua del rendimiento empresarial mediante la optimización de los procesos de negocio de la compañía. BPM empezó con el empleo de tecnologías de la Información para automatización de procesos industriales, donde la intervención de personas era menos representativa.
Desde entonces, se aplica a los procesos de negocio en los que las acciones humanas, las decisiones que ellos toman y la interacción entre actores distintos son esenciales para el éxito del proceso. Es lo que también se ha denominado “sistemas de gestión por workflow”.
La automatización de procesos de gestión documental se ha convertido es una categoría del BPM que ha cobrado mucha relevancia por la necesidad de reducir tiempos, gastos y en general optimizar aquellos procesos en los que la producción, trámite o publicación de documentos forma parte esencial de la cadena de valor de las empresas.
Sin embargo, en el mundo del software de gestión electrónica de documentos asistimos a dos tendencias opuestas respecto a la automatización:
- La masificación de herramientas de tramitación electrónica de expedientes que no disponen en absoluto de una capacidad de modelado de procesos, que son muy eficientes para tareas muy concretas, pero poco aprovechables para un empleo universal y flexible en las organizaciones.
- La presencia de herramientas BPM muy potentes, con amplias capacidades de integración, a veces muy costosas para despliegues masivos, pero que en su diseño no consideran ni favorecen las buenas prácticas en gestión documental, sembrando o multiplicando con frecuencia el caos digital en la empresa moderna.
En este artículo conoceremos más de cerca algunas tecnologías de BPM acopladas con herramientas de gestión documental profesional, que logran equilibrar los requisitos de modelado, optimización y control de procesos, con los requisitos funcionales de la gestión documental y el records management.
Situaciones comunes
Dependiendo de los países en los que estamos implantando soluciones de gestión electrónica de documentos, asistimos a aproximaciones muy diferentes en el abordaje de la gestión de los procesos empresariales.
En España, la Administración Pública ha definido directrices para la gestión electrónica de documentos que son muy detallados en lo que respecta a la certificación digital, el modelo de interoperabilidad y el modelo de gestión documental, sustentando en buenas prácticas internacionales y requisitos funcionales ampliamente aceptados como Moreq. Sin embargo, no se han establecido lineamientos claros respecto a la forma de modelar y parametrizar los trámites administrativos, dejando la gestión del trámite documental, los flujos de trabajo y por ende la conformación del expediente electrónico al arbitrio de las propias entidades.
Muchos pliegos para implantación de soluciones de administración electrónica parten de que los procesos o trámites administrativos son estándar, universales y fijos, por lo que no se exigen softwares con capacidad para su modelamiento, simulación o perfeccionamiento de los flujos de trabajo. Y parece obvio que existan normas y regulaciones de ámbito regional o nacional para llevar a cabo la recogida de solicitudes de los ciudadanos, el intercambio de información, el trámite interno y la publicación de las resoluciones, todo ello respetando las leyes de protección de datos (RGPD). Pero una cosa es un marco común y otra cosa es implementar la gestión electrónica en el ámbito de una entidad pública o privada, donde es imposible la estandarización total.
Lo que lleva esta tendencia es hacia el desarrollo de soluciones cerradas con un grado de estandarización alto y tiempos de implantación reducidos, pero con carencias en sus capacidades de adaptación de procesos, ajuste a las necesidades de cada entidad y/o a los requisitos cambiantes de la gestión electrónica de documentos.
Por otro lado, hay países en Latinoamérica donde existe una tendencia opuesta hacia la adquisición de soluciones tipo BPM sin considerar lineamientos para una gestión documental profesional. Se solicitan herramientas 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 evidencias documentales sin necesidad de informáticos ni documentalistas, casi volcando los procedimientos tal cual vienen en el Manual de Calidad.
Sin embargo, esta idea parte de 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.
- 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.
- 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.
- 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).
- 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.
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.