基于协作服务流程的计量系统主数据管理技术研究

林尔迅

（广东电网有限责任公司中山供电局，广东 中山 528400）

0 引言

主数据构成了业务流程的基础，在业务数据处理的整个过程中，主数据代表了公司在特定时间段内保持不变的基本数据[1]，这些数据包括客户、员工、材料以及供应商的各类信息，一旦其相关主数据不一致，则会使得业务流程发生错误，从而导致更高的成本输出。但是由于目前许多公司通常使用各种应用程序来支持其服务流程[2]，因此在实际处理过程中，主数据不仅缺乏一致性，而且缺乏即时性。在这种背景下，便出现了跨系统和公司边界管理主数据的特殊解决方案和标准，各种软件供应商如SAP、Siebel和Oracle等皆在为跨系统和集成主数据管理开发新的解决方案。

1 主数据在服务中的挑战

如何确保数据质量的一致性和即时性[3]是组织间主数据管理所面临的一个普遍挑战，相关数据的不一致使得对应的操作常常出现错误的响应，从而造成流程效率低下的结果，而对该现象进行人工修正的成本往往更高，基于此，不一致的主数据集通常会造成一个公司的经济劣势[4]。

但是在服务领域，除了主数据不一致的一般缺点外，通常还需要考虑其他挑战，主要有以下几个方面：（1）客户服务必须依赖上一个服务流程的信息，如客户主数据、保修协议和产品配置等；（2）只有通过标准化流程和唯一的客户标识才能有效实现面向客户的多单位一体化展现；（3）工厂的机器组成日益复杂，只有拥有完整的主数据（如产品配置、维护历史、正确的手册版本），工程师才能快速有效地进行维修；（4）如果要得出有关服务质量和产品改进的结论，就需要对顾客的投诉和关注进行有效地评估；（5）客户查询的快速响应（特别是在呼叫中心进行应答的情况下）需要具备所有客户联系人的最新信息和透明度。

因此，在客户服务中，不一致的主数据会导致不正确的决策，并且会降低客户的满意度以及产生较高的成本。

针对此情况，可以通过将现有数据集重新协调组织成为一致的、当前的、全公司范围的主数据来挖掘出巨大的收益潜力，例如在数据一致性的前提下节约成本；提高生产力（如通过改善电子分布节省主数据创建的时间）[5]；改善客户服务，从而提高客户满意度；对可能出现的错误报告进行及时改进。

2 架构方案

在本节中，主要对主数据分布的架构备选方案进行简要说明，同时对方案下的主数据系统和跨系统存储库进行介绍。

首先必须通过集成底层信息系统来支持分布式服务流程，因为这是跨系统边界交换主数据的核心条件。为了有效创建分布式的主数据，可以在与信息管理组合作的实际项目的基础上确定4种架构方案[6]，同时在实践中也可以组合不同的方案。这4种方案可以从两个方面进行分类，一是全局主数据属性；二是数据的创建、维护和分布。架构方案的分类如图1所示。从图中可以看出，中央主数据系统数据的创建、维护和分布确保了预定义流程可以正常有效地响应，但是灵活性较差。

图1 架构方案分类Fig.1 Classification of architecture approaches

基于这种方案特点，建立一个可以将全局主数据从一个应用程序分发到各个应用程序的主数据系统，该系统下的所有子系统将全部使用相同的主数据，继而通过全局主键[7]来实现对主数据的唯一标识。

由于主数据集的全局属性总是在中央主数据系统中创建，所以数据将始终以相同的方式进行唯一创建，而且以往不在中央系统中维护的附加（本地）属性将必须在接收系统中完成。基于这种情况，中央主数据系统将只负责核心主数据的传输，其系统底层中间件则主要对密钥进行管理，因此由中央主数据系统主导发起的数据分发存在着一定程度上的异步响应，表1所示为对这种方案下主数据系统的特征进行了简要概述。

表1 中央主数据系统的特征

根据以上说明，可以知道此方案可以对数据进行集中、标准化地创建，因此，所有链接的应用程序都可以拥有相同的全局主数据。但是通常情况下，修改后的更新数据只能在一段时间后才可以获得。

