De quién es el dato del cliente: gobierno de datos entre CPG y distribuidor

El jefe de trade de una CPG mediana le pide al distribuidor las ventas por cliente de las últimas doce semanas. El distribuidor responde, con toda cortesía, que lo va a revisar. Pasan tres semanas. Vuelve a preguntar. Le llega un Excel con totales por zona, sin nombres de clientes, con columnas que no coinciden con las de su propio sistema. Nadie mintió y nadie se negó. Simplemente no había reglas sobre qué se comparte, con qué detalle, para qué y quién responde si algo sale mal.
En el canal tradicional pasa todo el tiempo, y casi siempre se lee como un problema de confianza entre las partes. Esta nota propone otra lectura: se comparte poco dato porque nadie escribió las reglas, no porque falten ganas. Y las reglas se pueden escribir.
Qué dato tiene cada parte
Antes de hablar de compartir, conviene saber qué hay sobre la mesa. Con variaciones según el negocio, el mapa suele verse así:
| Dato | Quién lo tiene hoy | Por qué importa | Sensibilidad |
|---|---|---|---|
| Sell-in: lo que la CPG vende al distribuidor | CPG | Es la base del forecast de producción | Baja entre las partes |
| Precios de lista, promociones y lanzamientos planeados | CPG | El distribuidor necesita anticiparse | Media: tiene valor competitivo |
| Pedidos por cliente y por SKU (sell-out del distribuidor) | Distribuidor | Muestra qué se vende realmente y a quién | Alta: es su cartera |
| Frecuencia de compra, devoluciones, quiebres y faltantes | Distribuidor | Explica por qué no rota lo que se envió | Media |
| Cobranza y saldos por cliente | Distribuidor | Define el riesgo de cada cuenta | Alta |
| Rutas, visitas y cobertura | Distribuidor | Dice dónde llega y dónde no | Media |
| Datos de contacto del tendero | Distribuidor, a veces la CPG | Permiten comunicar y entregar | Alta: son datos personales |
La columna de sensibilidad no es una verdad universal: depende de cada relación. Pero sirve para una conclusión práctica. No hay que decidir “compartimos todo o no compartimos nada”. Hay datos que se pueden compartir agregados, otros con detalle pero sin identificar al cliente, y otros que solo se comparten bajo condiciones.
Por qué vale la pena resolverlo
La idea de que compartir información mejora la cadena de suministro tiene décadas. En un artículo clásico de Management Science, Hau Lee, V. Padmanabhan y Seungjin Whang describieron lo que llamaron el efecto látigo: la variabilidad de los pedidos puede ser mayor que la de las ventas, y la distorsión tiende a crecer a medida que se sube en la cadena. Los autores identifican cuatro fuentes —el procesamiento de la señal de demanda, el juego de racionamiento, el agrupamiento de pedidos y las variaciones de precio— y señalan que contrarrestarlo requiere, entre otras cosas, compartir información de sell-through y de estado de inventario entre los miembros de la cadena.
Conviene leerlo con sus límites. Es un trabajo de 1997, formula un modelo general de cadenas de suministro y no estudia el canal tradicional latinoamericano. No te da un porcentaje de mejora para tu operación. Lo que sí deja es el mecanismo: cuando la CPG solo ve los pedidos del distribuidor, y no lo que ocurre detrás, lo que ve ya viene distorsionado. Si quieres entender mejor esa diferencia entre embarcar y vender, lo desarrollamos en sell-in vs. sell-out. Aquí nos ocupamos de otra pregunta: bajo qué reglas se comparte.
Lo que la colaboración formal ya resolvió en otras industrias
El modelo de CPFR (planeación, pronóstico y reposición colaborativos), desarrollado por VICS, no empieza por la tecnología. Su primera etapa es un acuerdo. Según la descripción del Supply Chain Resource Cooperative de NC State, el llamado collaboration arrangement fija los objetivos y el alcance de la relación, y asigna roles, responsabilidades, puntos de control y procedimientos de escalamiento. Es un documento que ambas partes escriben juntas, que define cómo se medirá el desempeño de cada una y que formaliza su disposición a intercambiar conocimiento y a compartir el riesgo.
No hace falta adoptar CPFR completo para aprovechar la idea. Hay dos lecciones que sí se trasladan:
- El acuerdo viene antes que la integración. Conectar sistemas sin haber definido qué se comparte solo acelera la discusión.
- Los roles y el escalamiento son parte del acuerdo. Cuando un dato llega mal, alguien tiene que saber a quién llamar.
Siete preguntas que debe responder un acuerdo de datos
Esta es una lista de trabajo, no un contrato modelo. Para la parte jurídica, consulta con tu área legal.
- Propósito. ¿Para qué se va a usar el dato? Un forecast conjunto y una campaña dirigida a los clientes del distribuidor no justifican el mismo nivel de detalle.
- Propiedad y uso. ¿De quién es cada dato y qué puede hacer la otra parte con él? Conviene escribir también lo que no puede hacer, por ejemplo usarlo para contactar directamente a clientes del distribuidor.
- Granularidad. ¿Totales por zona, por ruta, por cliente anonimizado, por cliente identificado? Empieza por el nivel más agregado que responda tu pregunta.
- Datos personales. El nombre, el celular y la ubicación del tendero están sujetos a la normativa de cada país. Antes de compartirlos, confirma con tu área legal el fundamento y el consentimiento aplicables.
- Calidad y formato. ¿Quién arma el archivo o la integración, con qué campos, con qué frecuencia y quién corrige cuando algo no cuadra?
- Trazabilidad. ¿Quién accedió a qué y cuándo? Si no hay registro, no hay forma de resolver una discrepancia.
- Salida. ¿Qué pasa con los datos cuando termina la relación? Borrado, devolución o conservación, y en qué plazo.
Lo que le toca a TI
Para el CTO o el responsable de sistemas, la discusión se vuelve concreta en cuatro puntos:
- Identificador común de cliente. Si el distribuidor identifica al cliente con un código y la CPG con otro, ningún cruce funciona. Definir una llave maestra, o una tabla de equivalencias, es el primer trabajo técnico.
- Cadencia. ¿Diaria, semanal, por evento? La que sirva al propósito, no la más frecuente que se pueda.
- Canal de intercambio. Archivos, API o una plataforma intermedia: cada opción cambia quién opera, quién paga y quién ve los registros de acceso.
- Permisos por rol. Quien ve el total por zona no necesariamente debe ver el saldo por cliente.
Cómo empezar sin un proyecto grande
Una forma razonable de partir, como propuesta y no como receta:
- Elegir una categoría y un distribuidor con quien ya exista confianza.
- Acordar tres o cuatro campos, no treinta, y su nivel de detalle.
- Escribir en una página las siete respuestas de arriba.
- Probar durante un ciclo corto y revisar qué decisión cambió gracias al dato. Si ninguna cambió, el dato que compartieron no era el correcto.
- Recién entonces ampliar categorías, distribuidores o detalle.
Cómo lo vemos en Yom
Yom es una plataforma SaaS de inteligencia comercial para el canal tradicional que se integra con el ERP existente y reúne pedidos de distintos canales en una sola vista. Eso ayuda con la parte técnica de esta conversación, pero no reemplaza el acuerdo: qué se comparte, con quién y bajo qué reglas lo decide cada empresa con su socio comercial. Lo que sí vemos es que las operaciones que parten por ordenar el dato propio llegan a esa conversación con mucha más claridad.
En síntesis
Los datos entre CPG y distribuidor no fluyen poco por desconfianza, sino por ausencia de reglas. El trabajo previo a cualquier integración es un acuerdo escrito, simple, con propósito, granularidad, permisos y salida. Con eso, la parte técnica deja de ser el cuello de botella.
¿Existe hoy un documento de una página que diga qué dato comparten tú y tu distribuidor, y para qué? Si quieres ver cómo se ordena el dato comercial propio antes de compartirlo, conversemos en yom.ai.
Artículos relacionados

Sell-in vs sell-out: por qué tus embarques no te dicen qué se está vendiendo

Nueva era, nueva interfaz: El administrador de Yom se reinventa

