El software no es un diagnóstico
Q2 2026En medicina hay una palabra para prescribir antes de examinar: negligencia. En el software empresarial se le llama proceso de ventas.
Lo digo como alguien que pasó más de una década del lado del proveedor, cerrando y entregando proyectos grandes. El mejor trabajo que hice en esos años corrió siempre igual: entender la operación con la profundidad suficiente para que la propuesta se leyera como una descripción del propio negocio del cliente, y después ajustar la tecnología a esa descripción. Los peores deals de la industria corren al revés. El proveedor llega con la prescripción escrita, la llamada de discovery es una formalidad para encontrar citas para la presentación, y el software sale a producción contra un problema que nadie examinó.
El fracaso está bien documentado. Las encuestas de la industria siguen encontrando que la gran mayoría de los proyectos de IA empresarial no llegan a generar valor en producción, y las razones citadas rara vez son el modelo o el código. Son los hechos alrededor que nadie diagnosticó: datos que resultaron desestructurados y desconectados, flujos de trabajo que nunca estuvieron definidos, costos que nunca se pesaron contra una línea base medida. Son condiciones diagnosticables. Simplemente nunca se diagnosticaron, porque el diagnóstico no estaba en el plan de comisiones de nadie.
Los compradores no son inocentes en esto. El software es una compra cómoda precisamente porque sustituye al diagnóstico. Elegir una plataforma se siente como avance y no requiere que nadie diga nada incómodo sobre el organigrama. Si el problema real es que dos ejecutivos no se han puesto de acuerdo en qué es un lead calificado, un CRM nuevo pospone esa conversación dieciocho meses a un costo de varios cientos de miles de dólares. La factura es más fácil que la reunión. He visto empresas comprar la misma categoría de herramienta tres veces en seis años, cada vez configurándola fielmente alrededor del mismo proceso sin diagnosticar, cada vez obteniendo el mismo resultado con una interfaz más nueva.
La prueba que uso es simple. Una prescripción es legítima cuando nombra la condición, y la condición tiene que enunciarse sin referencia a ningún producto. "Los deals se estancan porque no tenemos una definición compartida de calificación y los vendedores improvisan el discovery" es un diagnóstico. "Necesitamos mejor visibilidad del pipeline" es un síntoma vestido con el vocabulario de un proveedor. Si el enunciado del problema solo tiene sentido en el lenguaje de una categoría de producto, lo escribió la categoría.
Nada de esto es un argumento contra el software. Construyo con software constantemente; el trabajo de automatización del que más orgulloso estoy bajó una tarea manual de tres horas a minutos. Pero la secuencia fue diagnóstico primero: semanas mapeando cómo corría realmente el trabajo, dónde se originaban los errores y cuánto costaba un minuto de latencia, antes de escribir una línea de automatización. El software funcionó porque se ajustó a una condición examinada. El mismo software, comprado a partir de un demo un año antes, habría automatizado el proceso equivocado más rápido.
Así que la disciplina, para un comprador, se reduce a unas preguntas hechas en orden. ¿Cuál es el problema, enunciado sin sustantivos de producto en la oración? ¿Cuál es la evidencia, y cuánto nos costó el trimestre pasado, medido, no sentido? ¿Qué esperaríamos observar en noventa días si el problema estuviera realmente resuelto? Solo entonces: ¿cuál es la intervención más pequeña, herramienta, proceso, persona, o nada, que produce esa observación? Los proveedores que reciben bien esas preguntas merecen tu tiempo. Los que las esquivan te están diciendo para qué era su discovery.
El software es una prescripción. Las prescripciones son maravillosas, con una condición que la medicina resolvió hace mucho y que la compra empresarial sigue olvidando. Primero se examina.