餐饮供应链系统设计方案

一、业务场景及理解程度

首先是业务理解程度，无论是c端还是b端，业务熟理解程度我个人认为都是最重要的，如果要比喻的话，业务就是战场（场景），而其余的原型设计、交互规划、逻辑展开都是武器或战术，了解战场后才知道武器和战术要如何更好地运用。

下面先说说餐饮供应链中的一些主要业务场景。

（一）业务大场景：

一提起供应链产品，一下子会想到进销存，进货、销售、库存仅是一个经营个体最基础也最重要的三大环节，因为涉及到成本、收入等和“钱”相关的计算，这三个环节自身与三者之间衔接（单据流转、单位转换、审批流、角色权限等）也比较有复杂度。

然而这仅仅只是指一个个体内的进销存管理，真正的餐饮供应链中，若是中大型餐饮集团，还会加入多个个体（例如门店、集团、供应商、OEM、区域采配中心等）之间的协作流程，这中间的每个个体，都会或多或少的直接或间接地参与进销存流程，而他们之间，又会因打通进销存流程或者适度同步进销存信息。

比如连锁店与集团之间的信息交互，采配中心、区域各供应商和下属门店之间进销流转和打通等。总之只是最基础的进销存，就会涉及到多方之间的协调和影响，而根据参与方的不同，衔接的模式简直能出排列组合，产品设计也要在实际业务场景的复杂性、逻辑要求的严密性和模式通用性之间不断权衡周旋。

（二）用户场景

首先不得不把用户分为老板、管理人员（店长等）、执行人员（采购人员、库管人员等等），首先是老板，也许你首先会疑问，老板应该不会直接参与供应链操作，最多看看报表数数钱，然而在实际产品设计中真的会考虑到这些因素，比如涉及到一些错误单据的回退操作，操作者肯定不希望留下太多痕迹（即错误单据）。这时操作人员就会希望简单无痕地回退流程，例如直接把已审核过的单据反审核掉，在原单上继续删改重审。

但其实老板层次，则大多不喜欢这种方式，若是单据（出入库单据等）直接涉及到实物和金钱，这种操作或掩盖掉一些猫腻，另一方面，若是管理严谨的企业，还会和财务系统对接，反审这种抹干痕迹的逆操作会引起问题。所以老板心理上更喜欢有据可查，例如类似会计上的红冲留底操作。

其次是管理人员和执行人员，管理人员一般为单据（主要是工单）审核把关，查看单据时，例如在采购订单会考虑提单人员所购物料品相、数量、价格、供应商是否合理；在货物调配单据会考虑和调入店之间的关系等。而执行人员则是接到单据指令，亲自去仓库点货出入库或者盘点的，所以这两方操作的场景和考虑的问题其实可能会不同，流转在这两方之间的单据上数据会有差异，同时，不同业务环节，制单者是管理人员还是执行人员也会不一样，不同的情况，流转到下一级时，功能权限配置或单据上需要哪些灵活的处理也需要考虑。

（三）用户类型和操作习惯

to b的用户往往不向to c那么多样，因为每个领域作业的人特征不会差太多。而且最重要的是，他们要达成的目的和期待的效果大多情况下也一致。但这并不代表用户操作方面的产品设计就很简单，正是因为用户类型与作业复杂度的两极化，才会需要花更多心思；正是因为操作目的性的统一明确，才更需要在效率和严谨度间达到平衡。

1.用户类型：

餐饮基础从业人员，一般文化程度较低（没有贬低用户的意思，无论啥行业的工作者我都很尊敬啊，这里只是说出实际情况），有的甚至是一些老阿姨（尊敬，真的），这些人真的hold不住复杂而精细的操作，并且出错率时也会很高。

这就要求无论是元素、页面、流程都要尽量简单，有一种说法是把用户当傻瓜，一开始我听到这句话其实有点那啥，因为我也是千千万万互联网用户之一，但体会到这种困境时才发现，真的要珍爱那些把用户当傻瓜的产品人员，他们肯定不是真正意义上把用户当成傻子，而是天天费劲心思搜集用户操作习惯，在容错和严谨性之间的周旋中掉光头发。

