复盘｜集采系统的整体设计方法

当一个系统的内部分校业务越来越多，而且都是小量的零散订单，这时需要花费大量人力来做重复性流程工作。从这个方面，如何设计集采系统，让它提高效率呢？本文作者对此进行了分析，一起来看一下吧。

一、项目背景

1. 用户心声

我们的内部分校业务越来越多，而且都是小量的零散订单，要花大量人力来做很多重复性流程性工作，希望这套产品能解决的问题：

1）不用再人工一单一单发货，让分校客户自己去系统下单，自动连接C端ERP和B端ERP系统发货，客户还可看到快递信息，运营伙伴就可以把更多的时间用于前端业务拓展和服务客户上，效率可以大大地提升；

2）客户下单、上级确认、订单确认和成本中心确认等全程线上化，这也可以大大节省财务老师的工作流程；

3）以前我们只能接分校的ToB订单，即只能物流发给分校。但还有一个业务场景，分校很多部门没有仓储和发货能力，希望我们来代发货，之前我们靠人力是无法支持这种toC代发采购的订单的，如果有了这个系统，这一部分业务也可以承接了，能真正实现供应链集成复用，并能给更多兄弟事业部赋能。

需求小结：

• 分校运营团队需集中采购图书
• 采购过程人工操作，费时费力，成本高，易出错
• 集团要求，内部采购需真实打款，财务透明化
• 需符合“审计”对过程合规性的稽查

产品预期：

• 快速下单，一键审批，全流程线上化
• 数据安全、可视化
• 系统联动，流程打通，信息透明，合法合规

2. 现状分析

根据用户心声的描述，对现有问题，可以归纳为以下两种诉求：

1）入仓采购诉求

目前运营老师一个月需要洽谈入仓采购内部合作金额高达200多万，但是每次进行下单、订单跟进、结算都是线下完成，需要运营老师自己去ERP系统查库存，再反馈给采购方，整个流程耗时较长，后期数据不好追溯，数据无法长期沉淀。

2）代发采购诉求

目前代发采购有很多的需求，但是因为代发采购需要去C端ERP系统手工下单，洽谈一次合作可能需要购买4000本书，但是每一本书都是不同的收货人，运营老师没有人力手动去下4000个订单，并且跟踪和反馈这批订单的难度极大。

二、需求分析

1. 入仓采购（2B场景的采购）

场景描述：集团的各个分校，在教学的过程中，可能需要采购品牌图书。

场景举例：某个分校，在暑假期间，为了给学员进行强化训练，需要集中采购10000本《XXXXXX》的图书。这种情况下，是很难通过电商渠道的图书商城进行购买的，而且，这笔购书费用不能让采购老师自己掏腰包，需要走分校的“集团内部财务账户“进行统一的结算。

产品诉求：那么，基于这种场景，就需要一个系统来进行集中的批量采购，采购老师只需要选择需要采购的图书，确认收获信息、物流信息、发货清单等信息就可提交采购单了，费用问题通过集团内部账户对接扣款和划拨即可。

该场景的需求业务流程图如下：

2. 代发采购（2C场景的采购）

场景描述：由于集团内有些部门或分校等，会不定期举办一些有奖赠送的活动，奖品可能涉及图书。

场景举例：某次活动有10000个用户参加，其中100人获奖了，需要给获奖者每人赠送一本《XXXXXX》的图书作为奖励，那么该活动组就需要分别给所处不同地点的100个用户分别各寄送1本图书。基于这样的业务场景，操作起来就非常费时费力，如果活动人数更大的话，就几乎不能靠人工实现。

产品诉求：如果能有一个针对该种情况或者类似情况的系统，从技术角度实现该功能，就能极大地节省人力物力，提高效率，且数据可储存、复用、沉淀，便于记录和追溯。

该场景的需求业务流程图如下：

三、竞品分析

本需求主要是内部采购业务需求，结合电商以及审批流程进行产品方案设计。暂未有明确的竞品。

四、项目目标

在现有需求的基础上，我们对产品进行了长期的，分阶段的规划，主要分为四个阶段。前三个阶段，主要聚焦在产品的内部应用，满足集团2B2C的采购需求。从图书采购，逐渐拓展到其他品类的采购。长期来看，是希望能达到采购系统平台化，商业化的目的，实现系统的自盈利，自增长。

1. 一期阶段

• 在1个月内完成集采系统MVP的版本的方案PRD落地、需求评审、UI设计和评审、前后端开发、联调、产品测试、验收和上线；
• 为后续产品的有序迭代打下坚实的基础；
• 跑通业务场景，满足运营诉求，当前千万级的GMV业务覆盖率超30%；

2. 二期阶段

• 希望通过在线化系统提升运营效能、减少财务的工作量、增加交易的安全性，并避免误操作；
• 当前千万级的GMV业务覆盖率100%；
• 彻底替代人工采购操作，全部迁移线上化；

