4.1 主数据项目实施的主要风险

主数据项目实施的风险包括组织管理风险、数据质量风险、数据转换风险、系统集成风险等方面。项目建设初期，组织管理风险会较为突出，这些风险包括缺少风险管理部门、缺乏风险管理体系、缺少持久稳定的运行机制、缺乏必要的规范、缺少风险管控机制、缺乏事后的总结分析、缺少对项目的考核、不重视事前控制等内容。在项目建设过程中，数据质量风险、数据转换风险、系统集成风险会较为突出，其中数据质量风险会涉及缺失的或不完整的数据、不准确的数据、不一致的数据、重复的数据、无效记录等。在数据转换过程中，由于对数据关系没有做到充分的准备，因此容易造成数据部分丢失或者整体丢失的现象。数据转换过程如果没有对某些数据进行完整性校验，则容易造成数据不完整的事故。数据转换过程中，也会带来数据的不一致性问题。在系统集成时也会出现系统多、关系复杂、系统封闭、不开放、开发平台不同、数据结构有差异等多种现象。如何规避这些风险，是主数据项目实施过程中的主要任务。

4.1.1 组织风险

在数据治理过程中，首先应建立数据治理组织。许多企业在数据治理初期，对数据治理组织没有充分的重视，随着系统的建设，管理问题不断出现，此时才意识到数据治理组织的重要性。数据治理的组织应在数据治理项目初期就得到高层领导的高度重视。

在数据治理过程中对组织风险重视程度不足的主要表现如下。

• 从事数据治理的管理组织中普遍缺少风险管理部门。

• 在实际的项目管理中，缺乏系统性的风险管理体系的建立，缺少较为持久稳定的运行机制。

• 数据治理企业缺乏必要的规范，导致工作失误与重复工作。

• 对于数据治理项目，参与各方都缺少全面的风险评估和控制机制。

• 对于已经出现的大小风险事件，缺乏事后的总结分析。

• 对项目管理机构的考核，缺少“风险管理”内容。

• 领导层对风险事件的处理，只重视事后处置，而不重视事前控制。

缺少风险控制，会导致如下问题。

• 数据治理项目大多不能按期完成，或项目实施过程中总会出现“抢工”的情况。

• 项目的成本处于失控状态，计划成本的预控性得不到发挥。

• 项目实施过程中经常出现“意外”的质量事件。虽然有些企业总结了以往的质量缺陷，制定过预控措施，但由于缺乏系统性，依然会导致质量控制目标难于实现、成本上升、进度滞后。

• 数据治理项目管理团队常常处于一种焦虑状态，缺乏信心，总有失败感，使项目团队的凝聚力下降，管理人员注意力难于集中，管理水平持续下降。

• 管理人员的管理能力并未与项目经验同步提升，将会导致管理人员流动性加大，项目管理团队不稳定，企业的项目管理时间、进度、成本受到冲击，严重者将影响企业的生存与发展。

为了避免由于组织不健全、领导不重视引起的项目风险，首先需建立健全项目管理组织，强有力的项目管理组织是项目成功的基础。主数据会一直伴随着企业的经营，大多数情况下是几十年甚至上百年不变，所以在定位上，主数据项目所涉及的主数据系统是企业级的核心基础信息系统，这也就意味着需要纳入信息管理的系统比较多，会横跨许多部门或分子公司，而大企业的各部门或分子公司往往有着自己成型的业务习惯。在推行主数据建设时，系统的需求调研、部门的协调沟通、数据清洗的烦琐步骤等工作量巨大，这是主数据项目实施过程中的难点之一。因此，需要站在集团层面统一实施、统一管理、统一协调，建立集团层面项目管理组织（PMO）。

其次，与其他管理信息系统一样，高层领导重视、参与、支持是主数据项目成功的关键。作为一个自上而下的信息化工程，主数据项目涉及的业务范围广、系统影响大、协调事项多。在各部门之间的数据应用环节，过往的纸质文件线下传递、电话沟通、“使用习惯”“不成文规定”等，都将是数据标准化建设时会遇到的“关卡”，能有一位有话语权的领导来强力支持和推行主数据项目建设将是成功的关键。因此，项目建设需要公司高层领导高度重视，并列入工作计划进行项目推动与管理，形成专门的考核评价体系，对项目团队人员进行考核，使团队成员重视项目建设，避免项目实施失败风险。

