段效亮: 企业主数据中心管理与实践（六）
中国经济导报、中国发展网记者 尹明波
段效亮，中国企业数据治理联盟秘书长，国际数据管理协会会员，中翰软件创始人之一。作为国内数据治理领域资深咨询专家，段效亮拥有15年以上IT行业从业经验，12年以上数据管理咨询、平台实施、数据保养等实战经验，参与并主持中国中铁、国家核电、天保控股、青钢集团、康尼集团等几十家国内大型企业集团的数据治理项目。
段效亮还独创国内及数据治理行业内多个第一：国内首推主数据管理平台、企业数据治理平台，物资数据清洗，静态数据中心管理 ，数据协同维护管理，数据多编码体系管理，数据规划管理，数据保养等理念和方案。
段效亮领衔的中翰软件，从2012年初开始联合已经实施主数据平台的相关企业进行了深入的探究，最终提出“主数据中心”的概念和主数据动态问题的解决方案。中国发展网近期连续六期刊发这位业内“大咖”对企业数据治理中主数据中心管理与实践的认识、见解和相关建议，试图为企业数据治理领域的研究发展以及应用辅以参考借鉴。
第五章 主数据治理项目风险规避
项目风险管理是针对项目中可能发生而且一旦发生影响项目的因素进行识别、分析和管理。风险管理是“成年人的项目管理”，也就是说风险管理是在成熟的项目管理的基础上自然产生的管理需求。
第一节 风险管理办法
通用项目风险管理采用FMEA（失效模式影响分析）的方法，将风险分为风险项、风险情况、风险的影响、风险发生的可能性、风险的可检测性。每个风险使用风险优先数进行量化，风险优先数（RPN）＝ 影响 ＊ 可能性 ＊ 可检测性。影响、可能性和可检测性又进一步被细化分成1～10个等级。因此风险优先数（RPN）在1和1000之间。基于FMEA的风险管理表，如下图5-1：
图5-1 风险管理表
第二节 风险管理过程
图5-2 风险管理过程
风险管理分为风险识别、风险评估、风险跟踪三个步骤。风险评估包括：严重程度评估、发生可能性评估、可检测性评估，另外还包括风险措施的制定、风险责任人和实施计划。在项目进展过程中对制定的风险措施的实施情况进行跟踪管理，评价措施的有效性，对已经识别的风险跟踪是否已经发生，风险优先数（RPN）是否变化，是否有新的风险发生。风险的跟踪分为项目例会和在实施计划时间点进行跟踪两种情况。
第三节 风险识别
在风险的识别阶段，项目团队内召开头脑风暴会议，利用因果分析图的方法，识别出项目的风险。我们修改了基于“人机料法环测”六个方面的因果分析图，主要对客户、过程、技术、人员、环境和组织管理六个方面进行分析如图5-3：
图5-3 风险识别因果分析
第四节 项目实施风险点及规避方法
5.4.1 主数据管理体系架构方面
1. 风险点
数据管理制度不严谨，未切合本企业实际；没有配套的组织架构，对违章者约束力不够，无法强化 执行力度；数据管理流程层次不清晰，责任不明确；数据管理流程过长，导致数据新增、变更周期不可控；数据申请人、审核人权限分配不合理。
2. 规避方法
结合本企业实际制定完善的数据管理制度，并配合相关组织结构分配执行，使数据管理的执行力最大化的加强； 结合本企业情况，制定完善、规范的数据管理流程，实现不同情况下的数据新增、变更的及时性，可操作性。
5.4.2 数据建模方面
1. 风险点
由于类别的唯一性，导致制定这个主数据类别结构的周期过长，影响项目进度；由于类别参与编码导致后期主数据类别结构的调整难以实现，且主数据无法在类别间实现自由搬迁、挪移；由于主数据类别制定的周期较长且只有一个类别结构树，经常是最后将就订之，导致后期数据新增时由于不符合操作习惯或者误解而放错位置，直接造成编码重复的可控性降低；主数据编码属性信息模板的不规范、不标准，随意性太强或者太国标化，没结合本企业、本行业相关标准，导致使用人员无法对应添加相关属性值；不重视元数据管理的规范和标准，难以实现数据新增、变更时的统一、规范的数据验证实现，也难以保证数据查重的准确率；不重视非编码属性模板和业务视图的制定，导致数据传输到对应业务系统中后无法直接使用，再次维护信息增加工作繁琐程度；忽视数据模型版本的存档工作，导致版本变更前的数据无法实现依据的追踪；数据模型建好后，没有合适的系统工具实现落地，无法摆脱只建模不落地或者随便找一工具落地的传统思想；数据模型建好后，没有形成标准、规范的主数据管理手册（含编码手册），无法实现数据新增、变更时的录入规范，数据验证标准等。
图5-4 主数据和主数据中心对比
图5-5 数据建模方式对比
2. 规避方法
结合企业实际，允许主数据多类别结构树的同时存在，且允许借用原有类别结构树，以满足不同操作人员的传统习惯，减少错误的发生，同时缩短或者省去类别制定周期；需要系统工具实现类别参与编码和不参与编码（都可模拟原有编码结构）的不同管理方式，且允许一条主数据同时存在于多个类别结构树上，允许主数据类别结构树本身的自由调整和主数据在类别结构树间的自由搬迁、挪移；利用专业人员，结合国标、行标、企标制定出一套完全符合企业实际情况的编码信息模型、非编码信息模型以及业务视图模型，并实现系统落地和手册沉淀； 利用系统实现数据模型变更前后的存档工作，使所有的数据都有据可依，有法可循；重视元数据管理，制定规范、严谨的数据验证标准，并实现系统落地和手册沉淀； 从根本上转变只建模不落地，或者随意落地的传统管理思想。
5.4.3 历史数据清洗方面
1. 风险点
忽略主数据清洗的制度、流程的建立和相关权限的划分，不重视数据清洗过程中的多人协同顺序工作，使数据清洗工作无法保质保量按时完成；不重视对老数据的和质量分析、清洗建模工作，导致好的清洗策略难以很好的发挥作用；错估数据清洗的工作量和繁琐程度，严重影响参与人员的工作激情。
2. 规避方法
针对不同的主数据类型，寻找并利用专业的数据清洗工具，如物资数据等专业清洗工具；全面分析原有数据，本着逐步清洗的原则进行间断性的质量模型的建立和调整，配合数据清洗人员的顺序协同工作，最终实现老数据的模拟（完善信息）和映射（查重）工作；不定期的召开清洗工作总结和动员会议，时刻给所有参与清洗工作的人员以心理准备，防止工作热情的过早消退。
5.4.4 数据日常管控治理方面
1. 风险点
数据新增、变更时的单人录入、随意性录入，或者是故意错误输入；数据新增、变更时，现有数据多类别间的自动匹配、传输问题；单人收集并添加相关数据新增信息，导致难以追溯错误的来源；不同业务系统的视图信息分散管理，不能实现数据的集中管理，就无法实现集团层面的数据的‘单一视图’，也无法为企业的数据中心建立奠定很好的基础；借用业务系统实现数据的查重和验证，由于这些业务系统本身没有严格的数据验证，无法有效杜绝数据的重复发生；依然沿用人工查重、手工添加新增数据到各业务系统中，殊不知手工的错误率和周期更难以把握。
图5-6 数据新增过程对比
2. 规避方法
利用落地系统建立完善的基础参照数据库，供录入时参照或者选择，可直接设置为只能选择，不能手动直接录入，杜绝故意错误的发生；利用专业系统，建立自身完善的数据申请、审核、验证等机制，全面杜绝重复数据的再次发生；建立数据新增的协同完善机制，即实现多人协同、顺序、补充完善数据申请单据（如供应商信息的外部增强），使责任明确化，减少信息错误的发生率；建立健全组织架构、全业务系统的数据视图，全面集中管理管控整个企业的所有数据信息，实现集团层面的数据的‘单一视图’，为企业数据中心的建立奠定坚实的基础；实现数据多类别映射关系表的MDM落地（限定表），以便于数据新增、变更时实现数据多类别的自动匹配，并通过中翰service实现自动分发到相关目标业务系统。
5.4.5 数据交换治理方面
1. 风险点
通过业务系统和ESB实现数据的统一分发服务，因为业务系统的数据视图信息通用型不强，且无法相互包含，无法实现全面集中的数据管理；数据传输的接口的模式和机制互不相同，单独维护数据传输接口工作量巨大；依然是部分数据信息分散在各业务系统中，无法实现全公司，全人员、权限范围内的数据全面共享，直接影响生产周期，降低客户忠诚度。
2. 规避方法
利用专业的数据服务平台，建立规范、标准的数据分发机制，实现企业内数据的统一、针对性分发服务；建立企业统一的数据分发平台，标准各业务系统的分发方式、传输格式等，实现后期自由新增业务系统的数据传输；利用系统实现全企业、全员元数据层面的数据共享，真正打通企业管理各环节数据共享的各种障碍。
