神马文学网主数据管理经验谈
来源：百度文库 编辑：神马文学网 时间：2024/04/28 01:11:29
主数据管理经验谈 2005.08.29 来自：ZDNET
在公司中，主数据管理系统（MDMS）的主要作用在于可以有一个单一的系统作为所有公有数据项的一个参考点。
在刚刚过去的一年中，Builder.com公司一直没有很好的解决带有多个客户端的主数据的管理问题，为此，根据我的经验，针对这个问题我为他们写了一篇文章，告诉他们如何才能实现主数据的最佳管理。针对这个目标，在本文中，我将检查分析所有的实现进程，得到的经验教训、所走过的弯路以及对目标所做的修正。
在一个公司中，主数据管理系统（MDMS）的主要作用在于可以有一个单一的系统作为所有公有数据项的一个参考点。然后，在组织内的每个"客户"系统就可以参考这个系统来管理它的关键数据，从而可以确保在整个应用程序套件内数据的共通性以及正确性。
通过其他应用程序来了解MDMS
我在以前的文章中指出，在公司内，实现这个目标的进程来的很慢，但是确实在向前推进。这主要是因为公司中存在着这样的三类应用程序：
新创建的应用程序，包括内部和外部创建的应用程序以及一些不需要定制的应用程序。
升级的应用程序，在一个已经存在的系统中可能存在一个这样的窗口，通过这个窗口可以实现升级工作。
遗留下来的应用程序，系统中没有升级窗口，也没有该系统的替代产品。
在第一种情况中，如果在系统分析的过程中就已经认识到这一点，那么作为这种类型项目的研发或者安装和配置进程的一部分，就可以将其作为一个到MDMS系统的连接引入到MDMS系统中。如果没有做这方面的连接，那么其主要原因或者部分原因通常可以归结为没有预算、没有可用的资源或者没有时间等方面。然而，如果已经考虑到了这个连接问题并且有预算的话，那么就没有理由不让这些新的应用程序充分利用MDMS。
在第二种情况中，作为该系统升级规程的一部分，是可以规划和预算相应连接的。当然，增加这些系统到MDMS系统的连接的话，需要对这种连接的影响做大量的分析工作；例如，如果对存储在MDMS中的一个数据项进行升级的话，那么对系统的影响是什么？ 另外，在这种类型的项目中，资金一般是用于新的功能而不是用于改善基础设施，因此在一个特定的升级过程中，可能不会执行一些低优先级的连接。
最后一种情况是遗留下来的应用程序，从连接到MDMS系统的角度来说，在一些大的公司中，遗留系统是最常见的系统也是处理起来最复杂的系统。如今，很多公司都有一个用所谓的"遗留"语言如COBOL所做的重要程序，根据DevX的一份声明：
"世界上70％的数据都是用COBOL语言处理的，并且90％的ATM事务处理用的都是COBOL语言。如今每天在线处理的COBOL事务有300亿次。500强中有492家使用了COBOL语言，包括全部的100强，而且目前在COBOL方面的投资已经超过3万亿美元。"
尽管情况如此，但是很少有程序员具有这种必要的COBOL语言的技能。这是因为很多有这种技能的程序员正处于退休的年龄。因为无论是在公司中还是在大学中，具有COBOL技能的程序员看起来远远没有具有如Java或者.NET技能的程序员那样有诱人的前景，如今具有这种技能的程序员的数量在急剧下降，如果公司没有明智的考虑到这些问题的话，这个问题将类似于当年的Y2K问题，可能成为一件令人头痛的事情，并且可能导致具有这种技能的程序员的大量加薪。
在有些公司中，存在着这样的谚语"如果没有出现问题就不需要修理。"并且他们将其作为另外一种常见的理由，只要这些系统能够工作就不对其进行任何改进，有限的资金、资源和时间最好用在其他地方。从而使得这种类型的系统很难集成到新的MDMS系统中，但是面对这种趋势，我的建议是：虽然这些资源仍然可以使用，但是至少应该尽量考虑到他们，当然是相对便宜的应该优先考虑。
并行研发的问题
我们所需要解决的一个主要问题是：在一个组织内研发MDMS系统的同时常常会并行的有其他的研发工作。因此在规划MDMS系统或者其他系统的行为时常常会引起一些问题。这些问题可能包含以下情景：
直到MDMS已经开始"运转"时，MDMS系统也没有得到最初规划所需要的数据。
作为一种共有的并且是系统需要的数据，可当时并没有打算将其包含在MDMS系统中。
在现存的应用程序中新识别出来的共有数据并没有从MDMS中提取出来。
对研发团队和MDMS团队来说，还有其他的限制因素如预算、时间或者资源等。
在一个组织内部署MDMS系统将可能带来大量增加修改工作，因为管理者总是试图要求研发路径和升级路径尽可能与MDMS系统自身的研发路径相符合。虽然这确实可能导致大量的令人头痛的问题以及一些其他问题，但是总体来说还是值得的。
在我曾经合作过的几个团队中，他们解决这些可能潜在问题的一种方法是：一开始将他们的数据存储在本地的一个数据库内，然后，在一个合适的时候，或者从MDMS系统中将这些数据导入到这个数据库中，或者更改连接这样就可以直接从MDMS中加载数据。通过这种方式就可以让本地应用程序按照自己的节奏、一条一条的将它的管理数据转换到MDMS系统中，而且它们就不会受到其他活动的影响也不会受到这些活动的约束。这是因为相对而言，更改一个数据库的连接器或者将另一个数据库增加到数据活动脚本如EAI或者ETL或者甚至是一个SQL Server DTS包中是一件相当容易的任务。
案例研究
在我的客户中，有一个客户很特别，任何修改MDMS系统对企业运作所造成的影响他都很清楚，并且他对在最近一次内部分类继承的更新过程中数据流过其他系统的速率也非常清楚。虽然只有一部分数据发生了改变，但是在真的发生了改变以后，IT部门就会开始接到需要技术支持的传票--它们声称系统A中的数据和系统B并不匹配，因为在当时的情况下，只有其中的一个系统发生了改变，而另一个系统还没有来得及改变。
然后，他们会发现另一个系统--系统C已经崩溃，因为系统C的数据库中包含了分类继承表和公司销售的产品之间的关系。这些改变已经破坏了原有的连接，因而导致了系统出错，并且导致系统C中有些数据丢失。幸运的是，系统在将这些已经被破坏的数据传向其他系统之前就已经发现了问题，否则的话终端用户有可能使用这些被破坏的数据来做任何他们想做的事情。
通过MDMS系统将各个系统连接在一起确实存在着一定的风险，这些风险又让你怀疑是否真的值得去冒这种风险。IT团队为此不得不投入大量的时间和资源来对系统C进行备份，更不用说他们让那些终端用户对他们失去了信心，并且终端用户完全有可能将此作为他们工作中的一段插曲。
有人支持Pooh Sticks吗？
Pooh Sticks是一个（由A. A. Milne创建的）游戏，在这个游戏中，每个参与者都将一个棍棒投入到溪流中，看谁投出的棍棒首先到达指定的结束地点。
无论是以什么方式将各个系统连接在一起来实现数据的共享，在数据开始流动的时候，很重要的一点就是看一看这些数据是如何从该系统中流入它的各个子系统中的；例如，这些数据流是每天晚上都自动加载还是手动初始化上传？抑或是每周出现一次丢弃？如果能够懂得这些，通过对每个系统的进行一次合理的分析，那么，在MDMS系统中变化的数据通过你的基础设施公开的时候你就会知道将会出现什么样的问题。
由于存在各种不同的因素，而且还有数据在不停的流过系统，因此有些系统可能即使是出现了相同的点也不会显示出完全相同的数据。只要客户系统知道了这一点并且接受这种事实，在第一次出现这种问题的时候，这也可能不会成为一个大的问题。数据项的改变所造成的影响可能会依赖于不同的因素，如数据项、系统或者依赖于这个数据项的用途不同而不同。
对于实时系统来说，我在我的一次大学演讲中提到了这样一点，"在错误的时间中即使是出现了正确的数据仍然是一种错误。"
最初看上去这个映射工作是一个比较简单的过程，因此我们就将几个关键系统连接在一起。然而，这个工作变成了一个相当大的项目，因为我们没有剥离这些系统，没有预先对应用程序进行记录，并且发现了很多过期文档等，因此我们的中心IT团队无法实现对这些系统的控制。除此以外，我们还发现要想确定在各个系统中数据的用途，简单的询问相应的项目经理是解决不了问题的，为了跟踪代码中数据的用途，我们不得不让程序开发人员介入到其中，而且还需要会见关键的用户，只有这样我们才能确定我们所做的改变会造成什么样的影响。这成为推出MDMS系统过程者需要解决的一个最大的问题。
三合一的MDMS 系统管理团队
在我的原来的一篇文章中，我曾经建议最好的实现MDMS系统的方法是组建一个管理团队，这个管理团队由三个方面组成：一个成员管理MDMS系统数据，另一个成员管理这些数据的使用，第三个成员管理与MDMS系统相关的主要技术联系以及系统中数据的使用（见图A）。
图A：三合一团队
这种实现方法已经被我所服务的一个公司采用，但是对于MDMS系统来说，没有一个"三合一"团队中的成员是全职工作的。然而，这种在一个项目团队内有三个来自于截然不同部门的成员的组成方式可以确保MDMS系统能够朝着成为公司基础设施的核心系统方向迈出坚实的步伐。
在部署MDMS系统的早期，还需要另外一个角色，那就是MDMS系统的传道者。这个人必须要向IT团队以及企业的主要股东宣传MDMS系统的概念和优势。这些股东不仅要向MDMS系统投资，还会资助那些为了保证能够和MDMS系统兼容而需要进行相应的改变的系统。尤其重要的一点是要让企业的不同部门都能够接受MDMS系统的概念，并且需要让他们知道MDMS系统可以让他们的工作变得更容易，效率将变得更高，而且将会产生更高的生产力。
第二个案例
最近为欧洲一个非常大的装备公司做的一个项目是要实现一个可变控制系统，我们可以使用他们的MDMS系统来为新系统提供大量的必要数据。对于这些数据这个公司已经有了很好的存储解决方案，并且管理的很好，而且实现了很好的控制，因此我们不需要进行更多的处理。在这个项目中，这为我们节约了大量的时间、资源和资金，从而我们可以将我们的主要精力用于在新系统中进行主要的改进并且可以用于开发新的功能。
对于那些在MDMS系统中还没有的数据项，我们将其保存在我们自己的小数据库中，在MDMS系统中这些数据可以使用的时候，我们将为这些数据寻找最适宜的更新方法。其结果是，如今这个系统所需要的所有数据几乎都来自于MDMS系统，有些数据是可以直接反馈的，而其他的数据则可以在不同的时间中通过数据加载的方式得到。
得到的经验教训
如今，我们已经认识到在这个项目中的经验教训。我们的主要教训远不止这些：
规划
确信自己知道数据在什么时候以及如何从MDMS系统中流向其他的各个系统，并且确信自己知道数据的改变会对系统产生什么样的影响。
仔细考虑你的IT团队的年度规划，并且在研发相似的系统时尽量与MDMS系统内已经包含的数据一致。
如果你的数据有一个很大的变化的话，那么对此要单独进行规划。
研发
只开发你所需要的MDMS系统的功能。记住这只是一个数据来源，并且要记住这个系统不会被大量的终端用户直接使用。
在MDMS系统和其他系统之间尽可能提供一个公共数据访问基础设施。这样可以减少系统的复杂性，并且可以让数据维护和技术支持变得更容易。
沟通
和IT团队要保持经常性的交流，这样可以确保他们需要数据的时候，MDMS系统可以尽可能的为他们提供数据。
和终端用户群体要保持经常性的沟通，让他们理解使用MDMS系统的好处，因为他们的投资可以为他们带来更多的时间和效益。
放眼未来
在随后的几个月中，我们将着眼于在MDMS系统中尽可能多的识别和包含公用数据，并且鼓励那些现在正在使用这些数据的系统从MDMS系统中获得这些公用数据。我们还需要考虑在各个不同系统之间的数据项的关系（比如说，你在系统中有一个产品的类型为A，但是你的子产品类型可能只是1、2、或者3等），以及在每个系统中对于不同数据项来说所使用的有效法则。从而可以确保各个系统之间的数据能够保证一致性。当然，其中一部分关系和规则可能在MDMS系统内部就已经解决了，因为他们只是从一个简单的数据仓库中延伸出来而已。
我们还需要考虑在我们的MDMS系统中还能够存储什么类型的数据，例如，常用习语，如：哈泽德习语的翻译；用法指令以及数字化资产的管理，如：产品的标识等。
在这种情况下，团队的主要项目是对其他系统的数据流向以及数据用法进行分析，所涉及到的工作将消耗团队的大部分资源，并且在分析所有系统的过程中可能会涉及到公司内的大部分人。
对于任何新的研发，包括升级工作来说，连接到MDMS系统是必须具备的一个功能，没有理由不这么做。在某些情况下，IT被迫回退来确保每个项目有足够的资金和时间，并且还需要确保这些工作都已经正确完成。另外，在公司内可能成立了另外一个不同的团队来研发数据共享工具，如：ETL、EAI等，以确保系统间的连接尽可能的以公用和可管理的方式建立。
我们还需要开始注意在新的MDMS领域的软件如SAP的MDM系统，该系统可以用来替换我们自己的MDMS解决方案。
_xyz
在公司中，主数据管理系统（MDMS）的主要作用在于可以有一个单一的系统作为所有公有数据项的一个参考点。
在刚刚过去的一年中，Builder.com公司一直没有很好的解决带有多个客户端的主数据的管理问题，为此，根据我的经验，针对这个问题我为他们写了一篇文章，告诉他们如何才能实现主数据的最佳管理。针对这个目标，在本文中，我将检查分析所有的实现进程，得到的经验教训、所走过的弯路以及对目标所做的修正。
在一个公司中，主数据管理系统（MDMS）的主要作用在于可以有一个单一的系统作为所有公有数据项的一个参考点。然后，在组织内的每个"客户"系统就可以参考这个系统来管理它的关键数据，从而可以确保在整个应用程序套件内数据的共通性以及正确性。
通过其他应用程序来了解MDMS
我在以前的文章中指出，在公司内，实现这个目标的进程来的很慢，但是确实在向前推进。这主要是因为公司中存在着这样的三类应用程序：
新创建的应用程序，包括内部和外部创建的应用程序以及一些不需要定制的应用程序。
升级的应用程序，在一个已经存在的系统中可能存在一个这样的窗口，通过这个窗口可以实现升级工作。
遗留下来的应用程序，系统中没有升级窗口，也没有该系统的替代产品。
在第一种情况中，如果在系统分析的过程中就已经认识到这一点，那么作为这种类型项目的研发或者安装和配置进程的一部分，就可以将其作为一个到MDMS系统的连接引入到MDMS系统中。如果没有做这方面的连接，那么其主要原因或者部分原因通常可以归结为没有预算、没有可用的资源或者没有时间等方面。然而，如果已经考虑到了这个连接问题并且有预算的话，那么就没有理由不让这些新的应用程序充分利用MDMS。
在第二种情况中，作为该系统升级规程的一部分，是可以规划和预算相应连接的。当然，增加这些系统到MDMS系统的连接的话，需要对这种连接的影响做大量的分析工作；例如，如果对存储在MDMS中的一个数据项进行升级的话，那么对系统的影响是什么？ 另外，在这种类型的项目中，资金一般是用于新的功能而不是用于改善基础设施，因此在一个特定的升级过程中，可能不会执行一些低优先级的连接。
最后一种情况是遗留下来的应用程序，从连接到MDMS系统的角度来说，在一些大的公司中，遗留系统是最常见的系统也是处理起来最复杂的系统。如今，很多公司都有一个用所谓的"遗留"语言如COBOL所做的重要程序，根据DevX的一份声明：
"世界上70％的数据都是用COBOL语言处理的，并且90％的ATM事务处理用的都是COBOL语言。如今每天在线处理的COBOL事务有300亿次。500强中有492家使用了COBOL语言，包括全部的100强，而且目前在COBOL方面的投资已经超过3万亿美元。"
尽管情况如此，但是很少有程序员具有这种必要的COBOL语言的技能。这是因为很多有这种技能的程序员正处于退休的年龄。因为无论是在公司中还是在大学中，具有COBOL技能的程序员看起来远远没有具有如Java或者.NET技能的程序员那样有诱人的前景，如今具有这种技能的程序员的数量在急剧下降，如果公司没有明智的考虑到这些问题的话，这个问题将类似于当年的Y2K问题，可能成为一件令人头痛的事情，并且可能导致具有这种技能的程序员的大量加薪。
在有些公司中，存在着这样的谚语"如果没有出现问题就不需要修理。"并且他们将其作为另外一种常见的理由，只要这些系统能够工作就不对其进行任何改进，有限的资金、资源和时间最好用在其他地方。从而使得这种类型的系统很难集成到新的MDMS系统中，但是面对这种趋势，我的建议是：虽然这些资源仍然可以使用，但是至少应该尽量考虑到他们，当然是相对便宜的应该优先考虑。
并行研发的问题
我们所需要解决的一个主要问题是：在一个组织内研发MDMS系统的同时常常会并行的有其他的研发工作。因此在规划MDMS系统或者其他系统的行为时常常会引起一些问题。这些问题可能包含以下情景：
直到MDMS已经开始"运转"时，MDMS系统也没有得到最初规划所需要的数据。
作为一种共有的并且是系统需要的数据，可当时并没有打算将其包含在MDMS系统中。
在现存的应用程序中新识别出来的共有数据并没有从MDMS中提取出来。
对研发团队和MDMS团队来说，还有其他的限制因素如预算、时间或者资源等。
在一个组织内部署MDMS系统将可能带来大量增加修改工作，因为管理者总是试图要求研发路径和升级路径尽可能与MDMS系统自身的研发路径相符合。虽然这确实可能导致大量的令人头痛的问题以及一些其他问题，但是总体来说还是值得的。
在我曾经合作过的几个团队中，他们解决这些可能潜在问题的一种方法是：一开始将他们的数据存储在本地的一个数据库内，然后，在一个合适的时候，或者从MDMS系统中将这些数据导入到这个数据库中，或者更改连接这样就可以直接从MDMS中加载数据。通过这种方式就可以让本地应用程序按照自己的节奏、一条一条的将它的管理数据转换到MDMS系统中，而且它们就不会受到其他活动的影响也不会受到这些活动的约束。这是因为相对而言，更改一个数据库的连接器或者将另一个数据库增加到数据活动脚本如EAI或者ETL或者甚至是一个SQL Server DTS包中是一件相当容易的任务。
案例研究
在我的客户中，有一个客户很特别，任何修改MDMS系统对企业运作所造成的影响他都很清楚，并且他对在最近一次内部分类继承的更新过程中数据流过其他系统的速率也非常清楚。虽然只有一部分数据发生了改变，但是在真的发生了改变以后，IT部门就会开始接到需要技术支持的传票--它们声称系统A中的数据和系统B并不匹配，因为在当时的情况下，只有其中的一个系统发生了改变，而另一个系统还没有来得及改变。
然后，他们会发现另一个系统--系统C已经崩溃，因为系统C的数据库中包含了分类继承表和公司销售的产品之间的关系。这些改变已经破坏了原有的连接，因而导致了系统出错，并且导致系统C中有些数据丢失。幸运的是，系统在将这些已经被破坏的数据传向其他系统之前就已经发现了问题，否则的话终端用户有可能使用这些被破坏的数据来做任何他们想做的事情。
通过MDMS系统将各个系统连接在一起确实存在着一定的风险，这些风险又让你怀疑是否真的值得去冒这种风险。IT团队为此不得不投入大量的时间和资源来对系统C进行备份，更不用说他们让那些终端用户对他们失去了信心，并且终端用户完全有可能将此作为他们工作中的一段插曲。
有人支持Pooh Sticks吗？
Pooh Sticks是一个（由A. A. Milne创建的）游戏，在这个游戏中，每个参与者都将一个棍棒投入到溪流中，看谁投出的棍棒首先到达指定的结束地点。
无论是以什么方式将各个系统连接在一起来实现数据的共享，在数据开始流动的时候，很重要的一点就是看一看这些数据是如何从该系统中流入它的各个子系统中的；例如，这些数据流是每天晚上都自动加载还是手动初始化上传？抑或是每周出现一次丢弃？如果能够懂得这些，通过对每个系统的进行一次合理的分析，那么，在MDMS系统中变化的数据通过你的基础设施公开的时候你就会知道将会出现什么样的问题。
由于存在各种不同的因素，而且还有数据在不停的流过系统，因此有些系统可能即使是出现了相同的点也不会显示出完全相同的数据。只要客户系统知道了这一点并且接受这种事实，在第一次出现这种问题的时候，这也可能不会成为一个大的问题。数据项的改变所造成的影响可能会依赖于不同的因素，如数据项、系统或者依赖于这个数据项的用途不同而不同。
对于实时系统来说，我在我的一次大学演讲中提到了这样一点，"在错误的时间中即使是出现了正确的数据仍然是一种错误。"
最初看上去这个映射工作是一个比较简单的过程，因此我们就将几个关键系统连接在一起。然而，这个工作变成了一个相当大的项目，因为我们没有剥离这些系统，没有预先对应用程序进行记录，并且发现了很多过期文档等，因此我们的中心IT团队无法实现对这些系统的控制。除此以外，我们还发现要想确定在各个系统中数据的用途，简单的询问相应的项目经理是解决不了问题的，为了跟踪代码中数据的用途，我们不得不让程序开发人员介入到其中，而且还需要会见关键的用户，只有这样我们才能确定我们所做的改变会造成什么样的影响。这成为推出MDMS系统过程者需要解决的一个最大的问题。
三合一的MDMS 系统管理团队
在我的原来的一篇文章中，我曾经建议最好的实现MDMS系统的方法是组建一个管理团队，这个管理团队由三个方面组成：一个成员管理MDMS系统数据，另一个成员管理这些数据的使用，第三个成员管理与MDMS系统相关的主要技术联系以及系统中数据的使用（见图A）。
图A：三合一团队
这种实现方法已经被我所服务的一个公司采用，但是对于MDMS系统来说，没有一个"三合一"团队中的成员是全职工作的。然而，这种在一个项目团队内有三个来自于截然不同部门的成员的组成方式可以确保MDMS系统能够朝着成为公司基础设施的核心系统方向迈出坚实的步伐。
在部署MDMS系统的早期，还需要另外一个角色，那就是MDMS系统的传道者。这个人必须要向IT团队以及企业的主要股东宣传MDMS系统的概念和优势。这些股东不仅要向MDMS系统投资，还会资助那些为了保证能够和MDMS系统兼容而需要进行相应的改变的系统。尤其重要的一点是要让企业的不同部门都能够接受MDMS系统的概念，并且需要让他们知道MDMS系统可以让他们的工作变得更容易，效率将变得更高，而且将会产生更高的生产力。
第二个案例
最近为欧洲一个非常大的装备公司做的一个项目是要实现一个可变控制系统，我们可以使用他们的MDMS系统来为新系统提供大量的必要数据。对于这些数据这个公司已经有了很好的存储解决方案，并且管理的很好，而且实现了很好的控制，因此我们不需要进行更多的处理。在这个项目中，这为我们节约了大量的时间、资源和资金，从而我们可以将我们的主要精力用于在新系统中进行主要的改进并且可以用于开发新的功能。
对于那些在MDMS系统中还没有的数据项，我们将其保存在我们自己的小数据库中，在MDMS系统中这些数据可以使用的时候，我们将为这些数据寻找最适宜的更新方法。其结果是，如今这个系统所需要的所有数据几乎都来自于MDMS系统，有些数据是可以直接反馈的，而其他的数据则可以在不同的时间中通过数据加载的方式得到。
得到的经验教训
如今，我们已经认识到在这个项目中的经验教训。我们的主要教训远不止这些：
规划
确信自己知道数据在什么时候以及如何从MDMS系统中流向其他的各个系统，并且确信自己知道数据的改变会对系统产生什么样的影响。
仔细考虑你的IT团队的年度规划，并且在研发相似的系统时尽量与MDMS系统内已经包含的数据一致。
如果你的数据有一个很大的变化的话，那么对此要单独进行规划。
研发
只开发你所需要的MDMS系统的功能。记住这只是一个数据来源，并且要记住这个系统不会被大量的终端用户直接使用。
在MDMS系统和其他系统之间尽可能提供一个公共数据访问基础设施。这样可以减少系统的复杂性，并且可以让数据维护和技术支持变得更容易。
沟通
和IT团队要保持经常性的交流，这样可以确保他们需要数据的时候，MDMS系统可以尽可能的为他们提供数据。
和终端用户群体要保持经常性的沟通，让他们理解使用MDMS系统的好处，因为他们的投资可以为他们带来更多的时间和效益。
放眼未来
在随后的几个月中，我们将着眼于在MDMS系统中尽可能多的识别和包含公用数据，并且鼓励那些现在正在使用这些数据的系统从MDMS系统中获得这些公用数据。我们还需要考虑在各个不同系统之间的数据项的关系（比如说，你在系统中有一个产品的类型为A，但是你的子产品类型可能只是1、2、或者3等），以及在每个系统中对于不同数据项来说所使用的有效法则。从而可以确保各个系统之间的数据能够保证一致性。当然，其中一部分关系和规则可能在MDMS系统内部就已经解决了，因为他们只是从一个简单的数据仓库中延伸出来而已。
我们还需要考虑在我们的MDMS系统中还能够存储什么类型的数据，例如，常用习语，如：哈泽德习语的翻译；用法指令以及数字化资产的管理，如：产品的标识等。
在这种情况下，团队的主要项目是对其他系统的数据流向以及数据用法进行分析，所涉及到的工作将消耗团队的大部分资源，并且在分析所有系统的过程中可能会涉及到公司内的大部分人。
对于任何新的研发，包括升级工作来说，连接到MDMS系统是必须具备的一个功能，没有理由不这么做。在某些情况下，IT被迫回退来确保每个项目有足够的资金和时间，并且还需要确保这些工作都已经正确完成。另外，在公司内可能成立了另外一个不同的团队来研发数据共享工具，如：ETL、EAI等，以确保系统间的连接尽可能的以公用和可管理的方式建立。
我们还需要开始注意在新的MDMS领域的软件如SAP的MDM系统，该系统可以用来替换我们自己的MDMS解决方案。
_xyz