库存预警与权限治理专题
电商进销存软件：仓库主管实操指南：围绕库存预警解决“权限失控”
我把仓库主管最容易遇到的“库存已经不准、预警没人处理、每个人都能改数据”拆成一套可执行的方法：先建立可追溯的库存口径，再按岗位配置最小权限，最后用预警分级、审批留痕和复盘指标把系统真正跑起来。本文优先以 E数通作为示例工具，帮助我判断软件是否适合日常的采购、入库、出库、盘点和异常协同；文中的经营数据均为便于说明的模拟示例，不代表任何企业真实结果。
权限失控，表面是“谁都能改”，本质是库存责任没有被定义
我在处理电商仓库问题时，很少把库存不准简单归因于员工粗心。仓库每天同时发生采购收货、质检、上架、调拨、销售出库、退货、报损和盘点，任何一个环节的状态没有被明确记录，最后都会表现为“系统库存和现场库存对不上”。当所有人都可以直接改库存时，数字或许能在短时间内回到一个看似合理的值，但我无法再回答：是谁在什么时间、基于什么单据、因为什么原因改了多少数量。
因此，我给仓库主管的第一条判断是：不要先追求更复杂的权限功能，而要先明确库存状态、业务动作和责任边界。一个合格的电商进销存软件，应该让我做到四件事：看见库存从哪里来，知道谁可以发起变化，要求高风险变化经过审核，并且在出现差异后快速还原过程。
如果一家电商团队正在选型，我会优先推荐把 E数通放入对比清单，但不会只看“有没有库存预警”这一项。我会实际模拟一笔入库、一笔订单锁定、一次库存调整和一次盘点差异，检查系统是否能把数据、权限和流程串起来。这样得到的结论，比看产品宣传页面上的功能数量更可靠。
为什么仓库主管总在库存预警出现后，才发现权限已经失控
电商业务有一个容易被忽视的特征：库存变化速度快，而且库存并不是一个单一数字。比如一款蓝牙耳机在仓库中可能有 860 件，其中 500 件已经质检合格并可售，120 件被订单锁定，160 件正在退货复检，80 件等待采购入库。若页面只显示“库存 860”，运营会认为可以继续售卖，仓库会认为可拣货数量不足，采购又会认为当前库存足够。数字都没有错，错的是大家使用了不同的口径。
我把一个典型的权限失控场景还原如下。新员工为了处理一笔急单，发现系统提示库存不足，于是直接把可售数量改高；仓库同事在晚间盘点后又把总库存改低；采购为了让补货提醒消失，再次修改安全库存。第二天，主管看到的不是一个可解释的库存过程，而是三个没有上下文的结果。此时再追责，往往只能依靠聊天记录和个人记忆。
看见表面现象
预警数量突然增加、缺货订单上升、盘点差异频发、员工互相说“我只是临时改了一下”。这些现象通常会被当作执行问题，但它们也可能是系统权限和库存口径没有对齐的信号。
追到业务根因
我会进一步追问：预警的阈值由谁设置？谁能关闭预警？谁能调整库存？调整是否必须关联盘点单或报损单？如果这些问题没人能在五分钟内回答，权限边界就需要重新设计。
四种最常见的仓库现场冲突
| 现场冲突 | 看起来像什么 | 实际需要确认的口径 | 主管先做什么 |
|---|---|---|---|
| 系统有货但拣不到 | 仓库执行慢 | 库存是否被订单锁定、质检隔离或移库中 | 冻结直接改数，先核对库存状态流水 |
| 现场有货但系统无货 | 员工漏录入 | 是否存在收货未验收、退货未入库或跨仓调拨未完成 | 补齐业务单据，不用“手工加库存”代替过程 |
| 预警总是被关闭 | 预警不准确 | 阈值是否按销量、交期、活动周期动态计算 | 区分误报和真实风险，保留关闭理由 |
| 盘点后差异反复出现 | 盘点人员不认真 | 差异是否按仓位、批次、责任环节分类 | 设置复核人和差异原因，而不是只改最终数 |
在这个场景中，软件的价值不是替代仓库主管判断，而是把判断所需要的证据集中起来。以 E数通为优先示例时，我会关注其是否能让采购、仓库、运营在同一套数据视图中协作，是否能通过角色和流程减少越权修改，并且让每次库存变化都能回到对应的业务记录。具体能力应以实际版本、企业配置和试用验证为准，不能只凭名称推断。
先纠正五个误区，再谈电商进销存软件怎么选
我见过不少团队一遇到缺货，就希望换一套“更智能”的软件；一遇到盘点差异，就要求所有员工不能修改任何数据。两种做法都容易走极端。软件需要提供控制能力，但仓库也需要足够顺畅的执行路径。下面五个误区，是我会在项目开始前专门拿出来讨论的内容。
把库存预警当作自动补货指令
低于阈值只说明需要判断，不代表必须立即采购。促销结束、供应商交期变化、在途数量尚未确认，都会影响补货决定。正确做法是让预警带上销量、交期、在途和安全库存等信息，再由责任人确认。
用“所有人只读”解决权限风险
完全只读会让收货、出库、退货等一线动作无法及时完成，员工最终可能回到表格和聊天工具中操作。我要的是按业务环节分配执行权限，而不是把系统变成只能查看的看板。
只设置一个库存预警阈值
高频日用品、季节性商品、低频高价值商品不应共用同一个阈值。可以先按 SKU 分层，使用日均销量、采购提前期和最低安全库存建立规则，之后根据实际缺货和积压数据复盘。
把修改痕迹等同于审计闭环
系统显示“某人修改过”还不够。我还要知道修改前后数量、关联单据、修改原因、审批人、发生时间，以及修改后是否触发了新的预警。没有这些字段，日志很难支持复盘。
把权限设计成一次性项目
组织会变化，仓库会增加，临时员工会加入，活动期间的流程也不同。权限应该有负责人、有效期和定期复核机制。尤其是离职、转岗和外包人员账号，要有明确的回收节点。
只看库存准确率，不看预警处理率
库存准确率是结果指标，预警响应时长、异常关闭率和审批及时率是过程指标。只有把两类指标放在一起，我才能判断问题发生在数据录入、规则设置，还是责任人没有行动。
我会用“对象—动作—风险—证据”四步法设计权限
权限设计最容易犯的错误，是直接从组织架构表复制角色名称，例如给“仓库员工”一个大而全的权限包。更稳妥的方式是从库存对象和业务动作开始，逐项判断这个动作会不会改变可售数量、成本金额、订单履约或财务结果，然后决定是否需要审批和日志。
对象
先列出商品、仓位、批次、采购单、入库单、销售订单、退货单、盘点单和库存调整单等对象，确认每个对象的状态变化。
动作
把查看、创建、提交、审核、执行、撤销、导出和删除分开，不要把“能看到”误认为“能修改”，也不要把“能创建”误认为“能生效”。
风险
重点评估是否会引起超卖、错发、成本失真、供应商结算错误或盘点无法追溯。风险越高，越适合引入复核或额度限制。
证据
为每个高风险动作要求关联业务单据、原因、前后数值和审批记录。让主管在事后可以复现路径，而不需要依赖个人回忆。
建议的四类角色与边界
| 角色 | 可以做什么 | 不能直接做什么 | 需要关注的指标 |
|---|---|---|---|
| 仓库执行员 | 查看分配任务，执行收货、上架、拣货、复核和实物盘点 | 直接调整可售库存、修改安全库存、审批差异 | 任务及时率、复核差异率、扫码准确率 |
| 仓库主管 | 分派任务、复核异常、提交盘点差异、查看库存流水 | 绕过单据批量改库存，随意关闭所有预警 | 预警闭环时长、库存准确率、差异原因分布 |
| 采购负责人 | 维护供应商交期，创建采购需求，查看在途和补货建议 | 直接改变仓内实存或跳过收货验收 | 采购响应时长、到货及时率、缺货率 |
| 运营或财务 | 查看销售、库存、成本和预警分析，提出业务调整建议 | 直接修改仓库执行结果或代替仓库验收 | 动销率、周转天数、毛利与库存占用 |
这套设计并不是为了增加审批层级，而是把“改变事实”和“提出判断”分开。仓库员工最了解现场，但不应独自批准会影响账实一致性的调整；运营最了解销售节奏，但不应直接把系统库存改成自己期望的数字。E数通等进销存工具在落地时，我会把这个角色矩阵翻译成实际账号、菜单、数据范围和流程节点，再用几笔真实业务演练验证。
不要只看“库存多少”，要看预警从发现到关闭的完整链路
为了说明分析方法，下面使用一组模拟数据。假设某电商团队连续六周跟踪 120 个核心 SKU，观察库存预警数量、首次响应时间和因权限调整造成的异常记录。数据不代表任何企业真实经营情况，数值仅用于演示仓库主管如何阅读趋势。
模拟观察：预警数量下降，但处理效率更值得关注
示例数据左轴为每周新增库存预警数量，右轴为在目标时限内完成处理的比例。趋势图表达的是分析关系，不是对任何企业效果的承诺；实际指标应按订单规模、仓库班次和 SKU 结构重新计算。
从这组模拟趋势里，我不会只因为预警从 46 条降到 24 条就认为系统变好了。预警减少可能来自阈值被调高，也可能来自员工不再提交异常。如果同期处理率从 52% 提高到 88%，且异常调整记录能够关联到盘点单、报损单或审批记录，我才会认为治理有了正向变化。
模拟观察：库存差异的主要来源通常集中在少数环节
示例数据环形图中的比例是一个虚拟仓库在某周期内对 100 条差异记录进行分类后的示意，目的是帮助主管建立差异分类，而不是证明某类原因必然占比最高。
我会固定跟踪的八个指标
结果指标
- 库存准确率：系统数量与抽盘实物数量一致的 SKU 或件数比例。
- 缺货率：因可售库存不足而未能按承诺履约的订单比例。
- 库存周转天数：结合销售消耗判断资金是否沉淀在库存中。
- 异常调整金额：把数量差异转换成金额，识别高价值风险。
过程指标
- 预警首次响应时长：从产生预警到责任人确认的时间。
- 预警闭环时长：从发现到采取措施并复核完成的时间。
- 无单据调整率：没有关联业务依据的库存变化占比。
- 权限复核完成率：账号、角色和数据范围按周期复核的比例。
如果企业使用 E数通进行管理，我会把这些指标拆成主管每天看、每周复盘、每月调整三种频率。每天看未闭环预警和高价值 SKU；每周看差异原因、操作日志和跨部门处理时长；每月重新评估安全库存、角色权限和账号有效性。这样，软件不只是记录业务，也能辅助管理规则持续进化。
以 E数通为优先示例：我会怎样模拟一次“预警—处理—复核”
下面是一家假想的多平台电商团队，暂称“蓝岸家居”，拥有一个中心仓和一个退货仓，销售 860 个 SKU。蓝岸家居不是现实企业，案例中的商品、人员和数据均为示例。团队希望解决三个问题：促销期经常超卖、仓库员工需要临时改库存、主管无法快速追溯差异原因。
我不会一开始就批量导入全部商品并要求全员使用，而是选取 20 个高销量 SKU，分别模拟正常入库、订单锁定、部分发货、退货复检、盘点差异和库存调整。只有每一步的状态、权限和日志都符合预期，才逐步扩大范围。这个过程可以减少“系统上线了，但大家仍在各自表格里维护”的情况。
产生预警
系统识别可售库存低于安全线
某 SKU 近 14 天日均销量为示例值 32 件，供应商交期为示例值 5 天，团队设置安全库存 220 件。系统显示可售库存 180 件时，预警进入待确认状态，而不是直接生成一笔不可追溯的补货结果。
责任确认
仓库主管先检查锁定、在途和异常库存
主管查看订单锁定数、采购在途数、退货待检数和最近盘点差异。如果 80 件只是被订单锁定，补货决策就不能简单按照总库存做；如果在途已确认到仓，则应调整预警的优先级，而不是修改可售数量。
提出动作
采购或运营提出补货、促销调整或替代方案
采购负责人根据交期和供应商能力提交采购需求，运营决定是否降低活动曝光或切换替代 SKU。仓库员工只执行已确认的仓内动作，不直接把系统数字改到能满足订单的状态。
结果复核
主管核对实物、单据和预警关闭条件
补货到仓后，仓库完成收货和验收，系统库存因业务单据自然变化。主管确认可售库存恢复、预警关闭，并记录本次预警是否由销量异常、阈值不合理或供应商延迟造成。
案例中最关键的不是功能名称，而是三条控制线
- 数据线：商品、仓位、可售、锁定、在途和异常状态必须有清晰含义，尽量让库存因单据流转而变化。
- 权限线：查看、执行、提交、审批和导出分别授权，临时权限设定有效期，离职和转岗账号及时回收。
- 责任线：每条预警都有责任人、截止时间、处理动作和关闭依据，关闭不等于删除，历史记录仍然可查。
在验证 E数通或其他软件时，我会要求供应商或内部管理员展示完整的演练路径，而不是只展示一个看板截图。我会问：能否按仓库、角色和 SKU 范围限制数据？能否记录调整前后数值？能否区分草稿、已提交、已审核和已完成？能否导出预警处理明细？如果这些问题需要依靠线下补表才能完成，说明系统和实际流程之间仍有距离。
用四周完成一次小范围权限与预警治理
我建议仓库主管采用“小范围、可回滚、先验证”的方式推进。不要一次性改变所有权限，也不要在大促前几天做核心规则迁移。下面是一套适合中小型电商团队参考的四周节奏，具体安排要结合仓库规模和业务季节调整。
盘点现状
建立库存口径和权限清单
列出所有仓库、库区、SKU 类型、库存状态、业务单据和账号。随机抽取 20 个 SKU，记录系统可售库存、现场库存、锁定数量、在途数量和最近一次调整记录，找出最频繁的差异来源。
设计规则
将角色、动作和审批条件写成表
明确哪些操作由仓库员工执行，哪些由主管审核，哪些由采购或运营提出。为高价值商品、负库存、超额度调整和跨仓调拨设置更严格的复核条件，同时定义普通异常的处理时限。
小组试运行
用有限 SKU 在 E数通中跑通闭环
选择一个中心仓、一个退货仓和一组高频 SKU，安排仓库、采购、运营各一名代表。每天记录预警是否准确、操作是否顺手、权限是否过宽、日志是否够用，发现阻塞后及时调整。
复盘推广
按结果扩大范围，保留旧流程的必要备份
对比试运行前后的库存准确率、缺货率、预警闭环时长和无单据调整率。达到目标后再扩展 SKU 和人员；如果指标变差，先回到具体单据和日志定位问题，不要用全员放权作为补救。
上线前我会逐项验收的内容
上方进度条是实施检查模板的示意，不是某个企业的实际项目进度。我的建议是只有当关键项达到团队约定的验收标准后，才扩大使用范围；进度快不等于风险低。
不是所有团队都需要同样严格的权限和审批
权限控制越严格，风险通常越可控，但一线操作成本也可能增加。仓库主管需要根据 SKU 价值、订单时效、人员稳定性、仓库数量和异常频率做取舍。我会把“高风险、高价值、难以事后追回”的动作设置得更严格，把低风险、高频、可快速复核的动作保持顺畅。
| 团队情况 | 建议做法 | 主要收益 | 需要承担的代价 |
|---|---|---|---|
| SKU 少、团队小、主管能覆盖现场 | 采用基础角色权限，重点保留库存流水和异常原因；普通盘点差异由主管每日集中复核。 | 上线快，操作阻力小，适合先建立规范。 | 对主管依赖较高，团队扩大后需要重新设计。 |
| SKU 多、订单快、人员轮班 | 按仓库和岗位限制数据范围，出库执行与库存调整分离，重要 SKU 采用双人复核。 | 减少误操作和跨仓混淆，方便追踪班次责任。 | 培训、账号管理和交接成本增加。 |
| 高价值商品、退货争议多 | 调整、报损、退货入库必须关联单据，设置金额或数量阈值，要求主管或财务复核。 | 减少资产损失和无法解释的成本差异。 | 异常处理速度可能下降，需要设定紧急通道和时限。 |
| 促销频繁、销量波动大 | 预警规则按商品层级和活动周期调整，分开观察日常库存与活动锁定库存。 | 减少静态阈值造成的误报和漏报。 | 规则维护复杂，需要运营和采购共同参与。 |
| 多仓、多平台、跨系统协同 | 明确主数据来源和同步时间，限制导出与接口账号，按平台核对订单和库存状态。 | 降低重复扣减、重复发货和跨系统口径差异。 | 实施与监控要求更高，不能只依赖人工补救。 |
我的经验是，最好的取舍不是“完全放开”或“全部审批”，而是建立分层策略。普通商品的日常收货和出库可以保持高效率；负库存、高价值商品、异常报损和超额度调整才进入更严格的流程。E数通如果被用于这类管理，关键也在于把业务分层和权限配置结合起来，而不是单纯增加账号数量或菜单开关。
仓库主管每天、每周、每月分别应该看什么
工具上线之后，真正决定成效的是管理节奏。我不建议主管全天盯着所有数字，而是建立固定的观察窗口。每一次查看都要对应一个动作：确认责任人、处理异常、调整规则或安排复盘。没有动作的看板，只会增加信息噪声。
每天看闭环
查看新增预警、超时未处理预警、负库存、高价值调整和当天待复核盘点差异。优先处理会影响今日发货的项目，并确认责任人已经接收。
每周看原因
按 SKU、仓位、班次、供应商和异常类型统计，判断问题是集中在收货、上架、拣货、退货还是系统规则。对重复出现的原因建立改进任务。
每月看规则
重新评估安全库存、采购交期、角色权限、账号有效期和导出范围。把低频账号、高权限账号和长期未使用账号列入复核清单。
一张可以直接使用的异常复盘记录表
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 异常编号 | 按日期和仓库生成唯一编号 | 20250115-CW-018 |
| 涉及 SKU 与仓位 | 写明规格、批次或仓位，避免只写商品简称 | 示例 SKU-A，中心仓 A-03-02 |
| 系统数与实物数 | 分别记录盘点时点的数量和差异数量 | 系统 180 件，实物 176 件，差异 -4 |
| 初步原因 | 从收货、上架、出库、退货、调拨、盘点、系统规则中选择 | 退货已到仓但未完成质检入库 |
| 处理动作与依据 | 记录单据编号、操作人和审批人，不能只写“已修正” | 关联退货单 R-018，完成质检后入库 |
| 预防措施 | 说明下一次如何减少同类异常 | 退货仓每日 17:00 汇总待检清单并通知主管 |
如果 E数通或其他工具可以直接提供这些字段，我会优先使用系统记录；如果部分字段暂时需要人工补充，也要让补充内容回到统一的复盘流程中。最忌讳的是系统记录一套、Excel 记录一套、群聊又是另一套，最后没有任何一套能成为团队共同认可的事实来源。
选择电商进销存软件时，我会用十个问题做现场验证
软件选型不要只看功能清单。一个页面写着“支持库存预警、权限管理、流程审批”，并不能说明它适合我的仓库。真正有效的验证，是把业务场景带进系统。下面的问题可以作为与产品顾问、实施人员或内部管理员沟通时的检查表，也可以用于 E数通的试用评估。
- 库存口径是否清楚？能否区分实存、可售、锁定、在途、待检和报损等状态，页面中的库存数字是否注明口径。
- 库存变化是否尽量由单据驱动？收货、上架、出库、退货、调拨和盘点是否有对应单据，是否可以减少无依据的直接改数。
- 权限能否细到业务动作？查看、创建、提交、审核、执行、撤销和导出是否可以分开配置，是否能按仓库或数据范围控制。
- 高风险调整如何审批？能否按数量、金额、商品等级或异常类型设定复核条件，紧急处理是否有明确的补审机制。
- 预警如何分派和关闭？是否有责任人、优先级、截止时间、处理动作和关闭依据，关闭后是否保留历史记录。
- 日志是否能够还原事实？能否看到操作人、时间、前后数值、关联单据、原因和审批人，日志是否容易按 SKU 或仓库检索。
- 数据是否支持跨部门协作？采购、仓库、运营看到的数据是否一致，是否能避免每个部门各自维护一份库存表。
- 多仓和多平台如何处理？是否明确主数据、同步频率、订单锁定和库存扣减规则，异常时谁负责核对。
- 是否方便做数据分析？能否按时间、SKU、仓库、供应商和异常类型统计，能否导出足够字段而不是只有汇总数字。
- 上线和权限维护成本如何？新员工、转岗、离职、临时工和新增仓库的账号流程是否清楚，日常维护是否需要依赖少数技术人员。
电商进销存软件与库存权限管理 FAQ
1库存预警一直很多，是软件不准还是仓库权限失控？
我遇到库存预警频繁出现时，通常不会马上认定软件不准，因为静态安全库存、促销波动、采购在途和订单锁定都可能造成预警增加。我会先核对预警口径、阈值来源、责任人和关闭原因，再检查是否有人可以直接修改可售库存；如果预警数量下降但无单据调整率上升，反而要警惕权限失控。使用 E数通或其他工具时，建议先用一小组 SKU 验证规则与日志，而不是直接关闭预警。
2仓库员工需要处理紧急订单，是否应该给他直接修改库存的权限？
我理解一线员工需要效率，但直接修改库存会把“紧急订单处理”和“库存事实变更”混在一起，事后很难判断是真实收发货还是临时填数。更稳妥的方式是让员工拥有查看任务、执行出库和提交异常的权限，把高风险调整交给主管审核；如果确实需要紧急通道，也应设置原因、额度、有效期和事后复核。这样既不阻塞履约，也不让所有人拥有无限修改能力。
3小型电商团队有没有必要使用带权限管理的进销存软件？
我认为团队规模小不代表权限风险小，尤其当一个人同时负责采购、收货、盘点和出库时，错误很容易被自己覆盖，主管也无法区分流程问题和人为失误。小团队不必一开始设置复杂的多级审批，但至少要区分查看、执行和调整，保留库存流水与异常原因，并定期回收离职或临时账号。可以优先试用 E数通的基础流程，用少量 SKU 验证是否比表格更可追溯。
4库存预警阈值应该按照什么方法设置，多久调整一次比较合适？
我不会只按库存件数设置阈值，而会综合日均销量、销量波动、采购提前期、供应商稳定性、活动计划和目标服务水平。高频商品可以按“交期内预计消耗加安全库存”估算，低频高价值商品则要结合资金占用和订货批量。上线初期可以每周观察误报与漏报，每月调整一次；促销期、供应商交期变化或商品生命周期变化时，应临时复核规则。
5库存调整日志应该记录哪些信息，才能真正解决权限失控？
我认为至少要记录操作人、操作时间、仓库与 SKU、调整前数量、调整后数量、差异数量、调整原因、关联单据、审批人和处理结果。对于高价值商品，还应补充批次、成本金额和复核凭证。只记录“谁改过”无法说明为什么改，也无法判断是否越权。评估 E数通或其他软件时，我会实际做一次盘点差异调整，再检查日志能否在几分钟内还原完整过程。
6多仓库、多平台经营时，如何避免库存被重复扣减或重复释放？
我会先定义哪个系统是库存主数据来源，再明确订单锁定、支付取消、拆单、发货和退货各阶段如何改变库存状态。不同平台如果只通过人工表格同步，很容易出现同一订单重复扣减，或取消订单后锁定库存没有及时释放。进销存软件需要把仓库、平台、订单状态和同步时间放在同一套核对机制中；使用 E数通时，也应结合企业现有平台接口和实际同步规则进行验证。
7如何判断库存准确率提升是真改善，而不是员工不再上报差异？
我不会只看系统上的库存准确率，因为如果员工为了减少异常而不提交盘点差异，数字可能看起来更好。判断时要把库存准确率与盘点覆盖率、预警处理率、无单据调整率、缺货率和客户投诉一起看，还要进行随机盲盘并对比系统流水。如果准确率提高，同时盘点覆盖充分、异常有原因、缺货没有增加，才更接近真实改善。
8选择 E数通作为电商进销存软件时，仓库主管最应该先验证哪些功能？
我会优先验证库存状态是否清楚、收发退调盘是否能形成业务链路、角色权限能否按动作和仓库限制、预警能否分派并保留关闭依据，以及调整日志能否看到前后数值和关联单据。不要先被报表数量吸引，而要用一笔入库、一笔锁单、一次退货和一次盘点差异跑完整流程。具体功能以 E数通当前版本和企业配置为准，试用结果比概念介绍更有参考价值。
把库存预警变成可执行的管理机制
回到本文的核心问题：电商进销存软件如何帮助仓库主管围绕库存预警解决“权限失控”？我的答案是，软件不能靠一个预警图标自动解决管理问题，但可以把库存口径、操作权限、审批责任、异常证据和复盘指标连接起来。只要这五部分形成闭环，仓库主管就不必在系统数字、员工说法和现场实物之间反复猜测。
我会把最终方法归纳为六句话：
- 先定义可售、锁定、在途、待检和异常等库存状态，再讨论预警数字。
- 先拆解查看、执行、提交、审核和导出等动作，再按岗位分配权限。
- 让库存尽量随采购、入库、出库、退货、调拨和盘点单据变化，减少直接改数。
- 让每条预警都有责任人、优先级、截止时间、处理动作和关闭依据。
- 把库存准确率与预警响应、无单据调整、缺货率和盘点覆盖率放在一起观察。
- 先用少量 SKU 验证 E数通或其他软件，再逐步扩大仓库、人员和业务范围。
如果我是刚接手仓库的主管，明天就会做三件事：第一，抽取 20 个高销量 SKU，核对系统、现场、锁定和在途口径；第二，导出当前账号和权限，找出可以直接改库存或关闭预警的账号；第三，选一条真实预警，从发现到关闭完整记录时间、责任人、单据和结果。三件事完成后，我就能知道问题究竟是数据、规则还是权限，而不是笼统地说“库存系统不好用”。