近期完成审批系统的大升级，这期间改变了很多对业务系统的思路，故，整理之以分享和自我总结。
之前做过很多竞品分析，得到的结论大都是：系统功能都差不多，只是细节做得更细致。但其实不然，重要的是思路和意识。
业务系统，本质就是办事，还原原有线下流程，起到提质增效的作用。主要分成两条线：业务事项和数据流转。
审批系统整体业务框架
一、业务事项
业务事项，就是理清办理的业务是什么，需要办理什么，由谁办理，流程怎么样。可用5W2H进行分析：
What：做什么，目的是什么。大的层面是了解办理的事项是什么，比如进行不动产登记等，逐步细化就是具体每个节点的表单（如填写申请表等）、操作是什么。
Who：由谁来做，事项讲究一个职责分明。就是涉及部门、人员、角色、权限等。
Where：在什么场景下办理，是在办事大厅接件，还是在办公室中进行业务审批；在哪些页面办理，待办列表需要展示哪些内容等。
When：办理时限的要求是怎么样的。在各种内卷下，各地方提出了签约即拿证等，体现到业务和系统层面，就是每个流程节点的时限是多少天。
Why：为什么，就是办理规则是怎么样的，比如说涉及矿业覆盖，需要提供（上传）采矿权主体单位的同意协议等。
How：怎么做，即办理流程是怎么样的，有什么规则和要求；再细化就是每个流程的向导，告诉用户需要做什么（填写哪些表单、上传哪些材料等）。
How much：最后一个，可以扩展为系统的质量、报价等。
二、数据流转
除了理解业务，另一个就是关于数据流转，业务办理、监测监管过程中需要用到哪些数据，这些数据怎么产生，其中包括业务数据以及空间数据，同时还需要理清二者如何关联。
比如针对市政类项目、建筑类项目，所办理的流程、表单相同，附件材料不同，则在项目基本信息中记录项目类型，用于匹配对应的附件材料目录；业务办理过程中，实例id作为事项的唯一标识，空间图层入库时也需要记录对应的实例id，用于关联业务与对应的范围红线；申请表、呈报表中字段重合度高，字段之间关联度高，则可考虑用同一个实体表存储数据。
同时，作为政务系统，还需要考虑操作留痕，用于后续溯源、追责。
综上
1.在功能层面
功能模块可分为（1）架构用户管理；（2）子系统菜单配置；（3）实体表及表单设计；（4）审批方案配置，包括流程、权限、规则、时限、空间图层入库等配置等四大核心配置，最终展示在应用端，交由用户进行业务办理、数据查询统计以及项目全息查看等。
2.在业务层面
业务分析过程中，需要获取业务办理的部门清单、用户清单，梳理业务流程、表单、附件目录，分析角色权限等。
3.在操作层面
业务配置流程可分为：
1.配置组织架构、用户及角色
2.创建实体表（数据库中的数据表）
3.创建表单，选择实体表（数据源）
4.复制已有表单的样式
5.调整字段、样式，生成元数据
6.配置数据源（常规的sql-字典等）
7.创建业务审批方案
8.选择向导类型（即创建案件时，需要做什么操作，如先“关联项目”等）
9.选择审批流程，可选流程版本（版本可预览）
10.选择表单（设置启动表单）
11.配置附件
12.配置权限
13.应用端测试效果，调试，在调试过程中，系统提供完善的报错提示，以满足于实施人员进行配置校验。
作为强大的审批系统，灵活配置是必须的，但个性化需求是不可避免的，为保证产品版本的平滑升级，则可通过指定路径用于个性化扩展，不影响主版本的核心代码。
再强大一点，支持数据、业务的横向对接，通过接口或RPA机器人的方式，进行自动化数据推送及接收，横向打通。
最终发现，这其实是一个为自然资源业务量身定做的低代码平台。
【一个小目标】75/365，关注行业关注趋势，多看多想多反思，做一个讲故事的人，讲一个好故事
网友评论