企业数据平台如何有效支持项目制转产品制路径？你准备好了解最佳实践和成功案例了吗？

我的判断很直接：项目制转产品制失败的案例里，八成不是研发流程没改，而是数据底座还停在项目制的逻辑上。这些年我参与过不少 B2B 软件公司的转型评估，会议室里讨论的往往是组织怎么拆、产品经理怎么配、售前怎么考核，很少有人先问一句——我们的数据模型能不能跨客户复用？客户主数据是一套还是七套？同一个”毛利率”指标，在八个项目里是不是八个算法？

项目制的本质是”为客户定制一套能跑起来的东西”，交付即结束；产品制的本质是”用一套可配置的底座，快速拼出满足不同客户的形态”，交付只是开始。这两件事对数据层的要求完全相反。前者允许每个项目自带一套库表，后者要求主数据唯一、指标口径唯一、数据服务可被反复调用。所以数据平台在这里的角色必须变——从”项目交付的配套设施”，变成”产品零件的生产车间”。

我会用三个标准来判断一家企业的数据平台到底支不支撑产品化：口径是否唯一、资产是否可被检索和复用、交付是否靠配置而不是靠改代码。这三条过不了，产品化就只能停留在 PPT 上。普元这套面向数据治理的产品线——主数据管理平台、数据资产平台、数据开发平台、BI、AI 问数、高质量数据集平台——覆盖的恰好是从”项目数据”到”产品零件”的这条链路。下面我按自己踩过的坑和见过的案例，把这条路拆开讲。

一、项目制转产品制，卡住的往往不是研发，是数据底座

我见过太多企业把转型做成了一次组织调整：成立产品部、设产品经理岗、画产品路线图，然后发现第二年还是在做项目。原因很简单，组织可以一夜之间改完，数据资产的沉淀是慢功夫。项目制的副产品是一堆”够用就好”的数据结构，字段命名靠开发个人习惯，主数据靠 Excel 维护，指标口径写在需求文档里，人一走就没人说得清。

产品制要求的是另一套东西：一套稳定的领域模型，一套可配置的规则引擎，一批能被不同客户复用的数据服务。说白了，产品化不是把项目卖两遍，而是把项目里那些重复出现的部分抽出来，做成可组装的零件。零件从哪来？只能从数据层来。

我通常会让客户先做一张对照表，把自己现在的位置标清楚。很多争论在表格填完的那一刻就消失了。

这张表最扎心的一行是成本结构。项目制做十个客户要十份人力，产品制做十个客户可能只需要三份，差距不在销售，在数据复用率。

二、同一个数据平台，在两种模式里的角色完全不同

很多企业已经建了数据平台，但它是为项目服务的：项目来了建库、抽数、做报表，项目结束库还在，人没了。这种平台只是”存储和计算资源池”，对产品化几乎没有贡献。

真正支撑产品化的数据平台，功能定位要往前提一层：它得成为产品配置的数据来源。客户差异不是靠改代码解决，而是靠参数和主数据映射来解决；新客户上线不是重新建模，而是在已有资产目录里挑选和组装。

我在一家工业软件公司看到过很典型的转变：他们把数据平台的考核指标从”报表交付数量”改成”新客户上线时被复用的数据服务数量”，一年之内团队的建模习惯就变了。指标改在哪里，行为就变在哪里。这件事靠开会喊口号是改不动的。

三、三个我反复见到的误区

第一个误区是把中台当项目做。立项叫”数据中台建设”，验收标准是一批报表上线，结果中台本身成了一次性交付物。中台的价值在于被反复调用，不被调用的中台就是一套昂贵的数据库。

第二个误区是把”复用”理解成”建个目录”。我见过资产目录做得很漂亮，点进去几百张表，可是没有口径说明、没有血缘、没有责任人，开发人员根本不敢用。可复用资产的判据不是”有没有登记”，而是”别人敢不敢直接拿去交付客户”。这中间差着元数据质量、血缘追溯、样例数据、变更通知一整套机制。

