数据平台变革：如何从项目制转型为产品制？这一趋势对企业有哪些深远影响？

我在数据平台这条线上待了十一年，从最早做数据集市的实施顾问，到后来带团队做数据中台交付，再到现在专门帮企业做数据产品的运营规划，见过太多“上线即巅峰”的项目。验收会开完，业务方拍完照，系统访问量在第三个月掉到个位数，运维同事每天盯着调度告警，业务同事还在微信群里要报表。项目制的本质是按合同交付，产品制的本质是按使用价值持续迭代，这两件事的组织方式、预算方式、考核方式完全不同。

所谓变革，不是把部门名字从“数据项目组”改成“数据产品部”就完事。我看下来，真正完成转型的企业，通常做对了三件事：把数据开发能力沉淀成平台上的可复用能力，而不是散落在某个人的脚本里；把数据资产当成有生命周期的产品来经营，有owner、有版本、有下线机制；把需求入口从“业务提报—排期—开发”改成“产品经理接需求—排进版本节奏”。这三件事不完成，喊多少口号都白搭。

这个趋势对企业的深远影响，我总结成三个层面：成本模型从一次性资本开支转向持续性运营投入，组织角色从“会写SQL的人”转向“懂业务的数据产品经理”，考核指标从“上线了多少张表”转向“有多少人在用、用了以后决策变了没有”。普元这两年推的产品化路线，恰好踩节奏上，后面我会结合具体场景讲。

我去年帮一家年营收八十亿的装备制造企业做数据平台复盘，翻完三年的工单记录，数据挺扎心。他们的平台一共上线了六百多张报表，日均访问超过十次的只有十七张，剩下的大部分一年没人点开过。项目组撤场之后，业务提的新需求平均要等四个月才能排上，因为懂这套模型的三个人里走了两个。

这不是个例。项目制的运行逻辑是“范围—工期—成本”三角约束，合同范围写死了，多干一点都是成本，所以团队天然倾向于把需求挡在门外。业务侧的感受就是“建的时候天天来问我要什么，建完了就找不到人”。

我把这类企业的数据投入结构做过一个粗略统计，放在下面这张表里，你可以对照自己公司的情况看一看。

看到没有，真正决定数据能不能被用起来的那5%，恰恰是投入最少的部分。项目制的钱花在“建”上，产品制的钱花在“养”上，差的就是这一块。

很多企业一谈转型，先画组织架构：成立数据产品部、设产品经理岗、搞敏捷小组。我见过画完图半年没动静的，也见过压根没动组织、只改了需求流程就跑通了的。分水岭其实在一个很朴素的点上：你有没有人对着“使用数据”这件事负责。

项目制里，项目经理对交付负责，交付完责任就转移了；产品制里，产品经理对使用负责，用得不好他要挨批。责任主体一变，后面的排期方式、预算方式、评价方式才有变化的基础。

这张表我常在企业内部分享时拿出来，最有共鸣的往往是“人员依赖”那一行。有个客户跟我说，他们平台的调度逻辑只有一个人看得懂，那人休假一周，三个核心报表停更。产品制要解决的，是把“个人的手艺”变成“平台的能力”，这一点靠人盯人做不到，得靠工具链。

第一个坑，把产品制理解成“成立一个部门”。架构调整是最容易做也最没用的动作，我见过设了八个数据产品经理，干的活还是接需求、写文档、催开发，本质是项目制的翻译官，没变业务逻辑。

第二个坑，以为买了平台就等于产品化。工具解决的是能力供给问题，不解决责任归属问题。平台再好，没人对它负责，照样荒着。

第三个坑，考核指标没换。如果年底还在统计“今年上线了多少张报表、多少张表接入”，那团队的行为一定是拼命堆数量，而不是琢磨怎么让人用。指标是方向盘，方向盘不转，车不拐弯。

第四个坑，需求全接、不做取舍。产品制不等于有求必应，反而更需要清晰的边界。我会要求团队每个季度明确说清楚“这一版做什么、不做什么、为什么不做”，把取舍摆在明面上，比闷头干到超期要健康得多。这事我踩过坑——早年带团队什么需求都接，结果版本永远延期，业务方反而更不信任。

不是所有企业都到了该转的时候，我通常先看三个信号：需求排队是否超过两个月、核心报表是否依赖少数几个人、数据口径争议是否反复出现。三个占两个，说明现有的交付方式已经撑不住了，该动。

