Complejidad real: los factores que hunden una automatización

Por qué la complejidad se subestima

Cuando alguien propone una automatización, describe el camino feliz: llega la solicitud, se valida, se ejecuta, se cierra. Ese camino suele ser fácil de automatizar. Lo que consume el proyecto es todo lo demás: la solicitud que llega incompleta, el servidor que no responde, el proveedor que cambió el formato, la aprobación que depende de quién esté de turno.

Por eso en nuestro marco Valor × Complejidad la complejidad no se estima con una sola impresión. Es el promedio de cinco factores, cada uno puntuado de 1 a 5:

• Cantidad de sistemas e integraciones.
• Variabilidad del proceso (cuántas excepciones).
• Calidad de los datos y accesos disponibles.
• Riesgo del cambio en producción.
• Dependencia de terceros.

Ninguno de estos factores tiene que ver con la herramienta de automatización. Es una decisión deliberada: la herramienta casi nunca es lo que hunde un proyecto.

Una rúbrica para los cinco factores

La tabla describe los extremos y el punto medio de cada factor; 2 y 4 son valores intermedios. Como toda rúbrica, conviene calibrarla con tu propio contexto después de las primeras puntuaciones.

Factor	1	3	5
Sistemas e integraciones	Un solo sistema, con acceso directo.	Dos o tres sistemas con interfaces conocidas.	Cinco o más sistemas, o integraciones sin interfaz documentada.
Variabilidad del proceso	Un único camino, casi sin excepciones.	Algunas variantes conocidas y documentables.	Muchas excepciones; decisiones que dependen del criterio de una persona.
Calidad de datos y accesos	API documentadas, cuentas de servicio disponibles, datos confiables.	Acceso posible pero con trámites; datos que requieren limpieza.	Solo interfaz gráfica o archivos manuales; sin cuentas de servicio; datos inconsistentes.
Riesgo del cambio en producción	Solo lectura o acciones fácilmente reversibles.	Modifica configuración en sistemas no críticos, con reversión posible.	Modifica sistemas críticos con acciones difíciles de revertir.
Dependencia de terceros	Todo está bajo control del equipo.	Requiere coordinación con otra área interna.	Depende de un proveedor externo sin compromiso sobre la interfaz.

El puntaje por factor también sirve después de clasificar. En una apuesta estratégica, los factores más altos indican por dónde dividir el trabajo: si la complejidad viene de la cantidad de sistemas, la primera entrega puede cubrir solo uno; si viene del riesgo del cambio, puede empezar en modo de solo lectura, generando reportes antes de ejecutar acciones. Así cada entrega tiene una complejidad menor que el conjunto y entrega valor propio.

La variabilidad merece atención especial. Es el factor que más se subestima en la ficha y el que más se descubre durante la construcción, cuando ya es caro. Las dos secciones siguientes explican cómo descubrirla antes.

Cómo descubrir la variabilidad: el recorrido del proceso

La documentación de un proceso describe cómo debería funcionar. Para saber cómo funciona, hay que verlo. Recomendamos un recorrido del proceso con la persona que lo ejecuta, no con quien lo supervisa:

1. Observa una ejecución real. Pide a quien hace la tarea que la ejecute mientras explica cada paso en voz alta. No en una sala con diapositivas: en su pantalla, con datos reales.
2. Pregunta por cada decisión. Cada vez que la persona elige entre dos caminos, anota el criterio. "Depende" es una respuesta valiosa: ahí hay una excepción.
3. Pregunta qué sale mal. "¿Cuándo fue la última vez que esto no funcionó como siempre?" suele revelar más que cualquier diagrama.
4. Identifica el conocimiento tácito. Atajos, planillas personales, nombres de contactos a los que se escribe "cuando pasa X". Todo eso es parte del proceso real.
5. Repite con otra persona. Si dos personas ejecutan el mismo proceso de forma distinta, la variabilidad es mayor de lo que dice la ficha.

Cómo descubrir las excepciones: el muestreo de tickets

El recorrido muestra cómo se hace la tarea un día cualquiera. Los tickets muestran qué pasó durante meses. Si el proceso se registra en una herramienta de gestión de servicios, el muestreo es la forma más barata de medir la variabilidad con evidencia:

