Métodos · Tema T9

Cómo se debe convertir un proceso en una operación inteligente

Revisado el 21 de octubre de 2026

Se imprime completa desde el navegador, en A4 o en carta.

Bloque 1

El problema

Convertir un proceso en una operación inteligente sin automatizar un proceso malo: modelarlo antes de tocar la tecnología, decidir qué automatizar y con qué herramienta, y dejar a cada decisión el control humano que su riesgo exige.

Síntesis en tres líneas

El proceso va antes que la herramienta: un BPMN con responsables, compuertas, eventos y datos sirve para acordar con el negocio, especificar para tecnología y decidir qué eventos capturar para medir.
La herramienta se elige subiendo una escalera: primero la intervención más sencilla —arreglar el proceso, una regla en código—, después los flujos y, solo donde hace falta interpretar, un agente con límites.
Cada automatización se mide contra el proceso que reemplaza y se vigila después: el ritmo lo fija la capacidad real, no el cronograma, y la autonomía crece con la evidencia.

Bloque 2

El mapa

Del proceso acordado a la operación inteligente, peldaño por peldaño

Desliza para ver el mapa completo.

Leyenda de formas y colores

Actor — quien hace el trabajo
Dato — lo que se guarda y se lee
Control — una regla que se comprueba
Persona — una persona decide
Externo — lo que viene de afuera

Lectura del mapa, nodo por nodo

El dueño del proceso lo modela en BPMN; lo esperado se contrasta con lo ejecutado, que llega del registro de eventos, y el proceso se corrige antes de medir su capacidad real y su restricción. Con esa medida se prioriza qué automatizar y se empieza por el peldaño más sencillo: código y reglas; si no hay API, RPA sobre la interfaz; con conectores, flujos low-code; con la plataforma de datos, flujos de n8n; y solo donde hay que interpretar, un agente con código. El agente actúa dentro de límites, bajo un control humano que depende del tipo de decisión; la operación queda observable, deja su rastro en el registro de eventos y se mide, y las métricas vuelven al dueño del proceso.

Nodo 1 Dueño del proceso (Persona) — Quien responde por el resultado del proceso y decide qué se automatiza, con qué herramienta y con cuánto control.
Nodo 2 El proceso en BPMN (Dato) — Carriles por responsable, compuertas con su regla, eventos que lo disparan y objetos de datos que viajan entre actividades.
Nodo 3 Formal frente a ejecutado (Control) — Dónde lo que el procedimiento dice y lo que la operación hace se separan: decisiones informales, correcciones manuales y excepciones.
Nodo 4 Capacidad y restricción (Control) — Tiempo estándar, capacidad efectiva y la estación que fija el ritmo del flujo completo, medidos antes de cambiar nada.
Nodo 5 Qué automatizar (Control) — Valor, frecuencia, datos disponibles y riesgo de equivocarse: se automatiza lo estable y lo que vale la pena, no lo que sigue en discusión.
Nodo 6 Registro de eventos (Dato) — Qué pasó, cuándo, sobre qué objetos y quién lo hizo: la base para comparar lo esperado con lo ejecutado.
Nodo 7 Código y reglas (Actor) — Una macro, un script o una consulta que aplica reglas explícitas: el peldaño más sencillo y el primero que se prueba.
Nodo 8 RPA sobre la interfaz (Actor) — Un robot que repite clics y tecleo donde el sistema no ofrece API; depende de que la pantalla no cambie.
Nodo 9 Flujos low-code (Actor) — Flujos entre aplicaciones con conectores y aprobaciones: deterministas, la misma entrada da la misma salida.
Nodo 10 Flujos n8n con datos (Actor) — Flujos que conectan servicios, reglas y agentes, con una plataforma de datos que guarda cada evento para observarlos.
Nodo 11 Agente con código (Actor) — Interpreta lenguaje, recupera conocimiento o elige entre opciones dentro de límites, con criterios verificables; entra donde una regla fija no alcanza.
Nodo 12 Control humano por decisión (Control) — Informar, recomendar o ejecutar: la autonomía depende del costo de equivocarse y de si la acción se puede revertir.
Nodo 13 Operación observable (Dato) — Cada ejecución con su estado, su tiempo, sus excepciones y su costo, registrada fuera del componente que hace el trabajo.
Nodo 14 Métricas de la automatización (Control) — Tiempo de ciclo, retrabajo, errores y trabajo manual que queda, comparados con la línea base del proceso.

