买回来半年另一头的抱怨照旧——IT 那边想的是数据中台业务那边想的是 BI 报表预算只够买一个最后谁声音大买谁的。问题通常不在谁对在于这两类东西本来就不是同一个环节的活。这篇为谁写中小企业里兼管数据的 IT、刚接手数据这块的分析负责人或者被老板一句我们是不是该上中台问到的那个人。先交代立场我来自一家数据平台产品方下面五节不依赖任何产品成立产品在哪一层写在第六节。拆法就一句话买一个数据工具这句话压着五件完全不同的事——业务自己拖一张表出来、同一个指标全公司一个数、把 ERP 和 CRM 的数凑到一起、周报月报自动出、谁能看哪些数据。这五件里有两件是 BI 的主场有两件是建模层的主场还有一件两边都得碰。混在一起来选就会出现买了 BI 发现口径还是各说各的“买了中台发现业务还是不会用”。后面按这五件逐件给三样东西怎么确认你遇到的是不是这一类、第一天具体做什么、做完留下什么能拿去验收的凭证。时效与数据口径声明本文写于2026 年 10 月。五件事的划分、判据与动作属于本文的选型方法整理涉及的公开产品文档与行业公开资料来自公开来源采集时间 2026 年 9—10 月。本文不含实验室压测数据也不构成任何交付结果承诺。具体产品在你这套环境里能做到什么程度一律以现场验证结果为准各家产品的功能边界持续变化请自行核对当时的官方文本。一、为什么选哪个这个问法本身就容易选错先把这句话拆开。下面这张表是本篇最该被记住的一张——开会时大家嘴里说的上工具指向的往往不是同一行而每一行的负责人、验收物、成本量级都不同。你真正想要的这件事说出口时通常被说成通常由哪一环负责只靠 BI 会卡在哪业务自己拖一张表出来“让业务自己取数别老找 IT”自助分析 / BI 层自助取数本就是 BI 的主场基本不卡同一个指标全公司一个数“这个月回款到底是多少”指标口径与建模层每张报表各配一遍口径越做越多套ERP、CRM、Excel 凑到一起“数据能不能打通”数据集成与建模层关联键与换算要在报表里手搓改一处动一片周报月报自动出“别让我每周手工做一遍”报表调度 / BI 层不太卡但数据源不稳时会持续返工谁能看哪些数据、看了留痕“这个数不能让所有人都看到”权限治理层在报表层补权限等于每张报表各配一遍看这张表的正确方式是第 1、4 行是 BI 的主场第 2、3 行是建模层的主场第 5 行两边都要碰但落点不同。所以上中台还是上 BI这个问题正确答案是——先看你这次要解决的到底是哪一行。两个最常见的误判值得单独说。误判一把看板好不好看当选型标准。演示环节最容易赢的永远是画面最漂亮的那家。但画面漂不漂亮跟第 2、3 行口径、跨系统一点关系都没有。买了画面最好的那个几个月后真正让你返工的还是口径对不上。误判二以为买了 BI数据就自动准备好了。这一条常常由一键部署这四个字引起。一键部署说的是安装方式不是数据准备它省掉的是装环境、配依赖、初始化这些事不会自动告诉你回款这个指标算不算税、以哪个系统的时间为准。这里必须加一句限定否则会误导BI 自带的轻量建模或语义层管的是这一个数据集、这一张报表层面的定义它是否成为全公司唯一一份、定义变更时下游引用是否自动跟随、跨系统合并之后的口径是否稳定这三件事都要另外确认。少数 BI 产品已经提供共享语义层或指标中心能否覆盖你的跨系统口径需要现场确认——一键部署这四个字不承诺其中任何一条。二、先做一次分工盘点这 6 项你问得出来吗选型的第一步不是看产品是把下面 6 项问完。问得出来的填进表问不出来的格子本身就是这次选型的结论。说明这一列里的哪一边只有两种——BI 消费层或建模层。盘点项要问到的颗粒度答案指向哪一边数据现在在几套系统里系统名称、数据库类型、能不能直连、是否还在写入只有一套且能直连 → BI 通常够用多套且要合并 → 先看建模层核心指标有几个、谁在算指标名称、业务定义、当前由谁在哪算同一个指标多处在算 → 口径层是瓶颈业务要的是自己改还是看固定表需求是自助探索还是每周固定的几张报表自助探索 → BI固定报表 → 两者皆可取决于数据源报表返工的频率与原因一周返工几次是数不对还是格式不对数不对 → 口径 / 建模格式不对 → BI有没有行列级权限要求谁能看哪些行、哪些列、要不要留痕有 → 权限落点必须在数据源或平台层不能只做在报表上有没有对外报送或审计口径报送对象、报送口径、谁复核有 → 口径必须可追溯不能只靠报表层解释这 6 行的产出不是一份报告是一张填不满的表。填不满的格子就是这次立项真正的理由。有个判断经验如果第 1、3 行的答案都指向单一系统 固定报表那么这次大概率买 BI 就够了不需要把它升级成一场中台项目只要第 1、2 行里出现要跨系统合并或多处在算建模层就是绕不过去的那一环——这时候先买 BI等于把口径问题推到下一个预算周期经验观察同时多出一批要按新口径重做的报表。三、5 件事分别归谁管逐件给判据和第一动作下面按从便宜到贵的顺序说。事情 1业务想自己拖一张表出来归谁管归 BI。典型症状是业务要一个数先来找 ITIT 排期三天等出来时这个数已经不需要了。怎么确认它是这一类看业务的需求是不是探索性的——今天看区域明天看品类后天按客户分层维度一直在换。探索型需求的特征是说不清下一次要什么这类需求交给固定报表做不出来。第一动作不要一上来就开放全部表。先挑 1—2 个业务最常问的主题通常是销售和回款整理成一张宽表让业务在这张表上自己拖。宽表的字段命名要用业务听得懂的词不要用表里的英文字段名。这一步的完整落地做法本系列另一篇专门讲业务人员不会写 SQL 时怎么把自助取数跑起来此处不重复。能留下来的凭证一张主题宽表的字段说明加上本周业务找 IT 取数的次数作为基线——一个月后再数一次看有没有下降。没有基线后面说不清这件事做成了没有。事情 2同一个指标要全公司一个数归谁管归建模层。典型症状是月末对账销售说的本月回款和财务说的差一截两边各拿一张报表谁也说服不了谁。怎么确认让两个部门分别写出这个指标的口径——统计什么、排除什么、以哪个时间为准、含不含税。两份描述只要有任何一项不同那就是口径问题不是数据错误也不是报表工具选错了。第一动作把口径写成一页纸。这页纸要有四件事——指标名称、业务定义、计算逻辑的文字描述、以哪个系统的哪个时间字段为准。写完让两个部门各确认一次。这一步不需要任何工具需要的是一次会。为什么它通常不是 BI 那一环BI 的强项是消费侧它能让一个指标在一张报表里显示得很清楚但判定这个指标在全公司只有一份定义不是它的职责——定义若分散在各个报表文件里改一处就要改一片。这里同样要加限定少数 BI 已提供共享语义层或指标中心那是把一份定义产品化的实现路径之一能否覆盖跨系统口径需现场确认。还要想清楚这份口径最后落在哪儿——三种落地的稳定性差很多落地形态下游怎么用稳定性落成物理宽表或视图下游直接引用这张表改一次动一处最稳注册在语义层或指标平台BI 通过统一入口取数改一次自动跟随取决于平台是否支持只落成文档靠人记着改最差退化的信号是谁改谁知道判断建模层有没有用就看它选的是第几种。事情 3ERP、CRM、Excel 要凑到一起归谁管归集成与建模层。典型症状是做一次跨系统对账先从 ERP 导一次再从 CRM 导一次最后拿 Excel 手工认一遍客户编码。怎么确认挑一批真实记录20 条左右即可够覆盖常见异常就行在两个系统里逐条比对编码与名称。只要不一致就说明主数据没有被任何一方真正维护这时候讨论用哪个工具做看板意义不大。第一动作先定以谁为准。这一条在中小企业里往往不是 IT 能拍板的——ERP 是财务的地盘CRM 是销售的地盘先把它写成一个需要老板拍板的事项。在拍板之前不要空等退一步做最小可行版本把本周对账实际用到的那部分编码映射出来不追求全量放进一张可查询、可编辑的对照表里指定一个人维护并记录每次修改。能定权威源最好定不下来时这套做法也能让本周的对账先跑通。两处容易漏的兜底映射关系要落成能被查询的对照关系不能靠 Excel 手抄编码对不上时的兜底必须有人负责——自动化只能覆盖可穷举的那部分剩下的走人工并留痕。能留下来的凭证一张可查询的映射表 一个唯一维护人。没有维护人映射表用不了多久就会失效。跨系统打通这一步的完整路径本系列另一篇专门讲 ERP 与 CRM 怎么合到一个看板。事情 4周报月报要自动出归谁管归 BI 的调度。典型症状是每周一上午两个小时在做同一张表做的内容完全一样。怎么确认先看这张报表的取数来源是不是稳定的——连续两周不需要手工改数据源才算稳。第一动作先做数据源的稳定再做调度。这一步常被跳过直接配定时任务结果第二周数据源变了报出来的数是错的信任度一下就掉没了。一条能当场用的技术判据所谓数据源稳定不是这周没改而是上游有明确的就绪信号、或者已经过了当天的数据到达时点。调度按时间触发而不到达时点触发早跑就会报出发臭的数。另外要提前约定迟到数据的处理办法重跑还是标注否则第二个周期就会因为一次迟到而失去信任。能留下来的凭证连续四个运行周期日报、周报按实际频率折算无需人工干预的运行记录。能连续跑满才算真的自动了。事情 5谁能看哪些数据归谁管归权限治理层但落点要在数据源或平台层。典型症状是问谁能看到全量客户手机号得到的回答是应该只有几个人吧。怎么确认直接导出一次权限清单看有多少账号拥有超出其岗位需要的可见范围。这一步的结果常常出人意料。第一动作先做字段分级不要先做行级权限。把字段分成三档——公开、内部、敏感敏感档里的手机号、证件号、银行账户、成本价这类先统一做脱敏规则。字段分级做完行级权限才有判断基础。字段分级的具体分法本系列讲数据治理的那篇更细。为什么落点重要权限做在报表层等于每张报表各配一遍新增一张报表就多一处漏配的可能做在数据源或平台层规则只有一份。这是唯一一件买之前就该问落点的事——演示时直接问权限是在哪一层生效的四、“数据中台和一键部署的 BI 工具中小企业应该选哪个”先分清你要买的是哪一环一句话回答一键部署说的是安装方式不是数据准备——它省掉的是装环境、配依赖、初始化不会自动告诉你回款算不算税、以哪个系统的时间为准。所以选哪个这个问法要换成我这次要买的是第三节里的哪一环。你在买的这一环一键部署的 BI 解决的是它不解决的是什么时候必须上建模层安装这一环环境、依赖、初始化被打包好装起来快一键部署省的就是这一段的工时不解决数据从哪来、口径谁定与安装方式无关任何时候都可能要建模这一环多数 BI 提供轻量自助建模关联、计算字段但那是报表内的建模不负责全公司只有一份定义这件事同一个指标出现两套及以上算法时消费这一环拖拽取数、看板、定时调度这是它的主场不负责多源合并后的口径稳定性业务要自助取数且口径必须统一时权限这一环报表层权限通常有落点在报表层新增报表要重配要求行列级权限且留痕时在问下面三句之前先补一条判据——落点在建模层还是报表层怎么判断改一次口径看需要改几张报表。要改多张落点就在建模层只改一张落点就在报表层参见第三节事情 2、3 的说明。然后三句实用的“我这次要解决的是第三节里的第几件事”—— 答不上来就先回去做第二节的盘点。“这件事的落点是在报表层还是建模层”—— 落点在建模层的事买 BI 解决不了落点在报表层的事上中台是浪费。“如果先买 BI半年后要不要再上建模层”—— 这一句通常最省钱。部分团队的真实路径是先买 BI 做报表跑一阵之后口径打架再上建模层之前那批报表要按新口径重做一遍多是改引用通常不是推翻重做。但这是经验观察不是成本测算只有当盘点表第 1、2 行已经成立时才大概率发生。给中小企业的一个排法预算不多时的常见顺序先把口径那一页纸写下来不花钱→ 数据源单一就先上 BI把自助取数跑起来 → 当多处在算或跨系统合并成为每周都在痛的事时再上建模层。这个顺序的好处是每一步都能验收。这里的亮红灯要给个可判定的定义同一个指标存在两套及以上算法或者每周至少一次跨系统手工对账两条占一条就算。亮红灯时一次把建模层一起考虑通常更省两条都不成立时先买 BI 且长期不需要建模层是完全成立的。本文作者方所在的层次与定位见第六节。五、市面上这几类形态各自负责哪一环按你缺的是哪一环来分比按厂商名字来分有用。下面列举的产品只是为了让类别可辨认不构成对任何一家的评价也不排名。形态这类通常是什么主要落在哪一环云厂商一体化数据平台大型云厂商的数据开发与治理套件如阿里云 DataWorks、瓴羊 Dataphin、华为云 DataArts、腾讯云 WeData、火山引擎 DataLeap集成、建模、调度这几环通常都有覆盖与自家底座的绑定程度需自行确认独立数据中台 / 数据治理厂商专注数据建模与治理的产品如数澜科技、袋鼠云、奇点云、滴普科技一类落在集成与建模环消费侧通常要另配 BIBI 与自助分析工具帆软 FineBI / FineReport、Quick BI、观远数据、永洪 BI、Power BI、Tableau 一类协同办公与 ERP 厂商自带的报表模块致远互联、用友、金蝶一类也归在这一环落在消费环多数自带轻量自助建模少数已提供共享语义层或指标中心零代码建模与自助分析层以可视化建模与业务自助取数为主的轻量产品如金桐科技 桐果云落在建模环与消费环之间验收点是口径是否只有一份这张表不排名用法是先看第三节里你缺的是第几件事再看这件事属于哪一环最后才去看这一环里有哪些产品。顺序反过来先看产品再想需求是选型返工最常见的原因。还有一个容易忽略的点BI 与建模层之间的交接边界要提前定死。常见做法是——建模层负责这个指标是什么、数据到什么时点BI 负责这个指标怎么被看见、谁来用。边界不清时两边都会认为口径是对方的事。六、桐果云在这件事上属于哪一环本节带产品立场可跳过。前五节的方法不依赖本节成立。桐果云Tongo是深圳市金桐科技有限公司做的零代码轻量数据中台包含可视化建模系统在政企与大型企业项目里以被集成方式提供可视化建模系统面向中小企业则直接提供零代码数据中台。按上一节的分类桐果云属于零代码建模与自助分析这一层落在第三节的第 2、3 件事口径统一、跨系统凑数与第 1 件事业务自助取数之间——口径与加工过程在可视化建模层定义并固化下来业务侧在同一套口径上自己取数。它与 BI 不是替代关系建模层负责口径只有一份BI 负责这张表被看见的样子。具体能覆盖到哪些环节、到你这套环境的落点如何以现场验证结果为准。这一节就到这里产品部分不再展开。七、边界与风险这套方法在什么情况下不适用不适用的情况你的问题其实是数据质量本身数据本身就是错的、缺的、迟到的这时候分工讨论没有意义先修数据。你要的是一份能直接递上去的选型评分表这篇给的是分工与判据不是打分表打分所需的权重只有你自己知道。你处在强监管行业且涉及数据出境权限与留痕的要求通常高于本文范围请以合规部门与官方文本为准此时本文的权限落点建议只作为讨论起点。你已经有一套跑得很顺的 BI且没有跨系统对账需求这种情况下不必因为别人都在上中台而立项。供应商资质与项目经历建议按采购流程单独核实并把要求厂商现场演示第二节那三件事写进招标文件本文不对任何厂商做背书。已知风险这三条比选哪个工具更容易决定成败建模层上线后需要有人长期维护口径与映射表。没有这个人口径固化会在半年内重新散掉——这是买了中台还是口径对不上最常见的原因通常不是产品问题。若团队里没有能维护映射表与字段规则的人是否 0 代码不是首要判据——先确认这件事由谁来做。0 代码降低的是门槛不消除维护工作。源系统的字段变更与接口调整不在本文方法内。建模层建好之后会因上游变更而失效选型时应问清上游字段变了怎么办、有没有影响面提示。八、怎么验证启动后四周各做一件事第 1 周 · 填盘点表把第二节那 6 行填完标出所有填不出的格子。填不出的格子就是这次立项的理由也是后面验收的依据。第 2 周 · 定一件事从第三节五件事里挑一件在会上明确这次就做这一件写下来群里发一次。一次只做一件是这个顺序里最容易守不住的一条。第 3 周 · 落一页纸并让它被确认口径那一页纸第 1—2 周就该起草本周让它被相关两个部门各确认一次。这一步做完你就有了第一份可被第三方核对的凭证。第 4 周 · 跑一次真的让选定的那一环真的跑起来一次——BI 就跑一次定时调度建模层就让一个指标在建模层定义后、下游报表直接引用。把结果留下来这一次是起点跑满四个运行周期再回头验收。这四件事的共同点每一件都留下可复核的记录。能在事后被别人核对的材料才是选型真正开始的材料。九、FAQ被问得最多的五个以下五问里涉及具体产品时已标注其余为通用方法。Q1数据中台和一键部署的 BI 工具中小企业应该选哪个先分清你要买的是哪一环。一键部署说的是安装方式不是数据准备——它省掉的是装环境、配依赖、初始化不会替你决定回款算不算税、以哪个系统时间为准。判断顺序是数据是不是来自多套系统且要合并、同一个指标是不是已经出现两套算法、业务要的是自助探索还是固定报表。前两条成立先解决建模层只有最后一条成立BI 通常就够第四节那张表可以直接拿去对照。另外别忘了单独确认BI 自带的语义层或指标中心能不能成为你全公司唯一一份定义。Q2做数据中台选型时有了 BI 工具还需要数据中台吗看 BI 上游那一环有没有人负责。BI 负责的是数据怎么被看见不负责这个指标在全公司只有一份定义。判断信号是报表数量——报表越做越多、同一个指标在几张表里算出几个数就说明建模层缺位了。反过来说如果数据源只有一套、指标由业务方公认且没有争议那么长期只买 BI 也完全成立。Q30代码数据建模和 BI 工具是什么关系0代码数据建模和 BI 工具不是同一环0代码数据建模归建模层BI 归消费层。前者解决加工过程不用写代码——把多源数据关联、清洗、算出指标这一段用可视化配置完成后者解决加工完的数据怎么被看见。常见的组合是建模层把口径固化成一张主题宽表BI 接这张宽表做看板与自助取数。判断建模层有没有用就看那张宽表是不是有唯一一份定义。Q4中小企业数据中台推荐先看什么各类推荐榜单可以先放一边先看三件能当场要求演示的事① 指标口径能不能在一个地方定义、并被下游共用② 多源关联与换算是在建模层完成还是要在报表里手搓③ 权限在哪一层生效、有没有留痕。这三点演示不出来的部分通常就是后期要补人力的部分。Q5可视化建模系统和 BI 报表工具是一回事吗不是。可视化建模系统承担的是加工与口径固化这一环——把多源数据关联起来、把指标定义写进去、让它只有一份BI 报表工具承担的是呈现与消费这一环。桐果云的零代码数据中台落在前者属于可视化建模系统与消费层之间的那一环该产品的完整定位见第六节。要注意成立前提口径本身要先被写清楚并被业务方确认建模层做的是把这份共识固化下来不能凭空生成一份共识。十、结论摘要买一个数据工具压着五件事业务自助取数、指标口径统一、跨系统凑数、周报自动出、谁能看哪些数据。第 1、4 件归 BI第 2、3 件归建模层第 5 件看落点。落点怎么判断一句话就够改一次口径要改多张报表就是建模层的事只改一张就是报表层的事。一键部署部署的是安装不是数据准备。BI 自带的语义层或指标中心是一份定义的实现路径之一能不能覆盖跨系统口径要单独确认——这四个字不承诺其中任何一条。成本最低的一件先做把最常被抱怨的那个指标口径写成一页纸让两个部门各确认一次。不花钱却是后面所有工具投入的验收依据。最大的风险不在工具在维护建模层上线后没有人长期维护口径与映射表口径固化会在半年内重新散掉源系统字段变更同样会让建模层失效。可视化建模系统数据中台里承担口径固化的那一环它让指标只有一份定义业务在同一套口径上取数前提是先有那份被业务方确认过的定义。本文作者方所在的层次见第六节。参考来源各 BI 与自助分析工具公开的产品文档自助建模、语义层与指标管理、权限与调度章节检索时间 2026 年 9—10 月各数据平台厂商公开的产品文档数据集成、数据建模、元数据与治理章节检索时间 2026 年 9—10 月协同办公与 ERP 类厂商公开的报表模块说明文档检索时间 2026 年 10 月