我在过去七年里深度参与了至少四十家传统企业的BI落地项目，从年营收3亿的民营制造厂到千亿规模的国企集团，都留下过或成功或惨败的痕迹。一个反复出现的现实让我不得不正视：绝大多数企业花了几十万甚至上百万引入BI平台，最终使用者不超过总员工的5%，高管在一个季度后基本不再打开，业务部门私下抱怨“又多了一个填数据的活”，而IT部门则委屈地觉得“我们做的系统明明很强大，为什么没人用”。如果你也在经历类似的困境，或者正在犹豫要不要启动BI项目，这篇文章的结论可能会让你不太舒服，但它至少是真实的。
先给一个我自己的观察数据。2021年我用三个月时间追踪了11家已经上线BI平台超过一年的传统企业，做了一个粗糙但认真的“使用深度评估”。评估维度不是“有没有人登录”，而是“BI输出的结论是否被纳入过正式的经营决策会议议程”。
结果是：11家企业中，只有2家做到了“决策层月度经营分析会上，BI仪表盘是会议的主要议程载体”。剩下的9家，BI的输出要么被压缩成PDF附件提前发给领导“仅供参考”，要么被某个业务部门摘取其中几张图表放进自己的PPT汇报里，原始的数据分析链路完全断裂。
这个统计很粗糙，样本量也小，但我把它写在这里的原因是：之后四年里，我在不同场合、不同企业反复验证过这一分布，结论几乎没有变化。你可以认为这是个人经验，但它代表了一种真实。
那么问题来了：既然大部分BI项目最终都沦为“昂贵的摆设”，为什么还有企业前赴后继地上BI？答案藏在“推不动”背后的第一层逻辑里。
在很多传统企业里，BI项目的立项流程是这样的：IT部门提出需求，IT部门做选型调研，IT部门写立项报告，管理层审批通过，IT部门主导实施。整个链条里，业务的角色最多出现在“需求调研阶段”做一个被访谈者，然后项目就进入了漫长的技术实施期。
这里面有一个根本性的错位：
| 你以为BI解决的是 | 实际上BI解决的是 |
|---|---|
| 数据提取效率问题 | 决策逻辑的重构问题 |
| 报表制作速度问题 | 谁来定义“什么是重要的” |
| 系统打通的技术难题 | 组织内信息权力的再分配 |
| 可视化的美观程度 | 不同部门之间的信任机制 |
当一个IT总监信心满满地向我展示他选的BI产品的技术架构有多先进时，我通常会问他一个问题：“你未来的BI系统里，产品退货率这个指标，最终以哪个部门的定义为准？质量部？售后部？还是财务部？”这个问题一问出口，90%的IT负责人会愣住。因为这不是技术问题，这是政治问题。
传统企业的IT团队习惯用项目管理的方式推进一切：先做蓝图规划，再做数据治理，然后搭数据仓库，接着建数据模型，最后做报表开发。一套流程走下来小半年过去了，等终于拿出第一批仪表板准备给业务部门展示时，业务部门的反应往往是：“你们做了半年就做了这个？”
问题出在哪里？工程化思维擅长处理确定性强的技术问题，但BI落地本质上是变革管理问题。数据治理不是技术做完就结束的，它需要在业务场景中反复验证和迭代。你把数据治理放在最前面，花两个月把所有主数据标准统一了，结果第一个BI应用场景是“客服工单分析”，而客服系统的数据根本不在你的主数据治理范围内，这属于典型的“用大炮打蚊子还打歪了”。
我听过的关于业务部门最多的抱怨，来自IT团队：“他们根本说不清自己要什么”、“问他们需求就一句话，能自动出决策报告就行”、“给他们做的报表从来不看，天天来问我们要数据”。
但我站在业务方角度去看的时候，看到的是完全不同的画面：
业务部门不是不配合，他们是“没有被设计进协作流程里”。
在BI项目里最稀缺的，不是技术专家，也不是业务高手，而是能把业务问题翻译成数据需求、又能把数据结论翻译回业务动作的人。我习惯叫这个角色“数据翻译官”，有些企业叫“数据分析师”或“BI产品经理”，但不管叫什么，这个角色必须同时具备以下能力：
多数传统企业的组织架构里根本没有这个岗。IT部擅长技术、业务部擅长业务、管理层要结果，中间这个“翻译层”是真空的。结果是：IT按自己理解开发了平台，业务按自己习惯绕过了平台。
传统企业里，“看数据”这件事儿几十年来就是“看报表”。报表的特点是：固定格式、固定周期、事后汇总、逐级上报。而BI的初衷是“自助分析、探索式分析、实时监控”，这两者在使用习惯上有着根本冲突。
我见过最典型的场景：某快消品企业的区域经理，每个月5号收到一份当月销售统计报表，格式二十年没变过。他养成的习惯是：先看总额是否达标，再看重点产品销售是否正常，然后签个字交上去。你给他上线一个BI平台，期望他自己去钻取、联动、对比，他内心真正的想法是：“我按原来的方式五分钟就搞定了，现在要摸索十分钟还不一定找到我要的东西。”他没有说错，对于他的实际工作场景来说，固定报表的效率确实高于自助BI。
这不是他的问题。是你的BI没有解决“他更需要的东西”，比如：在月中就开始预警哪些区域可能完不成目标、告诉他哪个经销商库存已经连续三周异常、或者在竞品调价后自动分析对他负责区域的影响。如果BI不能提供“比固定报表更强的增量价值”，那被抛弃就是必然的。
很多BI文章会说“中层管理者的抵制是数字化转型的最大障碍”，这个判断太粗糙了。我的观察是：中层管理者对BI的态度，完全取决于BI是增加了他们的掌控感，还是削弱了他们的掌控感。
如果BI让他们“更早发现本部门的异常、更快做出应对、更清晰地向高层展示成绩”，他们就是最积极的推动者。如果BI让他们“被高层实时监控、所有失误无所遁形、失去了对数据解释的主动权”，他们当然会无声抵制。
这里面有一个微妙但关键的心理机制：
所以问题不是“中层抵不抵制”，而是你设计的BI系统，在底层逻辑上是“监控工具”还是“赋能工具”？大多推广失败的BI，本质上是前者披着后者的外衣。
2023年我参与的一个制造企业的BI项目，就踩了这个坑。最初上线的版本中，生产总监的仪表板上有一个“各车间OEE实时对比排名”，每天自动刷新。设计初衷是“激励各车间提高设备综合效率”，结果上线第二周，三个车间主任同时向生产总监投诉：“这个排名算法有问题，我们的设备类型不一样，这样比不公平。”投诉的背后真正原因是什么？是这个排名直接暴露了二车间连续三个月设备维护不及时的事实，而这个事实二车间主任一直自己知道、但没让上面知道。
后来我们调整了策略：不再做跨车间的横向排名，而是给每个车间一个“本车间OEE趋势与异常预警”视图，同时把设备维护的工单数据拉进来，做成一个“设备健康指数”。车间主任看到的是：我的设备哪些指标在恶化、预计什么时候需要维护、维护成本预估是多少。他从“被监控者”变成了“信息的使用者”。三个月后，二车间的OEE提升了11个百分点，不是因为他们被排名逼迫，而是因为他们主动申请了一笔设备保养预算。
我从来没有见过哪家企业的老板会说“数字化转型不重要”。每一家都重要，每一家都是一把手工程。但你去看老板的实际行为：
这三个问题能直接测出一把手对BI的真实态度。态度不是听他说什么，是看他把注意力分配到了什么地方。
我经历过的最典型场景：某企业老板在BI项目启动会上发表了慷慨激昂的动员讲话，说这是今年的战略级项目。三个月后我参加他们的月度经营会，业务副总做汇报时用的仍然是PPT，里面插了几张从BI系统截图的数据图表。整个会议两个小时，没有一次打开过BI系统进行实时数据验证或钻取分析。老板也没有要求。会议结束时老板对我说：“BI系统挺好的，你看王总已经在用了。”，王总的“使用”就是截了三张图。
这不是在批评。这是想说明一个深层问题：高层的决策习惯没有被纳入变革范围。如果经营会的议程、汇报模板、提问逻辑都没有变，只是让底下人多了一个数据工具，那BI永远在决策链的外围。
真正把BI用起来的企业，往往做了同一件事：把月度经营分析会的议程载体从PPT切换为BI仪表板。
这听起来像个形式上的变化，但它的冲击是结构性的：
这种变化会自然淘汰掉靠信息不对称维持权力的中层，也会自然筛选出真正愿意靠数据决策的高层。这套逻辑在很多书籍和咨询报告里都有提及，但真正做到了的企业不到我接触过的5%。
几乎所有传统企业在面对BI时都会说：“我们的数据基础太差了，系统之间没有打通，主数据不一致，历史数据有很多脏数据，能不能先做数据治理再上BI？”
我的回答通常是：你把数据治理和BI实施的先后顺序搞反了。
纯数据治理项目是典型的“投入大、周期长、看不到短期成果”的项目。你花半年把ERP、CRM、WMS、TMS等各种系统的数据标准统一了，业务方看不到任何直接价值，最后他们会说：“你们IT花半年就做了一堆数据标准文档？”但如果你用一个具体的业务场景驱动数据治理，比如“我们想分析经销商渠道的库存周转情况”，你会发现：跟这个场景相关的表只有十几张，需要对齐的主数据只有客户和产品两个维度，脏数据的清洗范围也很明确。三周就能出第一版结果。
用业务场景倒逼数据治理，而不是治理完了再谈场景。
有一个反直觉的发现，来自我多年的观察：业务部门口中的“数据不准”，在大部分情况下并不是真的不相信数据，而是不认同数据呈现的结论。
当数据显示他们的区域业绩排名靠前时，没有人会质疑数据准确性。当数据显示他们的费用率高于公司平均水平时，“数据不准”的说法就开始出现了。这是人性，不是技术问题。
我的处理方式是：首次使用BI数据的会议，预留15分钟专门做“数据一致性确认”，当着所有部门负责人的面，用BI系统对关键指标的取数逻辑进行逐字段解释。解释完后，愿意认可这套逻辑的部门留下，有异议的部门给出他们的数据源，现场对比。通常两轮会议之后，“数据不准”的声音就会降到极低水平。
这个方法没有技术含量，但它是组织信任的建立过程。很多IT团队把它跳过去了，直接进入“功能演示”阶段，然后被业务方用“数据不准”挡在门外。
传统企业选BI平台的标准流程是：供应商来做POC（概念验证），用企业的真实数据搭建几个仪表板，然后各个部门负责人来打分。哪家做出来的界面好看、功能炫、响应快，哪家的分就高。
这个流程天生有利于会做PPT的供应商，而不是真正适合企业长期发展的产品。
POC阶段搭建的仪表板是供应商投入了最优资源（总部技术支持专家+行业顾问）在特定数据集上精雕细琢的结果。这相当于拿供应商的上限能力来测试，测试通过后就认为他们能持续输出这个水平，但实际上签完合同进场的是当地实施团队，原厂专家一年来一次就不错了。
我提供两个更靠谱的评估维度：
选型时另一个被忽略的维度是：你们企业现有团队的技术栈和这个产品匹配吗？
如果你们IT团队全是SQL高手，选了一个拖拽式自助BI（零代码产品），让他们去给业务做数据准备和复杂逻辑开发，他们会很痛苦，效率反而降低。如果你们业务部门几乎没有数据分析基础，选了一个需要写公式和脚本的强大分析工具，那推广难度会指数级上升。
我做过一个简单的适配框架，供参考：
| 企业特征 | 更适合的BI类型 | 注意事项 |
|---|---|---|
| IT团队强、业务弱 | 报表导向型BI（如帆软FineReport类） | 容易变成IT包办一切，业务还是不用 |
| 业务有分析基础、IT弱 | 自助分析型BI（如Tableau、Power BI类） | 需要配专门的“数据翻译官”角色 |
| IT和业务都不算强 | 模板化轻量BI（如简道云、九数云类SaaS） | 复杂分析能力有限，适合标准化场景 |
| IT和业务都很强 | 全栈型BI平台（如帆软FineBI类） | 需要强有力的内部运营把两端拉通 |
基于过去多年的观察，我把BI“推不动”最终导致项目实质性死亡的路径归纳为五种。每一种的成因和应对策略都不同。
表现：项目启动时高层很重视，但三个月后被另一个更重要的事（比如并购、新产品上市、组织调整）覆盖了注意力，BI项目失去了权力支撑，推进速度骤降，业务部门感知到优先级变化后迅速“用脚投票”。
核心矛盾：BI项目的价值释放周期（通常6-12个月才能看到真正的决策价值）远长于高管的注意力周期（通常在3个月左右会出现疲劳）。
应对策略：不要把宝押在“高层持续关注”上。在项目启动时就要设计多个短期可见的小胜利（我称之为“数据飞轮上的小赢”）：第一个月解决一个具体业务痛点（比如库存预警），第二个月解决另一个（比如销售日报自动化），用连续的小成果维持组织对BI的期待值，把项目从“等待大回报”变成“持续小回报”的节奏。
表现：BI上线后第一次在正式场合（经营会、部门会）展示数据，结果被发现取数逻辑有问题或者数据滞后严重，当场被业务方或高管指出错误。此后“BI数据不靠谱”的标签就牢牢贴上了，再花多少时间修正也很难撕掉。
核心矛盾：第一印象的破坏力远超后续修正的修复力。数据产品天然具有“一次失信、长期不信任”的特质。
应对策略：首次公开展示的数据范围要极度保守。宁可只展示三个指标（但保证100%准确），也不要展示三十个指标（可能有一个错的）。首次亮相的底线不是“展示能力”，而是“建立信任”。如果有可能，首次数据展示前做一个“预演”，邀请最挑剔的那个部门负责人私下先看一遍，把可能的问题在公开之前解决掉。
表现：BI实施时选择了“容易开发”的场景作为切入点（比如财务三大报表、人力资源统计），而不是“业务最痛”的场景。上线后业务方觉得“有没有这个系统差别不大”，参与度持续走低。
核心矛盾：IT选择场景的标准是“数据完整度高、开发难度低”，而业务关心的场景是“能帮我省钱或多赚钱”，两者很少重叠。
应对策略：在选第一个BI应用场景时，用一个简单的坐标轴来判定：横轴是“业务价值”，纵轴是“数据可获得性”。选那些业务价值极高、但数据可获得性只有60分左右的场景，而不是反过来选数据完美但价值有限的场景。因为业务价值高，才会有人愿意配合你攻克那些数据缺失和脏乱问题。
表现：BI平台上线后有一个“推广培训期”，业务部门被要求参加培训、学习使用。培训结束后，IT团队认为“已经教会了”，业务团队认为“学会了但没时间用”。没有人持续运营，三个月后打开率降到冰点。
核心矛盾：BI平台的使用习惯养成需要至少6-8周的持续触达和激励，而多数企业在上线后第3周就停止了一切运营动作。
应对策略：设立一个“BI运营专员”的角色，哪怕只是兼职。这个人的核心工作是：每周分析一次登录数据，找出“最近七天没登录”的核心用户，主动联系了解原因；每月组织一次“数据发现分享会”，让用BI发现了有价值洞见的业务人员分享经验（并给小额奖励）；每个季度做一次“仪表板活跃度排行榜”，给前三个最活跃的仪表板制作者公开表彰。
表现：BI项目的核心推动者（可能是某个IT骨干、某个懂数据的业务经理、甚至就是CIO本人）离职了，人走之后整个BI运营体系瞬间停摆，没有人能接上。
核心矛盾：BI项目在国内传统企业里高度依赖个人英雄主义推动，制度化程度低。核心人物离开意味着知识断层和推动力消失。
应对策略：在BI项目初期就有意识地把知识沉淀为制度。具体操作包括：要求核心人物把每个分析模型的设计逻辑写成文档（即使只有他自己看得懂也要写）；在团队内建立“备份角色”，每块内容至少两人知晓；把BI使用的关键步骤嵌入正式的业务流程（比如“月度销售预测必须引用BI分析结果”），让制度而不是人情维系BI的运转。
不需要大而全的改革，先把下面这几件具体的事做了：
打开下次月度经营会的会议议程，看一看：决策看的是PPT还是BI？如果是PPT，BI的输出有没有出现在任何一页上？如果BI没有在最重要的决策会议上占据哪怕一个固定的位置，那你的BI只是在“做报表”，不是在“服务决策”。
下一步行动：和管理层讨论，下一季度的某一次经营分析会，能否以BI仪表板为主要议程载体做一次试点。哪怕只是这个会上三个议题中的一个。
在BI的后台拉一个登录记录，筛选出过去30天登录天数超过10天的用户。这些人是你的种子用户。去和他们聊：他们用BI在解决什么具体问题？他们觉得最好用的功能是什么？他们最受不了的是什么？从这些人的反馈中你才能看到“活着的使用场景”，而不是你假想的。
下一步行动：给这5%的人一个正式的身份，“数据推广先锋”，给一点实际的好处（绩效加分、一定额度奖金），让他们成为BI推广的内部代言人。
不管是从业务部门调人培养，还是从IT部门选人转型，还是干脆外招，这个角色必须存在。不用多，一个中型企业配1-2个人就够了。岗位职责写清楚三条：
下一步行动：写一份“数据翻译官”的岗位职责书，和HR以及业务部门负责人讨论这个人放在哪个团队最合适（建议放在运营管理部或总裁办，不要单纯挂在IT下面）。
多数企业的BI平台上，仪表板数量远超过需要。打开你的BI首页，数一数有多少仪表板？其中过去30天被打开过的又有多少？不活跃的仪表板不是“放着也没关系”，它们会稀释用户的注意力，让真正重要的信息被淹没。
下一步行动：把BI平台上超过60天零打开的仪表板，全部设为“不活跃状态”（不删除，但不出现在推荐列表）。让首页只剩下真正被使用的核心视图。
很多企业在BI上线一年后就开始考虑“升级”，增加AI预测功能、增加移动端、增加实时数据流。但这些功能在“基础使用习惯都没养成”的阶段，投入产出极低。先把最基础的“让管理层把BI当决策工具”这件事做扎实，再去谈功能扩展。
下一步行动：做一个“BI功能使用率统计”，看看哪些功能实际被用过。你大概率会发现“拖拽关联分析”、“自由下钻”、“自助创建指标”这些在POC时重点展示的高级功能，上线后使用率很低。不是功能不好，是阶段不对。
大部分传统企业的BI推不动，根源在于组织在潜意识里并不真的想“用数据说话”。
“用数据说话”听起来是绝对正确的。但当你真的把它翻译成组织行为时，它意味着：
对于依靠经验、人情和信息不对称运转了几十年的传统组织来说，这不仅仅是“换个工具”的事儿，这是权力运行机制的重构。那些BI用得好的企业，不是因为买的平台更好，也不是因为IT技术更强，而是因为组织已经准备好了接受这种运行方式，或者被市场逼到了不得不接受的地步。
如果你正在推BI，真正要问自己的不是“选哪家产品”，而是：
这三个问题想清楚了，选什么产品、用什么实施方法，都是战术问题。这三个问题没想清楚，花多少钱上多好的平台，最终的结局都是又一个“昂贵的摆设”。
真正的数字化不是让数据变多，是让权力更透明。这句话我说过很多次，每一次都会在会议室里引发一阵沉默，然后才有人开始点头。希望读到这里，你能理解那个沉默意味着什么。
我们公司老板去年大会上拍板花了两百多万上BI，还成立了数字化转型领导小组，结果半年过去了，除了IT部门在用，业务部门根本没人碰。老板自己也只问过两次销售总表，后来就再没提过。这到底是工具不行还是人不行？
我在多个传统制造企业BI落地项目中观察到，一把手投入度经常是‘假性投入’：口头重视、预算到位，但行为上却缺席。比如某集团CEO在第一阶段评审会上全程看手机，对数据治理议题避而不谈。真正的推动力来自一把手的‘介入度’，每周亲自参与数据回顾会、公开表扬用数据做决策的管理者、将‘数据考核’纳入绩效。
而多数一把手只做到了‘投入资源’（花钱、建系统），却做不到‘投入时间’（用数据、问数据）。据我测算，一把手每周在BI相关事务上花的时间少于2小时的项目，失败率高达82%。对比美的集团方洪波，他每月亲自审查数据周报，并直接质疑业务部门的‘经验判断’。
所以，别再说‘一把手工程’了，先问问你家老板在数据上花了多少时间。
我们IT部门辛辛苦苦把ERP、CRM、MES的数据全都接入BI，做了统一的指标口径，结果销售总监开会时说‘你们这个BI数据有问题，明明是500万，它显示450万’，然后大家就不看BI了。这到底是谁的锅？
数据不准往往是业务部门‘防御性反应’的表现，他们害怕BI暴露其管理漏洞。我曾服务一家年营收30亿的食品企业，上线BI后仓库账实相符率突然从95%掉到78%。一查发现，仓管员习惯手工改单补货，而BI实时抓取后暴露了流程问题。业务部门第一反应是‘系统不准’，实际上是不愿承认自己的操作不规范。
解决方案不是去修系统，而是建立‘数据责任矩阵’：每个数据源有业务owner，owner需签字确认数据质量。同时要设定‘灰度期’：前三个月新旧报表并行，允许业务部门质疑并修改，但第四个月强制切换。最终这家企业用了5个月把账实相符率提升到98%。
记住：数据不准的归因，80%在流程和管理，只有20%在技术。
我们IT团队调研了三个月，参考了Gartner的行业最佳实践，上线了一套功能强大的BI平台，包含自助分析、移动端看板、预警推送。结果业务部门说太复杂，又要学拖拽又要理解模型，还是喜欢每周让IT帮他们导Excel。这到底是业务懒还是IT做的有问题？
IT犯了一个经典错误：把BI当成了‘IT项目’而非‘业务产品’。某大型家居企业IT团队花半年搭建了全集团数据仓库，但业务部门拿到手的是一堆逻辑表名和维度度量，根本不知道‘月复购率’对应哪个字段。
后来我们换了个策略：把业务部门最痛的三个场景（应收账龄预警、退换货分析、渠道库存健康度）做成小快灵的可视化看板，让业务方直接体验‘秒级洞察’，他们才慢慢接受。另外必须配备‘数据翻译官’，既懂业务又懂数据的角色，负责将IT的技术语言转译成业务的决策语言。
比如，不是告诉业务‘这是关联引擎’，而是说‘你可以根据客户画像筛选高价值人群’。从‘大而全’到‘小快灵’，从‘技术驱动’到‘场景驱动’，这是BI推广的关键转折。
公司内部推BI大半年了，生产副总每次开会还是拿一张纸质报表，指着上面的数字说‘我干了三十年，一眼就知道哪里有问题’。BI系统里明明有实时预警、异常归因，但他从来不点开看。数据文化到底怎么落地？
数据文化不是靠喊口号建立的，而是一场‘经验权威’与‘数据权威’的隐性博弈。我见过一个极端案例：某汽车零部件企业，厂长在会议室墙上挂了一块大屏，但每次开会他只看自己的小本本。
后来我们用了‘数据故事化’破局：把库存周转率下降5%这个冷数据，包装成一个‘过去三个月因缺料导致生产线停线3次，每次损失50万’的动画故事，让厂长意识到数据的代价。
另一个有效手段是‘数据成果透明化’：在月度经营会上，强制要求所有汇报必须基于BI仪表盘展示数据，并且设置‘数据最佳决策奖’，奖励那些用数据挖掘出异常并带来节约的团队。从‘老人家的经验’到‘年轻的数据派’，需要找一个旗手，通常是愿意试新的中层管理者，让他先做出一个小胜利，然后所有人都会跟进。
读者评论
做过同类项目的人看到文章里那句“IT做报表业务摘图进PPT”简直想握手。我们公司BI上线两年，最终状态就是高层要数据时，业务部门从系统里截图美化一下做成PPT。问为什么不直接看系统，答曰领导没这个习惯。文章里说的数据翻译官缺失太准了，我们就是缺这么个人，结果IT觉得做完了，业务觉得不好用，两边互相埋怨。这文章把中间那层真空说透了。
作为一家制造企业的IT负责人，文章里生产车间OEE排名那个案例看得我后背发凉。我们去年也踩了同样的坑，上线第一个月车间主任集体投诉算法不公，后来改成只看自身趋势才消停。现在反思，当时确实只想着怎么展示数据，没想过数据展示出来对车间主任意味着什么。文章说BI本质是权力再分配，这话糙理不糙。
文章里那个“决策层是否把BI纳入会议议程”的统计太扎心了。我是财务出身，参加过的经营分析会十有八九还是领导对着打印出来的Excel表拍脑袋。老板说数字化转型喊了三年，BI系统也买了，但每次开会他更习惯听副总口头汇报。不是不想用，是几十年的决策习惯改不了。文章说的对，一把手不改变自己的信息获取方式，BI永远在决策链之外。
文章把业务部门不配合的原因讲清楚了。我们销售部门被IT拉去开过需求会，问我们想要什么图表，我们哪说得清啊。后来系统做出来，一堆花里胡哨的仪表盘，但我就是想知道每个月的回款缺口和预警，得自己翻半天。文章说的对，不是我们不配合，是系统没解决我们最痛的点。后来公司换了个懂业务的BI产品经理，按我们实际工作流重新设计，现在每天上班先看三张图，这才是正道。