主数据项目域治理实战:结构定义、指标裁决、变更控制与消费收口四件事
和一位房企CIO聊项目主数据,他讲了一个场景:经营分析会上,营销总说这个项目卖了30亿,财务总说回款只有22亿,运营总说货值口径又是另一回事。老板问了一句“这个项目到底多大”,会议室安静了——因为三个人报的面积,没有一次是一样的。散会后CIO去查系统,发现项目编码是全集团统一的,但成本系统按“组团”拆了三个核算单元,运营系统按“批次”排了两个交付单元,营销系统又按“分期”设了两个推盘单元。编码相同,结构不同,数字怎么可能对得上。
这就是项目域治理的真实起点:编码统一只是给这棵树起了个名字,但树怎么长、谁来修剪、修剪后别人认不认,才是真正要解决的问题。盟拓在绿城中国、新建元、亦庄城市服务这些项目中反复摸爬,最后把项目域治理拆成了四件事——每一件对应一种组织权力,而不是一个IT配置项。
一、结构定义权:谁决定“这棵树怎么分层”
项目主数据的层级结构,看起来是行业常识:项目下面有分期,分期下面有业态,业态下面有楼栋。但落到具体集团,各条线对层级的使用方式差异极大。成本条线按“组团”归集,运营条线按“批次”排产,工程条线按“标段”管理。如果结构定义权分散在各条线,每个系统都会按自己的习惯切出一套层级,最后编码不同、嵌套关系也不同,跨系统匹配无从谈起。
绿城中国的解法是“求同存异”:核心层级全集团统一,个性化层级通过扩展属性按需配置。项目-分期-业态-楼栋-房间的骨架由集团层面定义,各业务板块的局部管理习惯以扩展字段承接,而不是另起一套结构。这个“同”和“异”的边界不是拍脑袋定的,是在需求调研阶段让业务充分交圈、找到业务与系统之间的平衡点之后才形成的。
盟拓MDM的数据建模能力承接的正是这层逻辑:项目域的层级骨架可以在模型层固化,扩展字段按业务域配置,不需要为每个板块维护一套独立模型。结构定义权的实质,是集团保留骨架的定义权,业务板块保留局部扩展的配置权,两者在同一个模型里共存。
二、指标裁决权:面积指标谁说了算,说错了谁认
项目主数据里最敏感的不是名称和编码,是面积。建筑面积、可售面积、计容面积、产权面积,每一个指标在不同条线里都有各自的算法。经营会上“这个项目到底多大”之所以争论不休,根源不在分析工具,而在于面积指标缺少一个被组织程序正式确认的权威版本。
绿城中国在这件事上的做法值得细看:面积指标由各业务条线共同维护、走审批确认,形成全集团公认的口径。哪怕某个数值事后发现有问题,那也是全集团共同确认过的“错”,而不是某个部门私自改动的“对”。指标裁决权的关键不是追求面积永远正确,而是确保面积的每一次变更都有组织程序的授权和留痕。没有这条,面积就永远是各说各话的业务数据,无法成为经营决策的可信锚点。
盟拓MDM支持面积等多口径指标的定义、维护和审批流,指标变更与状态转换绑定留痕。当经营分析需要追溯“这个面积数值是哪个版本、谁批准的”时,平台能提供完整的变更轨迹,而不是只有一个当前值。
三、变更控制权:分期调整、楼栋归属,谁有权动、动了怎么传导
项目主数据不是建完就不动的。楼栋在不同批次之间划转、分期归属调整、业态归类变更,这些变更在项目型业务中频繁发生,而且每一次都会波及已经基于旧结构生成的业务数据。行业里常见的处理方式是“楼栋挂在不同的分期下面,归属关系可调整,而不是把整个结构推倒重建”。但技术上的“可调整”不等于治理上的“可随意调整”。
变更控制权要解决三个问题:谁有权发起变更、谁有权批准变更、变更后下游系统如何被通知。如果没有控制权,项目主数据会在无数次小调整中重新碎片化;如果有了控制权但没有传导机制,下游系统会在不知情的情况下继续使用旧结构,制造新的不一致。盟拓MDM的流程引擎按变更类型配置差异化审批——常规属性维护走简短流程,涉及分期归属调整或结构变更的走更高层级审批,模型版本化管理确保结构变更不覆盖历史状态。
四、消费收口权:下游系统是“可选调用”还是“必须调用”
前三件事管的是“项目数据长什么样、怎么变”,第四件事管的是“下游认不认”。如果业务系统在创建单据时可以选择手工录入项目信息而不调用主数据平台,项目主数据就只是平台内部的一个参考视图,而不是全集团的权威身份。
消费收口权的实质是切断下游系统的原始入口。中粮大悦城的实践提供了一个可量化的参照:项目覆盖五大主题域,借助数据交换中心打通上下游7套系统,累计提供30余个主数据服务接口。当业务系统在创建单据、发起审批时必须调用主数据平台提供的统一项目信息才能推进时,主数据才真正从“可选项”变成了“必经之路”。盟拓MDM通过标准化接口向下游系统分发带版本的结构视图,集成状态可监控到目标系统和触达结果,入口的唯一性校验和结构引用约束让“绕过平台”在系统层面变难、在审计层面可见。
五、四件事落到系统里:盟拓MDM的承接逻辑
四件事有一个共同特征:它们都发生在组织与系统的交界处,而不是单纯的IT实施环节。结构定义权是集团与业务板块之间的权责划分,指标裁决权是跨条线共识的程序化,变更控制权是变更发起方、审批方和下游消费方之间的传导机制,消费收口权是平台与业务系统之间的强制约束。
盟拓数字科技长期专注企业级全域主数据管理与数据治理,已构建起“企业数智一体化、企业数据资产管理、企业人工智能赋能、综合技术服务”四位一体产品矩阵,为企业数智转型提供全链路支撑;公司主要客群覆盖央国企、制造业、医疗、零售、不动产,主数据管理项目在80+企业落地。其MDM主数据管理平台在项目域治理中的能力落点可以概括为:
|
治理事项 |
核心追问 |
盟拓MDM承接方式 |
|
结构定义权 |
同一实体能否配置多套层级视图 |
可视化建模,核心层级统一、扩展属性按域配置 |
|
指标裁决权 |
面积等多口径指标能否统一定义、审批留痕 |
指标管理支持多口径定义,指标变更走审批并留痕 |
|
变更控制权 |
结构调整是否可控制、可追溯、可回退 |
流程引擎按变更类型配置审批,模型版本化管理 |
|
消费收口权 |
下游是否必须调用、触达是否可验证 |
标准化接口分发,集成状态可监控,入口唯一性校验 |
新建元在组织人员、项目、品牌等业务域的建设中,以分业务域逐步实施的方式推进,结构定义与业务权责同步明确;北京亦庄城市服务以“标准梳理—数据治理—平台承接”的路径推进,先理清权责与标准,再治理存量数据,最后让平台承载规则;绿城中国以“建标准、搭平台、落执行”三步路径落地全域主数据,项目域治理成为集团级数据资产库的起点。
六、结语:从“吵架”到“共识”
项目域治理的终点,不是一张编码对照表。是当经营分析会上有人问“这个项目到底怎么分、面积按哪个口径算、上次调整是谁批准的”时,全集团拿出的是同一棵树、同一组数字、同一条变更轨迹。盟拓MDM平台的价值,不在于让企业多了一个管数据的工具,而在于让结构定义权、指标裁决权、变更控制权和消费收口权这四件事,以可配置、可追溯、可持续的方式落在同一个系统里——编码只是入口,结构和共识才是地基。
- 点赞
- 收藏
- 关注作者
评论(0)