1. Toma una muestra reciente. Por ejemplo, los últimos 40 tickets del proceso, o los de los últimos tres meses si son pocos.
2. Clasifica cada ticket. ¿Siguió el camino principal o necesitó un paso adicional, una reapertura, una escalación o una consulta a otra área?
3. Agrupa las excepciones. Suelen concentrarse en pocas causas: datos de entrada incompletos, un sistema específico, un tipo de solicitud.
4. Calcula la proporción. Por ejemplo, si de 40 tickets 12 salieron del camino principal, casi un tercio de las ejecuciones necesita tratamiento especial. Eso no es un 1 en variabilidad.
5. Decide el alcance. Muchas veces conviene automatizar solo el camino principal y derivar las excepciones a una persona, con un ticket bien documentado.

Una advertencia: los tickets solo muestran lo que se registró. Si parte del trabajo se resuelve por chat o por teléfono sin ticket, el muestreo subestima la variabilidad. El recorrido del proceso ayuda a detectar esos huecos.

Datos, accesos y riesgo del cambio: preguntas antes de puntuar

Los factores técnicos se puntúan mejor con una lista corta de preguntas concretas. Si la respuesta a varias es "no sé", la complejidad real es mayor de lo que parece.

• ¿Los sistemas involucrados ofrecen API o interfaces de línea de comandos documentadas?
• ¿Existe o se puede crear una cuenta de servicio con privilegios mínimos, aprobada por seguridad?
• ¿Los datos de entrada tienen un formato estable y validable?
• ¿Hay un entorno de pruebas que se parezca razonablemente a producción?
• ¿La acción se puede simular antes de ejecutarla? Herramientas como Ansible, por ejemplo, ofrecen un modo de verificación (check mode) que informa qué cambiaría sin aplicar cambios.
• ¿Existe un procedimiento de reversión probado si la automatización falla a mitad de camino?
• ¿Algún tercero puede cambiar la interfaz sin aviso? ¿Hay un acuerdo que lo impida?

El riesgo del cambio en producción no es motivo para no automatizar. Es motivo para diseñar con más cuidado: ejecuciones por lotes pequeños, validaciones previas y posteriores, y la automatización tratada como un cambio más dentro del proceso de habilitación de cambios.

Del descarte al rediseño

Cuando un candidato cae en el cuadrante Descartar o rediseñar (valor bajo, complejidad alta), la regla del marco es clara: no se automatiza así. Primero se simplifica el proceso. Eso no significa olvidarlo; significa que el trabajo útil no es de ingeniería de automatización sino de diseño del proceso.

Las palancas de simplificación más habituales actúan directamente sobre los factores de complejidad:

• Estandarizar la entrada: un formulario con campos obligatorios en lugar de correos libres reduce la variabilidad y mejora la calidad de los datos.
• Eliminar pasos que no agregan control: aprobaciones heredadas que nadie revisa de verdad, copias de datos entre sistemas que podrían consultarse en origen.
• Acordar interfaces con terceros: un formato fijo, un canal único y un aviso previo ante cambios reducen la dependencia.
• Separar el caso común de las excepciones: si un tipo de solicitud concentra la mayoría de las excepciones, quizás deba tener su propio proceso.

Ejemplo ilustrativo. Retomemos un candidato ficticio: la conciliación mensual de inventario con un proveedor que cambia el formato de sus archivos. Sus factores de complejidad eran 3, 5, 4, 2 y 5 (sistemas, variabilidad, datos y accesos, riesgo del cambio, terceros), con una complejidad de 3,8 y un valor de 2,0: cuadrante Descartar o rediseñar.

Supón que el equipo acuerda con el proveedor un archivo con estructura fija entregado siempre por el mismo canal, y define reglas escritas para las tres excepciones más frecuentes. Al re-puntuar, la variabilidad baja a 2, los datos y accesos a 2 y la dependencia de terceros a 3. La complejidad queda en (3 + 2 + 2 + 2 + 3) / 5 = 2,4.

Con valor 2,0 y complejidad 2,4, el candidato pasa a Mejoras oportunistas. No se convirtió en una victoria rápida, y está bien: el marco no promete que todo rediseño termine en prioridad alta. Lo que sí logró el rediseño es que, cuando haya capacidad libre, automatizarlo sea una tarea acotada y no un proyecto que se arrastra.