Consultoría de Datos en México: Qué Preguntar Antes de Firmar
- SaaS y Tecnología
- Finanzas, Fintech e Inversión
Resumen
Contratar consultoría de datos es difícil porque el producto no se puede inspeccionar antes de recibirlo: firmas una promesa. Seis preguntas convierten esa promesa en algo verificable. Quién va a hacer el trabajo realmente (nombre y disponibilidad, no un organigrama). Si el alcance y la fecha son fijos o si vas por horas abiertas. Cómo validan que los números están bien (pide el método y una evidencia concreta). Qué pasa cuando se van (documentación, accesos, pruebas automatizadas). Qué han construido para empresas parecidas a la tuya (con nombre o con detalle técnico suficiente para verificarlo). Y cómo cobran, incluyendo qué NO está incluido. Ninguna respuesta tiene que ser perfecta; lo que importa es que sea específica. La vaguedad en la venta se convierte en órdenes de cambio en la entrega.
Conclusión clave — Comprar consultoría de datos es difícil porque no puedes inspeccionar el producto antes de recibirlo: firmas una promesa. Estas seis preguntas la convierten en algo verificable — quién hace el trabajo, si el alcance es fijo, cómo validan los números, qué queda cuando se van, qué han construido antes y qué no incluye el precio. Lo que buscas no es la respuesta correcta, es una respuesta específica.
Cuando compras maquinaria, la puedes ver. Cuando contratas un despacho contable, hay un título profesional de por medio y una autoridad que audita. Cuando contratas consultoría de datos no hay ninguna de las dos: no existe una certificación que signifique algo, y el trabajo ocurre dentro de sistemas que tú no puedes evaluar mientras se construyen.
Estás firmando una promesa. Y la mayoría de los proyectos de datos que terminan mal no fracasan por incompetencia técnica — fracasan porque la promesa era ambigua y nadie lo notó hasta la semana ocho.
La ambigüedad sí se detecta antes de firmar, con preguntas que cualquier proveedor serio contesta sin incomodarse. Aquí están las seis que más información dan. Aclaración de origen: soy consultor, y algunas las contesto bien porque así construí mi práctica — pero la guía sirve igual si nunca me contratas. Si se las haces a alguien más, saliste ganando.
1. ¿Quién va a hacer el trabajo, realmente?
Por qué importa. El modelo de negocio más común en consultoría consiste en que un socio senior venda y un equipo junior entregue. No es malo — es cómo se escala una firma. El problema aparece cuando crees que pagas por la persona que te vendió y en realidad pagas por su capacidad de supervisar a otros a tiempo parcial.
Esa diferencia no se nota en la propuesta. Se nota en la semana cinco, cuando quien entendía tu negocio ya está vendiendo el siguiente proyecto y quien te contesta el correo lleva ocho meses en la industria.
Qué preguntar exactamente. No preguntes “¿quién va a trabajar en el proyecto?” — la respuesta va a ser un organigrama. Pregunta:
- ¿Quién escribe el código? Nombre.
- ¿Qué porcentaje de su tiempo está en mi proyecto?
- ¿Cuántos proyectos lleva esa persona en paralelo mientras dura el mío?
- ¿Esos nombres pueden quedar en la propuesta?
Cómo suena una respuesta seria. Nombres, porcentajes, y disposición a escribirlo. “Yo hago el modelado y la validación, al 60% durante seis semanas; traigo un ingeniero de datos para las cargas iniciales, aquí está su perfil; no llevo otro proyecto de construcción en ese periodo.”
Cómo suena una que te está esquivando. Perfiles en lugar de personas (“un arquitecto senior y dos analistas”), o la frase “asignamos según disponibilidad”. Ninguna es una mentira; las dos son una forma de no comprometerse. Si el proveedor no puede poner nombres, es porque planea poder cambiarlos.
En Clarivant este punto define el modelo: el principal es quien hace el trabajo, y ese es el techo de cuántos proyectos puedo llevar a la vez. Es una restricción real — y es justo la restricción que deberías evaluar en cualquier proveedor.
2. ¿El alcance y la fecha son fijos, o vamos por horas?
Por qué importa. Aquí se decide quién carga el riesgo. Con tarifa por hora abierta, si el proyecto resulta más grande de lo que cualquiera pensó, el costo extra es tuyo. Con alcance y fecha fijos, es del proveedor. Ninguno de los dos modelos es deshonesto — pero solo uno te permite ir al comité con un número que puedas defender. El modelo por horas además tiene un efecto secundario incómodo: el proveedor gana más si el proyecto tarda más. No hace falta suponer mala fe para reconocer que ese incentivo existe.
Qué preguntar exactamente. ¿El precio de la propuesta es un techo o una estimación? ¿Qué pasa si el alcance resulta 30% más grande — quién lo paga? ¿Qué eventos disparan una orden de cambio, y quién decide que se dispararon?
Cómo suena una respuesta seria. Precio y fecha comprometidos por escrito, con una definición explícita de qué constituye alcance nuevo, precedidos de un levantamiento pagado: nadie honesto cierra precio sin haber visto tus sistemas. Si te dan precio fijo sin mirar nada, o están adivinando o ya te metieron un colchón que vas a pagar aunque no se use.
Cómo suena una que te está esquivando. “Trabajamos por bolsa de horas y vamos priorizando contigo.” Puede funcionar para soporte continuo. Para una migración con fecha límite significa que el alcance es negociable todos los martes y que la fecha no existe.
3. ¿Cómo validan que los números están bien?
Por qué importa. Es la pregunta que casi nadie hace y la que más dinero cuesta. En una migración, el peor resultado no es que el sistema nuevo falle — es que funcione y dé números ligeramente distintos a los del viejo, y que nadie sepa cuál está bien. Ese escenario destruye la confianza en la plataforma nueva de forma que casi no se recupera. Y “validar” es una palabra que todos usan; lo que cambia entre proveedores es si detrás hay un método o hay una junta.
Qué preguntar exactamente. ¿Cuál es el método, paso a paso? ¿Se reconcilia registro por registro o solo totales? ¿Cuál es el umbral de tolerancia acordado, y quién lo firma? ¿Y me pueden contar una diferencia real que hayan encontrado en otro proyecto y cómo la resolvieron? Esa última es la mejor pregunta de la lista, porque no se puede contestar sin haberlo vivido.
Cómo suena una respuesta seria. Un método concreto: línea base congelada del sistema viejo, reconciliación registro por registro contra el nuevo, cada diferencia documentada con causa raíz, umbral acordado antes de empezar. Y una anécdota específica de una diferencia que resultó ser un bug del sistema viejo — porque cuando validas de verdad, eso pasa seguido.
Cómo suena una que te está esquivando. “Lo validamos con los usuarios en el UAT.” Traducción: la validación es tuya, y va a ocurrir cuando tu equipo ya no tenga tiempo para hacerla bien.
Como referencia de qué tan lejos llega el método cuando existe: en una reconstrucción de analítica de ingresos, la reconciliación cerró con 0.002% de diferencia sobre $84M validados, y en el camino aparecieron 15 bugs silenciosos que llevaban años en producción en el sistema anterior. Ese es el tipo de evidencia que puedes pedirle a cualquiera: no el certificado, el método y un ejemplo.
4. ¿Qué pasa cuando se van?
Por qué importa. Un proyecto de datos no termina el día de la entrega; termina el primer martes en que algo se rompe y tu equipo tiene que arreglarlo solo. Si en ese momento la única persona que entiende el pipeline ya no trabaja contigo, acabas de convertir una inversión en una dependencia. Hay firmas cuyo modelo de negocio es esa dependencia: entregan algo que funciona pero que nadie más puede mantener, y el retainer de soporte se vuelve inevitable.
Qué preguntar exactamente. ¿Qué documentación entregan y en qué idioma? ¿El código queda en mi repositorio desde el día uno o en el suyo? ¿Los accesos quedan a mi nombre? ¿Hay pruebas automatizadas que fallen solas cuando un dato viene mal, o alguien tiene que darse cuenta? ¿Cuánto dura el traspaso y qué incluye?
Cómo suena una respuesta seria. El handover está en la propuesta como entregable con criterio de aceptación, no como cortesía final. Código en tu repositorio, en tu nube, con tus accesos. Documentación que tu equipo pueda leer en su idioma. Pruebas automatizadas que corren solas — esa es la diferencia entre una plataforma que se cuida sola y una que necesita un guardián.
Cómo suena una que te está esquivando. “Al cierre les damos una sesión de traspaso de dos horas y la documentación.” Dos horas y un PDF no son un traspaso; son un adiós.
Si el proyecto incluye IA sobre tus datos, este punto tiene una versión más urgente: pregunta qué evita que el modelo conteste desde métricas mal definidas cuando ya nadie del proveedor está mirando. Escribí aparte sobre las barreras que deben sobrevivir al consultor.
5. ¿Qué han construido para empresas como la mía?
Por qué importa. El logotipo de un cliente en una presentación no dice nada sobre quién hizo el trabajo, cuándo, ni si esa persona sigue en la firma. Y “como la mía” casi nunca significa la misma industria: significa el mismo tamaño, el mismo tipo de caos y la misma clase de restricción.
Qué preguntar exactamente. ¿Qué construyeron — qué herramientas, cuántos objetos, en cuánto tiempo? ¿Quién de su equipo lo hizo y sigue disponible? ¿Puedo hablar con alguien de ese cliente? Y si el caso está anonimizado, ¿me pueden dar el detalle técnico suficiente para juzgarlo?
Cómo suena una respuesta seria. Números y mecánica: qué había antes, qué se construyó, cuánto tardó, qué salió mal en el camino. Un proveedor que solo cuenta victorias limpias está editando. Un caso anonimizado puede ser perfectamente verificable si el detalle técnico es específico; lo que no sirve es “trabajamos con empresas líderes del sector”.
Cómo suena una que te está esquivando. Casos sin números, o números sin contexto (“mejoramos la eficiencia 40%” — ¿de qué, medido cómo, contra qué línea base?).
Para calibrar qué tan concreto puedes pedirlo: la plataforma de datos de una franquicia de 100+ sucursales de Carl’s Jr en México se describe con el stack completo, el sistema de origen y el resultado operativo. Exige ese nivel de detalle a cualquiera; los casos publicados te sirven de vara de medir aunque nunca nos contrates.
Si operas una cadena multi-sucursal, desarmamos esa misma construcción capa por capa en Data Warehouse para una Cadena de Restaurantes — sirve como plantilla de qué preguntarle a quien te la quiera construir.
6. ¿Cómo cobran y qué NO está incluido?
Por qué importa. La segunda mitad de la pregunta vale más que la primera. Casi todas las sorpresas de presupuesto no vienen del precio acordado; vienen de lo que quedó fuera sin que nadie lo dijera en voz alta: licencias de las herramientas, consumo del warehouse, tiempo de tu equipo, migración de datos históricos, capacitación, el mes de estabilización después del go-live.
Qué preguntar exactamente. ¿Qué explícitamente NO está incluido en este precio? ¿Qué costos de terceros voy a pagar directo y cuánto estiman? ¿Cuántas horas de mi equipo asumen en su plan? ¿Qué pasa si mi gente no puede darles esas horas a tiempo?
Cómo suena una respuesta seria. Una lista de exclusiones escrita sin que se la pidas, y una estimación honesta de los costos de terceros aunque no los cobre el proveedor. Sobre todo, un número claro de cuántas horas de tu equipo requiere el proyecto — ese es el costo que nunca aparece en la propuesta y siempre aparece en el calendario.
Cómo suena una que te está esquivando. Una propuesta sin exclusiones. Suena generosa y es lo contrario: la frontera se va a definir después, cuando ya firmaste y ya no tienes poder de negociación.
¿Cuánto cobra un consultor de datos en México?
Es la pregunta que todo mundo hace primero, y la respuesta honesta es que la cifra sola no te sirve: lo que determina tu costo real es el modelo de cobro, no la tarifa. En el mercado conviven al menos tres:
- Por hora o por día. Transparente, fácil de arrancar, y el riesgo del alcance es 100% tuyo.
- Bolsa de horas o retainer mensual. Pagas capacidad disponible, no un resultado. Funciona para soporte continuo; mal para un proyecto con fecha.
- Alcance fijo, precio y fecha cerrados. El riesgo del alcance es del proveedor, y por eso exige un levantamiento previo real.
Una tarifa por hora baja con alcance abierto termina seguido más cara que una cotización cerrada más alta: compara modelos, no tarifas. Y sin importar a quién contrates, puedes exigir una cotización en firme después de un levantamiento pagado. Si el número te llega antes de que alguien haya visto tus sistemas, no es una cotización, es una apuesta — y el colchón lo estás pagando tú.
Qué debe incluir la propuesta
Cuando llegue el documento, revisa que estas seis cosas estén:
- Alcance escrito como lista de entregables verificables, no como objetivos.
- Fecha comprometida, con hitos intermedios que te dejen ver el avance.
- Nombres de quienes van a trabajar, con su dedicación.
- Criterio de aceptación de cada entregable, incluyendo el método de validación.
- Qué queda en tus manos al cerrar: repositorio, documentación, accesos, pruebas.
- Precio, forma de pago y la lista explícita de exclusiones.
Si falta alguno, ese punto se va a definir después — y “después” siempre significa con menos poder de negociación del que tienes hoy.
La forma barata de probar las respuestas
Las preguntas se pueden contestar bien sin que el trabajo sea bueno. Eso es lo que hace difícil comprar consultoría, y por eso el mejor consejo no es una pregunta más sino una estructura: empieza con un compromiso pequeño, pagado y con fecha, antes del proyecto grande. Un diagnóstico acotado te deja ver cómo trabaja el proveedor de verdad — si documenta, si aparece a las juntas, si el senior que te vendió es el que abre la consola — con dos o tres semanas de riesgo en lugar de seis meses.
Así funciona la Radiografía de Datos, el proyecto de entrada con el que empezamos casi todo en Clarivant: alcance fijo, dos a tres semanas dentro de tu stack real, y al final un inventario, hallazgos y una cotización a precio fijo con fecha fija. El principio vale con cualquier proveedor: pide un primer entregable chico y pagado, y evalúa el trabajo en lugar de la presentación.
Las líneas de servicio están publicadas con su mecánica y una llamada de estrategia alcanza para hacer las seis preguntas de esta guía. No hace falta que me las hagas a mí — pero házselas a alguien antes de firmar.
Preguntas frecuentes
¿Qué preguntar antes de contratar una consultoría de datos?
Seis preguntas cubren casi todo el riesgo: quién va a hacer el trabajo realmente — con nombre y porcentaje de dedicación, no un organigrama; si el alcance y la fecha son fijos o si vas por tarifa por hora abierta; cómo validan que los números migrados están bien, con método y evidencia de un proyecto anterior; qué te queda cuando se van — documentación, accesos, pruebas automatizadas, código en tu repositorio; qué han construido para empresas parecidas a la tuya, con detalle técnico suficiente para verificarlo; y cómo cobran, incluyendo qué explícitamente no está incluido. No busques respuestas perfectas: busca respuestas específicas.
¿Cuánto cobra un consultor de datos en México?
Depende del modelo de cobro más que del proveedor, y por eso una cifra genérica no te sirve para presupuestar. En el mercado conviven al menos tres modelos: tarifa por hora o por día (el riesgo del alcance es tuyo), bolsa de horas o retainer mensual (pagas capacidad, no resultado) y proyecto de alcance fijo con precio y fecha cerrados (el riesgo del alcance es del proveedor). El mismo trabajo puede costar muy distinto en cada modelo. Lo que sí debes exigir, sin importar el proveedor, es una cotización en firme después de un ejercicio de levantamiento — no un número inventado desde una llamada de descubrimiento de 30 minutos, y no una tarifa por hora sin techo. Si alguien te da precio cerrado sin haber visto tus sistemas, o está adivinando o ya metió un colchón grande que estás pagando.
¿Qué debe incluir una propuesta de consultoría de datos?
Seis cosas concretas: el alcance escrito como lista de entregables verificables (no como objetivos), la fecha de entrega comprometida con sus hitos, los nombres de las personas que van a trabajar en el proyecto y su dedicación, el criterio de aceptación — cómo se demuestra que cada entregable quedó bien, incluyendo el método de validación de los números, lo que queda en tus manos al cerrar (repositorio, documentación, accesos, pruebas) y el precio con su forma de pago y una lista explícita de lo que NO está incluido. Esa última lista es la más informativa de todas: una propuesta sin exclusiones no es generosa, es ambigua, y la ambigüedad se cobra después como orden de cambio.
¿Cómo sé si van a poner seniors o juniors en mi proyecto?
Pregúntalo directo y pide tres datos: nombre de quien va a escribir el código, porcentaje de dedicación al proyecto y cuántos proyectos lleva en paralelo. Luego pide que esos nombres queden en la propuesta. Una firma que planea rotar gente no puede comprometer nombres por escrito y va a responder con perfiles genéricos — 'un arquitecto senior y dos ingenieros'. No es que un modelo con juniors esté mal: es que cambia el precio justo, el ritmo y cuánta supervisión te toca a ti. Lo que no debe pasar es que descubras la composición del equipo en la primera sesión de arranque.
¿Cómo verifico que los números de una migración quedaron bien?
Pide el método antes de firmar, no el certificado al final. Un método serio se ve así: se define una línea base con los números del sistema viejo, se reconcilia registro por registro contra el sistema nuevo — no solo los totales — se documenta cada diferencia con su causa raíz, y se acuerda de antemano el umbral de tolerancia. Pide además que te cuenten una diferencia real que hayan encontrado en un proyecto anterior y cómo la resolvieron. La respuesta genérica ('validamos todo con el usuario') es la señal de alerta: significa que la validación te la van a delegar a ti bajo el nombre de UAT.
¿Es mejor contratar una consultoría local o una internacional para un proyecto de datos?
La pregunta útil no es local contra internacional, sino en qué idioma y en qué zona horaria va a ocurrir el trabajo real. Un proveedor internacional puede ser excelente y aun así entregarte documentación que tu equipo no puede mantener, o poner las juntas de avance a horas imposibles. Un proveedor local puede tener el idioma resuelto y no tener experiencia con el stack que necesitas. Pregunta en qué idioma van a quedar el código, los comentarios y la documentación de handover, quién va a estar en las juntas y en qué horario, y quién responde cuando algo se rompe en producción un martes a las nueve de la mañana, hora de México.