Conexiones

de Dueño del proceso a El proceso en BPMN (modela)
de El proceso en BPMN a Formal frente a ejecutado (lo esperado)
de Registro de eventos a Formal frente a ejecutado (lo ejecutado)
de Formal frente a ejecutado a Capacidad y restricción (se corrige)
de Capacidad y restricción a Qué automatizar (prioriza)
de Qué automatizar a Código y reglas (empieza por)
de Código y reglas a RPA sobre la interfaz (sin API)
de RPA sobre la interfaz a Flujos low-code (con conectores)
de Flujos low-code a Flujos n8n con datos (con datos)
de Flujos n8n con datos a Agente con código (hay que interpretar)
de Agente con código a Control humano por decisión (dentro de límites)
de Control humano por decisión a Operación observable (opera)
de Operación observable a Registro de eventos (deja su rastro)
de Operación observable a Métricas de la automatización (se mide)
de Métricas de la automatización a Dueño del proceso (informa)

Bloque 3

Las fases

1
Fase 1
Modelar el proceso antes de tocar la tecnología
Entradas
- El proceso tal como se ejecuta hoy, con sus excepciones y sus archivos auxiliares.
- Los procedimientos escritos y las personas que hacen cada actividad.
Actividades
- Dibujar el proceso en BPMN: quién hace cada actividad, qué decisión bifurca el flujo, qué evento lo dispara y qué información viaja.
- Contrastar el proceso formal con el ejecutado y anotar cada divergencia.
- Decidir con el dueño qué se conserva, qué se transforma y qué falta acordar.
Artefactos
- El BPMN acordado con el dueño del proceso.
- La lista de divergencias entre lo formal y lo ejecutado.
Quién decide
El dueño del proceso.
Control que cierra la fase
Ninguna automatización empieza sobre un proceso que su dueño no ha acordado.
Evidencia
En Cafam, en 2020, el proceso de la bodega que el WMS esperaba y el que la bodega ejecutaba no eran el mismo, y las pruebas existían para encontrar cada punto en que divergían.
2
Fase 2
Medir la capacidad real y la restricción
Entradas
- Los tiempos observados de cada operación y quién la ejecuta.
- Los volúmenes, las estaciones y las colas del flujo completo.
Actividades
- Calcular el tiempo estándar con la valoración del ritmo y los suplementos por fatiga.
- Encontrar la estación que fija el ritmo del flujo completo.
- Balancear el flujo hacia la restricción, no acelerar cada estación por separado.
Artefactos
- Los tiempos estándar de las operaciones.
- El mapa de capacidad con su cuello de botella.
Quién decide
El dueño del proceso, con quien lo opera.
Control que cierra la fase
Ninguna meta de automatización se fija contra la capacidad nominal.
Evidencia
En Ceinfes, en 2018, no tenía sentido acelerar el escaneo si la captura manual no daba abasto: balancear no fue comprar más escáneres, sino mover personas hacia la restricción y medir cada jornada el avance y el pendiente de digitalización.
3
Fase 3
Decidir qué automatizar y con qué herramienta
Entradas
- El proceso acordado, su capacidad y su restricción.
- El valor, la frecuencia y el riesgo de equivocarse de cada actividad.
Actividades
- Descartar lo que se resuelve cambiando el proceso, aclarando una definición o mejorando el dato.
- Elegir el peldaño más bajo de la escalera que produce el resultado.
- Escribir por qué no alcanza el peldaño de abajo cada vez que se sube uno.
Artefactos
- La cola priorizada de automatizaciones.
- La decisión escrita de herramienta para cada una.
Quién decide
El dueño del proceso, con quien opera la tecnología.
Control que cierra la fase
Ningún agente donde una regla fija alcanza, y nada se automatiza sin línea base.
Evidencia
En Banco Pichincha, en la escalera de instrumentos del reporte al agente, el escalón correcto para fuga y mora fue el modelo predictivo con la persona decidiendo, no un agente; en Vesting, agentes que actuaban con límites explícitos y monitoreo en tiempo real.
4
Fase 4
Construir con el control humano que cada decisión exige
Entradas
- La actividad elegida y su peldaño.
- Las decisiones que toca y lo que cuesta equivocarse en cada una.
Actividades
- Especificar cada actividad con entradas, reglas, salidas, excepciones y criterios verificables.
- Fijar qué informa, qué recomienda y qué ejecuta solo, y bajo qué condiciones.
- Probar contra la definición de terminado antes de operar.
Artefactos
- La especificación con sus criterios de aceptación.
- La matriz de autonomía por tipo de decisión.
Quién decide
El dueño del proceso aprueba el nivel de autonomía.
Control que cierra la fase
Ninguna acción de alto impacto sin aprobación humana, y la definición de terminado se acuerda antes.
Evidencia
En Vesting el proceso core de once etapas fijaba el nivel de autonomía de cada agente —consultar, recomendar o ejecutar, y bajo qué condiciones— antes de construirlo, y la definición de terminado se acordaba antes, no se demostraba después.
5
Fase 5
Operar, observar y medir contra la línea base
Entradas
- Los eventos de cada ejecución.
- La línea base del proceso antes de automatizar.
Actividades
- Registrar cada ejecución con su estado, su tiempo, sus excepciones y su costo.
- Comparar lo ejecutado con lo esperado y con la línea base.
- Decidir si se corrige la operación o se actualiza el modelo del proceso.
Artefactos
- El tablero de la operación automatizada.
- El registro de excepciones con su responsable.
Quién decide
El dueño del proceso, con producto y operaciones.
Control que cierra la fase
El componente que hace el trabajo no es el único que afirma que el trabajo se hizo bien.
Evidencia
En Vesting n8n coordinaba parte de la ejecución de los agentes y Microsoft Fabric conservaba sus eventos —sesiones, solicitudes, respuestas, tiempos, estados y costo en tokens—, que Power BI ponía frente a producto y operaciones: la ejecución y la observación se separaban, porque el componente que hace el trabajo no debería ser el único que afirma que se hizo bien.

