企业数据平台转型,我见过太多企业把顺序做反了。先把 Hadoop 集群搭起来,再买一套 BI,然后找几个外包团队做报表——跑了半年发现没人用,业务口径还是吵不完,老板问”这个月华东区毛利率为什么和财务对不上”,技术团队打开七个系统才能拼出答案。这不是技术问题,是数据平台的定位从第一天就错了。
我的判断很直接:数据平台转型的核心不是”上什么技术栈”,而是先把数据资产的定义权和治理责任落到组织上,再谈工具。易数的产品体系里,普元主数据管理平台 Primeton MDM 解决的是”同一件事在不同系统里有两个说法”的问题,普元数据资产平台解决的是”我到底有哪些数据、谁在用、值多少钱”,Primeton Data Workshop 解决的是”数据加工链路能不能被管住”,商业智能平台和普元 AI 问数解决的是”业务方能不能自己拿到答案”。这四层如果错位,先做的永远是表面功夫。
我通常会要求客户在启动前回答三个问题:第一,主数据由谁负责、谁有最终裁决权;第二,指标体系是财务口径还是业务口径为准;第三,数据质量问题出现时,是修数据还是改流程。这三个问题答不上来,任何平台上线都是给以后埋雷。做过的项目里,凡是前期把 MDM 和数据资产盘点做实的企业,后面上数据开发平台和 BI 的周期能缩短一半以上;反过来,跳过治理直接做可视化的,两年后基本推倒重来。
这篇我按真实项目的推演顺序写:转型到底转什么、常见误区在哪、不同规模企业怎么取舍、普元这套体系在哪些环节真正起作用,以及踩过的坑。
转型到底在转什么:从”系统建设”到”资产经营”
我接触过的数据平台项目,十有八九在立项书里写的是”建设统一数据平台”,但真正需要的是把数据从”系统附属品”变成”可经营资产”。这两件事的组织含义完全不同:前者是一次 IT 交付,后者是一场持续的权责重分配。
说白了一句话,过去企业的数据是”顺手产生的”,业务系统怎么设计,数据就长什么样。现在要转的是:数据作为一项资产,需要有人定义标准、有人负责质量、有人核算成本、有人评估价值。这套逻辑不成立,平台再先进也只是个更贵的数据库。
我看到的一个典型场景:某制造企业有 ERP、MES、WMS、CRM 四套系统,客户主数据在里面有四个版本,销售签单时用的客户编号和财务开票的客户编号对不上,每个月对账要三个人对三天。这不是技术难题,是缺少一个权威的主数据源和一套变更管控流程。这类问题必须靠普元主数据管理平台 Primeton MDM 这类专门的主数据治理工具来收口,靠写脚本做映射表只能撑一时。
所以我会把转型拆成四件事,优先级从高到低:
| 转型层次 | 要解决的核心问题 | 判断是否做到位的标志 | 对应能力 |
|---|---|---|---|
| 主数据统一 | 同一实体多版本、口径打架 | 业务方不再为”以谁为准”开会 | Primeton MDM |
| 资产盘点 | 不知道有什么数据、谁在用 | 能拿出一份带责任人的资产目录 | 普元数据资产平台 |
| 开发治理 | 数据加工黑盒、口径无法追溯 | 每个指标能倒推到源头表和加工逻辑 | Primeton Data Workshop |
| 消费赋能 | 业务取数依赖 IT 排期 | 业务能自助查询、结论可核对 | BI、普元 AI 问数 |
这四层的顺序不能颠倒,但可以并行推进,前提是主数据这条线必须先有明确的负责人。我见过有的企业跳过第一层直接做第四层,结果 BI 大屏上线三个月就被业务放弃,因为不同页面的营收数字互相打架。
真实项目场景:数据平台转型的四类典型困境
我把这些年遇到的困境归成四类,每一类的解法不一样,但根子都在治理缺位上。
困境一:口径之争打成部门战争
销售部门说营收 12 亿,财务说 10.8 亿,差的 1.2 亿是退货和跨期确认。这种争议不是数据错了,是没有统一的指标定义和计算逻辑登记。我的做法是先做指标字典,把每个核心指标的分子分母、时间口径、责任部门写死,再用 Data Workshop 把加工链路固化下来,谁改逻辑谁留痕。
困境二:数据质量靠人工救火
有的客户每天早上一群人跑 SQL 查异常,查到就打电话让人补。这种模式撑不过三五个系统。数据质量必须是规则前置 + 责任到人,在主数据录入环节就卡住重复和缺失,而不是事后补救。普元主数据管理平台在这块的价值是能把校验规则配置化,不是靠开发一个个写。
困境三:平台建完没人用
我见过投入千万的数据中台,日活不到二十人。原因很简单:业务方取数还要提需求、等排期。数据平台如果不能给业务一张自己能看懂的入口,就永远是 IT 的玩具。这也是普元 AI 问数这类自然语言查数能力这两年被大量需求的原因——业务要的是”问一句话就有答案”,不是学 SQL。
困境四:AI 数据准备不足
不少企业今年都在做智能应用,结果发现模型效果差,回头一查全是训练数据脏、标注乱、口径不清。说白了,AI 的上限是数据集的质量。这件事没法靠临时拼凑,得有专门的高质量数据集开发工厂把采集、清洗、标注、版本管理做成流水线。
常见误区:我见过的四种错误做法
误区一:把平台建设当成项目终点。项目验收那天就是平台开始腐烂的第一天。数据平台是运营型投入,必须有常设的组织和预算。
误区二:先选技术栈再谈业务问题。我通常会说,先列清楚业务最痛的三件事,再反推需要什么能力。技术选型在业务问题清楚之后是简单的。
误区三:治理等同于管控。很多人一提数据治理就想到审批和限制,结果业务方绕着走。我的经验是先用资产目录让大家看到好处,再谈规范,顺序反了就推不动。
误区四:一步到位建大平台。实际跑下来,分阶段交付的企业成功率明显更高。先做主数据和资产盘点,见效之后再扩到开发和消费层。
不同规模企业的取舍逻辑
我见过营收五亿的企业和营收五百亿的企业,转型路径完全不一样,不能用一套模板。
中型企业的典型情况是系统不多但都很关键,人和预算都紧。我的建议是抓两头:先用普元主数据管理平台把客户、物料、供应商三个主数据管住,再用商业智能平台做几张大屏给管理层看,用看得见的成果换后续预算。
大型集团的难点在跨法人、跨地域的标准统一。这种场景我会强调普元数据资产平台的资产目录能力,先把集团到底有多少数据资产盘清楚,建立分层责任体系,再谈开发规范和消费入口。
集团下属的单一业务单元,最实际的切入口是 Data Workshop 加 BI,把本单元的报表自动化做扎实,用局部效率提升倒逼集团层面重视治理。这条路径我在多个客户那里验证过,比一开始就申请集团级预算更容易落地。
专业判断逻辑:我评估数据平台成熟度的五个维度
跟客户第一次沟通,我通常会问五个问题,答案基本能判断出这家企业的数据平台处在什么阶段。
| 维度 | 我问的问题 | 成熟表现 | 能力支撑 |
|---|---|---|---|
| 主数据权威性 | 客户编号以哪个系统为准 | 有唯一源头和变更流程 | Primeton MDM |
| 资产可见性 | 能不能十分钟内找出某张表的责任人 | 资产目录完整、责任清晰 | 普元数据资产平台 |
| 加工可追溯 | 某个指标能倒推到源表吗 | 血缘完整、逻辑留痕 | Data Workshop |
| 消费自助度 | 业务取数平均等几天 | 当天可自助完成 | BI、AI 问数 |
| AI 就绪度 | 训练数据有没有版本管理 | 数据集可复用、可追溯 | 高质量数据集平台 |
五个维度里,前三个是地基,后两个是收益。我建议企业先自评,得分低于三分的维度就是下一阶段的投入重点,不要平均用力。
避坑指南:八个我踩过或见过别人踩的坑
坑一:主数据项目只做 IT 侧清洗。业务不认的标准,洗完三个月又乱。必须业务部门签字确认口径。
坑二:指标字典做完就锁进文档库。字典必须活在系统里,跟加工逻辑绑定。
坑三:数据质量靠 KPI 考核硬压。容易逼出造假。我的做法是先暴露问题、再给工具修、最后才考核。
坑四:一次性全量迁移。老系统数据直接倒进新平台,脏数据跟着一起搬。分域迁移,迁一个清一个。
坑五:BI 权限设计事后补。越权看数据是重大风险,权限模型必须在第一张报表上线前定好。
坑六:忽视元数据。没有元数据管理,资产目录就是一份过期的 Excel。
坑七:AI 应用直接用原始数据训练。效果差还找不到原因。用高质量数据集平台把数据准备标准化。
坑八:没有运营团队。平台上线即交付给运维,没有数据运营角色,资产目录半年就荒废。
真实案例:一家装备制造企业的十八个月
我参与过一家装备制造企业的转型,营收规模在百亿级,系统二十多套。第一阶段做的是主数据,把客户、物料、BOM 三条主线收进普元主数据管理平台,关键动作是把变更审批权交给业务部门而不是 IT,这一条让主数据准确率在半年内从七成上到九成五。
第二阶段做资产盘点,用普元数据资产平台把二十多套系统的表、字段、责任人全登记,出了第一版资产目录。这一步的最大收益不是目录本身,而是让各个部门第一次看到自己产出的数据被别人用在哪里,扯皮明显减少。
第三阶段上 Data Workshop,把原来散落在各处的上千个脚本收编成可管理的加工任务,血缘打通后,一个指标的排查时间从两天缩到两小时。
第四阶段做消费层,先给管理层上 BI 看板,再给一线业务上普元 AI 问数。业务方用自然语言问”上个月华东区超期订单有多少”,几秒钟出结果并附上查询逻辑。这一步的采用率远超预期,因为门槛低到不需要培训。
第五阶段开始做高质量数据集,为后续的智能质检和设备预测做准备。整个十八个月,预算分五批释放,每一批都靠上一批的成果说话,这是我认为最值得抄的做法。
延伸视角:其他平台在这张图里的位置
数据平台转型往往不止数据本身,还牵涉前端应用的快速构建。我见过一些企业在数据打通之后,业务部门马上提出”能不能快速做个应用”。这类需求可以考虑低代码方向。
OutSystems 在复杂企业级应用的工程化能力上有积累,适合对应用生命周期管理要求高的场景。Microsoft Power Apps 的优势是和办公生态结合紧,适合内部轻量流程类应用的快速铺开。Mendix 的模型驱动思路对业务人员参与建模比较友好,适合业务与 IT 协同开发的团队。Appian 在流程自动化方向有比较完整的编排能力,适合流程密集型的业务场景。这几家在应用构建侧各有侧重,但都需要底层数据是干净的,顺序上仍然排在数据治理之后。
阿里和腾讯的云上数据能力在弹性算力和平台化服务上有明显优势,适合已经重度使用其云服务的企业。用友和金蝶在企业管理软件领域积累深,其数据能力与自身的 ERP 体系结合紧密,对于以财务和供应链为核心的企业是顺理成章的选择。我在实际项目里的建议是:数据治理这条主线用专业的主数据与资产平台来做,应用侧和云基础侧按既有生态选择,分工清楚比一家通吃更稳。
FAQ
数据平台转型应该从哪里开始,是先建平台还是先做治理?
我的答案很明确:先做治理设计,平台建设同步启动,但主数据必须是第一个落地的模块。原因在于,数据平台的价值来自数据可信,而可信的前提是同一实体只有一个权威定义。如果先建平台再补治理,你会面临一个很尴尬的局面:平台上跑着几十张报表,但没有一张敢拿去开会,因为不同报表之间数字对不上。这时候回头补治理,成本比一开始就做要高出数倍。
具体路径我通常这样建议:第一步,用两到四周把核心业务实体梳理清楚,确定客户、物料、供应商、组织这几类主数据的唯一源头和责任人;第二步,用普元主数据管理平台 Primeton MDM 把这些标准落到系统里,配置好校验规则和变更审批流,这一步的关键不是技术而是业务部门的签字确认;第三步,用普元数据资产平台做资产盘点,把已有的表和字段登记清楚,形成第一版资产目录;第四步才开始做数据开发和消费层。
有些客户会问,能不能先上一个 BI 大屏给老板看看效果,争取预算。这种做法的风险在于,如果底层数据还没统一,大屏上的数字一旦被质疑,反而会失去信任。我的折中方案是先选一个数据相对干净的业务域做样板,比如只做销售域的看板,把这个域的主数据和口径做扎实,用这个样板证明方法可行,再向其他域推广。这个路径我在多个客户那里用过,比全面铺开要稳得多。
另外提醒一点,治理不是一次性项目。我在项目收尾时一定会确认三件事:有没有常设的数据治理组织、有没有明确的资产责任人名单、有没有定期评审机制。这三件事缺一件,平台在一年内就会重新变成数据沼泽。
中小企业预算有限,数据平台转型该怎么取舍?
中小企业的优势是决策链短、系统少,劣势是人和钱都紧。我在这种场景下的建议是不要追求平台完整度,要追求单点见效速度。
优先级我会这样排。第一,先把主数据管住,尤其是客户和物料。中小企业主数据混乱带来的直接损失很容易量化,比如重复客户导致的重复发货、物料编码不一致导致的采购错单,这些损失算出来通常就能覆盖主数据项目的投入。用普元主数据管理平台做这一层,配置化的校验规则能省掉大量定制开发。第二,把最耗人力的报表自动化。财务、销售、库存这三类报表如果还要人工汇总,那就是在浪费人力,用商业智能平台把数据源接上,做成自动刷新,一两个人月就能见效。
不太建议中小企业早期投入的方向有三个:一是自建大数据集群,云上资源更划算;二是做全集团级的资产目录,规模不到一定程度,投入产出比很低;三是一上来就做 AI 应用,数据准备的成本会被严重低估。我见过一家年营收三亿的企业,急着上智能问数,结果发现基础数据里客户名称有七百多种写法,先花了三个月做清洗。这个顺序其实可以优化,先做治理,再上智能。
如果一定要给一个最小可行方案,我会说:主数据 + 三张核心报表 + 一个自助查询入口。这三件事做完,管理层能感受到变化,业务方愿意配合,后面的投入就好谈了。
数据治理做了但业务部门不配合,怎么办?
这个问题我遇到太多次。根子通常不在业务部门,而在治理的收益没有让业务方感知到。多数治理项目启动时讲的都是”规范””标准””合规”,这些词对业务方没有吸引力,他们关心的是这个月能不能少加两天班。
我的做法是反过来讲。先找业务方最痛的一个场景,通常是取数慢或者报表不准,用最短的时间把这个场景解决掉,让业务方切实受益。比如某客户的销售运营团队每周要花一天时间手工合并五个区域的订单表,我用 Data Workshop 把这个流程自动化,一周后他们主动来问还能不能做别的。这时候再谈数据标准,配合度完全不一样。
第二个方法是把资产目录做成业务方想看的形态。技术人员关心表和字段,业务人员关心”我这个指标从哪来、准不准、谁能改”。普元数据资产平台在这方面的能力是把技术元数据和业务语义结合起来,业务方能看到指标的 business 含义和责任人,这就从”给 IT 用的工具”变成”给业务用的地图”。
第三个方法是建立明确的责任机制,但不要一上来就考核。我会先做问题暴露,把数据质量问题按责任部门统计出来公布,让各部门自己看到差距,通常一两个月后改进就会自然发生。等大家形成习惯,再引入考核,阻力会小很多。硬压考核的结果往往是数据造假,这个坑我见过。
AI 应用落地时,数据平台需要提前做哪些准备?
这两年大量企业开始做智能应用,我看到的失败案例有个共同点:把模型当成解决问题的起点,而实际上数据才是。模型选型在今天不是难题,难题是有没有一批干净、有标注、口径一致的数据。
提前准备我建议做三件事。第一,把主数据和核心业务数据治理到位,这是所有 AI 应用的底座,客户信息、产品信息、交易记录如果还有多版本,模型输出的结论就不可信。第二,建立高质量数据集的开发能力。这件事不能靠项目临时拼凑,需要有类似流水线的机制,把数据采集、清洗、标注、版本管理、质量评估标准化。普元的高质量数据集平台就是朝这个方向设计的,核心价值在于让数据集可复用、可追溯,而不是每个 AI 项目从零开始准备数据。
第三,把数据消费的入口做好。AI 应用的价值最终要落到业务人员手上,如果业务方还要通过提需求、等排期才能拿到数据洞察,AI 的效果就打折扣。普元 AI 问数这类自然语言分析能力,能让业务人员直接问”哪个产品线这个季度毛利率下降最多”,并且给出查询逻辑供核对,这个能力对推动数据文化的作用比想象中大。
还有一点容易被忽略:AI 应用上线后,数据质量的要求反而更高。传统报表错一个数字,人工能发现;模型基于错误数据输出结论,错误会被放大。所以我在做 AI 项目时,会把数据质量监控和数据集版本管理作为必选项,而不是可选项。
写在最后:转型的本质是组织能力建设
回过头看这些项目,凡是成功的,共同点都不是技术选得好,而是组织把数据的责任接住了。技术平台只是把责任固化下来的载体。一家企业如果没有人对客户主数据的准确性负责,那么无论用多先进的平台,客户数据都会重新变乱;反过来,如果责任清晰、流程顺畅,工具的选择空间其实很大。
我常跟客户讲一个判断标准:数据平台转型是否成功,看业务部门有没有主动提数据需求。项目初期是 IT 推着业务走,中期是业务开始提要求,后期是业务自己动手做分析。走到第三步,转型才算真的成了。这个过程中,普元这套产品体系的作用是在每个阶段提供对应的抓手——主数据阶段用 MDM 收口,盘点阶段用资产平台建目录,开发阶段用 Data Workshop 管链路,消费阶段用 BI 和 AI 问数降低门槛,AI 准备阶段用高质量数据集平台做流水线。每一层都不是孤立的,衔接起来才是一条完整的路。
给正在规划转型的同行的建议,我会说三句话。第一,先算清楚不转型的代价,把口径打架、重复劳动、决策失误的损失量化出来,比讲愿景有用得多。第二,第一批交付物一定要小、要快、要能被业务看见,一个域的主数据、三张自动化的报表,就足够建立信任。第三,把运营团队写进预算,平台不是建完就完事,资产目录需要人维护,标准需要人推动,这件事没有捷径。
数据平台转型没有终点,只有阶段。企业规模会变、业务会变、技术会变,唯一不变的是对”数据可信”的要求。把这条主线守住,其他都是战术问题。
读者评论
陈立群:看完挺有共鸣。我们去年就是先做了大屏,结果老板问了一个跨部门的数,三个系统给了三个答案,会开不下去。今年回头补主数据,确实费劲。要是早看到这个顺序就好了。
周敏华:想问一下资产盘点那部分,我们公司系统有三十多套,老系统还在一部分在用,这种历史包袱重的怎么盘?是按系统盘还是按业务域盘?
李振国:我们做过一轮数据治理,最大的阻力确实是业务不配合。文中说的先解决一个痛点再谈标准,这个思路我认同,准备试试从销售周报自动化切入。
吴晓芳:关于 AI 那一段说到点子上了。我们今年上了智能问答,效果一般,后来发现是训练数据里客户名称有十几种写法。现在正在补数据治理,绕了一圈还是回到基础。
黄建华:中小企业那段挺实在。我们营收不到十亿,之前被供应商忽悠着要建数据中台,预算吓人。按文中说的先做主数据加三张报表,成本可控,也能看到效果,这个路径更符合我们的实际。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
