Java生鲜电商平台-生鲜电商订单结算系统的深入解析与反思总结

Java生鲜电商平台-生鲜电商订单结算系统的深入解析与反思总结

说明:最近疫情影响，生鲜电商这个行业被彻底的激活了，全中国人民都知道用小程序或者APP可以进行买菜了，但是可惜的是，我的生鲜电商在去年经营了两年半左右的时候因为

一些原因被暂停搁置了，回顾在六年的生鲜电商职业生涯过程中，我想有没有什么值得跟大家学习与思考的东西呢？

这是笔者2018年上半年负责的企业订单结算系统，虽然题目写的是订单结算系统，但里面也涉及到了订单系统、发票系统、投入产出系统，四个系统互相联动。在产品设计过程中，碰到

了一些问题同时也解决了问题。

文章总结了订单结算系统后台产品从0到1设计过程中的一些反思，与大家分享，希望可以给大家一些启发。但本人经验尚浅，也望大佬们提出意见。

为避免公司敏感信息泄露，以下公司名称、功能名称均为化名。

 

 

 

 

大纲如下：

1.项目基本介绍

2.业务调研

3.系统的整体方案设计

4.系统的细节方案设计

5.系统重难点分析

6.个人收获与总结

一、项目基本介绍

随着A公司的不断发展，订单量逐渐增多，市场部的商务同事对于结算有了新的业务需求，财务部的同事每到月底都头疼于财务报表和投入产出的数据输出。原有的订单结算方式不再高效，同时也缺乏相应的数据分析。

A公司管理者希望建立一套全新的结算系统，这个系统可以解决订单结算、发票管理、财务报表和投入产出这四个问题。管理者可以通过系统的财务报表和投入产出做出下一阶段的工作安排和决策，A公司员工也能更加高效地处理工作问题。

二、业务调研

2.1业务现状梳理

A公司希望产品运营部门今年能实现业务数字化管理，这个部门在今年能获得更多的订单量。原先的订单结算系统在一个办公协同软件上跑，无法实现数据分析，管理层无法通过数据做出决策。

这个新的订单结算系统的战略目标是帮助部门快速实现订单结算，同时提高多个部门的工作效率和给管理层提供决策意见。

经过对市场部商务、产品运营部的同事、财务部的同事进行深度访谈，对目前结算的流程有了了解。整个流程为商务提起结算，商务申请开发票，财务开发票，结算完成。

2.2业务问题总结

（1）关键业务问题梳理

经过访谈分析，目前结算业务存在以下业务问题和需求：

每个客户都有许多订单，如何快速准确地查找选择应结算的订单

复核环节会出现价格修改、订单修改，如何保障退回给相应的人和修改完后给相应的人，流程需要高效

开票系统是否能显示应收款账期

对账和开票工作复杂

开票系统需要自动生成相应的开票周、月报表

投入产出涉及的系统包括部门原有的工时系统、订单系统和现在的结算系统、发票系统，如何处理四个系统的数据联动，如何保障成本和收入数据的准确性

（2）问题解决思路

实现商务快速准确选择订单（高优）

订单结算流程高效（高优）

实现账期监控（低优）

实现对账报表（高优）

实现周月财务报表（中优）

建立主数据库，联动多个系统，实现投入产出数据生成（中优）

三、系统的整体方案设计

3.1业务流程设计

通过对业务的了解和对各部门人员的访谈，思考了业务的各个参与方，原先结算流程缺少产品运营部门同事和主管复核和确认收款环节，现在设计的这个流程能够使结算业务变成一个闭环。

图3-1是经典的泳道流程图，横轴代表相关的业务部门，纵轴代表的是业务系统。

 

图3-1

3.2 应用架构融合

A公司的产品运营部门用简道云建立了订单系统、CRM和工时系统，这一次即将要设计的结算系统和发票系统必须要与原先的系统架构融合，结算系统结算的订单就是订单系统上的订单，投入产出要展现的数据是联动了工时系统、CRM、结算系统和开票系统。

3.3功能模块设计

通过自顶向下的分析思路，我们明确了这次结算业务分为两个系统，分别是结算系统、发票系统、投入产出系统。

接下来我们进一步拆解，将每一个系统可能需要的功能都列出来，先做加分后坐减法。

（1）结算系统

商务需要在结算系统选择订单进行结算，结算流程跑完之后，也需要对结算单进行查询，查询这个结算单目前流转到了哪个节点，后续也对报表功能有要求。

所以从商务和产品运营部的角度，结算系统应该具备以下模块和功能，如图3-2所示。

 

图3-2

（2）发票系统

发票系统是给财务部门使用的，这相当于一个发票管理后台，财务部的主管和员工可以用来查询发票，至于有哪些查询筛选项和查询值，这个放到产品细节设计再来考虑。

