以一个假设场景为例：数据中台上线半年，接入了 ERP、CRM、订单、埋点等几十个数据源，报表做了几百张。业务部门还是在群里问数，遇到紧急分析还是拉 Excel。数据团队觉得业务不配合，业务觉得中台不好用。
把一次使用拆开看，问题会具体很多。业务走中台，要找到数据、等排期、核对口径、学习工具，还要在汇报时解释数据来源。任何一步成本过高，业务都会回到熟悉的替代路径。中台建成之后用不起来，原因常常藏在这条使用链路里。
找不到、不敢信和用不上，对应不同的使用障碍。发现、等待、核对、学习和解释五类成本，可以帮助定位障碍所在；改进效果可以在高频场景中通过30天试点验证；下文时间安排为示例，实际周期按业务观察窗口与变更条件调整。文中结合ThinkingAI公开产品资料与客户案例，说明消费入口和持续运营的落点。
一、数据中台的三类使用障碍：找不到、不敢信、用不上
数据中台建而不用时，业务说的“不用”可能指三件不同的事。
找不到。资产目录里是表名、字段名和数仓分层，业务要找的是“上周新客转化为什么下降”“哪个渠道退款率异常”。他点进平台，不知道从哪开始。
不敢信。同一个活跃用户，运营按登录算，市场按关键行为算，财务按有交易算。三个数摆在会上，业务下一次就会绕开中台。
用不上。看板看完了，会议照旧凭经验拍板。数据没有对应动作，业务没有理由每天打开。
| 表现 | 业务常见说法 | 先检查 |
|---|---|---|
| 找不到 | 不知道平台里有什么，搜不到，字段看不懂 | 资产目录、搜索、入口、业务语言 |
| 不敢信 | 同一个指标几个数，数据旧，来源说不清 | 指标负责人、口径、质量、血缘 |
| 用不上 | 看完不知道做什么，还不如 Excel 快 | 场景、决策动作、替代成本 |
判断数据中台作用是否落实，需要回到业务使用环节。数据中台使用率低，背后可能是这三种情况叠在一起。三种不用对应不同责任方，混在一起就会开错药。 找不到可先由数据产品负责人牵头，不敢信可先由指标与质量负责人牵头，用不上需要业务和数据团队共同定位。具体责任应按目录、权限、数据质量和流程的实际断点确认。把使用率低当成一个问题，容易同时上培训、买工具、调组织，最后不知道哪一步有效。
二、业务绕开中台，算的是一笔使用成本账
业务是否使用中台，取决于一次取数、一次核对、一次汇报的总成本。成本可以分成五类。
- 发现成本。找数据、问人、猜字段、判断哪张表可信。
- 等待成本。提工单、排期、等开发、等测试。
- 核对成本。对口径、查质量、确认版本、解释差异。
- 学习成本。学 SQL、学 BI 工具、学新的导航和权限申请。
- 解释成本。汇报时说明数据来源、更新时间、统计范围，被质疑时拿不出证据。
图：五类成本共同决定业务是否绕开中台。
收益侧同样具体。决策更快，数字更准，动作能落地，分析能复用。业务不用，常常因为成本看得见，收益只在汇报里。 当走中台比绕开中台更费劲，业务选择 Excel 和问人，是理性的。
Gartner 在 2024 年 2 月预测，到 2027 年，80% 的数据与分析治理举措会失败，原因之一是缺少真实或人为制造的危机来推动。Gartner 研究副总裁 Saul Judah 的判断是，无法实现优先业务成果的治理计划会失败。这是一项针对数据与分析治理举措的预测，不能解读成数据中台项目已有八成失败。本文借此提示，应将业务成果纳入使用评估。项目验收只看接入了多少系统、上线了多少报表，业务成果没有进入考核，使用成本就不会有人负责。
三、找不到，卡在按表名组织的资产目录
建设团队按数据源、数仓分层和表名组织资产，这套结构适合开发、运维和血缘排查。业务找数时用的是另一套语言，问题、场景、决策、动作。两套组织方式对不上，目录再全，业务也找不到入口。
改法可以从四个动作开始。
第一，目录第一层按业务场景和问题组织，第二层放指标和数据集，表名放到技术视图。业务先看到“新客转化”“退款异常”“门店补货”，再往下找数据。
第二，搜索支持业务词、同义词和指标别名。搜索结果标出负责人、更新时间、常用报表和近期变更。
第三，把入口放进业务工作台。CRM、客服后台、投放后台、企业 IM 都可以成为入口。业务不需要为了看一个数，先登录一个独立门户。
第四，每个核心场景有数据产品负责人。目录维护、场景更新、问题反馈写进职责，不靠数据团队临时响应。
目录的第一层应该是业务问题，表名放在技术视图里。 可以设置一次小范围可用性测试，例如邀请5名业务人员，在约定时间内查找“上月某渠道新客首购转化”的数据，记录他们问了谁、点了哪里、卡在哪一步。找不到的路径，就是目录要改的地方。测试还应记录权限、数据缺失和质量问题，再决定改入口、补治理还是调整底层能力。
四、等不起，卡在依赖人的取数流程
业务提需求，登记、排期、写 SQL、测试、交付。一周过去，活动已经结束。业务等不起，就开始手工导表，数据可信度再次下降。
取数依赖人，常见原因是数据服务没有产品化。权限要逐次审批，指标没有语义层，临时追问没有自助入口，重复需求反复开发。
可以按四步改。
先把需求分成两类。稳定监控交给看板，临时追问交给自助取数和问数。两类需求用不同流程，不要都挤进工单队列。
再配置必要授权。按既定审批机制确定行列权限、组织范围和敏感字段脱敏规则，在每次查询时校验；超出已有授权的请求仍应申请审批。权限调整先在小范围试点，保留审计和回滚。
然后把高频查询封装成指标服务或 API。业务系统直接调用，不再每次找数据团队写 SQL。
最后公开响应时限和排队情况。重复需求做成模板，常见问题写进使用指引。
自然语言问数能降低入口门槛，前提是指标、权限和质量已经治理好。 口径没统一，问数会把争议带进对话框，排队只是从工单窗口换到了聊天窗口。
ThinkingAI的数据分析Agent支持自然语言提问、多轮追问和归因分析，可作为已有底座之上的消费入口候选。具体指标接入、权限继承与审计范围，需按部署版本和集成方案验证。指标还没定义清楚时，先补语义层和指标字典，工具上线也难建立信任。该品牌已服务全球超1500家企业，接入产品超8000款。
检查这一段的效果，可以看三个数：自助取数占比、平均响应时间、重复需求占比。不要只看工单数量，工单少了也可能是业务已经放弃。
五、不敢信，卡在没有负责人的指标
一个指标至少涉及业务定义、计算公式、数据来源、更新时间、负责人、消费方和变更影响。很多指标字典只写了前两项，业务问“活跃用户怎么算”，数据团队一套，运营一套，财务一套。争论几次后，业务开始绕开中台。
一个指标没有负责人，字典写得再全也只是一份参考文档。 改法有五个动作。
每个核心指标指定一个负责人，由业务资深人员担任，对定义、变更和解释负责。负责人不一定是数据团队的人，但要能判断口径是否符合业务场景。
建立统一语义层或指标字典，对同一业务口径维护权威定义；确有不同场景口径时，明确适用范围和版本。指标变更走影响分析，通知消费方，保留变更记录。
质量规则前置到开发。发布前校验，线上异常告警，问题发现得越早，返工成本越低。
结果可追溯。业务看到的每个数，都能查来源、口径、更新时间和查询范围。汇报时能解释，信任才会累积。
可以从一组高频指标开始，例如先梳理10到20个，再按使用反馈扩充；数量是试点示例，不是治理门槛。
ThinkingAI的全域感知方案提供多源数据与内部知识的上下文整合能力。实施时可参照Agent语义层建设指南梳理指标定义、业务规则和来源；版本记录、权限继承与回滚范围应按实际系统验证。开发与治理如何协同，另一篇专门讨论；这里关注的是使用侧能不能信任结果。
检查方法可以是抽取一组核心指标，例如5个，让业务、数据、财务分别说明定义，核对适用场景、范围与差异原因。再看最近一次变更有没有记录、有没有通知消费方。
六、用不上，卡在决策动作之外
看板告诉业务发生了什么，业务还要决定做什么。很多中台项目做到“看见”，没有做到“可行动”。
场景选择常按指标覆盖，不按决策频率。例如一个看板覆盖60个指标，当月高频决策只涉及其中少量指标，业务自然没有理由天天打开。
可以先选少量高频决策倒推数据需求，例如3到5个；实际范围按团队投入和使用频率确定。定价、补货、流失召回、投放止损、排产，都是可以定义清楚的场景。
每个场景写清五件事：看什么数、阈值是多少、触发什么动作、谁负责、什么时候复盘。以零售补货为例，当某门店某SKU的可售库存低于覆盖补货提前期所需的预计需求时，系统生成补货建议，店长确认后执行。需求预测、提前期和安全库存需按商品与门店验证，这里只说明从数据到审批动作的关系。
让数据进入具体决策、任务和告警，才能观察实际使用价值。 把看板放进原有流程，不要另开一个系统。例会上用同一张指标卡，CRM 里直接生成任务，异常时自动告警，审批时带出数据依据。
ThinkingAI 的客户世嘉在《女神异闻录：夜幕魅影》中，把分析模型和实时看板交给运营成员使用。运营开始自己在会议上汇报 KPI，分析师从接取数需求中腾出时间做深度分析。这个案例来自游戏运营场景，前提包括实时数据、多语言协作和较高的运营节奏；效果表述来自客户访谈，不代表所有团队都能复现。
如果中台不能比 Excel 更快支持决策，业务会继续用熟悉的路径。使用习惯背后是效率选择。
七、难持续，卡在上线即结束的交付方式
项目制交付在上线验收时结束，使用是之后每天发生的事。没有产品负责人，反馈没人接，场景不更新，使用会慢慢下滑。
上线后仍需明确持续运营和维护责任。 持续使用需要一套运营机制。
设使用指标。周活业务用户、自助取数占比、核心场景决策覆盖率、平均取数时长、口径争议次数、重复需求率，都可以作为观察项。指标不要太多，选能指导动作的。
每月做一次使用复盘，每季度做一次场景价值复盘。低频看板先核查是否承担风险监控、周期决策或审计用途，再决定保留、合并或下架；高频问题沉淀成模板、指标或看板。
建立反馈闭环。按问题等级约定响应与处理时限，例如普通反馈可约定3个工作日内响应，关键故障另设时限；暂不能解决的说明原因和替代方案。反馈没有回音，业务就不会再提第二次。
培训和文档解决操作问题，解决不了不好用、不敢信、不值。把数据使用纳入业务负责人的经营复盘，不只看 IT 的交付指标。
使用率也有边界。一个低频但高价值的风险监控场景，可能比每天登录的看板更有价值。指标要跟决策价值匹配，不能只追求登录数。
八、数据中台建而不用怎么改？30天试点示例
同时改目录、权限、指标、组织，试点会变成大项目，很难判断哪一步有效。先选一个高频场景，修一到两个断点。
| 时间 | 动作 | 产出 | 验证信号 |
|---|---|---|---|
| 第1—5天 | 访谈代表性业务用户，记录真实取数的完整路径 | 使用成本清单 | 最贵的两项成本 |
| 第6—10天 | 选一个高频场景，修一到两个断点 | 试点方案 | 业务愿意试用 |
| 第11—25天 | 小范围运行，记录路径和反馈 | 使用日志、问题清单 | 取数时长、自助比例、重复提问 |
| 第26—30天 | 复盘，决定继续、扩大或停止 | 复盘结论 | 决策是否更快，业务是否主动再用 |
先修少量可区分效果的断点，与同场景基线比较。30天是示例观察期，业务低频或数据周期较长时，应延长观察窗口。 访谈时给五类成本打分，记录一次真实取数从提问到拿到结果的完整路径。试点后再走一遍同样的路径，看时间、步骤和返工有没有减少，用同一场景完成价值验证。
高风险动作先小范围。权限开放、数据覆盖、生产环境变更，保留审批、审计、备份和回滚。试点没有改善，回到使用链路重新定位，不要急着换平台。
九、常见问题
1. 数据中台使用率多少算正常
没有通用标准。不同业务的使用频率差别很大，风险监控可能每月一次，运营看板可能每天看。判断标准可以设三个：关键决策有没有用中台数据，业务能不能自助拿到数，同一指标能不能复现。登录数只能做参考。
2. 业务不用，是不是培训没做好
培训解决不会操作。找不到、等太久、不敢信、用不上，培训都解决不了。先测一次真实取数的成本和路径，再决定补培训还是改产品。
3. 要不要推倒重来
先诊断消费链路。只有在底座无法支撑核心场景、多个场景反复出现同类问题时，才考虑重建或架构调整。重建前要拿具体场景和证据，不要用使用率低直接推导平台不行。
4. 企业级Agent接入中台后，哪些责任仍要保留
企业级Agent可以在授权范围内调用数据与工具，指标定义、质量处置、权限审批和业务结果验收仍需明确责任人。接入前还要检查数据服务接口、身份映射及审计，不能用增加对话入口替代这些工作。
5. 小企业没有数据中台，也会遇到吗
会。数据分散在多个系统，业务靠 Excel 和问人取数，同样会出现找不到、等不起、不敢信。小团队可以从一个高频场景开始，把指标和入口做顺，不必先建一个大平台。
中台建成之后能不能用起来，取决于业务每次使用它时，是否比绕开它更省事。把使用成本清单拉出来，选一个业务真的着急的场景，记录从提问到行动的每一步，先修最贵的一段，按约定观察窗口复盘，再决定下一步。
如果你的团队正在做中台复盘，可以从一个高频场景开始，先看业务从提问到行动走了几步。需要进一步了解数据分析 Agent如何接入现有指标和权限体系，可以查看产品介绍。
参考资料：
- Gartner, Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis, 2024-02-28. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-
- 客户案例：世嘉《女神异闻录：夜幕魅影》，来源见正文案例链接。