Bloque 4

Las decisiones de diseño

El BPMN antes que la herramienta
Cuándo sí
Cuando el proceso cruza áreas, tiene excepciones o nadie ha escrito cómo se ejecuta de verdad: el diagrama acuerda con el negocio, especifica para tecnología y dice qué eventos capturar para medir.
Cuándo no
Cuando la tarea es de una sola persona, con pasos estables y conocidos: basta con escribirla.
Por qué
Evidencia
En Cafam cada actividad del despacho tenía que dejar un registro en el WMS, y si no lo dejaba, el BI de control no podía verla: el BPMN va antes que el modelo de datos, y el modelo de datos antes que cualquier tablero.
Estado del campo
La norma de BPMN busca una notación que todos los usuarios del negocio entiendan y un puente estandarizado entre el diseño de un proceso y su implementación.^[1]
Cómo se decide qué automatizar y con qué herramienta: la intervención más sencilla que produce el resultado
Cuándo sí
Siempre: primero se prueba si basta cambiar el proceso, aclarar una definición o mejorar el dato; después, el peldaño más bajo que resuelve —una regla en código antes que un flujo, un flujo antes que un agente—.
Cuándo no
Cuando la actividad todavía está en discusión o cambia cada semana: automatizarla congela la discusión dentro de una herramienta.
Por qué
Evidencia
En Ceinfes la programación de profesores y consultores para más de 100 colegios al año, que se hacía a mano en Google Calendar, no necesitó un sistema: necesitó una macro en VBA que la optimizara con las restricciones escritas —disponibilidad, competencia, ubicación y ventana de cada colegio—.
Estado del campo
La guía HEAT de Microsoft parte de que no todo proceso puede automatizarse: propone escoger cada automatización por su retorno esperado y usar la minería de procesos para descubrir cuál automatizar.^[5]
RPA solo donde no hay otra puerta
Cuándo sí
Cuando el sistema no ofrece API ni conector, la pantalla es estable y las reglas se pueden escribir: un robot repite el trabajo sobre la interfaz.
Cuándo no
Cuando existe una API o un conector, o la pantalla cambia con frecuencia: la automatización por interfaz se rompe con cada rediseño.
Por qué
Estado del campo
Los flujos de escritorio amplían la automatización robótica de procesos (RPA) de Power Automate: automatizan tareas repetitivas basadas en reglas sobre aplicaciones modernas y heredadas.^[7]
Criterio
Un robot sobre la interfaz dura lo que dura la pantalla: necesita dueño y fecha de revisión desde el primer día.
Flujos deterministas para lo que debe salir igual, agentes para lo que hay que interpretar
Cuándo sí
Cuando la misma entrada debe producir siempre la misma salida —una aprobación, una carga, una notificación—, el paso es un flujo; el agente entra solo en el paso que exige interpretar lenguaje, recuperar conocimiento o elegir entre opciones.
Cuándo no
Cuando se pone un agente a ejecutar un paso que una regla fija resuelve: se gana variabilidad y se pierde la trazabilidad de la regla.
Por qué
Estado del campo
En Copilot Studio los flujos de agente son deterministas: siguen un camino basado en reglas, y la misma entrada produce siempre la misma salida.^[9]
Evidencia
En Vesting n8n fue una base fundamental para la automatización de los flujos de los agentes, no la arquitectura completa: el valor estaba en definir qué información entraba, qué transformación ocurría, qué resultado se esperaba y cómo se manejaba una excepción.
Control humano por tipo de decisión
Cuándo sí
Cuando una decisión tiene consecuencias que no se pueden revertir o su error cuesta caro: la automatización informa o recomienda, y una persona aprueba.
Cuándo no
Cuando la acción se puede verificar y revertir, y aprobar cada caso volvería a la persona el cuello de botella.
Por qué
Evidencia
En los 11 agentes del portafolio los límites de cada uno y lo que «nunca» hace están escritos en su ficha técnica, y el Constructor de Tableros Power BI tiene 5 gates de aprobación humana: ninguna corrida cierra sin que una persona apruebe el resultado.
Estado del campo
Copilot Studio separa tres capas de control: la determinista para las acciones críticas o irreversibles, una intermedia con puntos de aprobación para el riesgo medio y la generativa para lo de bajo riesgo, con límites de decisión explícitos.^[11]
Medir la automatización contra la línea base del proceso
Cuándo sí
Siempre que una automatización sale a operar: se compara con el proceso que reemplaza —tiempo de ciclo, retrabajo, errores, trabajo manual que queda— y no con su demostración.
Cuándo no
Cuando no hay línea base: primero se mide el proceso y después se automatiza.
Por qué
Evidencia
En Cafam, la exactitud de registro de inventario se medía antes y después de las pruebas de implementación del WMS, y las aplicaciones en VBA que reemplazaron cargas manuales subieron un 15 % la automatización y contribuyeron a bajar un 50 % los errores de datos.
Estado del campo
En el modelo de madurez de automatización de Microsoft, desde el primer nivel se fijan indicadores para medir los beneficios de la automatización y su efecto en las métricas operativas.^[6]

