Dashboards de Power BI para empresas de comercio

Una empresa de comercio necesita unos pocos dashboards construidos sobre definiciones de KPI acordadas y datos de ERP limpios: ventas y margen, inventario, cuentas por cobrar y envíos. Power BI, Tableau y Looker Studio pueden todos entregarlos, de modo que la decisión sobre la herramienta la dictan sus fuentes de datos, sus usuarios y su gobernanza, no la lista de funciones.

¿Qué dashboards necesita una empresa de comercio?

Los negocios de comercio comparten un puñado de preguntas de gestión que se repiten cada semana, y cada una de ellas es un dashboard y no un informe:

Ventas y margen. Qué se vendió, a quién y con qué margen —por producto, cliente, mercado y mes. La vista de margen es la que cambia el comportamiento: una empresa de comercio puede hacer crecer los ingresos y encoger el beneficio en el mismo trimestre, y solo el desglose por margen lo muestra.

Inventario. Qué se tiene, dónde, desde hace cuánto y qué ha dejado de moverse. Para los distribuidores este es el panel de tesorería: los días de inventario y el stock de movimiento lento inmovilizan el capital de trabajo que necesita el siguiente pedido.

Cuentas por cobrar. Quién debe cuánto, desde cuándo, y qué saldos han cruzado su vencimiento. Los tramos por antigüedad hacen visible de un vistazo la diferencia entre una cartera normal y una cartera con problemas.

Envíos. Qué salió a tiempo, qué va tarde y qué está atascado en un paso documental o aduanero. Para los exportadores este es también un panel de calidad de servicio, porque el retraso que vive el cliente es un evento de envío, no un evento de factura.

Pedidos abiertos. Qué está comprometido, qué está pendiente y qué está bloqueado: la imagen operativa que decide la producción, las compras y los contenedores de esta semana.

Cinco dashboards construidos sobre un solo modelo de datos superan a cincuenta informes construidos sobre cincuenta extractos. La razón es de definiciones: cuando cada responsable de informe calcula el margen a su manera, las reuniones se convierten en discusiones sobre cifras, y la reunión se gasta en la discusión en lugar de en la decisión. Por eso el primer entregable de un proyecto de BI no es un gráfico: es un diccionario de KPI por escrito, acordado por las personas que después rendirán cuentas de esas cifras.

Definiciones de KPI y fuentes de datos

La tabla es el núcleo operativo del proyecto: cada KPI necesita una definición, un responsable y una fuente, y la columna de trampas es donde nacen la mayoría de las discusiones sobre dashboards:

Tabla A: KPI | definición | fuente de datos | trampa frecuente

KPI	Definición	Fuente de datos	Trampa frecuente
Ventas	Ventas netas facturadas en la moneda acordada, por periodo, desglosadas por producto/cliente/mercado	Facturas del ERP (solo documentos registrados)	Contar pedidos en lugar de facturas, o incluir facturas rectificativas sin decirlo
Margen bruto	Ventas menos el coste de lo vendido, línea por línea donde existe el coste	Facturas del ERP unidas a datos de coste o de stock	Promediar entre productos, lo que esconde una línea que pierde dinero dentro de un total sano; costes que se retrasan un periodo respecto de las ventas
Días de inventario	Valor medio del stock dividido por el coste diario de ventas del periodo	Valoración de stock y datos de coste del ERP	Cambio del criterio de valoración a mitad de año (media ponderada, FIFO) sin que el dashboard lo sepa; stock repartido en almacenes con reglas distintas
Antigüedad de cuentas por cobrar	Saldos abiertos agrupados por días de retraso, por cliente	Partidas abiertas del ERP	Tratar las facturas en disputa como si solo fueran tardías; ignorar las rectificativas que reducen un saldo después de fijado el tramo
Envío puntual	Envíos que salen en o antes de la fecha acordada, como porcentaje de los envíos del periodo	Despachos del ERP + documentos de transporte o sistema logístico	Definir la «fecha acordada» distinto en cada equipo; contar la fecha del documento en lugar de la salida física
Pedidos abiertos	Valor de pedidos comprometidos y pendientes, con los bloqueados mostrados por separado	Cartera de pedidos del ERP	Mezclar pedidos confirmados con pedidos provisionales; una sola cifra que oculta la proporción bloqueada

Dos disciplinas mantienen viva esta tabla. Las definiciones se escriben en lenguaje comercial llano, no en fórmulas: la fórmula pertenece al modelo de datos, la frase pertenece al diccionario, y la frase es lo que el equipo comercial discute. Y toda definición lleva fecha y responsable: las definiciones se desvían a medida que cambia el negocio, y un dashboard que funciona con la definición del año pasado está equivocado en silencio en lugar de estar honestamente obsoleto. La pregunta más amplia de si esta capa pertenece a un sistema nuevo o al ERP existente se trata en la página de ERP a medida frente a estándar, y la página de BI y analítica de datos cubre la disciplina en su conjunto.