财务管理模块还有对账管理、账期管理、财务部门月报，如图3-3所示。

 

图3-3

（3）投入产出系统

投入产出系统其实就是为了生成投入产出明细表和业绩报表，投入产出明细表分为两大块，一块是收入，一块是成本。收入可以通过填写项目进度、成本可以通过薪酬录入和填写成本费用。

综合考虑，将其分为两个模块，一个是数据录入，功能分为薪酬等级录入、项目进度填写、成本费用填写、客户税率数据录入，其中成本费用填写和客户税率数据录入放在订单管理系统里提交订单的时候填写。

综合报表的功能有投入产出明细表、业绩分析、数据核对、客户分析，如图3-4所示。

 

图3-4

四、系统的细节方案设计

4.1数据建模

正确的数据建模，才能在后面的设计中更加清晰地完成功能模块的细节设计和交互设计。数据建模决定了数据库的表结构，对后续的报表设计十分重要，也能够体现产品设计者对业务的理解。

多个部门会用到结算系统，不同部门的使用权限不一样，因此有多层级管理的需求，根据对业务的理解和优化，组织结构树如图4-1所示。

 

图4-1

在组织结构树中，可以看到，这个业务有一个管理员总账户，这个管理员账户可以管理所有的数据，包括市场部、产品运营部、财务部这三个部门的所有数据，权限度最高。

每个部门下表明了一个员工有一个账户，员工使用自己的账户，可以在系统进行相应权限内的操作。

根据图4-1的组织结构树进行简化，可以得到图4-2的ER图。

 

图4-2

通过ER图，可以清楚理清账户、结算业务、部门、员工之间的关系，能够把业务中独特的逻辑关系理清楚了，这一步是关键的，唯有把业务数据建模好了，后面的设计才不会出现数据逻辑问题。

4.2页面流转图

业务流程图已经在项目的整体方案设计中设计好了，不过这是一个颗粒较粗的概要性设计，降下来将要绘制页面流转图。

页面流转图是用户完成某项工作需要涉及到的页面和流转顺序。我将根据业务流程并且针对不同的使用对象一一设计页面流转图。

结算系统的商务提起结算：市场部商务人员，图4-3。

 

图4-3

结算系统的项目经理复核、客户经理复核、部门主管复核、客户经理让客户复核、商务申请开票、财务开票、确认收款：分别对应项目经理、客户经理、部门主管、客户经理、市场部商务人员、财务部人员、财务部人员。

 

图4-4

结算系统的综合查询：市场部商务人员

 

图4-5

结算系统的报表：市场部所有主管、产品运营部主管

 

图4-6

发票系统的综合查询：财务部所有人员

 

图4-7

发票系统的财务管理：财务部门部分人员

 

图4-8

投入产出系统的数据录入：财务部门人员、市场部门人员、产品运营部门人员

 

图4-9

综合报表：管理层、财务部主管、产品运营部主管

 

图4-10

以上只是展示每个流程的主要页面，主页面里的管理、编辑、筛选、数据导出等页面由于篇幅过多且细，不在此全部展出。

4.3 页面设计

页面有太多了，所以只是展示结算系统的2.1项目结算提交页、3.1我的待办页这两个页面。

项目结算提交页是整个业务流程的开始页面，由商务提起，页面里涉及到的每一个文本、日期、下拉框、复选框、子表单、成员选项都是经过深思熟虑的。

这些设计反映了这个业务的需求，同时里面涉及到的一些函数和联动也是为了提高使用者的使用体验。

项目结算提交页的页面设计如图4-11所示。

 

图4-11

我的待办页面的页面如图4-12所示。

 

图4-12

4.4 权限设计

权限设计规范了哪些角色能看到哪些数据和做哪些相应的操作，所以分为功能权限、字段权限和数据权限。每一个模块和功能都有设置了权限。

在此我以结算系统作为例子进行复盘。

功能权限的权限表如图4-13所示。

 

图4-13

字段权限在结算流程中用到了很多，也是这次设计中的重点。字段权限规定了在这个流程中哪些字段能被哪些人看到，哪些人看不到。

这里必须得谈到RBAC（Role　Base　Access　Control）权限模型，这个模型由计算机科学家Ravi Sandhu于1995年提出。每个用户都会被赋予一个或多个系统角色，每个角色都对应一个明确的权限集合。

在结算系统中我将所有员工分为这几个角色，分别是财务、商务、产品运营部门主管、客户经理（动态角色）、项目经理（动态角色）。

我将复盘在结算系统中结算流程的每一个角色的字段权限，本应该细分到字段权限里的编辑和查看权限，但由于篇幅有限，只整理每一个角色和字段之间的权限，如图4-14。

 

