SaaS系统能提供一个或者多个行业常见场景的功能支持，只要在有网络的情况下，便“随处可用、拿来即用、不用下载”，所以现在也是一个流行的趋势。本文介绍了SaaS系统的框架搭建，一起来学习一下吧。
根据百度百科的解释：“SaaS，是Software-as-a-Service的缩写名称，意思为软件即服务，SaaS平台供应商将应用软件统一部署在自己的服务器上，客户可以根据工作实际需求，向厂商订购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得SaaS平台供应商提供的服务”。
SaaS系统能提供一个或者多个行业常见场景的功能支持，并且只要在有网络的前提下具有“随处可用、拿来即用、不用下载”的特点。
对于SaaS服务商来说，边际成本随着客户的增多大幅度降低；对于客户来说，能在业务开展前期先小成本试用，降低软件综合成本，可以更聚焦于业务本身的开展；对于用户来说，可以拿来即用，并且SaaS系统的常规设计符合相对应领域用户的心智模型，使用起来非常方便。
所以现在SaaS系统的流行已然是一种趋势。接下来为大家详细介绍一下SaaS系统的框架搭建，也就是SaaS异于其他常规B端平台的地方—权限的配置以及数据的隔离要更为复杂一些。
菜单管理主要是为了管理后台系统菜单的展示、排序、以及跳转，开发人员每次做好新的的功能时，可以直接从这里配置到后台，不需要通过在数据库插数据，或者走开发、发布、上线的流程。
参照原型如下：
站点管理主要是为了不同机构的名牌化宣传，专门为机构配置专属域名&名字&logo等。多个机构也可以用同一个域名。不管是否使用不同的域名，不同机构的用户数据都会做数据隔离。
大概涉及到的字段如下：
不同机构需要做的个性化配置维度以及配置涉及到的参数都比较多。例如上面提到的“支付相关配置”，不同租户的收款商户肯定不同的，所以要对微信开放平台、微信公众平台、微信商户号、支付宝商户号等进行配置。不同配置维度的具体配置我们后续专门写文章进行详解。
SaaS系统通过组织来实现多租户管理，为租户配置管理员以及系统的功能权限等，除此之外还可以根据实际需求为租户设置可以管理的其他组织以及组织下内容，对于会提供内容服务的SaaS服务商，需要对应设计跨组织共享内容的功能。接下来要给大家分享的SaaS框架支持跨组织管理数据以及跨组织共享内容。
参照原型如下：
①管理员默认有该组织的最高功能权限；
②管理员默认有管理组织的全部数据权限；
③SaaS服务商（原型中的A机构）默认有一个总的管理员账号，拥有整个系统最高的数据以及功能权限；
④操作者可以对自己管理的其他组织进行所有的信息变更，但是对于自己所在的组织只有【重置密码】的操作；
⑤组织中的管理员账号只在组织模块中出现，不会在账号管理模块中出现；
①系统到了有效期之后，如果机构不续约一般数据还会保留1~3年；
②超过有效期之后前端用户一般无法登录；
③超过有效期之后后台用户设置为只能查看部分数据，无法操作。如果数据被清空之后也无法登录了；
①门户网站的功能模块配置；
②不配置的模块在前端看不到或者点击提示无权限；
③选项为操作者所在组织有权限的前台模块；
①配置该组织拥有的后台功能权限；
②默认授权给组织管理员功能权限；
③选项为操作者拥有的功能权限，操作者按需选择；
①分配该组织可以管理的组织以及每个组织对应的模块内容（课程包&资讯&角色&账号等）；
②默认分配给管理员；
③可查看选项：操作者有权限的组织以及组织下所有的内容模块；
④可操作选项：操作者有权限的组织以及组织下有权限的内容模块；
原型如下：
①共享给被操作组织具体的内容，同步共享给管理员一份；
②无法共享给自己所在的组织，同组织共享通过账号进行共享，后续在账号管理中会讲到；
③跨组织共享是一种复制性的共享，同一个ID的内容可以多次共享，每次共享生成一个新的内容（产生新的ID）；
④选项为操作者有权限的内容，如果操作者其中一个内容来源为被操作的组织，那么该内容仍旧可以被分享，因为该内容和原内容目前已经是两个产品，如果业务实际场景需要做限制也ok；
原型如下：
⑤可以查看的内容是【被操作组织所有被共享的内容】和 【操作者有权限内容】（来源ID）的 交集。同一个内容不管详情是否发生了更改，重复分享会生成新的ID，并对应一条新的共享记录。
原型如下：
角色是权限的集合，作为桥梁的作用把权限赋予给后台账号。操作者可以看到的角色分为两种：一种是操作者所拥有的开通了角色模块权限的管理组织下的角色，另外一种是操作者所在组织下的权限小于等于操作者权限的角色。操作者可以通过【组织下拉列表】进行不同组织角色的查看。
具体涉及到的字段如下：
根据实际场景的需要给后台账号配置数据和功能权限，操作者可以看到的账号分为两种：
一种是操作者所拥有的开通了账号模块权限的管理组织下（不包含自己所在的组织）的后台账号；
另外一种是操作者所拥有的自己所在组织下自己所在层级结构下的后台账号（同一层级的无法看到，例如部门A的经理无法看到自己以及部门B经理的账号）。
参考原型如下：
①如果操作者和被操作者是不同的组织，那么选项为被操作者所属组织下的所有角色；
②如果操作者和被操作者是同一个组织，那么选项为权限小于等于操作者权限的角色；
③支持多选；
①展示的选项为被操作者所在组织有权限的组织以及每个组织有权限的模块内容（课程包&资讯&账号&角色等）；
②可操作的选项为操作者有权限的组织和【被操作者所在组织有权限的组织】的交集，模块内容同理。
①一种为跨组织后台账号的内容分享：可以查看的内容是【被操作者所属组织所有被共享的内容】和 【操作者有权限内容】的 交集，其中被操作者已经有权限的内容（分享ID）无法被分享。
原型如下：
注：被分享的内容如果之前已经分享给了被操作者同组织的其他账号aa，那么被操作者得到的内容应该和aa账号下的内容是一样的。
所以比较规范的操作流程是：内容在进行跨组织分享时同步分享给被操作组织的管理员后，后续再用管理员账号或者其他账号在组织内部进行分享。
②另外一种是同组织后台账号的内容分享，可以查看的内容是 操作者有权限的内容，其中被操作者已经有权限的内容无法被分享。
原型如下：
注：跨组织分享后一个产品相当于被复制成内容一样的另外一个产品，后续的任何更改都不会被同步。而同组织共享之后仍旧是同一个内容，后续任何更改都会同步。
前台用户可以在门户网站上看到自己所在组织的有权限的前台模块，如果有场景需求可以精细化同一个组织下的不同前端用户分别设置权限。前端的数据隔离分为两种：
①不同的组织发布的内容只能本组织的前台用户可以看到。
②对于SaaS服务商为多个租户提供内容服务的业务，可以对其进行特殊化处理，使其发布的内容让所有的组织的前端用户都可以看到，但是不同组织产生的用户内容只能本组织的用户看到。
前台用户涉及到字段如下：
常规SaaS系统的设计用到的概念或者思路大概是类似的，但是是否需要进行跨组织管理，跨组织管理需要精细到什么程度。
不同组织的用户数据、相同组织的用户数据如何隔离，处理方式是否相同等都是要根据实际业务场景来设计的。
没有完全标准通用的SaaS系统，我们需要设计的并不是一个完美的SaaS，而是一个最大限度符合业务需求，又能在通用的同时兼顾后续长远规划，尽最大可能降本增效、提升用户体验的系统。
此部分分享到此结束，希望本篇文章能帮助到需要的小伙伴们~
本文由 @Grace 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。