复盘|集采系统的整体设计方法
当一个系统的内部分校业务越来越多,而且都是小量的零散订单,这时需要花费大量人力来做重复性流程工作。从这个方面,如何设计集采系统,让它提高效率呢?本文作者对此进行了分析,一起来看一下吧。
一、项目背景
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商城。实现了全流程线上自动化,省人耗、提效能、降风险、重数据,使采购业务高效安全。
此处的用户包含:
- 学生:获得学习资料;
- 家长:为学生的学习和效果买单,对该类用户,主要是提升其满意度;
- 老师:教学支持,需要教辅图书、教具、文具等。
此处的分校包含,但不限于:培优、网校、小猴、集团客服团队等。
业务流程图如下:
根据该业务流程,可以分析得出产品的产品逻辑流程如下,主要分为:
- 选购阶段
- 审批阶段
- 发货出库
- 物流收货
- 费控结算
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端图书采购平台,实现选购、下单、审批、发货和结算的全流程自动化,整体人效提升90%以上;
- 1个月发布MVP,3个月跑业务,实现采购流程规范化、透明化、数据合规化,累计GMV超2000W。
3. 提效数据
具体来看,整个采购的阶段可分为4个环节,那么在各个流程中,我们都能看到明显的效果提升。
1、咨询选品环节:从原来的5~7天,提升到2小时;
2、下单环节:从原来的半天,提升到5分钟;
3、收货结算环节:从原来的5天,提升到10分钟;
4、回款环节:从原来的30天,提升到1天。
整体而言,集采系统的设计和开发:
- 使得图书采购的业务效率提升了数倍,并释放大量的人工重复劳动;
- 财务流程外显化、合规化,使得采购业务更加可持续发展;
- 采购操作数据、订单数据等都能永久留存在线上更持久,方便集团的内审内控进行监督和管理。
八、总结
本文整体复盘了一款集中采购系统。从用户心声出发,分析需求场景,制定了产品的阶段性目标。产品方案的梳理,从业务流程开始,分析了用户画像,角色关系,并给出了详细的产品架构图,明确了产品范围,以帮助产品落地开发。
作为产品开发必要的文件,本文也给读者展示了客户端和后台系统的需求节点的详情。
最后,从产品和数据等维度,展示了产品成果。
希望,对从事和学习相关产品的同仁有启发。
作者:Echo小姐,公众号:产品经理的逻辑与审美
本文由 @Echo小姐的产品论 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
- 目前还没评论,等你发挥!