Una planilla, una base departamental heredada o un prototipo construido con IA contienen reglas reales y criterios ya probados. Ese trabajo se recupera y se convierte en un proceso con formularios, tareas, responsables, integraciones y un modelo de operación que la organización puede sostener.
01 · El problema
Un área construyó lo que necesitaba: una planilla con las reglas de aprobación, una base local con años de solicitudes, un trámite interno, o un prototipo levantado para probar una idea. Esas piezas resuelven un problema real y contienen criterios que nadie más escribió.
Las reglas de aprobación viven en fórmulas de una planilla de Microsoft Excel que una sola persona sabe leer; el historial está en una base de Microsoft Access sin respaldo declarado; el trámite se reparte entre listas de Microsoft SharePoint y cadenas de correo, con una copia del archivo por persona. El tablero de Microsoft Power BI muestra el atraso acumulado: informa el estado, no reparte el trabajo ni deja constancia de quién autorizó.
El área dueña ya no puede cambiar una regla sin pedir un favor. TI recibe pedidos de soporte sobre algo que no diseñó, sin documentación ni ambiente de prueba, y sin forma de responder por su disponibilidad.
El punto de partida no es un error. Es un límite: lo que dejó de escalar no son las reglas, sino la operación que las rodea.
02 · La solución
El trabajo empieza por recuperar lo que ya funciona: qué campos se completan, qué valida cada uno, qué condiciones disparan una aprobación y qué excepciones se resuelven a mano. Ese contenido se ordena junto al equipo que lo usa y se contrasta con los casos históricos de la aplicación. Nada se traslada por sí solo: una regla que nadie logra explicar se declara como decisión pendiente, no se replica a ciegas.
Sobre esas reglas se rediseña el recorrido: formularios con las validaciones acordadas, tareas con responsable y plazo, autorizaciones por regla y por tramo, y estados que distinguen lo solicitado de lo ejecutado. BPMflow sostiene la ejecución —casos, asignación, plazos, autorizaciones y evidencia—. El contexto del Operational Graph aporta la sociedad, el área, el rol responsable y los documentos aplicables, de modo que las reglas se apoyen en definiciones vigentes y no en una copia dentro del formulario.
Cuando lo que hay que modernizar es un repositorio de modelos de proceso o de arquitectura —diagramas, notaciones heredadas, atributos y relaciones—, el recorrido es otro: Legacy Modernization y Process Knowledge. Cuando el proceso nace de un desvío que hoy solo se ve en un tablero, la entrada es From Reporting to Action.
03 · Situaciones de partida
El punto de partida cambia cuánto se reutiliza al empezar, no el destino. Y no siempre se parte de algo construido: el mismo recorrido sirve para crear una capacidad que todavía no existe, o para sustituir una aplicación heredada cuyo alcance ya se conoce.
Los cálculos y los criterios están en la planilla; el resto ocurre por correo.
Qué se conserva
Los criterios, los cálculos y las categorías que el área ya validó en el uso diario.
Qué cambia
Una sola instancia del caso, con solicitante, revisor y autorizador declarados, y sin copias paralelas que reconciliar.
Formularios, lógica y datos de años, con permisos que crecieron por excepción.
Qué se conserva
Los datos históricos y la lógica que sigue siendo correcta; la aplicación puede seguir operando durante la transición.
Qué cambia
Qué se conserva, qué se adapta y qué se sustituye se decide por alcance, con permisos revisados e integraciones declaradas.
Funciona, pero hoy nadie puede modificarla ni responder por su disponibilidad.
Qué se conserva
Su alcance real: qué resuelve, quién depende de ella y qué ocurre si deja de estar disponible.
Qué cambia
Aparece un responsable de operación y evolución. El alcance se sostiene o se sustituye por decisión explícita, no por abandono.
Ya demuestra la idea; faltan las condiciones para operarlo.
Qué se conserva
El diseño del recorrido, las decisiones de producto y lo aprendido por el equipo durante la prueba.
Qué cambia
Se completan integraciones, permisos, tratamiento de errores, pruebas y modelo de soporte. El prototipo no se descarta.
04 · Capacidades
El área dueña recupera la posibilidad de cambiar una regla por el procedimiento acordado, y TI recibe una aplicación con documentación, permisos y responsables. Max responde sobre el caso dentro del contexto autorizado: muestra el estado, la evidencia registrada y la regla aplicada.
Campos, validaciones, condiciones de aprobación y excepciones se ordenan con el área que las usa y se contrastan con los casos históricos de la propia aplicación.
Formularios con las validaciones acordadas, tareas con responsable y plazo, y estados que distinguen lo solicitado, lo autorizado y lo confirmado.
El proceso toma el contexto que necesita y devuelve el resultado donde debe quedar registrado, con la confirmación acordada para cada paso.
Si un sistema no responde o un dato no valida, el caso queda con un pendiente visible, un responsable y un camino de reintento o de resolución manual.
El alcance nuevo puede operar junto a la aplicación actual, con criterio de corte, pruebas sobre casos del período y plan de vuelta atrás.
Queda declarado quién opera el proceso, quién cambia una regla, cómo se aprueba ese cambio y qué ocurre con los casos en curso.
05 · Roles
Aporta las reglas y decide cuáles siguen vigentes.
Qué ve
El proceso con sus reglas explícitas, los casos en curso y los pendientes de su área.
Qué hace
Explica cómo se resuelve hoy, acuerda qué regla se implementa y pide los cambios posteriores sin depender de una persona.
Conoce el detalle que nunca se documentó.
Qué ve
Las reglas recuperadas y los casos donde el comportamiento actual no coincide con lo declarado.
Qué hace
Corrige la interpretación, aporta el histórico y valida el recorrido contra casos que ya ocurrieron.
Se hace cargo de lo que hoy no puede sostener.
Qué ve
Las integraciones declaradas, los permisos, los ambientes y los pendientes técnicos del alcance.
Qué hace
Acuerda accesos y fuentes autorizadas, participa en las pruebas y recibe el proceso con su documentación y su modelo de soporte.
Ejecuta el trabajo diario.
Qué ve
Sus tareas, el plazo comprometido y qué información falta en cada caso.
Qué hace
Completa el formulario, responde las observaciones y confirma lo que le corresponde.
06 · Implementación
Alcanza con la aplicación que hoy se usa, sus casos recientes y el equipo que la opera: no hace falta un proyecto de arquitectura previo ni documentación completa del proceso.
1 · Acordar alcance y resultado
Qué reglas se conservan tal como están, cuáles se acuerdan de nuevo, quién autoriza y qué cuenta como resultado confirmado.
2 · Recuperar reglas y conectar fuentes
Se ordenan campos, validaciones y excepciones desde la aplicación actual y sus casos históricos, y se acuerdan las fuentes de contexto y el sistema que registra el resultado.
3 · Probar, convivir y transferir
Se prueba con casos del período en curso, se ajustan reglas y plazos, se acuerda el criterio de corte y la operación diaria queda bajo control del equipo del cliente.
Ejemplo ilustrativo
La base tiene el formulario, la numeración, el cálculo del monto y una regla de aprobación por tramo que solo su autor conoce; el correo tiene la autorización. El recorrido rediseñado conserva el formulario y los tramos, los declara como reglas del proceso y los conecta con la sociedad, el centro de costo y el responsable vigentes.
La excepción relevante aparece cuando el monto cambia después de aprobado. El caso no vuelve a empezar. Si el monto corregido cruza un tramo, el caso pasa al autorizador que ese nuevo tramo requiere, y la aprobación anterior y su motivo quedan registrados. La transición mantiene la base en modo de consulta mientras los casos abiertos terminan por el camino anterior. El cierre lo confirma el registro devuelto desde el sistema donde la inversión debe quedar asentada.
El ejemplo describe cómo se plantea un alcance. No corresponde a un despliegue existente.
07 · Escenarios típicos
Un proceso de poco volumen también justifica el recorrido cuando el costo de un error es alto o la operación depende de una sola persona.
Una aplicación departamental queda modernizada cuando sus reglas están explícitas, el proceso tiene responsables y el resultado se confirma donde corresponde. Conviene empezar por un proceso concreto y por la regla que hoy solo una persona puede explicar.
Departmental Application Modernization es una solución transversal de EAFlow sobre el Operational Graph, sostenida por las capacidades de automatización de BPMflow. Legacy Modernization y Process Knowledge cubren los repositorios de modelos; From Reporting to Action cubre el desvío detectado en un tablero. Los ejemplos de esta página son ilustrativos.
