商品主数据是进销存的地基。运营主管经常低估它的影响，因为商品资料看起来只是名称、图片和价格，真正运行后才会发现，库存、采购、订单、售后和报表都依赖同一套编码。

我会检查哪些字段

• 基础身份：SPU、SKU、商品名称、规格、条码、品牌、分类和状态。SPU用于描述一个商品系列，SKU用于描述可独立采购、库存和销售的具体规格，二者不能混用。
• 交易属性：销售单位、采购单位、库存单位、单位换算、含税售价、活动价、建议零售价和最低可接受价格。
• 供应属性：默认供应商、备选供应商、起订量、采购周期、最小包装、交期和质检要求。供应商变更要留下生效时间。
• 库存属性：安全库存、补货点、批次管理、保质期、序列号或库位要求。不是所有商品都需要全部属性，但选择依据要写清楚。
• 分析属性：渠道、季节、活动、负责人、成本中心和商品生命周期。尽量用标准枚举值，避免同一个渠道被录成多个名称。

采购模块不是简单记录买了什么，而是帮助团队解释为什么买、买多少、什么时候到、到货后是否合格。对季节性明显或活动波动大的电商业务，采购计划至少要同时看历史销量、未来活动、现有库存、在途库存和供应周期。

建议从四类单据开始

1. 采购需求：记录申请人、需求来源、商品、数量、期望到货时间和需求依据。需求依据可以是补货点、活动计划或人工说明。
2. 采购订单：明确供应商、含税单价、交期、付款方式、收货仓、允许超收比例和质量要求。
3. 收货与入库：区分已收、待检、合格、拒收和部分到货，不能收到货就直接把全部数量计为可售库存。
4. 对账与付款依据：让采购、仓库、财务看到同一张业务事实，差异包括数量、价格、税率、运费和折让。

补货量不要只看一个公式

示例公式可以是：建议采购量 = 预测期间需求 + 安全库存 − 可用库存 − 已确认在途库存。这里的“可用库存”必须先定义是否扣除锁定库存和质检库存；“预测期间需求”也要明确看过去多少天或未来哪个活动周期。公式只负责提供建议，最终仍要结合现金流、起订量、保质期和供应商交期判断。

库存数字最容易造成误判。一个仓库里看到的数量，可能包含已被订单锁定的商品、等待质检的商品、因包装破损不可售的商品和已经在途但尚未入库的商品。运营主管要先统一库存状态，再谈缺货率和周转率。

建议至少区分这些库存概念

• 现存库存：已经完成入库、物理上在仓库中的数量。
• 可售库存：现存库存扣除锁定、质检、报废和其他不可销售状态后的数量。
• 锁定库存：已经被有效订单占用，但尚未完成出库的数量。
• 在途库存：已采购或已调拨，但还没有完成目标仓入库的数量。
• 安全库存：为了覆盖交期波动或需求波动而保留的缓冲，不应直接当作可随意销售的数量。

盘点和调整要留下三层证据

第一层是盘点前的账面快照，第二层是现场实际盘点记录，第三层是差异原因和审批记录。盘盈盘亏不能只改一个数字，因为后续需要知道差异来自收货未入库、错发、破损、赠品、单位换算还是录入错误。

订单链路的关键不是把订单导入系统，而是让订单状态、库存占用、发货结果和售后结果保持一致。多渠道团队尤其要检查订单是否重复导入、取消订单是否释放库存、拆单和合单是否影响成本归属。

订单状态建议按业务动作定义

• 待支付、已支付、待审核、待拣货、待发货、部分发货、已发货、已完成、已取消、售后中和已关闭。
• 每个状态都要有进入条件、退出条件、责任人和超时处理方式。状态名称越多不一定越专业，关键是团队能按状态采取动作。
• 对于货到付款、预售、赠品、组合套装和分仓发货，要单独确认库存占用、收入确认和售后处理逻辑。

运营主管需要关注的四个异常

1. 已付款但未锁库，导致承诺库存被其他订单占用。
2. 已取消但库存未释放，报表看起来有货，实际上无法销售。
3. 部分发货被系统当成整单完成，客服无法判断剩余责任。
4. 退款完成后，退货商品没有回到质检或不可售状态，库存和利润同时失真。

“利润”不是一个天然统一的数字。运营报表里的毛利，可能只扣商品采购成本；经营利润还可能扣平台佣金、支付费、履约费、投流费、达人佣金、售后损失和人工分摊。若不先定义口径，团队会围绕数字争论，而不是围绕行动改进。

这里的公式只是示例。实际使用时，我会在指标字典里写明数据来源、更新频率、是否含税、退款如何处理、成本采用哪种计价方式，以及缺失成本时如何标记。一个暂时不完整但口径透明的指标，比一个看似精确却无法解释的指标更适合做决策。

团队版软件的权限设计，不能只按职位粗略分成“管理员”和“普通成员”。运营主管需要把查看、录入、编辑、删除、导出、审批和配置拆开，尤其要防止业务人员可以直接修改历史成本、库存和结算结果。

我建议采用“角色 × 数据范围 × 操作权限”三维设计

• 角色：运营主管、商品专员、采购、仓库、客服、财务、管理层和外部协作人员。
• 数据范围：全部店铺、指定店铺、指定仓库、指定商品分类、本人负责的活动或订单。
• 操作权限：查看、创建、修改、审核、导出、删除、回滚和配置。删除权限应尽量收紧，优先使用作废、撤回和冲销。

权限上线前做四次模拟

让采购人员尝试查看不相关的财务数据，让仓库人员尝试修改商品成本，让客服人员尝试取消已出库订单，让运营主管尝试查看跨渠道汇总。模拟不是为了找谁越权，而是确认职责边界是否符合真实工作。

运营主管看报表的目的不是收集更多数字，而是决定今天先处理什么、下周调整什么、月底复盘什么。我通常把指标分成三层：第一层是事实数据，第二层是过程效率，第三层是经营结果。

数据看板应该让人能够从总览下钻到店铺、商品、订单和操作记录。若只能看到一个漂亮的总数，无法继续追查明细，它更像展示页而不是管理工具。E数通等数据工具是否适合，需要重点核对数据连接、权限、指标计算、筛选下钻和团队协作能力，而不是只看图表样式。

很多软件项目在试用期表现不错，正式上线后却逐渐失效，原因常常是没有安排数据维护、异常处理、版本变更和培训复盘。运营主管要把“谁维护、多久查、发现问题怎么处理”写进日常节奏。

• 每日：检查同步失败、异常订单、库存负数、待处理售后和关键任务超时。
• 每周：复盘缺货、滞销、采购延期、退货原因、活动商品和权限变化。
• 每月：核对平台账单、库存结余、成本口径、人员账号和指标定义。
• 每季度：清理无效 SKU、回顾流程是否仍适配业务、检查数据导出和备份方案。