去年年底接了个制造业客户的项目，做升降桌的。产品看着不复杂，但客户需求五花八门：桌面有3种尺寸、4种颜色、3种升降行程、2种控制面板、要不要线缆管理槽、要不要USB接口，排列组合下来，光成品物料编码就建了小一万个。

供应链总监跟我吐槽："每次来新订单，我的人得在系统里翻半天物料号。找对了还好，找错了就是一整批返工。ERP里的物料主数据比仓库里的货还多。"

我听完笑了笑。这不就是变式配置（Variant Configuration，简称VC）的经典场景嘛。一个可配置物料号搞定所有组合，Super BOM把所有可能的组件挂在一张清单上，销售订单输入特性值，系统自动选出正确的组件。客户听完两眼放光。

但说实话，VC这东西，用好了是利器，用不好是灾难。我见过太多项目把VC配得跟迷宫似的，最后连自己都走不出来。今天就聊聊这个话题。

什么是变式配置？你其实天天在用

先说个大家都能get的类比。

你去吃火锅，菜单上写着：锅底选一种（麻辣/番茄/菌汤/清油），肉类选若干，蔬菜选若干，小料自助。你不会因为"麻辣锅底+牛肉+毛肚+莲藕"这种组合就要求店家专门建一个菜品编号吧？你只要在菜单上打勾，后厨自然知道给你上什么。

VC的逻辑一模一样。

在S/4HANA里，变式配置的核心要素就三个：

特性（Characteristic），就是菜单上的选项。比如"桌面尺寸"是一个特性，可选值是1200mm、1500mm、1800mm。事务码CT04创建。

类（Class），把相关的特性打包到一起。比如"升降桌配置类"里面包含桌面尺寸、桌面颜色、升降行程、控制面板类型这些特性。事务码CL02创建。

依赖关系（Dependency），就是规则。比如"选了1800mm桌面就必须用加强型升降柱"，或者"选了电动升降就不能选手动升降"。事务码CU01创建。

还有个配置参数文件（Configuration Profile，CU41），相当于把物料和类绑起来的"婚介所"，告诉系统：这个物料号是可配置的，用这个类的规则来配。

Super BOM：一棵长满选项的树

光有配置规则不够，你还得告诉系统：选了某个特性值之后，到底用哪些原材料？这就是Super BOM登场的时候。

普通BOM大家都熟，一个父物料下面挂一堆子物料，固定不变。可配置物料的BOM不一样，它要把所有可能用到的组件全挂上去，然后通过选择条件来决定哪些组件在实际订单中被选中。

还是火锅的例子。Super BOM就是后厨的"万能备料清单"：所有锅底的食材、所有肉类、所有蔬菜、所有调料，统统列在上面。你点了麻辣锅底，系统自动勾选麻辣锅底的材料包；你点了牛肉，系统勾选牛肉的出库记录。没点的那些，自动排除。

在S/4HANA里，Super BOM的每个行项目可以挂一个对象依赖关系（Object Dependency），写法大概是：

// 当桌面尺寸选了1800mm时，选中这个行项目 $DESK_SIZE = '1800'

意思是：特性DESK_SIZE的值等于1800时，这个行项目被选中。如果客户选了1500的桌面，1800的桌面组件就不会出现在生产订单里。

这就是Super BOM的精髓：一张BOM覆盖所有产品变体，系统根据配置结果自动做"减法"。

后台配置：从零搭建一套VC

这部分我尽量说得接地气一点，不堆事务码。但关键步骤必须提到，不然你真上手的时候会一头雾水。

第一步：建特性（CT04）

先想清楚产品有哪些可配置的维度。升降桌的例子：

• 桌面尺寸：1200 / 1500 / 1800（单位mm）
• 桌面颜色：白色 / 黑色 / 木纹
• 升降行程：600 / 800 / 1200（单位mm）
• 控制面板：基础款 / 智能款
• 线缆管理：有 / 无

每个特性建一个，注意设好数据类型和允许的值。别想着后面再加，特性一旦投入使用再改，影响面非常大。我有一次在项目后期给客户加了个特性，结果已有的销售订单配置全报错，排查了一整夜。

第二步：建类（CL02）

把这些特性全部分配到一个类下面，比如叫ZDESK_CONFIG。类的类型选300（可配置物料用）。这一步比较直接，没有太多花样。

第三步：写依赖关系（CU01）

这是整个VC最容易翻车的地方。依赖关系分几种：

