主数据管理与实施策略文档格式.docx
《主数据管理与实施策略文档格式.docx》由会员分享，可在线阅读，更多相关《主数据管理与实施策略文档格式.docx（19页珍藏版）》请在冰点文库上搜索。
图2.主数据管理的信息流
一般来说，主数据管理系统从IT建立的角度而言都会是一个相对复杂的系统，它往往会和企业数据仓库/决策支持系统以及企业的各个业务系统发生关系，技术实现上也会涉及到ETL、EAI、EII等多个面，如图2所示，一个典型的主数据管理的信息流为：
1某个业务系统触发对企业主数据的改动；
1主数据管理系统将整合之后完整、准确的主数据分发给所有有关的应用系统；
1主数据管理系统为决策支持和数据仓库系统提供准确的数据源。
因此对于主数据管理系统的建立，要从建立初期就考虑整体的平台框架和技术实现。
以客户主数据为例，常见的主数据域包括：
∙Party：
参与。
参与包含的围是所有与企业发生了或者发生过正式业务关系的任合法的实体，比方填写了投保单的参与。
Party是分类别的，可以是个人、机构和团体。
对于Party来说，因为开展业务的需要，可能要对他们进展分级、分类，比方VIP，黑等。
个人包括个人根本属性、个人名称、职业、性别、教育等自然属性；
机构是指在法律上有登记的组织实体，可以分为政府机构、商业机构、非盈利机构等类别；
团体可以有多种形态，比方他们可以是家庭、兴趣小组、某个大机构中的一局部，或者通过某种数据分析技术得出的客户细分群体。
∙PartyRole：
参与在业务中扮演的角色。
例如，对于保险行业而言，可以有：
投保人，被保人，受益人，担保人，报案人，核保人，查勘员，核赔人等。
∙Relationship：
Party与Party之间的关系,例如可以是：
夫妻关系、父子关系、母女关系、兄弟姐妹关系、总（母）公司分（子）公司关系、企业事业单位隶属、上下级关系等。
∙Account：
XX是客户使用企业效劳的付费实体。
∙Location：
Location记录的是每个Party可能拥有的所有，地址的类别包括邮寄地址、email地址、电信联络地址等。
∙Contract：
Party与企业之间的契约。
主数据有几个鲜明的特点，其中包括：
它是准确的、集成的，其次它是跨业务部门的，再有就是它是在各个业务部门被重复使用的。
主数据管理的意义
图3.主数据管理的要素
如图3所示：
集成、共享、数据质量、数据治理是主数据管理的四大要素，主数据管理要做的就是从企业的多个业务系统中整合最核心的、最需要共享的数据〔主数据〕，集中进展数据的清洗和丰富，并且以效劳的式把统一的、完整的、准确的、具有权威性的主数据分发给全企业围需要使用这些数据的操作型应用和分析型应用，包括各个业务系统、业务流程和决策支持系统等。
主数据管理使得企业能够集中化管理数据，在分散的系统间保证主数据的一致性，改良数据合规性、快速部署新应用、充分了解客户、加速推出新产品的速度。
从IT建立的角度，主数据管理可以增强IT构造的灵活性，构建覆盖整个企业围的数据管理根底和相应规，并且更灵活地适应企业业务需求的变化。
以客户主数据为例，客户主数据是目前企业级客户普遍面临的一个问题，在大多数企业中，客户信息通常分散于CRM等各个业务系统中，而每个业务系统中都只有客户信息的片断，即不完整的客户信息，但却缺乏企业级的完整、统一的单一客户视图，结果导致企业不能完全了解客户，无法协调统一的市场行为，导致客户满意度下降，市场份额减少。
因此，建立客户主数据系统的目的在于：
∙整合并存储所有业务系统和渠道的客户及潜在客户的信息：
一面从相关系统中抽取客户信息，并完成客户信息的清洗和整合工作，建立企业级的客户统一视图；
另一面，客户主数据管理系统将形成的统一客户信息以播送的形式同步到其他各个系统，从而确保客户信息的一致；
∙为相关的应用系统提供联机交易支持，提供客户信息的唯一访问入口点，为所有应用系统提供及时和全面的客户信息；
效劳于OCRM系统，充分利用数据的价值，在所有客户接触点上提供更多具有附加价值的效劳；
∙实现SOA的体系构造：
建立客户主数据系统之前，数据被锁定在每一个应用系统和流程中，建立主数据管理系统之后，数据从应用系统中被释放出来，并且被处理成为一组可重用的效劳，被各个应用系统调用。
主数据管理系统与数据仓库系统的关系
主数据管理系统与数据仓库系统是相辅相成的两个系统，但二者绝不是重复的，也不是互斥的。
它们有很多共同之处：
∙首先二者对企业都具有一样的价值，可以减少数据冗余和不一致性、提升对数据的洞察力，二者都是跨部门的集中式系统；
∙其次二者都依赖很多一样的技术手段，都会涉及到ETL技术、都需要元数据管理、都强调数据质量；
∙第三就是二者建立手段类似，都需要数据治理的规作为指导、都需要不同系统、不同部门的协作、需要统一的平安策略。
但是，主数据管理系统和数据仓库/决策支持系统二者之间也存在很多不同：
∙处理类型不同：
主数据管理（MDM）系统是偏交易型的系统，它为各个业务系统提供联机交易效劳，系统的效劳对象是呼叫中心、B2C、CRM等业务系统；
而数据仓库是属于分析型的系统，面向的是分析型的应用，是在大量历史交易数据的根底上进展多维分析，系统的使用对象是各层领导和业务分析、市场销售预测人员等；
∙实时性不同：
与传统的数据仓库案的批量ETL式不同，主数据管理系统在数据初始加载阶段要使用ETL，但在后续运行中要大量依赖实时整合的式来进展主数据的集成和同步；
∙数据量不同：
数据仓库存储的是大量的历史数据和各个维度的汇总数据，可能会是海量的，而MDM存储的仅仅是客户和产品等信息。
虽然主数据管理系统和数据仓库系统异同共存，但是二者却有着严密的联系，并且可以互为促进、互为补充。
举例而言，数据仓库系统的分析结果可以作为衍生数据输入到MDM系统，从而使MDM系统能够更好地为操作型CRM系统效劳。
以航空公司为例，客户的主数据模型大致可以分为三局部：
首先包括客户根本信息和偏好信息。
∙客户根本信息：
o个人及公司信息
o消费者市场状况
o常旅客会员卡号，状态，及累计里程等
o客户间关系（个体-个体，个体-公司）
o，包括，电子等
∙客户偏好信息：
o餐食偏好
o是否吸烟
o座位偏好
o机型偏好
o公务舱位偏好
o旅行舱位偏好
o休息室效劳偏好
除了这两局部之外，我们还可以从数据仓库系统中提取相关的信息，作为客户主数据的衍生信息局部，从而更好地、全位地描述客户特征，这些可以包括：
∙衍生信息：
o本月飞行里程
o年度飞行里程〔最近12个月〕
o提前预订倾向
o习惯预订模式
o使用自主效劳倾向
o上次预订使用的信用卡号
o累计/本月转签/取消航班次数
o转签航班倾向
o取消航班倾向
oNoShow倾向等。
主数据管理系统和ODS的关系
在某些情况下，主数据管理系统和ODS系统可能容易被混淆，确实，从实时上来看，主数据管理系统和ODS系统存储的都是实时数据，但是二者存储的数据容是全然不同的，主数据管理系统中不存储交易数据，比方银行客户的交易流水信息是不应该放在主数据管理系统中进展管理的，这与MDM与ODS的一个很大区别。
举一个航空公司的例子，比方某个客户在电子商务上定了一机票，产生一个订单，然后他又通过呼叫中心要求改签，这个场景中，两个系统之间要实现客户信息和订单信息的共享，其中客户信息共享通过MDM系统来实现，而订单信息那么需要采用ODS或其它手段进展共享，我们是不推荐把此类信息交由MDM系统来管理的。
回页首
主数据管理解决案介绍
目前业界比拟常见的主数据管理解决案主要可以分为三类：
∙第一是依托专业套装软件来实现主数据管理，这类案是作为套装软件的一局部，主要是为套装软件的其它模块提供效劳的，因此，通常功能都缺乏完善性。
∙还有一类是侧重于分析型应用的主数据管理，这类案在数据实时同步以及面向交易型应用时通常缺乏整体案的完整性。
∙再有一类就是专注于主数据管理的中立的、完整的解决案，这一类应用独立于套装软件，不仅具有整体架构的完整性和先进性，从功能上讲往往也最为完善，除了具有比拟完整的数据模型（DataModel）之外，还会提供广泛的集成性，具备先进的机制实现数据同步，并且可以对外提供多种预置的主数据效劳被外部交易系统调用，从而使系统具有很强的实时操作性，同时还强调主数据管理、主数据质量控制以及主数据维护的手段和规性。
企业主数据管理系统逻辑架构
一个完整的主数据管理解决案的逻辑架构应如下列图所示：
图4.主数据管理系统逻辑架构
在一个完整的主数据管理解决案中，除了主数据管理的核心效劳组件之外通常还会涉及到企业元数据管理、企业信息集成、ETL、数据分析和数据仓库以及EAI/ESB等其他各种技术和效劳组件。
其中主数据管理效劳又包括如下一些主要的效劳组件：
∙InterfaceServices：
为企业中需要主数据的所有业务系统提供各种效劳接口，通过实时的、批量的接口可以读取或者修改主数据，这些接口包括Batch,WebServices,XMLInterface,MessagingInterface,Publish/Subscribe,Import/ExportServices,DataStandardizationInterface,DirectoryIntegration等。
除了这些标准的技术接口之外,对于某些专有系统还提供适配器（Adapter）接口,通过适配器接口可以和一些特有的系统做接口，例如企业中的传统（Legacy）应用系统或者SAP等打包应用。
∙LifecycleManagementServices:
履行针对主数据的CRUD操作，执行对主数据存储库中的数据进展更新、存取和管理时的业务逻辑，除此之外，它还负责维护主数据的衍生信息，例如客户之间的关系、客户的偏好、客户在各种客户效劳渠道上的行为轨迹等。
LifecycleManagementServices贯穿整个主数据管理的生命期，它利用DataQualityManagementServices来确保数据质量、利用MasterDataEventManagementServices来捕获各种主数据变化等相关的事件，以及利用HierarchyandRelationshipManagementServices用来维护数据实体之间的关系和层次。
∙DataQualityManagementServices：
确保主数据的质量和标准化，这在主数据管理解决案中一个非常重要的组件，在我们从各个业务系统获取数据之后，要对数据进展清洗和验证，例如对于地址而言，要弥补地址的缺失、地市的缺失、的缺失、进展地址的标准化等。
对于其他数据要进展非空检查、外键检查、数据过滤等。
然后要对数据进展匹配/重复识别、自动进展基于规那么的合并/去重、穿插验证等，并且还要遵从企业的数据管控规和流程。
它可以是MasterDataManagementServices的一个部组件，也可以调用整个企业的InformationIntegrityServices来实现。
∙AuthoringServices：
依据数据管控流程，定义和扩展企业的主数据模型。
∙HierarchyRelationshipandManagementServices：
定义数据实体的层次（Hierarchy）,分组（Grouping）,关系（Relationship）,版本（Version）等。
∙MasterDataEventManagementServices：
捕获事件并且触发相应的操作，包括事件发现、事件管理和通知功能，它在主数据管理系统和业务系统之间进展数据同步时起到至关重要的作用。
∙BaseServices：
提供通用效劳，包括平安控制、错误处理、交易日志、事件日志等功能。
∙MasterDataRepository:
主数据存储库，包括Metadata,MasterData,HistoryData,ReferenceData等。
下面我们介绍两个这些逻辑组件之间的协作场景：
图5.场景1--初始数据加载
场景1：
初始数据加载：
1源数据从外部业务系统及EDW系统过批处理式拷贝到磁带；
1数据被加载到StagingDB，进展数据质量分析；
1DataQualityManagementServices对数据进展清洗、匹配、标准化等；
1ETLTransformandLoadservices对合格数据进展转换并准备好加载数据；
1MasterDataInterfaceServices接收批处理更新请求，调用LifecycleManagementUpdateService进展数据的批量更新；
1LifecycleManagementUpdateService调用Hierarchy&
RelationshipManagementServices和BaseServices更新主数据库。
图6.场景2--主数据库更新，然后同步到各业务系统
场景2：
主数据库更新，然后同步到各业务系统
1某业务系统发起一个创立主数据的交易，该业务系统将交易数据以消息的形式发送到消息队列；
1MDMInterfaceServices捕获该消息，进展消息解析，并调用SecurityandPrivacyServices进展权限验证；
1MDMInterfaceServices调用LifecycleMgmt.UpdateService；
1LifecycleMgmt.UpdateService再调用DataQualityManagementServices进展数据的清洗和标准化；
1UpdateService调用SearchServices发现该主数据已经存在，确认这是对已有主数据的更新操作；
1UpdateService通过调用外部系统对数据进展扩大；
1UpdateService在更新主数据库之前调用EventManagementServices；
1EventManagementServices确认是否需要涉及数据管控面的处理；
1UpdateService调用Hierarchy&
RelationshipManagementServices并且更新主数据库；
1AuditLoggingServices纪录相应交易日志和历史数据；
1MDMLifecycleManagementService调用MDMInterfaceServices返回更新处理请求；
1源业务系统接收到处理请求之后，利用MDM系统发回来的数据对本地的应用系统数据库进展更新操作；
1其他所有需要主动被更新的相关的业务系统都会接收到更新后的最新数据。
IBM主数据管理解决案
IBM的主数据管理解决案InfoSphereMasterDataManagement是IBM信息管理大家族的一员。
图7.IBMInfoSphereMDMServer产品构成
如上图所示，IBMMDMServer包含：
∙Knowledge（知识层）：
知识层包括当事（人员和组织）、角色、地址位置、当事人属性〔统计学信息〕、关系、财务简档、多渠道集成、协议和产品、事件等。
Action〔交互层〕：
MDMServer本身就是按照SOA的体系构造设计的，它提供700多个开箱既有的效劳接口，这些效劳可划分为多个主题围，如下列图所示：
图8.MDMServerBusinessServices其中主要包括：
o当事人口统计学效劳：
o角色：
一个当事可以扮演一个或多个角色，如XX角色效劳用于管理当事在一个或多个XX中扮演的多个角色，折扣或索赔角色效劳用于维护当事在一个或多个折扣或索赔中扮演的角色的信息。
o关系效劳：
维护当事对当事关系，当事对当事关系不仅可以存在于两个独立的当事之间（例如甲和乙是配偶），也可以存在于双在某个XX中扮演的角色围之（例如甲是乙遗嘱的执行人）。
o位置效劳：
维护关于位置的数据，如地址和联系式。
o客户效劳和销售效劳：
包含管理多渠道集成所需要的客户效劳与销售信息的综合业务效劳。
例如：
隐私效劳用于维护数据管理与请求的默认隐私偏好以及客户声明的隐私偏好；
偏好效劳用于管理复杂的客户效劳偏好（比方，特定联系法和特定产品的联系偏好）。
o协议和产品效劳：
XX或合同效劳用于维护某个XX或合同的详细信息，这里合同定义为一个或多个当事与公司的合法协议。
o数据维护效劳：
MDMServer提供重复嫌疑管理效劳,进展当事记录的合并等。
o当事财务简档：
比方收入来源信息、财务XX信息等。
o当事识别效劳：
为每个客户记录创立一个唯一客户ID，并且维护对其它系统的穿插引用。
o历史纪录和审核效劳：
包含检索对象的历史审核数据的效劳。
∙Integrity（完整性层）：
完整性效劳用于管理数据质量和维护客户数据的单一版本，包括疑似处理、重复处理、数据检查、标准化等。
∙Intellegence（智能层）：
包括事件管理、业务处理规那么、数据平安性。
∙DataGovernance（数据管控层）：
管理数据实体间的关系（Relationship）,分组（Group）,层次（Hierarchy），以及数据生命期等。
∙ServiceInteface（接口层）：
MDMServer支持多个实时和批处理接口，其中实时接口包括XML接口、WebServices接口、消息接口、Java对象接口、COBOL和CICS接口等。
此外，还支持用户自定义接口。
使用IBM全套解决案的主数据管理案例
以下是一个使用全套IBM软件解决案的案例，这是一个典型的客户主数据管理的应用场景，其中使用的产品包括：
WebSpherePortalServer，WebSphereMDMServer，WebSphereEnterpriseServicesBus,WebSphereQualityStage,DB2等。
图9.主数据管理应用案例
图9描述了一个主数据管理应用的端到端流程：
1业务系统通过自己的用户界面创立一个新的用户，并且把数据写入了其应用系统数据库中；
1该业务系统向MQ发送一条XML消息；
消息中包含了客户根本信息和策略信息；
1MDMServer接收到该MQ消息，对此消息进展处理；
1MDMServer通过与QualityStage的接口调用WebSphereQualityStage的效劳，进展客户XX和联系式的清洗和标准化；
1WebSphereQualityStage对客户XX和联系式的清洗和标准化；
1WebSphereQualityStage返回标准化了的客户数据；
1MDMServer接收到标准化了的客户XX和地址，查询主数据库获取候选XX，调用QualityStage的疑似匹配效劳；
1QualityStage进展疑似处理；
1QualityStage将打分结果返回给MDMServer，结果说明这是一个新客户；
1MDMServer向某外部系统发出WebServices请求，进展数据扩大；
1外部系统将结果返回MDMServer；
1MDMServer分配一个唯一的PartyID，并且将客户主数据写入MDMServerDB；
1根据客户Profile，MDMServer发现该客户是新推出的一项新业务的目标客户；
1MDMServer向MQ产生一条XML/JMS消息；
1WebSphereESB接收到XML消息并且将其转换为市场促销系统所需要的消息格式；
1市场促销系统接收到该消息，进展相应的业务处理；
1MDMServer产生XML交易响应信息给源业务系统；
1源业务系统接收到响应信息，对其应用系统数据库进展更新；
1MDMServer又产生一个关于该新增客户的完整信息，并且发送到MQ，利用MQ的Pub/Sub机制将数据通知到各个相关的业务系统；
1各个业务系统接收到新增的客户信息，并且更新自身的应用系统数据库。
客户主数据系统实施法论
客户主数据工程的本质是一个系统间针对客户信息的整合工程
升级会员 