Valor × Complejidad: cómo priorizamos qué automatizar

Un backlog de automatización ordenado por quien más presiona desperdicia capacidad. Así funciona nuestro marco Valor × Complejidad: definir, clasificar y priorizar con dos ejes y cuatro cuadrantes.

El problema: backlogs ordenados por quien más grita

Casi cualquier área de operaciones tiene más ideas de automatización que capacidad para construirlas. Scripts que alguien prometió, tareas repetitivas que nadie quiere hacer, pedidos de auditoría, mejoras sugeridas después de un incidente. El problema rara vez es la falta de candidatos. El problema es el orden.

Cuando no hay un criterio explícito, el backlog se ordena solo, y casi siempre mal. Sube lo que pide el gerente con más peso, lo que generó el último incidente visible o lo que a un ingeniero le parece interesante construir. Bajan las tareas silenciosas que consumen horas cada semana, o los controles que reducirían un riesgo de cumplimiento que nadie reclama hasta la próxima auditoría.

El resultado es conocido: automatizaciones que costaron semanas y ahorran poco, proyectos ambiciosos que se estancan a mitad de camino y un equipo que pierde credibilidad frente al negocio. Para evitarlo usamos un marco sencillo, que llamamos Valor × Complejidad, para definir, clasificar y priorizar el backlog de automatización.

Tres pasos: definir, clasificar, priorizar

El marco tiene tres pasos que se aplican a cada candidato, más una regla de mantenimiento.

Definir. Cada candidato se documenta en una ficha con los mismos campos: proceso, disparador, frecuencia, volumen, sistemas involucrados, dueño, resultado esperado y riesgo actual. Sin ficha completa, no hay puntuación.
Clasificar. Se puntúa el candidato en dos ejes, Valor y Complejidad, cada uno de 1 a 5. El corte entre "alto" y "bajo" es 3.
Priorizar. La combinación de ambos ejes ubica al candidato en uno de cuatro cuadrantes, y cada cuadrante tiene una regla de tratamiento distinta.

A eso se suma la regla de mantenimiento: el backlog se re-puntúa periódicamente, por ejemplo cada trimestre, porque el valor y la complejidad cambian con el tiempo.

La ficha parece burocracia, pero cumple una función concreta. Obliga a quien propone una automatización a describir el proceso real, y deja en evidencia cuándo nadie sabe con qué frecuencia ocurre una tarea o quién es su dueño. Ese vacío ya es información útil.

Los dos ejes y sus factores

Cada eje es el promedio de varios factores, todos puntuados de 1 a 5. Promediar en lugar de usar una impresión general obliga a separar las conversaciones: una tarea puede ahorrar pocas horas y, aun así, tener mucho valor porque reduce un riesgo serio.

Valor

El eje Valor es el promedio de cuatro factores:

Ahorro de esfuerzo: horas por mes liberadas.
Reducción de riesgo y errores: cuánto baja la probabilidad o el impacto de una falla humana.
Impacto en el cliente o en el SLA: si la automatización acorta tiempos de atención o evita incumplimientos de nivel de servicio.
Aporte al cumplimiento o la auditoría: si deja evidencia trazable, aplica un control de forma consistente o responde a un requerimiento regulatorio.

Complejidad

El eje Complejidad es el promedio de cinco factores:

Cantidad de sistemas e integraciones que la automatización debe tocar.
Variabilidad del proceso: cuántas excepciones tiene en la práctica.
Calidad de los datos y accesos disponibles: si hay API, credenciales de servicio y datos confiables, o si todo depende de pantallas y archivos manuales.
Riesgo del cambio en producción: qué pasa si la automatización falla a mitad de camino.
Dependencia de terceros: proveedores, otras áreas o plataformas que no controlas.

Cada factor merece una rúbrica explícita, calibrada con datos de la propia organización, para que dos personas puntúen igual el mismo candidato.

Los cuatro cuadrantes

Con el corte en 3, cada candidato cae en uno de cuatro cuadrantes:

	Complejidad baja	Complejidad alta
Valor alto	Victorias rápidas: se ejecutan primero.	Apuestas estratégicas: se dividen en entregas menores y se planifican.
Valor bajo	Mejoras oportunistas: cuando hay capacidad libre o como formación.	Descartar o rediseñar: no se automatizan así; primero se simplifica el proceso.

Cada cuadrante tiene una lógica propia:

Victorias rápidas (valor alto, complejidad baja). Van primero porque entregan resultados visibles en poco tiempo y financian la confianza en el programa. Un equipo que muestra tres victorias rápidas en un trimestre consigue más fácilmente el espacio para una apuesta grande.
Apuestas estratégicas (valor alto, complejidad alta). Valen la pena, pero no como un único proyecto. Se dividen en entregas menores, cada una con valor propio, y se planifican con hitos.
Mejoras oportunistas (valor bajo, complejidad baja). Son útiles para llenar capacidad libre o para que alguien nuevo aprenda la plataforma de automatización sin riesgo.
Descartar o rediseñar (valor bajo, complejidad alta). Automatizar un proceso confuso solo produce un proceso confuso más rápido. Primero se simplifica; después se vuelve a puntuar.