4.1.2 数据风险

有数据统计表明，雀巢公司在200个国家出售超过十万种产品，有55万家供应商，但由于数据库内容混乱，结果并未形成强大的采购议价优势。在一次检查中发现，雀巢公司的900万条供应商、客户和原材料记录中有差不多一半是过期或重复的，剩下的有三分之一不准确或有缺失。供应商名称有的简写有的不简写，产生了重复记录。在这一案例中就包含了封闭、断裂、缺失等数据问题。

封闭数据：数据增值的关键在于整合，但自由整合的前提是数据的开放，不开放的数据就是封闭数据。以新浪、搜狐、网易、腾讯四大微博的数据平台为例，四家公司的数据各自为政，相互独立，关于微博用户行为分析都是基于对自己现有用户的分析，这种封闭的数据环境下，很多层面的具体分析都将受到很大的局限，例如：如何分析重叠用户？什么特征的人群会只在一个平台上开设账号？什么特征的人会在不同平台上都开设账号？在不同平台上使用风格是否相同？在不同账号下活跃度是否相同？影响因素是什么？这是在封闭的数据环境下无法进行分析的。

断裂数据：断裂数据则使数据缺乏结构化，造成表面上全面，实际上都是片段式的数据。以淘宝为例，当淘宝想研究“究竟是什么人在淘宝上开店”的时候，并不像想象中的那么容易。在淘宝公司的实时地图上，可以利用GPS系统清晰地知道每一秒全国各地正在发生的交易，但是实时地图却不知道这些人的族群特征。同样的问题出现在腾讯游戏部门的用户研究中，研究人员并不能从实时的监测中知道是谁在玩游戏，他们有什么爱好、是什么性格、为什么喜欢一款游戏，研究人员知道的只是一个ID账号，这就是断裂数据带来的问题：表面上全面，实际上都是片段式的数据。全数据确实可以在一定程度上掌握人的行为，但是无法知道是什么样的人的行为。

缺失数据：只有有价值的数据才称得上信息，然而从数据中获得尽量多的信息并非易事。随着数据量的扩大，缺失数据产生的比例也会相应扩大，尤其当一个样本中出现多项缺失时，会显著加大处理的难度。通过构造模型可以部分克服数据的缺失，使之更加准确，但却面临计算的时间复杂度方面的问题。对所有大数据分析来讲，适用于具体问题的有效数据量都不够大，同时数据都是缺失多于正常。在数据收集和整合过程中采用新技术手段避免这一问题，将使这一问题在分析上带来的风险变得更突出，例如，BI公司为了避免数据的不完整性，采用快速修复技术整合分散数据，这将失去最原始的真实数据，使得研究者很容易舍弃与假设不符合的数据，也使验证结论变得不再可能。

1. 数据质量风险

数据质量风险主要发生在主数据项目建设初期，由于数据来源众多，种类繁杂，会存在不少的数据质量问题。由于原始的数据是集成人员从被集成信息系统中获得的，这些源数据可能存在几种情况：一是有些列的数据对数据集成是无意义的；二是对那些有意义的数据，可能又存在缺失的或不完整的数据、不准确的数据、不一致的数据、重复的、无效的记录等问题。这些有质量问题的数据会影响后续的分析结果。针对数据质量问题，集成人员要首先进行评价。

数据质量的主要评价指标如下。

• 准确性：数据值与假定正确值的一致程度。

• 完整性：需要值的属性中无值缺失的程度。

• 一致性：数据对一组约束的满足程度。

• 唯一性：数据记录（及码值）的唯一性。

• 有效性：维护的数据足够严格，以满足分类准则的接受要求。

