导语

每年 BI 厂商收到的选型 RFP（需求建议书，即企业向供应商发出的"需求清单"）里，排在最前面的几乎都是"功能清单对照"：能不能做看板、能不能做看板、能不能做权限分级、能不能接数据仓库。这张表对比得再细，真正上线后被吐槽最多的，往往不是清单上没勾的项，而是"问个数要等两天"“换个口径全公司对不齐”“业务一上新业务线，模型又得重新跑一遍”——这些不在功能表里、却在使用现场每天发生的事。

方案探索期最常见的错觉，是把"选型"等同于"比功能"。

替换或升级 BI 的真实考题只有一个：这套系统能不能撑起未来 3 年的业务问数与决策节奏。功能清单只是入场券，撑不撑得起业务节奏才是淘汰赛。选型团队真正要做的，是带着业务方一起把"未来 3 年会怎么变"翻译成几个可验证的问题，再用这些问题去压厂商、去试 Demo、去压测真实数据。

这份清单的设计原则很简单：每个问题配 1 个反直觉判断，再配 1 个可验证动作。反直觉判断帮你跳出厂商话术，可验证动作让你带着结果离开每一场交流。它不是给"已经决定换、只差选哪家"的团队准备的——那种情况直接走 POC（Proof of Concept，即概念验证测试，用真实数据小范围验证产品能力）就行。

它面向的是正处在方案探索期的团队：年营收 10 亿以上、数据团队 5 人以上、已有 BI 在用但开始吃力、正在认真评估"要不要换、换哪家、怎么换"的企业。如果你还在用 Excel 拼数据，这张清单用不上；如果你已经做完 POC 只等签合同，这张清单也用不上。它最适合的，是那种"再不上就要出问题，但还没想清楚换什么"的状态。

下面 7 个问题，按"先验证底线，再验证上限"的顺序排列。建议每场厂商交流前，挑其中 2-3 个作为必答题，用真实数据当堂跑、当堂看。

问题一：现有 BI 的"卡点"到底是功能缺失，还是数据底座没打通

把"卡点"拆对，是选型决策的第一道分水岭。

先做一次"卡点归因"：拉出近 3 个月业务侧最常投诉的 5 个场景，逐条标注它是"表象卡点"还是"根因卡点"。表象卡点通常很具体——报表打开慢、看板加载要十几秒、某个筛选条件选不了；根因卡点藏在更深的地方：数仓分层缺失导致每张报表都现拉原始表、指标口径散落在十几个人的 Excel 里、权限粒度只到部门级所以财务和 HR 数据混在一起。功能补不齐的，往往是表象；工具换再多也救不了的，往往是根因。

一个反直觉的判断需要先讲出来：根据多年 BI 落地经验的体感观察，超过六成的"BI 不好用"投诉，根因都不在 BI 工具本身，而在上游的数据底座——要么是数仓分层没做好导致查询链路冗长，要么是指标口径没统一导致"同一个销售额在财务和运营那里数字不一样"，要么是权限粒度太粗导致业务部门不敢把数据真正放上台面。换句话说，很多人盯着 BI 的报表功能做选型，却忽略了"如果数据底座不重做，换一套 BI 工具只是把问题搬了个地方"。

可验证动作很简单，但也最容易被跳过：把那 5 个投诉场景拆成"功能缺失"和"数据底座"两类。如果超过一半都落在后者，这轮选型的重心就不是比功能，而是先推动数据团队把数仓分层、口径统一、权限粒度这三件事往前推一步。厂商可以帮你解决前者，后者的责任在你自己的数据团队身上，工具替代不了组织动作。

这也是为什么这份清单的 7 个问题按"先验证底线，再验证上限"排序——第一个问题问的正是底线：如果卡点不在 BI 本身，把 BI 换掉解决不了问题。想清楚这一层，再去和厂商谈"你能提供什么"才有意义。

问题二：替换的目标是"让业务自助"，还是"让分析师提效"

同样一句"我要换 BI"，两家企业的目标可能完全相反。一家想的是"业务自己就能查到数，别再排队等分析师出报表"；另一家想的是"分析师出报表快一点、深一点，别再花 80% 的时间在清洗和拉数上"。这两类诉求对应的产品形态，差异大到没法用同一张功能清单去比较。