图4-14

数据权限采用的是管理账户由所有数据的权限，包括编辑、修改、添加。不同角色的数据权限如图，这里也仅仅是讨论结算系统的结算流程。

 

图4-15

五、系统重难点分析

做这个项目一共经历了4个月，刚开始接手这个结算业务的时候，个人觉得并不是很难，初步以为只要解决好订单结算这个业务问题就行。经过业务调研之后，发现业务现存的问题还是蛮棘手的，同时要解决的业务需求很多。

由于是第一次接触B端产品的方案设计，也缺少对业务的深刻认识，最开始的两个星期处于停滞不前的状态。我与产品总监交流了当时的状况，产品总监也提供了一些解决思路，回去也看了一些B端产品的书籍，这个项目的设计才开始走向正轨。

不过在这四个月的项目设计中，还是碰到了一些问题，我在这里讲述最主要的三个重难点，分别是如何准确快速地查找应结算的订单、没提订单的项目怎么结算、投入产出的成本、收入、收款如何定义及生成数据。

5.1如何准确快速地查找应结算地订单

准确快速地查找应结算的订单可以说是结算业务最重要的业务需求也是最基本的需求，如果这个都实现不了，那么接下来的设计也进行不了，所以当时将这个需求的重要度和紧迫度都标为高优。

这个需求用大白话来说就是结算的时候不能漏掉订单，同时操作要方便。

通过业务调研，了解到部门的订单分为框架类和项目类。框架类订单指的是公司与客户签约了框架类合同，由售前经理去谈订单，订单上线之后，以月份或者季度为单位去收取这个月份或季度已上线的框架类订单的钱。

项目类订单指的是公司与客户签约了项目类合同，这类合同一般签约的时候会收一部分的钱，项目类订单全部上线之后再收剩下的钱。

经过分析，将订单分为两大类，如图5-1。

 

图5-1

因此要考虑后续的文本字段、数值型字段、表单哪些是两类订单共有的，哪些不是共有的。

在处理这个问题的时候，订单能够快速选择一直是商务提的重要需求。以框架类订单为例，怎么能确定哪些订单是应结算的呢？在订单管理系统中也没有字段说明这个订单是完成的。

那能不能在订单系统加一个日期字段和文本字段，让项目经理去填写这两个字段，那就能确定客户的订单是哪些完成的，哪些是没完成的，然后在结算系统的时候联动已完成的订单。

这个功能上线一个月之后，经过测试发现了两个问题，一是项目经理经常会忘记及时填写【订单完成】这个字段，二是以前的订单（上线之前）没有这个字段，无法被选择。

在测试过程中，又发现了一个问题，订单管理系统是产品运营部门使用的，他们对订单的命名是以项目为单位，也就是说一个项目名称，可能会有多个订单。但市场部商务结算的时候是以订单结算的，结算的时候依据项目名称无法找到准确的应结算订单。

经过对两个部门的再度访谈，更加深刻理解了订单业务。框架类订单一般是按月份来结算的，第一个问题的解决思路是，通过月份的选择，自动选出这个月的所有订单，商务提交之后，项目经理复核时进行修改。

这样就能解决漏选订单，并且只要选择月份，结算明细就会自动填充所选订单，提高效率，交互设计图为下图5-2。

 

图5-2

第二个问题的解决方法是，在订单管理系统中加多一个文本字段【报价名称】，【报价名称】命名规定是【项目名称＋日期】，这样就能使得每一个订单都是独一无二的。商务在结算的时候通过报价名称来选择订单能确保不会错选。

 

图5-3

5.2没提订单的项目怎么结算

通过业务调研，得知订单的提交规则是，所有订单都会提交在订单管理系统。但是项目类的订单可能还没来得及提交订单管理系统，这个项目就要先收一部分的钱。这种情况的话，结算系统里也找不到这个订单，无法进行项目结算。

刚开始想设置一个虚拟订单，结算的时候勾选这个虚拟订单，虚拟订单的价格自己编辑，并且能够反向联动到订单管理系统里，这个订单的提交是在结算系统里提交的。不过这个方案技术方面行不通，牵扯到两个系统，开发难度大。

这个问题困扰了一阵，无法解决的话，结算就会漏订单。后来的解决思路是如果这个订单还没在订单管理系统上提交，结算的时候可以先漏掉，不过金额需要手动修改为全部订单的金额。

漏掉订单的结算单用一个字段标记，每个月底由商务检查这些标记的结算单，去订单管理系统查看这个订单有没有提交了，一旦提交了就在结算单中编辑上来，没有则不用操作，通过人工编辑来解决漏订单的问题。

虽然不是很智能，却能够顺利解决事情。就目前来说，这个看起来比较笨拙的方法是最好的方法。

 