凡是有助于提高数据质量的过程都是数据清洗过程。数据清洗是面向数据和计算机集成中的重要一环。检查、控制和分析数据的质量，在数据质量问题上发现集成线索，清洗有质量问题的数据，为后续的数据分析服务，是面向数据的计算机集成的技术重点。数据清洗工作主要包括确认输入数据、修改错误值、替换空值、保证数据值落入定义域、消除冗余数据、解决数据中的冲突等。

• 解决不完整数据（即值缺失）的方法：大多数情况下，缺失的值必须手工填入。某些缺失值可以从本数据源或其他数据源推导出来。

• 错误值的检测及解决方法：用统计分析的方法可识别可能的错误值或异常值，如偏差分析、识别不遵守分布或回归方程的值，可使用简单规则库（常识性规则、业务特定规则等）检查数据值，可使用不同属性间的约束或使用外部数据。

• 不一致性的检测及解决办法：可定义完整性约束用于检测不一致性，或通过分析数据发现联系。

• 重复的数据解决办法：可通过在数据库中建立主键，定义数据记录（及码值）的唯一性。

2. 数据转换风险

通过数据清洗以后的数据就可以进行数据转换了。数据转换是数据治理过程中的一项复杂工程，如果方法不得当，则容易造成数据丢失。有机构研究表明，主数据关联的业务数据，丢失300MB的数据，对市场营销部门就意味着13万元人民币的损失，对财务部门就意味着16万元人民币的损失，对工程部门来说损失可达80万元人民币。如果丢失的关键数据在15天内仍得不到恢复，企业就有可能被淘汰出局。对企业数据转换造成的丢失，将意味着更大的损失。数据转换过程中的几种风险包括数据丢失、数据不完整、数据不一致等几种。

（1）数据丢失。主数据与各个业务系统有紧密的关联关系，数据转换过程中，由于对数据关系没有做到充分的准备，容易造成数据部分丢失或者整体丢失的现象。主数据对于日常业务运作数据及领导层决策数据都起着至关重要的联系作用，一旦不慎丢失，将会造成不可估量的损失，轻则辛苦积累起来的心血付之东流，严重的会影响业务的正常运作，给生产造成巨大的损失。为了避免数据丢失，在数据处理前必须做好数据备份工作。一种简单的方案就是执行基于磁带或硬盘的备份，并执行恢复。不过，类似平移迁移，备份和恢复在及时恢复服务方面提供的能力很有限。另外，备份和恢复并不是最适合数据迁移的理想方法，它更适合数据恢复方案有限的灾难恢复这种场景。

为了避免数据丢失，在数据迁移处理前要做好充分的准备。

• 前期的环境调研工作必须充分：环境调研包括源数据库环境、版本、数据量大小、业务场景、操作系统版本、源数据库环境与目的数据库环境的差异等。

• 迁移方案准备，尽量优化细节，预留充分的备份时间窗口：最好能在测试环境测试其可行性以及实际耗时后，再到生产环境中实施。有时工作中碰到过实施时间安排的貌似很合理，结果实施过程中的第一步操作延误，造成系统停顿了好久时间。

• 方案一定要扎实、全面，一定要有回退方案或者保底方案：确保数据备份，回退可行，不能存在侥幸心理，以免发生当数据迁移失败紧急回退时才发现源数据库竟然无法启动，不得不再对源数据库进行回退操作的情况。

• 有条件的，一定要各方面的专家给予现场支持：数据迁移一般是晚上实施，需保证人员角色齐备，最好是A/B角一起参与，以免晚上精神不好，敲错指令。最好是主机工程师和存储工程师都在。

（2）数据不完整。如果数据库中存储有不正确的数据值，则该数据库称为已丧失数据完整性。数据转换过程中，如果没有对某些数据进行完整性校验，由于转换关系不正确，容易造成数据不完整的事故。因此，在数据转换过程中，应对数据做好充分前期校验工作。数据库采用多种方法来保证数据完整性，包括外键、约束、规则和触发器。系统应很好地处理这四者的关系，并针对不同的具体情况用不同的方法进行，相互交叉使用，相补缺点。

完整性约束主要有实体完整性约束、参照完整性约束、函数依赖约束、统计约束4类。