Fuentes de datos e integración

La fuente de verdad de una empresa de comercio está repartida en cinco sistemas, y el trabajo de la capa de BI es unirlos sin inventar nada:

ERP. Facturas, pedidos, stock, pagos y datos maestros. La fuente principal y, normalmente, la única con integridad transaccional.

Hojas de cálculo. Objetivos, presupuestos, ajustes manuales y las cifras paralelas que viven en el archivo de una sola persona. Trátelas en serio: un presupuesto que solo existe en una hoja de cálculo sigue siendo un presupuesto real; pero tráigalas como datos con un responsable, no como adjuntos de correo.

Comercio electrónico y marketplaces. Pedidos y tráfico para las empresas que venden en línea; datos de canal que rara vez coinciden uno a uno con el ERP, de modo que las reglas de asignación —qué cuenta como venta y cuándo— pasan a formar parte del diccionario.

Logística. Despachos, referencias de seguimiento y estado del transportista: la fuente del KPI de puntualidad y del dashboard de envíos, y la que con más frecuencia necesita claves manuales o alimentaciones de los socios.

Banco. Cobros y pagos conciliados con las partidas abiertas: el puente entre el dashboard de cuentas por cobrar y la realidad de la caja.

Los patrones de integración van desde exportaciones programadas —una rutina que deja un archivo cada noche: sencilla, frágil a su manera y fácil de reparar— hasta conexiones en vivo y gateways: datos actuales, más piezas móviles. La elección se hace por fuente y no por proyecto: un ERP que expone una interfaz debe conectarse por esa interfaz, y un socio que envía una hoja de cálculo semanal debe seguir enviándola mientras no haya un motivo para dejar de hacerlo. Lo importante es que cada fuente tenga por escrito una expectativa de actualización: cuándo se pone al día y qué significa «actual» para las personas que leen el dashboard.

Conceptos básicos del modelo de datos

No hace falta convertirse en ingeniero de datos para acertar aquí, pero tres conceptos deciden si el proyecto sobrevive a su segundo año:

Hechos y dimensiones. Los hechos son los eventos —líneas de factura, despachos, pagos— con sus cantidades y valores. Las dimensiones son el contexto —producto, cliente, mercado, fecha, almacén— con los atributos por los que se filtra y se agrupa. Cada KPI de la tabla de arriba es una agregación de hechos cortada por dimensiones, y por eso un solo modelo sirve a cinco dashboards.

Esquema estrella, deliberadamente. Mantener los hechos en el centro y las dimensiones a su alrededor, sin atajos ingeniosos de muchos a muchos, es lo que mantiene las medidas aditivas: las ventas sumadas por región equivalen a las ventas sumadas por mes y al total de ventas. Los modelos que se saltan esta estructura funcionan en la demostración y se rompen en el tercer informe.

Una sola versión de la verdad. El mismo código de producto, el mismo código de cliente y la misma moneda en cada tabla de hechos, tomados de los mismos datos maestros. Las dimensiones duplicadas que se desvían entre sí son la manera en que dos dashboards empiezan a mostrar dos totales distintos para el mismo mes, y la discusión que sigue cuesta más de lo que el modelo ahorró nunca.

Los nombres de tecnologías —los modelos semánticos de Power BI o DAX para las medidas— encajan aquí, pero en esta guía se quedan en el nivel de nombrar: la disciplina de modelado de arriba es la misma en todas las herramientas, y es la que de verdad determina si los dashboards son creíbles.

Power BI, Tableau y Looker Studio comparados

Los tres entregan los dashboards de arriba; las diferencias están en el encaje. La comparación es deliberadamente cualitativa: las condiciones de licencia y los conjuntos de funciones cambian con frecuencia en este mercado, así que compruebe la información vigente del proveedor antes de decidir y trate cualquier cifra anterior al ciclo de versión actual como una pista y no como un hecho:

Tabla B: criterio | Power BI | Tableau | Looker Studio

