ERP/MRP 系统如何处理产品变体（选项）？
How do ERP/MRP systems handle product variations (options)?
这个问题围绕着如何在现成的 ERP/MRP 系统和其他系统（包括定制开发的程序或模块）之间划分业务功能。我们可以构建后者，但如果现成的可以避免定制工作、维护等，为什么要这样做呢？
我希望了解的领域是 ERP/MRP 系统是否通常在产品结构（变体和选项，更不用说相同的版本控制）上充当企业权威，如果是，多么精巧。
举一个具体的例子，一家公司生产各种电子设备，其中一种是笔记本电脑。与戴尔或联想一样，笔记本电脑产品线包含一个基本型号，然后是一组选项或变量，每个选项或变量提供两个或更多选择。示例：笔记本电脑提供屏幕选项（高分辨率；低分辨率；TFT；OLED）和电池选项（标准；高容量），等等可能有几十个功能区域。有些选项本身可以有附属选项。
我看到一些 ERP/MRP 系统包含 "Configurator" 功能，可以为销售人员（或在线的最终客户）提供所有这些产品选项和他们的选择，以允许他们配置特定产品购买、组装和交付。
但在我更仔细地观察过的某些系统中，在配置器 UI 中，可用选项基本上是硬编码的（好吧，由程序员在程序语句中编码），link 到需要组装以制造配置产品的 BOM 项目。 Configurator 基于程序语句而不是由数据驱动。
[编辑：这里我的意思是配置器屏幕是用自定义代码编程的，可能由企业的程序员或顾问编写。未由 ERP 供应商修复编程。]
而且由于该产品结构信息是作为程序代码捕获的，因此它不容易用于其他目的，例如报告、link连接到 PLM 等其他数据、目录、协调内部配置器和 Web-面向电子商务或B2B等。
现在很难评估该行业的当前状态，因为许多供应商只有在参与销售过程后才会提供这种级别的产品洞察力，即使是在深入挖掘非技术层面之后销售人员.
所以我希望这里的其他人可以阐明管理产品结构数据的问题是否通常被纳入至少某些 ERP/MRP 系统，或者通常期望在外部处理其他方式？
（出于此问题的目的，假设 ERP/MRP 为低于 5000 万美元范围内的企业提供的系统，即 II 级或以下。）
这是一个笼统的问题，所以答案也是笼统的，并且包含个人意见：
我很少发现编码到程序中的产品结构信息。这可能是非常小的发展情况，或者只是 最糟糕的策略 。在程序中编码产品结构是犯罪。任何标准的 MRP/ERP 解决方案都无法通过这种方法生存，除了一些微小的实施之外，所以让我们放弃并忘记这种方法。
大多数 ERP/MRP 解决方案都是基于 SKU、项目代码或材料的概念。这就是可配置产品的问题所在。由于供应商必须将其销售给不同的客户（在相同或什至不同的行业 - 例如电缆、纺织、汽车、电子），他们必须：
- 提供结构来映射特性/属性/属性/组件
- 提供结构来映射可能的选项、值、度量、这些特征的限制等
- 提供这些值到组件的映射（这可以是简单的或再次可配置的 material）
- 提供灵活性，以便在 运行 时输入可能的值，并有必要的限制，有时还带有测量单位
- 提供特性/选项/组件/操作的依赖性
- 根据库存和可用性、计划时间表、生产能力等实施业务规则
大多数标准 ERP 解决方案都提供专用但通用的功能，通过组合 SKU、配置和物料清单、SOP（配方或工艺路线）来映射这些功能。此功能的 泛化 有助于覆盖更多行业，但势必会弄乱 table 结构、代码库和标准报告。如果您在领先的 ERP 解决方案之一中查看可配置产品的相关 table 结构，您会惊讶地发现地毯下的低效率（CODD 会哭！）。在大多数大型实施中，复杂性和体积都在增加，而这些 ERP 无法处理这一切。因此，他们有专门的优化器或规划器解决方案来处理预测和 material 规划。您会发现来自同一供应商的通用优化器或 certified 第三方插件。
到时候，客户场景被映射到实时环境中，每个依赖的功能和报告都会出现功能失调！客户不理解问题，供应商根据过去的经验知道答案（但对不知情的客户隐瞒）——更多的计算资源！供应商往往会掩盖这些低效问题，并建议使用功能强大的服务器、负载分配和平衡以及类似技术。这样下去，客户会在这个过程中不断学习。
其他一些ERP/MRP供应商选择不一概而论，而是专注于一个行业，获得一个行业或非常相似行业的信心。这种区别（相同或相似行业）是棘手的——在纱线纺织品中有效的方法可能不适用于原布纺织品，而在原布纺织品中有效的方法可能不适用于 ready-to-wear 纺织品！所有产品都有选择，属于纺织行业。纺织、汽车、造纸行业有许多规模较小但重点突出的解决方案，在该行业中运作良好。该功能通常被巧妙地实现，但仅限于一个行业。由于这些解决方案已经专注于单一行业，因此性能总体良好且资源需求适中。
最后，客户可以决定自己动手进行定制开发。您将再次查找客户的产品规格并提供 table 结构来涵盖这些变体。但永远不要在程序中编写产品结构或选项，即使是最小的实现 - 使其成为 table 驱动的 。除非在这些开发中部署了非常好的功能和技术资源，否则它们很可能永远处于开发阶段。
具有变体和选项的产品不是一个简单的场景。无论您是寻找标准的 ERP 解决方案、行业解决方案还是定制开发，您都需要进行大量研究，而其中一些知识只有通过经验才能获得。我有理由相信 少于 5000 万美元 边界在上述情况下是次要问题。我已经看到并参与了所有三种类型的解决方案（具有变体配置的大型 ERP 解决方案、行业解决方案和优化器；来自中等供应商的以行业为中心的解决方案和第三方定制解决方案开发团队以及 in-house 开发团队；专用行业优化器集成在自定义解决方案中）并且都有其 优点 和 缺点 。 每个实施 都需要仔细评估。
如果你问我的经验，标准的 ERP 解决方案（可能你知道我指的是什么）通常是不适合流程 -like 行业（纺织、造纸、包装），但在某种程度上合理 -like 行业（汽车、电子、装配） .来自专注供应商的行业特定解决方案可能是最有效的解决方案，如果行业有的话！为具有可配置产品的行业定制 ERP 开发不亚于生孩子 - 过程中需要大量计划、精力和痛苦，但最终是一个幸福的家庭 - 如果生孩子，结果更可预测table ，在定制解决方案开发的情况下更少。 我是两个这样的孩子的幸福父亲！二胎果然更健康更强壮了！！.
So I'm hoping that others here can shed some light on whether this matter of managing product structure data is customarily incorporated into at least some ERP/MRP systems, or is it generally expected to be handled externally in some other manner?
是的，大多数合理 ERP 系统都能够映射产品选项。基于仅计划 SKU 的 ERP/MRP 解决方案仅适用于具有少于数百个变体和组合的较小行业。在 MRP 方面，大多数 ERP 系统都依赖 add-on 可配置产品解决方案。
这个问题围绕着如何在现成的 ERP/MRP 系统和其他系统（包括定制开发的程序或模块）之间划分业务功能。我们可以构建后者，但如果现成的可以避免定制工作、维护等，为什么要这样做呢？
我希望了解的领域是 ERP/MRP 系统是否通常在产品结构（变体和选项，更不用说相同的版本控制）上充当企业权威，如果是，多么精巧。
举一个具体的例子，一家公司生产各种电子设备，其中一种是笔记本电脑。与戴尔或联想一样，笔记本电脑产品线包含一个基本型号，然后是一组选项或变量，每个选项或变量提供两个或更多选择。示例：笔记本电脑提供屏幕选项（高分辨率；低分辨率；TFT；OLED）和电池选项（标准；高容量），等等可能有几十个功能区域。有些选项本身可以有附属选项。
我看到一些 ERP/MRP 系统包含 "Configurator" 功能，可以为销售人员（或在线的最终客户）提供所有这些产品选项和他们的选择，以允许他们配置特定产品购买、组装和交付。
但在我更仔细地观察过的某些系统中，在配置器 UI 中，可用选项基本上是硬编码的（好吧，由程序员在程序语句中编码），link 到需要组装以制造配置产品的 BOM 项目。 Configurator 基于程序语句而不是由数据驱动。
[编辑：这里我的意思是配置器屏幕是用自定义代码编程的，可能由企业的程序员或顾问编写。未由 ERP 供应商修复编程。]
而且由于该产品结构信息是作为程序代码捕获的，因此它不容易用于其他目的，例如报告、link连接到 PLM 等其他数据、目录、协调内部配置器和 Web-面向电子商务或B2B等。
现在很难评估该行业的当前状态，因为许多供应商只有在参与销售过程后才会提供这种级别的产品洞察力，即使是在深入挖掘非技术层面之后销售人员.
所以我希望这里的其他人可以阐明管理产品结构数据的问题是否通常被纳入至少某些 ERP/MRP 系统，或者通常期望在外部处理其他方式？
（出于此问题的目的，假设 ERP/MRP 为低于 5000 万美元范围内的企业提供的系统，即 II 级或以下。）
这是一个笼统的问题，所以答案也是笼统的，并且包含个人意见：
我很少发现编码到程序中的产品结构信息。这可能是非常小的发展情况，或者只是 最糟糕的策略 。在程序中编码产品结构是犯罪。任何标准的 MRP/ERP 解决方案都无法通过这种方法生存，除了一些微小的实施之外，所以让我们放弃并忘记这种方法。
大多数 ERP/MRP 解决方案都是基于 SKU、项目代码或材料的概念。这就是可配置产品的问题所在。由于供应商必须将其销售给不同的客户（在相同或什至不同的行业 - 例如电缆、纺织、汽车、电子），他们必须：
- 提供结构来映射特性/属性/属性/组件
- 提供结构来映射可能的选项、值、度量、这些特征的限制等
- 提供这些值到组件的映射（这可以是简单的或再次可配置的 material）
- 提供灵活性，以便在 运行 时输入可能的值，并有必要的限制，有时还带有测量单位
- 提供特性/选项/组件/操作的依赖性
- 根据库存和可用性、计划时间表、生产能力等实施业务规则
大多数标准 ERP 解决方案都提供专用但通用的功能，通过组合 SKU、配置和物料清单、SOP（配方或工艺路线）来映射这些功能。此功能的 泛化 有助于覆盖更多行业，但势必会弄乱 table 结构、代码库和标准报告。如果您在领先的 ERP 解决方案之一中查看可配置产品的相关 table 结构，您会惊讶地发现地毯下的低效率（CODD 会哭！）。在大多数大型实施中，复杂性和体积都在增加，而这些 ERP 无法处理这一切。因此，他们有专门的优化器或规划器解决方案来处理预测和 material 规划。您会发现来自同一供应商的通用优化器或 certified 第三方插件。
到时候，客户场景被映射到实时环境中，每个依赖的功能和报告都会出现功能失调！客户不理解问题，供应商根据过去的经验知道答案（但对不知情的客户隐瞒）——更多的计算资源！供应商往往会掩盖这些低效问题，并建议使用功能强大的服务器、负载分配和平衡以及类似技术。这样下去，客户会在这个过程中不断学习。
其他一些ERP/MRP供应商选择不一概而论，而是专注于一个行业，获得一个行业或非常相似行业的信心。这种区别（相同或相似行业）是棘手的——在纱线纺织品中有效的方法可能不适用于原布纺织品，而在原布纺织品中有效的方法可能不适用于 ready-to-wear 纺织品！所有产品都有选择，属于纺织行业。纺织、汽车、造纸行业有许多规模较小但重点突出的解决方案，在该行业中运作良好。该功能通常被巧妙地实现，但仅限于一个行业。由于这些解决方案已经专注于单一行业，因此性能总体良好且资源需求适中。
最后，客户可以决定自己动手进行定制开发。您将再次查找客户的产品规格并提供 table 结构来涵盖这些变体。但永远不要在程序中编写产品结构或选项，即使是最小的实现 - 使其成为 table 驱动的 。除非在这些开发中部署了非常好的功能和技术资源，否则它们很可能永远处于开发阶段。
具有变体和选项的产品不是一个简单的场景。无论您是寻找标准的 ERP 解决方案、行业解决方案还是定制开发，您都需要进行大量研究，而其中一些知识只有通过经验才能获得。我有理由相信 少于 5000 万美元 边界在上述情况下是次要问题。我已经看到并参与了所有三种类型的解决方案（具有变体配置的大型 ERP 解决方案、行业解决方案和优化器；来自中等供应商的以行业为中心的解决方案和第三方定制解决方案开发团队以及 in-house 开发团队；专用行业优化器集成在自定义解决方案中）并且都有其 优点 和 缺点 。 每个实施 都需要仔细评估。
如果你问我的经验，标准的 ERP 解决方案（可能你知道我指的是什么）通常是不适合流程 -like 行业（纺织、造纸、包装），但在某种程度上合理 -like 行业（汽车、电子、装配） .来自专注供应商的行业特定解决方案可能是最有效的解决方案，如果行业有的话！为具有可配置产品的行业定制 ERP 开发不亚于生孩子 - 过程中需要大量计划、精力和痛苦，但最终是一个幸福的家庭 - 如果生孩子，结果更可预测table ，在定制解决方案开发的情况下更少。 我是两个这样的孩子的幸福父亲！二胎果然更健康更强壮了！！.
So I'm hoping that others here can shed some light on whether this matter of managing product structure data is customarily incorporated into at least some ERP/MRP systems, or is it generally expected to be handled externally in some other manner?
是的，大多数合理 ERP 系统都能够映射产品选项。基于仅计划 SKU 的 ERP/MRP 解决方案仅适用于具有少于数百个变体和组合的较小行业。在 MRP 方面，大多数 ERP 系统都依赖 add-on 可配置产品解决方案。