• 实体完整性约束：实体完整性是指一个关系中所有主属性（即主码的属性）不能取空值。所谓“空值”就是“不知道”或“无意义”的值。如主属性取空值，就说明某个不可标识的实体，这与现实世界的应用环境相矛盾，因此这个实体一定不是完整的实体。

• 参照完整性约束：参照完整性约束是指参照关系中外码的取值或者是空值（外码的每个属性均为空值），或者是取被参照关系中某个元组的主码值。

• 函数依赖约束：大部分函数依赖约束都是隐含在关系模式结构中，特别是规范化程度较高的关系模式（如3NF）都由模式来保持函数依赖。在实际应用中，为了不使信息过于分离，一般不能过分地追求规范化。这样在关系的字段间就可以存在一些函数要显式地表示出来。

• 统计约束：即某个字段值与一个关系多个元组的统计值之间的约束关系。如本部门经理的工资不得高于本部门职工平均工资的5倍。其中职工的平均工资值是一个统计计算值。在许多场合，统计数据往往可以公开，而个别数据却是保密的，但是个别数据值可以从统计数据推断出来，所以要采取一定的防范措施防止数据泄密。

（3）数据不一致。信息系统的多样性带来了数据不一致性。开展计算机集成必然面临各式各样的迥然相异的被集成单位的信息系统。被集成信息系统的差异，必然给集成工作带来数据的不一致性问题。数据的不一致性大体有以下表现形式。

• 同一字段在不同的应用中具有不同的数据类型。

• 同一字段在不同的应用中具有不同的名字，或是同名字段，具有不同含义。

• 同一信息在不同的应用中有不同的格式。

• 同一信息在不同的应用中有不同的表达方式。

对于这些不一致的数据，必须进行转换后才能供主数据平台分析之用。数据的不一致性是多种多样的，对每种情况都必须专门处理。

解决数据不一致的问题，需要进行数据转换。所谓数据转换，从计算机集成的需求来讲，主要包括两方面的内容：一是将被集成单位的数据有效地装载到主数据平台所操纵的数据库中；二是明确地标识出每张表、每个字段的具体含义及其相互之间的关系。

数据转换的第一步工作，是数据的有效性检查。为避免数据冗余和差错，在转换之前，应该对数据进行有效性检查，如果没有进行数据有效性检查，就有可能破坏主数据平台处理所需的完整性。检查数据有效性的最好方法是获得被集成单位的有关人员（包括具有技术专业知识和业务专业知识的人员）的帮助。

在有效性检查完成后，就要进行数据的清除和转换。所谓清除，指的是去掉那些与集成目的无关的数据，而仅仅将集成工作所关注的那些数据采集过来。数据转换有以下几种基本类型。

1）简单变换

• 数据类型转换：最常见的简单变换是转换一个数据元的类型，这是将一种类型的数据转换成另一种类型的数据，数据转换的前提是类型相容。类型相容指的是一种类型数据的值域可以通过常用的转换函数映射到另一种类型的值域上，这种映射不会丢失数据的精确度。类型相容的转换被认为是合适的转换，如整型到文本型转换；类型不相容的转换是不合适的转换，如文本型到整型的转换。

• 日期／时间格式的转换：因大多数系统都采用许多不同的日期和时间格式，所以在主数据平台中几乎都要进行日期和时间格式的转换，将它转换成主数据平台处理所需的统一格式。这可以通过手工程序编码来完成，它能把一个日期或时间字段拆成几个子部分，再将它们拼成想要的格式和字段。然而，大多数主数据平台中的数据导入和转换工具都提供了日期和时间格式之间转换的设置，采用手工编码的情况就比较少了。

• 代码转换：在业务数据库建立代码是为了节省数据库存储空间并提高计算机的处理效率。这些代码一般是系统管理员设置，由应用程序维护的。这给主数据平台处理带来了很大的不便。有两种方法可以解决这一问题，如果主数据平台中采用了代码设计，而被集成单位的代码能够满足主数据平台需要的，可以将被集成单位的代码表转换到主数据平台的代码表上来；如果集成单位的代码不能满足主数据平台的需要，就必须根据主数据平台的要求对它重新编码。