3. 三期阶段

• 系统全流程打通，内外部系统运作更加敏捷顺畅；
• 满足更多业务场景，支持更多采购需求，拓展到集团的其他品类采购；
• 预期带来2～3倍的GMV增长；

4. 长期目标

• 外购系统平台化，商业化，为更多外部小B业务的采购提供支持；
• 实现采购平台的自盈利、自增长。

五、产品方案

1. 业务流程梳理

面向我们的用户，各分校在不同阶段，都需要进行图书的采购，主要有入仓（集中入仓再分发）和代发（一次性分发给用户）两种采购模式。确定好采购方案后，在集采系统进行采购操作，在这个过程中，需要通过集团共享的通讯系统、商品库、OMS、ERP、财务费控系统、BPM审批流程等系统的交互和支持。

在完成采购操作后，商品出库，经过物流的配送，用户收货确认，并进行系统结算。整个过程需要集团审计的参与和监控，全流程线上化。

总之，就是需要提供一个一站式的图书采购业务的PC商城。实现了全流程线上自动化，省人耗、提效能、降风险、重数据，使采购业务高效安全。
此处的用户包含：

• 学生：获得学习资料；
• 家长：为学生的学习和效果买单，对该类用户，主要是提升其满意度；
• 老师：教学支持，需要教辅图书、教具、文具等。

此处的分校包含，但不限于：培优、网校、小猴、集团客服团队等。

业务流程图如下：

根据该业务流程，可以分析得出产品的产品逻辑流程如下，主要分为：

1. 选购阶段
2. 审批阶段
3. 发货出库
4. 物流收货
5. 费控结算

2. 用户画像分析

根据用户心声和需求场景的洞察得出，集采系统面向的典型用户画像，可以描述如下：

集采系统面向的用户可以抽象提取为集体画像，描述如下：

3. 角色交互关系

该系统运营的过程中，主要涉及的角色有：

• 业务员角色：负责业务洽谈、采购咨询、客服等；
• 采购员角色：通过集采系统进行采购操作；
• 采购上级角色：审批采购行为；
• 业务运营角色：审批采购行为；
• 库房角色：收发货、出入库等；
• 使用者角色：收货、反馈、评价、使用采购物品；
• 财务角色：结算；

以一次典型的采购操作为轴线，各角色前后互动形成了一个互动网络，绘图如下：

4. 产品系统构架图

在流程梳理清楚，产品逻辑构建完成后，产品前后台的架构关系已经跃然纸上了，是指导产品开发的重要工程文件，如下：

5. 产品范围

1）集采系统-PC端商城

PC商城提供全流程采购服务，包括：浏览检索商品、加入购物车、购物车管理、下单、确认信息、审批、订单管理、审批管理、结算确认等。

2）集采系统-管理后台

• 商品库管理
• 价格管理
• 订单管理
• 财务对接
• 审批管理
• 用户管理
• 用户分析
• 采购分析
• 数据中心
• 交易管理
• 库存预警
• 角色与权限管理
• 通用数据管理

3）对接的第三方系统

①集团用户中心

该对接主要用于真实身份的登录和验证；

需要统一通过有效方式登录，需要获取用户相关数据；

数据维度：真实姓名、工号、邮箱、部门等。

②集团发票管理系统

集采系统的采购业务，提供正规的增值税普通发票，需要分校老师提供其所在公司主体、税号、开户行、电话、地址等信息；

为了更快捷安全地输入发票信息，采用系统对接的方式，集采系统提供集团所有收录的开发票信息；

采购员进行选择即可。

③集团费控中心

分校采购，不需要支付现金，通过内部财务结算；

内部结算对快捷的方式就是对接费控系统，将费控单据作为支付凭证，实现内部打款和结算；

采购员需要在采购之前，创建费控单据，在采购时，选择对应的费控单据即可；

费控单据后续的审批流程，在集采系统持续更新。

④集团通知助手

集采系统的审批流程，可通过集团助手消息推送的形式实现；

审批方收到消息，点击详情，即可跳转到系统的审批页面。

六、 需求详情

需求详情涉及企业产品，这里做简要处理，仅展示主要的节点的相关方案图，请理解。

1. 用户端

1）登录：通过集团账号扫描或者账号密码登录

2）选择采购模式

3）浏览商品

4）功能页–商品详展示+加入购物车

5）功能页-购物车管理

6）采购单确认页（入仓采购）

7）审批流

8）费控对接

2. 后台系统

1）商品管理

2）采购单管理

3）审批管理

七、 项目成果

1. 产品展示

从MVP版本开始，在2年时间内，陆续完成了30多个版本的迭代，基本实现了前两期的目标。

2. 成果数据

从0~1产出web端图书采购平台，实现选购、下单、审批、发货和结算的全流程自动化，整体人校提升。