Cómo evaluar una propuesta de automatización: qué preguntar y qué evitar
Recibir una propuesta de automatización se parece bastante a recibir un diagnóstico médico sin saber medicina: el lenguaje es técnico, todo suena razonable, y es difícil saber si lo que te están describiendo tiene sentido para tu caso específico.
El problema no es la propuesta en sí. Es no tener criterios para evaluarla.
Por qué la mayoría de las propuestas de automatización se parecen
Cuando una firma de automatización llega con una propuesta, generalmente ya tiene algo listo: una arquitectura que funcionó en otro cliente, un conjunto de herramientas conocidas, una metodología prefabricada. El trabajo de adaptar eso a tu operación ocurre después. O a veces no ocurre.
El resultado es que muchas propuestas describen con precisión qué se va a construir, pero evitan responder por qué ese proceso primero y no otro.
Esa omisión no es siempre intencional. A veces es falta de diagnóstico previo. A veces es que el proveedor parte de la herramienta, no del problema. En ambos casos, el riesgo es el mismo: automatizar el proceso equivocado, o en el orden equivocado, y descubrir el error seis semanas y varios millones después.
El costo de equivocarse no es solo el proyecto que no funcionó. Es el tiempo invertido en levantar el proceso, el retrabajo del equipo durante la implementación, y la fricción nueva que aparece cuando el flujo automatizado no encaja con la operación real. Automatizar un proceso mal priorizado no resuelve la fricción. La mueve.
Cinco preguntas que definen si una propuesta tiene lógica de negocio
Una propuesta bien construida puede responder estas cinco preguntas con claridad. Si no puede, eso ya es información.
¿Por qué este proceso y no otro? La propuesta debería explicar por qué el proceso seleccionado es prioritario: frecuencia, costo manual, impacto en el margen o en la capacidad de entrega. Si la respuesta es vaga (“porque es el más evidente” o “porque el cliente lo pidió”), falta diagnóstico.
¿Qué pasa si el proceso no está bien definido antes de automatizarlo? Automatizar un proceso mal diseñado solo acelera el error. Un buen proveedor lo dice antes de cobrar la implementación. Debería haber una fase de levantamiento y diseño explícita antes del desarrollo. Si la propuesta va directo a construir, vale la pena preguntar cómo se valida el diseño.
¿Cómo se mide el éxito? ¿En horas ahorradas? ¿En reducción de errores? ¿En tiempo de entrega al cliente? Si la propuesta no define un indicador concreto de resultado, no hay forma de saber si funcionó. “Mejora operacional” sin número no es un criterio: es una promesa sin verificación posible.
¿Qué queda documentado al final? Una implementación que solo el proveedor entiende crea dependencia estructural. La propuesta debería incluir documentación operacional que permita a alguien del equipo operar y ajustar el flujo sin conocimiento técnico profundo. Si no está contemplado, vale la pena preguntar qué pasa cuando hay que ajustar algo seis meses después.
¿Cómo funciona la adopción? El riesgo más subestimado de cualquier implementación no es técnico: es que el equipo no lo use. ¿Está contemplado el acompañamiento durante las primeras semanas de operación? ¿Hay un período de estabilización antes de que el proveedor considere el proyecto cerrado?
Señales de alerta que vale la pena tomar en serio
Ninguna de estas señales descalifica automáticamente una propuesta. Pero cada una merece una pregunta directa antes de comprometerse.
| Señal | Pregunta que hay que hacer |
|---|---|
| La propuesta menciona más herramientas que procesos | ¿Cuál es el diagnóstico de mi operación específica? |
| No hay fase de levantamiento antes del desarrollo | ¿Cómo saben qué construir si no mapearon el proceso? |
| El plazo es muy corto para la complejidad descrita | ¿Qué estamos sacrificando para llegar a esa fecha? |
| Los resultados prometidos son muy precisos sin datos del caso | ¿En qué proyecto similar obtuvieron esos números? |
| No se menciona qué pasa si el flujo falla | ¿Cuál es el plan ante una excepción no contemplada? |
| El diagnóstico y el desarrollo están en el mismo paso | ¿Cómo se valida que estamos automatizando lo correcto? |
Una propuesta seria puede responder todas estas preguntas sin defensividad. Si la respuesta a alguna es “eso lo vemos durante la implementación”, es razonable pedir más detalle antes de firmar.
Lo que no debería faltar
Más allá de las preguntas, hay elementos que una propuesta de automatización bien construida debería incluir:
Un diagnóstico documentado. No solo “identificamos los procesos a automatizar”, sino cuáles son, por qué se priorizaron y cuál es el costo actual estimado de cada uno. Sin ese documento, no hay manera de evaluar si la priorización tiene sentido para tu negocio.
Una descripción del proceso rediseñado. No solo la solución técnica: el flujo de trabajo antes y después. La automatización debería implementar un proceso mejor diseñado, no solo acelerar el proceso actual con sus problemas intactos.
Un criterio de entrega funcional. ¿Cuándo se considera que el proyecto está terminado? ¿Qué pruebas se hacen antes de pasarlo a producción? ¿Hay un período de estabilización con ajustes incluidos?
La lógica de excepciones. ¿Qué pasa cuando el flujo encuentra un caso que no estaba contemplado? ¿Se detiene? ¿Notifica? ¿Escala a alguien del equipo? Un flujo sin manejo de excepciones no está listo para operar en producción.
El criterio más importante
Al final, la pregunta más importante no es técnica. Es si el proveedor entiende el problema que estás tratando de resolver, o si está describiendo una solución que ya tenía antes de conocer tu operación.
La diferencia no siempre es fácil de detectar en una primera reunión. Se hace evidente en la propuesta: en el nivel de especificidad sobre tu caso, en si hay un diagnóstico previo documentado y en si las preguntas que hacen apuntan al negocio o solo a los sistemas.
¿Quieres saber cuánto le está costando a tu consultora la fricción que todavía no tiene nombre? Usa la calculadora de ROI de Calibria o agenda una conversación diagnóstica de 30 minutos.