Un ejemplo completo

Ejemplo ilustrativo. Los candidatos y los puntajes que siguen son ficticios. Sirven para mostrar la mecánica del marco, no describen a ninguna organización real.

Imagina el área de operaciones de TI de una aseguradora mediana con seis candidatos en su backlog. Los puntajes de Valor siguen el orden esfuerzo, riesgo, cliente o SLA, cumplimiento. Los de Complejidad siguen el orden sistemas, variabilidad, datos y accesos, riesgo del cambio, terceros.

Candidato	Factores de Valor	Valor	Factores de Complejidad	Complejidad	Cuadrante
A. Reinicio controlado de un servicio ante una alerta conocida	3, 4, 4, 2	3,25	2, 2, 2, 3, 1	2,0	Victorias rápidas
B. Altas y bajas de usuarios en el directorio y seis aplicaciones	4, 5, 2, 5	4,0	5, 4, 3, 3, 3	3,6	Apuestas estratégicas
C. Informe mensual de capacidad armado a mano en una hoja de cálculo	2, 2, 1, 2	1,75	2, 1, 2, 1, 1	1,4	Mejoras oportunistas
D. Conciliación de inventario con un proveedor que cambia el formato de sus archivos	2, 2, 1, 3	2,0	3, 5, 4, 2, 5	3,8	Descartar o rediseñar
E. Renovación de certificados TLS antes de su vencimiento	2, 5, 5, 3	3,75	3, 2, 2, 3, 2	2,4	Victorias rápidas
F. Aplicación de parches del sistema operativo en servidores	5, 4, 3, 4	4,0	3, 4, 3, 4, 2	3,2	Apuestas estratégicas

Dentro de cada cuadrante recomendamos ordenar por valor descendente y, ante un empate, por menor complejidad. El orden resultante queda así:

E. Renovación de certificados (victoria rápida, valor 3,75). Un certificado vencido puede dejar un servicio fuera de línea; el riesgo y el impacto en el cliente pesan más que las horas.
A. Reinicio controlado (victoria rápida, valor 3,25). Acorta el tiempo de recuperación de una falla repetida y bien conocida.
F. Parches del sistema operativo (apuesta estratégica, valor 4,0, complejidad 3,2). Se divide en entregas: primero el inventario y el reporte de cumplimiento de parches, luego un grupo piloto de servidores no críticos, después ventanas por criticidad.
B. Altas y bajas de usuarios (apuesta estratégica, valor 4,0, complejidad 3,6). Empata en valor con F y queda después por mayor complejidad. Una primera entrega razonable es automatizar solo las bajas en el directorio, que concentran el riesgo de accesos huérfanos.
C. Informe de capacidad (mejora oportunista). Buen ejercicio para alguien que se incorpora al equipo.
D. Conciliación con el proveedor (descartar o rediseñar). No se automatiza en su forma actual. Antes hay que acordar con el proveedor un formato estable y reducir las excepciones.

Fíjate en lo que el marco hizo visible. La conciliación D probablemente era el pedido más ruidoso, porque molesta cada mes. Pero automatizarla hoy significaría construir sobre un formato que cambia sin aviso. Y la renovación de certificados, que nadie pedía con urgencia, sube al primer lugar por el riesgo que evita.

Re-puntuar: el backlog no es una foto fija

Los puntajes envejecen. Un proveedor publica una API y la complejidad de una integración baja. Una nueva exigencia de auditoría sube el valor de un control. Un proceso se rediseña y sale del cuadrante de descarte. Por eso el marco incluye una revisión periódica; nosotros sugerimos una cadencia trimestral.

En cada revisión conviene:

Revisar las fichas nuevas y completar las que quedaron a medias.
Volver a puntuar los candidatos cuyo contexto cambió: sistemas reemplazados, procesos rediseñados, nuevos requisitos de cumplimiento.
Comparar el valor estimado de las automatizaciones ya construidas con el valor observado, para calibrar cómo puntúa el equipo.
Mover a "Descartar o rediseñar" lo que lleva varios trimestres sin avanzar, y preguntar por qué.

Esa revisión necesita un dueño, participantes definidos y unas pocas métricas que se reporten siempre de la misma forma.

Lo que el marco no hace

Valor × Complejidad no reemplaza el juicio. Es una forma de hacer explícito ese juicio y de discutirlo con datos en lugar de impresiones. Dos personas pueden puntuar distinto el mismo factor; esa diferencia es justamente la conversación que vale la pena tener antes de invertir semanas de ingeniería.

Tampoco decide la herramienta. Un candidato puede resolverse con un playbook de Ansible, un flujo en la plataforma de gestión de servicios o un script programado. El marco solo dice qué hacer primero y qué no hacer todavía.