一个公司在考虑实施主数据管理(master data management,MDM)时，主要是出于几个原因。有些公司想要解决他们的数据质量问题，只有将所有的流程进行集中化管理才有可能解决这一问题;有些公司认为他们没有特别严重的数据质量问题，但是还是有许多相同的数据是来自不同信息源的，他们需要对数据模型和数据源进行集中管理才能减缓数据分离的问题。

　　然而，还有一些公司想要针对特定的操作系统收集主数据，并且需要与主系统开发任务区分开来。他们希望更改公司的业务流程，只有这样才能在MDM系统下的工作流环境中得到相应的支持。

　　所有上述的场景都需要MDM流程与操作系统数据的整合。因此，读者不禁要问“支持操作系统的MDM hub中究竟管理的是哪一种数据?”

　　通常说来，这些数据就是预定用在多个系统中的，也就是所谓的“核心”数据。对客户数据来说，就是姓名、地址以及一些统计的细节信息，这些都可以轻松地与独立客户联系起来，使用的是整合而不是计算。

　　这就是初级的MDM——控制数据进行整合。

　　另一方面，一些组织想要运行深层次的商业分析计算(作为其商业智能项目的一部分)，他们会把MDM数据库当做收集、合并需求信息的一个容器。客户终身价值、购买习惯以及购买可能性等元素都可以用来进行主分析数据计算，然后导出报表。这可以成为巨大价值的催化剂。

　　这同样是初级的MDM——控制分析数据。

　　上面所述两种MDM的普遍认识也并不冲突。而MDM最大的优势则来自于两种方式的结合，分析型MDM+操作型MDM。企业MDM数据模型无论是在分析还是在计算方面都十分健壮，同时也是自动化流程与手动输入MDM工作流环境的结合产物。

　　在分析型MDM进程中添加操作型系统

　　一个分析型MDM项目可以作为操作型MDM的起始点。但是从分析角度来说，数据变为操作型系统可用只需要非常短的时间。

　　一些操作系统能够更快地接收分析型MDM数据，而它们的数据模型以及相应的流程可能需要进行扩展。此外，一些操作型系统会比分析型MDM反应速度快。

　　无论是什么系统在支持分析计算之前都需要得到交易数据。从定义上来说，分析就指的是一个源码方式，用来根据交易数据进行值计算。如果你根据客户活动或者第三方系统向记录中添加人口特征数据，你就可以利用分析方式来使用这些数据了。

　　我个人发现对于MDM的争论在大多数情况下都是非常激烈的。不管怎样，理解分析型数据都拥有大量的MDM sourcing组件。一些系统订阅了MDM系统的分析数据才可以更加轻松地使用那些字段进行分析，而其他的系统则相对困难。

　　因此，尽管分析型MDM可以作为操作型MDM的跳板，但是反之也是如此。一旦一个MDM系统控制了操作型数据，那么信息也可以承担分析值。不管顺序如何，只有最大限度地利用两种形式的MDM功能，才有可能实现价值的最大化。