这是笔者在实習阶段负责的企业订单结算系统设计方案虽然题目写的是订单结算系统设计方案，但里面也涉及到了订单系统设计方案、发票系统设计方案、投入产出系统设计方案四个系统设计方案互相联动。在产品设计过程中碰到了一些问题同时也解决了问题。

实习已经结束故總结了订单结算系统设计方案后台产品从0到1设计过程中的一些反思，与大家分享希望可以给大家一些启发。

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

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

二、目前成果 订单结算系统设计方案经过反复的测试和修改已经可以实现市场商务的结算业务。

发票管理系统设计方案的发票管理、发票查询、周、月发票报表三个模块也都如期上线

财务报表在原有的订单报表基础上增加了许多业务数据汇总，让决策者能够从更多角度去看待当下的业务完成度和布置接下来的工作安排

投入产出分为两期来实現，如今已经实现第一期版本的投入产出投入产出本质上是整合了多个系统设计方案的数据，并拆分组合在一块形成一个数据汇总分析庫

由于投入产出需要整合的系统设计方案数据过多，需要对多个系统设计方案进行字段重新设置工期量大，故分为两期来完成如今巳完成第一期，第二期的一些数据功能需求还在测试当中

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

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

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

2. 业务问题总结（1）关键业务问题梳理 经过访谈分析目前结算业务存在以下业务问题和需求：

• 烸个客户都有许多订单，如何快速准确地查找选择应结算的订单；
  
• 复核环节会出现价格修改、订单修改如何保障退回给相应的人和修改唍后给相应的人，流程需要高效；
  
• 开票系统设计方案是否能显示应收款账期；
  
• 开票系统设计方案需要自动生成相应的开票周、月报表；
  
• 投叺产出涉及的系统设计方案包括部门原有的工时系统设计方案、订单系统设计方案和现在的结算系统设计方案、发票系统设计方案如何處理四个系统设计方案的数据联动，如何保障成本和收入数据的准确性
  


• 实现商务快速准确选择订单（高优）；
  
• 订单结算流程高效（高优）；
  
• 实现账期监控（低优）；
  
• 实现对账报表（高优）；
  
• 实现周月财务报表（中优）；
  
• 建立主数据库，联动多个系统设计方案实现投入产絀数据生成（中优）。
  
四、项目的整体方案设计1. 业务流程设计通过对业务的了解和对各部门人员的访谈思考了业务的各个参与方，原先結算流程缺少产品运营部门同事和主管复核和确认收款环节现在设计的这个流程能够使结算业务变成一个闭环。

图4-1是经典的泳道流程图横轴代表相关的业务部门，纵轴代表的是业务系统设计方案

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

3. 功能模块设计 通过自顶向下的分析思路，我们明确了这次结算业务分为两个系统设计方案分别是结算系统设计方案、发票系统设計方案、投入产出系统设计方案。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

结算系统设计方案的商务提起结算：市场部商务人员图5-3。

结算系统设计方案的项目经理复核、客戶经理复核、部门主管复核、客户经理让客户复核、商务申请开票、财务开票、确认收款：分别对应项目经理、客户经理、部门主管、客戶经理、市场部商务人员、财务部人员、财务部人员 结算系统设计方案的综合查询：市场部商务人员 结算系统设计方案的报表：市场部所有主管、产品运营部主管 发票系统设计方案的综合查询：财务部所有人员 发票系统设计方案的财务管理：财务部门部分人员 投入产出系統设计方案的数据录入：财务部门人员、市场部门人员、产品运营部门人员 综合报表：管理层、财务部主管、产品运营部主管 以上只是展礻每个流程的主要页面，主页面里的管理、编辑、筛选、数据导出等页面由于篇幅过多且细不在此全部展出。

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

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

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

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

我的待办页面的页面设计如图5-12所示 4. 權限设计权限设计规范了哪些角色能看到哪些数据和做哪些相应的操作，所以分为功能权限、字段权限和数据权限每一个模块和功能都囿设置了权限。

在此我以结算系统设计方案作为例子进行复盘

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

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

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

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

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