图5-4

5.3 投入产出的成本、收入、收款如何定义及生成数据

财务部门个月都需要整理出当月的投入产出指标，财务部的同事以前一直是用Excel去生成这个指标，不过就这一个指标以前就需要２－３天的时间来整理，因为这个指标涉及到项目的成本、人工成本、分摊成本、收入、进度、收款情况，这里的每一个数据都需要向产品运营部门的主管和市场部的主管获取。

这个指标涉及到的数据大部分都在公司的系统上，少部分不在的需要在相应的系统里添加，所以如何跨系统增添字段而不影响原有系统也是一个难点。

经过思考，将投入产出分为三个模块，分别是成本、收入、收款情况。

成本模块如下图5-5。

 

图5-5

其中每类成本费用的定义和操作是：

薪酬等固定分配成本费用：需要设置一个薪酬等级录入表，这个表将员工薪酬分为４个等级，避免详细薪资曝光，财务填写这个数据，联动工时系统里的每个项目的工时。某个活动的工资成本=全部人员投入相加，单个人员的某个项目活动工资成本=单个人某个项目活动工时/个人总工时*工资

代发奖品成本：在订单系统里增加这个奖品（不含税、不含手续费）的成本字段，由商务在订单管理系统里提报价的时候填写

外透服务器成本：在订单系统里增加服务器的成本字段，由商务在订单管理系统里提报价的时候填写

委托开发设计费成本：自动联动外包系统的订单成本（外包系统有，无须再添加）

推广成本：在订单系统里增加投放／推广的每月实际投放／推广的字段

投放成本：在订单系统里增加投放／推广的每月实际投放／推广的字段

收入模块如图5-6所示。

 

图5-6

表的一些字段的定义和操作：

实际工时：通过工时系统里可以得知每个项目当月的工时；

开发效率：人日开发效率=含税收入/（实际工时/8）；

含税收入：含税收入＝订单含税金额＊进度，需要在订单管理系统增加一个项目进度的编辑页，每个月底由项目负责人去填写项目进度，从而得知这个项目的当月进度；

不含税收入：不含税收入=含税收入/（1+增值税税率），增值税税率通过财务每月去客户数据录入页填写客户的增值税税率值来确定。

 

图5-7

收款情况：收款情况可以在订单管理系统里增添【流程状态】字段，通过结算系统的流程状态联动订单管理系统的每一个订单的收款情况

六、个人收获与总结

这是第一次接触B端产品的设计，以前也有过C端产品设计的经验，发现两者还是有很多不一样。

最开始的业务调研，B端是要针对业务问题进行访谈，梳理业务现状，总结业务问题，目的是获取业务需求，给出解决方案。Ｃ端则是需要市场分析、竞品分析、调研问卷、深度访谈获取用户需求，解决用户痛点。

B端产品和C端产品在设计上也有不同，针对性不同，在这里就不一一展开了。

通过这次的结算业务产品设计，将产品从０-１进行设计，后续通过测试和运行获取反馈，进行迭代，使得产品落地，现在也已经投入使用。在这段经历中，我也收获了不少，自己也成长了不少，个人收获如下。

对需求有了更深刻的认识，需求优先级、假需求这些都有了深刻体会。做产品必谈需求，但又有多少人是真的懂需求呢，C端产品的需求可以用Kano模型，B端产品在收集需求时应该问问自己这四个问题：这个需求背后真正的问题是什么？这个需求有快速解决的办法吗？这个需求是个别需求吗，值得花多长时间去解决？这个是共性需求，优先级如何？面对需求的时候，多问问自己这四个问题，对需求才会洞察地更加深刻。

对B端产品的结算方向有了经验积累，在这次产品设计中，也更加深刻地体会到业务的重要性。对业务理解地越深刻，产品的设计才会更加高效。

跨部门合作锻炼了我的沟通能力，因为结算业务需要跨系统、跨部门合作，所以同公司的所有部门都有了接触，一番接触下来，学会了如何同上级反馈问题、与研发交流、与产品运营部门、财务部、市场部进行访谈。这对我来说是一次大的交际挑战，持续的沟通也让我学会了如何更好地交流和获取业务需求。

项目管理能力的提升和学习，这次的产品设计没有项目经理来安排项目进度，靠自己来规划项目，所以也深刻de好的项目管理能保障项目按计划推进、落地，同时也能保障产品研发的效率和质量。

虽然这次我只是接手了结算项目，负责了结算系统、发票系统、投入产出系统，但将这些系统融入公司原有的架构中，我明白了一个好的企业应用架构对公司来说多么重要，只有合理地将这些系统全部融合起来，企业的业务才能全部盘活起来

 

 

 

 

实际运营截图：

联系QQ：137071249

QQ群：793305035