第三个误区是等组织调完再动数据。组织调整往往一拖两年，而数据口径的收敛是可以并行推进的。我通常建议先把主数据和指标字典这两件事抓起来，它们跟组织架构关系不大，但直接决定产品能不能配置化交付。普元主数据管理平台在这类场景里做得比较扎实，模型、编码规则、审批流、分发机制是成套的，不用企业自己从零拼。

这三个误区有个共同点：都把产品化当成”管理动作”，没当成”工程动作”。管理动作解决意愿，工程动作解决能力。缺一个都跑不通。

四、把项目交付物变成产品零件：三条链路

我理解的资产化路径，实际就三条链路，缺哪条都会断。

第一条是主数据链路。客户、供应商、物料、组织、人员这几类对象，只要在不同客户之间能建立映射关系，产品就具备了”同一套逻辑、不同数据”的基础。这件事我用普元主数据管理平台配合做过几轮，感受比较深的是它的分发和订阅机制——主数据变更后能主动推送到下游系统，而不是靠各系统自己定时去捞。产品化交付里这个能力很关键，因为客户现场的系统是异构的。

第二条是资产目录与血缘链路。普元数据资产平台解决的问题是”我知道我有什么、它从哪来、谁在用”。资产要有责任人、有质量规则、有变更记录。我一般会要求客户在上线前做到：任一指标能追溯到源系统字段，任一核心表有明确的业务负责人。做不到这两条，复用的信任建立不起来。

第三条是开发与调度链路。产品化之后，数据开发不再是”一个项目一套脚本”，而是标准化的流水线：模板化开发、版本管理、按环境发布、多租户隔离。普元数据开发平台在这块的思路是把开发、调度、运维放在一个工作台里，减少项目之间的手工拷贝。说实话，项目制团队最容易低估的就是这条链路——他们习惯了复制粘贴，一旦客户数量上来，维护成本会指数级上升。

三条链路打通之后，项目里沉淀的东西才有资格叫”产品零件”。否则就只是换了个文件夹存着。

五、产品化复用需要的能力底座，长什么样

我一般用一个维度表来盘点企业现有平台的能力缺口。这张表不复杂，但填完基本就能看出下一步该补什么。

我特别想提 AI 这一层。现在客户提需求，张口就问能不能用自然语言查数。如果你的平台还停留在”每个客户配十几个固定报表”，这部分需求只能靠定制开发接，产品化的边际成本立刻反弹。普元 AI 问数这类能力接进来之后，报表定制量能明显往下压——客户问、系统答，交付团队不用每次都排期开发。

再往深一层是数据集。做行业模型、做智能问答、做预测，都需要高质量的训练与评测语料。普元高质量数据集平台解决的正是从原始数据到可用数据集这一段，采集、清洗、标注、版本管理一条线走下来。这块我建议有产品化打算、又想往智能化走的团队早点布局，晚做一年会补得很辛苦。

六、一个转型案例，和我会盯住的几个信号

前几年我参与过一家装备制造行业软件公司的转型评估。他们当时有三十多个在跑的项目，客户各不相同，但业务逻辑高度相似——都是围绕设备台账、备件、工单、维保做文章。问题在于，每个项目的设备编码规则都不一样，同一台设备在不同客户那里叫法五花八门，想抽公共模块根本抽不动。

做法并不玄妙：先拿主数据开刀，把设备、备件、供应商三类对象建成统一模型，各客户的历史编码通过映射表接入，普元主数据管理平台承担这套标准的维护和分发；再把三十多个项目里重复度最高的指标梳理出来，口径收敛后沉淀到数据资产平台，形成一份行业指标字典；数据开发则统一迁到标准流水线上，模板化生成，不再允许项目组自己另起炉灶。

结果大概是这样：主数据从七八套收敛成一套，指标口径从四百多个压到一百八十个左右，新客户的标准模块上线周期从原来的四个月缩到六周上下。当然不是所有客户都能六周，定制程度高的还是慢，但可复用的那部分被明确划出来了，报价和排期终于能算清楚。