Bloque 5

Lo innovador en 2026

Estado del campo
La minería de procesos centrada en objetos
Qué cambia frente a la práctica común
Un registro de eventos ya no supone un solo caso por proceso: OCEL 2.0 registra eventos que tocan varios objetos a la vez, los cambios de esos objetos y sus relaciones calificadas, con tres formatos de intercambio —SQLite, XML y JSON—, y Power Automate documenta cómo preparar un registro centrado en objetos —un CSV en Azure Data Lake u OneLake, o una tabla delta en un Lakehouse de Fabric— para ingerirlo en su minería de procesos.^[2]^[3]
Criterio
La minería de procesos muestra lo que se ejecutó, no lo que debería ejecutarse: el modelo acordado sigue haciendo falta para saber cuál de los dos se corrige.
Estado del campo
La minería de procesos para descubrir qué automatizar
Qué cambia frente a la práctica común
La minería de procesos de Power Automate usa los registros de eventos del sistema de origen para dibujar el proceso real con datos y métricas; entre sus usos declara ver los pasos reales, detectar procesos no conformes y descubrir oportunidades de automatización, y la minería de tareas mira lo que ocurre en el escritorio.^[4]
Estado del campo
Agentes que usan el computador frente a la RPA
Qué cambia frente a la práctica común
La RPA sigue reglas predefinidas sobre el árbol de la interfaz; un agente que usa el computador ve la pantalla, razona y se corrige. Microsoft recomienda la RPA cuando la interfaz es estable, las reglas son claras y el volumen es alto, y el agente cuando las interfaces cambian o la decisión es difusa.^[8]
Criterio
Un agente que usa el computador no reemplaza la pregunta de fondo: si existe una API, la interfaz sigue siendo la puerta equivocada.
Estado del campo
Del proceso a un flujo que llama agentes
Qué cambia frente a la práctica común
Cuando un proceso exige orden estricto, reglas de negocio y auditoría, puede ser apropiado encadenar los agentes en un flujo con una secuencia predefinida: cada paso con precondiciones, poscondiciones y umbrales, y compuertas de aprobación humana.^[10]
Criterio
Un diagrama aprobado es la mejor primera especificación de esa secuencia, siempre que cada actividad declare qué recibe, qué hace y qué entrega.
Estado del campo
Los principios de diseño de una automatización
Qué cambia frente a la práctica común
La guía HEAT de Microsoft pone entre los principios de diseño de una automatización el registro, la gestión de credenciales y las pruebas, la estrategia de manejo de errores y reintentos, y la elección entre API e interfaz.^[5]

