论文部分内容阅读
多域主数据管理有应用程序法和平台法两种。前者从业务逻辑、图形用户界面到数据模型的顺序来推进，虽然能快速实施，但长远看却是本末倒置，而后者则恰恰相反……
一家制造公司為能衔接买方和卖方的供应链流程，更有效地管理直接和间接材料的采购，并改善产品的分销，决定部署 主数据管理（MDM）解决方案。若要达成上述目标，MDM解决方案必须能够管理供应商、客户、材料和产品主数据。
但目前市场上专注于客户数据集成 （CDI)）或产品信息管理（PIM） 的技术解决方案，只能解决部分的业务问题，不能将技术扩展至其他业务，MDM 的实施效率很低。且仅从其中一个主数据域着手无法有效地改善系统供应链，且会严重限制 MDM 解决方案对于供应链绩效管理的有效性，于是多域MDM方法进入人们的视野。
多域主数据管理的两种方法
多域主数据管理有两种方法：第一种是 MDM 应用程序法，第二种是 MDM 平台法。
MDM 应用程序法附带特定的数据模型、业务逻辑或功能以及图形用户界面，所有这些特点都非常适合解决单一、明确界定的业务问题。这就类似于购买现成的销售软件来管理销售渠道，或购买一个采购软件来管理直接或间接材料，是针对性地解决某一方面的问题。
而借助 MDM 平台法，企业可以灵活定义其自身的数据模型，基于定义的模型产生业务逻辑和功能，并支持基于相关功能来配置图形用户界面。
尽管应用程序法和平台法都可以快速满足组织采纳 MDM 的初始需求，但笔者认为只有借助平台法，公司才能发展和扩展其 MDM 系统以解决各种其他业务问题。而应用程序法将不可避免地导致 MDM 孤岛和成本超支。
尽管有时企业必须在第一时间内解决业务问题，因此需要能快速实施的MDM 方案，但要扩展MDM实施以解决其他业务需求或满足将来的不时之需，平台法是降低总拥有成本和加快实现价值的正确途径。
传统药品部的苦恼
为了更好地理解这两种方法有何区别，让我们看一个假设的业务问题。一家全球制药公司将其业务分为多个分部，包括传统药品部、非处方药部、生物技术部和医疗设备部。
传统药品部主要供应重大疾病和流行病（如癌症、HIV/AIDS 和细菌感染）的药物，由于其销售团队用于追踪销售活动（对象要拓展到医生、医院和药剂师等）的陈旧系统充满重复记录，导致该分部在合规报告方面遇到严重问题。于是，传统药品部的管理层和 IT 决策者决定通过 MDM 方案解决此问题，形成一个集成的医师主数据。
此医师主数据将用来清洗、标准化及整合各种来源的信息，并将整理后的信息返回至该分部的销售团队系统。有了准确的医师拓展数据，分部将能够及时地产生准确的合规报告。简而言之，药品部可以妥善地解决其当前的问题。
他们采用哪种 MDM 方法能获得最佳效果呢？是应用程序法还是平台法？
如果采用MDM 应用程序法，由外到内推进，那么，药品部首先要隔离业务逻辑，在独立的MDM Hub 中创建、管理医师数据；然后，开发图形用户界面（GUI），按现有程序要求的数据模型支持业务逻辑。这种方法是药品部从具体问题（有关医师拓展的合规报告）以及与该问题相关的业务逻辑着手，然后构建 GUI 管理业务逻辑和数据模型，从而支持全部功能。
而如果采用MDM 平台法，由内而外推进，与前面方法恰恰相反，药品部将首先从数据模型入手，完成定义数据模型后，再配置图形用户界面管理主数据，最后在数据模型顶部汇编业务逻辑。这种MDM 策略首先从数据着手，然后在之前定义的数据顶部灵活配置图形用户界面和业务逻辑。
只顾眼前导致信息孤岛
现在重新回到上述传统药品部及其所属公司产生的业务问题。如果采用应用程序法，药品部将满足其眼前的业务目标，且最终的 MDM 系统可以妥善地解决其合规报告问题，但获得的所有益处仅限于此。如果在此新系统投入使用后一年，药品部的 IT 决策者认识到，供应链数据中的重复项和其他错误及差异开始对其生产计划产生了不利影响，又该如何处理？
最初使用应用程序法的 MDM 解决方案所采用的业务逻辑、GUI 和数据模型只能解决先前的合规问题，而无法解决此新问题，这个最新出现的业务问题将非常有可能导致下一个 MDM 的需求。这是因为之前的解决方案只是有针对性地处理单个业务实体即药品部的医师拓展/合规流程等独特问题，而对新问题鞭长莫及，一旦实施便成为一个静态的解决方案点。
因此，药品部将必须针对此新供应链数据问题制定全新且独立的 MDM 解决方案，那公司最终将存在两个不同的 MDM 孤岛，非标准化数据造成的问题更加严重。
平台法 不再本末倒置
如果药品部采纳平台法来解决其合规报告问题，那么，他们首先考虑的是数据模型，并需要构建一套详细的指引，指明结构化数据来源于何方，各个系统如何组织该模型，哪些应用程序会访问它以及访问时间等，然后再配置图形用户界面来管理业务问题产生的业务逻辑的相关数据。
借助平台法，药品部的 MDM 系统可以轻松得到扩展，应对可能产生的后续问题。这样，不仅可以解决药品部的问题，而且可以应对组织本身所面临的更多业务难题。例如，公司可以优化核心药品经营的供应链，在医疗设备经营范围内进行合同管理，或者优化非处方药分部的销售团队管理。
主数据管理能消除多数企业固有的数据错误和冲突，进而消除冗余的数据存储库和系统，但通过应用程序法实施 MDM 无法实现这些目标。MDM 应用程序法通常引导有需求的客户购买不同的 MDM 应用程序来解决不同的问题，从而产生不同的数据孤岛。因此，依照从业务逻辑、图形用户界面到数据模型的顺序来推进MDM是顺序颠倒的，或者说是上下倒置的。
传统的由外而内法可能适用于应用程序解决方案，如企业资源规划（ERP）、客户关系管理 （CRM） 和供应链管理（SCM）。这些解决方案仅需解决一个业务问题。但是，多域 MDM 就其本质而言是以平台为中心。只有多域 MDM 平台才可以提供最灵活的方法，从而在整个企业范围内随时创建和发展 MDM 解决方案。
链 接
主数据管理的远景
主数据跨越所有的组织业务部门，分布在多个不同的系统中，如企业资源计划 、客户关系管理、商业智能系统、遗留系统和大型机系统、合作伙伴和供应商系统，以及单个电子数据表、文档、.pdf 文件和桌面数据库。
它的远景是为权威性主题领域的数据提供单一视图。在Jill Dyché 与 Evan Levy合著的《客户数据集成：获取唯一版本的真相》一书中，将 MDM 定义为：一套规则和方法集，用于确保公司参考数据的通用、含义和质量能够在不同系统和机构中得到共享。
随着公司成长、重组、收购以及在防火墙内外安装新系统和共享数据，对公共的权威参考数据的需求正在不断增长。只要处理得当，MDM 就能够简化在为单个主题领域部署和维护参考数据时涉及的所有规则和详细信息。
一家制造公司為能衔接买方和卖方的供应链流程，更有效地管理直接和间接材料的采购，并改善产品的分销，决定部署 主数据管理（MDM）解决方案。若要达成上述目标，MDM解决方案必须能够管理供应商、客户、材料和产品主数据。
但目前市场上专注于客户数据集成 （CDI)）或产品信息管理（PIM） 的技术解决方案，只能解决部分的业务问题，不能将技术扩展至其他业务，MDM 的实施效率很低。且仅从其中一个主数据域着手无法有效地改善系统供应链，且会严重限制 MDM 解决方案对于供应链绩效管理的有效性，于是多域MDM方法进入人们的视野。
多域主数据管理的两种方法
多域主数据管理有两种方法：第一种是 MDM 应用程序法，第二种是 MDM 平台法。
MDM 应用程序法附带特定的数据模型、业务逻辑或功能以及图形用户界面，所有这些特点都非常适合解决单一、明确界定的业务问题。这就类似于购买现成的销售软件来管理销售渠道，或购买一个采购软件来管理直接或间接材料，是针对性地解决某一方面的问题。
而借助 MDM 平台法，企业可以灵活定义其自身的数据模型，基于定义的模型产生业务逻辑和功能，并支持基于相关功能来配置图形用户界面。
尽管应用程序法和平台法都可以快速满足组织采纳 MDM 的初始需求，但笔者认为只有借助平台法，公司才能发展和扩展其 MDM 系统以解决各种其他业务问题。而应用程序法将不可避免地导致 MDM 孤岛和成本超支。
尽管有时企业必须在第一时间内解决业务问题，因此需要能快速实施的MDM 方案，但要扩展MDM实施以解决其他业务需求或满足将来的不时之需，平台法是降低总拥有成本和加快实现价值的正确途径。
传统药品部的苦恼
为了更好地理解这两种方法有何区别，让我们看一个假设的业务问题。一家全球制药公司将其业务分为多个分部，包括传统药品部、非处方药部、生物技术部和医疗设备部。
传统药品部主要供应重大疾病和流行病（如癌症、HIV/AIDS 和细菌感染）的药物，由于其销售团队用于追踪销售活动（对象要拓展到医生、医院和药剂师等）的陈旧系统充满重复记录，导致该分部在合规报告方面遇到严重问题。于是，传统药品部的管理层和 IT 决策者决定通过 MDM 方案解决此问题，形成一个集成的医师主数据。
此医师主数据将用来清洗、标准化及整合各种来源的信息，并将整理后的信息返回至该分部的销售团队系统。有了准确的医师拓展数据，分部将能够及时地产生准确的合规报告。简而言之，药品部可以妥善地解决其当前的问题。
他们采用哪种 MDM 方法能获得最佳效果呢？是应用程序法还是平台法？
如果采用MDM 应用程序法，由外到内推进，那么，药品部首先要隔离业务逻辑，在独立的MDM Hub 中创建、管理医师数据；然后，开发图形用户界面（GUI），按现有程序要求的数据模型支持业务逻辑。这种方法是药品部从具体问题（有关医师拓展的合规报告）以及与该问题相关的业务逻辑着手，然后构建 GUI 管理业务逻辑和数据模型，从而支持全部功能。
而如果采用MDM 平台法，由内而外推进，与前面方法恰恰相反，药品部将首先从数据模型入手，完成定义数据模型后，再配置图形用户界面管理主数据，最后在数据模型顶部汇编业务逻辑。这种MDM 策略首先从数据着手，然后在之前定义的数据顶部灵活配置图形用户界面和业务逻辑。
只顾眼前导致信息孤岛
现在重新回到上述传统药品部及其所属公司产生的业务问题。如果采用应用程序法，药品部将满足其眼前的业务目标，且最终的 MDM 系统可以妥善地解决其合规报告问题，但获得的所有益处仅限于此。如果在此新系统投入使用后一年，药品部的 IT 决策者认识到，供应链数据中的重复项和其他错误及差异开始对其生产计划产生了不利影响，又该如何处理？
最初使用应用程序法的 MDM 解决方案所采用的业务逻辑、GUI 和数据模型只能解决先前的合规问题，而无法解决此新问题，这个最新出现的业务问题将非常有可能导致下一个 MDM 的需求。这是因为之前的解决方案只是有针对性地处理单个业务实体即药品部的医师拓展/合规流程等独特问题，而对新问题鞭长莫及，一旦实施便成为一个静态的解决方案点。
因此，药品部将必须针对此新供应链数据问题制定全新且独立的 MDM 解决方案，那公司最终将存在两个不同的 MDM 孤岛，非标准化数据造成的问题更加严重。
平台法 不再本末倒置
如果药品部采纳平台法来解决其合规报告问题，那么，他们首先考虑的是数据模型，并需要构建一套详细的指引，指明结构化数据来源于何方，各个系统如何组织该模型，哪些应用程序会访问它以及访问时间等，然后再配置图形用户界面来管理业务问题产生的业务逻辑的相关数据。
借助平台法，药品部的 MDM 系统可以轻松得到扩展，应对可能产生的后续问题。这样，不仅可以解决药品部的问题，而且可以应对组织本身所面临的更多业务难题。例如，公司可以优化核心药品经营的供应链，在医疗设备经营范围内进行合同管理，或者优化非处方药分部的销售团队管理。
主数据管理能消除多数企业固有的数据错误和冲突，进而消除冗余的数据存储库和系统，但通过应用程序法实施 MDM 无法实现这些目标。MDM 应用程序法通常引导有需求的客户购买不同的 MDM 应用程序来解决不同的问题，从而产生不同的数据孤岛。因此，依照从业务逻辑、图形用户界面到数据模型的顺序来推进MDM是顺序颠倒的，或者说是上下倒置的。
传统的由外而内法可能适用于应用程序解决方案，如企业资源规划（ERP）、客户关系管理 （CRM） 和供应链管理（SCM）。这些解决方案仅需解决一个业务问题。但是，多域 MDM 就其本质而言是以平台为中心。只有多域 MDM 平台才可以提供最灵活的方法，从而在整个企业范围内随时创建和发展 MDM 解决方案。
链 接
主数据管理的远景
主数据跨越所有的组织业务部门，分布在多个不同的系统中，如企业资源计划 、客户关系管理、商业智能系统、遗留系统和大型机系统、合作伙伴和供应商系统，以及单个电子数据表、文档、.pdf 文件和桌面数据库。
它的远景是为权威性主题领域的数据提供单一视图。在Jill Dyché 与 Evan Levy合著的《客户数据集成：获取唯一版本的真相》一书中，将 MDM 定义为：一套规则和方法集，用于确保公司参考数据的通用、含义和质量能够在不同系统和机构中得到共享。
随着公司成长、重组、收购以及在防火墙内外安装新系统和共享数据，对公共的权威参考数据的需求正在不断增长。只要处理得当，MDM 就能够简化在为单个主题领域部署和维护参考数据时涉及的所有规则和详细信息。