为了加强商品管理，企业有时需要将各SKU归属至对应的商品OneID中，这个过程里，有可能会出现哪些问题或挑战呢？这篇文章里，作者针对商品OneID项目做了梳理与重构，一起来看看作者的经验分享。

商品SKU、商品体系的管理，对于日化/消费产品主导的公司而言，是至关重要的，由于系统人力等诸多因素，需要将各SKU归属至对应的商品OneID，以加强对商品的管理与分析。

一、商品管理背景及痛点

背景：同一款商品会被单独销售、组成不同的商品组合BOM，或者有不同的活动版本进行销售。不同的版本有不同的价格，折扣等相关信息。如果需要看某个同款商品的商品信息，或者查看对应的销量/销售额数据时，需要单独累计各个商品的数量，对于商品效益分析十分不便。

痛点：

1. 活动方选品时，组BOM需求由各团队提出，相互之间信息独立。核对商品信息，或统计同款商品整体销量时，容易遗漏，核对困难。
2. 活动方选品时，很难拿到过往组BOM数据，不清楚产品与那些产品搭配的销量和效果好，制定组BOM方案的时只能重新规划思考，效率低，没有办法持续提升。
3. 一个产品升级/改版后（容量变化，口味变化，或者年版不同），无法统计/或归属到原来的产品。

二、商品OneID管理目标

1. 形成报表，统计出同款商品数量，分别来自哪些版本，什么活动，哪些产品BOM组合，各自销量情况。
2. 根据报表1的数据，统计产品的贡献率，需要单独统计活动版本或者BOM里面产品的贡献率。
3. 对新品/在售的主产品，逐一核对历史组BOM数据或相关活动版本产品数据，看报表统计是否完整。
4. 基础数据搭建完成后，针对同款商品进行数据分析、管理，控制同款商品参与活动的次数和折扣力度，使商品效益最大化。

三、商品管理梳理-单品&套装

1. 商品管理维度

目前主流商品管理维度：包括商品分类/商品属性/商品信息/商品图片/商品库存/商品资质；具体如下图所示：

2. 商品分类管理痛点

1）当前商品分类管理不统一

商品管理维度以SKU为主，SPU仅作为辅助管理维度，未将SKU与SPU做对应归属（如91002-01巧克力，未归入对应SPU）。

2）套装与单品归属于不同SKU

鉴于财务核算的贡献不同，礼盒与单品SKU未有统一的SPU归属（如巧克力礼盒vs巧克力单品SKU不同，未将礼盒SKU的贡献计入巧克力单品中）。

3. 商品OneID归属逻辑梳理

1）所有商品SKU挂靠SPU，同时将属性、功效相同的商品归为同款商品OneID。

2）考虑在代码前几位做SPU归属定义。如产品SPU可以采用8位码（6位分类码+2位随机码），商品SKU可以采用SPU码+2位递增码（如91201-01为巧克力的SPU，91201-01-01为巧克力小份体验装90g常规款的SKU）。

四、商品管理梳理-BOM组合

1. 商品BOM组合的分类现状

组BOM两大类型：常规BOM与活动BOM。活动BOM的折扣类型：商品折扣/电子券折扣/赠品折扣。

2. 商品BOM组合的产品构成

1）主力型产品：属于产品角色之一，指公司自主研发，具有良好市场认知度和消费基数，在品牌内销售排名前5的产品，如图中P1；

2）产品组合：公司主要战略下的产品组合，如图中P2；

3）计划升级/退市产品：本年度有升级/品牌切换/退市计划的产品, 如图中P2和P6；

4）具有短龄风险的产品:

如图中P3、P4/P5/P7分三个级别：

• 一级短龄风险产品：“120天＜距短龄期天数≤150天”的产品。
• 二级短龄风险产品：“90天＜距短龄期天数≤120天”的产品。
• 三级短龄风险产品：“距短龄期天数≤90天”的产品。

3. 组BOM机制和确定流程

目前商品BOM的管理现状：

1）组合类型较明确，分常规/活动BOM；针对活动BOM的折扣类型管理较明确；BOM适用的主要渠道较为明晰。

2）审批流程较明确，产品研发/商品中台/IT开发/财务参与涉及各职能环节，流程规范。

3）各需求方，前期就BOM或活动方案，与产品研发/财务沟通，确认具体组合产品/产品的价格和效益；确认后在商品中台，对BOM信息进行维护，经IT维护补充BOM信息和属性后，可进行上架。

痛点：

1）需求方众多，各需求方提方案给产品研发，在BOM的确认机制上未形成统一规范。

2）BOM的数据治理/效益反馈有所缺失，活动BOM的运营数据/财务指标未形成组织过程资产，未能反哺后续BOM的管理。

下架产品BOM代码失效后未清理，一直占用数据中心代码，数据堆积冗余。

4. BOM的管理目标

目标一：管理商品更简单

组合BOM仅可从商品分类属性中选择属性项，就单个SKU组合成对应BOM的SKU，且该SKU需从属于唯一SPU（如果有两个主产品，可根据贡献率确定归属的SPU和商品OneID）。