先讲一个反直觉的判断：很多企业把这两件事混在一起说——“我既要让业务自助，又要让分析师提效”。听起来很合理，但落地时往往两头都做不好。原因在于这两种目标的产品设计哲学是相反的：前者强调"降低使用门槛，让不会 SQL 的人也能问出数据"，产品重心在自然语言交互、推荐问题、知识库兜底；后者强调"把分析师从重复劳动里解放出来，让他们做更深的归因和建模"，产品重心在增强分析（Augmented Analytics，即用机器学习自动做异常检测、根因下钻、趋势预测等分析动作）、自助建模、复杂计算引擎。同时追求两个方向，不是"加配置"能解决的，而是会让后台的数据集结构、知识库内容、权限粒度全部变得臃肿，最终哪边都跑不顺。

观远在 ChatBI（对话式 BI，即让用户用自然语言直接向数据提问并获得图表回答的产品形态）落地中观察到一个可复用的节奏：主题（一个业务域的数据问答容器，内部包含数据集与知识库配置）的搭建建议从单表起步。也就是说，第一周只接一张核心表，把"问-答"的准确率打磨到 80% 以上（文档中的可验证门槛），再逐步扩到第二张、第三张表。原因是多表关联会迅速放大歧义——同名字段、相似指标、时间口径差异都会让问答准确率断崖式下跌，而此时再回头补知识库，补的不是规则而是逻辑黑洞。很多团队的 ChatBI 推进到第三个月就"用不起来"，根因往往不是模型不够聪明，而是起步阶段铺得太开。

可验证动作分两步。第一步，回到企业内部做一次"目标对齐"：让业务负责人和数据负责人各写一句话回答"这次替换 BI，首要让谁省时间"。如果两句话指向同一个人群，恭喜你，目标清晰，可以进入下一步；如果指向不同人群，先别急着选型，先把主次排出来——是"业务自助优先"还是"分析师提效优先"，还是按业务线分阶段走。第二步，带着明确的主目标去和厂商谈：偏业务自助，重点看 ChatBI 的问答准确率、推荐问题质量、知识库维护成本；偏分析师提效，重点看增强分析能力、ETL（Extract-Transform-Load，即数据抽取、转换、加载流程）效率、复杂计算性能。先定目标，再选型，顺序反了，后面所有评估都会失焦。

问题三：AI 能力是"锦上添花"还是"核心入口"

聊到第三题，话题开始变得"性感"起来——AI 问答、ChatBI、智能分析，每家厂商都会在这块堆功能，但越热闹的地方，越要冷静。

先把两个常见误解拆开。第一种误解是"准确率 80% 就够用"。不少厂商的 Demo 现场表现亮眼——业务人员随口问一句，系统秒回图表，准确率高得惊人。但要追问的是：这个 80% 是在什么数据条件下测出来的？是单表还是多表？字段注释是否完整？口径是否已经统一？如果答案都是"在干净的数据集上"，那这 80% 几乎不说明问题。Demo 表现不等于生产表现，这句话在 BI 选型里被反复验证过。第二种误解是"AI 能力可以后期再补"。逻辑上没错，行动上很难——AI 问答对底层数据治理的依赖度极高，数据集描述、字段注释、业务知识库（把业务口径、行业术语、特殊计算逻辑提前教给模型的知识合集）、错题集（把模型答错的典型问题与正确 SQL 沉淀下来、供模型后续避开的纠错知识）一旦缺位，模型再聪明也只能"猜"，而业务侧最不能接受的就是"猜出来一个错误数字"。

那怎么科学评估 AI 能力？观远的建议是从三个维度同时看。第一是自然语言问数的准确率，但这个准确率要按主题拆开统计，而不是看一个平台平均值。第二是知识库的召回率，即你配置的业务知识（口径说明、关联关系、表选择优先级）有没有真的被模型调用——观远 ChatBI 的运营后台提供了"召回次数透出"和"召回知识"查看能力，正是为了回答"我配的知识模型到底用没用"这个问题。第三是上下文理解轮数，也就是多轮对话能力——用户问完"上月销售额"接着问"那华东区呢"，系统能不能接住，而不需要用户重新描述背景。

