Cómo medir el valor de una automatización antes de construirla

Medir antes, no después

La mayoría de los equipos mide el valor de una automatización cuando ya está en producción, si es que lo mide. Para entonces la decisión de inversión ya se tomó. Lo útil es estimar el valor antes de construir, con un método lo bastante simple como para aplicarlo a decenas de candidatos y lo bastante explícito como para discutirlo.

En nuestro marco Valor × Complejidad, el eje Valor es el promedio de cuatro factores, cada uno puntuado de 1 a 5:

• Ahorro de esfuerzo: horas por mes liberadas.
• Reducción de riesgo y errores.
• Impacto en el cliente o en el SLA.
• Aporte al cumplimiento o la auditoría.

Este artículo explica cómo puntuar cada uno de forma consistente, para que un 4 signifique lo mismo cuando lo pone el equipo de redes que cuando lo pone el de bases de datos.

Una rúbrica para los cuatro factores

Una rúbrica no elimina el juicio, pero lo ancla. La tabla describe los extremos y el punto medio; 2 y 4 son valores intermedios. Los umbrales de horas son valores de referencia que proponemos como punto de partida: ajústalos al tamaño de tu equipo y de tu operación.

Factor	1	3	5
Ahorro de esfuerzo	Menos de 5 horas al mes liberadas.	Entre 15 y 40 horas al mes.	Más de 80 horas al mes.
Reducción de riesgo y errores	La tarea casi no genera errores, o sus errores son menores y reversibles.	Errores ocasionales que producen retrabajo o incidentes menores.	Un error puede causar una caída de servicio, pérdida de datos o una exposición de seguridad.
Impacto en el cliente o en el SLA	Sin efecto visible para usuarios ni clientes.	Acorta tiempos de atención de solicitudes internas.	Afecta directamente la disponibilidad o un SLA comprometido con clientes.
Aporte al cumplimiento o la auditoría	Sin relación con controles ni auditorías.	Genera evidencia útil para un control interno.	Aplica o evidencia un control exigido por la regulación, o cierra un hallazgo de auditoría abierto.

Para el ahorro de esfuerzo, los valores intermedios de referencia son: 2 entre 5 y 15 horas al mes, y 4 entre 40 y 80 horas al mes.

Dos reglas prácticas ayudan a puntuar con la rúbrica. Primero, quien puntúa debe poder justificar el número en una frase; si no puede, el puntaje es una opinión. Segundo, ante la duda entre dos valores, conviene elegir el menor y anotar qué dato haría falta para subirlo.

Cómo estimar las horas liberadas

Las horas son el factor más fácil de cuantificar y, por eso mismo, el más fácil de inflar. Recomendamos estimarlas siempre con la misma fórmula:

Horas al mes = frecuencia × volumen × duración

• Frecuencia: cuántas veces al mes ocurre la tarea.
• Volumen: cuántos elementos se procesan en cada ocurrencia (servidores, cuentas, archivos, solicitudes).
• Duración: cuánto tiempo toma cada elemento, medido y no recordado.

Por ejemplo, supón una revisión diaria de respaldos. Se hace 22 días hábiles al mes, cada día se revisan 15 trabajos de respaldo y cada revisión toma unos 4 minutos. Eso da 22 × 15 × 4 = 1.320 minutos, es decir, 22 horas al mes.

A ese número bruto hay que restarle el esfuerzo que la automatización no elimina:

1. Esfuerzo residual: alguien seguirá revisando las excepciones que la automatización marque. En el ejemplo, supón 2 horas al mes.
2. Mantenimiento: credenciales que rotan, versiones que cambian, ajustes cuando el proceso evoluciona. Supón 1 hora al mes.

El ahorro neto queda en 19 horas al mes, lo que según la rúbrica de referencia es un 3. La diferencia entre bruto y neto parece pequeña aquí, pero en automatizaciones frágiles o con muchas excepciones puede comerse la mitad del ahorro.

Tres advertencias sobre la estimación:

• Mide la duración. Pide a quien ejecuta la tarea que la cronometre durante una o dos semanas. La memoria tiende a subestimar las tareas aburridas y a sobrestimar las molestas.
• Usa la frecuencia típica, no el pico. Si la tarea se dispara al cierre de mes, refléjalo como tal y no como si cada semana fuera de cierre.
• Mira cómo se reparten las horas. Veinte horas concentradas en una persona liberan capacidad real. Veinte horas repartidas en veinte personas, una hora a cada una, liberan mucho menos de lo que sugiere el número.

