连锁型客户,该如何用最小成本解决复杂需求

1 评论 7626 浏览 25 收藏 9 分钟

编辑导语:管理系统对于大企业或者连锁店来说需要足够全面的组织架构,因为连锁店类型的涉及的分支非常密集,需要每一个层级需要清晰明了,管理起来才比较方便;本文作者分享了关于如何用最小的成本为连锁型的客户解决复杂问题,我们一起来看一下。

连锁和集团化是一个趋势,但凡大一点的机构,随着业务的发展,都会有向外扩张的趋势;比如说诊所会从单店变为市内连锁店,工厂会在各地建分厂。

这也意味着我们单店版的系统不能满足客户的要求了,那系统如何解决集团化问题呢?

一、集团的组织结构

我们先来看下工厂集团的组织结构:

一般来说总部拥有最全的组织结构,包含销售、管理、财务、生产等各部门。

分厂可能是完整的组织,但也可能只是一个生产基地,财务独立核算,但销售和管理都由总部统一控制。

连锁型客户,该如何用最小成本解决复杂需求

上面看到的工厂即便有很多分厂和子公司,一般也是由集团控股的。

但如果是门店类型的组织结构,比如说诊所,连锁店之间很可能就是战略型合作,但实际还是各自运营的,这种关系就比较弱了。

二、集团设计模型

假设我们现在已经做完了单租户的系统,那如何在这基础上支撑集团呢?

1. 方案1:切换各租户账号

做集团后台是有不少工作量的,前期在人力不够的情况下,集团管理员想要了解各分部的情况,就只能登录不同租户的账号查看信息。

这就面临着一个问题:无法做统一报表,并对各分部进行横向对比和分析;如果客户月末或者年末需要数据,那就只能让开发从数据库里把数据导出来了。

2. 方案2:单租户系统数据权限控制

上面的组织结构按理是可以支持在一个系统中实现的,不同的分厂就是和总厂平级的父节点。

人员挂在不同的节点上,系统可以控制该人员只能看到自己节点以下的数据,或者有个数据权限的功能,让客户手动设置。

连锁型客户,该如何用最小成本解决复杂需求

但这边带来的问题是系统中所有的地方都要标明是哪个厂的,比如产品要增加适用分厂;设备要增加所属分厂——这样一来数据设置麻烦,字段冗余,而且在用户使用时还要根据数据权限进行判断,增加了系统复杂性。

但实际上工厂中大部分的人员是操作工等干活的人,不需要也没有权限看到其他厂的数据,仅为了少部分管理者的需求,把单租户系统复杂化性价比不高。

3. 方案3:搭建集团后台

比较清晰的设计方法就是在单租户的头上再包一层集团的概念,这对于客户来说也是比较好理解的,各厂在实际生产过程中独立运行,但管理权在集团。

连锁型客户,该如何用最小成本解决复杂需求

这就意味着需要再做一个集团后台,看似增加了一倍的工作量,但实际上不会多很多。

我们都有这样的经历,新做一个系统远比改造老系统来的简单且不易出错;下一节也会讲到集团后台的功能,比单租户系统中的功能少得多,而且更多的是把做过的系统复制一遍,就简单很多。

综上所述,还是建议用集团后台的方式来处理。

三、集团后台功能设计

首先明确集团后台的使用者:财务和管理者。

那么后台的功能主要是2大块:报表和统一管理配置。

1. 报表

这里的报表包括财务的,也包括运营管理的。

比如说诊所集团后台的报表,有费用统计、医务统计、药品进销存统计、运营统计。

这些数据就是把各分店的数据做了个汇总查询页面,在筛选的时候可以选全部,也可以选具体某个诊所。

对原代码的复用率是很高的。

2. 基础数据设置

集团进行统一管控时,绕不开基础数据的统一配置,比如诊所的药品,一般连锁店之间的药品是统一进货,各店之间互相调配的。

但如果只做统一设置还不够,诊所间因为有地域的差异,药品还不完全一样;比如城西店有医美项目,那肯定会增加医美类药品;不同诊所间的价格也可能不一样,北京店的会比小乡镇的贵。

连锁型客户,该如何用最小成本解决复杂需求

所以这边通常有3种做法:

  • 集团有统一创建权,分店无任何权力。
  • 集团有统一创建权,分店有各自修改权。
  • 集团有统一创建权,分店有各自创建和修改权。

最好是都能支持,开篇也说过不同集团的运营模式差异比较大,就算同一集团下的分店也可能是不同的模式,比如一些是直营的,一些是加盟的。

3. 基础参数配置

基础参数的配置也是运营管理中的重要一块,比如会员管理,一般连锁店之间的会员是通用的,那会员的设置规则就需要由集团统一控制了。

连锁型客户,该如何用最小成本解决复杂需求

还有一些参数的控制,比如各分店的地址等基础信息,储值赠送规则,流程参数控制等;这些权力的上收能保证各分店服从集团的调配,避免私下搞运营活动。

四、总结

之前连锁类的需求一直是用集团后台的方式来实现的,最近有人提问说,为什么不在一个系统里面用组织结构树来实现呢?听着也挺合理的。

我分析了下,还是用集团后台的方式实现成本最小,也比较好理解。

当然也有缺点:管理者在集团后台只能看到总况,想要看明细数据还是要去各系统。

但从场景的使用频率来说,这样的设计还是较为合理的,毕竟没有一个完美的解决方法。

#专栏作家#

司马特小队,公众号:司马特小分队,人人都是产品经理专栏作家。8年+互联网资深产品经验,多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验;主要教授产业互联网产品相关的硬核知识点。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 你好,有两个问题想请教一下:1、就是某连锁店或者是某分公司有一定的自主权,决定使用我们系统的服务和我们签约,后来集团整体合作,都使用服务,集团需要看整体和各分公司的运营情况;2、集团和我们合作签约,在某几家分公司中试点,好的话会同样推广到其他分公司,集团也只是整体情况,各分公司自己运营业务,以上两个场景要怎么设计来支持?目前组织没有层级机构,都当成一个新客户去配置一遍,要看整体数据及结算很麻烦,希望重构来解决问题

    来自北京 回复