项目投入及产出总结 第1篇

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

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

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

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

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

（1）结算系统

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

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

项目投入及产出总结 第2篇

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

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

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

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

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

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

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

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

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

项目投入及产出总结 第3篇

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

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

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

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

题图来自Unsplash，基于CC0协议。

项目投入及产出总结 第4篇

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

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

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

（1）关键业务问题梳理

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

（2）问题解决思路