Cómo valorar el riesgo y el cumplimiento

La reducción de riesgo es el factor que más se subestima, porque no aparece en ninguna planilla de horas. Una tarea de diez minutos al mes puede ser la que, mal hecha, deja un servicio fuera de línea. La renovación manual de certificados es un ejemplo clásico: poco esfuerzo, alto riesgo.

Para puntuar el riesgo sin inventar cifras, recomendamos mirar evidencia concreta:

• Historial de incidentes y problemas: ¿hay incidentes cuya causa fue un error en esta tarea manual?
• Cuasi incidentes: errores que se detectaron a tiempo pero pudieron haber escalado.
• Matriz de riesgos de la organización: si existe, usa su escala de probabilidad e impacto en lugar de crear una paralela.
• Dependencia de una persona: si solo una persona sabe ejecutar la tarea, el riesgo es mayor aunque nunca haya fallado.

El aporte al cumplimiento se valora preguntando qué control concreto apoya la automatización. Puede ser un control interno, un requisito de un estándar como ISO/IEC 27001 o una exigencia regulatoria. En organizaciones financieras que operan en la Unión Europea, por ejemplo, el Reglamento DORA establece obligaciones de gestión del riesgo de TIC que hacen especialmente valiosa la evidencia trazable y consistente.

Una automatización aporta al cumplimiento de tres formas: ejecuta el control siempre igual, deja registro de cada ejecución y reduce la dependencia de que alguien recuerde hacerlo. Si la automatización no deja registro auditable, su aporte al cumplimiento es bajo aunque el proceso sea regulado.

El impacto en el cliente o en el SLA

Este factor responde a una pregunta simple: si la automatización funciona, ¿lo nota alguien fuera del equipo? Puede ser un cliente externo que deja de sufrir una indisponibilidad, o un usuario interno cuya solicitud se resuelve en minutos en lugar de días.

Para puntuarlo conviene partir de los acuerdos de nivel de servicio vigentes. Si la tarea manual está en la ruta crítica de un SLA comprometido, por ejemplo el tiempo de restauración de un servicio, el impacto es alto. Si solo acelera un proceso interno sin compromiso formal, es medio. Si nadie fuera del equipo percibe la diferencia, es bajo.

Errores frecuentes al medir el valor

• Contar solo horas. Es el error más común. Deja fuera la reducción de riesgo y el cumplimiento, que suelen ser los factores que justifican automatizar tareas pequeñas pero críticas.
• Usar horas brutas. Sin descontar esfuerzo residual y mantenimiento, el valor queda sobrestimado.
• Confundir horas liberadas con ahorro presupuestario. Liberar horas permite reasignar capacidad; no significa automáticamente reducir costos. Prometer lo segundo cuando solo ocurrirá lo primero erosiona la credibilidad del programa.
• Contar dos veces el mismo beneficio. Si un control regulatorio reduce un riesgo, decide en qué factor pesa más y no lo puntúes alto en ambos solo por la misma razón.
• Ignorar el horizonte. Si el sistema involucrado se retira en seis meses, el valor acumulado de automatizarlo es menor, por alto que sea el ahorro mensual.
• Puntuar según quién pide. El valor se mide sobre el proceso, no sobre la jerarquía del solicitante.

Del factor al puntaje: un ejemplo

Ejemplo ilustrativo. Volvamos a la revisión diaria de respaldos, con datos ficticios:

• Ahorro de esfuerzo: 19 horas netas al mes, puntaje 3.
• Reducción de riesgo: un respaldo fallido que nadie detecta puede significar pérdida de datos ante un incidente, puntaje 4.
• Impacto en el cliente o en el SLA: la capacidad de restaurar servicios depende de respaldos válidos, puntaje 3.
• Aporte al cumplimiento: la verificación de respaldos suele ser un control revisado en auditoría y la automatización deja registro diario, puntaje 4.

El valor es (3 + 4 + 3 + 4) / 4 = 3,5: valor alto. Si solo se hubieran contado las horas, el candidato habría quedado en la frontera. Con los cuatro factores queda claro por qué merece atención. El paso siguiente es medir su complejidad, que tratamos en los factores que hunden una automatización.