后台

OSS系统搭建复盘,被业务推着走的后台产品

原创: Kevin改变世界的点滴 Kevin改变世界的点滴 昨天

负责的后台系统OSS,经过1年的规划整体系统整体规划上线。在这里复盘下我工作中负责的后台产品经理搭建模块和经历过的坑。


整体系统是服务于门店、客服、销售团队、IOT平台4个模块,在这里列出OSS系统规划的案例




OSS系统全称(operation support system),全局运营管理后台。因负责的后台4个业务特点在后期才逐渐出现明显划分,在初期其实是并没有这样的模块分类。


初期快速发展期


初期建立OSS系统,可以说整个后台开发与产品团队都相当懵逼的。我们只知道某个业务模块需要一个管理模块,但很难想到在初期产品设计上就需要考虑这个模块未来可能会是其他业务线的公共模块。到底什么业务应该放在这里,什么业务不放在这里管理,说实话团队没有人非常清楚。


作为OSS产品负责人,首先要清楚当前最需要的解决的业务场景,因门店急需要这样的系统作为支撑。起初处于门店管理的业务就考虑在内,例如


客户预约-达到门店-门店签到-开始检测-数据解读-服务完成


在上述业务流出下,需要一套管理系统能够检测客户的服务进度,并且管理者也可以知道门店日常的服务情况,客户的消费支收;门店涉及到智能硬件的服务,系统还可以实时监控硬件的运转状态,及时报错让体验店人员感知立马修复。



满足业务下,OSS系统首先以门店管理为优先模块,打通客户进入门店后的业务流程。



在同时,因服务人员需要数据查看客户数据功能。因此业务化的客服系统同样被需要,不仅是正常的日常客服服务,还要包含整个用户的业务数据查看。使用人员通过客服系统接受客户咨询、查看客服服务记录信息、基本信息,还有产品信息。


在业务上,进入门店的用户,进行信息管理升级成为会员管理。这里的信息管理是区别于普通注册用户的信息管理,需要针对客服一对一服务。每个会员都服务类型的标记、服务状态的标记。方便医生进行下次服务或初次服务。



4个产品线后的权限设计


4个产品线上线后,因为都归属于OSS系统中。每个内部使用人员都不需要使用其他产品线的功能,并且因为会员信息属于用户隐私,保证用户数据只对相应人员查看。


这里开始进入第二阶段权限设计。权限设计包含


  • 操作权限

  • 数据权限


操作权限是指用户可以操作的页面权限,比如客服人员不需要操作门店管理页面、门店管理人员不需要登录客服系统。


此针对权限设计,增加了角色。基于RABC权限设计的方式一个账户下配置多个角色,每个角色有对应的数据权限和操作权限。


通常一个账户只能对应1个角色,但因特殊场景比如外部客服可能需要使用某2个角色的功能,所以一个账户通过配置2个不同角色,获得最高的权限。



权限上线后,隔离了账户与账户之间的数据性。保证每个客户都属于自己归属的服务商。


与业务一起定标准



在OSS系统初期,会员与普通用户概念对于业务部门还无法区分,产品经理就需要协助在先有业务下考虑到未来的业务扩展性进行设计。


在OSS系统中,涉及到游客、用户、会员,如何配置3者的基础信息,以及3者之间的信息权重。


会员用户扩展到客户管理系统(CRM)中,游客与用户则用户运营管理平台中。不同的用户类型所存储的产品业务线也不同。


尤其是服务人员、客服人员、销售人员都需要熟悉知道自己关系的用户是那一类类型。服务人员只需要关系会员即可、客服人员需要关于用户、销售人员则需要关系游客与用户。


后系统搭建的难点


第一个难点:数据表的设计


在后台设计中,尤其是前期业务线不明确的时候。同样的一个模块可能因为产品线不同,会出现不同的地方。比如用户基本信息查询,会员会包含基本信息、游客也会包含基本信息。


用户列表、会员列表都会存在这样的基本信息查询,但对于后台来说由需要调用不同的接口,可能需要对接口进行改造。


第二个难点:后台平台与其他平台的关联


在搭建OSS系统中,因为本身企业就存在一个老管理系统,为此首先以用户列表管理模块、系统登录都是用的老系统下的账户体系。登录页面都是用的一套。导致了后续在客服系统对外使用时候,调整前端登录页面会关联到老系统。影响了老系统内部使用


第三个难点:数据接口的管理和维护


在系统不断扩展后,随着数据纬度和类型越来越多。客服系统中所需要扩展的功能都需要调用增加的接口。系统架构的设计就会逐渐重要,那一些接口是底层接口,带有公共属性的。哪一些是某个特定功能下才会出现的数据。



当然,整个系统花了1年的搭建时间。今天复盘的点,都是整个过程中的大节点,为以后作为良好的记录。


好啦,今天的原创就在这, 我会坚持每周更新两篇~




推荐阅读:

坚持一年,招募100个产品经理


我的第一本书,给你们




Talking

发表