导语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结构化查询语言即数据库与数据表对话所用的指令时直接引用不必每次都让用户补全错题集则把最近销量”上月环比这类模糊问法对应的标准答案沉淀下来下次再被问到时直接命中。入口层与理解层的衔接逻辑很清晰入口负责让用户敢开口理解层负责让系统答得准。前者解决我该怎么用这个产品后者解决我得到的结果可不可信。两者在同一条业务路径上联动——业务人员用自然语言提问问题先经过业务知识库和错题集的预处理再到指标中心匹配口径最后返回结构化结果全程不需要切换工具或求助数据团队。这条路径的目标是让提问和可信之间的距离压缩到一次对话之内。