Bloque 6

Modos de falla y cómo anticiparlos

Qué se rompe
Automatizar un proceso malo
Cómo se ve venir
La automatización repite más rápido los reprocesos y las excepciones que ya existían.
Control que la atrapa
Ninguna automatización sobre un proceso sin acordar y sin contrastar lo formal con lo ejecutado.
Qué se rompe
Optimizar fuera de la restricción
Cómo se ve venir
Una estación va más rápido, la cola crece en la siguiente y el tiempo total no cambia.
Control que la atrapa
Medir el flujo completo y automatizar primero donde está la restricción.
Qué se rompe
El robot que se rompe con la pantalla
Cómo se ve venir
Una RPA falla después de un cambio de interfaz que nadie avisó.
Control que la atrapa
API o conector cuando existen; la RPA con dueño, fecha de revisión y alerta de fallo.
Qué se rompe
Un agente donde bastaba una regla
Cómo se ve venir
La misma entrada produce salidas distintas en un paso que tenía una regla fija.
Control que la atrapa
Flujo determinista para lo que debe salir igual; el agente solo en el paso que exige interpretar.
Qué se rompe
Una automatización sin dueño
Cómo se ve venir
Un flujo corre y nadie sabe qué actividad cubre ni qué pasa si deja de correr.
Control que la atrapa
Cada automatización con dueño, límite y la actividad que cubre, escritos.
Qué se rompe
Un ahorro sin línea base
Cómo se ve venir
Se anuncia un ahorro que nadie puede comparar con el proceso de antes.
Control que la atrapa
La línea base del proceso se mide antes de automatizar.
Qué se rompe
Autonomía antes que confianza
Cómo se ve venir
Un agente ejecuta acciones que nunca se revisaron mientras solo recomendaba.
Control que la atrapa
Autonomía gradual: informar, después recomendar y, con evidencia, ejecutar.
Qué se rompe
Excepciones que nadie ve
Cómo se ve venir
El flujo marca éxito y el caso quedó a medias.
Control que la atrapa
Los eventos de cada ejecución van a una plataforma aparte de la que ejecuta.

Bloque 7

Métricas y controles

Qué se mide
Tiempo de ciclo del proceso
Umbral
Menor que la línea base, medido en el flujo completo y no en una actividad.
Quién aprueba el paso a producción
El dueño del proceso.
Qué se mide
Trabajo manual que queda
Umbral
Medido por actividad y comparado con la línea base.
Quién aprueba el paso a producción
El dueño del proceso.
Qué se mide
Errores de datos y retrabajo
Umbral
Por debajo de la línea base, con cada excepción registrada.
Quién aprueba el paso a producción
Quien opera el proceso.
Qué se mide
Excepciones de alto impacto resueltas por una persona
Umbral
Todas.
Quién aprueba el paso a producción
El dueño del proceso.
Qué se mide
Automatizaciones con dueño y límite escritos
Umbral
Todas, antes de operar.
Quién aprueba el paso a producción
Quien administra las automatizaciones.
Qué se mide
Divergencias entre lo modelado y lo ejecutado
Umbral
Revisadas en cada ciclo; ninguna sin decidir si cambia el proceso o el modelo.
Quién aprueba el paso a producción
El dueño del proceso.
Qué se mide
Acciones ejecutadas sin aprobación
Umbral
Solo las que se pueden verificar y revertir.
Quién aprueba el paso a producción
El dueño del proceso, con riesgo.