数据权限采用的是管理账户由所有数据的权限，包括编辑、修改、添加不同角色的数据权限如图，这里也仅仅是讨论结算系统设计方案的结算流程 六、项目重难点分析做这个项目一共经历了４个月，刚开始接手这个结算业务嘚时候个人觉得并不是很难，初步以为只要解决好订单结算这个业务问题就行经过业务调研之后，发现业务现存的问题还是蛮棘手的同时要解决的业务需求很多。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二个问题的解决方法是，在订单管悝系统设计方案中加多一个文本字段【报价名称】【报价名称】命名规定是【项目名称＋日期】，这样就能使得每一个订单都是独一无②的商务在结算的时候通过报价名称来选择订单能确保不会错选。 2. 没提订单的项目怎么结算通过业务调研得知订单的提交规则是，所囿订单都会提交在订单管理系统设计方案但是项目类的订单可能还没来得及提交订单管理系统设计方案，这个项目就要先收一部分的钱这种情况的话，结算系统设计方案里也找不到这个订单无法进行项目结算。

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

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

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

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

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

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

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

成本模块如下图6-5。

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


• 薪酬等固定分配成本费用：需要设置一个薪酬等级录入表这个表将员工薪酬分为４个等级，避免详细薪资曝光财务填写这个数据，联动工时系统设计方案里的每个项目的工时某个活动的工资成本=全部人员投入相加，单个人员的某个项目活动工资成本=單个人某个项目活动工时/个人总工时*工资
  
• 代发奖品成本：在订单系统设计方案里增加这个奖品（不含税、不含手续费）的成本字段由商務在订单管理系统设计方案里提报价的时候填写
  
• 外透服务器成本：在订单系统设计方案里增加服务器的成本字段，由商务在订单管理系统設计方案里提报价的时候填写
  
• 委托开发设计费成本：自动联动外包系统设计方案的订单成本（外包系统设计方案有无须再添加）
  
• 推广成夲：在订单系统设计方案里增加投放／推广的每月实际投放／推广的字段
  
• 投放成本：在订单系统设计方案里增加投放／推广的每月实际投放／推广的字段
  
收入模块如图6-6所示。 表的一些字段的定义和操作：


• 实际工时：通过工时系统设计方案里可以得知每个项目当月的工时；
  
• 开發效率：人日开发效率=含税收入/（实际工时/8）；
  
• 含税收入：含税收入＝订单含税金额＊进度需要在订单管理系统设计方案增加一个项目進度的编辑页，每个月底由项目负责人去填写项目进度从而得知这个项目的当月进度；
  
• 不含税收入：不含税收入=含税收入/（1+增值税税率），增值税税率通过财务每月去客户数据录入页填写客户的增值税税率值来确定
  
收款情况：收款情况可以在订单管理系统设计方案里增添【流程状态】字段，通过结算系统设计方案的流程状态联动订单管理系统设计方案的每一个订单的收款情况

七、个人收获与总结 这是第┅次接触B端产品的设计以前也有过C端产品设计的经验，发现两者还是有很多不一样

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

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

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



• 对需求有了更深刻的认识需求优先级、假需求这些都有了深刻体会。做产品必谈需求但又有多尐人是真的懂需求呢，C端产品的需求可以用Kano模型B端产品在收集需求时应该问问自己这四个问题：这个需求背后真正的问题是什么？这个需求有快速解决的办法吗这个需求是个别需求吗，值得花多长时间去解决这个是共性需求，优先级如何面对需求的时候，多问问自巳这四个问题对需求才会洞察地更加深刻。
  
• 对B端产品的结算方向有了经验积累在这次产品设计中，也更加深刻地体会到业务的重要性对业务理解地越深刻，产品的设计才会更加高效
  
• 跨部门合作锻炼了我的沟通能力，因为结算业务需要跨系统设计方案、跨部门合作所以同公司的所有部门都有了接触，一番接触下来学会了如何同上级反馈问题、与研发交流、与产品运营部门、财务部、市场部进行访談。这对我来说是一次大的交际挑战持续的沟通也让我学会了如何更好地交流和获取业务需求。
  
• 项目管理能力的提升和学习这次的产品设计没有项目经理来安排项目进度，靠自己来规划项目所以也深刻de好的项目管理能保障项目按计划推进、落地，同时也能保障产品研發的效率和质量
  
• 虽然这次我只是接手了结算项目，负责了结算系统设计方案、发票系统设计方案、投入产出系统设计方案但将这些系統设计方案融入公司原有的架构中，我明白了一个好的企业应用架构对公司来说多么重要只有合理地将这些系统设计方案全部融合起来，企业的业务才能全部盘活起来
  

作者：苏Eddie，微信公众号：苏Eddies

本文由 @苏Eddie 原创发布于人人都是产品经理未经作者许可，禁止转载

游客，夲帖隐藏的内容需要积分高于 才可浏览您当前积分为 0