点击上面↑“Teamcenter笔记”关注，回复“MES”"Teamcenter"领资料！
| 数字孪生 | 最佳实践 |
| 选型指南 | BOM方案 |
| 变更管理 | PLM资料 |
| ERP资料 | MES/MOM |
| SCADA资料 | IIOT资料 |
| 工控基础 | 职业发展 |
在过去的几个月中，我进行过几次有关迁移 PLM 数据的讨论，无论是从一个系统迁移到另一个系统，还是将一组应用程序整合到一个环境中。这听起来熟悉吗？
让我分享一些数据迁移的经验和教训。 它不是一本技术指南，而是你在考虑解决技术梦想时可能错过的经验和想法的集合。
写到一半我意识到自己太过雄心勃勃，因此，我将在这篇介绍之后再写一篇文章。在这里，我将重点介绍业务方面和数字化转型之旅。
垃圾出 – 垃圾进
“垃圾出进”的说法在某种程度上是我们日常生活中习惯的范式。当你买一台新电脑时，你会使用备份和恢复。更简单的是，如今，大多数数据都已经存储在云端。
这个简单的场景假设所有专业系统都应该易于升级。我们不知道我们存储的数据量及其相关性。这种现象已经有了一个名字：“暗数据”。暗数据消耗云中的存储能量，并且不再可见。请在此处阅读有关它的全部内容：暗数据。
提示 1：每次迁移都是清理数据的时刻。拖着所有东西迁移，迁移的负担会越来越重。在简单的迁移中，进行清理可以防止将来出现更广泛的问题。
永远不要遵循“垃圾出-垃圾”的原则，即使这很容易！
PLM 域中的迁移有所不同 – 设置场景。
在讨论各种情况之前，让我们先看看各家公司都在做什么。对于汽车、航空航天和国防工业领域的早期 PLM 采用者来说，从大型机迁移到现代基础设施已变得不可能。真正的问题不仅是硬件的变化，还有数据和数据模型的变化。
对于这些公司来说，解决方案通常是在现有基础设施之上构建一个全新的 PLM 基础设施，其中可管理的数据片段使用数据湖、仪表板和自定义应用程序迁移到新环境以支持现代用户。
在这种情况下，只要数据存在，迁移就是一次旅程 - 而我们可以从中学习！
跟着钱走
从业务角度来看，迁移被视为负面干扰因素。谈论迁移会提高人们对其复杂性的认识，这可能会损害人们的热情。
对于发起者、PLM 软件供应商或实施者来说，这可能会危及销售交易。传统 IT 组织力求简化 — 只需管理一个 CAD、一个 PLM 或一个 ERP 系统。虽然这种说法很有道理，但始终应该进行分析，比较收益和（迁移）成本及风险，以达到理想情况。
在这些讨论中，迁移问题常常被淡化，我不点名，但我已经多次观察到这种淡化现象，甚至一些知名企业也是如此。所以，如果你认识到你的公司也处于这种境地，那么你并不孤单。
提示 2：迁移从来都不是一件简单的事情。将迁移作为 PLM 项目的一个重要主题——与软件一样重要。这种方法意味着需要分析潜在的迁移风险及其缓解措施。
大爆炸的风险最高，并且可能再次导致垃圾出，垃圾进。
您要对自己的垃圾负责
这听起来可能有点贬低，但事实并非如此。大多数公司都知道，多年来，人员、工具和政策已经发生了变化。由于采用了协调一致的工作方式，各个学科不需要关心其最初创建的数据的下游或上游使用情况——Excel 和 PDF 是学科之间的桥梁。
所有实际知识和背景都存储在经验丰富的员工的头脑中，他们已经习惯了处理不一致的情况。而且他们都会退休，因此迫切需要实际的数据质量和治理。
即使您还没有考虑迁移，PLM 领域的数字化转型也即将到来，我们应该学会以互联模式工作。
提示 3：在您的组织中创建一个团队，评估当前的数据质量并定义潜在的未来企业（数据）架构。然后，开始提高当前生成的数据的质量。与 ISO 900x 标准一样，ISO 8000 标准已经存在于数据质量中。
未来是由数据驱动的；为未来做好准备。
迁移场景及其最佳实践
这里有一些迁移场景 — — 这篇文章中有两个，即将发布的文章中还有更多。
从关系型到面向对象
我早期的一个项目，将基于大型机的飞机认证应用程序迁移到现代 Microsoft 基础设施。目标是创建一个新的环境，既可以用作大型机应用程序的替代品，也可以用作设计和验证环境，以便在维护或升级活动期间对现有飞机进行更改。
需求很高，因为不存在关于当前应用程序逻辑的详细文档，并且只有一个人能够部分理解该逻辑。因此，从内部来看，关系数据库是一个黑匣子。数据库中的表格包含项目数据、文档数据、变更状态和版本的混合。文档存储在具有有意义文件名的目录中，但与应用程序无关。
最初估计该项目需要两到三个月的时间，因此双方商定了两个月的固定价格。然而，该项目几乎持续了两年，而且最终结果似乎很可靠（从未有过数学证明）。
缺点是，SmarTeam 最终变得过于定制化，自动升级不再适用于此版本——使用现代技术创造了新的遗产。
早年的一篇的文章《PLM 迁移困境》中描述了同一个故事，并结合了爱立信迁移尝试的示例。对我来说，从这些示例中吸取的教训导致了以下建议。
提示 4：当数据模型发生范式变化时，不要迁移，而是建立一个新的（数据驱动的）基础设施，并尽可能以只读模式连接到您的遗留系统。
汽车和航空航天工业的故事是范式转变的故事之一。
CAD/PDM 到 PLM
当公司决定将传统 PLM 基础设施作为记录系统实施，合并 PDM 数据（主要是 CAD）和 ERP 数据（BOM）时，就会发生另一个迁移步骤。
其中一些公司一直采用基于文件的方式工作，并将最终的 CAD 文件存储在文件夹中；其他公司可能拥有原生于 3D CAD 的本地 PDM 系统。EBOM 通常以数字形式存在于 ERP 中，而且大多数情况下，它不是“纯”EBOM，而是混合型 EBOM/MBOM。
上图显示，这种类型的迁移可能非常具有挑战性，因为在源系统中，不一定存在与 BOM 项相匹配的一致 3D CAD 定义。由于系统过去曾断开连接，人们可能会在 BOM 端添加缺失信息或修复信息。与大多数公司一样，制造定义基于图纸，无法保证与 3D CAD 定义的一致性。
为了应对这一挑战，公司需要评估 CAD 和 BOM 数据的可用性。是否可以在 CAD 文件中填充导入所需的属性？例如，文件路径是否包含有用的信息？
我曾经遇到过这样的情况：一家公司的 3D 零件定义不明确且没有属性，因为所有的重点都在于使用 3D 来生成 2D 图纸。
接下来，制造的相关细节被添加到图纸中，而不再添加到零件或模型中——几乎不可能实现可追溯性。
在这种情况下，将 3D CAD 结构导入新 PLM 系统的价值有限。另一种方法是描述和测试在需要时处理遗留数据的程序，无论是实施设计变更还是新订单。让遗留数据可访问，但不要迁移。
从理论上讲，BOM 端对于制造的产品来说是稳定的，因为数据应该经过发布流程。但是，公司需要重新审视其新设计和新产品的零件定义流程。
需要考虑的几点：
PLM 系统中不需要有意义的标识符，因为它们会造成遗留问题。因此，导入带有智能标识符的零件时，除了 ID 之外，还应映射到相关零件属性。将 ID 拆分为属性将在未来产生更广泛的用途。更多信息请参阅智能零件编号 - 我们需要它们吗？
此外，公司应尽量避免使用来自 CAD 系统的物流信息，例如特定于供应商的零件编号。当供应商零件过时时，CAD 环境中的供应商零件会导致效率低下。在迁移过程中，应充分理解 EBOM 和 MBOM 以及可能的 SBOM 等概念。
当从 ETO 转向 CTO 方法或模块化成为未来的业务战略时，也应该引入 EBOM 和 MBOM 的概念。
结论
由于每家公司都在进行 PLM 之旅，而且技术也在不断发展，因此迁移讨论总是会展开。了解未来并着眼于未来应该是迁移的最关键驱动力。PLM 领域的迁移通常不仅仅是数据迁移——还应同时引入新的工作方式。因此，“大爆炸”通常成本过高，而且会打击未来的积极性。
