La primera junta con un cliente nuevo casi siempre empieza igual. Alguien te presenta, hay café, y a los diez minutos el director te explica lo que necesita. Ya lo trae pensado, a veces incluso escrito. Quiere un reporte que le muestre X, quiere automatizar tal proceso, quiere que el sistema haga lo que hoy hacen tres personas en Excel.
Y ahí es donde empieza el trabajo real, porque lo que te acaban de pedir rara vez es lo que hace falta.
No lo digo como crítica al cliente. Él conoce su negocio mucho mejor que tú, y por eso mismo llegó a una conclusión razonable desde adentro. Lo que no conoce es el catálogo de soluciones posibles. Tú tampoco conoces su operación. El valor del consultor está justo en ese cruce, y solo aparece si dedicas tiempo a entender antes de proponer.
El problema que te plantean casi nunca es el problema
Te piden reproducir un reporte que alguien arma cada semana en Excel. Preguntas para qué se usa, y resulta que el director solo revisa tres cifras del final. Esas tres cifras ya están en el sistema, en una pantalla que nadie le enseñó a abrir. Lo que parecía dos semanas de desarrollo se resuelve en una capacitación de veinte minutos.
Te piden automatizar un proceso de autorización, y al recorrerlo descubres que el proceso existe porque hace cinco años hubo un fraude y nadie ha vuelto a evaluar si sigue teniendo sentido. Automatizarlo sería congelar en código una regla que ya nadie defiende.
La herramienta más útil que tengo no es técnica. Es preguntar «¿y esto para qué lo usas?» tres veces seguidas, con genuina curiosidad, hasta llegar al motivo de fondo. Suena obvio. Casi nadie lo hace, porque cuestionar al cliente en la primera reunión se siente incómodo y porque decir que sí es más rápido.
Otra cosa que ayuda: pedir que te muestren cómo trabajan hoy. No que te lo cuenten, que te lo enseñen en pantalla, con sus documentos reales, con sus casos raros. Cómo trabajan hoy define el piso mínimo que tienes que cubrir. Lo que dicen que quieren en el futuro es una lista de deseos armada desde las limitaciones de su sistema actual, y buena parte se cae sola cuando ven una forma distinta de hacer las cosas.
En una empresa del sector agropecuario, mientras revisaba con los usuarios qué actividades repetían cada semana, salió una que no estaba en el levantamiento de requerimientos. Cada embarque llega acompañado de un documento oficial en papel donde viene la identificación individual, alrededor de setenta por camión. El auxiliar administrativo capturaba esas identificaciones una por una en una hoja de cálculo y después cotejaba la lista contra lo que se había leído físicamente al momento de la recepción. El documento ya se escaneaba, pero solo para archivarlo: el archivo se guardaba y nadie lo volvía a abrir.
Nadie lo mencionó como problema porque siempre se había hecho así. La automatización terminó apoyándose en ese mismo escaneo que ya existía, para extraer las identificaciones y conciliarlas contra lo capturado. No es infalible, depende de qué tan limpio salga el escaneo del papel, así que las lecturas dudosas se marcan para revisión en lugar de darlas por buenas. Lo que me quedó del caso no fue la solución, fue que apareció por preguntar qué hacían todos los días, no por preguntar qué querían.
La confianza se gana en las primeras semanas
Entras a una empresa donde nadie te pidió estar. Para el equipo operativo eres una decisión que se tomó en una oficina sin consultarlos, y muchas veces la leen como una amenaza: alguien va a documentar cómo trabajan, alguien va a encontrar lo que no se está haciendo bien, alguien puede terminar recomendando que sobra gente.
Esa lectura no es paranoia. Es una interpretación razonable de la situación, y si no haces nada para desactivarla, va a definir todo el proyecto. Los proyectos que se atoran rara vez se atoran por razones técnicas. Se atoran porque las personas que tienen que usar el sistema nuevo no quieren que funcione.
Lo que funciona es sencillo y toma tiempo: llegar como alguien que viene a facilitarles el día, no a evaluarlos. Escuchar de verdad las quejas sobre el sistema anterior, que suelen ser la mejor fuente de requerimientos que vas a conseguir. Y ser especialmente paciente con quien más se resiste, porque casi siempre es la persona que mejor conoce los detalles finos de la operación. El que cuestiona cada pantalla en la capacitación es el que va a estar listo el día del arranque. El que asiente y no pregunta es el que te va a llamar en pánico la primera semana en producción.
Decir que no también es parte del servicio
Aquí está la parte del oficio de la que poco se habla, porque no queda bien en un folleto.
Un consultor que dice que sí a todo no está dando servicio, está tomando pedidos. Y es una forma cara de fallarle al cliente, porque cada petición aceptada sin filtro tiene un costo que no se ve en la cotización: alarga el proyecto, complica el sistema, y deja algo que hay que mantener y actualizar durante años. Un desarrollo a la medida no se paga una vez. Se paga cada año, en mantenimiento, en actualizaciones, y en la libertad que pierdes para moverte a la siguiente versión.
Así que la conversación difícil hay que tenerla, y de preferencia temprano. Explicar por qué algo no conviene, proponer una alternativa, y sostener la postura cuando el cliente insiste. A veces el cliente se molesta. Es un costo aceptable, porque el que se molesta hoy porque le discutes una funcionalidad es el mismo que se molestaría en un año cuando el proyecto lleve seis meses de retraso y el presupuesto se haya duplicado.
Esto solo se puede hacer desde un lugar honesto: si dices que no, tiene que ser porque analizaste el costo contra el beneficio y no cuadra, no porque no sabes hacerlo o no te conviene. La diferencia se nota. Y la única forma de que te crean el «no» es que hayas dedicado tiempo real a entender por qué lo pedían.
Una solución que depende de ti no es una buena solución
Hay una tentación permanente en este trabajo, y es volverte indispensable. Configurar cosas que solo tú entiendes, resolver las dudas en lugar de enseñar a resolverlas, quedarte con el conocimiento del sistema.
Es rentable a corto plazo y es una mala forma de trabajar. El objetivo debería ser el contrario: que el cliente termine el proyecto sabiendo operar su sistema, con alguien adentro que entiende por qué está armado como está. Eso significa que la capacitación no es una demostración donde tú manejas el teclado, es una sesión donde ellos lo manejan y tú corriges. Significa que la documentación de sus procesos la escriben ellos, con su terminología, porque escribirla es lo que garantiza que la entendieron.
La paradoja es que funciona mejor comercialmente. Un cliente autónomo y satisfecho te vuelve a llamar para el siguiente proyecto. Un cliente atrapado te llama con resentimiento hasta que encuentra a alguien más.
Al final
Ser consultor no es saber más que el cliente. En su negocio, nunca vas a saber más que él. Es haber visto suficientes operaciones parecidas como para reconocer patrones, tener criterio para distinguir lo que importa de lo que no, y suficiente carácter para decirlo aunque no sea lo que quieren oír.
Lo demás se acumula con los años, un proyecto a la vez.