En las personas
Quien lleva años en un proceso sabe por qué cada excepción existe. Ese saber no está escrito en ninguna parte.
Caso de estudio · Sector público
Sistema de Inteligencia de Procesos
De levantamientos BPMN aislados a una arquitectura integrada de procesos, datos, trazabilidad y capacidades analíticas futuras.
El desafío
El conocimiento existía. Repartido.
Un departamento que administra beneficios estudiantiles de educación superior opera sobre procesos largos, regulados y con muchos actores. Ese conocimiento existe —y funciona— pero vive distribuido.
En los documentos
Procedimientos, minutas y actos administrativos que describen partes del proceso, sin una vista que los una.
En las planillas
Reglas operacionales reales viviendo en hojas de cálculo, fuera de todo control de versiones.
En los sistemas
Datos correctos en cada sistema, sin un contrato común que permita cruzarlos con confianza.
Mientras el conocimiento está repartido, cada mejora exige volver a levantarlo. El problema no era falta de información: era falta de arquitectura.
Mi rol
Coordinación general, y arquitectura
Como Coordinador General del Departamento de Financiamiento Estudiantil, el encargo evolucionó desde levantar y diagramar procesos hacia estructurar una arquitectura que se pudiera gobernar.
Levantamiento end-to-end
Articulación de los procesos de beneficios estudiantiles, desde la postulación hasta la asignación, integrando áreas funcionales, de datos, tecnología y gestión.
Coordinación de equipo
Conducción de un equipo transversal y su distribución temática, articulando owners funcionales, técnicos, jurídicos y de gestión en torno a una visión común.
Contrato de datos
Un requerimiento maestro que traduce necesidades de proceso en datasets, campos, llaves, granos e historia, con mapeo source-to-target validado con las áreas técnicas.
Gobernanza y QA
Criterios de control de versiones y no regresión para sostener la consistencia entre procesos, documentación, matrices y modelos de datos a lo largo del tiempo.
El método
Simple primero, complejo después
El principio que ordena el trabajo. Una arquitectura que nadie puede validar no es una arquitectura: es una hipótesis cara.
01
Unidad mínima de análisis
Definir cuál es la pieza más pequeña que tiene sentido levantar completa, en vez de intentar el mapa entero de una vez.
02
Modelamiento BPMN 2.0
El proceso dibujado con una regla de modularidad explícita, para que cada diagrama se pueda leer y mantener por separado.
03
Paquete por proceso
Cada proceso entrega el mismo conjunto: documentación institucional, diagrama editable, matriz operacional y requerimiento de datos.
04
Validación con los owners
Los dueños del proceso validan; no rehacen. Si validar cuesta tanto como levantar, el entregable está mal diseñado.
05
No regresión
Cambios aditivos y control de versiones, para que una mejora no rompa en silencio lo que ya estaba validado.
Líneas de trabajo
Dónde se aplicó
Asignación de beneficios
El proceso que decide y comunica resultados. Trazabilidad de reglas, criterios y estados, para que una decisión pueda explicarse y reconstruirse.
Beca Vocación de Profesor
Robustecimiento del proceso: formalización de su ciclo completo y de la trazabilidad de sus hitos, con articulación entre las áreas funcionales, jurídicas y de gestión.
Requerimiento maestro de datos
La traducción entre lo que el proceso necesita saber y lo que los sistemas pueden entregar, escrita como contrato y no como conversación.
Cronograma operacional
El calendario como fuente de tareas, responsables y dependencias, reconciliable con el mapa de procesos en vez de vivir aparte.
Resultado
Capacidad instalada
El resultado se describe como capacidad, no como métrica. Las cifras de un proceso público dependen de su versión, su corte y su contexto, y publicarlas sin ese marco sería engañoso.
Procesos documentados end-to-end
Con sus reglas, hitos, responsables e interfaces en un formato común y mantenible.
Trazabilidad
Consistencia verificable entre diagrama, documentación, matriz y modelo de datos, sostenida por control de versiones.
Contrato de datos
Necesidades de proceso expresadas en granos, llaves, historia y mapeo source-to-target.
Base para lo que viene
Preparación funcional para event logs, process mining y una futura Control Tower. Esto es diseño, no implementación productiva, y la distinción es parte del trabajo.
Lo transferible
Qué de esto sirve fuera del sector público
Casi todo. El sector cambia el vocabulario y la regulación; el problema de fondo es el mismo en una empresa con ERP, CRM y ecommerce.
Exhaustividad no es usabilidad
Un modelo completo que nadie puede validar rinde menos que uno acotado que los owners sí revisan.
No automatizar sobre semántica incierta
Si dos áreas entienden distinto el mismo campo, automatizar multiplica el desacuerdo en vez de resolverlo.
Un dashboard no reemplaza la arquitectura
El tablero es la última capa. Cuando se construye primero, se termina rehaciéndolo cada vez que cambia el proceso.
La documentación debe ser gobernable
Si mantenerla al día depende de la voluntad de alguien, envejece. Necesita reglas de cambio.
La tesis que resume la etapa: transformar operación compleja en arquitectura comprensible, trazable y medible, conectando procesos, datos y decisiones.
¿Conversamos?
Si algo de esto se parece a lo que necesitas resolver, escríbeme y lo vemos.