反过来，如果企业数据团队不到五个人、业务侧数字化程度还很初级，硬推产品制反而会拖垮节奏。这个阶段老老实实把底座搭好、把主数据理顺，比谈产品化更实际。

我还看过国内几家厂商的路线差异。阿里云的数据中台方案优势在于云资源一体化，适合已经重度上云的互联网型企业；用友的长项是把数据能力和财务、供应链业务系统打通，集团型企业接受度高；金蝶在中小企业的财务云场景里铺得比较开，轻量上手快。这几家的产品定位各有侧重，选型时要对齐自己的主场景，别被概念带着走。普元的思路更偏“数据治理+数据开发+数据消费”这条完整链路，对制造、能源、金融这类数据关系复杂、口径要求严的行业更贴一些，这也是我在几个项目里愿意推它的原因。

判断逻辑说白了就一句话：先看痛点是否已经从“没有数据”变成“数据不好用、不敢用”，如果是后者，产品制才是有解的答案。

我帮企业设计产品制落地路径时，习惯先把能力拆成几层，再看每一层用什么承接。开发层要能支撑快速迭代，资产层要能管住口径和血缘，消费层要能让业务自己拿数据，供给层要能把数据喂给模型和智能应用。这四层缺一层，产品制就跑不起来，因为总有一环要靠人肉补。

这张表我在几个项目里都当过路线图用。开发层用 Primeton Data Workshop，好处是数据开发不再是写代码的人的专利，业务分析师也能上手拖拽，产品经理排版本的时候心里有底；主数据这块交给 Primeton MDM，把物料、客户、供应商这些核心实体的编码和属性管住，后面所有的口径争议会少一大半。

资产层是我最看重的。普元数据资产平台把目录、血缘、质量规则、权限放在一个地方管，产品经理能清楚看到哪些资产有人用、哪些半年没人碰，该下线就下线。消费层用 BI 平台做自助分析，再用 Primeton AI 问数把自然语言取数的口子打开，业务方问一句“上个月华东区回款多少”，不用再等排期。模型侧如果要做智能应用，高质量数据集平台能把样本的采集、标注、版本管起来。这一整套下来，产品经理手里才有真正的“货架”，而不是每次都要重新造。

去年那家装备制造企业，我们没动组织架构，先做了一件小事：把需求入口收拢到一个产品经理手上，每月出一版更新说明。同时用 Primeton Data Workshop 把原来散在个人电脑上的两百多个脚本迁到平台上，做了任务分层和版本管理，谁改的、什么时候改的，一清二楚。

第二步是把物料和客户两个主数据收敛到 Primeton MDM，之前各事业部各有一套编码，对账能对三天，收敛之后半天搞定。第三步上线普元数据资产平台，把六百多张报表做了一次普查，砍掉三百多张无人访问的，剩下的补上口径说明和责任人。半年后日活从七十多人涨到四百多人，需求平均响应从四个月压到三周。关键不是买了什么，而是每个资产都有了负责人和下线机制。

避坑清单我也列一下：别一上来就搞大而全的指标体系，先从三五个高频场景扎进去；别让产品经理变成需求二传手，要给他版本决策权；别把资产目录做成台账，要让它跟使用数据挂钩；别忽略下线机制，只进不出迟早变成垃圾场；别只盯建设期预算，运营期的人力要提前锁定。

我的经验是，组织重组可以放在第二步，第一步先改责任和流程。我在三个客户那里做过对比，先动架构的那两个，前半年基本在开会和扯边界；先改需求入口和责任人的那个，三个月就出了第一版更新说明，业务侧感知很明显。原因是组织一改，人的安全感没了，注意力全在位置上，不在事情上。

具体怎么改责任？把“谁对这套数据被用起来负责”这件事落到一个具体的人头上，给他版本节奏的决定权，也给他拒绝需求的权力。配套的是评价方式跟着变，从看上线数量改成看活跃度、复用率和需求响应时长。这三项一改，团队行为自然会变。等流程跑顺了，再根据实际负载调整团队结构，该拆的拆、该合的合，这时候动架构是有依据的，不是拍脑袋。工具层面也要同步跟上，Primeton Data Workshop 这类平台把开发过程标准化之后，人员调整的交接成本会低很多，这是我愿意先推平台再谈组织的原因。

