一 多域MDM与多个域MDM:区别比你想象的要大
我做了8年的主数据管理顾问，并在一家大型企业工作了两年，为客户和潜在客户提供建议。在这期间，我亲眼看到了采用多域方法处理MDM的重要性。组织试图用MDM解决的业务挑战非常复杂，很少只涉及单一类别的数据。
最近，出现了一种新的MDM趋势，供应商开始部署预构建的单域应用程序(例如，客户MDM、产品MDM等)，声称通过这些应用程序的组合提供了真正的多域MDM功能。问题是，虽然这些单独的、离散的应用程序一起管理多个数据域，但它们仍然作为多个独立的应用程序来管理——我将其称为“多个域”MDM。
多个域MDM供应商声称，部署预先构建的应用程序比使用更广泛、更灵活的多域MDM平台更快、更经济。他们甚至提倡这样一种观点，即客户仍然可以通过为他们想要管理的每个新域部署额外的MDM实例来成长为额外的用例。
1 剖析MDM单个实例的隐性成本
虽然这种新的多域方法乍一看似乎很精简，但与传统的多域MDM平台相比，它有一些限制和问题。由于每个域特定的应用程序都需要自定义，并且缺乏与其他应用程序的集成，因此，总是更加复杂和昂贵。然而，作为供应商价目表上单独许可的产品，它们的增量成本要高得多。
从表面上看，对于实现MDM的组织来说，这种多个域方法似乎更容易管理。因为每个MDM实例都是用特定类型的数据或域构建的，因此公司可以快速掌握客户数据。但是公司经常发现，虽然一个预先构建的客户数据解决方案，例如100个可用的“标准”属性，但实际上只有20个左右适用于他们的业务和客户基础。他们可能还会发现，一个只包含客户数据的数据模型，如果购买的产品、购买的渠道以及他们与之互动的营销活动隔离开来，就无法提供更多的见解。
此外，最终至少有一个(可能是全部)多域解决方案应用程序需要包含对其他MDM应用程序的引用，以便为单个用例服务。虽然这种多域解决方案是作为一种集成解决方案来销售的，以克服公司的数据质量问题，但它可能只是数据专业人员在试图报告来自各种企业资源规划(ERP)、财务报告和其他系统的数据时需要参考的另一个竖井应用程序。
企业需要定制每个预先构建的MDM实例以满足其特定需求，并可能将其集成到其他MDM域特定的应用程序，显然，这种方法通常比传统的与数据模型无关的多域平台(在一个MDM实例中处理多个数据域)更加复杂和昂贵。
这是因为必须修改MDM的每个单域实例，以适应业务、遗留数据源和用例的特定需求。随着其他用例的出现和组织的扩展，与维护多个实例和每个域的独立许可相关的成本可能呈指数级增长——所有这些都没有集成的、基于多域平台的MDM方法的好处。虽然这些问题中有许多是可以预见的，但通过仔细的尽职调查，将MDM需求与企业的实际业务问题相一致，这种单域或多域方法对其业务问题和机会的看法也同样是短视的(通常是不完整的)。
2 实现MDM灵活性:多域还是多个域
多个域MDM解决方案的支持者认为，多域MDM是两个或多个主数据域的串行实现，甚至是并发实现。然而，多域应该被理解为只对那些有助于达成一致业务结果的主数据实体和属性进行建模的自由和灵活性——而不管它们属于哪个数据域。
当然，这种最佳实践方法只有在获得的MDM解决方案是与数据模型无关的平台，而且供应商不单独授权每个域的情况下才有意义，不幸的是，即使是在多域平台MDM供应商和多域参与者中也是如此。
在我前面的例子中，有一个企业购买了一个包含100个属性的预先构建的客户数据解决方案，由于他们被迫购买额外的MDM应用程序或实例，因此成本会以指数形式增加，对客户的价值也会降低。即使是来自单一供应商的多域应用程序，通常也是基于底层多域平台的数据模型、数据集成服务和用户界面的简化版本。
确切地说，真正的多域MDM供应商和解决方案提供了一种与域无关的许可模型，它允许随着实现人员确定额外的业务需求而不断增长，而不必担心简单的跨数据域界线，这会导致未来软件成本的增加。使用与域无关的定价模型，企业可以授权他们需要的20个客户数据属性(在上面的例子中)以及80个属性(或者业务需求允许的任何数量)，这些属性被划分到多个其他类型的数据中，而不会为每个额外的域带来不必要的固定成本。
3 多域MDM案例
组织发现，理想的方法不是单域应用程序或多域MDM，而是真正的多域MDM，它可以扩展到其他域，同时为特定客户、提供者或其他用例提供起步解决方案模板。
没有真正的业务问题可以通过只管理一个域来解决，供应商和实现者必须对MDM采取全面的、多域的方法。虽然单域和多个域供应商声称他们的解决方案比多域MDM解决方案提供更快的启动和更低的成本，但他们缺乏全面解决方案的功能和特性集。随着客户在数字转型、云迁移或其他数据活动过程中不断前进，他们需要一种可以随着客户增长而扩展的MDM方法，使他们能够面对新的挑战。
