Un cliente de consumo masivo ten\u00eda un problema que, visto desde el reporte de inventario, no ten\u00eda sentido: bodega llena, y al mismo tiempo, quiebres constantes en punto de venta. Producto sobrando en un lado de la cadena y faltando en el otro, al mismo tiempo.<\/p>\n\n\n\n
El diagn\u00f3stico inicial apuntaba a log\u00edstica: rutas mal planeadas, tiempos de entrega inconsistentes, exceso de inventario de seguridad. Ninguno de esos diagn\u00f3sticos era falso. Ninguno era tampoco la causa ra\u00edz.<\/p>\n\n\n\n
La causa ra\u00edz era m\u00e1s simple, y m\u00e1s inc\u00f3moda: nadie en la organizaci\u00f3n ve\u00eda, en el mismo lugar y al mismo tiempo, cu\u00e1nto producto entraba al canal (Sell In) y cu\u00e1nto realmente se vend\u00eda en el punto de venta (Sell Out). Un equipo ve\u00eda Sell In. Otro ve\u00eda Sell Out, semanas despu\u00e9s, en un reporte distinto, con una definici\u00f3n de producto ligeramente distinta. Para cuando alguien cruzaba ambos n\u00fameros manualmente, la decisi\u00f3n que debieron tomar dos semanas antes ya no serv\u00eda.<\/p>\n\n\n\n
Sell In y Sell Out no son solo dos m\u00e9tricas de retail. Son dos preguntas de negocio distintas que, sin visibilidad conjunta, se responden por separado y casi siempre mal. Sell In responde \u00ab\u00bfqu\u00e9 tanto estamos empujando al canal?\u00bb. Sell Out responde \u00ab\u00bfqu\u00e9 tanto se est\u00e1 moviendo de verdad?\u00bb. Cuando esas dos preguntas viven en sistemas que no se hablan entre s\u00ed, la organizaci\u00f3n termina optimizando la que puede ver, no la que importa.<\/p>\n\n\n\n
En este caso, Sell In viv\u00eda en el sistema de distribuci\u00f3n. Sell Out viv\u00eda en reportes de los propios puntos de venta, cargados con retraso y sin una definici\u00f3n homologada de qu\u00e9 contaba como \u00abuna unidad vendida\u00bb versus \u00abuna unidad devuelta\u00bb o \u00abuna unidad en promoci\u00f3n\u00bb. No era un problema de falta de datos. Era un problema de que los datos que exist\u00edan no pod\u00edan conversar entre s\u00ed con confianza.<\/p>\n\n\n\n
Por eso, antes de tocar cualquier proceso comercial, el trabajo fue de integraci\u00f3n y calidad de dato: un proceso de ETL (Extract, Transform, Load) para traer Sell In y Sell Out a un mismo modelo, en la misma cadencia, con las mismas reglas de negocio. Y, debajo de eso, un ejercicio de MDM (Master Data Management) \u2014 un dato maestro \u00fanico de producto y de cliente, porque sin eso, \u00abla misma unidad\u00bb pod\u00eda aparecer con tres nombres distintos seg\u00fan el sistema que la reportara, y ning\u00fan cruce de Sell In contra Sell Out iba a ser confiable.<\/p>\n\n\n\n
Esta es la parte que casi nadie discute cuando habla de visibilidad comercial: no se puede tener un dashboard confiable de Sell In\/Sell Out si el producto y el cliente no est\u00e1n unificados en el origen. Un dashboard construido sobre datos sin gobernar no reduce la incertidumbre comercial. Solo le da una interfaz m\u00e1s bonita a la misma confusi\u00f3n.<\/p>\n\n\n\n
Con Sell In y Sell Out integrados sobre un dato maestro confiable, la organizaci\u00f3n pudo ver, por primera vez en el mismo lugar, d\u00f3nde el producto se estaba empujando al canal m\u00e1s r\u00e1pido de lo que realmente se vend\u00eda, y d\u00f3nde ocurr\u00eda lo contrario. Eso no es un hallazgo t\u00e9cnico. Es una decisi\u00f3n comercial distinta: a qu\u00e9 punto de venta reponer primero, a cu\u00e1l frenar el env\u00edo, y con qu\u00e9 anticipaci\u00f3n.<\/p>\n\n\n\n
La decisi\u00f3n comercial que cambi\u00f3 no fue una campa\u00f1a ni un descuento. Fue el criterio con el que el equipo decid\u00eda, semana a semana, a qui\u00e9n surtir primero. Antes, ese criterio se basaba en lo que se ve\u00eda del lado de Sell In \u2014lo que sal\u00eda de bodega\u2014 porque era el dato m\u00e1s disponible. Despu\u00e9s, se bas\u00f3 en Sell Out real, que es, al final, la \u00fanica m\u00e9trica que le importa al negocio.<\/p>\n\n\n\n
La primera es que los datos ya existen: el sistema de distribuci\u00f3n ya reporta Sell In, los puntos de venta ya reportan Sell Out. Es cierto, casi siempre. Lo que casi nunca es cierto es que ambos reportes compartan una definici\u00f3n de producto, de cliente y de periodo que permita cruzarlos con confianza. Confirmar eso \u2014o corregirlo\u2014 es el primer paso, no un paso opcional que se salta para llegar m\u00e1s r\u00e1pido al dashboard.<\/p>\n\n\n\n
La segunda es de tiempo: el equipo comercial ya est\u00e1 operando, ya est\u00e1 tomando decisiones semana a semana, detener eso para \u00abarreglar los datos\u00bb se siente como una fricci\u00f3n innecesaria frente a la urgencia del d\u00eda a d\u00eda. En este caso, el trabajo de integraci\u00f3n y calidad de dato no detuvo la operaci\u00f3n comercial \u2014 corri\u00f3 en paralelo, y el equipo sigui\u00f3 decidiendo con lo que ten\u00eda mientras el modelo unificado se constru\u00eda. Lo que cambi\u00f3 no fue la velocidad de la decisi\u00f3n. Fue la confianza en que la decisi\u00f3n se estaba tomando con el dato correcto.<\/p>\n\n\n\n
Y hay una tercera objeci\u00f3n que aparece despu\u00e9s, no antes: una vez integrado, \u00bfde qui\u00e9n es el dato maestro? En este caso, la respuesta no fue \u00abde sistemas\u00bb ni \u00abde comercial\u00bb por separado, sino de un due\u00f1o \u00fanico, con autoridad para decidir c\u00f3mo se nombra, se clasifica y se actualiza cada producto y cada cliente. Sin ese due\u00f1o, el dato maestro se degrada por defecto: alguien agrega un producto nuevo con nomenclatura propia porque necesita reportar esa misma semana, y meses despu\u00e9s el mismo problema regresa aunque la integraci\u00f3n t\u00e9cnica siga funcionando bien en el papel. La tecnolog\u00eda resuelve la integraci\u00f3n una vez. La gobernanza es lo que evita que la fragmentaci\u00f3n vuelva.<\/p>\n\n\n\n
Si tu organizaci\u00f3n reporta inventario y ventas por separado, y nadie ha cruzado ambos con una definici\u00f3n de producto y cliente unificada, no tienes visibilidad de canal. Tienes dos reportes que coexisten sin conversar. La pregunta que vale la pena hacerse, antes de invertir en m\u00e1s dashboards o m\u00e1s reportes, es la misma que resolvi\u00f3 este caso: \u00bflo que entra al canal y lo que realmente se vende viven en el mismo modelo de datos, con las mismas reglas, en el mismo momento?<\/p>\n\n\n\n
Si la respuesta es no, el problema no es de log\u00edstica ni de comercial. Es de datos \u2014de integraci\u00f3n y de calidad\u2014 y ah\u00ed es donde hay que empezar.<\/p>\n\n\n\n
Este patr\u00f3n no es exclusivo de consumo masivo. Se repite en cualquier organizaci\u00f3n donde dos \u00e1reas miden lo mismo con definiciones distintas y nadie se ha dado cuenta porque cada quien conf\u00eda en su propio reporte: en telecomunicaciones, entre lo que factura el sistema comercial y lo que factura el sistema de cobranza; en manufactura, entre lo que reporta producci\u00f3n y lo que reporta calidad sobre el mismo lote; en servicios financieros, entre lo que registra el sistema transaccional y lo que reconoce el sistema contable como cliente \u00fanico. En todos los casos, el s\u00edntoma se ve como un problema operativo y el diagn\u00f3stico inicial casi siempre apunta al proceso. La causa ra\u00edz, con m\u00e1s frecuencia de la que se reconoce, es que dos partes de la misma organizaci\u00f3n est\u00e1n viendo la misma realidad con dos definiciones de dato distintas, sin que nadie las haya conciliado.<\/p>\n\n\n\n
Antes de comprar otro dashboard o contratar otra plataforma de reporting, vale la pena seguir un orden distinto al que la mayor\u00eda de los equipos comerciales sigue por costumbre.<\/p>\n\n\n\n
Primero, diagn\u00f3stico de fragmentaci\u00f3n: qu\u00e9 \u00e1reas miden lo mismo con sistemas distintos, y con qu\u00e9 definici\u00f3n cada una. Segundo, dato maestro: antes de cualquier integraci\u00f3n, un mismo cat\u00e1logo de producto y de cliente, porque sin eso ning\u00fan cruce de datos es confiable, sin importar cu\u00e1ntos conectores tenga la plataforma. Tercero, integraci\u00f3n (ETL): traer los datos relevantes a un mismo modelo, con la misma cadencia y las mismas reglas de negocio. Cuarto, la decisi\u00f3n: construir la vista o el dashboard solo despu\u00e9s de que los tres pasos anteriores est\u00e9n resueltos, no antes.<\/p>\n\n\n\n
Invertir este orden \u2014empezar por el dashboard y dejar la calidad del dato para despu\u00e9s\u2014 es la raz\u00f3n por la que muchas iniciativas de visibilidad comercial terminan produciendo reportes bonitos que nadie usa para decidir, porque nadie conf\u00eda del todo en lo que muestran.<\/p>\n\n\n\n
Si tu equipo comercial est\u00e1 tomando decisiones con Sell In y Sell Out separados, o si simplemente no conf\u00edas en que el dato que ves representa lo que de verdad pasa en el canal, es exactamente el tipo de diagn\u00f3stico que hacemos en la pr\u00e1ctica de Data Intelligence de Scanda (Data Quality, Cliente \u00danico, MDM) antes de recomendar cualquier tecnolog\u00eda. Escr\u00edbenos.<\/p>","protected":false},"excerpt":{"rendered":"
Un cliente de consumo masivo ten\u00eda un problema que, visto desde el reporte de inventario, no ten\u00eda sentido: bodega llena, y al mismo tiempo, quiebres constantes en punto de venta. Producto sobrando en un lado de la cadena y faltando en el otro, al mismo tiempo. El diagn\u00f3stico inicial apuntaba a log\u00edstica: rutas mal planeadas, […]<\/p>\n","protected":false},"author":3,"featured_media":344891,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","content-type":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-344890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts\/344890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/comments?post=344890"}],"version-history":[{"count":1,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts\/344890\/revisions"}],"predecessor-version":[{"id":344892,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/posts\/344890\/revisions\/344892"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/media\/344891"}],"wp:attachment":[{"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/media?parent=344890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/categories?post=344890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scanda.com.mx\/en\/wp-json\/wp\/v2\/tags?post=344890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}