ES 
PT 
EN 
La elección ya está hecha cuando llega la propuesta. A esa altura usted habló con tres o cuatro empresas, le gustaron dos, y lo que queda por decidir es precio y plazo. Si el socio equivocado llegó hasta ahí, el documento no se lo va a advertir.
Lo que separa a un socio de gestión y arquitectura de datos de otro ocurre mucho antes, y casi siempre en la primera conversación. Solo que la señal no está en lo que usted pregunta. Está en lo que ellos preguntan.
La primera conversación es un diagnóstico, no una presentación
Quien busca un socio de datos ya tiene un dolor. El cierre que se atrasa todos los meses, el informe que cada área calcula a su manera, el número que llega después de la decisión que dependía de él.
Tener el dolor, sin embargo, no es lo mismo que saber describirlo. Eso no es culpa de nadie: la persona que siente el problema suele estar dos o tres pasos lejos de donde nace. El director nota que el cierre se atrasa. La causa puede estar en una integración que falla en silencio, en un campo que tres sistemas completan de maneras distintas, o en una planilla que alguien concilia a mano desde 2019 y que nadie documentó nunca.
Por eso la primera reunión no es para presentar una solución. Es para descubrir cuál es el problema de verdad.
Y ese es el trabajo de la consultoría, no el suyo. Usted no necesita llegar con el diagnóstico hecho. Si lo necesitara, no necesitaría a la consultoría.
Cómo es una buena primera conversación
Quien sabe conducir un diagnóstico escucha más de lo que habla. Y cuando habla, pregunta.
Las buenas preguntas suelen parecer laterales. Quién ejecuta esa conciliación hoy, y en cuánto tiempo. Qué pasa cuando la fuente se atrasa, y quién se entera primero. Cuántas versiones de ese mismo indicador existen en la empresa, y cuál llega a la dirección. Qué decisión se tomó el año pasado con un número que después resultó equivocado.
Ninguna de esas pregunta sobre tecnología. Todas cambian el diseño de la solución.
Un consultor con experiencia también va detrás de lo que usted no contó, porque no parecía relevante. El informe que un área mantiene por fuera. El sistema que nadie puede detener y que por eso quedó fuera del alcance. Aquel proceso manual que se volvió rutina y dejó de percibirse como problema. En proyectos de datos, casi siempre es una de esas cosas la que decide el plazo.
Toda información cuenta en esta etapa, incluso la que parece demasiado pequeña para ser dicha.
La señal más clara es la prisa por hablar de tecnología
Si en la primera reunión alguien ya dice qué plataforma van a usar, esa persona no está resolviendo su problema. Está encajando su problema en lo que ya vende.
Databricks, Snowflake, Fabric, BigQuery, dbt, Airflow. Todas funcionan. Existe más de un camino técnicamente correcto para prácticamente cualquier escenario, y la diferencia entre ellos no es cuál es el mejor en el papel: es cuál encaja en sus fuentes, en su volumen, en su equipo y en lo que usted puede pagar para mantenerlo funcionando dentro de dos años.
Nada de eso se conoce en la primera hora de conversación. Quien responde antes de saber está adivinando, o está vendiendo.
La competencia técnica, por cierto, separa menos de lo que parece. Toda empresa seria del mercado domina esas herramientas, y todas muestran las mismas certificaciones. Eso sirve para descartar a quien no la tiene, no para elegir entre quienes la tienen.
Por qué el diagnóstico decide el costo
Existe una relación directa, y poco comentada, entre la calidad del diagnóstico y la cuenta que llega al final.
Una arquitectura diseñada sobre un entendimiento superficial tiende a quedar sobredimensionada, porque ante la duda se compra holgura. O subdimensionada, y entonces el costo aparece después, en retrabajo. Los dos casos salen caros, y el segundo cuesta además en confianza: cuando la primera entrega no resuelve lo que dolía, la próxima conversación ya empieza difícil.
Entender el problema antes no es preciosismo de método. Es lo que permite elegir la solución más simple que resuelve, que casi siempre es también la más barata de operar.
Qué llevar a la primera conversación
Usted no necesita material listo, y no necesita tenerlo todo. Pero algunas cosas acortan mucho el camino, incluso incompletas:
La lista de las fuentes que usted conoce, aunque falten algunas. ERP, sistemas de área, planillas que se volvieron sistemas. Que falten es normal, y lo que falta suele aparecer justamente en la conversación.
Un ejemplo concreto de una decisión que se trabó por falta de datos. Un caso real vale más que cualquier descripción genérica del problema, porque lleva consigo las restricciones reales.
Quién, de su lado, va a convivir con el resultado. No siempre es quien está en la reunión. Saberlo desde el principio cambia el diseño.
Si la consultoría no pide nada de esto y sigue la conversación igual, eso es un dato sobre ella.
Tres señales de alerta
La solución llega antes que las preguntas. Ya tratado arriba, y es el más común.
Nadie habla de lo que puede salir mal. Un proyecto de datos tropieza con fuentes sin dueño, con campos completados de tres maneras, con sistemas heredados que no se pueden detener. Quien no menciona eso en la conversación inicial lo va a mencionar en la primera reunión de estado, cuando ya sea también su problema.
No hay nada sobre el después. Quién va a operar, quién documenta, quién de su equipo aprende a manejarlo. Cuando eso aparece como “capacitación” al final del cronograma, es lo que se recorta cuando el plazo aprieta.
Cuándo pedir la propuesta
Cuando usted pueda responder tres cosas sin consultar a nadie: qué problema de negocio resuelve el proyecto, quién de su equipo va a llevarlo adelante después de que la consultoría se vaya, y cuánto va a costar la operación por mes el año que viene.
Si la consultoría hizo bien el diagnóstico, usted va a saber responder las tres. Y, lo que es más revelador, probablemente va a describir su problema de una manera distinta a cuando empezó la conversación.
Si alguna sigue abierta, una conversación más cuesta menos que el contrato equivocado.
Preguntas frecuentes
¿La consultoría debe cobrar por el diagnóstico inicial?
La conversación de entendimiento no se cobra, y eso es lo habitual en el mercado. Lo que varía es el paso siguiente: el assessment técnico en su entorno, con relevamiento de fuentes, análisis de calidad de datos y diseño de alternativas. Parte de las consultorías lo trata como proyecto pago, otras lo absorben como inversión comercial.
En Integrity-UX la primera conversación nunca se cobra y, según el proyecto, el assessment en el entorno del cliente también se hace sin costo.
Lo que importa para usted, con cualquier proveedor, es saber antes de aceptar cuál de los dos modelos está sobre la mesa, y qué le queda al final: un informe que usted puede llevar a otra empresa para que lo evalúe, o una presentación que solo tiene sentido si el proyecto sigue con quien la hizo.
¿Y si no sé explicar bien mi problema?
Es el caso más común, y no es un impedimento. Convertir el dolor en un problema describible es justamente el primer trabajo de la consultoría. Si la conversación exige que usted llegue con el diagnóstico hecho, el papel está invertido.
¿Debo elegir una consultoría especializada en mi sector?
Ayuda, pero pesa menos de lo que parece. Lo que más cambia el proyecto es el volumen de datos, la cantidad y el estado de las fuentes y el grado de dependencia de sistemas heredados. Una consultoría que resolvió un problema parecido en otro sector suele ser mejor elección que una que conoce su sector y nunca lidió con su complejidad.
¿Importa que el socio tenga certificación del proveedor de nube?
Importa como piso. La certificación muestra que el equipo estudió la plataforma, no que ya operó la suya. Pregunte cuántos entornos mantienen hoy en producción en ese proveedor, y desde hace cuánto. El nivel de asociación también es público: Microsoft, por ejemplo, mantiene un directorio oficial de socios donde se puede verificar.
¿Vale la pena contratar una prueba de concepto antes del proyecto?
Vale cuando la duda es técnica de verdad, por ejemplo si determinada arquitectura aguanta su volumen. No vale como período de prueba del proveedor, porque una PoC exitosa en un alcance pequeño dice poco sobre la entrega a escala.
¿Cómo evitar la dependencia del proveedor?
Exigiendo, en el contrato, documentación en formato abierto, código en un repositorio suyo y al menos una persona de su equipo involucrada en cada entrega. La dependencia rara vez se impone. Casi siempre se instala porque nadie del lado de adentro acompañó.
¿Cuánto tiempo lleva un proyecto de arquitectura de datos?
Depende del número de fuentes y del estado en que están, y cualquier plazo dado antes de verlo es un cálculo al aire. Lo que sí se puede exigir es entrega incremental: algo en uso desde el principio, por pequeño que sea. Un proyecto de datos que solo muestra resultado al final suele no tener final.
