Cómo formar un equipo: Construyendo una verdadera alianza entre consultores funcionales y técnicos
(Parte 2 de 5 de la serie “El código humano de la ERP”)
Seamos honestos. Si has dedicado algún tiempo a la implementación de software empresarial, probablemente hayas notado que suele haber mala relación entre los consultores funcionales y los técnicos.
Entre ellos existe un abismo de malentendidos, correos electrónicos pasivo-agresivos y retrasos en los plazos de los proyectos.
El incidente de integración simple
He visto proyectos paralizarse durante semanas simplemente porque dos profesionales hablaban idiomas completamente diferentes.
Imagínese una reunión de alineación típica. El consultor funcional, recién salido de un taller con el cliente, se inclina hacia adelante y dice: El cliente necesita sincronizar el software de fabricación con el ERP. Es muy sencillo. Solo necesitamos crear una integración simple con su MES actual para enviar los datos.
El problema radica en que el consultor funcional presenta la solución como "fácil" principalmente porque no es él quien tiene que escribir el código. Proporciona muy pocos detalles y resta importancia a la ejecución técnica, subestimando por completo las complejas implicaciones técnicas que conlleva.
Para el consultor, una integración es simplemente un puente conceptual. Para el desarrollador, esa misma "integración simple" representa una pesadilla de estructuras de carga útil, errores de tiempo de espera, tokens de seguridad y validaciones de datos faltantes.
Cuando el desarrollador inevitablemente señala estas complejidades, surge una fricción innecesaria. El consultor funcional piensa que el desarrollador está complicando innecesariamente un requisito del negocio. El desarrollador siente que el consultor funcional está trivializando su arduo trabajo y haciendo promesas imposibles al cliente.
Lo cierto es que, como consultor funcional, el trabajo presenta dificultades que el desarrollador no puede comprender, y viceversa. El desarrollador no tiene que enfrentarse a las exigencias irracionales de un cliente en pánico, y el consultor funcional no tiene que lidiar con la lógica implacable de la arquitectura de sistemas. Ninguna profesión es menos importante ni más sencilla que la otra. Simplemente se enfrentan a desafíos únicos que la otra rara vez experimenta.
El verdadero enemigo en esta sala es el ego y la falta de entendimiento mutuo.
Bienvenidos a la segunda parte de El Código Humano de los ERP. Hoy vamos a derribar las barreras que existen entre quienes diseñan los procesos de negocio y quienes realmente tienen que implementarlos.
Estamos hablando de cómo forjar una alianza infalible entre los equipos funcionales y técnicos.
Dos mundos, dos idiomas
Para resolver este conflicto, primero debemos comprender la causa raíz. Los consultores funcionales y técnicos viven en dos realidades completamente diferentes.
El consultor funcional vive en el complejo e impredecible mundo de los negocios. Recorre la planta de producción. Observa el esfuerzo físico de los operarios. Lidia con la ansiedad del director financiero y con la manera caótica e ilógica en que las personas realizan sus tareas diarias. Su objetivo es lograr que el negocio funcione sin problemas.
El consultor técnico vive en un mundo de lógica binaria absoluta. A una tabla de base de datos le da igual si el gerente del almacén está teniendo un día estresante. La arquitectura de un sistema exige reglas rígidas, definiciones precisas y cero ambigüedad. Su objetivo es lograr que el sistema sea estable, seguro y de alto rendimiento.
Cuando estos dos mundos chocan sin un traductor, el resultado es un desastre. Se obtiene una integración de sistemas técnicamente impecable, pero completamente inútil para los operarios de planta, ya que no tiene en cuenta las demoras físicas que produce una carretilla elevadora al mover palés.
El mito del consultor técnico
Existe la creencia errónea de que, para superar esta brecha, un consultor funcional necesita aprender a programar. Esto es completamente falso. Un buen consultor funcional de ERP no necesita saber programar scripts ni escribir consultas SQL complejas.
Sin embargo, es absolutamente imprescindible que sepan cómo piensa.
No es necesario saber cómo escribir la carga útil de la API. Sin embargo, es fundamental comprender que cuando un sistema envía un mensaje, espera una respuesta específica, y se debe diseñar un proceso de negocio para lo que sucede si dicha respuesta nunca llega. Es imprescindible comprender la diferencia entre una tabla de datos maestros y una tabla transaccional. Asimismo, es fundamental comprender los principios básicos de la arquitectura de sistemas.
Tu verdadera labor como consultor funcional es ser el traductor humano por excelencia. Eres el puente, no un programador. Debes tomar las necesidades caóticas y emocionales del negocio y traducirlas en marcos lógicos y claros con los que un desarrollador pueda trabajar eficazmente.
Protegiendo las trincheras
El peor tipo de consultor funcional es el ejecutor ciego. Este es el consultor al que no le importa realmente la necesidad real del negocio. Ejecuta órdenes como un simple soldado, escuchando una solicitud de personalización ilógica o completamente inviable del cliente, transcribiéndola tal cual y entregándola directamente al equipo técnico sin cuestionarse si tiene sentido.
La arquitectura moderna de CloudSuite impide dañar la base de datos, pero los usuarios seguirán solicitando modificaciones que contradicen por completo la lógica estándar del sistema. Cuando el desarrollador inevitablemente señala que la solicitud es técnicamente absurda, este tipo de consultor simplemente se encoge de hombros y dice: «No me culpen. Es lo que el cliente quiere»
Este comportamiento destruye la confianza con el tiempo. Deja al equipo técnico en una situación comprometida.
Un verdadero consultor actúa como un escudo. Es tu responsabilidad discernir si una solicitud es totalmente inviable antes de delegársela al departamento de TI. Debes aplicar la técnica de los "Cinco Porqués" que analizamos en la Parte 1 y descubrir la verdadera necesidad del negocio.
Además, si el desarrollador tiene dificultades para cumplir con un requisito, no basta con señalar el documento de especificaciones y exigir resultados. Hay que colaborar con él. Deben investigar juntos para determinar si la limitación técnica es objetiva. Si se trata de un obstáculo objetivo, es necesario actuar como mediador y volver al cliente para negociar una solución intermedia.
A los clientes les encanta usar la frase clásica: «En informática, todo es posible». Debes proteger a tu equipo técnico de esta mentalidad, porque así no funciona el mundo real. No reescribimos los procesos centrales desde cero. Ampliamos las funcionalidades estándar.
Cuando los desarrolladores se den cuenta de que estás ahí, filtrando lo que no sirve y protegiéndolos de promesas imposibles, te respetarán. Dejarán de oponerse a tus peticiones y empezarán a colaborar en tus soluciones.
Soportando la presión
Los consultores funcionales suelen quejarse de una dinámica muy particular. Cuando un script personalizado falla o un sistema se bloquea, el consultor técnico se sienta cómodamente detrás de un monitor. Mientras tanto, el consultor funcional tiene que sentarse en una sala de reuniones, mirar a un cliente enfadado a los ojos y explicar por qué la personalización recién implementada no funciona como se esperaba. Resulta increíblemente injusto asumir la culpa de un error técnico que uno no ha cometido.
Sin embargo, te guste o no, ser el enlace entre el equipo técnico y el cliente es precisamente tu trabajo. Eres el puente. Quejarse de tener que tratar con el cliente es como si un escudo se quejara de recibir un golpe.
El secreto de un proyecto exitoso reside en la defensa mutua. Una alianza sólida implica que se apoyan entre sí. El consultor funcional absorbe el impacto, soporta la presión y gestiona la frustración del cliente para ganar tiempo valioso. Esta dinámica solo funciona si el desarrollador lo respalda.
En una verdadera colaboración, en el momento en que el consultor entra en esa sala de reuniones hostil, el desarrollador ya está informado y trabajando en segundo plano para solucionar el problema. Usted protege al desarrollador del pánico del cliente, y el desarrollador defiende su credibilidad corrigiendo el error rápidamente.
El manual de la alianza
¿Cómo convertir un departamento de TI hostil en tu mayor aliado? Aquí tienes tres reglas prácticas para aplicar en tu próximo proyecto y forjar una verdadera colaboración.
1. Escribe especificaciones binarias, no novelas
Los desarrolladores odian la ambigüedad más que nada en el mundo. Nunca escribas una especificación funcional que diga: «El sistema debería actualizar automáticamente el estado y notificar al usuario». Eso es una novela, no una especificación. En su lugar, escribe con lógica binaria. Especifica con precisión qué disparador activa el evento. Define con exactitud qué campo de la tabla debe cambiar del estado A al estado B.
Aclare con precisión qué debe decir la notificación y quién es el destinatario exacto. Elimine los adjetivos y sustitúyalos por condiciones precisas. Si su especificación deja margen para la interpretación personal, es una mala especificación. Incluso los detalles más pequeños deben documentarse en un análisis formal y compartirse. Una breve reunión inicial para revisar estos detalles puede marcar una gran diferencia a la hora de establecer un lenguaje común.
2. Explique siempre el “por qué” en el análisis
Al redactar la especificación funcional, es fundamental explicar claramente las motivaciones empresariales que justifican la solicitud. No trate al desarrollador como un simple ejecutor de código. Al igual que los consultores funcionales, los desarrolladores necesitan comprender el contexto completo del requisito. Deben entender en qué están trabajando, pero, sobre todo, por quélo hacen. No se limite a darles instrucciones técnicas.
Explica el problema que afecta al negocio. Por ejemplo: « Los trabajadores del almacén están introduciendo este número manualmente 500 veces al día, lo que provoca retrasos en los envíos. Necesitamos automatizar este campo para ahorrarles dos horas por turno». Cuando un desarrollador comprende el contexto y el impacto humano de su código, pasa de ser un mero receptor de órdenes a un socio activo que podría sugerir una solución técnica mucho mejor que la que se había previsto inicialmente.
3. Hazlos parte del viaje
En la mayoría de los proyectos, el consultor funcional es quien viaja a la oficina del cliente y asiste a las reuniones importantes. Esta dinámica suele dejar al desarrollador aislado en la trastienda. Si de verdad se quiere trabajar en equipo, hay que hacerlo correctamente. No basta con contactar a los compañeros técnicos solo cuando se tiene una tarea de codificación específica, sin proporcionarles el contexto general.
Debes hacer que se sientan parte integral del proyecto. Aprovecha la oportunidad para hablar con ellos con regularidad y mantenerlos al tanto de las novedades del cliente, los cambios en el proyecto y el ambiente general. Proporcionarles este contexto continuo garantiza su plena participación. Cuando los desarrolladores comprenden el panorama general y se sienten parte del proceso, dejan de ser meros ejecutores y se convierten en verdaderos socios del proyecto. Un proyecto donde un consultor funcional y un desarrollador trabajan en conjunto sin duda dará excelentes resultados tanto para el proyecto como para su trabajo diario.
La Alianza en las Trincheras
Crear una extensión personalizada o integrar un software externo en un sistema ERP nunca es tan sencillo como escribir líneas de código. Es un ejercicio de comunicación humana.
La mejor arquitectura técnica del mundo se derrumbará si quienes definen el proceso y quienes escriben la lógica se niegan a entenderse. Dejando de lado nuestros egos, aprendiendo a comunicarnos con claridad y respetando el tiempo de los demás, podemos poner fin a esta eterna lucha y empezar a crear software que realmente marque la diferencia.
El éxito de una puesta en marcha depende en gran medida de la sólida alianza entre un consultor funcional y uno técnico. Ninguno de los dos puede tener éxito trabajando solo.
A continuación: Cómo cultivar la habilidad más subestimada en el sector de la consultoría. Exploraremos el poder de la curiosidad frente a la memoria enciclopédica.
Escrito por Andrea Guaccio
7 de mayo de 2026