简介：这份PPT面向零售管理系统设计人员、免税业务信息化从业者及管理咨询学习者，围绕中免集团零售管理流程与系统需求展开，帮助读者理解免税零售业态的运营逻辑与IT支撑要点。压缩包内仅含1个pptx文件，约557KB，以图文页形式呈现门店业态对比、特殊流程与系统需求等核心内容。资料系统梳理了市内店、口岸店、供船店三类业态在客源、商品结构、提货方式与财务结算上的差异，并详细拆解市内店POS收银、顾客卡办理、六联销售单据流转、海关核销与机场提货等特殊流程，同时覆盖供船店的订单、报关与转账收款环节。此外还包含消费者行为分析、门店商品计划、采购收发货、运营财务等流程描述，以及门店POS系统在客户信息记录、汇率转换、支付验证与应收管理方面的核心需求。目前已有60人学习，适合用于零售管理系统需求分析与业务流程梳理参考。
1. 零售业务流程与系统需求：从一张 PPT 到可落地的需求基线
很多做零售系统的团队都遇到过这种场景：业务方甩过来一份《业务流程和相关系统需求零售.pptx》，里面画了十几张跨职能流程图，标注了“门店要能查库存”“线上订单要能改地址”“促销要支持叠加”，然后问你多久能上线。你打开 PPT 一看，流程图形状五花八门，需求描述一句话带过，连“库存扣减发生在哪个节点”都没写清楚。这份 PPT 本身不是技术文档，但它承载的是零售业务从采购、仓储、门店、电商到售后的完整链路，以及这条链路上每个角色对系统的真实诉求。谁能把这份 PPT 翻译成可评审、可排期、可验收的需求基线，谁就能把项目从“拍脑袋”拉回“按图施工”。这篇内容适合零售行业的产品经理、业务分析师、技术负责人，以及需要对接业务方做系统设计的开发同学。接下来我会按“先拆业务、再定需求、后落系统”的顺序，把这份 PPT 里最容易踩坑的地方和可复用的方法讲透。
2. 拆解零售业务流程：从 PPT 里的泳道图到可执行的活动清单
2.1 先分清零售业务的四条主干流程
零售业务看起来千头万绪，但落到系统需求层面，主干流程通常只有四条：商品从采购到上架的商品流转、从下单到履约的订单履约、从收款到对账的资金结算、从咨询到售后的客户服务。PPT 里如果把这些流程混在一张图上，评审时一定吵架。我一般会先把 PPT 里的泳道图按角色拆开，每个角色一条泳道，每条泳道只保留该角色负责的活动节点。比如“门店店长”这条泳道，只保留“审核补货申请”“确认收货”“处理退换货”三个节点，其他节点全部移到对应角色的泳道里。拆完之后，你会得到一张活动清单，每个活动后面标注触发条件、输入数据、输出结果、异常分支。这一步不需要任何工具，用 Excel 或在线表格就能做，但它是后续所有需求条目的来源。
拆流程时最容易翻车的地方是“隐性活动”。PPT 上画了一个“门店补货”的框，但实际业务里，补货申请提交后，区域经理可能有一票否决权，仓库可能因为缺货拆单发货，这些在 PPT 上往往没有体现。我的做法是拿着拆好的活动清单，找每个角色的实际执行人过一遍，问三个问题：这个活动你一般什么时候做？做之前需要看到什么数据？做完之后谁会收到通知？这三个问题的答案，就是系统需求里最容易被漏掉的“状态流转”和“消息通知”条目。
2.2 用状态机把流程节点变成系统可跟踪的对象
业务流程拆完之后，下一步是把每个关键对象的状态变化画出来。零售系统里最核心的三个对象是：商品、订单、库存。PPT 上通常只画了正向流程，比如“订单创建→支付→发货→收货”，但系统需求必须覆盖逆向和异常。我一般会为每个对象建一张状态机表，列出所有可能的状态、触发状态迁移的事件、迁移时的校验规则、迁移失败后的回退状态。
以订单为例，常见状态包括：待支付、已支付、待发货、已发货、已签收、已完成、已取消、退款中、已退款。每个状态之间的迁移条件必须写清楚，比如“待支付→已支付”的触发事件是“支付成功回调”，校验规则是“支付金额等于订单应付金额”，失败回退是“保持待支付并记录异常”。这张表一旦建好，开发在写代码时就有明确的依据，测试在写用例时也能覆盖所有分支。PPT 里的流程图是给人看的，状态机表是给系统看的，两者缺一不可。
2.3 从活动清单到需求条目的转换规则
活动清单和状态机表准备好之后，就可以逐条转换成系统需求条目了。我用的转换规则是：每个活动节点至少产生一条功能需求，每个状态迁移至少产生一条业务规则需求，每个异常分支至少产生一条非功能需求（比如性能、日志、告警）。功能需求的写法是“角色+动作+对象+约束”，例如“门店店长在补货申请页面提交补货单，系统校验该商品在当前门店的库存低于安全库存阈值，校验通过后生成补货单并通知仓库”。业务规则需求的写法是“当条件A满足时，系统执行动作B，否则执行动作C”，例如“当订单支付超时30分钟未完成，系统自动取消订单并释放库存占用”。
这里有一个血泪经验：PPT 里经常出现“支持多种促销叠加”这种模糊描述，直接写成需求条目就是给自己挖坑。必须追问清楚：哪些促销类型可以叠加？叠加顺序是什么？互斥规则是什么？优惠金额分摊到每个商品上怎么算？这些问题不解决，开发做到一半一定会返工。我一般会要求业务方在 PPT 之外补充一份促销规则矩阵，列出所有促销类型和叠加关系，作为需求附件。
2.4 用一张流程-需求映射表锁定范围
拆完流程和需求之后，一定要做一张映射表，把每个流程节点和对应的需求条目关联起来。这张表的作用是：当业务方说“这个功能怎么没做”时，你可以直接翻到对应的流程节点，确认是当时没识别到，还是识别到了但优先级排后了。映射表的列包括：流程编号、流程名称、活动节点、需求编号、需求描述、优先级、验收标准。优先级我一般用 MoSCoW 方法，分为 Must have、Should have、Could have、Won't have。验收标准必须可量化，比如“补货单提交后 3 秒内生成并推送通知”而不是“补货单要能快速提交”。
这张表还有一个隐藏价值：它是项目排期的依据。Must have 的需求必须进入第一个迭代，Should have 进入第二个迭代，Could have 根据资源情况决定。如果业务方要求所有需求都必须在第一个迭代上线，这张表就是你和他们谈判的底牌。
3. 零售系统需求规格化：把 PPT 里的“一句话需求”写成可验收的条目
3.1 功能需求的结构化写法与示例
PPT 里的需求描述通常是一句话，比如“门店要能查库存”。这句话直接交给开发，开发会问你：查哪个仓库的库存？是实时库存还是快照库存？查库存的人有没有权限限制？查出来的结果要不要显示在途库存？所以功能需求必须结构化。我用的模板包含六个字段：需求编号、需求名称、角色、前置条件、主流程、异常流程、后置条件、验收标准。
以“门店查库存”为例，结构化之后是这样的：需求编号 REQ-001，需求名称“门店库存查询”，角色“门店店员”，前置条件“店员已登录且拥有库存查询权限”，主流程“店员输入商品编码或名称，系统返回该商品在当前门店的可用库存、在途库存、锁定库存”，异常流程“商品不存在时提示‘未找到该商品’，无权限时提示‘请联系店长开通权限’”，后置条件“查询记录写入操作日志”，验收标准“查询响应时间小于 2 秒，库存数据与仓库系统同步延迟小于 5 分钟”。这样写出来的需求，开发可以直接估工时，测试可以直接写用例，业务方也能看懂。
3.2 非功能需求的量化指标怎么定
零售系统的非功能需求往往被忽视，但上线后出问题的多半是它们。PPT 里不会写“系统要支持多少并发”，但系统需求文档里必须写。我一般从四个维度定指标：性能、可用性、安全、可维护性。性能方面，核心接口的响应时间 P99 不超过 2 秒，峰值 QPS 按历史大促数据的 1.5 倍估算。可用性方面，核心交易链路可用性不低于 99.9%，非核心链路不低于 99.5%。安全方面，敏感数据（手机号、地址）必须加密存储，接口调用必须鉴权，操作日志保留至少 180 天。可维护性方面，关键业务指标要有监控大盘，异常要有告警，告警响应时间不超过 5 分钟。
这些指标不是拍脑袋定的，而是根据业务规模和成本预算权衡出来的。比如一个日订单量 10 万单的零售系统，和日订单量 1000 单的系统，性能指标完全不同。我一般会先问业务方三个问题：当前日均订单量是多少？大促峰值是日常的几倍？能接受的系统不可用时间是多少？这三个问题的答案，基本就能框定非功能需求的范围。
3.3 需求优先级排序：用 KANO 模型区分“必须有”和“有了更好”
零售业务方通常会说“这个功能很重要，那个功能也很重要”，但资源永远是有限的。我一般用 KANO 模型把需求分成三类：基本型需求、期望型需求、兴奋型需求。基本型需求是“没有它系统就不能用”的，比如下单、支付、库存扣减。期望型需求是“有了它业务效率更高”的，比如批量导入商品、自动生成补货建议。兴奋型需求是“有了它业务方会惊喜”的，比如基于历史数据的智能推荐补货量。
排序时，基本型需求必须全部进入第一个迭代，期望型需求根据资源情况排入后续迭代，兴奋型需求先做技术预研，不承诺上线时间。这里有一个踩坑经验：业务方往往把兴奋型需求说成基本型需求，比如“智能补货是必须的”。这时候我会让他们描述当前没有这个功能时，业务是怎么运转的。如果当前有替代方案（比如人工经验补货），那它就不是基本型需求，可以往后排。
3.4 需求评审的检查清单与常见争议点
需求文档写完不等于需求确定，必须经过评审。我一般会准备一份检查清单，评审时逐条过：每个需求是否有明确的角色和触发条件？每个需求是否有可量化的验收标准？异常流程是否覆盖了超时、失败、重复操作？需求之间是否有冲突？非功能需求是否覆盖了性能、安全、日志？依赖的外部系统是否已经确认接口？
评审时最常见的争议点是“库存扣减时机”。业务方通常认为“下单就要扣库存”，但技术方知道“下单扣库存”会导致未支付订单占用库存，影响其他用户购买。这时候需要把两种方案的利弊摆出来：下单扣库存，用户体验好但库存利用率低；支付扣库存，库存利用率高但可能超卖。最终选择哪种，取决于业务对超卖和库存周转的容忍度。这种争议不要在现场拍板，而是记录下来，会后找业务负责人和数据负责人一起决策。
4. 零售系统落地避坑：从需求到上线最容易翻车的五个地方
4.1 坑一：库存扣减时机与超卖问题
现象：大促期间，多个用户同时下单同一商品，系统显示有库存，但支付成功后发现库存不足，导致超卖。原因：库存扣减逻辑写在了订单创建之后，且没有加锁或乐观锁校验，并发请求同时读到相同库存值。解决：把库存扣减提前到订单创建时，用数据库行锁或 Redis 原子操作保证并发安全。如果业务允许少量超卖，可以设置安全库存缓冲，比如实际库存 100 件，系统只放出 95 件。同时，支付超时未完成的订单要自动取消并释放库存，释放逻辑必须幂等，防止重复释放。
4.2 坑二：促销规则叠加导致金额计算错误
现象：用户下单时同时使用了满减、折扣、优惠券，系统计算的优惠金额与预期不符，有时多减有时少减。原因：促销规则的叠加顺序和互斥关系没有在需求阶段定义清楚，开发按照自己的理解实现，导致不同促销类型的计算优先级混乱。解决：在需求文档里明确促销叠加矩阵，定义每种促销类型的优先级、是否可叠加、叠加后的计算顺序。优惠金额分摊到每个商品时，要定义分摊算法（按商品原价比例分摊还是按数量平均分摊），并确保退款时按分摊金额退回。
4.3 坑三：门店与线上库存不同步
现象：线上显示有库存，用户下单后门店实际没货，或者门店卖出后线上库存没有及时扣减。原因：门店 POS 系统和线上商城系统各自维护一套库存，同步机制是定时任务，延迟较大。解决：如果业务要求实时同步，必须把库存中心独立出来，门店和线上都通过库存中心读写库存，库存中心负责并发控制和同步。如果业务允许一定延迟，定时任务的频率要明确写入需求，比如“每 5 分钟同步一次”，并在前端显示“库存数据可能有延迟”。
4.4 坑四：订单状态流转缺少异常分支
现象：订单支付成功后，系统没有收到支付回调，订单一直停留在“待支付”，用户重复支付。原因：需求阶段只画了正向流程，没有定义支付回调超时、回调失败、重复回调的处理逻辑。解决：在需求文档里补充支付回调的异常处理规则：回调超时后主动查询支付状态，查询失败进入人工处理队列；重复回调要幂等处理，只更新一次订单状态；支付状态与订单状态不一致时，以支付网关的数据为准，并触发对账告警。
4.5 坑五：需求变更没有留痕导致验收扯皮
现象：上线前业务方说“这个功能不是我要的”，开发说“当时就是这么说的”，双方都没有书面记录。原因：需求评审后的变更没有走正式流程，口头沟通的结果没有更新到需求文档。解决：建立需求变更流程，任何变更必须提交变更申请，说明变更内容、影响范围、工作量评估，由业务方和技术方共同确认后更新需求文档和映射表。变更记录要保留版本号，验收时以最新版本的需求文档为准。
5. 从需求基线到迭代计划：一个零售系统排期的实操技巧
需求基线确定之后，下一步是排期。我一般会把需求按“流程闭环”分组，而不是按“功能模块”分组。比如“门店补货”是一个闭环，包含补货申请、补货审核、仓库发货、门店收货、库存更新五个需求条目，这五个条目必须放在同一个迭代里，否则流程跑不通。按闭环分组的好处是，每个迭代结束都能交付一个可演示、可验证的业务场景，业务方能看到实际效果，而不是一堆零散的功能点。
排期时还要留出“技术债”和“联调”的时间。零售系统通常要对接多个外部系统：支付网关、物流平台、发票系统、会员系统。每个外部系统的接口联调至少预留 3 到 5 天，如果对方接口不稳定，时间还要拉长。我一般会在迭代计划里明确标注“联调依赖”，比如“订单支付功能依赖支付网关接口，需在第 2 周前完成联调”。如果依赖方延期，整个迭代就要调整。
最后分享一个我自己的习惯：每次需求评审结束后，我会把评审纪要、需求文档、流程-需求映射表打包成一个版本，命名为“需求基线_v1.0_日期”，发给所有参会人确认。确认后的版本不再修改，后续变更走变更流程。这个习惯帮我避免了很多次“当时不是这么说的”的扯皮。希望帮到你。
本文还有配套的精品资源，点击获取