• 值域转换：值域转换是将一个字段的全部或部分取值映射到另一个字段的全部或部分取值上。

2）数据清洗

数据清洗指的是比简单变换更复杂的一种数据变换。在这些变换中，要检查的是字段或字段组的实际内容而不仅是存储格式。清洗是检查数据字段中的有效值，这可以通过范围检验、枚举清单和相关检验来完成。

• 有效值：范围检验是数据清洗的最简单形式，这是指检验一个字段中的数据以保证它落在预期之内，通常是数据范围或日期范围。枚举清单也相对容易实现。这种方法是对照数据字段可接受值的清单检验该字段的值。相关检验复杂一些，因为它要求将一个字段中的值与另一个字段中的值进行对比，看它们是否满足一定的相关关系，当然，数据清洗规则往往是这些不同方法的结合。

• 复杂的重新格式化：数据清洗的另一种主要类型是重新格式化某些类型的数据。这种方法适用于将许多不同方式存储在不同数据来源中的信息转换成主数据平台所要求的统一的表示方式。最需要格式化的信息之一是摘要信息，由于没有一种书写摘要的标准方式，所以同一个内容的摘要可以用许多不同方式表达出来，这就要求将摘要解析成几个组成部分，然后再将这些组成部分进行转换并重新排列成一个统一的格式。

4.1.3 集成风险

经过专家组多次研讨和商定，建立完成了符合企业需求的主数据管理体系之后，就将进入系统集成阶段，目的是将确定无误的主数据推送到各个业务系统（如OA、HR、ERP等）中去使用，这时就涉及技术开发层面的系统集成和调试了。

在系统集成环节，主数据项目负责人的主要职责是协调各个信息系统厂商的工作进度，尤其是要集成多个信息系统时，各开发团队需要互相配合进行系统集成和调试。对关键时间节点企业要予以把控，及时跟进和督促各个厂商的工作进展，以保障建设工期按时按要求完成。

在系统集成过程中会涉及多个源系统，对于各个源系统的数据来源都可能是异构的，因此在集成的过程当中需要应用到一些数据库的工具来不断地增加其产品的稳定性和可靠性等。另外，数据资源的浪费现象也是相当严重的，在很大程度上会造成系统数据的丢失，其中包括了信息资源的丢失和信息资源结构的丢失两种现象。前者还可以利用数据备份和恢复及技术；但是如果发生了后者的丢失现象，就需要花费较大的精力。系统集成时主要的风险体现在系统多、关系复杂；系统封闭、不开放；开发平台不同、数据结构有差异。

针对集成过程中出现的风险，建议采取如下措施预防。

• 需要对其数据的应用做出严格的集成规定，对其数据在应用方面所产生的工作进行不断地优化，在业务运营方面可以再根据实际情况来建立一个相对独立的业务运营系统，来实现数据信息的存储，最大限度地将企业内部的信息形成一个较为集中的集成系统。在这个过程当中，需要对内部众多分散的业务系统和数据系统进行不断地优化，对数据进行一个有效的集中集合，针对分散的数据做一个全面的调整，最终实现对数据有效、科学的处理，避免出现数据冗余的现象。

• 针对数据分散问题找到有效的解决方式，需了解其数据集成方式带来的风险，如单一系统数据质量问题、数据缺失、错误数据非空、唯一数据关联完整性。在对跨系统数据进行处理的时候，其质量的问题会导致一定程度上的数据偏差。除此之外，在历史遗留的数据方面也会存在一定的数据集成风险，会对数据的协调性问题造成一定程度的影响。

• 遗留系统在管理方面存在着一系列的问题，集中体现在数据质量缺乏专门的数据管理组织与相关的制度及规范方面，从而使得对数据质量的改善仅仅依靠于临时的或者偶尔的数据清理行为。有时，会呈现出子系统数量众多且数据分散的现象，在此种情况下，需要对数据的质量问题做出严格的分析，如数据准确性小、数据完整性不够、数据冲突等，为此可以成立一个专门的数据质量核查小组来对数据质量做出严格审核，最终最大限度减少由于数据造成的数据风险等，为以后的项目运行提供必要的实践指导意义。

