Implementar no es el final: medimos qué cambió y buscamos la próxima restricción
Después de una implementación, observamos si el proceso realmente mejoró, qué nueva limitación aparece y si existe una siguiente intervención que valga la pena.
Medir antes de volver a construir
- CompararBaseline y resultado después de la implementación.
- ObservarQué cambió en el flujo y qué fricción sigue presente.
- EncontrarLa nueva restricción que condiciona el sistema.
- DecidirSi conviene intervenir, esperar o no hacer nada todavía.
La operación cambia después de cada mejora
Discor es el mejor ejemplo público de esa lógica: el trabajo no quedó reducido a un único sistema. A medida que la operación evolucionó, se midieron procesos distintos y aparecieron nuevas oportunidades de mejora.
- Consultas comerciales desde la web
- ~1 por mes → ~60 por mes
- Pedidos con mercadería equivocada
- Más de 80% menos pedidos afectados
- Carga diaria de facturas
- ~2 horas → 30–90 segundos de revisión final
- Costo tecnológico mensual recurrente
- ~USD 200 → ~USD 50
Por qué medir después
Una implementación puede reducir un problema y, al mismo tiempo, hacer visible otro que antes estaba escondido. Optimizar una parte aislada no garantiza que el sistema completo mejore. Por eso definimos métricas antes de intervenir y volvemos a mirar la operación después.
La pregunta deja de ser “¿qué funcionalidad agregamos?” y pasa a ser “¿qué limita ahora el resultado?”.
El ciclo de Evolución Operativa
1. Definir o recuperar el baseline
Tiempo, errores, volumen, consultas, costo, disponibilidad u otra métrica que represente el problema trabajado.
2. Medir el estado posterior
Observamos datos y experiencia de las personas que operan el proceso. No damos por hecho que “salió bien” solo porque la solución fue desplegada.
3. Buscar la nueva restricción
Identificamos qué punto del flujo está limitando ahora el resultado y evitamos optimizar tareas que no cambian el sistema.
4. Comparar alternativas
Puede ser un ajuste de proceso, integración, automatización, cambio de interfaz, infraestructura o una nueva pieza de software.
5. Decidir si vale la pena intervenir
Solo proponemos una siguiente etapa si existe una hipótesis de mejora defendible y una forma razonable de medirla.
Mantenimiento y evolución son trabajos distintos
Mantenimiento sostiene lo que ya existe: disponibilidad, correcciones, actualizaciones y cambios acordados. Evolución Operativa pregunta si la operación mejoró y dónde conviene intervenir después.
Una empresa puede necesitar solo mantenimiento. La evolución tiene sentido cuando hay una operación activa, datos suficientes y voluntad de seguir mejorando procesos concretos.
Qué podemos medir
- Tiempo: duración de tareas, esperas y ciclos completos.
- Errores: pedidos afectados, retrabajo, correcciones o incidencias.
- Volumen: consultas, operaciones, documentos o transacciones procesadas.
- Costo: infraestructura, licencias, horas manuales u otros costos recurrentes.
- Adopción: uso real de una funcionalidad o flujo por las personas que lo necesitan.
- Disponibilidad: uptime y comportamiento de servicios críticos cuando corresponde.
No todas las métricas sirven en todos los proyectos. Elegimos las que representan el problema original y la restricción que queremos observar.
No buscamos mejorar todo al mismo tiempo
Una lista larga de optimizaciones puede consumir recursos sin mover el resultado. Preferimos encontrar qué parte del sistema está limitando hoy la operación, intervenir ahí y volver a medir.
Si los datos muestran que la siguiente mejora no justifica costo o complejidad, la recomendación puede ser esperar. La continuidad no debería existir por inercia.
Si todavía no sabés dónde intervenir
Cuando el problema todavía está difuso, el paso anterior es Consultoría Operativa: mapear el proceso, encontrar la restricción inicial y diseñar una forma mejor de operarlo. Cuando ya hay una solución compleja priorizada, el Sprint de Arquitectura la vuelve implementable.
Medir, encontrar la siguiente restricción y decidir con evidencia
La próxima mejora no debería existir porque “siempre hay algo para hacer”, sino porque hay un resultado concreto que vale la pena perseguir.