业财税一体化是一种将业务流程、财务会计与税务申报紧密结合的管理模式。通过高度的信息系统整合，实现数据共享和流程优化，从而提升企业的效率和合规性。本文将从业务的角度出发，让您认清整体系统的本质，以实际的业务诉求切入，一步步的构建出一套完整的B端系统框架。
回顾上篇文章，我们讲解了如何搭建系统总架构，如下图：
所以在本篇及之后的文章将继续为大家讲解系统里具体功能模块该如何设计。
按照目标用户（暂以代账行业企业为目标用户）使用系统的顺序来看，创建人员账号和授予权限是所有操作的初始步骤，所以本次要设计的是《基础服务层》的【用户管理】和【权限管理】
业务模块从无到有的设计过程中，产品经理是有一套标准范式可以遵循的：
1）业务调研：
2）初步方案：
1）产品功能定位：
2）产品演进蓝图：
3）梳理业务流程：
4）提炼数据模型：
1）设计页面原型：
2）设计具体功能点：
3）梳理各产品/模块关联关系
4）输出原型、UML图、PRD文档等
研发发布和运营维护属于产品设计完成后的流程，因本篇主要讲解设计环节，所以这两个流程暂不做赘述。
不仅是业财税系统，任何系统的最初设计大都是从【用户】与【权限】开始，毕竟没有创建用户账号和密码，用户如何登录系统呢？
接下来，让我们按照上述流程来设计这两个模块，首先是调研阶段，早在设计系统整体架构前，就应该对目标客户进行充分调研，此处可先略过调研阶段，假设已调研完成，需要进行整体方案设计。
以虚构企业“北京小橙子代账公司”为案例。背景如下：
1）产品功能定位
根据整体调研结论，总结出以下功能定位
产品经理应优先聚焦核心业务流程，将其作为主要诉求，而将扩展功能和小众需求列为次级诉求，以此与业务部门保持一致，确保从高到低实现核心流程。
2）产品演进蓝图
用户与权限模块并不复杂，无需分期研发，此步骤可忽略
3）梳理业务流程
根据调研结果和产品功能定位，梳理出以下几个业务流程
（1）系统管理员创建各部门负责人的账号并分配角色权限，再由各部门负责人给本部门员工创建账号，并分配角色权限。
（2）部门员工离职，需先进行工作交接，把自己负责的客户转交给其他员工，才可提交离职申请，由部门负责人审批后进行离职，并注销账号。
若员工无负责的客户，则可以直接进行离职，略过工作交接的步骤。
这里给大家留2个小问题，欢迎大家评论区留言：
（3）部门员工调岗，由部门负责人变更部门或岗位，若被调岗人需要工作交接，则先进行工作交接，交接完成后进行变更。若被调岗人无需工作交接，可直接变更。
根据上述3个业务流程，可以分析得出
权限：
业务承载页面：
4）提炼数据模型
实体建模是信息系统设计中的关键步骤，它涉及将现实世界中的实体及其相互关系转换为抽象的模型，以便在计算机系统中表示和处理。一个清晰且合理的实体模型为后续的功能设计和用户界面设计提供了坚实的基础。如果实体建模有问题，可能会导致后续业务和系统无法扩展或失去灵活性。因此，在进行实体建模时，我们需要仔细考虑各种因素，并确保模型能够准确地反映现实世界中的对象和关系。
以下是实体建模的设计思路，我们将通过案例来详细说明：
（1）建立客户模型
首先，和业务方（小橙子公司）沟通确认，一期暂不支持复杂的行政层级管理，只需要给业务部门实现若干子账号可以管理企业内部客户即可。这里可以识别出是典型的树形组织机构管理诉求：
我们先将业务部门、员工、客户的关系以组织机构树的形式来表示。
将“员工”转变为“用户”的概念，接着梳理用户、角色、权限的关系，在此使用RBAC权限模型 ，RBAC权限模型是功能权限设计的经典方法论，描述了一套用户、角色、权限组的设计理念，该理论具体的讲解，读者可在网络上自行查阅
（2）划分数据领域
按照用户、角色、部门三个维度划分各个业务域，每个业务域按照业务过程梳理业务数据。
A. 用户（员工）
B. 角色权限
C. 部门
（3）实体建模ER图
通过客户模型和数据领域划分，我们梳理出了需要用到的业务数据，接下来可以通过实体建模ER图，描述出这几类业务数据的关系，这有助于后期原型绘制时的业务流转和设计限制规则。
例如“一个部门可以绑定多个员工，但一个员工不可绑定多个部门”，在这个1对N的关系下，系统界面设计就需要增加限制，在为员工选部门时，不支持多部门的选择；在部门内创建人员时，不可选择其他部门的人员。
实体建模中权限可分为【菜单资源资源】和【数据资源权限】
到这一步，整体方案设计已经完成，可以在此基础上，进行细节方案设计。
1）设计页面原型
（1）绘制原型时的注意事项
原型设计需建立自己独特的规范，原型规范化的主要优势在于提升信息传递的效率。人类天生被视觉所吸引，美观的设计往往容易吸引人们的注意力，而混乱的设计则直接令人感觉到逻辑不清。
在系统搭建初期，产品经理可以预设一套完整的界面样式规则，包括弹窗样式、列表样式、标签元素、页面布局、提示语样式等，按照这些规则作为通用模板。
不过，原型设计与ui设计不同，我们无需过分关注到每个像素的细节。设置原型规则是为了我们有个绘图标准，更快速的传递信息。若花费心思钻研每个按钮的摆放位置，每个元素的排版，每种颜色的搭配，岂不是本末倒置！
（2）原型规范
建议绘制时只以黑、白、灰三种颜色进行绘制，如此可不用在配色上做过多纠结。在此分享几个本人常用的原型规范。
①二次确认弹窗
②批量修改弹窗
③导入失败页面
④任务执行结果弹窗
⑤当页面按钮超过3个时，组合按钮
2）设计具体功能点
按照前期的整体方案设计，我们结合产品功能定位、业务流程和实体建模ER图，便可以设计每个信息承载页面的功能按钮和交互。
以《角色总览》列表区域为例：
同时还需要增加数据权限：
3）梳理各模块关联关系
目前系统暂无其他模块，此步骤可先忽略
4）输出各类文档和图示
结合前面方案设计过程中绘制的各类图示，再加上对每个功能点的详细说明，就可以产出PRD文档，当业务规则复杂时，可以在文档中适当列举案例，便于开发人员和测试人员的需求理解。
另外PRD文档的目录需要层级划分清晰，至少包含以下几点：
此外，在具体实践中，产品经理需要根据实际的产品类型和组织习惯来适配或调整PRD的内容和结构。无论何种形式，都要确保PRD能够明确地描述产品的功能需求，以便于团队成员理解和执行。
本文由 @尺素 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。