Criterio	Power BI	Tableau	Looker Studio
Conectores de datos	Conjunto amplio, con fuentes del ERP y del ecosistema Microsoft incluidas; opciones de gateway para datos on-premises	Conjunto amplio, con fuentes empresariales incluidas; potentes herramientas de preparación	Fuerte en plataformas de publicidad y web; menos conectores de ERP empresarial
Modelo de licencia	Suscripciones por usuario con roles; los términos y niveles cambian: consulte la información vigente de Microsoft	Opciones por usuario y por servidor; los términos cambian: consulte la información vigente del proveedor	Nivel gratuito con opción de espacio de trabajo de pago; orientado al ecosistema Google: consulte los términos vigentes
Gobernanza	Modelo maduro de espacios de trabajo, sensibilidad y seguridad a nivel de fila; encaja en organizaciones ya asentadas en Microsoft	Gobernanza de servidor empresarial con propiedad de contenidos y permisos	Gobernanza más simple; las fuentes de datos compartidas ayudan, pero el modelo es más ligero
Curva de aprendizaje	Asequible para los equipos acostumbrados a Excel; las medidas piden disciplina de modelado	El análisis visual es rápido para los analistas; el modelado tiene sus propios conceptos	El camino más rápido hasta el primer dashboard; en el modelado profundo es donde pide más esfuerzo

La manera honesta de decidir es con sus propias restricciones en la primera columna, no con los productos en las filas: dónde viven los datos (un ecosistema centrado en Microsoft favorece a Power BI por pura conectividad e identidad), quiénes son los usuarios del día a día y quién gobernará el modelo dentro de dos años. Un ejercicio de compra que puntúe estas filas contra sus requisitos por escrito —el método de la lista de comprobación RFP para proveedores— llega a una respuesta defendible; una demostración que compara tres páginas de inicio, no.

Control de acceso y gobernanza

Los dashboards de comercio muestran margen, nombres de clientes y comportamiento de pago, por lo que el acceso es una pregunta comercial antes que técnica:

Seguridad a nivel de fila. Un responsable regional ve su región, un comercial ve sus cuentas, la dirección lo ve todo: aplicado en el modelo de datos y no en copias separadas del dashboard. Las copias separadas son la manera en que vuelve el «dos cifras para el mismo mes».

Roles por encima de informes. El acceso sigue a los puestos, se concede una vez y se revisa periódicamente; que el acceso de una persona que deja la empresa termine con su relación laboral es una rutina de gobernanza, no un proyecto.

Campos sensibles. Las columnas de margen y de coste merecen decisiones explícitas: quién las ve en absoluto y si existe un dashboard sin ellas para una difusión más amplia.

Protección de datos. Los datos personales de clientes en un dashboard caen bajo las mismas obligaciones que la empresa ya tiene: KVKK para las operaciones en Türkiye y GDPR para los datos de clientes europeos, con base jurídica, conservación de los extractos y registros de acceso. Las obligaciones son las mismas que para los sistemas de donde proceden los datos; un dashboard no está exento por el solo hecho de leer. El contexto contractual más amplio, alojamiento y acceso del proveedor incluidos, se trata en la página de externalización de TI.

Actualización y control de cambios. Un dashboard cuya definición cambia debería cambiar de forma visible —una nota de versión, una fecha, un responsable—, porque la redefinición silenciosa de un KPI es la manera en que dos departamentos dejan de confiar en las cifras del otro.

Pasos de implementación

La secuencia que funciona, en orden:

Primero las definiciones de métricas. El diccionario de KPI, aprobado por los responsables comercial, financiero y logístico. Una o dos páginas: todo el riesgo de fracaso del proyecto se sienta en que este paso se haya hecho bien.

Una fuente de datos, un dashboard piloto. Normalmente las facturas del ERP y el dashboard de ventas y margen: la pregunta que más hace la dirección y los datos que suelen estar más limpios. El piloto demuestra a la vez el recorrido, el modelo y la definición.

Prueba de usuarios con preguntas reales. Dé el piloto a tres usuarios reales durante dos semanas, con sus preguntas semanales de verdad, y observe lo que no saben responder. La lista de carencias de esa quincena es el trabajo pendiente que de verdad importa; las peticiones de funciones que genera suelen ser más pequeñas que el temor que despiertan.

Primero corregir, después ampliar. Los problemas de calidad de datos encontrados en el piloto se corrigen en el origen, no en el dashboard: una corrección calculada dentro de un informe oculta un ERP sucio que envenenará todos los dashboards posteriores.

Desplegar por dashboard, no por número de usuarios. Publique los cinco dashboards acordados en secuencia, cada uno con su responsable y su fecha de definición, en lugar de abrir la herramienta a todos de una vez: la segunda mitad del problema de adopción es lo que la gente mira, y cinco dashboards con dueño vencen a un lienzo vacío.

Operarlo. Supervisión de las actualizaciones, un responsable con nombre por dashboard y una revisión trimestral de las definiciones. Un proyecto de BI que termina en la puesta en marcha se convierte en un hobby de informes dentro de un año; la rutina de operación es lo que lo convierte en infraestructura de gestión.

