173张表→300张表
01 问得更广
更多常用业务问题，都能在一个入口里问。
优先接入库存、销售等已被访问量验证的高价值主题；同时把业务侧的取数类定时任务统一搬上服务端。
下一阶段目标 · 300 张热门表
终端AI作战 · 联勤保障部队 基建兵
基建兵 · iData 数据服务 · 韩鑫江
1 / 7
联勤保障部队 · 基建兵 · iData 数据服务
我是「基建兵」
深耕底层，提供数据服务
《iData 智能问数服务 —— 让每位同事都能用一句话，查到需要的数据》
系列分享 04 · 基建兵视角 | 上一讲：炊事兵 · 刘明帝
汇报人 · 韩鑫江
数字化部
基建兵 · iData 智能问数
2026 年 9 月 · 产品荟
173张表
已同步 · 覆盖销售、库存、工单等主题
11.9亿行
数据规模 · 服务端每日同步副本
3.2万次
累计访问 · 截至 2026-07
107张
自助报表 · 随时可查的资产
01 战场 · 问数不方便
之前的问题很直接：问数不方便
数据不是没有，而是散落在各处、拿数据的路太长。业务同事每天的真实感受是这样的（痛点 4 / 5 的原话来自与销售部同事产品荟前的直接沟通，2026-09）：
痛点 1 · 找数
不知道数在哪——数据散落在邮件、各业务系统、各张表里，想查个数，第一步是先打听「这个数在哪儿」。
痛点 2 · 排队
取数靠排队——提需求 → 找取数的同事 → 排期 → 等待，一个数等半天，追问一次再来一轮。
痛点 3 · 口径
口径对不上——同一个指标各有各的算法，来回确认成本高，最后不敢直接引用。
痛点 4 · 单点依赖
定时任务拴在个人电脑上——每人自己电脑上跑定时任务，出差、关机，任务就断，数据当天就缺。「如果说他出差、他关机，这个任务就跑不了了。这是一个非常死的坎儿。」
痛点 5 · 工具泛滥
小工具越做越多、越来越乱——有了 AI 之后，一线平均每天新增一两个小工具：千人千面工具、答题工具、巡店工具……各部门各做各的，没有统筹。「反正这东西整得非常的乱，但是现在乱的他也跑着也能跑。」
一句话：大家不是没有数据，而是拿数据的路太长、太散、太依赖某一个人的电脑。
02 本事 · iData 智能问数服务
我做的事：把取数变成一项公共数据服务
基建兵的打法——不在业务侧反复救火，而是把底层一次打通：数据同步、身份鉴权、权限控制、智能查询、结果解释，串成一条闭环服务。
01
同事提问
业务语言直接问
用自己的话，直接说出想要什么数，不用知道表名。
人人可用 · 零门槛
02
识别身份
个人 API-Key 鉴权
一人一把 key，先确认「是谁在问」。
凭据 · 按人隔离
03
理解并查询
大模型转查询
把问题转为查询，只查有权访问的数据。
权限 · 结构化控制
04
返回结果
带解释、可追问
结果带口径解释，可以继续追问，随问随取。
口径 · 统一解释
173张表
已同步 · 覆盖销售、库存、物流、采购、财务、华盛通查工单等主题
11.9亿行
数据规模 · 行云数据库常用表 → 服务端每日同步副本
3.2万次
累计访问 · 业务同事真实的问数行为（截至 2026-07）
107张
自助报表 · 高频取数沉淀为随时可查的报表资产
关键点：同步在服务端跑、权限按人控、口径统一——正好对着上一页的每个痛点。
03 战果 · 效果对比
从「排队等数」到「随问随取」
业务同事的取数方式发生了实际变化（统计口径：截至 2026-07-31 的使用通报 / 2026-08-25 治理清单）：
| 维度 | 以前 | → | 现在（iData） |
|---|---|---|---|
| 找数方式 | ✕找表靠打听——先问「数在哪」，再找人、再找表 | → | ✓一句话直接问——用业务语言描述需求即可 |
| 取数时效 | ✕取数靠排期——提需求、等排期，一个数等半天 | → | ✓即时返回、可追问——秒级拿数，口径不对当场换问法 |
| 数据口径 | ✕口径各说各话——同一指标多种算法，确认成本高 | → | ✓统一底座、统一口径——常用数据进入同一份副本 |
| 任务稳定性 | ✕拴在个人电脑——出差、关机，数据当天就缺 | → | ✓服务端每日同步——不依赖任何人的电脑，到点自动跑 |
87.8%
累计访问来自自助报表——高频、重复的取数需求已被消化
116张表
已被实际访问（占 81%），活跃资产持续扩大
131张表
已带中文名、更新频率、敏感字段标记的元数据记录
87.8% 的访问落在自助报表上——高频取数已经资产化，剩下的随问随取。
04 回应 · 与业务同事的沟通
一线痛点，恰好指向同一个方向
产品荟前与销售部同事沟通取数与数据服务的实际问题，三个反馈与 iData 的思路直接对得上：
反馈 1 · 定时任务跑不动
每人自己电脑跑定时任务，出差关机就断，这是「非常死的坎儿」。
iData 的回应
定时任务搬到服务端
iData 的每日数据同步本身就是服务端定时任务——不依赖任何人的电脑。下一步可把业务侧的取数类定时任务统一搬上来，在线跑、稳定跑。
任务不再拴在任何人的电脑上
反馈 2 · 小工具泛滥
一线平均每天新增一两个小工具，各部门各做各的，没人统筹。
iData 的回应
工具可以各做，数据应该共用
上层工具百花齐放没问题，底层供数由 iData 统一——每个小工具不用再各自找表、各自取数，数据口径也自然对齐。
工具百花齐放，数据一套底座
反馈 3 · 数据散落邮件
收入类数据很多在邮件里流转，散落难汇总，上不了工具。
iData 的回应
散落数据接进统一底座
这正是统一数据库要解决的问题：把邮件、各系统里的常用数据接进同一份底座，变成随问随取的服务。
邮件里的数，接进底座随问随取
沟通后的共识：上层工具百花齐放，底层由 iData 统一供数——基建兵的价值就在这一层。
05 下一步 · 只抓三件事
问得更广、看得更懂、一套数据大家共用
方向不变——继续深耕底层，让数据服务覆盖更多业务、更清楚、更可复用。
把每个字段解释清楚
02 结果更清楚
每个数是什么意思、怎么算、什么时候更新，一看就懂。
完善数据字典与字段级解释，让问出来的数敢直接引用，不用再回头确认口径。
字段级解释 · 数据字典
建设统一数据库
03 一套数据，多处使用
散落的数据接进底座，其他部门也能复用。
把邮件等渠道散落的常用数据接进统一底座，公司统一治理，各部门的小工具共用同一套数据服务。
统一数据库 · 统一治理
基建兵的定位：把底层建扎实，业务同事只管往前冲。
深耕底层，提供数据服务——
把底层建扎实，业务同事只管往前冲。
把底层建扎实，业务同事只管往前冲。
上层工具百花齐放，底层由 iData 统一供数。
数据基建一次打通，人人一句话，查到需要的数据。
数据基建一次打通，人人一句话，查到需要的数据。
📡 系列分享：这一讲是「基建兵」视角；上一讲 刘明帝「炊事兵」、石书宇「通信兵」、孙鹏「炮兵」——同一套打法，不同兵种。
终端AI作战 · 联勤保障部队 基建兵 · 韩鑫江 · 2026.09
← → 翻页 · 空格下一页