pm|产品领域的元宇宙：aPaaS产品解构( 三 )

文章插图
这种设计当数据需要存储到data中时，data需要知晓每个字段是什么样的object，也就是业务系统需要依赖于“元数据引擎”。反过来，在业务系统在使用业务数据查询data时，也需要“元数据引擎”做好column+含义的处理。
3. 业务规则的实现方法有了数据实体，还需要有大量的业务规则。举个例子，拿线索实体来说：

电销业务可能认为“手机号”是个必填字段，否则无法联系客户
其它业务可能认为“手机号”和“微信号”有其一即可

这两种规则在SaaS模式下，都是用硬编码的模式写在应用程序中的，一旦调整，需要研发去改逻辑、验证、上线，在规则频繁变动的情况下，非常棘手。所以，如果这些规则也能做到配置化，会减少很多变动成本。要抽象并配置这些业务规则，至少需要3种引擎：
1）规则引擎
类似上面提到的，字段校验、过滤、表单引用联动等，如果可选、必填；字段长度、格式；是否引用关联这些都可配置，大量的基础硬编码工作将被aPaaS取代，研发工程师可以一劳永逸。
2）流程引擎
处理静态规则之外的，当系统发生交互后的流程处理，包括各类触发和执行、通知反馈。比如当用户拨打电话后，记录一次跟进，同时给TA的主管推送一条消息。这样的流程其实抽象出来后，就是“触发”“编排”和“执行”“反馈”，是可以像画流程图一样配置出来的。
3）权限引擎
SaaS理解为独立单个系统，往往有角色控制即可满足，而aPaaS可以理解为跨系统复杂模型，不但要管控系统内的功能、应用，还得对meta层、读写权限进行管控。
比如当A工程师是“线索”实体owner时，一旦“线索”实体增加了一个不可操作的字段，也许是一个全新的、不被之前权限定义的字段，这时就需要对这个对象记录的权限进行管控，此时就需要引入对象、记录等权限，只靠角色和数据表的权限，就不够用了。综上，通过对规则、流程、权限进行配置化处理，能够让软件的主干业务逻辑部分支持配置化，是aPaaS的核心能力之一。
三、aPaaS设计干货实例-权限设计上面讲了很多原理、方法、总结。这部分想用一个实例来让文章更直观完整。我想用“权限”这个模块来作为实例。权限模块，在传统SaaS中，其实并不算复杂。一般一个产品经理半个人力就能cover住，只需要注意用户A是否能用某系统，是否能查看某些数据、是否有编辑等功能权限即可。但在aPaaS中，如上所说，已经不仅仅是一个SaaS的权限问题，而是多个错综复杂的SaaS权限问题。
关键在于比SaaS来说，aPaaS核心的两大能力：低代码灵活配置和打破数据孤岛，这决定了从产品上来说，一定会存在大量的元数据定义和大量的租户，这样一来，权限系统就会成倍复杂。但无需担心，可以直接用类比SaaS的方式进行产品设计。
从数据实体来说，因为引入了object，就需要对这个维度进行权限管控。object意味着某些字段对于用户来说是否可用，这往往是根据角色来决定的。比如行政可以看到每把椅子的采购价格和实付价格，而普通员工却不关心也不应该看到“椅子采购系统”。
data层面，也要有记录维度的管控。比如对于薪酬hr来说，应该可以看到员工的薪资，而普通员工只能看到自己的薪酬，其区别不在于“薪酬”这个字段，而在于“别人的”“自己的”，所以并不是object层面的管控，而是data的record层面管控。
如上，object其实决定了领域，一个领域应该有一个对应的profile，比如采购人员应该负责采购相关系统，所以需要一个采购profile。如果采购人员同时兼任HR，那么也应该具有HR的profile。profile背后，是对一些实体、对象甚至系统的权限，可以和业务、事业领域做类似的映射。