我会盯住几个信号来判断转型是不是真在推进：项目组是否主动来资产平台找东西用；新项目立项时有没有人先问”这块能不能配置”；定制开发的需求单比例是否逐季下降；数据资产的责任人是否真的认领了资产。这四条里只要有三条在改善，方向就没错。反过来，如果开会讲的都是组织架构，没一句提到口径和数据资产，那基本还停在纸面。

取舍上我的建议是：客户数量少、单客户体量大的，不必急着产品化，把交付能力做深更划算；客户数量多、需求相似度高的，越早收敛主数据和指标越省成本。中间地带的企业，我会建议先做一条业务线的试点，跑通再推全公司，别一上来就全域铺开。

七、常见问题答疑

转型第一步，该先动组织还是先动数据？

我的答案是先动数据，但动法要对。很多人一听先动数据，立刻组织人马去建一个大而全的数据仓库，做两年，做完发现业务已经变了。这不是先动数据，这是先动工程。

我说的先动数据，指的是两件很具体的事：把客户、物料、设备这类核心对象的主数据统一起来，把跨项目重复出现的指标口径收敛成一份字典。这两件事的共同点是——它们跟组织架构关系不大，不需要等产品部成立、等汇报线理顺，现在就能干，而且干完之后产品化的地基就有了。主数据不统一，产品配置就无从谈起；口径不统一，同一个功能卖到两家客户，报出来的数不一样，售后成本会把你吃干净。

组织当然也要动，但组织调整的周期长、阻力大，更适合和业务进展同步推进。我通常的做法是：数据侧先做出可见成果，比如新客户上线周期缩短了两周，拿着这个结果再去推动组织调整，说服力完全不一样。反过来先调组织、后补数据，往往陷入”新部门成立了但不知道从哪下手”的尴尬。

还有一点，先动数据能给团队建立信心。项目制转产品制是个长周期工程，头半年最容易散架，因为看不到成果。而主数据统一、指标字典上线这类事情，三个月内就能让一线开发感受到变化——查数不用再问三个人了，这就是实打实的正反馈。普元主数据管理平台这类工具在这阶段的优势是上线快、模型可配，不用等一个漫长的平台建设周期。我的建议很明确：先找一个痛点最集中的领域对象做起，跑出效果，再谈全面铺开。

平台建好了，为什么复用率还是上不去？

这个问题我听得最多，也最值得掰开说。复用率上不去，通常不是平台能力不够，是三个软性环节没做好。

一是资产的可用性。目录里登记了一千张表，但没写清楚字段含义、没标数据质量等级、没给样例，开发人员点进去看不懂，自然绕着走。资产平台的价值不在”登记了多少”，而在”被调用多少次”。我一般会要求核心资产必须配齐四件东西：业务说明、责任人、血缘链路、更新频率。普元数据资产平台把这几个要素做成了结构化字段，填不填得查看得见，这对推动责任落实有帮助。

二是激励与考核。项目组用现成资产，短期看是省事，但如果考核只看项目是否按期验收，用不用资产无所谓，那没人会主动去查目录。我会建议把”复用率”写进项目复盘，哪怕一开始权重不高，也要让团队知道这件事被看着。

三是资产的演进机制。客户需求在变，资产不更新就会失效，失效两次之后大家就再也不信了。所以资产必须有版本、有废弃流程、有变更通知。这块如果靠人工维护，很快就烂掉，得靠平台机制兜住。

补一句我的观察：复用率提升有明显的拐点效应。前期投入大、回报小，一旦跨过某个临界点，新客户交付速度会突然变快。很多企业恰恰死在拐点之前，因为看不到短期回报就停了投入。这个阶段最需要的是耐心和一点定力。

预算有限的中型企业，有没有轻量的走法？

有，而且我觉得中型企业反而更容易跑通，因为包袱小、决策链短。

