Por qué la consultoría IA tradicional falla en mid-market

Hay un patrón que se repite en muchas conversaciones con fundadores de empresas entre cinco y veinte millones. Hace doce o dieciocho meses contrataron a una consultora reconocida para un proyecto de IA. Pagaron una cantidad seria. Recibieron entregables. Y hoy, sentados delante nuestro, intentan explicar por qué nada de aquello acabó funcionando.

No es mala suerte. Es estructural. La consultoría IA tradicional, tal y como se vende desde firmas grandes y medianas, no está diseñada para empresas mid-market. Funciona razonablemente bien en grandes corporaciones, donde hay equipos internos que pueden absorber lo que la consultora deja a medias. En empresas medianas, no hay esa capa, y por tanto el modelo no encaja. Vale la pena explicar las razones, porque entenderlas evita repetir el error.

Razón uno: el ciclo de venta exige proyectos que justifiquen el esfuerzo

Una consultora grande no se mueve por proyectos pequeños. El coste de adquirir un cliente, hacer la propuesta y montar el equipo es alto, lo que obliga a vender proyectos grandes. Para una empresa mid-market, "grande" significa un alcance que excede su problema real. Lo que necesitaba era un agente de clasificación de tickets. Lo que recibe es una transformación digital de seis fases con un comité de gobierno.

El resultado predecible es que el proyecto se convierte en un ejercicio de discovery interminable, con muchas reuniones, muchos diagramas y poco software funcionando. Cuando llega el momento de implementar, ya se ha quemado la mitad del presupuesto en estrategia y nadie se atreve a decir en voz alta que el alcance era demasiado grande para empezar.

Razón dos: pruebas de concepto que no escalan

El modelo clásico de la consultoría grande es el POC. Tres o seis meses para construir una prueba de concepto, demostrar que la tecnología funciona, y luego pasar a una fase de implementación que casi nunca llega. La razón es que la prueba de concepto se diseñó para impresionar a un comité, no para integrarse con los sistemas reales de la empresa.

Cuando llega el momento de pasar a producción, el coste de adaptar la prueba a la realidad operativa es tan alto como construirla desde cero. La empresa, que ya ha gastado un dinero importante, tiene que decidir si gasta otra cantidad similar para tener algo en producción o si guarda la presentación y sigue adelante. La inmensa mayoría guarda la presentación.

Razón tres: equipos júnior con la marca encima

Una consultora grande vende con sus partners y entrega con sus consultores. La diferencia es enorme. El partner que inspira confianza en la fase de venta aparece tres veces durante el proyecto, en momentos protocolarios. El día a día lo lleva un equipo donde la mayoría tiene menos de cinco años de experiencia y aprende sobre la marcha.

En una corporación grande, esto se compensa con un equipo interno que sabe lo que hace y reorienta a la consultora cuando hace falta. En una empresa mediana, ese equipo interno no existe, y el cliente no tiene cómo detectar a tiempo que el trabajo se está haciendo con criterio insuficiente. Los problemas aparecen en producción, cuando ya no hay vuelta atrás.

Razón cuatro: nadie opera lo que se entrega

Probablemente la razón más importante. Una consultora tradicional entrega un sistema y se va. El contrato de mantenimiento es opcional, suele ofrecerse en condiciones poco atractivas, y casi siempre cubre solo errores técnicos, no evolución. La empresa hereda un sistema que funciona el primer mes, se degrada en silencio durante los siguientes seis y se apaga sin ruido al año.

En los proyectos donde trabajamos, este es el factor que más diferencia el éxito del fracaso. Un sistema de IA es un producto vivo. Necesita alguien que lo observe, lo ajuste, lo mejore. Esa función no se entrega, se opera. Y el modelo de consultoría tradicional no está diseñado para operar.

Síntomas que indican que estás cayendo en este patrón

• La propuesta tiene fases con nombres como "discovery", "ideation" y "transformation", pero ninguna entrega software funcionando antes del mes tres.
• El equipo asignado al proyecto cambia entre la venta y la ejecución.
• No hay un compromiso explícito sobre qué pasa al mes seis o al mes doce, más allá de un contrato de soporte estándar.
• Las métricas de éxito están redactadas en términos de adopción y satisfacción, no en términos de horas ahorradas o ingreso incremental.
• El presupuesto incluye una partida muy grande de "gestión del cambio" sin un entregable concreto detrás.

Lo que sí funciona en mid-market

En empresas medianas, lo que vemos funcionar tiene rasgos opuestos al modelo tradicional. Proyectos pequeños bien definidos, con software funcionando antes del mes dos. Equipos sénior implicados desde el primer día, no consultores júnior con la marca de un partner detrás. Compromiso explícito de operación durante meses o años, no entrega y olvido. Métricas concretas de negocio, no indicadores de adopción.

No es necesariamente más caro. A menudo es más barato, porque no hay overhead de gobierno ni capas intermedias. Lo que es distinto es el enfoque: construir lo justo, operarlo bien, ampliar cuando lo construido demuestra valor. Es menos espectacular en una presentación de venta. Es mucho más probable que funcione.

Una nota personal

No escribimos esto para atacar a las consultoras grandes. Hacen un trabajo razonable en su segmento natural, que es el enterprise. El problema aparece cuando aplican el mismo modelo a empresas que no tienen la estructura para absorberlo. La conversación honesta, en este caso, es señalar a un fundador entre cinco y veinte millones que su problema no se resuelve con el modelo grande, y que hay alternativas mejor diseñadas para su tamaño. Quien lea este post sabiendo que está repitiendo este patrón, tiene un buen motivo para parar y reconsiderar antes del siguiente cheque.