EN CONVERSACIÓN / Inteligencia
Entrevista a Samuel Vireda, director de automatización: automatizar empieza por elegir qué merece seguir existiendo
Samuel Vireda, director de automatización, sitúa la conversación en una tensión muy concreta: un proceso automático que acelera una tarea que ya no hacía falta. Una conversación sobre tareas repetidas, decisiones humanas y cómo comprobar si una automatización ayuda a trabajar o simplemente añade otra herramienta. Recorremos las decisiones, los límites y las preguntas que aparecen cuando esas ideas llegan al trabajo cotidiano.
Por la Redacción de ContrafeedConversamos con Samuel Vireda · Director de automatización
¿Cuál es la primera pregunta antes de automatizar?
Para qué existe la tarea. Parece demasiado básica, pero evita dedicar semanas a reproducir una rutina que ya no utiliza nadie. Preguntaría quién necesita el resultado y qué decisión toma con él. Si no encontramos una respuesta clara, revisaría el proceso antes de buscar una herramienta. Un proceso innecesario no mejora por ejecutarse más deprisa.
¿Qué tarea elegirías para empezar en una agencia?
Una frecuente, acotada y fácil de comprobar. Por ejemplo, ordenar información que llega con una estructura conocida y preparar un primer borrador para revisar. Evitaría comenzar por la tarea más sensible o por la que concentra todas las excepciones. El primer proyecto debería enseñar al equipo cómo funciona el sistema, no exigir confianza ciega.
¿Cómo sabes que el ahorro es real?
Contando también la revisión y las correcciones. Si una tarea tarda menos en producirse pero obliga a comprobarlo todo desde cero, el beneficio puede ser pequeño. Miraría el recorrido completo y hablaría con quienes reciben el resultado. A veces la mejora importante es una información más consistente, aunque el tiempo no se reduzca de forma espectacular.
¿Qué responsabilidad debe conservar una persona?
La de decidir cuándo el resultado es adecuado para el contexto. Un sistema puede ejecutar una instrucción sin entender por qué hoy convendría hacer una excepción. Por eso hace falta una persona responsable, criterios para detener el proceso y una forma sencilla de revisar qué ocurrió. Automatizar no debería volver invisible la responsabilidad.
¿Qué señal te haría retirar una automatización?
Que el equipo empiece a trabajar alrededor de ella para poder cumplir su tarea. Si todos guardan una hoja paralela o corrigen siempre el mismo paso, el sistema está pidiendo una revisión. Mantenerlo porque costó mucho construirlo sólo añade otra dificultad. También forma parte del trabajo reconocer cuándo una solución dejó de ser útil.
Llevemos esta conversación a una situación concreta. ¿Por dónde empezarías?
Pensemos en un proceso automático que acelera una tarea que ya no hacía falta. Mi primer paso sería dibujar el recorrido y eliminar pasos antes de conectar herramientas. No empezaría por una presentación de soluciones. Necesitamos acordar qué problema estamos intentando resolver y qué parte depende realmente del equipo. Esa conversación inicial evita invertir el presupuesto en una respuesta vistosa que no cambia la situación de partida.
¿Qué tendría que ocurrir para que consideraras que la decisión ha funcionado?
Buscaría menos excepciones manuales y un responsable capaz de explicar cada paso. Esa señal debe acordarse antes de poner el proyecto en marcha, junto con un periodo razonable para observarla. También conservaría lo que contradiga nuestra hipótesis. Un resultado útil no es necesariamente un resultado favorable: puede enseñarnos que debemos cambiar el enfoque antes de invertir más.
¿Dónde se suele torcer el proceso cuando aparece la presión por entregar?
En encadenar servicios sin prever cómo se detecta y corrige un fallo. Es tentador porque ofrece una sensación inmediata de avance. Pero desplaza la pregunta que daba sentido al encargo. Cuando aparece esa presión, volvería al acuerdo inicial y explicaría qué se gana y qué se pierde con cada atajo. Las renuncias deben ser decisiones conscientes, no accidentes del calendario.
Con un presupuesto reducido, ¿qué protegerías y a qué renunciarías?
Protegería la posibilidad de dibujar el recorrido y eliminar pasos antes de conectar herramientas. Reduciría el número de entregables antes de quitar el tiempo necesario para entender y comprobar la idea. Una versión pequeña puede ser muy exigente si tiene un objetivo claro. Prefiero probar una decisión completa en un entorno acotado que repartir el esfuerzo entre muchas ejecuciones a medio resolver.
¿Qué conversación debería mantener la dirección con el equipo antes de dar luz verde?
Le pediría que explicara qué prioridad tiene el proyecto, quién puede tomar decisiones y qué límites no son negociables. En este caso, el objetivo sería menos excepciones manuales y un responsable capaz de explicar cada paso. Si cada persona interpreta el éxito de una manera distinta, la revisión final se convierte en una discusión de preferencias que ya no puede resolverse con el trabajo entregado.
¿Qué papel darías a la tecnología sin dejar que decida el rumbo del trabajo?
La utilizaría para comparar alternativas y reducir tareas repetitivas, pero mantendría a una persona responsable de revisar lo que cambia. El riesgo de encadenar servicios sin prever cómo se detecta y corrige un fallo también puede automatizarse. Antes de incorporar otra herramienta comprobaría qué información utiliza, qué errores produce y si el equipo puede continuar cuando esa herramienta deja de funcionar.
Para alguien que quiera aplicar esta reflexión mañana, ¿cuál sería una primera acción concreta?
Elegiría un proyecto abierto y escribiría una página con el problema, la decisión pendiente y la evidencia que falta. A partir de ahí propondría dibujar el recorrido y eliminar pasos antes de conectar herramientas. No hace falta transformar toda la organización de una vez. Hace falta que esa primera prueba deje un aprendizaje que otra persona pueda entender, discutir y utilizar en el siguiente encargo.