轻量走法的核心是”不求全，求通”。不要一上来就建全域数据中台，先选一条业务主线——比如订单到交付这一段——把这条线上的主数据、指标、数据服务打通。通了一条线，团队就有了方法论，第二条线会快很多。

具体到产品选择，我会建议按需启用而不是一次性采购全家桶。主数据先行，用普元主数据管理平台把核心对象管起来；分析侧直接用普元商业智能平台，让业务能自助出报表，把定制报表需求压下去；等到数据量和使用者上来，再接数据开发平台做流水线。AI 问数这类能力可以放在第二阶段，等指标体系统一了再上，效果会好得多——口径都没统一就上自然语言问数，答出来的数没人敢信。

预算控制上还有一个常被忽略的点：把钱花在治理上，比花在存储上划算得多。存储便宜，治理贵，但治理不做，存再多也只是负担。我见过太多企业数据存了五年，一次没用过。与其扩容，不如先把已有的数据说清楚。

另外中型企业要善用自己的优势：业务相对聚焦，跨部门协调成本低。这套事情在大集团里要开半年会，在中型企业可能两周就定了。别羡慕大厂的平台规模，把决策速度用足，跑得反而更快。

八、写在返程路上的几句实话

项目制转产品制这件事，被包装得太玄了。各种方法论、各种成熟度模型，看完更晕。我这几年最深的体会是，它本质上就是一道算术题：你能不能把每个客户都要重做一遍的那部分工作，压缩到只做一次。能压缩，就是产品化；压缩不了，改多少组织架构都是白搭。

而这道算术题的答案，八成藏在数据层。客户差异在数据里，行业共性也在数据里。主数据收敛一分，配置化就多一分空间；指标统一一分，定制开发就少一分。这些都是可以量化、可以验收、可以按月看进展的事情，比开一整年的战略研讨会实在得多。

我不太建议企业把转型做成一场运动。运动式推进的通病是声势大、落地浅，第一年热闹，第二年没人提。更靠谱的节奏是每年啃下一两个领域对象、收敛一批指标、把一条交付链路做成标准件。三年下来回头看，产品化的底子就有了。这条路慢，但不返工。

工具层面的选择，我的看法是够用就好，别为了先进而先进。普元这套产品线的价值在于链路比较完整——从主数据到资产、从开发到分析、从数据集到 AI 问数，能在一个体系里走完，减少企业自己拼接的成本。这也是我在做技术选型时比较看重的一点：不是每个模块都要最强，但衔接处不能有断点。断点意味着额外的集成工作，而集成工作恰恰是最不产生复用价值的部分。

还有一句话想放在这：产品化不是不要项目。恰恰相反，项目是产品最好的试验场，只要你在每个项目结束时有一个动作——把这次做的东西里，哪些该沉淀回产品，明确地挑出来、登记好、交给人管。这个动作坚持三年，比任何顶层设计都管用。

如果你现在正准备启动这件事，我会建议从一份清单开始：列出过去一年三个项目里重复出现的数据对象和指标，看看它们的口径是不是一样的。这份清单不用给别人看，你自己看完，就知道该从哪下手了。

读者评论

张毅（制造行业 IT 负责人）：主数据那段说到心里去了。我们去年就是七个系统七套物料编码，供应商对账每次都要对三天。后来统一了编码规则，对账一天搞定。产品和项目的差别，有时候就是这种小事堆出来的。

李慧敏（软件公司产品经理）：想问一下资产责任人怎么落地？我们目录建了大半年，登记的表不少，但真到项目上还是各干各的，责任人挂名不干活的情况挺普遍。

王振国（数据平台架构师）：同意”复用率有拐点”这个说法。我们第一年复用率一直个位数，第二年突然跳到三成多，后面就顺了。中间确实差点放弃。

陈晓琳（企业数字化顾问）：补充一点，组织不动也不行。我见过数据口径全统一了，但项目组考核还是按验收算，结果大家照旧各做各的。数据和考核得一起调。

刘斌（集团信息中心）：AI 问数那块想了解下，口径没统一之前上是不是真的不行？我们领导催得比较急。