Los pasos 1 y 6 son los que los equipos se saltan, y son los dos que deciden si las cifras son creíbles dieciocho meses después.

Preguntas frecuentes

¿Necesitamos un almacén de datos?

Para empezar, no. Una conexión directa al ERP más un puñado de tablas de dimensiones cubre los primeros cinco dashboards de la mayoría de las empresas de comercio; un almacén de datos se amortiza cuando los sistemas de origen se multiplican, cuando hay que conservar el histórico más allá de la retención del ERP o cuando el rendimiento sufre. El detonante honesto es la repetición: cuando los mismos arreglos de extracción se reconstruyen una y otra vez, esa es la conversación del almacén de datos, y la pregunta de construir o configurar que plantea se trata en la página de ERP a medida frente a estándar.

¿Con qué frecuencia deben actualizarse los datos?

Ajuste la actualización al ciclo de decisión, fuente por fuente: ventas y pedidos abiertos justifican una actualización diaria o casi diaria; stock y cuentas por cobrar, normalmente diaria; marketplaces y alimentaciones bancarias, cada vez que se actualicen de forma fiable. Actualizar con más frecuencia de la que los datos cambian de verdad compra coste sin información, y los fallos de actualización deberían ser visibles para los usuarios y no silenciosos: un dashboard que muestra los datos de ayer como si fueran de hoy es peor que uno que anuncia que va con retraso.

¿Podemos usar exportaciones de Excel?

Sí, como fuente legítima: muchos primeros dashboards funcionan con una rutina de exportación programada y los presupuestos a menudo solo viven en hojas de cálculo. La disciplina consiste en tratar las exportaciones como canales de datos con responsable, calendario y un formato que se comprueba; el modo de fallo es el archivo que llega por correo de forma irregular y se detiene en silencio, llevándose un KPI con él.

¿Quién define los KPI?

Los responsables de negocio de las cifras: los comerciales para ventas y margen, operaciones para inventario y envíos, finanzas para cuentas por cobrar. El equipo de BI traduce las frases acordadas en medidas; cuando el equipo de BI define los KPI por su cuenta, los dashboards miden algo que nadie pidió: técnicamente correcto y organizativamente sin usar.

¿Power BI es gratuito?

Los términos de licencia de este mercado cambian con frecuencia, así que compruebe la información vigente de Microsoft antes de presupuestar, en lugar de fiarse de cifras que pueden ser anteriores al ciclo de versión actual. Lo que no cambia es la forma de la decisión: suscripciones por usuario con roles, una capa de modelado que necesita gobernanza y un coste que suele ser modesto junto a las decisiones que mejoran los dashboards; pero decida con los términos vigentes y por escrito.

¿Cómo protegemos los datos de clientes?

Seguridad a nivel de fila en el modelo, para que cada persona vea lo que su rol permite; decisiones explícitas sobre los campos de margen y de coste; acceso concedido por rol y revisado periódicamente; y las obligaciones de KVKK y GDPR aplicadas a la capa de dashboards —base jurídica, conservación de los extractos, registros de acceso—, exactamente igual que para los sistemas de origen. Las preguntas sobre alojamiento y acceso del proveedor son las mismas que se tratan en la página de externalización de TI y pertenecen al contrato antes de la puesta en marcha.

Fuentes y estándares

El conjunto de KPI, la asignación de fuentes de datos, los conceptos de modelado (hechos, dimensiones, esquema estrella, una sola versión de la verdad), los temas de gobernanza (seguridad a nivel de fila, visibilidad de las actualizaciones, control de cambios) y la secuencia de despliegue siguen la práctica general de inteligencia de negocios para empresas de comercio y logística; en esta página no aparecen estadísticas de uso, cifras de adopción ni resultados medidos.
La comparación de las tres herramientas es deliberadamente cualitativa y carece de precios de licencia, límites y afirmaciones de funciones que cambian entre ciclos de versión; cada fila de licencias instruye al lector para que compruebe la información vigente del proveedor, y no se afirma ninguna relación con Microsoft, Tableau ni Google.
Las afirmaciones de proceso siguen las páginas de este sitio: BI y analítica de datos, ERP a medida frente a estándar (dónde va la capa de datos) y externalización de TI desde Türkiye (obligaciones de KVKK y GDPR, acceso del proveedor, cuestiones contractuales).
Las obligaciones de protección de datos se nombran, no se interpretan: KVKK para las operaciones en Türkiye y GDPR para los datos de clientes europeos se aplican según la situación de la empresa; confirme el régimen aplicable con un asesor cualificado.

Páginas relacionadas

BI y analítica de datos · ERP a medida frente a estándar · Desarrollo de software · Lista de comprobación RFP para proveedores · Automatización con IA · Solicite un presupuesto