Los umbrales son ejemplos del método, no cifras de un proyecto concreto.

Bloque 8

Evidencia en proyectos

EvidenciaNivel: Uso real
El BPMN antes de la tecnología, en cuatro empleos
En cuatro empleos el proceso se modeló en BPMN con Bizagi antes de tocar la tecnología: en Inglopres, la operación de alquiler de maquinaria antes de implantar el ERP; en Ceinfes, la cadena de programación, material, aplicación y digitalización; en Cafam, recepción, almacenamiento, alistamiento y despacho, contrastados con el WMS antes de probarlo; y en Banco Pichincha, los productos analíticos situados en las decisiones que debían respaldar.
Ver dónde
EvidenciaNivel: Uso real
Inglopres: el estudio de tiempos con suplementos de la OIT
En Inglopres, en 2016, el estudio de tiempos cronometró las operaciones, valoró el ritmo de quien las ejecutaba, calculó el tiempo estándar y le aplicó suplementos por fatiga de la tabla de la OIT: un tiempo observado no es un estándar hasta que reconoce el esfuerzo de quien lo ejecuta.
Ver dónde
EvidenciaNivel: Uso real
Ceinfes: la digitalización balanceada como una línea
En Ceinfes, en 2018, la digitalización de unas 250 hojas por jornada se trató como una línea de estaciones —2 de escaneo, más alistamiento, organización, validación y reordenamiento—; cerca del 10 % de las hojas exigía captura manual, y esa estación fijaba el ritmo de toda la línea.
Ver dónde
EvidenciaNivel: Uso real
Cafam: herramientas en VBA con dueño y con límite
En Cafam, en 2020, lo que el WMS no cubría en el centro de distribución se resolvió con herramientas en VBA que lo complementaban —disponibles, útiles y mantenibles en esa organización— y no con una plataforma nueva: subieron un 15 % la automatización, contribuyeron a bajar un 50 % los errores de datos y siguieron corriendo después de la salida a producción, como piezas con dueño y con límite.
Ver dónde
EvidenciaNivel: Uso real
Ceinfes: Kanban para las solicitudes, Scrum para los proyectos
Entre noviembre de 2017 y noviembre de 2018, en Ceinfes, Kanban se usó para el flujo de solicitudes del área de tecnología —cada tarjeta, una solicitud visible con su estado y su responsable— y Scrum para los proyectos tecnológicos, durante la transición a un modelo de gestión por procesos apoyado en sistemas de información.
Ver dónde
EvidenciaNivel: Uso real
Vesting: el proceso core de once etapas, sobre n8n
Entre agosto de 2023 y enero de 2025, en Vesting, el proceso core de once etapas —del caso de uso a la operación observable— sirvió de marco para construir los 27 agentes del inventario, con n8n como base de automatización y sus eventos en Microsoft Fabric.
Ver dónde
EvidenciaNivel: Uso real
El portafolio: el BPMN que se genera solo
En el portafolio, el diagrama BPMN de cada pieza se genera desde la definición de su proceso con un motor propio y se valida en el build: si la definición cambia, el diagrama cambia con ella, y si está malformada, la publicación falla antes de salir.
Ver dónde
EvidenciaNivel: Prototipo
FORJA: del BPMN a una orquestación de agentes
FORJA, una de las investigaciones del autor, propone abrir cada actividad del BPMN con entradas, función y salidas, y su compilador convierte el diagrama en una orquestación de agentes donde cada elemento traza a su realización; el paso del BPMN a la orquestación se desarrolla en la publicación sobre sistemas de agentes.
Ver dónde

Bloque 9

Límites y alcance

