点击上面↑“Teamcenter笔记”关注，回复“MES”"Teamcenter"领资料！
| 数字孪生 | 最佳实践 |
| 选型指南 | BOM方案 |
| 变更管理 | PLM资料 |
| ERP资料 | MES/MOM |
| SCADA资料 | IIOT资料 |
| 工控基础 | 职业发展 |
近年来，我帮助多家公司制定了 PLM 战略。好消息是，这些公司首先讨论的是 PLM 战略，而不是立即讨论 PLM 系统选择。
此外，PLM 策略不应孤立地定义，而应作为更广泛的业务策略的一个组成部分。我最喜欢的一句话是：
“我们是在实现过去，还是在实现未来？”
当公司实施过去的策略时，感觉就像他们利用新技术和新能力来现代化当前的工作方式。新的环境更容易向公司里的每个人解释，甚至可以解决迁移问题，因为迁移可能是可控的。
注意：应始终考虑迁移问题 — — 这是房间里的大象。
现在实施 PLM 应该成为您业务战略的一部分。
来自不同类型竞争对手的威胁、必要的可持续性相关法规（例如CSRD 报告）以及积极的一面，新的机遇正在到来（例如产品即服务），所有这些都要求您的公司适应产品、服务甚至商业模式的变化。
假设你的公司希望从数字孪生和人工智能等概念中受益。在这种情况下，它需要一个数据驱动的基础设施——
数字孪生并不依赖文档运行，算法需要可靠的数据。
PLM 领域的数字化转型意味着结合协调和互联的工作方法。换句话说，您需要构建基于记录系统和参与系统的基础架构。关注我博客的人应该熟悉这些术语。
PLM不再是研发和工程解决方案
仍然存在的最大误解之一是 PLM 是由主要由研发和工程部门使用的单一系统实施的。这些部门被视为产品数据的传统创建者——这是一个合乎逻辑的假设，当时 PLM 更像是一个孤岛，使用 CAD 和 BOM 数据管理项目。
然而，这种误解将许多讨论引向了讨论什么是最适合我所在学科的系统，这或多或少地加强了组织中的孤岛。能够打破孤岛是数字化带来的技术能力之一。
业务和 IT 架构密切相关。也许你听说过康威定律：
“任何设计系统（广义定义）的组织都会产生一个设计，其结构是该组织的沟通结构的副本。”
这意味着，如果您计划实施或改进 PLM 基础设施而不考虑组织变革，您将再次陷入传统的工作方式 - 协调方法。
组织变革会影响中层管理，这是我们经常忽略的一个重要类别。这涉及到 C 级愿景和最终用户的声音。中层管理必须与他们建立联系，同时又不让他们觉得自己的工作有风险。
我们如何适应业务？
业务转型的最大挑战是它从原因开始，并且应该得到组织各个层面的理解和支持。
如果没有明确的变革愿景，却不断努力提高效率，您的公司就会面临风险！
60 多年来，企业已经习惯于采用协调的方式开展工作，从纸质交付到电子交付。
您如何激励您的组织向相对未知的方向发展？
您的组织中哪些人能够构建数字愿景和战略？
这两个问题是根本性的，你不能将其所有权外包。
转型团队中的人员需要具备数字技能（而不是极客）、沟通能力（讲故事的人），而且非常重要的一点是，要与业务紧密联系。
候选人通常来自现有业务部门，他们具备公认的技能。挑战在于培训他们，让他们能够胜任这项任务。
数字化转型并不是一份副业。
教育可以来自外部世界。让人们参与到新的数字基础设施建设中来是一项管理决策，也是他们的优先考虑。
如何获取外部支持？
如果您和我一样与 PLM 世界有联系，那么有很多信息可供参考。在学术论文、项目，尤其是 LinkedIn 上，目前充斥着大量关于架构的争论：
这些文章的挑战在于，它们只针对内部人士，无法与商界人士分享。我们总是会进行讨论，因为我们都在学习将理论与现实相结合。例如，Jörg W. Fischer 教授介绍了信息架构作为缺失环节：
所有这些方法要么侧重于数据架构，要么侧重于业务架构。盲点在哪里？我确信两者之间缺少一个必不可少的层。在 STZ-RIM 重塑信息管理中，我们称之为信息架构。
尽管如此，我们仍然处于专家领域，只有有限的一群人能够理解。我们需要与业务联系起来。我们在哪里可以找到更多来自业务方面的教育？
在我看来，下面其中一个讨论中的反应说明了一切：
从业务出发
我从与管理层的讨论中了解到：
不要提及 PLM – 您将被困在研发/工程框架中。
不要解释他们的问题，告诉他们你有解决方案（在 PowerPoint 上）
激发对与业务相关的主题的好奇心——如果……会怎样？
用讲故事的方式想象未来的状态——省去细节。
建立信任和信心，让您知道您不是在销售产品。让公司发现他们的需求，因为这是他们的转型。
下图描述了这一切：
这将是一个持续迭代的过程，从商业价值和目标开始，分析实施步骤、它如何适应 PLM 格局，以及最终措施和行动如何指导工具和技术的实施。
需要强调的是，这不是系统实施的指南，而是数字化转型之旅的指南。因此，图片中间的信息是：长期执行承诺！
尽管我们的世界尚未交集，但机械产品和软件的管理有所不同；他的原则越来越适合现代数据驱动的组织。我常常觉得我们在为指导公司进行业务转型而进行着同一场战斗。
在本文的背景下，我建议回顾一下来自软件领域的BAPO 模型。
BAPO 代表业务、架构、流程和组织。如下图所示，您应该从业务开始，定义架构需求，然后定义首选的工作方式。最后，必须根据流程建立组织。
公司通常会采用 OPAB 方法，这让他们感觉更舒服（康威定律）。
商业和技术
最后，我想讨论一下如何将业务和技术连接起来，因为两者都需要。尽管讨论最初侧重于技术能力，但我们最终将其与业务转型需求联系起来。下图是我们用来解释记录系统（垂直支柱）和参与系统（水平条 - 模块化）之间相互作用的特色图像。
看看下面的业务讨论：
接下来，下面的图表来自麦肯锡的一份白皮书：走向集成技术运营模式。在这里，作者描述了一家公司如何使用协调和连接的技术走向集成技术运营模式。
他们没有提到 PLM；他们关注的是业务，而且必须提到公司可以采用不同的模式工作。这是组织的选择，但不要让人们同时采用两种模式工作，
结论
我希望通过这篇文章，将重点从技术和工具转移到可以理解的业务重点，这使得我们的 (PLM) 任务如此复杂和有趣。
