EAFLOW · CASO · FINTECH
Capa de procesos gobernada sobre el grafo, en convivencia con la herramienta legacy
Una organización líder de tecnología financiera y medios de pago, con operación en Chile, validó Process Knowledge en convivencia con su herramienta BPA enterprise: la herramienta legacy se mantiene como fuente de edición y EAFlow agrega una capa superior de publicación, documentación oficial conectada y consulta estructural sobre el Operational Graph —navegación, reportería y trazabilidad— sin migrar el repositorio.
La validación mostró que la solución funciona sobre la operación real del cliente y el valor que aporta: el corpus de procesos publicado como capa navegable y conectado al Operational Graph, con la documentación oficial vinculada al proceso y la consulta estructural disponible para el resto de la organización, sin tocar el método de modelado existente.
El desafío
Las organizaciones de tecnología financiera y medios de pago que operan su práctica de procesos sobre una herramienta BPA enterprise legacy enfrentan el mismo patrón. El problema no es la calidad de los modelos: es que el corpus vive aislado del resto de la operación, encerrado en el modelador.
- El método de modelado actual sigue siendo válido: el equipo de arquitectura de procesos modela con confianza en su herramienta legacy, y la curaduría existente es un activo. Reemplazar la edición no es la prioridad —ni necesariamente deseable.
- El repositorio de procesos está bien modelado, pero no se conecta a las aplicaciones que lo soportan, a los datos que produce, a los documentos que lo respaldan ni a los responsables operativos. El conocimiento queda encerrado en la herramienta de modelado.
- La herramienta BPA legacy es potente para modelar, pero la publicación gobernada para el resto de la organización, la conexión a la documentación oficial y la consulta estructural cruzada quedan cortas o requieren exportaciones manuales.
- La documentación oficial —SOPs, instructivos, políticas y procedimientos— vive en repositorios paralelos, sin trazabilidad bidireccional con el proceso que la usa.
- Reemplazar de golpe es riesgoso y muchas veces innecesario: migrar todo el corpus a una plataforma nueva es proyecto largo y de alto riesgo, y cuando el método actual funciona, el reemplazo total no es la mejor primera decisión.
- No siempre se quiere —o se puede— incorporar IA desde el inicio: por gobierno de datos, madurez o política interna, la organización puede preferir una capa de publicación y consulta en una primera fase, dejando la consulta en lenguaje natural para más adelante.
El conocimiento de procesos no se sostiene con un modelador aislado. Se sostiene con procesos publicados, conectados al grafo, con su documentación vinculada y consultables por el resto de la organización.
La solución EAFlow
Process Knowledge es una solución transversal del área Modernización de Procesos y Arquitectura, construida sobre la capa común Operational Graph de EAFlow Platform, operando en convivencia con la herramienta BPA enterprise del cliente —que se mantiene como fuente de edición. La validación cubrió, sobre el corpus de procesos de la operación del cliente, el escenario de convivencia gobernada como capa superior:
- La herramienta BPA legacy se mantiene como fuente de edición. El equipo de arquitectura de procesos continúa modelando en su herramienta actual; el método y la curaduría existentes no se tocan. EAFlow no reemplaza la edición.
- Capa superior de publicación gobernada sobre el grafo. Los procesos publicados desde la herramienta legacy quedan disponibles como una capa superior consultable y navegable: cadena de valor, niveles de descomposición, proceso y tareas, con versión vigente y trazabilidad.
- Documentación oficial conectada al proceso. SOPs, instructivos, políticas, procedimientos y evidencias del repositorio documental oficial se vinculan al proceso publicado, al rol responsable y al control aplicable, sin migrar archivos.
- Sincronización gobernada con la fuente de edición legacy. Lo que se edita en la herramienta BPA legacy se sincroniza a la capa superior de EAFlow de forma gobernada: la herramienta legacy mantiene la autoría, EAFlow mantiene la publicación, la conexión y la consulta estructural, con trazabilidad de origen y versión.
- Operational Graph como destino de la capa de convivencia. Procesos publicados, tareas, roles, aplicaciones, datos, documentos y relaciones quedan conectados como entidades de primera clase, con cita a fuente y trazabilidad a nivel de evento.
- Soporte analítico y determinístico. La navegación del grafo, la consulta estructural —por cadena de valor, por nivel, por rol, por aplicación, por documento vinculado— y la reportería sobre la estructura del repositorio operan de forma determinística, rompiendo el aislamiento del repositorio respecto del resto de la operación.
La convivencia es gobernada, no automática: la autoría permanece en la herramienta legacy y la sincronización hacia la capa superior queda con reglas de publicación claras y trazabilidad. El nivel real de integración con la herramienta legacy se valida por madurez y validación técnica en discovery (API de la herramienta o exportación gobernada). La base queda lista para incorporar consulta en lenguaje natural como evolución posterior, sin que esa capacidad forme parte de lo validado en esta experiencia.
Qué se validó
La experiencia se ejecutó sobre el corpus de procesos de la herramienta BPA enterprise de la operación del cliente, en continuidad con un trabajo de convivencia previo. El equipo de arquitectura recorrió la capa de convivencia completa: sincronización gobernada desde la herramienta legacy hacia la capa superior, publicación de la cadena de valor y la jerarquía de descomposición como capa navegable, conexión de la documentación oficial al proceso sin migrar archivos, y vinculación de los procesos a aplicaciones, datos y responsables del grafo cuando esos corpus estaban disponibles. La navegación, la consulta estructural y la reportería sobre la estructura del repositorio funcionaron de forma determinística sobre el grafo, con trazabilidad de la versión publicada y del origen de cada sincronización.
Capacidades demostradas
- Operational Graph como base común de contexto.
- Convivencia gobernada con la herramienta BPA legacy como fuente de edición.
- Sincronización gobernada hacia la capa superior, con trazabilidad de origen y versión.
- Cadena de valor y jerarquía de descomposición publicadas como capa navegable.
- Documentación oficial conectada al proceso publicado, sin migrar archivos.
- Procesos conectados a aplicaciones, datos y responsables cuando esos corpus están disponibles.
- Navegación del grafo y consulta estructural (cadena de valor, nivel, rol, aplicación, documento), determinísticas.
- Reportería sobre la estructura del repositorio (cobertura de publicación, procesos sin documentación, procesos sin responsable).
Resultado observado
El corpus de procesos pasó de "estar encerrado en el modelador" a estar publicado como capa navegable y conectado al grafo, con la documentación oficial vinculada al proceso y la consulta estructural disponible para el resto de la organización —algo que el método previo solo resolvía con exportaciones manuales—. La herramienta BPA legacy siguió siendo la fuente de edición durante toda la experiencia, sin interrumpir el método del equipo.
La validación confirmó que la solución sostiene la capa de convivencia gobernada sobre la operación real del cliente, dejando la decisión de ruta evolutiva —ampliar la cobertura del corpus publicado, incorporar consulta en lenguaje natural sobre el corpus ya conectado o evaluar a futuro un reemplazo del BPA enterprise legacy hacia BPMN 2.0 portable— en manos del equipo de arquitectura, con la convivencia ejecutada como evidencia y no como decisión forzada.
Por qué importa para otras organizaciones
El patrón se repite en organizaciones de tecnología financiera y medios de pago con años de inversión en una herramienta BPA enterprise: el método de modelado sigue siendo válido, el repositorio vive aislado de la operación y reemplazar de golpe se percibe como riesgoso e innecesario. Demostrar, sobre la operación del cliente, que un corpus de procesos puede publicarse como capa navegable, conectarse a su documentación oficial y volverse consultable por el resto de la organización sin tocar la fuente de edición convierte una decisión de "todo o nada" en una decisión informada por evidencia.
Empezar por el conocimiento de procesos es además una puerta de entrada de bajo riesgo: el mismo Operational Graph que sostiene la capa de procesos en convivencia sostiene después arquitectura, inventario, documentos, riesgo y operación.
Cómo escala — soluciones relacionadas
El corpus de procesos publicado se reutiliza sobre el mismo Operational Graph:
- Hacia el inventario de aplicaciones Inventario Vivo TI
Las aplicaciones que soportan los procesos publicados se conectan al portafolio TI con owners, criticidad, dependencias e integraciones.
- Hacia gobierno de arquitectura Gobierno de Arquitectura Empresarial
El corpus de procesos pasa a ser base del repositorio vivo de arquitectura, con metamodelo, trazabilidad y gobierno por dominio.
- Hacia documentos vivos Document Governance & Evidence
La documentación oficial conectada al proceso entra en gobierno documental completo, con versión, aprobación y evidencia.
- Hacia riesgo, control y operación Risk & Control Assurance / Operational Graph for Service Operations
Los riesgos y controles asociados a los procesos publicados quedan conectados, y los tickets ganan contexto operacional del proceso.
- Hacia cambios y roadmap Mapa de Impacto y Roadmap de Cambio / Change Impact
Cuando un cambio toca un proceso publicado, el grafo permite estimar el impacto sobre aplicaciones, integraciones, datos y documentos antes de decidir.