Ingeniero de automatización: cómo elegirlo

Qué debería entregar realmente un buen ingeniero de servicios de automatización

Quien busca un buen ingeniero de servicios de automatización suele querer un atajo: un nombre de confianza que haga un proceso más rápido o más barato. No existe una clasificación neutral de ingenieros de automatización, y cualquier página que afirme serlo merece escepticismo. Lo que sí se puede evaluar es cómo trabaja un candidato: si convierte una petición vaga en algo observable, si dice que no a parte de ella y si define cómo se comprobará el éxito una vez que el sistema esté en funcionamiento.

Este artículo lo publica Victor Laybats, un ingeniero con sede en París que ofrece ingeniería de IA y automatización y documenta un método de trabajo que abarca la definición del alcance, la puesta en producción y el periodo de seguimiento posterior. Por tanto, es una guía de un proveedor, no una revisión independiente. No clasifica a nadie, no compara competidores con nombre y no informa de resultados de clientes. Su objetivo es dar a directivos y equipos de negocio preguntas que sigan siendo válidas sea quien sea la persona que acaben contratando.

El principal límite que hay que tener presente es que ningún ingeniero controla el resultado completo. Lo que consigue una automatización depende del proceso al que afecta, de los sistemas ya existentes y de la calidad de los datos que recibe. Un buen ingeniero hace visibles esas dependencias desde el principio en lugar de esconderlas en una estimación optimista.

Empezar por un proceso con responsable, no por una plataforma

Una primera conversación útil describe un único proceso: qué lo desencadena, qué resultado de negocio debe producir, quién es su responsable y qué sistemas toca. Las peticiones que empiezan por una herramienta preferida o por un deseo general de usar IA suelen producir demostraciones en lugar de sistemas operables. Un ingeniero competente debería poder reducir tu petición a un flujo de trabajo que se pueda observar, probar y detener, manteniendo visibles las decisiones que siguen en manos de personas.

Es de esperar que un primer encargo serio recomiende dejar parte del proceso en manual. Un volumen bajo, mucho criterio humano, una responsabilidad poco clara o interfaces a las que no se puede acceder de forma fiable son razones legítimas para aplazar la automatización. Un ingeniero dispuesto a decirlo te protege de un sistema que nadie puede gestionar con seguridad, y eso vale más que un prototipo impresionante.

El objetivo de negocio explícito importa porque es lo único que después permite decidir si el proyecto ha funcionado. Si nadie puede formularlo en una sola frase, el proyecto no está listo para un presupuesto de desarrollo.

El entregable de descubrimiento que hay que pedir antes de escribir código

El filtro más práctico es pedir un entregable de descubrimiento acotado antes de la implementación. Convierte las propuestas en documentos comparables y saca a la luz supuestos que, de otro modo, aparecerían como retrasos o facturas adicionales. Debe separar claramente lo que se ha observado en tu entorno de lo que se supone o se planifica para más adelante.

Pregunta qué elementos requieren acceso personal, aprobación de un proveedor de software o autorización de la empresa. Son dependencias reales y deben figurar en el plan, no quedar enterradas en una estimación de entrega. Un diagrama solo sirve si cada conexión que muestra corresponde a una interfaz que alguien ha verificado realmente.

• Un mapa del único flujo de trabajo incluido en el alcance, con responsables identificados
• Un inventario de integraciones comprobadas, no supuestas
• Una clasificación de los datos implicados y de adónde pueden ir
• Las acciones que la automatización puede realizar y las que no
• Los puntos en los que una persona revisa o aprueba antes de continuar
• Los casos de fallo conocidos y quién se encarga de la recuperación
• Los objetivos excluidos de forma explícita y un plan para medir los resultados

Datos controlados y revisión humana como criterios de selección

Datos controlados significa saber qué información lee la automatización, adónde se envía, quién puede verla y qué ocurre si es errónea. Al evaluar a un ingeniero, pregúntale cómo limitaría el acceso de la automatización a lo estrictamente necesario para el flujo de trabajo y cómo se detectarían los errores en los datos de entrada antes de que desencadenen una acción. Las respuestas vagas en este punto son una señal de alarma más fuerte que la falta de dominio de una herramienta.

La revisión humana no es señal de una automatización débil. Es la forma de que la responsabilidad siga en la empresa para las decisiones con riesgo: pagos, compromisos con clientes, eliminaciones o mensajes enviados al exterior. Una buena propuesta indica los momentos exactos en los que una persona aprueba, edita o rechaza, y explica qué hace el sistema mientras espera.

Pregunta también cómo se puede detener la automatización. Un proceso que no se puede pausar limpiamente, o que falla sin avisar, traslada el riesgo a quien descubra el problema más tarde, a menudo un cliente.

Medir en producción y los límites de la prueba

La medición debe acordarse antes de construir: una referencia de cómo funciona el proceso hoy, el indicador que debería cambiar y cómo se interpretará una vez que el sistema esté en uso real. Sin una referencia, cualquier afirmación sobre tiempo ahorrado es una conjetura. La medición en producción también revela desviaciones, como el aumento de las excepciones o de las correcciones manuales, que una demostración nunca muestra.

Trata con cautela los prototipos, las arquitecturas de referencia y los elementos de portfolio. Pueden ilustrar un método, pero no son prueba de retorno de la inversión ni de un resultado para un cliente. El estudio IVRYN, que Victor Laybats fundó y dirige, indica abiertamente que figurar en su portfolio no implica ningún resultado de cliente ni respaldo, lo cual es un estándar razonable que esperar de cualquier proveedor que evalúes.

Si un candidato ofrece ahorros garantizados o un porcentaje fijo de mejora antes de ver tu proceso, esa cifra no puede basarse en tu contexto. Pregúntale en cambio qué va a medir y cuándo lo revisaréis juntos.

Ejemplo: comparar dos propuestas hipotéticas

Ejemplo hipotético: un equipo de finanzas quiere que las facturas de proveedores se lean y registren automáticamente. La propuesta A nombra una plataforma, muestra una demostración pulida y ofrece un precio de desarrollo cerrado. La propuesta B pide dos semanas de descubrimiento y entrega un mapa del flujo de trabajo, una lista de interfaces verificadas del sistema contable, una regla según la cual las facturas por encima de un importe determinado esperan la aprobación de un responsable y una nota indicando que las facturas manuscritas siguen siendo manuales.

La propuesta A parece más rápida, pero nada en ella indica qué ocurre cuando un proveedor cambia de formato, quién corrige un registro erróneo o cómo se comprobará la precisión. La propuesta B es menos llamativa y más útil: puedes verificar lo que afirma, ver qué queda excluido y acordar de antemano cómo se medirán los resultados. En este ejemplo, B es la opción más segura aunque su desarrollo posterior no sea más barato.

Aplica la misma prueba a cualquier propuesta real: si quitaras el nombre del proveedor, ¿podría otro ingeniero retomar el documento y entender el alcance, los riesgos y los criterios de éxito? Si no es así, la propuesta no está terminada.