• 在数据的集成过程中，不能简单地把有质量问题的数据抛弃，因为这些数据中有可能蕴涵集成线索。首先要根据数据质量的要求，对数据进行检查，对发现的数据质量问题进行分析，找出造成问题的原因，发现隐含的集成线索；然后清洗有质量问题的数据。清洗的目的是为后续的数据分析做准备，有问题的数据会给数据分析工作带来错误。

4.1.4 其他风险

主数据项目实施的风险包括组织管理风险、数据质量风险、数据转换风险、系统集成风险等方面。在数据治理项目实施过程中，企业内部还可能存在以下风险。

• 仅通过企业内部调研各专业的需求难度较大。单单依靠信息部门的力量来了解企业领导、业务部门、基层单位和网点对数据的具体需求的工作实施较为困难，需要专业的团队配合信息部门进行调研、分析，通过了解模糊需求，然后采用业界成熟的方法和手段，抽丝剥茧，逐渐明确最终的数据需求。措施：专业团队介入、明确数据需求。

• 治理任务会对工作人员的主要任务造成影响。由于企业涉及的数据量非常大，如果对所有的数据全部铺开进行治理，需要全企业的各方资源进行倾斜，必然会对其他工作的进展造成影响，因此，一般会选取解决当前业务部门要求强烈的关键数据质量问题为着力点，倒推出其数据来源的问题进行重点整治，在该类数据治理得到价值体现后，再总结治理经验，然后逐步开展其他类型数据治理。措施：关键问题引领、先试点后推广。

• 企业缺少丰富经验的数据建模专家。数据标准化管理必须和各系统大量的数据模型打交道，从标准化要求的角度，分析该类数据包含的所有信息要素的技术定义，并进行对应逻辑数据建模和物理数据建模。此项工作的工作量非常巨大，建议在数据治理平台实施的同时，一方面引入业界有丰富经验的数据建模专家加以辅导和帮助；另一方面对各系统数据模型汇总分析求同存异，一步步形成企业数据标准的技术定义数据模型。措施：引入建模专家、建立数据标准。

• 治理权责归属会涉及各自的利益冲突。分析各类数据资源的业务和系统治理权责归属，此项工作可能涉及的利益冲突非常强烈，需通过项目实施过程中建立管控机制，让治理主体在背负一定责任的同时也能享受到对应的利益。措施：建立管理机制、责任利益共存。

• 多数据源同时治理时需要企业有预算支持。数据治理工作可能需要对各个数据源系统进行标准化及质量提升的改造。此项工作复杂度较高，在确定需改造的源系统后，各个源系统的管理部门应及时评估改造工作量及费用预算，这些工作后续通过项目立项的方式来实施，企业应给予充分的资源支持，而数据治理的责任主体对于这些项目的建设过程要负责全程跟踪和控制。措施：多数据源系统、共同参与治理。

站在项目开发与实施角度，主数据项目还有以下常见的几种风险。

• 需求风险：需求已经成为项目基准，但需求随时变化；需求定义欠佳，而进一步的定义会扩展项目范畴；产品定义含混的部分比预期需要更多的时间；在做需求调研时客户参与不够；缺少有效的需求变化管理过程。

• 计划编制风险：计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；计划是优化的，是“最佳状态”，但计划不切实际，只能算是“期望状态”；计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；产品规模（代码行数、功能点）比估计的要大；完成目标日期提前，但没有相应地调整产品范围或可用资源；涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

• 开发环境风险：设施未及时到位；设施虽到位，但不配套，如没有电话、网线、办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具。

• 设计和实现风险：设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。

• 过程风险：大量的纸面工作导致进程比预期的慢；前期的质量保证行为不真实，导致后期的重复工作；缺乏对软件开发策略和标准的遵循，导致沟通不足，质量欠佳，甚至需重新开发；教条地坚持软件开发策略和标准，导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。