业务|实战分享——我是如何设计复杂系统的( 二 ) 数字化|similarweb|App|Annie|data|a

比如主管部门能够实时了解管辖范围内鉴定机构鉴定情况、鉴定人希望能够通过系统减少重复操作、收案登记员希望能够更快更好地完成归档认为等等。
且整个司法鉴定流程中所涉及的操作、文书附件不计其数。
但部分操作和文书在实际业务过程中使用到的次数较小，所以在最开始梳理业务流程的时候，我选择性的忽略。
其次由于在这个行业已经有类似竞品，我通过使用分析后，了解到他们更多地将系统聚焦在日常的鉴定过程中。
而近年来随着司法行业大整顿，各大司法机构需要进行重新评审，评审的内容主要是对鉴定文书等资料进行检查、考核，对平日里对文书不重视的机构，面对这样严格的评审往往会出现应接不暇的情况，可能会被停业整顿，甚至吊销执照。
所以我们在解决通用业务流程的基础上，将系统进一步聚焦在“文书评查”板块，也作为我们产品的一大亮点。
最后如果在业务聚焦时团队内部举棋不定，可以选择最简单的方式，选择优先聚焦在“买单用户”的需求上进行设计实现。
类似钉钉的“买单用户”是老板，实际使用用户是员工，老板最大的需求就是能够实时监督员工、管理员工，以更高效的方式完成工作，所以也才有了钉钉最开始的版本。
三、主线流程和角色梳理在B端业务中，完成一项任务问题需要执行很多操作，但并非所有的操作都是主线业务流程和关键节点。
我认为主线业务流程是完成任务的最短路径，最短路径中的操作就是关键节点，操作是由人完成的，所以关键节点上的人就是关键角色。
比如司法鉴定的主线流程和节点包括：
前期技术服务（预检）——>受理审批——>鉴定实施——>文书出具——>鉴定收尾。
其中涉及到的角色包括收案登记员、鉴定助理、司法鉴定、技术负责人，不同的业务流程由不同的角色参与并完成任务。

文章插图
我们以上我们通过”人+事“的方式，梳理主线流程和关键角色是为了大致了解不同角色职责与执行任务顺序，进而抽象出业务规则和流程。但这样的结果还是非常粗旷，不足以作为我们产品涉及的依据，我们需要进一步梳理。
四、业务流程细化一条主线业务往往会有很多分支任务，这些任务也是完成主线业务的必要条件，所以我们还需要进一步细化主线业务；其次每一次操作必定伴随着信息的输入和输出，所以我们还需搞清楚完成操作的前提条件和产出数据；最后在主线业务流程外，还有很多异常流程也需要我们注意。

文章插图
比如上图是对审查受理阶段进行了细化，在流程上审查受理又需要分为”收案登记“、”初始审核“、”审批受理“、”办理手续“四个步骤，同时可以看到我在表格中添加了另外三列，包括输出文书、必要程度以及备注。上一个操作的输入作为下一个操作的输入，每个步骤的逻辑顺序是不可改变的；”必要“操作是主线业务的进一步细化，”可能“操作”是异常情况的标注。备注里是一些补充说明。
以这样的方式我们就把复杂的业务通过“时间顺序”对应”事“，”事“对应”人“，”人“对应”操作“、”操作“对应”输出“的逻辑梳理出来，这样能够更加清晰把握业务脉络。
五、产品功能架构设计产品功能架构是对业务流程和操作的抽象成功能板块，主线业务梳理（总）——>业务流程及角色细化（分）——>产品功能框架设计（总），我们距离产品原型设计，就只差一步了。
其实在前面的流程梳理过程中，根据”人+事+逻辑顺序“的方式产品框架已经显露出来了，再加上一个完整业务系统的常见功能就组成了我们的产品框架。

文章插图
六、结语业务是单纯的，其本质就是为解决问题，但人往往是复杂的，在不了解事情本质的情况下容易将简单问题复杂化。
产品经理是否厉害不在于把系统设计得多么复杂、多么高大上，而在于能够以最简单的方式解决用户需求。
大道至简，繁在人心。
本文由@蹦蹦怪原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pexels，基于CC0协议。