saas开源权限管理平台「SAAS模式」

今天给大家普及一下saas开源权限管理平台「SAAS模式」相关知识，最近很多在问saas开源权限管理平台「SAAS模式」，希望能帮助到您。

编辑导语：SaaS平台是一个比较复杂的系统，基于垂直领域SaaS平台特点，所需要的功能特点也不同。文章从药店SaaS平台出发，在基于基础功能模块的前提下，阐述垂直SaaS平台的设计流程，与大家分享。

阿强已经开始创业了（创业个毛线哦！就是他老爸给钱去锻炼了。我tm还在普通副本刷怪升级中……），他决定做一个SaaS平台，提供给他老爸的万家药店使用。作为阿强少爷的忠诚好友，给他老爸打工的我，“应该”为阿强献上我宝贵的意见……

一、客户的痛点思考

B端客户的痛点思考，从来都是以其实体业务经营的场景为基础进行思维发散的。

因为我们需要以“药店整体解决方案”的理念入场，所以药店的数据一体化显得非常重要。如果因为我们的入场，客户的系统数据还是四分五裂的，那么我们的存在就显得那么的无意义了。

因为是药店客户，所以，我们首先需要解决药店基础系统——药店进销存的问题，其次是药店销售处方药的问题，引入互联网医院提供的电子处方单。线下服务，连接性总是弱的，互联网的手段必须用起来，微信公众号、小程序就是首选，那么药店的在线商城和线上优惠券之类的在这里就是必须的了（这里不扯合法合规性的问题。服务要讲究粘性，讲究千人千面，会员系统也就是必须的了。作为药房本身的职能，可以考虑与社区医院合作，作为其指定的药房使用，也好契合着国家医药分家的号召。最迫切的，解决药店药品供应链的诉求，降低药店采购成本，满足用户用药的普及性。当然，除了通过供应链解决药品多样性的问题，为药店引入医药电商平台也是一种可行的解决方案。

放图：

当然，系统的输入永远都只是工具，真正的运营，还是需要团队去执行的。是药店的团队，或者是平台建立运营团队服务，那就是强少爷的事情了。我不建议了。

临阵退缩

做为一名专业的产品经理，我敢保证，上面的系统我都能做，我也敢做。但我绝不保证产品的质量和产品上线的时间。

B端的项目也好，C端的项目也好，都是需要迎合市场的。快速试错，快速调整，才是互联网产品迭代的规律。

很明显，上面的系统，市场上都有，并且还是经过多年的市场锤炼迭代到今天的。专业性不敢说都是100%完美，但肯定是要比半路出家的要强咯。再说，这里涉及到的随便一个产品板块，基本上都是可以养活一家百人级别技术公司的，让我们来搞，能不能搞好先不说，前期人力成本就得哗啦啦的烧一大笔钱。总之这个玩意就是：

工程量大，周期长。投入大，组建团队难。市场未经过验证，做完了，别人买不买单尚是未知数。二、专业的产品解决方案

问题总是比办法多的。不要害怕，搞就行了。我们始终要明确一个目标：保证业务开展，试错要快！

业务起步，每个业务系统都要自己搞，那是不可能的了。人家有的，我就直接借用吧，反正他们的产品都已经那么成熟，不用白不用：

对于进销存、电商商城、营销系统（和商城一起的）、在线直播等系统，直接找厂家合作，要求用户数据回传至我自研的平台。对于第三方系统无法提供的，或者提供不合适的系统，安排自研，平台输出给药店使用，如会员系统（多个系统的用户集合到我平台，他们的数据分别独立，即时提供会员功能，也是不好使）等。开放平台，允许第三方能力输入，如互联网医院、药品供应链等。

因此，我们相当于做了一个数据交互的枢纽平台。后续数据沉淀后，便可做精准化的用户服务。至于第三方系统接触哪些厂商，可以找市面最火的吧！那是阿强少爷的事情了。

业务先跑吧！如果后续客户用的爽了，第三方系统却不想和我平台合作的话，到时候可以让阿强考虑收购，或者来一次自研！有市场，怕啥投入哇！

回到主题SaaS

寻求第三方合作厂商，为药店提供应用系统，有个前置的条件——对方的系统也必须是SaaS，单机版本的系统自然是不能满足我平台建设的要求。当然，我平台的设计基础核心，也必须是SaaS。

三、SaaS的核心

