Un proyecto de digitalización rara vez fracasa por la tecnología. Las herramientas actuales funcionan bien, incluidos los modelos. Lo que falla está alrededor, y casi siempre era visible en la primera reunión — si uno sabía qué mirar.
Causa 1: empezar por la tecnología
El patrón se repite: alguien de la dirección ve una demo impresionante, se aprueba un presupuesto para «hacer inteligencia artificial», y entonces se busca dónde aplicarla. Es el orden inverso al que funciona. Un proyecto que nace de una herramienta buscando problema produce demos exitosas y operaciones que no cambian.
Señal temprana: si el proyecto tiene presupuesto antes de tener un indicador operativo que mejorar, ya está en problemas. No importa qué tan bueno sea el equipo que lo ejecute. La regla inversa es la que aplicamos nosotros: se recurre a la inteligencia artificial únicamente cuando mejora un proceso medible.
Causa 2: los datos no estaban listos y nadie lo dijo
Es la causa más frecuente y la más evitable. La tecnología amplifica el estado de tus datos: si están desordenados, produce respuestas desordenadas con mucha seguridad, que es la peor combinación posible. Lo grave no es que los datos estén mal — es normal. Lo grave es que a menudo el proveedor lo sabe y no lo dice, porque decirlo pone en riesgo la venta.
Una propuesta seria incluye una evaluación honesta del estado de los datos antes de prometer resultados. Si nadie te ha preguntado dónde vive tu información y en qué condiciones está, no te están vendiendo un proyecto: te están vendiendo un presupuesto.
Causa 3: el piloto que nunca iba a escalar
Los pilotos se diseñan para demostrar y no para operar. Se ejecutan con datos escogidos, sin las excepciones reales, sin la carga real y sin los usuarios reales. Después el piloto funciona, todo el mundo aplaude, y al llevarlo a producción aparecen los casos que nadie modeló: el cliente que escribe con faltas, el producto descatalogado, el proceso que en la práctica se hace distinto a como está documentado.
Señal temprana: pregunta quién va a usar esto el día 200. Si nadie ha pensado esa respuesta, estás financiando una demo, no un sistema.
Causa 4: nadie responde por el sistema
El proyecto lo impulsa la gerencia, lo construye un proveedor, y cuando termina no queda claro de quién es. El área de TI no lo pidió y no lo entiende. El área de negocio no puede modificarlo. El proveedor ya facturó. Con el tiempo nadie lo actualiza y el sistema muere sin que nadie llegue a tomar la decisión de matarlo.
Este es también el motivo por el que el recelo del área de TI hacia un proveedor externo suele estar justificado: han visto esta película y saben quién se queda con el muerto. La única forma de desactivarlo es que alguien responda explícitamente por la operación del sistema después de la entrega, y que esté escrito quién.
Causa 5: se midió el entusiasmo, no el resultado
«El equipo está muy contento con la herramienta» no es un indicador. «Pasamos de 40 a 6 horas mensuales en este proceso» sí lo es. Cuando un proyecto no puede mostrar un número que cambió, normalmente es porque no cambió nada — y el entusiasmo tiene fecha de caducidad corta.
Las señales tempranas, en una lista
Si reconoces tres o más, revisa el proyecto
- ✓Hay presupuesto pero no hay un indicador operativo definido.
- ✓Nadie ha auditado el estado de los datos antes de la propuesta.
- ✓El área de TI no participó en la evaluación, o participó en silencio.
- ✓El éxito se va a medir con una demo ante la gerencia.
- ✓No está definido quién opera y sostiene el sistema después de la entrega.
- ✓El proveedor no ha dicho «no» a nada de lo que le pediste.
Cómo se ve un proyecto que sí funciona
Empieza por un cuello de botella medible y acotado. Define el número que debe moverse antes de escribir código. Evalúa los datos con honestidad, aunque eso retrase el inicio. Deja por escrito quién opera el sistema una vez entregado. Y contempla que la respuesta correcta pueda ser que no había que construir nada — en cuyo caso te ahorraste el proyecto entero.
En Indicium ese análisis es el descubrimiento: la primera etapa del proyecto, no un trámite previo a la venta. Produce un activo que se queda contigo pase lo que pase — el proceso documentado, los criterios de aceptación, el alcance y la ruta de evolución. A veces termina en un desarrollo, a veces en la recomendación de resolverlo con una automatización simple, y a veces en que primero hay que ordenar los datos. Las tres son respuestas útiles.
Lo que no negociamos es lo que viene después de la entrega. Construir es la parte fácil; responder por que la operación siga funcionando —operarla y hacerla evolucionar cuando el negocio cambia— es lo que separa un sistema vivo de una carpeta de código que ya nadie abre.
¿Listo para el siguiente paso?
Empecemos por descubrir dónde está el problema