SaaS ToB产品的易用性设计2

SaaS ToB产品的易用性设计1

一、关于模块的划分以及权限的管理

模块的区分要干净清晰，一般模块的划分可以分为业务模块，系统管理模块，报表中心模块等。

业务模块一般要根据要管理的对象来进行模块的区分，以典型ERP基干系统为例。

几个主要的业务对象有客户、商品、订单、库存等，那么模块区分的时候也按照这种业务对象来划分，一个主业务对象一个模块。比如说人事管理的对象有人事信息、休假、考勤、薪资、福利、培训、绩效、招聘，那么按照这个原则来区分大的模块。

系统管理模块里面一般就是全局参数管理，系统数据字典，角色，用户管理等功能的管理。所有参数以及数据字典的管理尽量在系统里面都放在统一的地方，按照业务模块或者功能类别方式区分好（产品的本质是分类，好的产品都是分类做的很好的产品）。

权限模块的管理主要是二个维度的权限管理，基本上可以解决所有企业信息管理系统的权限问题。一个维度就是功能级权限，一个就是数据级别权限。

一般来说在角色上面设置功能级别权限，在用户身上设置数据级别权限，然后每个用户可以对应多个角色。

基本上这样二个维度就确定了每个用户的对应角色确定了可以访问哪些功能，用户的数据级别权限确定了访问这个功能的时候可以访问哪些数据。

别看这样基础的内容，我看到很多公司在设计权限的时候犯错，导致后面很多麻烦，主要有如下几个错误：

（1）数据级别权限设置在角色身上，导致同一角色的多个用户有不同数据级别权限的时候，要设置很多个角色来管理，非常麻烦。

（2）功能级别以及数据级别权限设置得太细，设置复杂，一般来说功能级别权限如果到菜单级别够的，就不要到页面级别。数据级别权限到数据行级够的，就不要设置到数据增删改的权限。

（3）一个用户只可以对应一个角色，在业务权限比较复杂的情况，如果一个用户只可以对应一个角色，也会导致最后需要设置很多角色。如果一个用户可以对应多个角色，这样只需要设置比较少的角色来进行组合就可以满足很多种功能级别权限控制了。

二、关于功能的设计原则

每个功能模块又有很多的功能，其实主要可以分为业务规则设置，输入，处理，输出（查询）三部分。

拿休假管理来说，业务规则设置就是各种假种。比如说年假。事假的获取以及扣取等规则的设置，输入就是休假加班的申请，处理就是假期天数以及休假结余的计算，输出就是休假历史记录以及休假剩余天数的查询。基本上所有模块都脱离不了规则设置，输入，处理，输出等几部分功能。

在进行功能设计的时候，要做到系统的极致易用要把握如下的原则：

01

功能的设计要采用去中心化的分布式，原来很多系统的设计都是中心化的设计，所谓中心化的设计就是将系统的使用控制在少数人手上。

比如说核心业务部门的人员来处理，这样导致的结果是核心业务部门的人输入输出工作特别繁重，体现在：

大量的数据输入以及导入工作，而且这样的数据输入还有导入都是来自一线部门的二手数据，错误很多，纠正错误以及确认的成本很高。
很多数据统计或者数据查询的功能，都是业务部门的人员承担，然后提供服务给到高管以及其他部门的人员。

在现在移动端的使用极其普及的情况，另外普通大众对移动软件的掌握程度，已经完全有条件采用去分布式的功能设计方式，将输入输出相关功能开放给相关工种的人来操作，从而大大提升效率，以及降低核心业务部门对复杂系统的掌握要求。

02

系统处理的地方尽量自动化或者智能化。其实如果数据输入的部分可以分布式来处理，比如说让机器来操作后端运算的部分，可以用如下的几种方式来进行处理：

通过一定的规则进行自动化处理，通过时间，状态或者一些组合规则来设置。
通过语音的控制自动唤醒执行任务
在移动端可以方便操作功能。

三、一个功能已经相对完善的系统，面对一个新需求，我们该怎样处理？

一般面对新需求，我们一共有四个选项可以来处理:

做为可配置性比较差的标准功能开发
做为可配置性极强的标准功能开发
自定义开发
拒绝

笔者觉得选择的原则和优先顺序大致如下：

1. 尽量拒绝，利用原有的产品功能来提供线上或者线上辅助线下的解决方案，很多需求不一定适合完全放在线上来处理的。

2. 如果是可以放在系统里面做为配置性较差的标准功能，或者在原有逻辑上面增加逻辑分支可以解决的，而且能够这个功能利于其他客户的，给合适的钱可以开发。

3. 如果不能放在系统里面做为配置性较差的标准功能，需要配置极其灵活的功能，才能利于其他客户的，等待多个客户需求积累之后才能够给予开发。

4.如果不能作为标准功能，需要客户化开发的需求，建议尽量拒绝，如果客户要用钱把你砸死，那尽量做一个比较独立的外挂功能，不要影响正常版本的升级。

提供客户解决方案的能力是售前最重要的能力，笔者的经验是绝大多数的需求都可以已有系统变通的功能来实现，不需要重新做开发。只是大多数售前或者产品没有能力挡住这些需求，做了大量客户化的需求，而不是通过变通方式或者做成标准功能，导致了系统越来越复杂。

四、功能的设计的灵活程度究竟要做到什么程度？

笔者的建议估计有很多人骂，个人意见是除了立志要做PaaS平台的公司以外，不要将系统做到无限灵活，将灵活配置的程度控制在最小的范围（灵活度越高，意味着功能让所有用户都不贴身，牺牲了易用性，另外系统实施和培训工作量变大）。

从长期来说，不同规模的客户需要不同的产品线来支持，不要想一条产品线支持大中小规模客户，要有所取舍，最后把目标客户服务到极致的产品会胜出。

那么哪些做成灵活度低的标准功能？哪些做成灵活度高的标准功能呢？这个需要产品经理对行业业务非常了解，可以参考的一些原则如下：

1. 一些关键的对象的属性字段因为不同客户各种情况确实太多样，需要留可以灵活配置的空间。比如说人事管理的员工信息字段，比如说客户管理的客户信息字段，但是可以固定下来的标准字段要固定下来。

2. 因为关键对象的字段不同客户会不一样，导致对应的输入，输出（主要是导入还有报表部分）需要进行对应灵活的支持。

3. 后端逻辑的部分，不同客户有不同分支的基本上可以通过参数设置来进行解决。但是如果参数也很难抽象出来的情况，可以考虑支持公式的配置，比如说薪资计算的薪资字段，以及年假天数获得的逻辑。

（即使这种不得不支持公式配置的情况，可以标准下来的字段也要尽量标准化内置，减少实施和培训的工作量）