SaaS平台的核心板块，就是商户体系。

以B2C模式的电商商城来举例，你做产品设计时，这里的B就是你所在的企业，所以你在做产品功能设计时，只会根据你们企业内部的需求进行定制化。但是SaaS不行，SaaS多了一层平台的概念，变成了S2B2C，在这个模式里，你所充当的角色是平台S，而这里的B，就是你之前的公司，所以在这里，你需要设计的是满足无数个B的需求，而不是像以前一样，只想着一个B是不行的了。

关于商户体系的建设，我们需要从市场的商户表现形式进行思考。市场主要表现形式为：单店型，连锁型。而连锁型里面又包括直营店、加盟店、代管店。单店模式是最简单的，麻烦在连锁模式，因为直营店、加盟店、代管店，他们与总部的关系是不一样的，特别是在分钱这个环节上。

所有合作的企业，不管是连锁型，还是单店型，对于平台来说，只是属于我平台的一个商户，平台允许其创建门店。也不在乎其创建多少家店，反正应用系统，直接与门店关联。设置总店与分店，进行数据范围的控制，总部可管理所有分店的数据。

因此，平台开始设计后，几乎所有数据，都是需要关联到具体门店的。如订单的数据存储，数据表的设计如下：

四、SaaS的权限控制

商户体系建立后，通过系统的账号、角色、权限来实现不同人员的操作权限，是SaaS平台的又一灵魂之处。

关于后台系统的账号、角色、权限，下面会简介的比较详细一些，如果没有什么兴趣的话，可以直接跳过当前章节。

1. 绝对标准化的系统角色权限设计

纵观大大小小的后台系统，关于系统的账号、角色、权限的产品设计，绝大多数后台创建账号的操作流程为：

开发预设好系统的功能、操作权限；添加角色，角色关联功能，功能可以再细分到操作权限，如增删改查等（很多系统喜欢偷懒，权限只控制到功能一层，无操作权限的控制）；添加账号；选择账号角色（也可以在创建账号的时候就关联角色）；2. 账号直接关联权限与角色直接关联权限的取舍

我总觉得账号关联角色，角色关联权限的设定，会使得系统在对账号进行灵活化的权限配置时，显示苍白无力。打个比方：设定一个角色为客服，客服关联了客服相关的操作权限，员工ABC均关联该客服角色，由于场景特殊化，需要给员工D添加多一个客服角色外的另外一个操作或者功能，就需要在系统中再单独创建一个客服2的角色，才可以实现此需求：

因为客服1和客服2的角色，关联的操作权限大部分是一样的，仅仅只有一个操作权限的差异而已，所以我想，使用账号直接关联权限，角色仅仅只是作为一个角色包快速选择的功能项：

在创建账号时，还是一样选择角色，角色关联权限包，选择角色后，加载当前角色所拥有的操作权限，允许进行二次修改（即添加多几个权限或减少几个权限）。

这样的话，针对上面的客服ABCD，我只需要添加一个客服的角色即可，在创建特殊化场景的客户账号时，给他选择了客服的角色，然后再进行多一个审批操作的添加或者是其他权限的添加即可。实现账号权限的绝对灵活化的配置。

但是，产品设计的理念告诉我，比如灵活配置的问题，不是最灵活才是最好的设计的，需要讲究最恰当的灵活，才是合理的。

所以，账号关联操作权限的理念在系统是行不通的。至于行不通的真实原因，可以自行思考下。对比下两种方式下创建账号，在系统生成的数据量，就大概知道原因了。

3. 数据权限的理解

上面讲到的仅仅只是功能的权限而已。对于系统权限来说，是会区分功能权限和数据权限的。但是很多情况下，在添加账号的时候，数据权限是没有办法显性的表达出来的，它是需要在某些特定的功能下，才会需要用到的。但是在SaaS平台中，数据的权限，处处都是明摆出来的。

首先，我们来理解没有做数据权限控制的功能，这个意味着，只要你给该账号添加该功能权限，所有的用户，进入该功能，看到的界面的数据都是一样的。自然这个是有违SaaS的规定的。你中不能让B商户的用户看到A商户的数据吧！那不是扯着吗？

那么SaaS关于数据权限的控制第一步，把上面订单的结构拷贝下来：