最后给一句边界提醒：AI 问答准确率高度依赖数据治理成熟度。观远在落地实践中发现一个反复出现的规律——ChatBI 主题搭建建议从单表起步，单表问答准确率打磨到 80% 以上（文档可验证的起步门槛）后再扩多表，原因就是多表关联会迅速放大歧义。如果企业当前数据底座尚未分层、指标口径尚未统一，AI 能力再强也兜不住底层的混乱。这一题的结论是：AI 能力值得重点评估，但评估的对象不是 Demo，而是"你的数据能支撑 AI 跑到什么程度"。

问题四：数据治理与权限体系能否支撑"全员问数"

一旦目标定在"业务自助"，紧接着就要回答一个更底层的问题：你的数据底座，撑不撑得住全员问数。很多企业把 ChatBI 想得很简单——“接上数据库，模型就能回答”。但真正跑起来就会发现，第一个崩的不是模型，而是权限和口径。

“全员问数"意味着同一套数据要服务几百甚至上千人，每个人的部门、职级、所属业务线都不一样，对应的数据可见范围也不一样。这里面至少要前置确认四项能力。第一是行列级权限——能不能精确到"华北区的销售只能看华北，华东区经理能看全国华东”。第二是用户属性自动带入查询，也就是用户的部门、职位等标签能不能在提问时自动被模型识别，免去每次手动加筛选条件。第三是数据集描述与字段注释的完整度，这是 ChatBI 能"听懂业务问题"的前提，没有注释的字段，模型只能靠猜。第四是指标口径统一，同一个"销售额"在财务、运营、销售三个部门不能各算各的。

观远在这一层的解法是指标中心——统一管理业务指标定义与计算逻辑的平台模块，让一个指标"一次定义、多处消费"。从 ChatBI、报表、到 API 调用，调用的是同一套口径，避免"同一指标 N 个数"的混乱。结合 ChatBI 的"问答流程用户属性感知"能力，用户在提问时，其部门、职位等属性会自动传入模型，模型据此生成带权限的 SQL，从机制上降低越权访问和误读数据的风险。

需要提前打一个预防针：数据治理准备通常占整体项目周期的 30%-40%。这意味着如果企业当前没有专职的数据治理团队，或者指标口径长期分散在各个业务线，那么 ChatBI 的推进节奏不能按"两周上线"来预期，而应预留至少 1-2 个月做底层梳理。先把权限模型、指标定义、字段注释这三件事理清，再让 ChatBI 接进来——这个顺序反了，后面所有 Demo 效果都会在生产环境里打回原形。

问题五：替换路径是"一次性切换"还是"灰度并行"

这个问题在方案探索期往往被低估，但实际上直接决定了上线前三个月是平稳过渡还是鸡飞狗跳。

观远在大量客户落地中形成的共识是：新旧 BI 并行 1-3 个月，按业务线或部门做灰度切换，而不是一刀切切换。理由很现实——老 BI 里沉淀的不只是报表，还有大量历史看板、邮件订阅、外部嵌入链接和用户使用习惯，"切"这个字说起来轻巧，做起来每一次跳转都可能引发业务侧的不安全感。灰度并行意味着新 BI 先在一个低风险部门（比如HR、行政）或一个独立业务线跑通，同步保持旧 BI 可用，给业务方留出"我能退回去"的安全垫。

数据迁移环节需要特别关注抽取数据集的"前置清理规则"——这是观远在数据更新场景里为应对"修数后如何保持 BI 抽取数据与数仓一致"问题而设计的机制。具体来说：当数仓中的事实表被修正或清洗后，BI 平台如果只做增量更新，本地缓存里仍然存有旧数据，导致两边对不齐。前置清理规则允许管理员在每次增量抽取前，按指定条件（比如"删除最近7天的数据"）先清理本地数据，再重新抽取，从而保证一致性。在迁移场景下，这套机制的延伸用法是：为不同业务线配置不同的清理范围和抽取频率——核心业务线保留更长历史窗口并每日抽取，边缘业务线则可缩短到近一年历史、按周抽取，用差异化的数据策略匹配差异化的灰度节奏。

最后一个实操建议：灰度期间一定要设明确的"退出条件"，而不是无限期并行。比如约定"新 BI 在某业务线连续4周活跃度达到目标值、旧 BI 该业务线活跃度降至 20% 以下"作为切换条件。有了硬指标，灰度才能收敛，否则并行期很容易拖成长期双系统维护，成本反而不降反升。