← Volver al blog Gestión de procesos

Modelado de procesos: notaciones, niveles y método [2026]

El modelado de procesos es la disciplina de representar cómo trabaja una organización con un conjunto de modelos conectados entre sí, en distintos niveles de detalle, escritos en una notación que significa lo mismo para todos los que la leen. Dibujar un proceso en una hoja es hacer un diagrama; modelar es construir y mantener ese conjunto con reglas de nomenclatura, niveles, dueño y versión.

La diferencia importa porque es donde se pierde el dinero: casi todas las organizaciones que «ya tienen sus procesos modelados» tienen en realidad una carpeta con cuarenta diagramas hechos en años distintos, con criterios distintos, sin relación entre ellos y sin nadie que sepa cuál es el vigente. Esta guía trata lo que hace falta para que eso no pase: los cuatro niveles de una arquitectura de procesos, qué notación usar y cuándo la respuesta no es BPMN, dónde dejar de detallar, cómo se valida un modelo con quien lo ejecuta y cómo se gobierna para que siga siendo cierto a los dos años. Si lo que buscas es cómo dibujar un proceso concreto, la pieza hermana es la guía de diagrama de procesos.

Qué es el modelado de procesos

Un modelo de proceso es una representación deliberadamente incompleta de la realidad: incluye lo que hace falta para responder una pregunta y deja fuera todo lo demás. Esa frase suena académica y es la más práctica de todo el tema, porque implica que no existe «el modelo» de un proceso: existe el modelo para auditar, el modelo para capacitar, el modelo para automatizar y el modelo para decidir dónde invertir. Cada uno incluye y omite cosas distintas.

Conviene separarlo de una sigla con la que se confunde: BPM es la disciplina de gestionar los procesos —descubrirlos, medirlos y mejorarlos de forma continua—, mientras que el modelado es la parte que los representa. El modelado es una pieza dentro de BPM, no un sinónimo. La distinción entre BPM, BPMN y BPMS está resuelta en la guía de diagrama de procesos; aquí se da por sabida.

De ahí sale la primera regla del oficio: antes de modelar, se escribe la pregunta que el modelo tiene que responder. Un modelo hecho sin esa pregunta acaba con el nivel de detalle equivocado —demasiado para un comité de dirección, demasiado poco para configurar un sistema— y sin destinatario que lo use.

Cuándo modelar y cuándo basta un procedimiento

Modelar cuesta tiempo de las personas que mejor conocen el trabajo, que es el recurso más caro de cualquier organización. Vale la pena cuando se cumple al menos una de estas condiciones:

• El proceso cruza más de un área. Un modelo por carriles es la única forma barata de que dos áreas vean al mismo tiempo dónde se pasan el trabajo y qué se pierde ahí.
• Hay decisiones con consecuencias. Cuando el flujo se bifurca según reglas —montos, tipos de cliente, plazos—, el texto corrido no alcanza: la ambigüedad se esconde en las conjunciones.
• Va a alimentar una configuración o una automatización. Lo que no está en el modelo, alguien lo va a improvisar en la pantalla de configuración.
• Es un proceso que se audita. El modelo es el índice que conecta cada paso con su registro y su responsable.

Cuándo NO conviene: un proceso lineal, de una sola área, sin bifurcaciones y con pocos ejecutantes se documenta mejor con un procedimiento escrito y una lista de verificación. Modelar todo lo que se mueve produce una biblioteca de diagramas que nadie consulta y que hay que mantener para siempre. La distinción entre las dos piezas está en proceso y procedimiento.

Los cuatro niveles de una arquitectura de procesos

Lo que convierte una carpeta de diagramas en un modelo es que los niveles estén definidos y que cada pieza sepa de quién cuelga. Cuatro niveles bastan para casi cualquier organización mediana, y lo importante de la tabla no son los nombres —cada consultora usa los suyos— sino qué decisión se toma en cada nivel y quién lo lee.

Nivel	Qué contiene	Quién lo lee	Qué decisión soporta
N0 · Mapa de procesos	Todos los procesos de la organización clasificados en estratégicos, clave y de apoyo, con sus relaciones. Una sola hoja.	Dirección, auditores, personal nuevo.	Dónde invertir, qué certificar, qué está sin dueño. Ver mapa de procesos.
N1 · Cadena de proceso	Las grandes etapas de un proceso de punta a punta, de disparador a resultado, sin detalle interno. De 5 a 9 cajas.	Dueños de proceso, gerencias implicadas.	Dónde están las transferencias entre áreas y cuál etapa concentra el retraso.
N2 · Flujo operativo	Las actividades reales con responsables por carril, decisiones, documentos y sistemas. Es el nivel de trabajo.	Quien ejecuta, quien capacita, quien audita.	Cómo se hace, quién responde, qué registro queda.
N3 · Instrucción de trabajo	El detalle de una actividad concreta: pantallas, campos, criterios, cálculos. Casi siempre texto, no diagrama.	Solo quien ejecuta esa actividad.	Cómo se hace este paso exacto. Se crea únicamente donde hace falta.