所有的业务功能，只要是提供给到商户或者门店去使用的，均需要根据商户或者门店进行第一层过滤。保证门店或者商户，只能看到自己范围内的数据。大哥，数据隐私性安全性，很重要的，可别乱搞……

第二步，个别功能，数据范围按角色进行定制化。如客服查看“我跟进的订单”，那么数据需要按账号进行过滤。或订单数据查看范围，需要按照区域进行划分，这就需要对账号进行定制化的区域范围关联了，要比较复杂，除非是账号本身也有关联区域，可进行数据匹配进行数据筛选。当前步骤比较特殊，需要根据特性场景定制化。

大多数的系统不愿意做数据权限控制，宁愿复制多一个一模一样的功能点，在查询数据的时候，加多个筛选条件，这样会比较好办些。比如说，订单管理和我的订单，其实界面来看，操作来看，其实是一模一样的，但是我的订单，是只筛选当前用户关联的订单信息。这样做虽然简单，但是功能会比较累赘些，且两个基本一模一样的功能界面点，后期有一个界面优化迭代，另外一个界面也需要同步进行维护迭代，真心挺麻烦的。

所以，关于数据权限的选择，真是各花各眼，从系统功能规划来讲，我个人更加喜欢把功能点划分的简单些，所以你看到的订单管理，就是你想看到的订单管理，不是专门给你多做一个“我的订单”的板块，后续维护，老子是真的懒得跟你改这又改那的……

4. 账号与商户的关系

先提个问题：先有账号才有商户，还是先有商户再有账号？

SaaS平台的账号，和单体系统的账号管理，绝对是不一样的。

单体系统不用问阿强都是知道的，肯定是现有系统，再有账号的啦！单体系统的商户就是平台自己，固定的。这也造就了我们对于创建后台管理账号的习惯性思维逻辑，禁锢了我们发的思想。

我告诉你哦，SaaS平台，账号和商户没有必然的先后关系：

模式1就是默化的设计思路，一般这种情况，在创建账号的时候，会习惯让填写一个登录账号和登录密码的玩意！试问一句，现在登录的操作，那是有手机号 验证码不能做的事情！！！另外就是，假设当前使用的是手机号作为账号，这样的设计，可能会漏考虑到同一个人，会关联多个商户或多个门店的情况。

那么模式2，在SaaS里面，就能够完美解决这个问题。如果有用过钉钉的，可以试想一下，用户账号是通过手机号先注册的，进入钉钉后，是允许选择进入的企业的。这样的思路同样适用于后台，我把微店的登录界面一截图，就很明显了：

这个页面搞得有点花，在设计上来说，去掉这个页面也是没有毛病，直接在进入主界面，在顶部栏，做好切换店铺或企业即可：

那么，账号和商户的设计理念，就是这样的了，账号登陆后，可以根据账号关联的商户或门店，展示出来，以供用户进行选择，切换管理：

5. SaaS系统中，平台管理员与商户管理员的区分

设计这个SaaS平台时，上面对于商户、门店的入口，我们上面基本已经考虑到了。但是如果作为平台本身的管理员，我们应该怎么去设计其在系统的登录呢？

很明显，商户只能看到商户的数据，平台管理员，需要看到全部的数据，但是平台管理员不是万能的，有些业务性的操作，平台是不能做的。比如说，商户的订单审核、商户的客户对接，平台是不能乱搞的。这个时候，我们需要考虑下，这个平台的管理员角色，我们一定要让他登陆到这个后台吗？

从产品业务合理性的角度出发，建议拆一个运营后台出来，专门给到平台的管理员去使用。这个运营后台，就不需要加SaaS的概念进去了。因为登陆的用户，就是平台自身的员工而已。之后，根据平台管理所需要的业务功能，定制化设计开发即可。

但是，从开发成本和时间成本的角度来说，产品经理就需要对设计做深一步的取舍了。如果人力物力不够的情况下，平台管理员和商户共用一套系统，是很有必要的。大不了，后期条件允许的情况下，再开始做运营后台咯。

6. SaaS的其他迭代

至此，SaaS平台从0到1的基础框架已经搞完了。至于其他业务板块的功能迭代，追寻以上的设计原理，在所有的数据前面做好商户和门店的关联，在功能展示上，定好功能、角色的数据可视可操作范围就可以了。想象一下，发现，SaaS也就那么回事……

