Noticias, guías y análisis
Cómo auditar una automatización después de cambiar de proveedor
Una auditoría posterior a la migración verifica que el nuevo proveedor no solo ejecute el flujo, sino que conserve reglas, contexto, evidencia y resultados esperados.
Define qué significa equivalencia. Antes de revisar, recupera el objetivo y los criterios del sistema anterior. No basta con confirmar que el nuevo proveedor recibe una entrada y produce una salida. La equivalencia puede incluir campos, orden, tiempo, permisos, mensajes, excepciones y posibilidad de deshacer. Escribe una lista de comportamientos observables y clasifica cuáles son obligatorios y cuáles pueden cambiar. Sin esa referencia, la auditoría termina evaluando si la nueva interfaz parece funcionar, no si el proceso conserva su propósito.
Compara casos normales y casos difíciles. Ejecuta un conjunto común de pruebas con datos representativos, errores, campos vacíos, duplicados y solicitudes fuera de alcance. Usa exactamente las mismas entradas cuando sea posible y conserva resultados de ambas plataformas. Las diferencias deben explicarse, no ocultarse dentro de una impresión general. Un proveedor puede mejorar velocidad y empeorar manejo de excepciones. La auditoría necesita mostrar qué cambió, qué impacto tiene y si la organización acepta esa variación como parte de la nueva arquitectura.
Revisa contexto y memoria. Muchas migraciones pierden instrucciones, etiquetas, historiales o asociaciones que no estaban en el archivo principal. El nuevo sistema puede producir una respuesta correcta durante la prueba y fallar semanas después porque no conserva continuidad. Verifica qué información se migró, qué quedó archivada y qué debe reconstruirse. También prueba separaciones entre clientes y proyectos. Una memoria incompleta es un riesgo, pero una memoria mezclada entre contextos puede ser todavía más grave.
Audita identidades y permisos desde cero. No copies automáticamente las autorizaciones del proveedor anterior. La nueva plataforma puede interpretar roles de manera distinta o incluir capacidades adicionales. Lista cada identidad, sistema y acción permitida. Confirma que las cuentas de prueba fueron eliminadas y que las credenciales antiguas quedaron revocadas. También revisa registros de acceso y alertas. Una migración que mejora funciones pero deja dos proveedores activos con permisos amplios aumenta la superficie de riesgo en lugar de sustituirla.
Mide el recorrido completo y el costo real. Incluye preparación de datos, ejecución, revisión, corrección, soporte y mantenimiento. El precio por uso puede ser menor mientras el equipo dedica más tiempo a validar resultados. También puede existir costo de almacenamiento, conectores, observabilidad o planes superiores. Compara durante un periodo suficiente para observar variación y no solo una demostración. La auditoría debe distinguir ahorro técnico de ahorro operativo y mostrar qué trabajo cambió de lugar después de la migración.
Conserva trazabilidad y plan de reversión. Verifica que cada acción pueda relacionarse con una entrada, una versión y una decisión. Prueba exportaciones y recuperación de configuraciones. Si el nuevo proveedor falla, el equipo necesita saber cómo volver temporalmente al proceso anterior o a un modo manual. No es necesario mantener dos plataformas completas indefinidamente, pero sí conservar datos y documentación durante una ventana de estabilización. Cerrar demasiado pronto elimina evidencia justo cuando aparecen errores tardíos.
Cierra con una revisión de resultados. Después de treinta o sesenta días, compara calidad, tiempo, incidentes, adopción y satisfacción con la línea base. Documenta diferencias, decisiones y tareas pendientes. La migración se considera completa cuando el proceso cumple el objetivo, los permisos antiguos están cerrados y existe evidencia de estabilidad. Si los resultados no mejoran, evita defender el cambio por costo hundido. Una auditoría posterior permite corregir configuración, renegociar o reconsiderar al proveedor antes de que la nueva dependencia se vuelva irreversible. Esta revisión adicional debe quedar documentada dentro del proceso de migración, con responsable, fecha y evidencia suficiente para comparar el resultado en la siguiente iteración.