La regla que evita el desastre más común: no todos los procesos bajan a los cuatro niveles. Un proceso crítico y de alto volumen llega a N3 en dos o tres de sus actividades; un proceso de apoyo estable se queda en N1. Bajar todo a N3 «por consistencia» es la forma más segura de producir un modelo que caduca más rápido de lo que se puede actualizar.

Qué notación usar, y cuándo no es BPMN

La respuesta corta es que BPMN 2.0 es la elección por defecto para flujos de trabajo, y esa recomendación está desarrollada en la guía de diagrama de procesos. La respuesta útil es la otra: hay cuatro casos donde forzar BPMN produce un modelo peor, y es lo que casi nadie escribe.

Notación	Qué modela bien	Cuándo es la respuesta
BPMN 2.0	Flujos de trabajo con secuencia, decisiones, roles, eventos y plazos. Es un estándar de la OMG con un formato de intercambio en XML.	La mayoría de los procesos de negocio, y obligatoriamente si el modelo va a ejecutarse en un motor.
DMN	Reglas de decisión en tablas: condiciones y resultado. Es el estándar hermano de BPMN, también de la OMG.	Cuando el proceso tiene pocas actividades y muchas reglas. Modelar veinte reglas como compuertas produce un diagrama ilegible; una tabla DMN cabe en media página.
CMMN	Trabajo dirigido por caso, donde el orden de las actividades lo decide quien lo lleva según lo que vaya apareciendo.	Atención de un siniestro, un litigio, una investigación, un proyecto de consultoría. Forzar una secuencia fija a un trabajo que no la tiene produce un modelo que nadie sigue.
SIPOC	Proveedor, entrada, proceso, salida, cliente. No es un diagrama de flujo: es un encuadre en una tabla.	Para acotar el alcance antes de modelar, y para hablar con dirección en una sola hoja.
Mapa de flujo de valor	El flujo con tiempos de proceso, tiempos de espera e inventario entre etapas.	Cuando la pregunta es dónde se va el tiempo. Ninguna notación de flujo lo muestra tan bien.
Diagrama de flujo clásico	Secuencia simple con decisiones binarias.	Para explicar algo corto a alguien que no va a aprender una notación. Sin ambición de repositorio.

La regla práctica de elección

Si el modelo va a ejecutarse o a auditarse, BPMN. Si el proceso son reglas disfrazadas de flujo, las reglas salen a una tabla de decisión y el diagrama se queda con tres cajas. Si el trabajo no tiene orden fijo, no se le inventa uno. Y si el destinatario es la dirección, la notación correcta casi siempre es una tabla, no un diagrama.

AS-IS y TO-BE: el error del AS-IS idealizado

Modelar el estado actual (AS-IS) y el deseado (TO-BE) es una práctica estándar. El error que la vuelve inútil es tan frecuente que conviene nombrarlo: el AS-IS que se dibuja no es el proceso actual, es el proceso actual como debería ser. Ocurre porque el modelo se levanta en una sala de juntas con los jefes de área, que describen el proceso aprobado, no el que ocurre a las once de la mañana de un día de cierre.

Cuando el AS-IS está idealizado, pasan tres cosas: las mejoras propuestas atacan problemas que no existen, los problemas reales quedan invisibles, y el equipo que ejecuta reconoce de inmediato que el modelo no describe su trabajo, lo que cuesta la credibilidad del proyecto entero.

Un atajo honesto para proyectos con poco tiempo: no modeles el AS-IS completo. Modela el AS-IS solo de los tramos donde está el problema, y el TO-BE completo. Modelar a fondo un estado actual que se va a tirar es el gasto más fácil de recortar.

Granularidad: la regla de paro

La pregunta que más frena a quien empieza es hasta dónde descomponer. Hay una regla de paro que funciona: una actividad no se descompone más cuando la ejecuta una sola persona, en una sola sesión de trabajo y en un solo sistema. Si se cumplen las tres condiciones, lo que hay dentro es una instrucción de trabajo, no un flujo, y se escribe en texto.

Tres comprobaciones adicionales para calibrar un modelo de nivel operativo:

• Entre 5 y 15 actividades por diagrama. Por debajo de 5, probablemente el proceso pertenece al nivel de arriba. Por encima de 15, hay un subproceso pidiendo salir a su propio diagrama.
• Cada actividad se nombra verbo + sustantivo. «Validar expediente», no «Validación» ni «Expedientes». Un nombre sin verbo casi siempre esconde dos actividades distintas.
• Cada decisión tiene todas sus salidas etiquetadas y ninguna sin salida. Un rombo con una sola rama dibujada es el defecto más común de los modelos heredados, y es exactamente donde vive la excepción que rompe la automatización.

Cómo se valida un modelo

Un modelo sin validar es una hipótesis con buena presentación. Tres pruebas baratas, en este orden:

1. El recorrido con casos reales

Se toman tres casos cerrados del último mes —uno normal, uno con excepción y uno que salió mal— y se recorren sobre el modelo, paso por paso, con quien los resolvió. Un modelo que no puede explicar un caso real que ya ocurrió está incompleto, y el punto exacto donde se atora el recorrido es el hallazgo.

