本文的目的主要是反思系统底层功能的建设到底要不要做，以及该怎么样做。
一个完整系统的功能层级大致可以分为3层：
- 最底层的功能是系统设置层，相当于整个系统的基石，因为整个系统都离不开底层信息的支撑；
- 中间层的功能是用户操作层，日常业务流程就是在这一层进行操作；
- 最顶层是数据层，提供一些业务数据报表，跟业务流程不挂钩，不用用户操作；
一个B端系统从0开始规划的时候，很多产品经理会优先做一些亮点功能用来招商吸引客户，这些亮点功能一般都是在用户操作层，由于更加贴近客户的日常业务流程，宣传的时候介绍这些功能，客户也容易理解。
而底层的系统设置，一般都属于基础型通用功能，偏向于信息的维护和配置，跟业务流程没有太大的关联，因此大部分产品经理会忽略系统的底层规划，或者只是做一些简单的规划，这些都相当于是变相的在挖坑。
最近一年接手的2个系统，在系统底层功能规划上都存在非常严重的问题。最后都追悔莫及开始完善，结果发现改起来真是比重新做一遍还要困难。
第一个系统组织架构设计不合理，必须要新增3级组织，且每一级节点有固定的组织类型；角色权限配置写在代码里，修改删除都要改代码等等；没有任何操作记录留痕；
第二个系统一是没有组织架构的概念，二是没有角色权限的区分，三是没有审批流的功能，四是没有操作记录的信息；系统的功能都堆积在中间操作层和数据层；
底层能力薄弱的系统，一开始用的时候可能不会觉得有太大问题，因为至少业务功能是全的，流程能跑通；但是到后期，随着客户的深入使用，就会发现系统的管理能力跟不上，从而管理需求就要开始提高优先级。
这个时候用户已经在系统上产生了大量数据，我们再去考虑完善修改底层功能，实际上是非常困难的，工作量简直会增加好几倍。因为底层功能的影响范围是非常广的，有的时候甚至会改变业务流程。
在这里我要大声地说出我的呼声：
一定要重视系统的底层功能设计！底层功能虽然跟业务关联不深，但是它却是会影响整个系统的功能！因此不但要重视！还要好好想清楚该怎么做！否则：简化一时爽，优化悔断肠。
下面讲讲我对系统的底层功能上的总结。
系统的底层功能建设主要包括以下5个方面：组织架构、权限、审批流、操作记录、消息通知；
一、组织架构
组织架构一般是用来管理系统里面的“用户信息”数据的，常见的组织架构分类方式主要是按部门分类；
组织架构的设计：
组织架构的设计一般是采用“树状结构”，包括父节点和子节点，节点下挂数据。
关键点：
- 组织架构的层级限制：固定层级/不限层级；
- 是否允许多个根节点存在；
- 父子节点下挂数据的方式，参见例1；
例1
节点下挂数据的方式有2种：
一是父、子节点下均可以添加数据，如图1；
图1.父节点下可以添加数据
二是父节点下不可以添加数据，仅最末级子节点可以添加数据，如图2；
图2.父节点下不可以添加数据
相对而言，方式一更加符合大部分大公司的管理习惯，组织层级比较多，确定组织层级的同时也确定了用户的层级，高层级用户是低层级用户的上级，但是最末层级中若有上下级关系是不好区分的；
同时方式一存在一个问题：选中父节点的时候是仅选中父节点下的数据呢？还是选中父节点下的数据以及其子节点下的数据？
- 如果是仅选中父节点下的数据，那要是想选中所有子节点的数据，就得一个一个手动选中节点；
- 如果是选中父节点下的数据以及其子节点下的数据？那要是想仅选中父节点下的数据，就得一个一个手动选中需要选中的数据；
方式二适用于一些比较扁平的小公司，比如一个公司就只有一个一级部门，那就直接把每个部门的人拉到该部门就好了，用户的上下级关系不在组织架构上进行体现，可以另外引入字段进行区分。
组织架构的优点
1.对“用户信息”根据某个维度进行分类，方便查找和批量处理用户数据。比如当系统其它地方需要用到选择“用户”时，不至于直接出现无分类的“用户信息”列表，一个一个查找选中需要的用户，如果“用户信息”上万，这就..不仅会导致系统性能问题，还会造成严重的用户体验问题。
2.方便一些需要根据组织架构进行隔离的功能。
此外，比较智能化的系统一般也会提供API接口供用户直接对接到其公司内部的EHR系统，避免用户重复维护员工数据；
组织架构影响的范围：
- 数据权限根据组织架构做隔离；
- 报表按组织架构进行汇总统计；
- 审核流程根据组织架构做隔离；
- 只要用到“用户信息”的地方基本都会跟组织架构有需求；
二、权限
对一个功能完善的B端系统来说权限分级是必不可少的，权限控制着能进入系统的每个账号所能查看和操作的范围。
权限分为功能权限和数据权限，功能权限控制用户能不能看到这个功能或信息，数据权限控制用户能看到的数据信息的范围。
如果不做权限控制，所有只要能进入系统的用户都能查看和操作所有的数据，其实是有很大的信息泄露风险的；其次一个系统既然有业务流程，就必然会存在操作流程节点的对应用户，如果说所有用户都能操作所有流程节点，那其实设置1个节点就够了，反正一个用户操作都能操作所有节点；所以流程上的不同节点需要有对应的用户来操作流转，这个时候也需要控制用户的查看和操作权限。
如果系统一开始没有设计权限控制功能，后面在优化的时候就需要对整个系统进行权限节点梳理和权限校验，测试的时候也是需要整个系统全局测，这工作量…
权限的设计
①功能权限的设计方式比较多：
- 最常用的设计方式是RBAC，是一种“用户-角色-权限节点”的功能权限设计，之前写过，不再赘述；
- 还有一种比较简单的功能权限设计方式是“用户-权限节点”，即对用户直接分配权限节点，这种方式适用于一些功能比较少的小型系统以及用户量很少的系统，直接对用户分配权限即可，如果用户量较大 ，就慎用此种设计方式。
②数据权限一般会通过组织架构做隔离，比如给某个角色 A分配了一个数据列表的功能权限：
- 若数据权限控制角色A只能查看“本人” 的数据，那拥有角色A的用户就只能看到他本人的数据信息；
- 若数据权限控制角色A只能查看“本部门” 的数据，那拥有角色A的用户就只能看到他所在部门的数据信息；
- 若数据权限控制角色A能查看“全公司” 的数据，那拥有角色A的用户就只能看到他所在公司的全部数据信息；
关键点：
- 功能权限节点细化颗粒度的确认：如页面，有些特殊的按钮也需要单独配置权限；
- 数据权限范围的确认：如个人、本部门、全公司；
- 功能权限节点的梳理，举个栗子如图3；
图3 精斗云系统角色权限配置
权限的优点
- 细化控制每个用户的数据查看范围，防止信息泄露；
- 每个人都只能操作自己权限内的功能，防止误操作，即操作到本不该自己操作的功能；
- 便于管理，各司其职；
权限功能影响的范围
- 全部页面以及一些操作按钮都需要单独做功能权限节点；
- 针对数据列表页面，如果需要限制用户查看数据的范围则需要梳理数据权限；
三、审批流
审批功能在OA系统中使用的比较多，其他系统根据业务需求而定，但是审批功能依然是一个非常高频的操作，比如涉及到一些数据的新增、修改、删除、生效等等都会存在审批；如果系统在一开始没有规划审批功能，后面想再插入审批流程，可能整个流程都会受到影响。
审批流的设计
包含的要素有：审批流程、审批类型、审批角色、审批人；
关键点：
- 审批方式：串行审批（如图4）、并行审批（如图5）
- 审批流程一定要闭环；
- 审批人的确定：按角色、按人；注意区分是否按组织做隔离；
- 特殊条件校验：审批流程中可能会涉及到不能按不同条件分不同的审批路径，比如费用报销流程，费用金额小于等于10万，仅需要财务助理审批，若费用金额大于10万，则需要财务总监审批；
- 加签：加签是在当前审批人审批之前加另外的审批人，还是当前审批人之后加另外的审批人；
- 抄送：选择抄送用户的范围是不限还是只能选择某个固定群体中的人；
- 转签：选择转签用户的范围是不限还是只能选择某个固定群体中的人；
- 驳回：审批节点被驳回是整个流程终止还是返回到某一节点重新开始；
- 如果当前审批人离职了怎么办？
图4.串行审批
图5.并行审批
审批流的优点
- 能限制用户的权限；
- 通知、知会所有相关人员；
- 减小误操作的影响；
审批流影响的范围
1.系统中涉及到关键数据的新增、修改、删除等功能；
四、操作记录
操作记录的设计
操作记录这个功能很多产品经理都不重视，在规划产品的时候也不会考虑，可是到需要用到这些信息的时候只能让开发查数据库，如果数据库数据存储不完整就…没办法了。
如果系统一开始没有规划操作记录的模块，之后在优化的时候对于历史操作记录数据很难处理，而且整个系统统一梳理操作记录，这工作量也不是一般的大…
关键点：
操作类型、操作时间、操作人、操作内容、变更前、变更后
操作记录的优点
- 便于追溯信息的变更记录；
- 便于对每个用户的操作进行跟踪；
- 便于产生问题后查找原因；
操作记录影响的范围
整个个系统涉及到有操作按钮的页面都可以有操作记录；
五、消息通知
消息通知主要是针对系统中一些重要的信息需要及时通知到用户。
消息通知的设计
在规划消息通知功能的时候一定要先统一消息模板，其次定义清楚什么消息需要发，该用哪种形式发，万不可所有信息都发，也不能一条消息全部途径都发送。不然消息过多的话，会对用户造成信息骚扰，其次也会把重要消息淹没掉。
关键点：
- 消息通知的方式：短信、邮件、app
- 模板设计：比如要不要加签名、logo等
- 邮件内容：主题+详情+附件+签名
- 短信内容：【主题】+详情+【发送方】
消息通知的优点
- 对一些重要信息及时传达给用户；
- 主动向用户推送信息；
消息通知影响的范围
对现有功能逻辑影响不大，主要是影响用户体验。