扯远了，这就考虑第一，单据本身操作与相互流转时的容错性，这个容错性我指的是考虑到用户会犯的“错”，让流程正常运转。单据本身，例如不同供应商供应相同物料的价格可能不一样（这样的原因很多，品质、品牌、是否給门店有优惠价格等），在单据中，用户选择了供应商A，带出了物料的价格和税率，结果用户突然发现供应商选错了，切换成B，那下面的价格和税率也要跟着变才行。第二，出错后及时的提醒，引导如何可达成正确的结果。第三，页面在布局上要便于用户找到重点，例如不常用的字段尽量折叠，视觉流从左向右扫动，那么明细中重要的字段尽量左放，填写率低的但必不可少的字段放在尾部等。有的人可能会说，不用这么操心，再复杂的系统，用多了也就习惯了，但其实餐饮人员流动性很大，所以要在设计时就开始考虑。

2.操作习惯：

这里主要说两点，就是便利性和效率。在操作习惯这方面，跟文化程度无关，再博学的人，在工作时便利性和效率都是首要的。

便利性：举个例子，实际场景中，大多采买都会形成固定的班次，物料其实每次也大多相同，为了方便用户重复批量操作制单，你会想到什么？当然是复制粘贴，也就是单据的复制。再举个例子，一些属性类似且包含内容变动不大的元素，却会被高频的选取或分配，这时就要考虑是否可以把它们做成组或者模板，便于用户快速操作。

效率性：除了基本的页面上点击、选择次数尽量降低，保持操作连贯性，还有就是在pc端，尽量使用键盘化操作（关于这一点，其实我们也一直没做到），这点也是用户渴望的效果，因为不断在鼠标点选和键盘录入中切换，频繁中断操作流，即使是制单老手，也会影响效率。但完全键盘化，这也只是理想中的目标，因为有时也不得不考虑，这种优化的成本和副作用。

餐饮业态下供应链系统的应用场景一般较为复杂，并且具有多变性，而从业人员操作水平和接受能力又往往较低，这些难点一度导致笔者刚接触餐饮供应链系统产品设计时踩了许多坑。接下来将会从粗至细介绍和讲解餐饮供应链系统的产品设计，也算是笔者对自身知识框架的梳理总结。

（四）基础架构节点

在这里先介绍一下大致的组织架构层级节点，便于大家初步在脑子里形成大致的印象和联系。

集团：有的系统中也叫做总部或者品牌，但是在供应链中一般都对应的是有最高管理职能和权限的层级。系统中总部一般由服务中心人员或者实施人员建立，可独立登录，有唯一id。

公司：实际场景中，一个集团下可能有多个公司，例如百胜餐饮品牌下有必胜客、kfc、东方既白等。但是在系统中，公司也可以作为最顶层级（若是公司购买供应链的话），如果是集团购买，则集团则是最顶层级。

配送中心（总仓）：可建多个（例如按区域分）。一般是负责一个地区的采购销售库存的中转站，处理门店的订货需求、自己仓库（总仓）的采购、及销售给门店品项。在系统中可独立登陆，有唯一id。

外部供应商：为门店或配送中心（总仓）提供货物

中央厨房：统一制作一些成品和半成品，销售配送给所需商户

门店：可按照属性分为加盟店、直营店等，是对外销售菜品的单位，在系统中可独立登陆，有唯一id。

（五）集团-配送中心-门店

系统的组织架构往往要根据业务的发展方向和产品定位来确定。例如未来的业务计划是抢占长尾市场，即针对非连锁的个体小商户，不需要复杂的采购集散配送流程，只需要简单的进销存功能，则可以只有总店（可包含简单销售功能）和门店两级即可。

若是未来的战略发展瞄准了大型连锁商户，因为考虑到大型连锁店实际场景中，其在食品质量方面、集中控权方面有严格要求，同时采购供给模式链条也更为长，所以则可以至少建立总部、配送中心、门店三层。

接下来讲一下集团主要的模块结构，本文主要介绍集团-配送中心-门店模式。

1. 集团

（1）品项管理

由于集团在组织架构中是顶层，一般为了有这种三级模式的连锁大型餐饮企业，在商品质量规格方面都有统一要求，所以物料品项信息，像包括代码、名称、规格、各种单位及换算率、各类属性（例如自采还是统配）等，一般由总部统一设置。

（2）供应商管理

由于对质量有把控，集团一般会选择某些供应商长期合作，也会要求下面的门店使用这些供应商供应的品项，所以集团需要有管理供应商的模块，可以给品项类别指定供应商，做的完善一点甚至可以构造供应商评级系统。

（3）门店和及配送中心管理