2. La prueba del suplente

Se le da el modelo a alguien competente que no ejecuta ese proceso y se le pide que diga qué haría en cada paso. Donde pregunte, falta información. Es más honesta que preguntarle a quien lo ejecuta, porque esa persona rellena los huecos sin darse cuenta.

3. El conteo de transferencias y esperas

Sobre el modelo validado se cuentan los cambios de responsable y los puntos donde el caso queda esperando. Son dos números que casi nadie pide y que ordenan la conversación de mejora mejor que cualquier diagnóstico: cada transferencia es una cola potencial.

Gobierno del modelo: lo que lo mantiene vivo

Aquí es donde se pierde la mayor parte del trabajo de modelado, y no se pierde por falta de técnica: se pierde porque nadie definió quién mantiene qué. Seis decisiones bastan, y se toman antes de dibujar el primer diagrama:

1. Un repositorio único. Un solo lugar donde vive el modelo vigente. Si hay diagramas circulando por correo, hay versiones en conflicto desde el primer mes.
2. Nomenclatura y codificación. Cómo se nombra un proceso, cómo se codifica y cómo se referencia entre niveles. Sin esto, dos áreas modelan el mismo proceso con dos nombres y nadie lo detecta.
3. Versión y estado. Cada modelo dice su versión, su fecha y si está en borrador, vigente u obsoleto. Un diagrama sin estado es un diagrama que nadie se atreve a usar ni a tirar.
4. Un dueño por proceso. Una persona con nombre, no un área. Es quien aprueba los cambios y quien responde por que el modelo siga siendo cierto.
5. Un ciclo de revisión. Fecha fija —anual para procesos estables, semestral para los que cambian— y revisión obligatoria cuando cambia el sistema o la estructura. Sin fecha, la revisión no ocurre.
6. Formato abierto. Si la herramienta no exporta BPMN en XML, el modelo queda secuestrado por el proveedor. Es el criterio de portabilidad que más se ignora al elegir software de BPMN y el más caro de descubrir tarde.

En una organización con sistema de gestión, estas seis decisiones no son nuevas: son control de la información documentada, que ISO 9001:2015 trata en su cláusula 7.5 pidiendo identificación, revisión, aprobación y control de cambios. Conviene resolver el gobierno del modelo con esas reglas y no con unas paralelas. Aquí se cita la cláusula y se parafrasea su contenido; el texto literal de la norma se adquiere a través de un organismo de normalización.

8 errores que hacen fracasar el modelado

1. Modelar sin la pregunta que el modelo responde. Produce el nivel de detalle equivocado y un entregable sin destinatario. Es el error de origen del que salen casi todos los demás.
2. Bajar todos los procesos al mismo nivel de detalle. Consistencia mal entendida: multiplica el mantenimiento sin agregar información donde no hace falta.
3. Modelar el AS-IS idealizado. Se levanta en sala con jefes de área y sale el proceso aprobado, no el real. Las mejoras que salen de ahí atacan problemas que no existen.
4. Meter las reglas de negocio dentro del diagrama. Veinte compuertas encadenadas son ilegibles y no se pueden mantener. Las reglas salen a una tabla de decisión y el flujo se queda con la secuencia.
5. Elegir la herramienta antes que la notación y el gobierno. La herramienta acaba imponiendo qué se puede modelar, y el formato propietario deja el modelo cautivo.
6. No versionar. Diagramas sin fecha ni estado circulando por correo. A los seis meses nadie puede decir cuál es el vigente, y entonces todos son papel.
7. Modelar sin quien ejecuta. El modelo queda técnicamente correcto y operativamente falso. Además, quien no participó no reconoce el modelo como suyo y no lo usa.
8. Cerrar el proyecto sin dueño ni ciclo de revisión. Es la causa de que una organización tenga «los procesos modelados» de hace cuatro años, con dos sistemas que ya no existen dentro.

Ejemplo resuelto: alta de cliente en tres niveles

Así se ve el mismo proceso —alta de un cliente nuevo en una empresa de servicios— modelado en tres niveles, con la pregunta que responde cada uno. Las cifras son de un ejercicio ilustrativo, no una medición de un cliente.

Lo que hace útil al conjunto no es que estén los tres niveles: es que el N3 existe solo donde había un problema. Un modelo con instrucción de trabajo para las once actividades habría costado cinco veces más y habría envejecido igual de rápido.

Preguntas frecuentes

Conclusión

El modelado de procesos no se juzga por la calidad de los diagramas: se juzga por si alguien toma decisiones distintas gracias a ellos y por si siguen siendo ciertos dentro de dos años. Las dos cosas se deciden antes de dibujar, cuando se escribe la pregunta que el modelo responde y cuando se define quién lo mantiene.

Si vas a empezar, tres decisiones ordenan el resto: escribe la pregunta antes del primer diagrama, define hasta qué nivel baja cada proceso —y acepta que no todos bajan igual— y resuelve el gobierno —repositorio, versión, dueño, ciclo de revisión y formato abierto— antes de que existan cuarenta archivos. Las tres son gratis al principio y carísimas después.