对此架构方案下的主数据系统运用较为成熟的有SINFOS，其通常会提供一个中央数据池，业务合作伙伴可以通过该数据池对产品数据进行访问，然后成员可以在SINFOS数据库中创建主数据，并使用自己的系统对其进行校准，从而为公司范围内的主数据池提供更好的服务方案。

接下来，对方案下的跨系统存储库进行简单介绍。由于需要为所涉及的所有数据配置合理的跨系统存储库，因此主数据集存储包中应该包括各种主数据集到它们的源系统之间的分配数据。例如，如果应用程序需要访问某个客户的具体数据信息，其便向存储库发送一个查询请求，继而接收数据库关于该客户数据所在系统位置的反馈，最后，其相关数据将直接从对应的系统中被调用。

同时，由于分布式数据在所有涉及的系统中都是冗余的，且每个数据集都有不同的主键，因此需要通过属性的映射来确保数据可以正确传输到接收系统。通常，只有存储库接收系统中需要的属性才可以被传输，其数据集中的修改也通常是异步分布的，过程如图2所示。

图2 存储库数据调用Fig.2 Repository data invocation

方案下的存储库可以在各个应用程序中对数据集进行分散式地创建和维护，因此在系统连接过程中，数据存储是相对分散的。如果在运行场景中没有数据分布，则数据访问直接由访问系统发起。通常各个应用程序中，主数据的主键是不同的，而存储库中则拥有每个数据集的全局键，并可以对其下各个应用程序的所有主键进行管理，因此每次的数据访问都可以使存储库对主数据集进行即时性地更改订正，从而满足非常大的数据集访问需求。

通过上述介绍可知，存储库中数据的存储、创建和维护都在各个系统中分散进行，由于需要确保全局属性的标准化在每个系统中具有相同的含义，且创建的属性最少，因此需要即时向存储库进行数据的调用和反馈，从而有效避免因不能跨系统一致性检查而导致的各种应用程序响应误差，其特征如表2所示。

表2 存储库的特征

存储库方案的优点是保留了应用程序自身的自主权，使得其自身对中央系统仅有少量依赖，但是该方案仍然存在着一个问题，即不同运行过程下，数据的创建和修改是分散式的。

对跨系统存储库方案运用较为熟练的是全球商业计划的全局注册中心，该注册中心是一个国际数据库，其中包含了存储在世界各地的主数据池中的全部信息。只要接收到访问申请，便可以在各自对应的主数据池中执行对具体主数据集的访问。

3 中央主数据管理

为了更高效率地让计量数据、营销数据快速接入业务对账平台，同时减少对应用带来的性能损耗和代码侵入，本系统通过事件模式，把业务数据变化触发的消息（如DB变更日志数据，消息中间件消息）转换成响应业务的事件，放入到事件执行队列进行规则的检查，事件监听框架采用了通用的架构设计，实现了消息的对接，而DB日志又可以转接到消息上，实现数据库变更的实时监听。

本系统平台主要实现以下4个目标：

（1）高实时性地发现线上业务脏数据或者错误逻辑，第一时间发现并及时通知技术保障，而不是等客户反馈；

（2）方便地接入各种业务规则，通过脚本规则编写的方式，让各应用快速接入平台；

（3）整合订正工具，形成规范的脏数据订正流程；

（4）业务上线的实时监控，新上线业务可以很方便地进行校验。

4 结束语

本文重点描述了在服务流程中进行主数据管理所面临的具体挑战，概括了协调的主数据具有提高客户满意度以及增强流程效率等的好处，同时以某企业的案例研究为基础，说明了客户和产品主数据管理是如何支持创新服务流程的。通过本文的介绍，了解了由于软件供应商提供的产品很大程度上依赖中央主数据系统，因此主数据交换效率较慢，尽管软件供应商针对此情况为主数据的管理提供了各种体系结构方法和解决方案，以期保证主数据的一致性和即时性，但却仍不足以在不同系统之间“无故障”地交换主数据对象。因此，有必要促进各组织间的相互协作，使得主数据的组织间交换可以有效实现。