• 前置条件（Precondition）：控制特性值是否可选。比如"只有升降行程选了1200mm，才允许选智能款面板"。
• 选择条件（Selection Condition）：控制Super BOM中哪个行项目被选中。
• 动作（Action）：给特性赋默认值。比如"默认桌面颜色为白色"。
• 约束（Constraint）：限制组合。比如"1800mm桌面不能配600mm升降行程"。

我的建议是：逻辑简单的用选择条件和前置条件就够了，约束留给真正互斥的场景。别什么规则都往约束里塞，到时候你自己都理不清谁依赖谁。

第四步：建配置参数文件（CU41）

把可配置物料和类关联起来。这一步比较简单，但别忘了把依赖关系也挂上去。

第五步：搭Super BOM（CS01）

把所有可能的组件挂到可配置物料下面，每个行项目挂对应的选择条件。这一步是体力活，组件多的时候很容易漏。我的习惯是搭完之后导出一份Excel，和研发逐行核对。

第六步：测试

这一步我单独拿出来说，因为它太重要了。

实战案例：升降桌的配置全流程

回到那个客户现场，我给他们搭了一套完整的VC方案。可配置物料号ZDESK升降桌，一张Super BOM搞定所有变体：

销售在创建订单时输入ZDESK这个物料号，系统弹出配置界面。销售选：1800mm桌面、木纹色、1200mm行程、智能面板、要线缆管理槽。系统自动选出003、006、009、011、012这几个组件，生成一张精确的生产订单。

客户原来小一万个物料编码，现在缩减到1个可配置物料号。BOM维护工作量从"每次新品都要建BOM"变成了"改一张Super BOM搞定"。供应链总监那天请我吃了顿火锅。

不过话说回来，成功的前提是把前面的特性和依赖关系想清楚。我见过另一个客户，自己折腾了三个月，最后Super BOM里有200多个行项目，依赖关系写得跟天书一样，谁都不敢改。后来找到我，我花了两天时间帮他们重新梳理，砍掉了60%的冗余依赖，才算恢复正常。

几个我踩过的坑

干了这么多年SAP，VC的坑我踩了个遍。分享几个最常见的。

坑一：特性越建越多

刚开始做VC容易上瘾，什么都想做成可配置的。桌面尺寸、颜色、行程这些核心维度没问题，但有些客户连"包装箱上印不印logo"都想做成特性。特性太多，维护成本指数级上升，最后自己也搞不清每个特性的作用。

我的经验是：只在真正影响BOM结构和工艺路线的维度上用VC。外观文字类的需求，用销售订单文本处理就行，别硬塞进VC里。

坑二：依赖关系不写注释

这个我真的要吐槽。有些顾问写依赖关系的时候不写注释，过了半年自己都看不懂。好的依赖关系应该自带说明：

// 1800mm桌面必须搭配1200mm升降柱 // 否则桌腿露出来不好看，客户投诉过 $DESK_SIZE = '1800' implies $STROKE = '1200'

多花十秒钟写注释，能省你十个小时的排查时间。血泪教训。

坑三：忘记考虑库存

VC的配置结果会生成生产订单，但你得想清楚：选出来的组件有没有库存？采购周期够不够？有些客户Super BOM搭好了，配置也通了，结果到了生产环节发现某个关键组件缺货，整个订单卡住。

建议在Super BOM搭建阶段就和采购部门对一遍，确保所有组件的供应计划是可行的。别等到生产车间打电话找你要料的时候才发现问题。

坑四：不做好版本管理

产品更新换代的时候，Super BOM要改，特性值要改，依赖关系也要改。如果没有好的版本管理机制，改完之后历史订单的配置可能对不上。S/4HANA有工程变更管理（ECM）可以用，一定要配合起来。不然你改了Super BOM，上个月的订单重新展开发现组件变了，财务月结的时候有你好看的。

· · ·

写在最后

变式配置这个功能，说难不难，说简单也不简单。核心就三句话：想清楚产品有哪些可配置维度，把依赖关系写干净写明白，Super BOM的行项目逻辑要对齐。

但真正难的是业务理解。你得搞清楚客户产品的工程逻辑，知道哪些组合合理、哪些不合理，这需要和研发、生产、采购反复沟通。做SAP顾问这些年，我最大的感触是：技术工具再好，也替代不了对业务的深度理解。VC尤其如此。

如果你正在做制造业的S/4HANA项目，产品又有很多变体，建议认真考虑VC+Super BOM的方案。前期投入大一点，但后期维护成本会低很多，长远看是值的。

做项目这种事，没有银弹，只有适合不适合。VC不是万能的，但在产品配置这个场景里，它确实是目前最成熟的方案。

阅读原文：原文链接