Cómo detectar fallos de una automatización antes de implantarla

Qué vas a practicar

Proponemos una revisión previa del piloto: imaginar fallos concretos, buscar cómo detectarlos y convertirlos en pruebas. Los escenarios son hipótesis de trabajo de Olduvia, no predicciones ni incidencias de clientes. El objetivo es decidir con evidencia qué puede pasar a producción.

Define qué significa que el piloto funcione

Acota un proceso, una entrada, una integración principal y una persona responsable. Escribe qué resultado esperas y con qué compararás el trabajo. Si quieres reducir tareas repetitivas, mide también la revisión, las correcciones y el tiempo dedicado a resolver excepciones.

Distingue un supuesto de un hecho comprobado. «El programa permite crear borradores por API» es un supuesto hasta verificar acceso, permisos y funcionamiento. «El equipo revisará todas las incidencias» necesita una persona, una cola visible y tiempo asignado.

Ejemplo: del correo a un pedido pendiente de aprobación

Caso ficticio: una distribuidora recibe solicitudes por correo. La automatización extrae cliente, referencia y cantidad, consulta el catálogo y prepara un pedido en su sistema. Una persona confirma las condiciones antes de aprobarlo.

Imagina que el piloto se detiene tras dos semanas. En lugar de decir que «la IA falló», plantea secuencias que puedas comprobar. Los escenarios siguientes son ejemplos para preparar pruebas; no llevan probabilidades inventadas.

• Un correo reenviado se interpreta como un pedido nuevo: aparecen dos borradores para la misma solicitud. Comprueba identificación de duplicados y registro de reintentos.
• Una referencia antigua se parece a otra vigente: el sistema propone un artículo incorrecto. Prueba cómo se bloquea una coincidencia dudosa.
• La conexión se interrumpe después de crear el registro: el reintento puede duplicarlo. Verifica cómo se consulta el resultado antes de repetir la acción.
• La cola de excepciones crece sin que nadie la atienda: el trabajo queda parado. Define responsable, aviso y tiempo de respuesta acordado.

Plantilla para revisar tu propio plan

Pide escenarios vinculados al proceso descrito. Una lista de riesgos genéricos aporta poco si no cambia las pruebas del piloto.

Revisa este plan de automatización antes del piloto. Resume el proceso, el resultado esperado y los supuestos aún sin verificar. Propón hasta cuatro escenarios concretos de fallo como hipótesis, sin inventar probabilidades. Para cada uno indica: desencadenante, secuencia del fallo, efecto observable, señal temprana, prueba que lo detectaría y responsable de resolverlo. Separa errores de ejecución de supuestos equivocados. Indica cuándo habría que detener la operación y qué necesitaríamos para volver al proceso anterior. Si falta información, formula preguntas. Termina con el supuesto que conviene comprobar primero.

PROCESO Y LÍMITES: [descripción]
PLAN DEL PILOTO: [pasos, herramientas y permisos]
CRITERIOS DE ACEPTACIÓN: [los acordados o pendientes]

Convierte cada escenario en una prueba con resultado esperado

Para un duplicado, define qué identificador se conserva y qué debe ocurrir al repetir la entrada. Para un documento incompleto, concreta qué campo bloquea el avance. Para una caída de conexión, comprueba qué quedó registrado antes de reintentar.

Ensaya primero con copias y permisos limitados. Incluye casos habituales y excepciones conocidas. No existe un tamaño de muestra universal: el volumen, la variedad y las consecuencias del error determinan qué evidencia necesita el responsable. Una demostración con tres casos correctos no acredita el funcionamiento general.

Decide cuándo avanzar y cuándo parar

• Avanzar: criterios acordados satisfechos, excepciones visibles y una persona capaz de operar y revisar el proceso.
• Corregir y repetir: hay fallos localizados y una modificación concreta que se puede volver a probar.
• Detener: no se pueden verificar los resultados, faltan permisos o el proceso puede ejecutar acciones fuera del alcance autorizado.
• Volver atrás: conserva el procedimiento manual, los registros y un responsable para reconciliar lo ocurrido. Una copia de seguridad no deshace un correo enviado.

Qué se entrega en el diagnóstico de Olduvia

Esta revisión forma parte del diseño del piloto: supuestos visibles, tareas que puede ejecutar la automatización, comprobaciones humanas, señales de fallo y criterios para detenerse. No exige un servicio independiente ni sustituye las pruebas con el sistema real.

Después del arranque, mide uso, errores y excepciones. Una nueva tarifa, un cambio de formato o una modificación de permisos puede justificar repetir parte de la evaluación. Amplía el alcance cuando los resultados lo sostengan.

Ver cómo definimos y comprobamos un piloto ↗