1. SKU到底是什么从一次发错货事故说起1.1 一个让我连夜改系统的订单错误先讲一件真实发生在我身边的事。某家做家居日用品的电商公司有一款杯子同款设计出了四个颜色白色、黑色、蓝色、粉色。运营团队为了方便在后台只建了一个商品链接库存统一填了500。结果开卖第三天仓库就炸了——系统显示有货但实际白色杯子已经没了订单却还在继续推给仓库。仓库拣货员对着单子找不到白色只好自作主张拿了黑色顶上客户收到货自然不满意退换货率直线上升。当时负责这块的同事跑来问我要不要给每个颜色单独建一个链接我说不用问题不在链接在你们压根没有把SKU当回事。所谓SKU就是库存量单位Stock Keeping Unit在电商和供应链语境里它指的是最小可区分的库存单元。同一款杯子白色和黑色在库存、价格、条码上都可能不同它们就是两个SKU。你把两个SKU混在一起记库存不出错才是运气好。那件事之后他们花了两个晚上把所有多规格商品拆成了独立SKU每个SKU单独管库存、单独打条码发错货的问题基本绝迹。所以聊SKU概念不能只背定义得知道它是来救命的。1.2 SKU和SPU的区别别再混为一谈很多刚入行的朋友会把SKU和SPU搞混我几乎每周都能在群里看到有人问这两个到底啥区别。SPU是标准化产品单元Standard Product Unit它代表的是同一个商品的公共属性。举个例子那款杯子不管白色黑色蓝色粉色它们的品牌、型号、材质、容量都是同一个这些公共属性聚在一起就是一个SPU。而SKU则是在SPU下面继续细化到每一个可独立售卖、独立入库的规格。用一句话记SPU是这个商品是什么SKU是我要具体卖哪一箱。SPU是商品的概念层SKU是库存和交易的操作层。电商平台的商品详情页通常挂在SPU下但购物车结算、订单拆单、仓库拣货、财务对账全部走SKU。如果一个系统里没有SKU这个概念或者把SKU和SPU混在一个字段里就会出现开头那种有链接、无库存细节的尴尬。我见过一个更极端的案例某服装品牌把红色M码卫衣的SKU命名为卫衣-红-M听起来没问题但后来出了个酒红色新款运营图省事直接用了红这个属性导致系统中两个不同的商品共用了同一个SKU。结果一盘点库存对不上财务那边两个商品的成本还串了。这种问题一旦发生靠人为核对非常痛苦根因就是SKU的定义边界没有划清楚。1.3 一个SKU对应一个最小库存单元的本质SKU的最小库存单元到底有多小它不是越小越好而是刚好到能独立管理库存和使用条码追溯的最小粒度。对服装来说颜色加尺码就是最小粒度没必要细分到哪一批次那是批次管理的事对食品来说口味加包装规格是SKU粒度生产日期则属于批次属性不应该混进SKU编码。对3C数码配件来说同一款数据线苹果接口和Type-C接口就是两个SKU哪怕它们长得几乎一样。理解这个最小单元特性很重要因为SKU既是库存统计的单位也是成本核算的单位还是销售分析的维度。如果你把两个应该分开的规格并成一个SKU库存数量和实际货品永远对不上如果你把同一个规格拆成多个SKU自己给自己制造重复数据报表里会出现一条裤子的销量被算到两条不同裤子上。我自己的经验是判断一个SKU划得对不对就问一个问题——我能不能只给这个SKU单独下采购单、单独盘点、单独调价而不影响其他规格如果能它就是独立SKU如果必须连带其他规格一起操作那说明它拆细了或者压根还在一个模糊的集合里。2. SKU编码规则一套好编码能省掉一半沟通成本2.1 编码设计的基本原则可读性、唯一性、扩展性搞清楚SKU是什么之后紧接着就会遇到一个问题SKU怎么编码很多人觉得编码不就是给商品起个编号随便写个字母数字组合就行。真不是。我在不同公司见过太多因为编码混乱导致的低级事故比如同样的商品在两个仓库有两套编码再比如因为编码里带了特殊字符导入系统时直接被截断。设计SKU编码我总结了三个原则可读性、唯一性、扩展性。可读性指看到编码就能大致猜出是什么商品不用查系统唯一性指一个SKU编码只能对应一个规格绝对不能出现一码多物扩展性指编码规则要留有余地未来新增颜色、尺寸、版本时不至于闹到规则推倒重来。这三条原则里唯一性是底线其余两条是体验。怎么理解可读性比如某家零食公司给混合坚果-原味-每日坚果30包装编成NUT-AM-30*1内部人一看就知道是原味坚果30包。如果编成0001这种流水号仓库老师傅只能天天抱着电脑查条码效率低还容易出错。2.2 推荐的分段编码法大类属性规格校验我比较推荐的分段编码法是把编码拆成几个有明确含义的段位用短横线或固定位数区隔开。下面是一个可参考的骨架第1段商品大类用2到3位字母缩写比如NUT代表坚果CUP代表杯子TST代表T恤。第2段核心属性比如颜色、口味、材质建议统一用固定单词或缩写并维护一份属性字典。第3段规格信息比如容量、尺寸、包装形式数字为主保持简洁。第4段校验位或流水号防止前面段位完全相同的极端情况出现也可以用来做条码防错。拿那款杯子举例可以编成 CUP-WHT-400-01。CUP表示杯具大类WHT表示白色400表示容量400ml01是流水或校验位。如果后面出了个400ml白色带盖款那就得在属性段里增加一个带盖标识比如 CUP-WHT-LID-400-01而不是继续往末尾堆数字。这里要特别提醒一点段位之间尽量不要用空格或中文标点避免导入导出时被系统截断。短横线是相对安全的分隔符但如果你用Excel批量处理记得把单元格格式设为文本防止系统自动把06当成数字6。2.3 常见编码反面教材纯流水号、含义过载、长度失控聊完推荐方案再说几个我踩过或围观过的反面教材。第一个是纯流水号。有些小团队为了省事直接按1、2、3排下去。初期没问题等到SKU数量上千运营想从编码里看出这是哪个大类的商品根本做不到。仓库拣货时也得对着系统逐条查极度影响效率。第二个是含义过载。有人想把所有信息都塞进编码里比如2023-男装-卫衣-红色-M码-外贸款-冬季-001。这个编码看着信息量很大但一旦长度超过20个字符在打印条码、导入OMS、对接物流时各种出问题。而且只要某个属性发生变化比如外贸款这个词要改成内销款所有相关编码都要改影响面非常大。第三个是长度失控和含义过载是孪生兄弟。有些系统的条码标签宽度有限编码太长就放不下只能缩印结果扫描枪识别率直线下降。还有一个更隐蔽的问题如果编码包含字母O和数字0、字母I和数字1打印出来很难区分人工核对时特别容易看错。所以编码中最好只使用不容易混淆的字符比如去掉O、I统一用小写或大写。提示编码一旦投入使用就不要随意改。宁可新增一个废弃状态并登记录入废弃原因也不要把旧SKU的编码直接改给新商品用否则历史订单和库存盘点数据都会变成一笔烂账。3. SKU在库存与供应链里的真实作用3.1 库存准确率为什么依赖SKU颗粒度库存管理里有个指标叫库存准确率计算公式很简单盘点时账实相符的SKU数量除以总SKU数量。但真正把准确率做上去很难难点就在SKU的颗粒度。库存准确率本质上是账、卡、物一致的比率如果你的SKU颗粒度太大比如把500件杯子混在一起记账面上永远是对的但实体仓库里具体到某个颜色就是错的。我做过一个模拟项目某日用百货仓有3000多个SKU刚开始库存准确率只有82%怎么盘都提不上去。后来发现原因很无厘头仓库里有一批白色陶瓷杯-带盖-350ml和白色陶瓷杯-不带盖-350ml两者条码贴错了。因为编码规则里没有体现带盖这个属性拣货员看着两个条码几乎一样混着贴也没发现。最后重新梳理属性字典把这两个SKU彻底分开并在库位上做了物理区隔准确率才慢慢爬到97%。这个案例告诉我们SKU颗粒度不是越细越好但凡是会影响客户是否愿意买单、仓库是否知道拿哪个货、财务是否分得清成本的差异都必须反映成独立的SKU。否则就不是颗粒度问题而是数据模型的黑洞。3.2 从采购到履约SKU如何串起全链路SKU不只是仓库里的一个标签它把采购、销售、物流、财务全部串在一起。你下采购单的时候采购单上写的是SKU供应商送货过来仓库收货清点的是SKU客户下单订单拆完的履约明细是SKU财务结转成本核算的也是SKU。可以说SKU是整个进销存体系的主键主键一旦乱掉所有关联表都会跟着乱。举个直观例子某食品贸易公司同时做线上电商和线下批发线上卖的是单包零食线下批发是整箱。他们一开始只建了零食-单包和零食-整箱两个SKU后来发现整箱的采购成本、毛利、效期管理和单包完全不同。如果硬放在同一个SKU下仓库发货时按整箱出库财务却按单包成本结转利润表完全失真。后来我建议他们把单包和整箱拆成不同SKU并在SKU属性里加一个销售单位字段。虽然系统里多了近一倍的SKU数量但采购、销售、库存、财务的口径终于统一了。这就是SKU作为全链路主键的价值——它让一个颗粒度的调整牵动整个公司的数据准确度。3.3 多仓、多渠道下的SKU映射问题当业务从单仓单渠道扩展到多仓多平台时SKU还会遇到映射问题。举个例子同一款杯子在自有商城、第三方平台A和B上可能各自有一套商品编码但它们对应的内部SKU应该是同一个。为了方便管理通常的做法是建立一张映射表内部SKU到平台SKU、平台商品ID、仓库库位编码一一对应。这里有三个容易踩的坑第一平台SKU命名和内部SKU不一致导致每天对单时大量订单匹配不上第二同一个内部SKU在不同仓库有不同库位但系统里只维护了一个默认库位造成另一仓发货时找不到货第三多仓库存同步时把不同SKU的可售库存简单相加忘了考虑调拨在途量结果超卖。我的建议是在做多仓映射前先明确一个原则内部SKU是唯一权威所有外部编码都只是别名。任何平台新上架的商品第一件事就是绑定内部SKU而不是为平台单独造一个新的内部SKU。否则很快你就会有几十套长得像同一款商品但编码完全不同的数据到时候想合并都难。4. SKU背后的数据分析价值4.1 同一个商品不同SKU的销量差异说明什么SKU不光是用来管库存的它还是一个非常关键的分析维度。同一款SPU下的不同SKU销量差异往往能告诉你很多经营信息。最典型的是颜色偏好。某服装品牌在推一款卫衣时黑色和白色是主力备货但实际数据出来后姜黄色和军绿色的售罄率反而更高而且退货率低。运营一开始不明白后来翻了评论区才发现这款卫衣的设计偏工装风穿姜黄色的人更愿意晒图。于是下一批补货时他们把姜黄色从辅助色提到了主力色整体动销率提升了不少。这就是SKU级数据的作用它让你看到用户在用真金白银投票。如果你只看SPU层面的总销量你只知道卫衣卖得不错但看不到具体哪个颜色才是真正的爆款。对于靠款式吃饭的服装、鞋帽行业SKU级别的销量、售罄率、退货率分析是每一年订货会都要做的核心功课。4.2 用SKU维度做ABC分析避免把SKU等同SPU库存管理里常用ABC分类法对SKU按销售额或出库频次排序把头部20%的SKU划为A类重点管理中部30%为B类尾部50%为C类粗放管理。但很多人直接把SPU当作分析对象最后做出的ABC分类完全是错的。举个例子某数码配件公司有一款充电宝分5000mAh和20000mAh两个容量。从SPU维度看这个充电宝卖得很好是A类。但细化到SKU20000mAh贡献了80%的销售额5000mAh几乎滞销。如果按SPU管理你会给5000mAh也配了很高的库存水位结果就是积压。所以做ABC分析时必须把SPU拆到SKU维度重新排序并用SKU的销量和库存周转率做交叉验证。你还得注意一个情况有些SKU单体销售额不高但是和爆款SKU强关联比如充电宝线材的配件包。这类SKU要单独标记为关联款不能简单按销售额归类。4.3 SKU层级的价格策略与促销设置价格策略同样要落到SKU层。同一个SPU下不同SKU的进货成本、市场接受度可能差异很大。你可以用某个SKU做低价引流款再用另一个SKU做利润款这是非常常见的打法。不过在促销设置时SKU的坑也很常见。某些电商平台在做满减或优惠券时是把整个SPU下所有SKU都算进来的。如果你想只对某个SKU做特价就一定要在后台单独勾选对应SKU否则就会出现顾客拍下经典款实际收到的是促销款或促销价错用在成本最高的SKU上的乌龙。我记得某家电品牌就出过这种事故大促期间把一台本应参与活动的低配SKU设置成功结果高配SKU也跟着打折单日亏损超过六位数。后来他们专门立了一条规矩所有活动报批前必须拉出参与活动SKU的清单由运营和财务双人复核。在定价层面我建议每季度至少做一次SKU层级的毛利分析。把每个SKU的销售价、采购成本、物流成本、平台佣金算清楚标出哪些是赚吆喝的哪些是真正赚钱的然后再决定下一季度的主推方向。很多公司只看SPU毛利率结果同款商品低配高配一平均自己都不知道哪个规格其实一直在亏钱。5. SKU管理中常见的坑与避坑经验5.1 SKU膨胀泛滥的SKU正在吞噬利润很多公司SKU越做越多销量却没有跟着涨这就是典型的SKU膨胀。表面上看多一个SKU就多一个销售机会但每个SKU都对应着设计成本、采购成本、仓储成本和库存风险。SKU数量过多会让采购失去规模效应仓库库位不够用滞销品越积越多最后只能清仓甩卖。我见过一家做创意文具的小公司为了满足个性化需求推出了几十种笔记本内页组合每种组合都建了独立SKU。结果大部分组合月销量只有个位数但每个SKU都有起订量光库存占款就压了几十万。后来他们下了狠心把月销低于5件的SKU全部砍掉统一改成自定义内页定制服务SKU从80多个压缩到15个反而利润变好了。通往判断SKU是否该保留我会看三个指标近90天销量、库存周转天数、毛利贡献。三个指标都表现差的SKU没有理由继续占用资源。要砍就果断砍不要因为万一有人买呢这种心理犹豫不决。5.2 复用SKU、乱删SKU带来的历史数据断裂另一个我经常强调的问题是SKU编码一旦被复用或删除历史数据就废了。什么叫复用某旧款洗面奶停产了运营把它的SKU编码直接改给了新款洗面奶用。结果后台的销售报表看起来新款销量很好其实里面混着旧款的历史数据。等到月底做复盘财务、运营、供应链各拿一套数据谁都说不清楚。正确做法是旧SKU只是停用而不是删除。停用之后它的编码永远保留在数据库里历史订单、库存流水、采购记录都能关联上。新品必须申请新编码。如果你用Excel手动管理SKU记得把停用表单独归档别直接覆盖。另外停用SKU时要检查是否有在途库存、在售订单和未结算账单。我有一次停用了某商品SKU结果仓库里还有几十件现货没清系统却已经不允许下单了最后只能申请临时恢复流程走了一周非常折腾。5.3 组合商品、赠品、多规格带来的SKU难题业务复杂起来后SKU还会遇到各种非标情况。下面列几个最常见的组合商品比如杯子杯垫吸管的礼盒套装它本身是一个可售SKU但库存逻辑上要扣减子商品库存。这时你要决定是单独备一套组合库存还是做子件库存联动。前者简单但容易造成子件库存和组合库存打架后者准确但系统必须支持BOM物料清单拆解对技术有要求。赠品赠品要不要建SKU我的建议是如果是固定的采购赠品要建SKU并计入库存但可以设置赠品标识如果是活动临时送的也至少要在系统里登记消耗数量否则营销成本完全失控。多规格叠加同款商品有颜色、尺码、材质、版本多个维度组合出的SKU数量会指数级上升。这时候编码规则里的属性字典就非常重要每个属性都要有标准值不能让工作人员随手输入红色红深红三种写法。我处理这类问题的方式是先画一张商品属性矩阵明确哪些属性会影响库存和销售哪些只是描述信息。只有影响库存和销售的那些属性才进入SKU编码和SKU主数据。描述信息如适用人群季节可以放在SPU属性里避免SKU表格冗余到让人头皮发麻。6. 如果从零搭建一套SKU体系我会怎么做6.1 先梳理业务边界再设计编码很多人一上来就急着定编码方案我反而建议先花两天把业务边界梳理清楚。你需要和运营、仓库、采购、财务分别聊一轮问几个关键问题你们现在有哪些商品分类每个分类下有哪些细分规格哪些规格会影响价格、库存、采购系统里现有的单据是以什么粒度运行的拿到这些答案后再开始设计SKU的粒度。比如家纺行业规格可能是被套-1.5m床-纯棉-单件食品行业可能是薯片-原味-40g-袋装。粒度确定后你才能去谈编码。业务边界不清就上编码设计等于在沙子上盖楼。6.2 建立SKU属性规范文档SKU体系要长期稳定必须有一份属性规范文档。这不是普通的Excel表而是用来约束所有团队成员的规则。里面至少包含以下内容属性字段列表比如大类、颜色、材质、规格、版本、销售单位。每个字段的取值范围比如颜色只允许从标准色卡中选择不能自由填。SKU编码的生成规则每段位用什么字符、多长、分隔符是什么。新SKU创建的审批流程谁来提交、谁来审核、谁录入系统。停用和变更的规则什么条件下可以停停用后如何处理历史数据。有了这份文档新员工入职后照着做就行不会每个人弄出一套野路子编码。老员工也不用因为口头沟通不到位而互相扯皮。文档建议用共享在线表格维护按季度更新一次。6.3 上线后要做的三件维护工作SKU体系上线不是终点只是起点后面有大量维护工作。我总结了三件最重要的事供你参考。第一件是定期巡检。每个月抽查一批SKU检查编码是否符合规范、属性值是否准确、库存是否账实相符。巡检发现的问题要记录在案并追溯是录入错误还是流程漏洞。第二件是属性字典治理。随着新品上市难免会遇到现有属性字典里没有的值比如新增了一款蓝绿色。流程上应该是先走属性字典更新申请通过后再建新SKU。如果跳过这一步直接建SKU过不了多久字典里就会冒出一堆同义词。第三件是历史数据归档。每当季度或年度结束后把停用SKU和在售SKU的数据做一次快照归档。这样即便以后有人误操作改乱了主数据你还能从归档里找回正确状态。这套流程听起来繁琐但它能让你从天天被库存和订单问题追着跑变成有一套稳定体系支撑业务扩张。我见过不少从几十个SKU做到几万个SKU的公司凡是能顺利扛过的都是早期就把SKU基础打扎实的。最后再分享一个小技巧建好SKU体系后把重要的编码规则做成一张卡片贴在仓库电脑旁边同时给运营团队发一份电子版。省得到时候每个人都来问你这个SKU是啥意思。这种问题少一次你的时间就多一分。