Puntos clave
- Casi ninguno de los patrones de fracaso es tecnico. La tecnologia generalmente funciona. El problema casi siempre esta antes: problema equivocado, responsabilidad poco clara, sin plan de adopcion, o medicion que comienza demasiado tarde.
- El error mas costoso es automatizar antes de entender el proceso. Construir una solucion tecnicamente correcta al problema equivocado cuesta lo mismo que construir la correcta y no entrega nada.
- El entusiasmo del equipo en el lanzamiento de un proyecto de IA no es adopcion. La adopcion real es lo que ocurre seis semanas despues, cuando la novedad ha desaparecido y las personas estan bajo presion de plazos.
- La IA que es propiedad de todos no la mantiene nadie. Cada automatizacion necesita una persona nombrada cuyo trabajo sea mantenerla funcionando y mejorarla con el tiempo.
- El patron que subyace a casi todos los fracasos es el mismo: la implementacion comenzo antes de que el diagnostico estuviera completo. Dos a cuatro semanas de reflexion estructurada antes de cualquier construccion evitan la mayoria de estos problemas.
Los articulos que aparecen cuando buscas por que fracasan los proyectos de IA comparten una caracteristica comun: citan un numero y luego no explican casi nada. "El setenta por ciento de los proyectos de IA fracasan" seguido de una lista de causas abstractas como "falta de calidad de datos" o "gestion del cambio insuficiente." Probablemente cierto, y no muy util si estas en medio de un proyecto que no esta funcionando.
Este articulo adopta un enfoque diferente. Describe los errores especificos y concretos que he visto repetirse en proyectos de IA y automatizacion de diferentes tamanos y sectores. Cada uno tiene una firma reconocible: lo sabes cuando lo ves. Y cada uno tiene una correccion practica que no requiere una reestructuracion importante del proyecto.
Por que sigue ocurriendo esto
Antes de los errores individuales, vale la pena nombrar la razon estructural por la que se repiten tan consistentemente. Los proyectos de implementacion de IA tienen una presion especifica que la mayoria de los otros proyectos tecnologicos no tienen: la expectativa de resultados visibles y rapidos. La direccion ha aprobado un presupuesto basado en ahorros proyectados. Un proveedor ha demostrado capacidades impresionantes. El equipo esta entusiasmado. Hay una enorme presion para mostrar algo funcionando rapidamente.
Esta presion es la causa raiz de la mayoria de los fracasos. Empuja a los equipos a saltarse el trabajo lento y poco glamoroso de comprender el proceso actual antes de comenzar a cambiarlo. Recompensa la actividad visible (automatizaciones construidas, demostraciones entregadas) sobre los resultados reales (tiempo ahorrado, errores reducidos). Y crea un entorno donde admitir que el proyecto va en la direccion equivocada se siente como un fracaso, por lo que los problemas se acumulan silenciosamente hasta que son demasiado grandes para corregirlos de manera incremental.
Cada error a continuacion es, en cierta manera, una consecuencia de esta presion.
Los cinco errores que aparecen en casi todos los proyectos fracasados
Automatizar antes de entender el proceso
Un fundador con quien hable el ano pasado habia gastado cuatro meses y alrededor de 40,000 euros construyendo un sistema de IA para automatizar el flujo de trabajo de informes del equipo de operaciones. El sistema funcionaba. Producia informes mas rapido y con menos pasos manuales. El problema era que el flujo de trabajo de informes no era realmente el cuello de botella. El verdadero cuello de botella era el proceso de toma de decisiones que ocurria despues de que se producian los informes, que la automatizacion no tocaba en absoluto. El equipo de operaciones estaba ahorrando dos horas a la semana en la generacion de informes y seguia pasando doce horas esperando que se tomaran decisiones sobre el resultado.
Este patron se repite constantemente. Los equipos automatizan el proceso manual mas visible, no el mas valioso. Los dos raramente son lo mismo. Los procesos mas visibles son generalmente aquellos que se sienten laboriosos para las personas que los realizan. Los mas valiosos son los que en realidad estan ralentizando el negocio. Encontrar la segunda categoria requiere una fase de diagnostico antes de que se seleccione cualquier herramienta o comience cualquier construccion.
Senal de advertencia
El proyecto comenzo con una herramienta o flujo de trabajo en mente, no con un problema de negocio. Si la primera conversacion fue "automaticemos nuestro proceso X con Make" en lugar de "que es lo que realmente nos esta costando mas tiempo o dinero", el proyecto esta en riesgo de cometer este error.
Confundir el entusiasmo del lanzamiento con la adopcion
Todo proyecto de automatizacion tiene un periodo de luna de miel. El equipo usa el nuevo sistema con entusiasmo. Las metricas iniciales parecen prometedoras. La direccion declara el exito. Luego, seis u ocho semanas despues, llega una semana de alta presion. Hay plazos, aparecen casos limite, y la automatizacion requiere una solucion alternativa o produce resultados que necesitan revision. Bajo presion, las personas vuelven a lo que conocen. La automatizacion se usa selectivamente, luego ocasionalmente, y luego ya no en absoluto por algunos miembros del equipo.
La adopcion no es entusiasmo. Es lo que sucede despues de que la novedad desaparece y las personas tienen que elegir entre el nuevo sistema y sus habitos antiguos bajo condiciones reales. Los proyectos que no planifican esta transicion fracasan en la adopcion incluso cuando la tecnologia es solida. Planificarlo significa identificar las condiciones especificas bajo las cuales las personas revertiran, entrenar para esos escenarios, y tener un propietario real que note cuando el uso cae y responda a ello.
Senal de advertencia
Los datos de uso no se estan rastreando, o nadie los esta mirando. Si no puedes responder cuantos miembros del equipo estan usando la automatizacion regularmente frente a ocasionalmente frente a nada, no sabes si esta adoptada.
Elegir la herramienta antes de definir el problema
Esta es la version impulsada por el proveedor del error uno. Una empresa asiste a una demostracion, queda impresionada y se suscribe a una plataforma. La plataforma luego da forma a los problemas que se resuelven, porque el equipo naturalmente busca problemas que la herramienta puede manejar en lugar de preguntar que problemas necesitan resolverse mas urgentemente. Terminas con un espacio de trabajo de Make maravillosamente configurado que automatiza procesos que no eran realmente alta prioridad, mientras los verdaderos cuellos de botella permanecen intactos porque no se ajustan a las fortalezas de la herramienta.
El orden de las operaciones importa: define el problema primero, identifica los requisitos en segundo lugar, luego evalua las herramientas frente a esos requisitos. Esto suena obvio y es casi universalmente ignorado. La seleccion de herramientas es emocionante. La definicion del problema es lenta y a veces incomoda porque saca a la luz desacuerdos sobre lo que es realmente importante. Los equipos lo saltean precipitadamente.
Senal de advertencia
El proyecto fue iniciado por una evaluacion de herramientas en lugar de una auditoria de problemas. Si el primer paso fue comparar Zapier con Make en lugar de mapear que procesos estan costando mas tiempo o dinero, el orden esta invertido.
Sin un propietario claro de la automatizacion despues del lanzamiento
Los proyectos de IA y automatizacion frecuentemente se tratan como proyectos en lugar de productos. Tienen una fase de construccion y un lanzamiento, y luego se consideran terminados. Lo que realmente necesitan es un propietario: una persona especifica cuyo trabajo sea mantener el sistema funcionando, manejar los casos limite, actualizarlo cuando los procesos anteriores cambien, y mejorarlo con el tiempo basandose en lo que muestran los datos de uso.
Sin un propietario, la automatizacion se degrada. Los formatos de datos anteriores cambian y la automatizacion comienza a producir errores. Un paso del proceso se modifica y nadie actualiza el flujo de trabajo. Un caso limite nuevo se vuelve frecuente y se maneja con una solucion alternativa manual que nadie documenta. Seis meses despues del lanzamiento, el sistema esta parcialmente roto y parcialmente reemplazado por alternativas manuales, y nadie tiene muy claro el estado actual de que esta automatizado y que no. He visto esto en todas las organizaciones que tratan la automatizacion como un proyecto con una fecha de fin en lugar de una capacidad que requiere administracion continua.
Senal de advertencia
La persona que construyo la automatizacion ya no esta activamente involucrada y nadie ha tomado formalmente la propiedad. Pregunta quien es responsable de que la automatizacion funcione correctamente el proximo mes. Si la respuesta es vaga, la propiedad no se ha establecido.
Esperar que la IA reemplace el juicio en lugar de apoyarlo
Este error es especifico de los componentes de IA en lugar de la automatizacion basada en reglas, y es cada vez mas comun a medida que los modelos de lenguaje se integran en los flujos de trabajo empresariales. Un equipo construye un sistema donde la IA toma una decision o produce un resultado que va directamente al proceso sin revision humana. Esto funciona bien hasta que aparece un caso limite que el modelo maneja mal. Debido a que no hay un paso de revision, el resultado deficiente se propaga en cascada antes de que alguien lo detecte, y el costo del error se multiplica.
El diseno mas adecuado es tratar los resultados de la IA como entradas para el juicio humano en lugar de sustitutos de el, al menos hasta que el sistema haya demostrado una fiabilidad consistente en tus datos y caso de uso especifico. Esto significa construir un paso de revision ligero, no para cada resultado para siempre, sino durante el tiempo suficiente para comprender donde el modelo funciona bien y donde no. El objetivo no es cero participacion humana. Es la participacion humana apropiada en los puntos donde el costo de un error de IA es mas alto.
Senal de advertencia
No existe ningun paso de revision para los resultados generados por IA que ingresan a los procesos posteriores. Si el resultado de la IA se usa directamente sin ningun punto de control humano, pregunta que sucede cuando es incorrecto. Si la respuesta es "se propagara por el sistema antes de que alguien lo note", se debe agregar un paso de revision.
El patron detras de los cinco errores
Cada uno de estos errores parece diferente en la superficie. Pero comparten una raiz comun: la implementacion comenzo antes de que el diagnostico estuviera completo.
Un diagnostico adecuado, realizado antes de que se seleccione cualquier herramienta o comience cualquier construccion, expondria la mayoria de estos problemas antes de que se vuelvan costosos. Identificaria que procesos son realmente el cuello de botella, no solo los mas visibles. Sacaria a la luz desacuerdos sobre para que es realmente el proyecto. Estableceria quien es propietario de que despues del lanzamiento. Definiria como se ve el exito en terminos medibles, de modo que haya algo contra lo que rastrear en lugar de una impresion.
El diagnostico toma de dos a cuatro semanas. No es glamoroso. No produce nada inmediatamente visible. Es la parte que la mayoria de las organizaciones omiten porque la presion para mostrar progreso ya es alta antes de que el proyecto haya comenzado oficialmente.
La ironia es que omitirlo no acelera el proyecto. Acelera la llegada a un punto donde el proyecto necesita reiniciarse parcial o totalmente. El tiempo perdido en una mala construccion mas un reinicio es casi siempre mas largo que el tiempo que habria llevado un diagnostico.
Para un marco practico sobre como medir si un proyecto de IA esta funcionando una vez que esta en marcha, consulta como medir el ROI de un proyecto de automatizacion de IA. Para orientacion sobre que procesos automatizar primero, consulta automatizacion de IA para startups y pymes.
Que hacer si reconoces tu proyecto en esta lista
Si estas leyendo esto porque un proyecto ya esta en problemas, el primer paso es separar los problemas tecnicos de los estrategicos. Los problemas tecnicos (la automatizacion no es confiable, la calidad del resultado es deficiente, el sistema falla con ciertas entradas) a menudo se pueden corregir sin reiniciar. Los problemas estrategicos (estas automatizando el proceso equivocado, nadie posee el sistema, el equipo no lo esta usando realmente) requieren volver al diagnostico antes de agregar mas trabajo tecnico.
Agregar funciones o complejidad a un proyecto con un problema estrategico hace que el problema estrategico sea mas costoso de abordar mas adelante, no menos. El instinto cuando un proyecto no esta funcionando es hacer mas. Por lo general, el movimiento correcto es pausar, diagnosticar y decidir si lo que se ha construido vale la pena continuar o si los recursos se gastan mejor comenzando desde un problema mejor definido.
Esta es una conversacion incomoda de tener internamente, que es a menudo por que no sucede hasta que el problema es muy grande. Una perspectiva externa, ya sea de un consultor, un asesor o incluso un par que ha pasado por una situacion similar, puede facilitar ver el proyecto con suficiente claridad para tomar una buena decision al respecto.
Trabaja con Ipernovation
Reconoces alguno de estos patrones en un proyecto que estas gestionando?
Una sesion de diagnostico enfocada puede identificar con cual de estos problemas te enfrentas y cual es el siguiente paso practico. Sin presentacion, sin propuesta: una conversacion directa sobre tu situacion especifica.
Iniciar una conversacion