Ordenar el trabajo
Un tablero que refleje la realidad, PO que diseñan requerimientos completos con ayuda de IA y entregas que se cierran con la firma del usuario.
Para el negocio: saber qué se está haciendo, cuándo sale y a quién pedirle cuentas.
Un Dynamics en movimiento
Plan de Soluciones e Innovación Tecnológica para Grupo Zuma. Dynamics 365 como núcleo transaccional, un hub por el que pasan todas las aplicaciones de las áreas y agentes de IA trabajando junto al equipo.
- 18 dic 2026Diagnóstico profundo y caso de negocio de Ubiqua
- 31 mar 2027Hub v1 en producción y proceso estándar
- 30 abr 2027Decisión sobre Ubiqua con datos reales
- 30 jun 2027Piloto de app de ventas sobre el hub
- 15 dic 2027Informe anual y plan 2028
ResumenEl plan en un minuto
Tres movimientos para que tecnología impulse el negocio
Zuma ya tiene las herramientas correctas: Dynamics 365, Microsoft 365, Azure y un equipo que conoce el negocio. Lo que falta es ordenar cómo se trabaja, conectar bien los sistemas y sumar inteligencia artificial. Este plan hace las tres cosas, en ese orden.
Conectar los sistemas
Un hub por el que pasen todas las aplicaciones antes de llegar a Dynamics, con las reglas del negocio escritas una sola vez.
Para el negocio: vender combos y promociones, inventario confiable en todas las apps y menos errores en pedidos.
Sumar inteligencia artificial
Agentes que revisan requerimientos, ayudan a programar y probar, y responden consultas sobre Dynamics.
Para el negocio: hacer más con el mismo equipo y depender menos de una sola persona.
Cómo leerlo
Cada sección tiene un recuadro con dos lecturas: «En palabras simples», para cualquier persona de Zuma, y «Para el equipo técnico», con el detalle de cómo se hace. Al final hay un glosario con todos los términos técnicos.
KM 0Punto de partida
El equipo resuelve, pero el tablero no refleja el trabajo real
Felipe y Cristopher sostienen Dynamics y Ubiqua en modo reactivo. Solo 8 de sus 71 items están en el sprint actual y lo que espera revisión del PO lleva hasta 9 meses. Datos de Azure DevOps al 16 de octubre de 2026.
Antigüedad del trabajo abierto
71 items según días desde su último cambio
Estado por desarrollador
Items abiertos asignados a cada uno
Los sistemas hoy
| Sistema | Estado | Tecnología | Hallazgo clave |
|---|---|---|---|
| Dynamics 365 F&O | 10.0.49 desde el 18 oct; proyecto LCS «ZUMA»; entidad Tohilgua | X++ en Visual Studio, Azure Repos, CI desde master, despliegue por LCS | Un solo desarrollador X++ y una sola rama. Paquetes urgentes desde la máquina de desarrollo. El caso Walmart falló tras una actualización de Microsoft. |
| Ubiqua | App de ventas en producción, integración sin terminar | Producto de terceros, conectado por servicios | Sin combos ni atados, no respeta múltiplos de 4, jala todo el inventario cada 30 minutos, conciliación sin validar. |
| Zumadores | App anterior, en salida | Ionic Angular, Django, Postgres; panel en AWS Amplify | Sí resolvía combos y múltiplos. Despliegue automático desde master con ambientes de prueba. |
| Power Platform | Flujos en construcción | Microsoft Forms, Power Automate, Approvals de Teams | Solicitudes de viaje y compras con tarjeta; sin estándar de ambientes. |
| Azure DevOps | Solo Boards en Equipo_IT | Proceso personalizado en español | Varias áreas comparten el proyecto y mezclan métricas; 0 items con prioridad o estimación. |
| Infraestructura | Microsoft 365, Entra ID, Azure y AWS | Dos nubes | Dos nubes para un equipo de dos desarrolladores; máquinas virtuales viejas por depurar. |
Lo que el propio equipo validó en el kickoff
Requerimientos sin herramientas
Las necesidades llegan por correo o mensaje y se registran como llegan: nadie le ha dado a proyectos una plantilla ni el tiempo para diseñarlas.
Entregas sin cierre
No hay acta ni traspaso a soporte; «terminado» significa que pasaron pruebas pequeñas.
Procesos sin documentar
Ni funcionales ni técnicos. Cada usuario opera el ERP a su manera, y tesorería tomó tres meses.
Conocimiento concentrado
El ERP depende de Felipe, Edric e Ismael; parte se perdió desde la implementación.
En palabras simples
Azure DevOps es el tablero donde el equipo anota cada tarea. Imagina un tablero de pedidos en bodega donde la mayoría siguen marcados como pendientes aunque muchos ya salieron: nadie sabe con certeza qué falta.
Eso pasa hoy. El trabajo sí se hace, pero el tablero no se actualiza, y así es imposible priorizar, prometer fechas o saber si el equipo necesita ayuda. Además, buena parte del tiempo de Cristopher se va en dar soporte a Ubiqua en lugar de construir cosas nuevas.
Para el equipo técnico
- Fuente: consulta de Azure DevOps sobre items asignados a Felipe López y Cristopher Barrios, excluyendo Completado, Closed, Done y Removed; exportada el 16 de octubre.
- Sin cambios: días desde Changed Date. Espera en revisión: días desde State Change Date en «Para Revisión PO».
- Sprint actual: Iteration Path terminado en Q4_Sprint1; 63 items siguen en iteraciones de Q1 a Q3.
- Proceso: plantilla personalizada con tipos Habilitador, Historias de usuario y Tarea; Priority, Tags y Remaining Work vacíos en el 100% de los items.
MapaProceso tecnológico de punta a punta
Siete fricciones entre la solicitud y producción
El cuello de botella no está en el código: está antes, en cómo entra el requerimiento, y después, en la revisión y el cierre. El flujo objetivo corrige cada fricción y pone IA donde más ayuda.
Hoyreactivo
1SolicitudCorreo o mensaje del área
2ProyectosTraslada sin herramientas de diseño
HistoriaEn DevOps, sin prioridad ni estimación
3DesarrolloLevanta el requerimiento con el usuario
4PruebasPruebas pequeñas, ambiente distinto
5Revisión POEspera mediana de 121 a 184 días
6ProducciónPaquete a veces desde la máquina
7SoporteVuelve a desarrollo
Objetivopredecible
IASolicitudPlantilla con problema, usuario y proceso
IAProyectosEl PO diseña el requerimiento con su copiloto
Historia listaCriterios de aceptación, prioridad y estimación
IADesarrolloRama propia, pull request, asistente de código
IAPruebasRSAT y casos generados desde criterios
Revisión POMáximo 5 días, agendada en el sprint
ProducciónSolo desde CI, con ventana acordada
SoporteActa de entrega y traspaso documentado
- Las solicitudes llegan por correo o mensaje y se copian como historia de usuario.
- Proyectos carga con traducir las necesidades de las áreas sin método, plantilla ni apoyo técnico.
- El desarrollador pierde tiempo buscando la causa raíz con el usuario.
- La máquina de desarrollo no reproduce producción (caso Walmart).
- 13 items esperan revisión del PO, el más antiguo 265 días, porque la revisión no tiene un espacio agendado en el sprint.
- Una sola rama y paquetes urgentes que saltan el control de versiones.
- Ubiqua nunca se entregó formalmente a soporte; Cristopher sigue atendiéndola.
En palabras simples
Piensa en el pedido de un cliente: si se toma mal en la venta, por más rápido que trabaje bodega, el despacho sale mal. Con el software pasa igual.
La mayoría de los atrasos no ocurren mientras se programa, sino antes, cuando el pedido de trabajo llega incompleto, y después, cuando nadie revisa ni recibe formalmente lo entregado. El flujo objetivo agrega controles sencillos en cada paso para que lo que entra bien, salga bien, y usa IA para que esos controles no le quiten tiempo a nadie.
Para el equipo técnico
- Definición de listo: ninguna historia entra al sprint sin criterios de aceptación, stakeholder, prioridad y estimación.
- Definición de terminado: código revisado en pull request, desplegado por pipeline, probado en sandbox y aceptado por el usuario con acta.
- Ramas: main protegida, una rama por requerimiento y al menos un revisor por pull request.
- Dynamics: paquetes solo desde el build de CI; las urgencias usan una rama de hotfix con el mismo pipeline.
- Revisión del PO: acuerdo de 5 días hábiles, agendada dentro del sprint.
EquipoProyectos y tecnología, un solo equipo
Los PO se convierten en arquitectos del requerimiento
El equipo de proyectos es el puente entre las áreas y tecnología, y hoy hace ese trabajo sin herramientas. El plan no les suma controles: les da un método y un copiloto de IA para diseñar cada requerimiento, como un arquitecto diseña el plano antes de que empiece la obra.
Hoy: mensajeros entre áreas y tecnología
Mucho esfuerzo, poco reconocimiento
- Reciben la necesidad por correo o mensaje.
- La trasladan como llega, sin tiempo ni plantilla para analizarla.
- Esperan a que desarrollo pregunte lo que falta.
- Validan al final, cuando cambiar ya es caro para todos.
Mañana: arquitectos del requerimiento
Dueños del diseño y del valor que recibe su área
- Descubren el problema real con el usuario, con una guía de preguntas.
- Diseñan la solución con su copiloto: alcance, criterios y datos de prueba.
- Entregan a desarrollo un plano completo y priorizado.
- Validan en cada sprint y miden el valor que llegó al negocio.
Lo que el copiloto hace por el PO
Entrevista guiada
Le sugiere las preguntas para descubrir el problema real detrás de la solicitud.
Resultado: menos idas y vueltas con el usuario.
Borrador de la historia
Convierte las notas de la reunión en una historia de usuario con la plantilla de Zuma.
Resultado: el PO revisa en minutos lo que antes tomaba horas.
Criterios de aceptación
Propone condiciones claras y verificables, en formato dado, cuando, entonces.
Resultado: todos saben desde el inicio qué es «terminado».
Impacto en sistemas
Avisa si el cambio toca Dynamics, Ubiqua o Power Platform, y qué procesos de otras áreas se afectan.
Resultado: sorpresas detectadas antes de programar.
Revisión antes de enviar
Señala lo que falta, sin bloquear. La última palabra siempre la tiene el PO.
Resultado: requerimientos listos a la primera.
Demo y acta de entrega
Prepara la guía de prueba con el usuario y el acta para cerrar formalmente.
Resultado: entregas cerradas y reconocidas.
Ruta de crecimiento del PO
Taller de diseño
Noviembre 2026. Plantilla, ejemplos reales de Zuma y práctica con casos como el combo de guantes.
El PO gana: un método claro y compartido con tecnología.
Práctica con el copiloto
Enero a marzo 2027. Cada requerimiento nuevo se diseña con el agente, con sesiones quincenales junto a desarrollo.
El PO gana: tiempo, porque el copiloto hace el trabajo pesado.
Comunidad de arquitectos
Desde abril 2027. Los PO comparten plantillas y casos, y dominan los procesos de Dynamics de su área.
El PO gana: visibilidad como dueño del valor que entrega su área.
En palabras simples
Un arquitecto no pone ladrillos: diseña el plano para que la obra salga bien a la primera. Eso es lo que hará el PO con cada requerimiento.
Hoy nadie le ha dado el plano ni las herramientas, y aun así sostiene la comunicación entre las áreas y tecnología. El plan le da un método, formación y un copiloto de IA que hace el trabajo pesado de redactar, ordenar y revisar. El PO gana tiempo, reconocimiento y control sobre lo que su área recibe.
Para el equipo técnico
- Copiloto: Copilot Studio con conectores a Azure DevOps para crear y comentar work items en nombre del PO.
- Conocimiento: plantillas por tipo de requerimiento y procesos de Dynamics documentados en las Fases 1 y 2 como base del agente.
- Control: el agente sugiere y el PO aprueba; nada se envía a desarrollo sin su confirmación.
- Métricas: porcentaje de historias listas a la primera, retrabajo por historia y días de la solicitud a listo para desarrollo.
DestinoArquitectura objetivo
Todas las aplicaciones llegan a Dynamics solo a través del hub
Dynamics es el único sistema de registro. La lógica de negocio vive una vez en el hub, así Ubiqua, una app propia o un Power App se comportan igual. Toca cada pieza para ver su papel y en qué fase entra.
En palabras simples
Zuma sabe mejor que nadie cómo funciona un centro de distribución: en lugar de que cada cliente vaya a cada fábrica, todo pasa por un centro que ordena, controla y despacha. El hub es eso, pero para los sistemas.
Hoy cada aplicación (Ubiqua, los flujos de aprobación, las apps de las áreas) se conecta por su cuenta a Dynamics, y cada una aplica sus propias reglas. Con el hub, todas pasan por una sola puerta, las reglas del negocio, como armar un combo o vender de 4 en 4, se escriben una sola vez, y cuando cambia el inventario todas las aplicaciones se enteran al instante.
Para el equipo técnico
- Puerta: Azure API Management con OAuth 2.0 de Entra ID, límites de uso, versionado y bitácora por consumidor.
- Eventos: Business Events de F&O publicados a Service Bus, con tópicos por dominio (inventario, órdenes, precios) y una suscripción por aplicación.
- Lógica: Azure Functions para reglas de dominio, como la disponibilidad de combos desde la lista de materiales y la validación de múltiplos, con caché de disponibilidad.
- Escritura: servicios personalizados y entidades OData para lo transaccional; Data Management Framework para cargas masivas.
- Operación: Application Insights con correlación por pedido e infraestructura como código en Azure Repos.
Aplicaciones periféricas de las áreas consumen, no integran
solo a través del hub, con identidad de Entra ID
Hub de integración en Azure la pieza nueva
OData, servicios personalizados y Data Management Framework
Dynamics 365 F&O
Sistema de registro único: ventas, inventario, bodega y finanzas
consultas controladas, de solo lectura al inicio
Agentes de IA trabajan con el equipo
Así viaja un pedido con combo en la arquitectura objetivo
El caso del atado de guantes con Urol 10W30, hoy bloqueado con 1,000 unidades, resuelto de punta a punta.
- App de ventas
El asesor ve «Combo guantes» con disponibilidad real, solo si su cliente pertenece al segmento de la promoción.
- Hub
Calcula la disponibilidad del combo desde las existencias de sus componentes, actualizada por eventos y no cada 30 minutos.
- Hub
Valida múltiplos y mínimos de venta antes de aceptar el pedido.
- Dynamics
Recibe la orden con el código del combo y explota su lista de materiales en las líneas de garrafa y guante, con el precio del acuerdo.
- Bodega
El picking sale de una ubicación combinada donde la garrafa ya tiene el guante atado, sin doble recorrido.
- Hub
El evento de inventario actualiza la disponibilidad en todas las aplicaciones al mismo tiempo.
IAEscalera de adopción
De preguntarle a un chat a trabajar con agentes
Hoy el equipo usa IA solo como consulta. Cada fase sube un peldaño, empezando por donde más duele: la calidad de los requerimientos, no la generación de código en producción.
Hoy1
Consulta
Preguntas sueltas en un chat, fuera del flujo de trabajo.
Fase 22
Asistentes en el editor
Código, pruebas y documentación asistidos dentro de VS y VS Code.
Fase 23
Copilotos y revisores
Ayudan al PO a diseñar requerimientos y revisan pull requests antes de la revisión humana.
Fase 34
Agentes con herramientas
Consultan Dynamics por MCP en solo lectura y generan pruebas desde los criterios.
Fase 45
Agentes operativos
Ejecutan tareas acotadas con escritura controlada y bitácora completa.
En palabras simples
Un agente de IA es como un asistente que conoce las reglas de trabajo y ayuda con tareas concretas. El primero que proponemos no programa: es un copiloto para los PO, que les ayuda a diseñar cada requerimiento completo antes de que llegue a Felipe o Cristopher.
Después vienen asistentes que ayudan a escribir y probar código, y agentes que consultan Dynamics para responder preguntas de las áreas. Siempre con permisos limitados, con bitácora de todo lo que hacen y con una persona revisando. La IA no reemplaza al equipo: le quita lo repetitivo.
Para el equipo técnico
- Copiloto del PO: Copilot Studio conectado a Azure DevOps; valida campos obligatorios y la calidad de los criterios (formato dado, cuando, entonces) y comenta en el work item.
- Asistentes de código: en VS Code y Visual Studio con el contexto del repositorio; para X++ el foco es documentación, análisis y pruebas.
- MCP de Dynamics 365 ERP: disponible desde la 10.0.44 (Zuma está en 10.0.49); respeta roles y privilegios del usuario en F&O. Arranca en sandbox y en solo lectura.
- Gobierno: identidad de Entra ID, bitácora de cada acción, datos dentro del tenant de Zuma y revisión de seguridad con Ismael.
Casos de uso priorizados
| Agente | Para quién | Problema que ataca | Herramienta | Fase |
|---|---|---|---|---|
| Copiloto del POAyuda al PO a diseñar cada requerimiento completo y listo para desarrollo. | Proyectos y PO | Requerimientos que llegan como correos, sin método ni plantilla | Copilot Studio | 2 |
| Asistente de código webAyuda a escribir y revisar código más rápido. | Cristopher | Tiempo de desarrollo en Python y Angular | Asistente de IA en VS Code | 2 |
| Analista de X++Lee el código de Dynamics y lo documenta para no depender de una persona. | Felipe | Conocimiento concentrado, código sin documentar | Asistente de IA sobre el repositorio | 2 |
| Generador de pruebasConvierte los criterios de aceptación en pruebas automáticas. | Equipo | Pruebas pequeñas, regresiones tras actualizaciones | Agente sobre criterios y RSAT | 3 |
| Consultor de DynamicsResponde a las áreas preguntas de inventario y órdenes. | Áreas usuarias | Consultas de inventario y órdenes que hoy llegan como soporte | MCP Dynamics 365 ERP | 3 |
RutaEjecución por tramos
Seis tramos, cada uno entrega algo visible
Ningún tramo depende de una gran apuesta al final: cada uno mejora la operación actual y prepara el siguiente.
Accesos completos, inventario de sistemas y línea base de indicadores, para que el diagnóstico parta de datos y no de opiniones.
Criterio de salidaAccesos completos, inventario v1 y dashboard con la línea base publicados al 13 de noviembre.
En palabras simples
Antes de diagnosticar hay que poder ver. Esta etapa consigue los permisos para revisar todos los sistemas, arma una lista completa de la tecnología que tiene Zuma y deja un tablero con los números de hoy para comparar después.
También protege información: antes de borrar las máquinas virtuales viejas de desarrollo, se respalda todo, porque ahí hay código y documentos que no están en otro lado.
Para el equipo técnico
- Accesos de solo lectura por sistema, documentados en una matriz con quién los aprobó.
- Inventario en tabla: sistema, dueño, tecnología, ambientes, integraciones, licencias y costo mensual.
- Team y Area Path «Desarrollo» para aislar las métricas del equipo en el proyecto compartido.
- Dashboard con widgets sobre consultas: items por estado, antigüedad y cola de revisión del PO.
Primeras cuatro semanas
Semana 1
26 – 30 oct
- Accesos con Ismael: Repos, LCS, PPAC, ambientes, Azure, AWS
- Reunión de arquitectura y ambientes
- Respaldo de las máquinas virtuales antes de eliminarlas
Semana 2
2 – 6 nov
- Inventario de sistemas v1
- Team y Area Path «Desarrollo»
- Validar el plan con Felipe y Cristopher
- Arranca la limpieza de backlog
Semana 3
9 – 13 nov
- Dashboard con línea base
- Arranca el diagnóstico de Dynamics, Ubiqua y proceso
- Inicia el registro de tiempos de 2 semanas
Semana 4
16 – 20 nov
- Entrevistas con Luis, Martina y Javier
- Depuración de la cola de revisión del PO
- Arranca diagnóstico de Zumadores e infraestructura
Accionables
| Accionable | Responsable | Fecha | Entregable |
|---|---|---|---|
| Matriz de accesos: Project Administrator, Azure Repos, LCS y Power Platform Admin Center, ambientes de Dynamics, Azure Reader, AWS Amplify, repositorios de Ubiqua y ZumadoresPermisos de solo lectura para revisar cada sistema sin riesgo de modificar nada. | Geovanni, Ismael | 30 oct | Matriz de accesos completa |
| Reunión de arquitectura y ambientesIsmael explica cómo están armados los servidores, los ambientes y las conexiones. | Geovanni, Ismael | 30 oct | Mapa preliminar de ambientes |
| Respaldo verificado de las máquinas virtuales de desarrolloLas máquinas viejas guardan código y documentos sueltos; se copian antes de eliminarlas. | Felipe, Ismael | 30 oct | Lista de lo rescatado |
| Inventario de aplicaciones, integraciones, repositorios, ambientes, nubes y licenciasUna sola lista de toda la tecnología: qué es, quién la usa, dónde vive y cuánto cuesta. | Geovanni | 6 nov | Inventario de sistemas v1 |
| Team y Area Path «Desarrollo» para separar métricasSepara en DevOps el trabajo de desarrollo del de otras áreas para medir solo lo del equipo. | Geovanni | 6 nov | Tablero propio del equipo |
| Ritmo de gobierno con JorgeReuniones fijas para revisar avance y tomar decisiones a tiempo. | Geovanni, Jorge | 6 nov | Calendario de seguimiento |
| Validación del plan con el equipoFelipe y Cristopher revisan y ajustan el plan: si no lo sienten suyo, no funciona. | Geovanni | 6 nov | Plan v2.1 |
| Dashboard con la línea baseLos números de hoy en una pantalla, para comparar el avance mes a mes. | Geovanni | 13 nov | Dashboard en Azure DevOps |
Un diagnóstico con datos de seis frentes y el caso de negocio de Ubiqua, presentado el 18 de diciembre como base de las decisiones de 2027.
CierreBorrador revisado con el equipo el 11 dic, caso de negocio de Ubiqua el 16 dic, presentación a Jorge Ramírez el 18 dic.
En palabras simples
Es como un chequeo médico completo antes de recetar. Revisamos seis frentes con datos reales y conversando con quienes usan los sistemas todos los días.
El resultado es un informe que dice qué funciona, qué falla, cuánto cuesta y qué conviene hacer primero, incluyendo una recomendación con números sobre si Ubiqua debe mejorarse o reemplazarse.
Para el equipo técnico
- Revisión de modelos y código X++, integraciones, batch jobs, pipelines y ambientes en LCS y PPAC.
- Mapeo de flujo de valor de 6 requerimientos reales, de la solicitud a producción, midiendo esperas y retrabajos.
- Entrevistas estructuradas con proyectos, comercial y tesorería; registro de tiempos de 2 semanas del equipo.
- Consolidación en una matriz de impacto y esfuerzo, y caso de negocio de Ubiqua con costo total de cada opción.
Dynamics 365 F&O
9 nov – 4 dic
Felipe, Edric, Geovanni
Saber qué se ha construido dentro de Dynamics, qué tan sano está y qué tan riesgoso es cada cambio o actualización.
- Inventario de extensiones, modelos y entidades X++ con su uso real
- Integraciones con Ubiqua y Zumadores, procesos batch
- Ciclo de vida: ramas, CI, paquetes, ambientes y migración de LCS a PPAC
- Caso Walmart y viabilidad de RSAT
- Mapa de quién sabe qué del ERP
Entrega: informe técnico con riesgos priorizados.
Ubiqua
9 nov – 4 dic
Cristopher, Geovanni, comercial
Medir con datos lo que Ubiqua no hace y cuánto le cuesta eso a Zuma en ventas perdidas y horas de soporte.
- Contrato, SLA, roadmap y costo anual
- Catálogo de brechas con evidencia
- Costo operativo: soporte, cargas manuales, ventas bloqueadas
Entrega: catálogo de brechas con costo estimado.
Zumadores
16 nov – 4 dic
Cristopher, Geovanni
Entender la app anterior, que sí resolvía combos y múltiplos, y si sirve como base para el futuro.
- Por qué se reemplazó y quién lo decidió
- Calidad del código y deuda técnica
- Qué se puede reutilizar para una app propia
Entrega: ficha técnica y opción de reutilización.
Infraestructura y repositorios
16 nov – 4 dic
Ismael, Geovanni
Saber dónde vive cada sistema, cuánto cuesta mantenerlo y qué tan seguro está el código.
- Nubes, ambientes por sistema y costos mensuales
- Ramas, pipelines, secretos y revisión de código
Entrega: arquitectura actual y propuesta de consolidación.
Proceso y requerimientos
9 nov – 11 dic
Geovanni, Luis, Martina, Javier
Comparar lo que se pidió contra lo que se entregó, y encontrar dónde se pierde el tiempo.
- Recorrido de 3 requerimientos por desarrollador
- 17 requerimientos padre: pedido, entregado, esperas
- Entrevistas con comercial y tesorería
- Registro de tiempos de 2 semanas
Entrega: flujo actual y comparativa requerido contra entregado.
Cuellos de botella e IA
7 – 11 dic
Geovanni con el equipo
Ordenar todos los hallazgos por impacto y esfuerzo para saber qué atacar primero.
- Matriz de impacto y esfuerzo
- Casos de uso de agentes por etapa
Entrega: matriz priorizada.
Brechas conocidas de Ubiqua, punto de partida del catálogo
| Brecha | Evidencia | Impacto | Dónde se resuelve |
|---|---|---|---|
| Combos y atados | Existencia cero porque no calcula disponibilidad desde componentes | 1,000 unidades del atado de guantes sin poder venderse | Hub (disponibilidad) y ubicación combinada en bodega |
| Múltiplos de venta | Respeta el mínimo de 4, pero acepta 5, 6 o 7 | Pedidos fuera de presentación comercial | Hub (validación antes de la orden) |
| Sincronización de inventario | Integrador que jala todo el inventario cada 30 minutos | Descuadres con pedidos de otros canales y carga innecesaria | Hub (eventos) |
| Conciliación y cobros | Proceso no validado; cargas manuales al panel antiguo | Tesorería depende de desarrollo | Diagnóstico con tesorería |
| Usuarios y bajas | Riesgo de cuentas transferidas entre asesores | Liquidaciones y cobros sin dueño claro | Checklist de bajas e identidad con Entra ID |
Cinco mejoras sin presupuesto que se notan antes de que termine el diagnóstico.
Resultado esperadoUn tablero que refleja la realidad y Cristopher con al menos 30% de su tiempo liberado desde enero.
En palabras simples
Son mejoras rápidas que no necesitan esperar al diagnóstico ni presupuesto: ordenar el tablero, acordar cómo se pide y cómo se entrega el trabajo, y que el soporte de Ubiqua lo atienda el equipo de soporte para que Cristopher vuelva a construir.
Para el equipo técnico
- Limpieza: cerrar lo completado, marcar Removed lo obsoleto y mover lo vivo a Q4_Sprint1.
- Plantilla: campos obligatorios en el tipo de work item del proceso personalizado.
- Terminado y acta: checklist en el work item y aceptación registrada por el stakeholder.
- Traspaso: runbook de Ubiqua, base de conocimiento y matriz de escalamiento en tres niveles.
| Accionable | Responsable | Fecha | Esfuerzo | Resultado |
|---|---|---|---|---|
| Limpieza de backlog con cada desarrolladorRevisar uno por uno los 71 items: cerrar lo terminado y descartar lo que ya no aplica. | Geovanni, Felipe, Cristopher | 13 nov | ●●● | Items estancados de 24 a menos de 5 |
| Depurar los 13 items en «Para Revisión PO»Sentarse con Luis a revisar los trabajos que esperan aprobación desde hace meses. | Geovanni, Luis | 20 nov | ●●● | Cola en cero o con fecha |
| Plantilla de requerimientos y taller con proyectosUn formato único para pedir trabajo al equipo y un taller para aprender a usarlo. | Geovanni, Luis, Martina | 27 nov | ●●● | Plantilla obligatoria para lo nuevo |
| Definición de terminado y acta de entregaAcordar cuándo algo está terminado y que el usuario firme que lo recibió. | Geovanni, Felipe, Cristopher | 27 nov | ●●● | Entregas cerradas con aceptación |
| Traspaso del soporte de Ubiqua al equipo de IsmaelDocumentar Ubiqua para que soporte la atienda y Cristopher vuelva a desarrollar. | Cristopher, Ismael, Javier | 11 dic | ●●● | 30% del tiempo de Cristopher liberado |
La plantilla de requerimientos
El problema
- Qué pasa hoy y a quién afecta
- Proceso de negocio involucrado
- Costo de no resolverlo
La solución esperada
- Usuario final y stakeholder que aprueba
- Criterios de aceptación verificables
- Datos de prueba reales
El contexto
- Prioridad acordada con proyectos
- Sistemas afectados: Dynamics, Ubiqua, Power Platform
- Fecha límite real, si existe
Al 31 de marzo, el equipo trabaja con un proceso estándar, cada actualización de Dynamics se valida con pruebas automáticas y el hub resuelve en producción la disponibilidad de inventario y combos.
Criterio de salidaSprints con más del 80% cumplido, cero paquetes fuera de CI, hub v1 en producción y 100% de requerimientos con plantilla.
En palabras simples
Aquí se construyen los cimientos. Una forma de trabajar igual para todos; pruebas automáticas que avisan si una actualización de Microsoft rompe algo, como pasó con los descuentos de Walmart; la primera versión del hub resolviendo combos y múltiplos; y los primeros asistentes de IA trabajando con el equipo.
Para el equipo técnico
- Pipelines de build y release en Azure DevOps para Dynamics, Ubiqua, Zumadores y el panel.
- RSAT conectado a Task Recorder para los 10 procesos críticos, ejecutado en sandbox antes de cada actualización.
- Hub v1: API Management, Service Bus y Functions desplegados con infraestructura como código y aprobados por Ismael.
- Métricas de adopción de IA: uso semanal, tiempo ahorrado reportado y calidad de requerimientos revisados.
Proceso de desarrollo
4 ene – 12 feb
Felipe, Cristopher, Geovanni
Que todos trabajen igual: cada cambio revisado por otra persona y publicado de forma automática y segura.
- Ramas por requerimiento con pull requests revisados
- Paquetes de Dynamics solo desde CI, también en urgencias
- Ambientes de prueba obligatorios para todas las apps
- Sprints de 2 semanas con revisión y retrospectiva
Entrega: manual de proceso v1 y pipelines operando.
Calidad y actualizaciones
18 ene – 26 mar
Felipe, Edric
Que ninguna actualización de Microsoft vuelva a detener la venta sin que lo sepamos antes.
- Suite RSAT para los 10 procesos críticos: ventas, descuentos, inventario, facturación, tesorería
- Ventana de pruebas en sandbox antes de cada actualización
Entrega: regresión ejecutada antes de la primera actualización de 2027.
Hub de integración mínimo
1 feb – 31 mar
Geovanni, Felipe, Cristopher, Ismael
Resolver el problema de hoy, combos y múltiplos en Ubiqua, con la pieza que servirá para todo lo demás.
- Arquitectura y aprobación de seguridad
- Disponibilidad por eventos con combos y atados, consumida por Ubiqua
- Validación de múltiplos y mínimos antes de la orden
- Monitoreo de todas las llamadas
Entrega: hub v1 en producción con Ubiqua conectado.
Agentes y documentación
11 ene – 31 mar
Todo el equipo
Que la IA empiece a ahorrar tiempo de verdad y que el conocimiento de Dynamics quede escrito.
- Copiloto del PO en Copilot Studio
- Asistentes de código para ambos desarrolladores
- Piloto del MCP de Dynamics 365 ERP en prueba
- Documentación de Dynamics asistida por IA, validada por Felipe y Edric
Entrega: tres agentes en uso y repositorio de documentación.
Decidir sobre Ubiqua con tres meses de datos del hub y, si se aprueba, tener una app de ventas propia en piloto al 30 de junio.
DecisiónComité del 30 de abril de 2027 con el caso de negocio actualizado.
En palabras simples
Con tres meses del hub funcionando ya hay datos para decidir sobre Ubiqua. Si conviene una app propia, se prueba primero con un grupo pequeño de asesores, sin quitar Ubiqua, y se compara. Al mismo tiempo, otras aplicaciones de las áreas empiezan a conectarse por el hub.
Para el equipo técnico
- Caso de negocio con costo total a 3 años por opción: licencias, desarrollo, soporte y costo de las brechas.
- App piloto offline-first sobre el hub; posible reutilización de Ionic Angular y Django según la ficha de Zumadores.
- Catálogo de APIs con documentación OpenAPI publicado en el portal de API Management.
- MCP en un caso real con rol de solo lectura y auditoría.
Tres caminos para Ubiqua
| Opción | Control | Velocidad | Esfuerzo interno | Cuándo conviene |
|---|---|---|---|---|
| A. El proveedor desarrolla las brechas | ●●● | Según el proveedor | ●●● | Si Ubiqua compromete fechas firmes y costo razonable |
| B. Ubiqua con lógica en el hub | ●●● | Inmediata con el hub | ●●● | Si lo que falta es lógica de negocio y no experiencia de usuario |
| C. App propia sobre el hub | ●●● | Piloto en 2 meses | ●●● | Si brechas y soporte cuestan más que desarrollar y mantener |
Evaluación preliminar; se confirma con los datos del diagnóstico y del hub.
Piloto de app de ventas
3 may – 30 jun, si se elige C
Probar con asesores reales si una app propia vende mejor y da menos problemas que Ubiqua.
- Catálogo, disponibilidad, combos, múltiplos, pedido y modo offline
- 10 a 15 asesores de una ruta, en paralelo con Ubiqua
- Posible base en Zumadores, según la ficha técnica
Entrega: piloto con métricas comparadas.
Periféricos y agentes
abr – jun
Que el resto de aplicaciones de las áreas use el hub y que un agente empiece a atender consultas reales.
- Catálogo de APIs publicado para las áreas
- Zumadores, panel, flujos de Power Automate y tesorería migran al hub
- MCP de Dynamics en un caso real de solo lectura
- Agente que genera pruebas desde los criterios
Entrega: 4 periféricos solo por el hub y un agente operativo.
El hub como estándar regional y un equipo que opera con agentes todos los días.
EntregaInforme anual de resultados y plan 2028 el 15 de diciembre de 2027.
En palabras simples
Se consolida lo construido y se prepara para crecer: la app de ventas en todas las rutas si se aprobó, el hub listo para Costa Rica y la región, y los datos de la operación disponibles para tomar decisiones.
Para el equipo técnico
- Despliegue por oleadas de rutas con plan de retiro de Ubiqua y Zumadores.
- Hub multi-entidad para la operación regional en Dynamics.
- Eventos del hub hacia Microsoft Fabric para analítica operativa.
Ventas
jul – sep 2027
- App de ventas a producción por rutas, si se eligió la opción C
- Retiro de Ubiqua y de Zumadores
Regional
jul – dic 2027
- Hub y proceso de desarrollo listos para Costa Rica
- Estándar único de integración para la región
Datos
sep – dic 2027
- Eventos del hub hacia Fabric para analítica
- Tableros de operación en tiempo real
Equipo
oct – dic 2027
- Capacidad para 2028 según productividad medida con IA
- Plan de carrera y formación del equipo
Catálogo de entregables
Todo lo que el plan produce, qué contiene y para quién sirve, en orden de fecha.
| Entregable | Qué contiene | Para quién | Fecha |
|---|---|---|---|
| Matriz de accesos | Permisos por sistema y quién los aprobó | Ismael, Geovanni | 30 oct 2026 |
| Inventario de sistemas v1 | Cada sistema con dueño, tecnología, ambientes, integraciones, licencias y costo | Jorge, TI | 6 nov 2026 |
| Dashboard de línea base | Los indicadores de hoy en Azure DevOps | Jorge, equipo | 13 nov 2026 |
| Plantilla de requerimientos | Formato obligatorio y guía de llenado con ejemplos | Proyectos, áreas | 27 nov 2026 |
| Definición de terminado y acta | Checklist de calidad y formato de aceptación del usuario | Equipo, usuarios | 27 nov 2026 |
| Traspaso del soporte de Ubiqua | Manual de operación, base de conocimiento y niveles de escalamiento | Ismael, Javier | 11 dic 2026 |
| Caso de negocio de Ubiqua | Tres opciones con costo, riesgo y recomendación | Jorge, comercial | 16 dic 2026 |
| Informe de diagnóstico | Hallazgos por frente, riesgos, costos y matriz priorizada | Jorge, Chief of Staff | 18 dic 2026 |
| Manual de proceso de desarrollo | Ramas, revisiones, despliegue, sprints y urgencias | Equipo | 12 feb 2027 |
| Suite de regresión | Pruebas automáticas de los 10 procesos críticos de Dynamics | Felipe, Edric | 26 mar 2027 |
| Hub v1 en producción | Servicios de disponibilidad, combos y validación de pedidos | Áreas, Ubiqua | 31 mar 2027 |
| Agentes de IA en uso | Copiloto del PO, asistentes de código y piloto MCP con métricas | Equipo, proyectos | 31 mar 2027 |
| Decisión sobre Ubiqua | Acta del comité con la opción elegida y su plan | Jorge | 30 abr 2027 |
| Catálogo de APIs | Servicios del hub disponibles para las áreas, documentados | Áreas | 30 jun 2027 |
| Piloto de app de ventas | App con 10 a 15 asesores y comparativo contra Ubiqua | Comercial | 30 jun 2027 |
| Informe anual y plan 2028 | Resultados contra metas y prioridades del siguiente año | Jorge, Chief of Staff | 15 dic 2027 |
TiempoCronograma por frente de trabajo
Cinco frentes avanzan en paralelo hacia los mismos hitos
La línea roja marca hoy. Del 19 de diciembre al 3 de enero no hay entregas; la Fase 2 arranca con la incorporación de tiempo completo.
Cómo leerlo
Cada fila es una actividad y su barra muestra cuándo empieza y termina. Los rombos son hitos, el amarillo es el más importante, y la línea roja marca el día de hoy. Las filas se agrupan por frente de trabajo, y varios frentes avanzan al mismo tiempo.
Dependencias
- El hub v1 depende del proceso estándar y de los pipelines de enero y febrero.
- La decisión sobre Ubiqua necesita tres meses de métricas del hub en producción.
- El piloto de app propia solo arranca si la decisión de abril elige la opción C.
- RSAT debe estar listo antes de la primera actualización de Microsoft de 2027.
GenteEquipo, responsabilidades y recursos
Quién hace qué, y con cuánto tiempo
Las Fases 0 y 1 se hacen con lo que Zuma ya tiene. El gasto nuevo empieza en la Fase 2 y se cotiza en diciembre para aprobarlo con el diagnóstico.
Matriz de responsabilidades
REjecutaAAprueba y respondeCConsultadoIInformado
Cómo leer la matriz
La matriz responde quién hace qué. R es quien hace el trabajo; A es quien responde por el resultado y da el visto bueno final, y siempre es una sola persona por entregable; C es a quien se le pregunta antes de decidir; e I es a quien se le avisa del resultado.
Notas de recursos
- La dedicación es el porcentaje de la semana destinado al plan; el resto sigue en operación.
- Los recursos por consumo dependen del volumen de llamadas y eventos; se estiman en diciembre con datos del diagnóstico.
- Las licencias se validan contra el contrato actual de Microsoft antes de comprar.
Dedicación al plan
Geovanni: intermitente hasta diciembre y 100% desde enero. Ismael: accesos, arquitectura y recepción del soporte. La dedicación de Cristopher depende del traspaso del soporte de Ubiqua. Sin él, la Fase 2 se extiende al menos dos meses.
Recursos nuevos
| Recurso | Fase | Costo |
|---|---|---|
| Azure API Management | 2 | Por cotizar según uso |
| Service Bus, Functions, Logic Apps | 2 | Por consumo |
| Azure Monitor y Application Insights | 2 | Por consumo |
| Copilot Studio | 2 | Validar licencia actual |
| Asistentes de código, 2 a 3 usuarios | 2 | Por usuario |
| Sandbox adicional de Dynamics | 2 | Validar con Microsoft |
| Partner de Dynamics, bolsa de horas | 2–3 | Opcional |
| Desarrollador adicional | 3 | Solo si se aprueba la app propia |
TableroMedición y gobierno
Siete indicadores, revisados cada viernes
Cada indicador tiene línea base de octubre, meta a marzo y meta a junio de 2027, visibles en el dashboard de Azure DevOps.
- Hoy
- Meta marzo 2027
- Meta junio 2027
Ritmo de seguimiento
Daily
15 minutos, todo el equipo. Avances y bloqueos.
Checkpoint de viernes
30 minutos con Jorge. Avance, riesgos y decisiones.
Revisión de sprint
Cada 2 semanas desde enero, con proyectos y usuarios.
Comité mensual
Indicadores, riesgos y presupuesto, con el Chief of Staff cuando aplique.
En palabras simples
Estos indicadores son la forma de saber si el plan funciona sin discutir opiniones. En cada línea, el punto rojo es cómo estamos hoy, el naranja es la meta a marzo y el verde la meta a junio. Si un indicador no se mueve, se revisa en el checkpoint del viernes y se ajusta el plan.
Para el equipo técnico
- Fuentes: Azure DevOps Analytics para el tablero, registro de tiempos para soporte y Application Insights para el hub.
- Cálculo: espera en revisión como mediana de días en «Para Revisión PO»; cumplimiento como items cerrados entre comprometidos por sprint.
- Publicación: dashboard compartido, actualizado automáticamente.
AlertasRiesgos y mitigaciones
El riesgo mayor es la capacidad, no la tecnología
Dos desarrolladores, uno de ellos único conocedor de X++, sostienen la operación y la transformación a la vez. Toca un riesgo para ver su mitigación. Evaluación inicial, a recalibrar en el diagnóstico.
Probabilidad media
Probabilidad alta
Impacto alto
Vigilar
Atender ya
Impacto medio
Monitorear
Vigilar
Selecciona un riesgo
Aquí aparece su mitigación y quién la lleva.
Cómo leer el mapa
El mapa ordena los riesgos según qué tan probable es que pasen (de izquierda a derecha) y cuánto daño harían (de abajo hacia arriba). Lo que está arriba a la derecha se atiende ya; lo de abajo a la izquierda se monitorea. Cada riesgo tiene un dueño que lleva su mitigación.
Cómo se gestiona
- Evaluación inicial basada en el kickoff, las dailies y los datos de Azure DevOps.
- Se recalibra con el diagnóstico y se revisa en cada comité mensual.
- Un riesgo que se materializa pasa a ser incidente con plan de acción y fecha.
TérminosGlosario
Las palabras técnicas del plan, explicadas
Para que cualquier persona de Zuma pueda leer el plan completo sin perderse.
Dynamics 365 F&O
El ERP de Zuma: el sistema donde se registran ventas, inventario, compras, bodega y finanzas.
ERP
Sistema central que integra la operación de toda la empresa en una sola base de datos.
X++
Lenguaje de programación de Dynamics F&O. Hoy solo Felipe lo domina en el equipo.
LCS y PPAC
Consolas de Microsoft para administrar los ambientes de Dynamics y publicar cambios. LCS se está migrando a PPAC.
Ambiente o sandbox
Copia del sistema para probar cambios sin afectar la operación real.
Azure DevOps
Herramienta donde se registran las tareas (Boards), se guarda el código (Repos) y se automatiza su publicación (Pipelines).
Backlog
La lista de todo el trabajo pendiente del equipo.
Sprint
Periodo fijo de dos semanas en el que el equipo se compromete a terminar un conjunto de tareas.
PO, Product Owner
La persona que representa al área usuaria, prioriza y aprueba lo entregado.
Historia de usuario
Forma de escribir un requerimiento desde quien lo va a usar: quién, qué necesita y para qué.
Criterios de aceptación
Las condiciones concretas que debe cumplir un trabajo para considerarse correcto.
Definición de terminado
El acuerdo de qué tiene que pasar para decir que algo está listo: revisado, probado y aceptado.
Rama y pull request
Copia aislada del código para un cambio, y la solicitud para que otra persona lo revise antes de unirlo.
CI/CD
Automatización que construye, prueba y publica el software cada vez que hay un cambio.
Paquete
El archivo con los cambios de Dynamics que se instala en un ambiente.
Pruebas de regresión y RSAT
Pruebas que verifican que lo que ya funcionaba siga funcionando. RSAT es la herramienta de Microsoft para automatizarlas en Dynamics.
Hub de integración
Capa central por la que pasan todas las aplicaciones para hablar con Dynamics, con reglas y seguridad comunes.
API
Puerta digital por la que un sistema le pide o le envía información a otro.
API Management
Servicio de Azure que controla, protege y registra todas las APIs del hub.
Eventos y Business Events
Avisos automáticos que Dynamics envía cuando algo cambia, por ejemplo el inventario.
Service Bus
Servicio de Azure que reparte esos avisos a todas las aplicaciones interesadas.
Functions y Logic Apps
Servicios de Azure donde se programan las reglas de negocio del hub sin administrar servidores.
OData y Data Management Framework
Formas de leer y escribir en Dynamics: OData para operaciones del día a día, DMF para cargas masivas.
Entra ID
El sistema de identidad de Microsoft: controla quién entra a qué con su cuenta de Zuma.
Ubiqua
La aplicación de ventas de terceros que usan los asesores hoy.
Zumadores
La aplicación de ventas anterior, desarrollada por el equipo, que está por salir.
Combo, atado y lista de materiales
Un combo agrupa productos en un solo código; la lista de materiales le dice a Dynamics qué productos lo forman.
Agente de IA
Asistente de inteligencia artificial que realiza tareas concretas con reglas y permisos definidos.
Copilot Studio
Herramienta de Microsoft para crear agentes de IA conectados a los sistemas de la empresa.
MCP
Protocolo estándar para que un agente de IA consulte un sistema, como Dynamics, de forma controlada.
Power Platform
Herramientas de Microsoft para crear apps y flujos con poco código, como Power Automate y Forms.
Arquitecto del requerimiento
El nuevo rol del PO: diseña cada requerimiento completo, con su copiloto de IA, antes de que llegue a desarrollo.
Copiloto del PO
Agente de IA que acompaña al PO a descubrir, redactar y revisar requerimientos. Sugiere; el PO decide.
Matriz RACI
Tabla que define quién ejecuta, quién aprueba, a quién se consulta y a quién se informa.
HoyLo que se pide
Cuatro decisiones para arrancar
Aprobar el alcance y las fechas de las Fases 0 y 1
Diagnóstico entregado el 18 de diciembre de 2026.
Formalizar el traspaso del soporte de Ubiqua
Del equipo de desarrollo al equipo de Ismael, para liberar a Cristopher.
Respaldar la plantilla obligatoria de requerimientos
Ante el equipo de proyectos, desde el 27 de noviembre.
Habilitar el presupuesto de la Fase 2
Azure y licencias de IA, cotizados en diciembre.
AbiertoPreguntas para el diagnóstico
Lo que todavía no sabemos
Márcalas cuando se resuelvan; se guardan solo en tu navegador.