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

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

立项阶段：整体方案设计 1. 方案设计

（1）系统定位

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）整体架构设计

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