商超项目复盘：B端产品从无到有（二）

Grace吖 2023-07-22 14:35:03

完成第一阶段的问题识别和目标定位，下一步需要确定整个项目的系统定位、框架设计等提纲挈领性工作，包含系统架构、功能蓝图、核心业务流、需求清单、任务拆解、资源预算等。

当所有方案确认以后，公司通常会进行立项评审，项目经理将准备阶段的工作做总结，依次论述项目背景、业务痛点、解决方案、目标计划、软硬件资源预算、实施计划等，并由项目管理委员、业务发起人、技术专家组做评审和确认后，方可执行开展。

立项阶段：整体方案设计

1. 方案设计

（1）系统定位

这个阶段的工作，建议由产品经理和研发经理一起完成。因为对系统的定位、应用框架的选择，研发经理相对能提供更专业的建议和选择。

根据之前的调研，我们基本确定了以下几个角色：客户、商家、派送员、市场专员。基于以上角色的不同诉求，考虑通过4套系统来支撑。

客户端（小程序）：面向客户，支持下单和售后；

客户不希望下载新的APP，培养客户的使用习惯也不是一件容易的事情，包括放弃已有平台的流量红利更不是一个明智的选择。所以原下单平台建议保留，通过外部接口的形式，实现第三方平台的业务流转即可。

但将最关键的流量入口单方面的依托于第三方平台也不是一个长久之计，故自建平台也不能放弃。考虑到研发周期、以及用户体验的问题，APP、小程序、H5中，小程序无疑是更好的选择。

另外，公司可建立公众号，面向客户发布公司宣传信息，公众号菜单等便捷入口可绑定小程序，借助微信自带流量同步实现宣传、吸粉、流量转化。

商家助手（小程序/H5）：面向商家，支持查看配货量和账单；

在当前第三方平台中，一个学校只有一个店铺，并且不同学校上架的店铺有公司统一的名称【xx餐】。对于客户而言，公司就是商家，而公司所谓的商家端更像是采购方或者供货商。作为供货商，商家关注的重点是签订合同、货物配送、定期结账。

而其中线上店铺的创建、编辑、菜单的组合、定价等工作，一是相对于一般的餐饮服务从业者而言过于复杂，二是作为供货商他们并不太关注于这部分工作，都是交由市场专员做处理。

所以面向商家，有一个可以方便、及时查看配货量、结算帐单的平台即可。既然已有微信公众号，保留一个商家端信息查看的入口即可。同时，根据之前我们对业务合作模式的了解，短期内，这个方案应该是满足业务现状的。

派送助手（小程序/H5）：面向兼职派送员，支持出勤排班、任务查看、处理和工资提现；

派送员主要是学生兼职，它主要通过宿舍楼匹配等方式进行直接分配，不存在抢单、售后服务等功能，对于他们而言，最主要的工作还是查看及处理派送任务、以及工资提现的问题。考虑学生的身份，以及及时性随时性的要求，通过小程序抑或是H5平台来搭建兼职派送端，是最适合的方式。

另外在公司的业务模式中，派送员采用学生兼职团队。一是因为高校管控的严格性，外部社会人员很难进入学校甚至是寝室；二是考虑下一步发展兼职业务的可能，通过提供更多的兼职机会或是自主创业机会，来形成新的业务链。那下一步，兼职端也有自建APP的可能。

运营管理后台（PC）：面向市场专员，支持商家、门店、兼职的管理和订单管理等基础功能；

整个任务的工作重点，创建一套方便操作的管理后台，因为涉及到大量的商品编辑处理、账号、门店管理等功能，所以选择PC版本实现。另外，考虑当前主要面向角色是市场，其工作地点可变化性较高，所以不能限制外网访问权限。同时，虽然对移动版本的需求也不低，但综合研发周期、资源投入等问题，移动版暂不列入当前研发计划内。

从当前的现状来看，公司主要及需运营管理的角色是市场部门，需要做商家管理、门店管理、兼职管理；而随着公司下一步发展，面向运营专员的营销活动策划、反馈；面向客服专员的售后服务、理赔等都需要独立的系统去支撑。如果业务蓬勃发展，这几个平台在短时间也有创建的必要。

不过从现阶段来看，可以先搭建运营管理后台，后续有必要，再创建独立的客户管理后台、营销管理后台等其他相关系统；

（2）整体架构设计

根据以上内容，我们可以绘制出公司当前的应用架构图，包括对外的客户端、商家端、兼职端以及企业公众号；以及对内的运营管理后台，主要面向商家、店铺、商品等管理功能。

商超项目复盘：B端产品从无到有（二）

以上是本次项目所要建设的内容，但针对一个从无到有的企业。还需要哪些环节需要建设，才能保证企业内部正常运转呢。

首先，有关职能支撑类：

公司内部信息发布、职员休假、入职、离职、物资采购、登记等等最基础的功能，需要一个OA（Office Automation办公室自动化）系统去承接，通常每一家公司基础的办公需求都差不多，所以OA系统可以选择外采；
其次，招聘、员工入职、档案、异动、薪酬、绩效、考勤、组织架构等信息的管理，需要创建一个HR（Human Resource 人力资源）系统，这套系统通常也具备普适性；
再有就是企业邮箱，它和OA、HR共同构成办公软件三大件，属于职能支撑系统，都可以通过外采实现。

第二，有关基础支撑类：

客户通过新平台下单，需要调用当前客户位置信息等、调用第三方支付系统。当前客户端选择的小程序，这些都可以先选择使用微信方所提供已有功能。

当公司有包含微信公众号、小程序、APP、官网等多客户渠道时，会需要统一认证平台，确保客户信息的唯一性、避免客户多方登陆信息不同步等问题；当客户的业务逐步扩展，比如早餐业务从校园市场扩展至社区服务市场等，会需要GIS、地址库等基础单元存储客户的地址信息；当做节假日季节性营销时，也会需要Msg统一短信服务调度功能，给客户发送营销短信。

GIS、Pay、Auth、Msg这些系统，根据当前的使用场景，可以先由相关业务系统自主研发，后期都应抽象出基础支撑单元，供多系统调用服务。

第三，底层数据：

这点和基础支撑单元类似，当公司只有一套业务、一套核心系统时，像客户主数据、地址数据、订单数据等基础数据，可以由业务系统自己存储。但随着业务发展，逐步扩张有多套支撑系统时，通用的数据信息，一般都会抽象为底层数据，做统一的存储，一是避免重复造车、二是方便集中调用分析、三是减轻核心业务系统的运行压力。

第四，有关管理后台：

在一开始我们就分析过，为了扩张市场，吸引更多的用户，公司可能会有一些打折、满减等线上营销需求，针对一次营销活动的创建、运营、复盘，需要整套的营销中心系统来支撑；如果市场扩张顺利，用户暴涨的情况下，也相应会引发售后问题的暴涨，那有关工单创建、受理、结同时随着公司一步步发展。

据此，我们可以绘制成一张相对成熟的应用架构图。虽然在短时间，这些产品并不能够全部搭建完成，但是从一开始就考虑到公司可能发展的一个方向，并为此创建一张应用框架图。有利于架构师搭建一个相对健壮的系统框架，避免后期重复改造；二是提早设立规范，为每个独立系统设计一套统一的方案，方便后期集成，同时也让每个独立系统在一开始创建时，就考虑到其他板块可能需要的服务和调用。三是避免重复造车，像用户、权限、角色、登陆、支付、认证、信息推送等，每个系统都可能使用到，做成基础模块共用，可以节省不少时间。

商超项目复盘：B端产品从无到有（二）