可以管理或者配置门店或者配送中心的信息、属性等。信息方面，例如门店或配送中心名称、区域地址、门店性质（直营／加盟）等。属性方面，例如门店盘点属性（明盘／暗盘）、订货接受性质（强制接收／可修改入库数量）等。这些信息或者属性多数情况下涉及到整个体系的管理，只能由总部配置。

（4）报表管理

作为集团当然也会有了解下面门店采购数据、菜品销售数据，配送中心的采销数据等需求，以便更好的制定管理决策。

（5）系统管理

用户配置用户、部门、角色权限、数据权限等。

2. 配送中心

（1）基础设置

一般包括对客户（下属门店）、供应商、品项等的设置。虽然集团已经规定了配送中心可使用的品项，部分可采购的供应商、区域内所属的门店，但是配送中心由于实际业务需要，还会在这些既定项上配置附加属性。例如某些品项是直销给门店还是由外部供应商配送；对不同供应商提供的各个品项采购价格的管理设置；对不同门店销售品项时销售价格和优化策略的管理设置。

（2）订货管理

订货单管理：配送中心每天要处理大量的从各个门店发过来的订货单外，每笔订单上品项的库存 储备情况也不同，有的有现货，有的需要先向供应商采购（配送中心自身向供应商采购的订单要走另一套），不同物料的供应商也许不同…简单的一笔订单，有着复杂的处理分支，所以需要强大的订单系统对这些进行自动化处理。

配送规则：为了解决配送门店订货时间碎片化、品类没有规则性，而增加配送中心库存管理、采购和配送工作的难度的问题，同行需要有为门店指定配送规则的模块。

（3）库存管理

出入库单据管理、各个仓库即时库存、仓库盘点管理、仓库间调拨管理，库存安全预警配置、库存锁定量配置、期末结转等都是需要考虑的。

（4）采购管理

配送中心自身向各个供应商下的采购订单。

（5）销售管理

配送中心销售给门店货物时产生的是销售订单。

（6）加工管理

有的配送中心内设中央厨房，需要自己加工半成品等。有的配送中心会和OEM合作，则需要指定加工成本卡等。

（7）报表管理

出入库报表、门店订货统计表、采销统计表等

（8）对账管理

门店对账、供应商对账等

（9）系统管理

用户配置用户、部门、仓库、角色权限、数据权限等

3. 门店

（1）基础设置：

品项：同样，在门店维度也需要根据实际情况在品项上设置一些适用于自己的属性，例如是否允许库存为负数等。

供应商：除了向配送中心采购规定品项，门店也会向外部供应商订货（毕竟买个葱姜蒜没有必要一般都会在附近小菜店解决），所以也需要有自己的供应商管理设置模块。

成本卡：一般有菜品成本卡和半成品成本卡两种。由于门店层就会涉及到对菜品的销售，也会自己粗加工部分半成品备用，所以需要提前配置好对应的成本卡，两者有较大区别，后期文章会详谈。

（2）库存管理：基本与配送中心模块一致

（3）采购管理：由于供应商可能是配送中心，也可能是外部供应商，两者在流程和单据上都有较大区别，需要作区分。

（4）报表管理：出入库报表、菜品销售相关报表等

（5）对账管理：供应商对账

（6）系统管理：用户配置用户、部门、仓库、角色权限、数据权限等

以上先粗维度地介绍了“集团-配送中心-门店模式”中的产品框架和主要功能范围，先建立起概念再循序渐进。接下来介绍该模式下的几种采销配送流程：

1. 门店——总店

一些规模较小的非连锁商户，通常不会有区域的配送中心这一结构。或者在实际场景中，总店有仓库可以贮存部分库存，简单地“兼任”配送中心这一环节，成为了品牌整体管理和销售品项的集合体。这些类型的商户使用供应链更注重的是单店个体的进销存功能，而这个“销”则主要体现在总店直接对门店销售。

2. 门店——配送中心

配送中心通常可以理解为一个货物的集散中心，会贮存一定量保存条件较低、保质期较长、门店高频需要，但为了品质把关又不许门店自行采购的品项库存。

当门店向配送中心下单，配送中心可以直接从库存中销售发货，无需先向供应商下采购订单采购。

“门店—配送中心”和“门店—总店”二者的不同：听起来基本上和第一点中的门店——总店模式一样，从单一流程上来看确实是一样的，但是在系统设计上来讲：