目标二：完善/目标品类

从商品管理角度考虑，组BOM可考虑：消库存搭配/活动搭配/新品推广，扩大缩小产品广度/深度/密度/长度/产品线延伸。

目标三：配合活动玩法，使BOM搭配标准化

配合活动玩法有不同的BOM组合可选，如降价、满减、秒杀、预售、优惠券、满减折扣、N元任选、买赠、拼团、搭售、免单、抽奖等。

目标四：BOM的产品数量和类型规范

如1+1主辅组合，1+2/3搭配组合，2+1搭配组合等，限制数量/产品/品牌等。

目标五：提升BOM组合的效益

梳理过往BOM的SOP需求文档，分析已上架/已下架BOM组合品的运营效益/财务收益，使组BOM效益最大化。

目标六：形成BOM组合确定机制SOP

以目标一～目标五为基础，形成BOM组合确定机制的规范文档，使BOM的确定，流程更规范，减少需求不明确场景。

5. 最终确定方案

1）SKU和SPU的区别：即商品的OneID范围>SPU，以产品为管理维度，比如巧克力就是一个SPU，巧克力有8个口味，每个口味就是一个SKU。当前产品SPU和SKU是一对一关系，可以一对多进行维护，后台BI数据以SKU作为呈现维度，产品代码SKU 91007-01，则SPU为 C91007-01，组合BOM会单独一个代码类别。

2）组BOM的确定机制：根据需求而定，可跨品牌跨品牌组合，组BOM的需求来源（包括产品活动，买赠活动，打包销售，上市销售，常规BOM组合等）。

3）组BOM的流程：活动类需求方前期跟产品管理，财务确定好组合和价格ROI，再由需求方操作组BOM流程，经过商品中台/财务完善商品信息完成上架动作；常规类流程相比更简单，不涉及财务审核。

4）后续BOM的管理：GMV的统计以产品为维度，大促活动以活动为维度，不会单独对BOM的效益做考核；产品和活动数据由各个需求方在后台查找/复盘。

五、商品OneID的建立

商品OneID的建立需从主数据逻辑梳理、系统功能优化两方面进行。

1. 梳理在售主商品数据，明确OneID归属关系

商品OneID是在原本主数据的基础上，创建商品OneID归属逻辑。明确除不同规格外，改版前后功能属性相同的商品，归为同款商品OneID。合并为OneID的商品类型：

• 版本不同，如商品升级版/品牌升级的同款商品合并；
• 口味不同，如巧克力的不同口味合并；
• 香型不同，如洗手液的不同香型合并；
• 颜色不同，如不同颜色的外包装，合并为同一个OneID。

需注意的是，规格不同，如50g或120g巧克力，不单独售卖的小规格活动品–如体验产品等，不在OneID范围内，需独立出来。

2. 建立商品OneID编码规则，初始化数据

建立商品OneID命名的统一规则：

【1】产品溯源码+最新统一产品名称 ( 如：91005-01纯黑巧克力七夕版)

【2】产品溯源码+新建商品OneID名称（如：91006-01纯黑巧克力礼盒版）

如图所示，合并为OneID的商品类型：

• 版本不同
• 口味不同
• 香型不同
• 颜色不同

除了单个商品，套装商品同样需有OneID归属。确定套装商品OneID命名规则相同：产品溯源码+最新统一产品名称 ( 如：91006-01纯黑巧克力礼盒版)。同时，确定体验装、套装商品、BOM组合商品的OneID属性：

【体验装商品】

作为独立OneID体系，根据版本/口味/香型/颜色四个大类做OneID归属。

【套装商品】

作为独立OneID体系，根据版本/口味/香型/颜色四个大类做OneID归属 ；

套装中的单个商品数量，销售量可拆分到单品中，体现套装中单品对OneID的贡献。

【组BOM商品】

无OneID归属，只看组合BOM中单品的OneID 组合BOM中的单个商品数量，销售额需拆分到单品中，体现BOM中单品对OneID的贡献。

3. 商品中台新增OneID字段，实现商品OneID管理

商品OneID的新增，需在商品中台将对应的字段/功能新增，同时对主数据进行初始化，才能运用起来，为此，需推进IT部门和产品开发部门完成：

1. 推进IT根据业务需求，升级商品OneID的系统功能，梳理系统维护的标准流程SOP；
2. 推进产品开发部门更新商品主数据治理机制，将商品OneID应用起来，并达到推广周知的效果。

商品OneID的建立会影响商品主数据、商品中台系统功能、乃至以商品为基础的仓储、产供、物流的系统功能，若运用得当，还可在商品分析的基础上，对商品升级布局、营销活动有助益。

为此，初期的逻辑梳理十分重要，当初花了很多精力，对标市面主流的商品管理方式，最终应用后的管理效能，也证明之前的努力没有白费。后续需要在应用层探索，尽量充分将OneID的作用最大化发挥。