为什么80%的业务人员不会用你的BI？重新定义易用性才能让数据用起来

导语

BI 进入中国企业的第 15 个年头，采购量翻了几番，单价一降再降，可一个老问题始终没解决：80% 的业务人员，仍然不会用。账单上写着"全员赋能"，办公位上摆着账号，真正每天打开 BI 看板的人，往往还是那 20% 的数据分析师和数据爱好者。问题出在哪里？多数讨论会把矛头指向"人不够努力"或"培训不够多"，但如果我们把视角翻过来，从"业务人员拿到 BI 之后到底发生了什么"去复盘，会发现根源不在用户侧，而在于产品对"易用性"的定义，从起点就跑偏了。

很长一段时间，"易用性"被等同于"操作步骤少"或"拖拽即可出图"。这是一种典型的工程师视角——把复杂留给自己，把简单留给界面。但业务人员要的不是"少点几次鼠标"，而是"在真实的业务场景里，能用数据把事办成"。一个门店店长早上 9 点想知道昨天哪款新品卖爆了、要不要补单；一个区域销售想搞清楚本周差额的客户是谁、要不要提前介入。当 BI 只能给出一张需要解读的图表，而不能给出"该不该补、补多少、找谁"的建议时，它对业务人员来说，就还是一份"另一个系统里多出来的报表"。

本文想做的，是把"易用性"这个词重新拆开来谈。先界定什么才是业务人员真正"用得起来"的 BI——它必须同时满足低门槛、场景化、可闭环、能对话四个条件；再具体到产品侧，给出四个可以落地的设计动作：把复杂查询封装成业务任务，让 ChatBI 接管问答入口，用指标中心统一口径，以及用订阅预警把洞察主动推到人面前。这四件事不靠概念包装，而是一行行产品能力堆出来的。读完之后，你会看到"让 80% 的人用上 BI"这件事，其实有一套可被设计的产品方法论。

先厘清一个定义：业务人员眼中的"易用"≠ 厂商眼里的"自助"

把"自助"等同于"易用"，是过去十年 BI 行业最常见的一个误读。

厂商语境里的"自助"，关键词是"少写 SQL、多拖拽"：把数据准备好、把字段铺出来，业务人员鼠标点几下就能生成一张图。站在工程师角度，这已经是了不起的简化——过去要写一整天 SQL 才能出的报表，现在五分钟搞定。但这个定义有一个隐含假设：业务人员知道要拖什么字段、按什么维度切、怎么解读结果。一旦这个假设不成立，"少步骤"就变成了"每一步都不知道该点哪"。

业务人员眼中的"易用"，关键词其实是"少决策"。一个门店店长早上 9 点打开系统，他脑子里跑的是三个问题：昨天哪款新品卖爆了？要补单吗？补多少？这三个问题背后，是一次"找到数据—理解数据—做出判断—执行动作"的完整链路。中间任意一个环节卡住，他就会关掉 BI，回到微信群、Excel、或者直接打电话问运营。所以真正决定"用不用得起来"的，不是首屏有几个图表入口，而是从一个问题到一个可执行结论，中间要走多少步。

由此，我们可以重新定义 BI 的易用性：让业务人员在 3 步以内，从一个业务问题走到一个可执行的结论或动作。 第 1 步，提出问题（可以是一句自然语言，也可以是一个固定场景入口）；第 2 步，系统直接给出结论或建议；第 3 步，结论要么可以直接转化为动作（推送给对应角色、触发补单流程），要么可以一键分享给决策人。这三步里，业务人员不需要理解底层表结构、不需要判断口径是否正确、不需要把图表翻译成业务语言。

对照这个标准回看，市面上大多数 BI 产品的"自助式分析"，其实只解决了第一步到第二步的一半——把"查数据"变简单了，但把"读懂数据"和"行动"留给了用户自己。BI 的价值因此被压扁成了一份"更高级的报表工具"，而没有被还原成业务人员真正想要的东西：一个能替我思考、替我跑腿的数据助手。后续的章节里，我们会把观远数据如何把这条路径拆成可落地的产品能力，一项一项拆开来看。

易用性失灵的三个真实场景

判断一个 BI 产品到底"好不好用"，最有说服力的证据，不是厂商发布的新功能列表，而是把账号交给一线业务人员后，他在第几分钟关掉它。以下几个场景在观远数据的客户回访、用户调研、产品工单里反复出现，构成了我们重做易用性设计的起点。

场景一：区域销售要查"本月跌得最猛的前 10 个 SKU"。 这个人在某个快消品牌的华中大区负责渠道销售，月初对照业绩时只想看一件事——这个月哪几个 SKU 掉得最厉害、是不是要调整铺货策略。他打开 BI，登录后看到的是默认的"销售总览"看板，找不到"SKU 维度下销量环比下滑 Top 10"这个视图。点进筛选器，字段列表里出现的是英文表头（sku_id、sales_amt、mom_rate），他不知道哪个对应"SKU 名称"、哪个对应"环比"。最后他截了一张看板图发到微信群，问"这个图是不是我想看的"。没有人秒回，他回到 Excel 里，十几分钟就拉完了。BI 在这里输给 Excel 的，不是能力，而是入口到结论之间的认知摩擦。

