从系统最基础的角色权限揭开“SaaS”平台的面纱

7 评论 17411 浏览 89 收藏 26 分钟

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

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

一、客户的痛点思考

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

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

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

放图:

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

临阵退缩

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

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

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

  1. 工程量大,周期长。
  2. 投入大,组建团队难。
  3. 市场未经过验证,做完了,别人买不买单尚是未知数。

二、专业的产品解决方案

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

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

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

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

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

回到主题SaaS

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

三、SaaS的核心

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

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

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

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

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

四、SaaS的权限控制

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

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

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

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

  1. 开发预设好系统的功能、操作权限;
  2. 添加角色,角色关联功能,功能可以再细分到操作权限,如增删改查等(很多系统喜欢偷懒,权限只控制到功能一层,无操作权限的控制);
  3. 添加账号;
  4. 选择账号角色(也可以在创建账号的时候就关联角色);

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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 小白想请教一下,现在我们有一个场景,一个平台下多个培训机构,可以自己创建教师账号,如一个教师在多个培训机构下都兼职,教师是算做不同的账号还是同一个账号处理,该怎么登录系统呢?

    来自江苏 回复
  2. “但是,产品设计的理念告诉我,比如灵活配置的问题,不是最灵活才是最好的设计的,需要讲究最恰当的灵活,才是合理的。
    所以,账号关联操作权限的理念在系统是行不通的。至于行不通的真实原因,可以自行思考下。对比下两种方式下创建账号,在系统生成的数据量,就大概知道原因了。”
    大佬,这块能帮忙详解一下吗,谢谢。我恰好碰到这个问题了,我想完全按照权限、角色、用户的模型,但是领导想更灵活,我说服不了我领导o(╥﹏╥)o

    来自江苏 回复
    1. 你老板想简单了吧,把RBAC完成的弄出来也基本满足绝大多数企业了。可以把角色的上下级、继承、约束等模型综合考虑一下。或者用ABAC模型

      来自北京 回复
  3. 平台管理员和商户管理员,可以认为是2套独立的组织架构吗?放在一起总觉得很奇怪。

    来自福建 回复
  4. 数据权限的讲解很棒!话风很幽默哈哈

    回复
  5. 如果角色是开放给客户自定义的,那么新功能上线后如何优雅的同步给用户呢?

    来自广东 回复
    1. 角色一定是给客户自定义的。平台给客户定义角色是没有意义的。但是可以自定义一两个通用的角色,方便客户快速使用。不给通用角色,也无所谓,微店就没有给……客户总是会用的……

      回复