当然，很多技术人员会和你讲到平台的分布式或微服务的概念，因为SaaS平台，本身在很多业务操作上，是存在很多共性的，所以需要将某些具备固定用途的板块独立化，比如支付、比如订单等等，嗯呐，这个属于中台的职能了，另外研究吧！

五、SaaS平台的门槛

如今技术的发展，要实现一个SaaS平台从0到1的搭建过程，已经不是一件什么难事了。所以在技术上，基本上是没有什么门槛的。但是在花钱上面，门槛比较大。

对于成本的预估，第一是平台从0到1的技术团队的组建，现在开发人员是那么的贵哦！想起当年在那个不堪回首的前公司，那个CTO一上来，就是分布式，关于产品的东西还没有见到雏形，就已经是100多人的技术团队了，从项目经理、产品经理、后台、前端、测试、运维、架构师等等，样样具备……

那个钱，刷刷刷的烧啊！可怕的是，搞了1年多，还是没有啥东西出来！第二就是服务器成本，系统大了，要用到的机器也是少不了咯。不晓得要多少，反正要花钱。第三块是宽带，现在短视频和直播那么火，这些按流量计费的玩意，怎么收费，可以去阿里云和腾讯云LOOK下吧。

最重要的，就是推广了。花了巨资后，终于把东西搞好了，但是如果没有人爱用，或者已经被其他同类型的SaaS平台抢了先机，这么折腾搞这个玩意，到头来是为了个啥子哦！

六、SaaS平台的市场认可度

以前都是单机化的软件部署模式，谁要，谁买。独立部署，独立维护。现在一套SaaS云端直接解决，一个注册分配一个账号，就完事了。商户不用东西折腾，又是搞服务器搞这搞那的。厂家也不用单个系统单个系统的维护，增加人手、增加成本，每个系统都定制化的改来改去，改到最后面都不晓得是自家开发的产品了。且原来独立化部署的系统，购买成本也是极高，现在SaaS账号，可以数千元就搞定了。对于这些来说，对于商户和厂家来说，SaaS真是福音啊！

但是，SaaS的市场群体是有限的，且在一定的程度上，它是不能够被市场所认可的。因为，SaaS里面产生的数据，是在SaaS厂商的数据库里面的。商户前期虽然在系统的投入上节省了大量的钱财，但是，这些都是通过出卖自己的数据所换回来的！然而，对于长期经营的商户来讲，数据，绝对是一大笔财富！

没有关系，业务先行，可以先跑。不想重投入或者没钱重投入的人，前期先这样咯，不然阿强少爷做这个平台还有什么意义啊！

七、我认为“阿强药店SaaS服务平台”的未来

虽然SaaS平台不应该被市场所认可，但是SaaS平台却终究是一个行业趋势，也终究要被很多人所接受。想象一下，当你以为山寨的年代已经过去了，拼多多的崛起还是让山寨回到你的视野了。为什么？不就是人太多，想法太多，各种各样的人都有吗？

有就好，所以给阿强少爷规划的这个平台，还是有未来的。

SaaS平台，讲究的是产品。产品好，解决了客户的痛点，而刚刚好又做好的客户的客情。生意就这样开始了。

但是要端正一个态度，当前做的这个SaaS平台，绝对不要给自己囚禁在产品服务的范畴了。对于平台来说，后期的增值性服务尤其重要。如数据分析、大数据辅助决策、用户标签千人千面、精准推送等等。这些都是让平台升值的关键性因素哇！

另外就是药店本身属于一个医疗健康类型的特殊性行业，平台还可以利用这点在行业里面做一个横向的扩展，逐步打造成大健康的医养平台。

八、最后

最近在研究微店的SaaS商城，因此想到了这个SaaS的主题。之前在钉钉上购买过一个叫“氚云”的服务，它也是一个SaaS的系统，同时还加上了PaaS(平台即服务)的理念。作为产品经理的我们，看到这些英文缩写的时候，并没有因此会角色它是高大上，因为从产品设计的理念出发，我们只是站在客户的角度去思考客户的痛点而已，然后通过我们专业的能力，刚刚好设计解决了他们的需求。

阿强少爷这个系统还在做，我主动申请亲自挂帅了。但是阿强他爸觉得自己来搞太慢了，强迫性要求去找外包团队实现它。我想，就这样吧，拜拜，不见。

最后，觉得文章还可以的老铁，点个赞，一定要点赞哦！

本文由 @产品经理龙汪汪 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议