Power BI数据看板：贸易公司KPI看板搭建与上线步骤
贸易公司真正需要的是少数几块建立在统一KPI口径和干净ERP数据之上的看板：销售与毛利、库存、应收账款与发运。Power BI、Tableau和Looker Studio都能交付这些看板，所以工具怎么选取决于数据源、使用者和治理要求，而不是功能清单。
贸易公司需要哪些看板？
贸易企业的管理问题每周都在重复那么几组，每一组对应一块看板，而不是一份报表：
- 销售与毛利。 卖了什么、卖给谁、毛利多少——按产品、客户、市场和月份拆分。真正能改变行为的是毛利视角：同一季度里营收可以涨、利润可以缩，只有按毛利切开才看得见。
- 库存。 货在哪里、压了多久、哪些已经不动了。对分销商来说这就是现金看板：库存周转天数和滞销库存占着下一单需要的营运资金。
- 应收账款。 谁欠多少、欠了多久、哪些余额已过到期日。账龄分桶让一本正常的账和一本有问题的账一眼拉开差距。
- 发运。 哪些按期发出、哪些晚了、哪些卡在单据或海关环节。对出口商来说这同时也是服务质量看板，因为客户感受到的延误是一次发运事件，不是一次开票事件。
- 未结订单。 已承诺的、待定的、被阻塞的——决定本周生产、采购和装柜计划的运营全景。
KPI口径定义与数据源
这张表是项目的工作内核：每个KPI需要一个定义、一个负责人和一个数据源，而"常见误区"一列正是大多数看板争议的出生地：
表 A：KPI | 定义 | 数据源 | 常见误区
| KPI | 定义 | 数据源 | 常见误区 |
|---|---|---|---|
| 销售额 | 按约定币种、按期间、按产品/客户/市场统计的已开票净销售额 | ERP发票（仅已过账凭证） | 按订单而非发票统计，或未加说明地把贷项通知单算进来 |
| 毛利 | 销售额减去已售商品成本，有成本核算的按行计算 | ERP发票关联成本或库存数据 | 跨产品取平均，把亏损线藏进健康的总计里；成本比销售滞后一个期间 |
| 库存周转天数 | 期间平均库存金额除以期间每日销售成本 | ERP存货计价与成本数据 | 年中变更计价基础（加权平均、FIFO）而看板不知情；各仓规则不同却合并计算 |
| 应收账款账龄 | 未结余额按逾期天数分桶、按客户列示 | ERP未结项目 | 把有争议的发票当成单纯逾期；分桶后才发生的贷项通知单减少了余额却被忽略 |
| 准时发运率 | 在约定日期当日或之前发出的发运占期间发运量的比例 | ERP发运记录 + 运输单据或物流系统 | 各团队自行定义"约定日期"；按单据日期而非实际离场时间统计 |
| 未结订单 | 已承诺与待定订单金额，受阻订单单独列示 | ERP订单簿 | 把确认订单与暂定订单混在一起；用一个总数掩盖受阻占比 |
有两条纪律让这张表保持可用。定义要用平实的业务语言写，而不是公式——公式属于数据模型，句子属于字典，而商务团队据以争论的正是那句话。每条定义都要带日期和负责人：业务在变，口径也会漂移；一块按去年定义运行的看板是悄悄出错，而不是诚实地过时。这一层该放进新系统还是留在现有ERP，自研与成品ERP对比页有讨论，BI与数据分析页则覆盖更广的方法论。
数据源与ERP系统集成
贸易公司的事实分散在五套系统里，BI层的工作是在不编造任何东西的前提下把它们连起来：
- ERP。 发票、订单、库存、付款、主数据。首要数据源，通常也是唯一具备事务一致性的来源。
- 电子表格。 目标、预算、手工调整，以及存在某个人文件里的影子数字。要认真对待——只存在于表格里的预算仍然是真预算——但要把它们作为带负责人的数据接入，而不是当邮件附件收进来。
- 电商与第三方平台。 线上业务的订单与流量；渠道数据很少与ERP一一对应，于是映射规则（什么算一笔销售、算在哪天）也成为字典的一部分。
- 物流。 发运记录、追踪编号、承运人状态——准时率和发运看板的数据源，也是最常需要手工键入或合作方数据推送的一个。
- 银行。 收款与付款，与未结项目核对——连接应收看板与现金现实的桥梁。
数据模型基础
不必成为数据工程师也能把这件事做对，但三个概念决定项目能否活过第二年：
- 事实与维度。 事实是事件——发票行、发运、付款——带着数量和金额；维度是语境——产品、客户、市场、日期、仓库——带着你筛选和分组用的属性。上表中每个KPI都是按维度切开的事实聚合，这正是一个模型能服务五块看板的原因。
- 刻意采用星型模型。 事实居中、维度环绕，不走取巧的多对多捷径，度量才可加：按地区汇总的销售额等于按月汇总的销售额，也等于销售总额。跳过这种结构的模型演示时好好的，到第三张报表就散架。
- 单一事实来源。 每张事实表里用同一套产品编码、客户编码和币种，取自同一份主数据。复制出来的维度各自漂移，两块看板就会对同一个月给出两个不同的合计——随后那场争论的成本，超过模型省下的一切。
Power BI、Tableau与Looker Studio对比
三者都能交付上文的看板，差别在于是否合身。下表刻意采用定性比较——这个市场的授权条款和功能集变化频繁，决定之前请核对厂商的最新信息，任何早于当前发布周期的数字都只能当提示、不能当事实：
表 B：比较项 | Power BI | Tableau | Looker Studio
| 比较项 | Power BI | Tableau | Looker Studio |
|---|---|---|---|
| 数据连接器 | 覆盖面广，含ERP与微软技术栈数据源；本地部署数据可用网关 | 覆盖面广，含企业级数据源；数据准备工具强 | 广告与网络平台表现出色；企业ERP连接器较少 |
| 授权模式 | 按用户订阅并配角色；条款与档位会变——请核对微软最新信息 | 按用户与服务器两种选项；条款会变——请核对厂商最新信息 | 免费层加付费工作区选项；面向谷歌生态——请核对最新条款 |
| 治理 | 成熟的工作区、敏感度与行级安全模型，适合已在微软体系内的组织 | 企业服务器治理，具备内容归属与权限管理 | 治理更简单；共享数据源有帮助，但模型较轻 |
| 学习曲线 | 熟悉Excel的团队容易上手；度量需要建模纪律 | 可视化分析对分析师上手快；建模另有一套概念 | 最快见到第一块看板；深入建模是它要你多投入的地方 |
诚实的决策办法是把你的约束放在第一列，而不是把产品放进各行：数据住在哪里（以微软为中心的体系会单纯因为连通性和身份管理而偏向Power BI）、日常使用者是谁、两年后由谁治理模型。一场按你的书面需求给这些行打分的采购——供应商RFP清单上的方法——能得出站得住的答案；一场比较三个首页的演示不能。
访问控制与数据治理
贸易看板呈现毛利、客户名称和付款行为，所以访问权限先是商业问题，后是技术问题：
- 行级安全。 区域经理看自己的区域，销售人员看自己的客户，董事会看全部——在数据模型里强制执行，而不是靠几份分开的看板副本。"同一个月两个数字"就是从副本回来的。
- 按角色授权，而不是按报表授权。 权限跟随岗位角色，授予一次、定期复核；离职即结束权限是治理的例行工作，不是一个项目。
- 敏感字段。 毛利和成本列值得明确决策——谁可以看、以及是否要有一块不含这些列的看板用于更大范围流转。
- 数据保护。 看板中的客户个人数据适用公司本就承担的同一套义务：土耳其业务适用KVKK，欧洲客户数据适用GDPR，涉及处理合法性基础、导出数据留存和访问日志。义务与数据来源系统完全相同；看板不因为它只读数据就获得豁免。更广的合同语境，包括托管与厂商访问，见IT外包页。
- 刷新与变更控制。 看板定义变了就应该看得见——版本说明、日期、负责人——因为悄悄改写一个KPI口径，正是两个部门彼此不再信任数字的方式。
实施步骤
行得通的顺序：
- 先定指标口径。 KPI字典，由商务、财务和物流负责人签认。一两页纸；整个项目的风险都压在这一步是否做扎实。
- 一个数据源，一块试点看板。 通常是ERP发票加销售毛利看板——管理层问得最多的问题、数据通常也最干净的那一块。试点同时验证管道、模型和口径。
- 用真实问题做用户测试。 把试点交给三个真实用户用两周，带着他们每周实际要回答的问题，观察他们答不上来的东西。这两周攒下的差距清单才是要紧的待办；由此产生的功能诉求通常比想象中少。
- 先修源头，再扩展。 试点中发现的数据质量问题要在源头修，不是在看板里修——在报表里算出来的修补会掩盖脏的ERP，而它会污染之后每一块看板。
- 按看板推进，而不是按用户数推进。 把五块约定好的看板依次交付，每块带负责人和口径日期，而不是一次性把工具向所有人开放——推广问题的后半段是人们到底看什么，五块有主的看板胜过一张空白画布。
- 把它当系统来运维。 刷新监控、每块看板一名明确的负责人、每季度一次口径复审。上线即结束的BI项目，一年内就会沦为报表爱好；让它成为管理基础设施的，是运维例行工作。
常见问题
我们需要数据仓库吗？
起步不需要。对ERP的直连加几张维度表，多数贸易公司的前五块看板就够了；当源系统开始变多、历史要保存得比ERP留存期更长、或者性能成为瓶颈时，仓库才值回成本。诚实的触发信号是重复：同一批取数变通办法被反复重建，就是该谈仓库的时候了——随之而来的自建还是配置的问题，自研与成品ERP对比页有讨论。
数据多久刷新一次？
按数据源、跟着决策周期走：销售和未结订单支持每日或接近每日；库存和应收账款通常每日；电商平台和银行数据按其可靠更新的频率来。比数据实际变化更频繁的刷新，买到的是成本而不是信息；刷新失败应当让用户看见，而不是悄无声息——把昨天的数据当作今天展示的看板，比明说自己迟到的看板更糟。
可以用Excel导出吗？
可以，把它当作正当的数据源——很多第一版看板就跑在定时导出例程上，预算也常常只存在于表格里。纪律在于把导出当作数据馈送来对待：有负责人、有排程、有被检查的格式；失败形态则是那个不定期到达、又悄悄停掉的邮件文件，顺手带走一个KPI。
KPI由谁定义？
由对数字负业务责任的人：销售和毛利归商务负责人，库存和发运归运营，应收账款归财务。BI团队负责把商定好的句子翻译成度量；当KPI由BI团队独自定义时，测的就是没人要的东西——技术上正确，组织里没人用。
Power BI免费吗？
这个市场的授权条款变化频繁，做预算之前请核对微软的最新信息，不要依赖可能早于当前发布周期的数字。不变的是决策的形态：按用户订阅并配角色、一个需要治理的建模层，以及相对于看板所改善的决策而言通常不算大的成本——但要按当前条款、以书面形式做决定。
客户数据怎么保护？
在模型里做行级安全，让人们只看到角色允许的内容；对毛利和成本字段做明确决策；按角色授予权限并定期复核；把KVKK/GDPR义务应用到看板层——合法性基础、导出留存、访问日志——与源系统一视同仁。托管与厂商访问的问题，IT外包页有同样的讨论，而且应当在上线之前写进合同。
资料来源与标准
- 这里的KPI集合、数据源映射、建模概念（事实、维度、星型模型、单一事实来源）、治理主题（行级安全、刷新可见性、变更控制）和推广顺序，沿用面向贸易与物流企业的通用商业智能实践；本页不出现任何使用统计、采用率数字或实测结果。
- 三工具对比刻意采用定性方式，不含授权价格、限制和随发布周期变化的功能宣称；每一行授权信息都提示读者核对厂商最新资料，本页不声称与Microsoft、Tableau或Google存在任何合作关系。
- 流程表述沿用本站页面：BI与数据分析、自研与成品ERP（数据层归属），以及土耳其IT外包（KVKK与GDPR义务、厂商访问、合同问题）。
- 数据保护义务只点名、不解读：KVKK适用于土耳其业务，GDPR适用于欧洲客户数据，具体按公司情况适用；请与合格顾问确认适用规则。