产品生命周期管理（PLM）供应商承诺其系统性能十分出色，企业组织可从初始阶段开始使用系统，这将彻底改变他们定义和管理产品数据的方式。但是，只有愿意为了PLM系统中预先实施的最佳实践而改变其自身内部标准和程序的企业组织才适用于此情况。所有其他企业组织则必须依靠配置和定制。它们之间有何区别？如何确保它们在将来不会成为风险、缺点或弱点？请继续阅读，找出答案。
OOTB
OOTB（或“开箱即用”）是安装系统后立即可供用户使用的一系列功能。
对于PLM系统的情况，OOTB表示一组预定义的要素，例如：
- 标准用户界面，具备浏览和搜索功能
- 数据模型（对象类型、其属性/参数）
- 生命周期
- 工作流
- 对象模板（包括产品模板，配备角色和安全性定义）
这些要素基于某些工业标准和最佳实践创建，PTC Windchill等更大型、更成熟的PLM系统尤其如此。它们由其创建者和世界上最优秀的大学中一些最聪明的人再加上实际的客户共同定义，经由多年的系统使用和实践经验得到的成果。系统中最初被认为是定制的某些东西逐渐进入核心产品，成为了“OOTB”。
大多数软件提供商都吹嘘说其软件“即开即用”，已为应对任何公司的任何挑战做好了准备，但没有几家能说到做到。想想看：办公软件套件（包括字处理软件、电子表格编辑软件、演示文稿编辑软件等）。不管是哪一家的产品，它们的工作原理都相似（即使用户界面（UI）或您可以使用的动画类型可能有些许差异，但整体“感觉”是一样的）。
但是，对于PLM的情况，并没有“包打天下”的解决方案。OOTB（或“原生”）系统不太可能在“任何”组织中都得到有效利用。特别是规模更大和/或历史更久的公司，他们都有自己发展出来的工作方法，这些方法已被证实有效，不应为适应系统而受到改动，而是应该对系统进行变更，使其适应这些方法。我们认为重要并决定存储在PLM系统中的数据和元数据，在不同企业组织中各不相同，给它们指定的角色和访问控制规则也是如此。这些方面和许多其他事情通常需要在“原生”PLM系统中加以改动，然后对于组织才真正有用，这就是配置和定制发挥作用的地方。
尽管这两个词听起来类似，但是它们在含义上显著不同。让我们从定义这两个词的含义开始——使用尽可能简单的术语。
什么是配置？
在PLM系统中，配置涵盖了从“用户界面”角度可以对产品进行的所有改动。PLM供应商通常附送配置工具，允许您在一定程度上更改系统行为。其中包括的内容，比如：
- 对数据模型的改动，包括新对象类型的定义和描述它们的属性
- 生命周期和生命周期状态的定义
- 工作流的（部分）定义
- 对象模板（产品、库等）的定义——包括容器中的角色和访问控制规则的定义
- 通过偏好设置的系统行为管理
某些人还将对系统属性值的潜在修改（就Windchill来说：更改.property文件内部的开放式文本值）作为配置包括在内，但为了清楚起见，当前我们不将其包含在这个类别中。
换句话说，配置是一种对系统的修改，它不需要对系统源代码的访问、修改、实现等[1]。因此，许多人还认为配置软件的能力（以及由此而来的配置本身）是OOTB功能的组成部分。
系统版本之间通常支持配置，因此，如果您升级PLM系统，通常不必担心需对配置进行相应升级以适应新版本。
[1]是的，配置通常可从系统中导出（用于将其导入到另一实），之后它以XML或可能包含代码的其他文件的形式呈现，但是您不必实际“接触”该代码：即打开文本编辑器并编写任何内容。您只需将其“导出”再“导入”，无需实际查看这些文件。
什么是定制？
另一方面，定制就是除配置之外的所有内容。定制是任何需要改动或扩展系统源代码的系统变更（即实现、开发），因为仅通过配置不能获得所需的结果。在大多数情况下，定制的示例包括：
- 侦听器（在给定事件发生时触发特定操作/系统行为的触发器，例如“变更通知”完成时的自动发布等）
- 新用户行为和向导
- 工作流（某些情况下）——Windchill允许您编写代码，因此当您在运行工作流时想进行一些自定义处理，您可以这样做
- 系统集成——很遗憾，PLM几乎所有的系统集成都是定制的
- 一些高级业务报告的案例
- 附加业务规则的各种实现
尽管如此，这里并没有列举出所有可能的定制。作为Windchill开发人员，在多年工作中，我看到人们就引入新的/自定义功能方面对系统做了很多……甚至还有更多我目前还未见过的……
包括PLM在内的软件系统通常有自身的生命周期，供应商会不时对其进行升级。PTC Windchill在此也不例外，它具有为未来几年详细设计的路线图。将系统升级至更新版本时，永远都不该假设您的定制将正常运行。系统供应商对其核心产品进行了升级、改动等操作，可能使部分定制内容变得没有必要，并且其中的某些部分处理的可能是核心产品中不再存在的代码段（或之前由其实现的功能），这可能在您的PLM系统上造成各种各样的混乱。每一次系统升级，如有定制存在，都应考虑所需的验证工作，来验证定制内容与新版本及（必要时）其升级版的兼容性。让我们来作一个比较，“原生”系统的升级有时会在几小时内完成。如果存在复杂、大量的定制，这个时间可能是数月甚至数年（是的，我见过这样的情况）。
配置和定制之间有何区别？
如您所见，配置和定制之间的主要区别在于前者通常可以通过系统界面来实现，而后者则需要程序员编码实现新的/更改过的功能。遗憾的是，情况并非如此简单。
即使是导出到一组文件中（用于部署到另一系统中），配置通常相对来说容易管理：只需跟踪您作出的一系列更改，千万不要手动修改导出的文件[2]。
与编程的大多数情况一样，定制可能（通常情况下确实如此）更为复杂，并应进行妥当的管理。否则，对其进行部署会导致系统中充满缺陷和错误，甚至根本无法启动（！)，从而导致无法使用，并因此浪费大量金钱和人力。
[2]在理想世界中就是这种情况。在现实世界中，有时确实需要修改配置文件，这些文件通常是XML。尽管如此，这样做仍不会影响核心应用程序的代码。
因此，您应依靠两样东西：
- 系统供应商——毕竟，不管是谁打造的系统，总是造它的人最了解（假设它的代表在描述系统按照OOTB并通过配置能做什么和不能做什么说的都是实话）
- 独立合作伙伴、系统集成商、增值经销商等（例如Transition Technologies PSC）可以帮助您评估需求并确定可以做什么
在您的组织中实施PLM系统时，合作伙伴应是您的最佳资产。通过多年与其他客户的合作，这样的合作伙伴对他正在使用的工具理应具备深入的了解，不仅能告诉您系统是否能像您想要的那样发挥作用，或许还能提出建议：告诉您丢弃其功能并开发您自己的功能是否确实明智。
我应该如何管理定制？
软件开发和系统操作（通常称为DevOps）可能是一个非常复杂的主题，产品生命周期管理系统也是如此。如果我在这里详细介绍，本文就会成为一篇有关PLM的DevOps最佳实践的长篇大论，因此我将在这里长话短说，只介绍一些必要细节：
- 使用用于您源代码的版本控制系统（最好是Git或等效系统）
- 使用Atlassian Jira或PTC Windchill RV&S（前Integrity，作为一套应用程序生命周期管理[ALM]系统）这样的系统来跟踪开发进度、任务、问题、用户案例、冲刺阶段等。
- 将以上两者紧密整合，让并非在特定工单上工作的人员无法修改存储库中的任何内容。
- 使用对任何自定义代码的自动测试（至少是单元测试）。
- 使用自动环境创建（如果可能——大大简化流程和缩短时间）并构建类似于Jenkins的部署工具。
- 将自动化工具与测试、源代码以及ALM系统紧密集成。
- 使用多重验证环境（例如：程序员在开发人员系统中编写代码，测试人员在测试系统中进行测试，最终用户验收测试在QA系统中完成——最后，在生产过程中不做任何改动，除非对正式发布计划的一部分进行跟踪、管理和验证）
我敢打赌，如果系统使用了定制，那么它也具有配置功能。在这种情况下，从开发系统中导出后，配置也应作为上述过程的一部分进行管理——这将确保整个系统的部署连贯平顺，所有问题都在早期被发现并得到解决。
显然，以上流程已被大大简化。即使如此（或者正因如此），一些组织还是决定不遵循这个流程，在开发PLM定制时冒很大的风险。依我所见，这样的情况总会以灾难性的结局告终[3]，因此，若想避免卷入灾难，请未雨绸缪，确保您的PLM服务提供商采用了正确的DevOp技术。
[3]是的，永远如此。或迟或早，但永远是这样。
配置与定制
阅读至此，您可能会觉得自己应该回避任何类型的定制：它们通常很复杂、有风险且高成本。基本上是这样：能够使用具备某些（甚至很多）配置的OOTB产品实现，就应用这种方式实现。毕竟，大多数PLM供应商都试图将尽可能多的灵活性整合到产品和解决方案中，所以您不必定制。
但是请记住，即便是最好的PLM系统，也无法完全按照您对它们的预期运行所有功能，因此会需要进行一些改动。如果PLM销售人员曾试图说服您，他的PLM产品安装好后就可完美贴合您的（以及其他各项）业务，那么让他走好不送。
是否存在定制过多这样的问题？
是的，有的。我见过拥有上万个自定义类的项目，从几十行到数千行代码不等。在以前这是可管理的，但基本上做不到。管理众多程序包之间的依赖关系慢慢成为噩梦，跟踪需求变更和由特定人员开发的一段代码等问题曾几乎是无法实现的。在每次发布之前，测试和调试解决方案需花费数周乃至数月的时间。
接着是系统升级，它更改了定制系统的核心代码……
（无需多说，在深度去定制化前，对升级该系统不要抱任何希望。）
如今，供应商发布新系统版本的频率前所未有。如同实体产品一样，软件“产品生命周期”也缩短到了一些版本仅仅被支持几个月的地步。客户现在必须决定是想使用最新功能（并频繁升级）还是安装长期支持（LTS）版本。当然，升级越频繁，确保配置及（特别是）定制继续按预期发挥作用需要花费的时间就越长。
但是，如果确实需要大量改动您的PLM系统，并非全部只有损失。有一种方法可以管理和维护即使是大量而复杂的定制：DevOp。如果能够得以正确实施，此概念将大大简化多项流程，并有助于保持解决方案的高品质，即使是在进行了重大改动的情况下。它并不能解决所有挑战，但会有所帮助。很多帮助。
我是否可以定制云托管的PLM系统？
可以，也不可以。让我来解释一下：
如果您决定以SaaS（软件即服务）的形式购买PLM系统，那么系统的供应商将负责所有后端工作：设置服务器、安装和维护系统、执行升级等。不过，您作为客户很少（如果有的话）会有权限访问运行PLM应用程序的实际操作系统（OS）。由于您没有访问操作系统的权限，因此无法部署自定义类/代码。您必须依靠SaaS提供商进行任何变更部署。一些提供商需要冗长繁琐的过程来部署甚至是很小的变更，因此请仔细选择您的合作伙伴，并询问他们部署程序。
第二种方法需要花费明显更大的精力，更不用说需要对云解决方案有深入的了解，尤其是当您想获得令人满意的自动化水平时。幸运的是，这正是您可以依靠PLM合作伙伴为您提供帮助的地方。根据汽车行业的真实示例，亲自了解如何在轻松实现SaaS级自动化（或更多！）的同时，利用公共云来托管您的Windchill系统：
<嵌入的TTPSC记录视频，LiveWorx提供：
结论
尽管“应该不惜一切代价避免定制”说出来很容易，但在PLM的世界里，“包打天下”并不存在。尽管有些机构可能确实从使用OOTB PLM系统中获益，但很难期待他们中的大多数放弃他们的原则和工作方式——正是这些因素使得这些公司在一开始就如此卓越。虽然确实应该以定制最小化为目标，但如果采用适当的流程，即使是大规模的定制也可以得到有效管理。最终决定是要进行配置还是定制（甚至是特定的PLM产品）应是基于您所在组织的真正需求和要求而做出的明智决定——最好的情况是获取可信合作伙伴的广泛知识和经验的支持，他们在之后便可执行计划。寫