Evidencia
La minería de procesos sobre un registro de eventos real es un método que se aplicaría, no un caso corrido en una empresa; lo más cercano fue Vesting, donde cada uno de los 27 agentes dejaba su rastro de eventos y el proceso core definía lo que debía ocurrir.
Evidencia
Los detalles internos de la arquitectura de Vesting, sus componentes propios y la secuencia exacta de implementación son conocimiento confidencial de la organización: la pieza cita las etapas y la disciplina, no los mecanismos.
Evidencia
En la Fundación CTIC se ha trabajado con n8n y con el ecosistema de LangChain, pero el corpus no nombra un entregable hecho con ellos: la base de automatización documentada es la de Vesting.
Evidencia
FORJA tiene su demostrador —compilador, cinco procesos, línea base y compuertas de aprobación—, pero que los profesionales lo usen se demuestra con profesionales, no con el prototipo.
Criterio
La escalera nombra peldaños que esta pieza trata solo como estado del campo —la RPA, los flujos low-code y los agentes que usan el computador—: la experiencia que se afirma es la del bloque 8, con el nivel que el corpus le da.
Criterio
Lo que conviene hacer distinto hoy: medir la línea base del proceso antes de la primera automatización, no cuando alguien pregunta cuánto se ahorró.
Criterio
Automatizar un proceso que nadie ha acordado convierte un desacuerdo en código.

Bloque 10

Fuentes y fecha de revisión

Revisado el 21 de octubre de 2026

[1]
ISO/IEC 19510:2013 Information technology - Object Management Group Business Process Model and Notation
IEC Webstore (ISO/IEC JTC 1) · 15 de julio de 2013
https://webstore.iec.ch/publication/10695
[2]
OCEL (Object-Centric Event Log) 2.0 Specification
arXiv · 4 de marzo de 2024
https://arxiv.org/abs/2403.01975
[3]
Create an object-centric event log
Microsoft Learn · 17 de agosto de 2026
https://learn.microsoft.com/en-us/power-automate/object-centric-create-event-log
[4]
Overview of process mining and task mining in Power Automate
Microsoft Learn · 28 de agosto de 2026
https://learn.microsoft.com/en-us/power-automate/process-advisor-overview
[5]
Holistic enterprise automation techniques (HEAT)
Microsoft Learn · 28 de septiembre de 2022
https://learn.microsoft.com/en-us/power-automate/guidance/automation-coe/heat
[6]
Microsoft Power Platform automation maturity model overview
Microsoft Learn · 1 de julio de 2024
https://learn.microsoft.com/en-us/power-automate/guidance/automation-coe/automation-maturity-model-overview
[7]
Introduction to desktop flows
Microsoft Learn · 23 de agosto de 2026
https://learn.microsoft.com/en-us/power-automate/desktop-flows/introduction
[8]
Use agent tools to extend, automate, and enhance your agents
Microsoft Learn · 5 de octubre de 2026
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/agent-tools
[9]
Agent flows overview
Microsoft Learn · 18 de junio de 2026
https://learn.microsoft.com/en-us/microsoft-copilot-studio/flows-overview
[10]
Workflow-oriented multi-agent patterns
Microsoft Learn · 3 de febrero de 2026
https://learn.microsoft.com/en-us/agents/architecture/multi-agent-workflow-oriented
[11]
Apply generative orchestration capabilities
Microsoft Learn · 18 de septiembre de 2026
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration

Síntesis en tres líneas

Del proceso acordado a la operación inteligente, peldaño por peldaño

Leyenda de formas y colores

Lectura del mapa, nodo por nodo

Conexiones

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

Entradas

Actividades

Artefactos

El BPMN antes que la herramienta

Por qué

Cómo se decide qué automatizar y con qué herramienta: la intervención más sencilla que produce el resultado

Por qué

RPA solo donde no hay otra puerta

Por qué

Flujos deterministas para lo que debe salir igual, agentes para lo que hay que interpretar

Por qué

Control humano por tipo de decisión

Por qué

Medir la automatización contra la línea base del proceso

Por qué

La minería de procesos centrada en objetos

La minería de procesos para descubrir qué automatizar

Agentes que usan el computador frente a la RPA

Del proceso a un flujo que llama agentes

Los principios de diseño de una automatización

El BPMN antes de la tecnología, en cuatro empleos

Inglopres: el estudio de tiempos con suplementos de la OIT

Ceinfes: la digitalización balanceada como una línea

Cafam: herramientas en VBA con dueño y con límite

Ceinfes: Kanban para las solicitudes, Scrum para los proyectos

Vesting: el proceso core de once etapas, sobre n8n

El portafolio: el BPMN que se genera solo

FORJA: del BPMN a una orquestación de agentes