场景二：门店运营想配置"库存低于阈值自动提醒"。 这个人管着 30 多家门店，每天要盯补货节奏。他听说 BI 可以做"数据预警"，于是试着找入口。系统告诉他：要实现"库存低于阈值就推消息"，需要先让数据团队建一个"库存事实表"数据集，再配一个 ETL 任务去算阈值，然后才能在订阅模块里挂规则、设接收人、选推送渠道。他不会写 SQL，也不清楚"数据集"和"ETL"到底有什么区别，于是提了一张工单，3 天后才被告知"排期要等下个月"。需求本身只有一句话，落到产品里却要跨四个模块、跨两个角色，门店运营的"自动提醒"，在 BI 里变成了一项需要立项的工程。

场景三：HR 想临时验证"近 3 个月新员工流失率"。 这个人在做招聘复盘，想看看这批新人的留存情况。打开 BI 找到"人力分析"看板，面对十几个筛选器（部门、入职日期范围、司龄段、是否在岗、岗位序列……），他不知道哪些组合才是对的。把"入职日期"设成最近 90 天、把"是否在岗"勾成"否"，跑出来一个数字，他自己也不确定口径对不对——试用期离职算不算？主动离职和被动离职要分开吗？最后他没有在 BI 里问，转头在企业微信上找了一个熟悉的分析师。问题卡在了"筛选器太多"和"口径不透明"上，业务人员不是不会点筛选，是不确定自己点出来的东西是不是答案。

把这三个场景并排放在一起看，共同的卡点非常清楚：每一个都卡在"需要懂技术"这一关，而不是"需要懂数据"。业务人员愿意理解业务问题、愿意基于数据做判断，但不愿意去弄清楚字段映射、ETL 流程、口径定义这些工程师语言。BI 产品在设计时，默认用户是"半个数据人"，于是把数据准备、模型抽象、口径校准这些专业动作，悄悄前置到了使用门槛里。当一个产品需要用户先变成另一个人才能用起来，那它就不是易用产品，而是专业产品。 这也是观远数据重做易用性时，最先要拆掉的一道隐形墙。

把易用性拆成四个可被产品化的能力

前文我们把"易用"重新定义为"3 步以内从问题到动作"。要撑住这个定义，不能只靠交互层做减法，而要把背后那些原本由用户承担的隐性工作，一项项做成产品里可配置、可验证、可托付的能力。结合前文三个真实场景中暴露的卡点，观远数据把易用性拆成下面四块能力，每一块都对应一个明确的工程化目标。

能力一：ChatBI 自然语言问数，让"一句话提问"成为标准入口。 业务人员输入"本月跌得最猛的前 10 个 SKU"，系统直接返回结构化结果。这背后依赖的不是大模型的"通用理解"，而是指标中心提供的统一口径，以及错题集对历史问法和 SQL 的沉淀——前者保证"销售额"在 BI 里和在官方报表里是同一个数，后者保证"跌得最猛"不会被翻译成"销量最低"。没有这两层底盘，ChatBI 只会把"看不懂字段"升级成"看不懂回答"。

能力二：订阅预警与数据回写，把"看数据"变成"自动通知 + 触发动作"。 库存低于阈值、业绩跌破红线这类需求，业务人员不需要建数据集、配 ETL、排排期，而是通过订阅模块配置触发条件和接收人即可。更进一步，分析结果可以通过数据回写能力直接写回 ERP、营销系统等业务系统，完成"分析—触发—执行"的闭环，而不是停在"知道"。

能力三：指标中心统一口径，解决"同一指标多种算法"的老问题。 业务人员敢用 BI 的前提，是他和官方报表看到的数是一致的。指标中心把口径集中管理、版本可追溯，从源头消除"为什么我和财务对不上"的反复扯皮。

能力四：细粒度权限与行级数据隔离，让业务人员只能看到自己该看的数据。 通过行权限的自由模式配置，可以实现"销售员只看自己的数据""区域经理只看本区数据"等场景。看不到不该看的数据，是业务人员放心使用 BI 的前提，也是数据合规的底线。

观远的产品落点：把四个能力装进同一条业务路径

把入口层和理解层放在同一条路径上，是这四个能力真正落地的前提。观远数据的产品设计中，统一搜索与 ChatBI 入口被放在导航的优先位置，传统 BI 中常见的"多级菜单 + 层层钻取"的入口结构被刻意弱化——业务人员打开系统后，搜索框就是第一动作，问问题比找功能更直接。当入口让出位置，下一步就要解决"问出来的东西靠不靠谱"。

理解层的核心由三件套构成：指标中心负责口径统一，业务知识库负责上下文沉淀，错题集负责把历史踩坑固化为可复用的问答模板。指标中心把"销售额""环比""新员工流失率"这类指标的定义、计算逻辑、适用场景集中管理，避免同一个词在不同看板里算出不同结果；业务知识库把组织代码与数据集的关联方式、常用维度的默认筛选条件等"业务上下文"前置到问答环节，ChatBI 在生成 SQL（结构化查询语言，即数据库与数据表对话所用的指令）时直接引用，不必每次都让用户补全；错题集则把"最近销量""上月环比"这类模糊问法对应的标准答案沉淀下来，下次再被问到时直接命中。

入口层与理解层的衔接逻辑很清晰：入口负责让用户"敢开口"，理解层负责让系统"答得准"。前者解决"我该怎么用这个产品"，后者解决"我得到的结果可不可信"。两者在同一条业务路径上联动——业务人员用自然语言提问，问题先经过业务知识库和错题集的预处理，再到指标中心匹配口径，最后返回结构化结果，全程不需要切换工具或求助数据团队。这条路径的目标，是让"提问"和"可信"之间的距离，压缩到一次对话之内。