第一在职能方面，总店是全局管理+营业+总仓的职能集合体，这种模式适合的是1对1（一个总店销售给一个门店），或1对多（一个总店销售给少数几个门店）。而配送中心，则是仅有总仓或加工职能的个体，一般适合1对多（一个配送中心销售给其区域内所有门店）或多对多（一个集团下，有多个配送中心，除了负责自己区域门店的销售外，也会给其他区域门店配货）。

第二，在功能设计上，由于“门店——总店”模式中，总店负责的门店较少，故采销系统具备基础功能即可，门店端有采购订单管理、总店端有销售订单管理等主要模块。

而“门店——配送中心”模式中，由于配送中心用户通常要处理大量门店的采购需求，为了减轻审批、拆单的负担，同时避免订货需求碎片化而造成的实际业务中库管及采销管理成本增高，供应链系统需要设计的更加效率化，仅在销售订单管理这个环节前，往往还需要有订货看板（用于规范门店的订货品类及时间规则）、门店订货需求池等功能（用于批量有序的处理大量门店品项订购需求），以及拆单环节。门店端也要遵从订货看板下单。而这也只是基本的，如果想要有更加全面还可以对配送路线加以职能分配、管控…能做的还有很多，暂时不赘述。

3. 门店——配送中心——供应商——门店

上面说到有些品项配送中心会常存，但是像一些生鲜等，新鲜程度要求高、存储成本更高，但又不能放任门店自行采购，就会产生这种“门店——配送中心——供应商——门店”模式，即门店订货，配送中心收到订货需求，再向供应商采购，由供应商直接配送到门店。这种模式其实大家平时在电商平台购买商品也会遇到，比如在京东买东西，就会有的在商品页表明需要先向供应商采购再配送到你手中。这种模式下系统设计方面需要注意的以下几点：

第一，如果供应商并不在你的供应链系统内，由于下单主体和要货主体不一致，就必须在配送中心向供应商下单后，设计有效的外部通知方式，通知供应商他所需配送的门店地址。

第二，反馈机制。由于验货的是门店，而一般向供应商付款的是配送中心，门店月末再向配送中心集中结账。经过门店清点验收后实际收到的货物可能或多或少与订货需求有差异（供应商少送漏送或途中品项变质损坏是常有的事儿），所以需要一个基于订单的有效收货反馈机制，以便配送中心和供应商结算货款。

4. 门店——配送中心——中央厨房——门店

如果门店订购的是需要二次加工的品项，则在上一方式的基础上，要加入中央厨房或者OEM（代工生产）。有些大型餐饮企业会有自己的中央厨房，例如海底捞的，除了加工一些成品、半成品供给给自己集团下的店铺，也会供给其他渠道（例如各大超市、商铺）。如果供应链系统足够强大，可以把中央厨房也纳入系统中，则可以支持这一整套模式。

而中央厨房的加入，会使得流程变的更为复杂，一般是中央厨房接单生产，库存不足时自行采购，最起码会涉及订单管理、进销存管理、加工卡管理等。而实际场景中，中央厨房的出品既有可能直接配送给门店，也会配送给配送中心，仅是进销存的管理设计复杂程度就不亚于配送中心。

5. 门店／配送中心／中央厨房——供应商

其实除了上面提到的协作采销方式外，还有一种最基本的方式，就是各个主体自己去向外部供应商采购。不过目前很多餐饮供应链系统中，外部供应商端为第三方，不在系统内，所以供应商销售给门店／配送中心／中央厨房的行为一般在系统内只体现于采购订单和采购入库单中，供应商的销售行为则不在系统内。

小结

看了这么多模式，你们可能觉得这几个主体之间的协作方式多到可以排列组合了，但是其实根据供应链的目标群体不同，也并不是要全部具备这些流程。如果产品瞄准的长尾小众市场，或者产品中有简易版本，则搭建模式1即可。

如果剑指大型连锁，则可以考虑后面几种，并且也不需要一口气全包含，先搭建基础的、再当前客户中普遍的模式，再补充加入其他环节来做到差异化增强市场竞争力也未必不可。并且也不一定要面面俱到，照葫芦画瓢，切记灵活地低成本地设计出满足用户需求的功能才是产品经理需要具备的能力。

物流IT圈

泛物流行业IT知识分享传播、从业人士互帮互助，覆盖快递快运/互联网物流平台/城配/即时配送/3PL/仓配/货代/冷链/物流软件公司/物流装备/物流自动化设备/物流机器人等细分行业。长按二维码即刻加入我们，如果你是以上行业公司中的IT从业人士加运营小哥微信后可入群交流。