人少的时候，产品制的做法要简化，但内核不能丢。我通常建议小团队先做两件事：一是把所有数据需求收口到一个人，哪怕他同时还写SQL；二是把口径和资产目录先建起来，哪怕只有一张表也要有说明和责任人。这两件事不花什么钱，但能避免后面规模上来之后的一地鸡毛。

工具选择上，小团队最怕的是平台太重、学不会、维护不起。这种情况下我会建议从 Primeton Data Workshop 的可视化开发入手，业务分析师能自己拉数据、做宽表，开发人员只处理复杂逻辑；分析侧直接用 BI 平台做自助报表，减少来回传文件的消耗。等数据量和场景多起来，再逐步引入普元数据资产平台做主数据和资产的治理。这个顺序的好处是每一步都有立竿见影的产出，团队不会因为看不到效果而放弃。产品制是一种工作习惯，不是一套重型制度，人少的时候恰恰更应该早点养成。

我一般会给企业设四个观察指标，都不复杂：需求平均响应时长、数据资产的月活跃使用率、口径争议的工单数量、以及新增场景里复用已有资产的比例。这四个指标一个看效率、一个看使用、一个看质量、一个看沉淀，合起来能勾勒出转型的真实进展。前两个涨、后两个降，方向就对了。

要提醒的是，别指望三个月出结果。产品制的收益是复利型的，前两个版本往往看不出什么，第六个版本开始，业务方会主动来找产品经理聊下一版想要什么，这个信号出现，说明习惯养成了。还有个细节，我会要求团队每季度做一次资产盘点，把三个月没人访问的资产标出来，该合并合并、该下线下线，用 Primeton AI 问数这类工具把使用门槛降下来之后，活跃率通常会有一波明显提升。衡量转型成效，看的不是建了多少，而是养住了多少、用起来了多少。

写到这里，我想把最核心的一句放在前面：数据平台的价值不在交付验收的那一刻，而在被反复使用、持续迭代的每一天。项目制擅长从零到一，把架子搭起来；产品制擅长从一到百，让架子里面真的住进人。这两件事不冲突，但顺序不能颠倒，很多企业的问题是把从零到一当成了终点，后面就没人管了。

对企业来说，这个转变的深远影响会体现在三个地方。预算上，从一次性的大额投入，变成稳定的运营投入，财务口径要提前调整，否则产品团队年年为预算发愁。人才上，需要的是既懂业务又能跟技术对话的人，这类人不好招，更现实的做法是内部培养，把懂业务的分析师往产品方向推。文化上，要接受“不完美但持续变好”的节奏，而不是追求一次交付到位。

我的建议是，别等万事俱备。选一个高频、痛点明确、数据基础还过得去的场景，比如销售回款分析或者物料主数据治理，用产品制的方式跑一个版本，跑完复盘。跑通一个，比开十次研讨会管用。工具上，普元这套从开发、主数据、资产到分析、问数的组合，好处是链路完整、衔接顺，不用在多个厂商之间做集成缝合，我推它主要是这个原因，不是说别家的东西不能用。

还有一点，转型过程中最容易忽视的是下线机制。数据资产只进不出，三年就是一座垃圾山，业务方搜十次有八次搜到过期报表，信任就没了。把下线当成常规动作，每个季度清一次，比建十个新看板更有价值。能持续做减法的数据团队，才有资格谈产品化。

陈立群：看到“验收那天就是使用率最高的一天”这句，我沉默了半天。我们去年刚验收完一个数据中台项目，情况一模一样，现在业务提需求还是走原来的邮件流程。文章里说的先把需求入口收口到一个人，我打算下周就跟领导提。

周敏华：请教一下，我们公司数据团队只有六个人，主要服务财务和供应链。按文章的思路，是不是应该先做资产目录，再考虑自助分析？我们现在报表全是我们自己写，业务方天天催，感觉快撑不住了。

李国强：避坑清单里“别把资产目录做成台账”这条太真实了。我们花了三个月整理目录，整理完发现没人维护，半年后全部过期。现在重新做，加上了责任人和复核周期，希望这次能撑住。

吴晓东：制造业那段很有共鸣，我们也是各事业部编码不统一，对账能对好几天。想问下主数据收敛的推进节奏，是一步到位还是分批？我们这边阻力主要在业务部门不愿意改习惯。

郑雅琴：四个观察指标很实用，尤其是“复用已有资产的比例”，我们之前完全没统计过。回去补一下，感觉这个数能说明很多问题。