上面看到的工厂即便有很多分厂和子公司，一般也是由集团控股的。但如果是门店类型的组织结构，比如说诊所，连锁店之间很可能就是战略型合作，但实际还是各自运营的，这种关系就比较弱了。02集团设计模型假设我们现在已经做完了单租户的系统，那如何在这基础上支撑集团呢？方案1：切换各租户账号做集团后台是有不少工作量的，前期在人力不够的情况下，集团管理员想要了解各分部的情况，就只能登录不同租户的账号查看信息。这就面临着一个问题：无法做统一报表，并对各分部进行横向对比和分析。如果客户月末或者年末需要数据，那就只能让开发从数据库里把数据导出来了。方案2：单租户系统数据权限控制上面的组织结构按理是可以支持在一个系统中实现的，不同的分厂就是和总厂平级的父节点。人员挂在不同的节点上，系统可以控制该人员只能看到自己节点以下的数据，或者有个数据权限的功能，让客户手动设置。 但这边带来的问题是系统中所有的地方都要标明是哪个厂的，比如产品要增加适用分厂；设备要增加所属分厂。这样一来数据设置麻烦，字段冗余，而且在用户使用时还要根据数据权限进行判断，增加了系统复杂性。但实际上工厂中大部分的人员是操作工等干活的人，不需要也没有权限看到其他厂的数据，仅为了少部分管理者的需求，把单租户系统复杂化性价比不高。方案3：搭建集团后台比较清晰的设计方法就是在单租户的头上再包一层集团的概念，这对于客户来说也是比较好理解的，各厂在实际生产过程中独立运行，但管理权在集团。这就意味着需要再做一个集团后台，看似增加了一倍的工作量，但实际上不会多很多。我们都有这样的经历，新做一个系统远比改造老系统来的简单且不易出错。下一节也会讲到集团后台的功能，比单租户系统中的功能少得多，而且更多的是把做过的系统复制一遍，就简单很多。综上所述，还是建议用集团后台的方式来处理。03集团后台功能设计首先明确集团后台的使用者：财务和管理者。那么后台的功能主要是2大块：报表和统一管理配置。报表这里的报表包括财务的，也包括运营管理的。比如说诊所集团后台的报表，有费用统计、医务统计、药品进销存统计、运营统计。这些数据就是把各分店的数据做了个汇总查询页面，在筛选的时候可以选全部，也可以选具体某个诊所。对原代码的复用率是很高的。
基础数据设置
集团进行统一管控时，绕不开基础数据的统一配置，比如诊所的药品，一般连锁店之间的药品是统一进货，各店之间互相调配的。但如果只做统一设置还不够，诊所间因为有地域的差异，药品还不完全一样。比如城西店有医美项目，那肯定会增加医美类药品。不同诊所间的价格也可能不一样，北京店的会比小乡镇的贵。所以这边通常有3种做法：（1）集团有统一创建权，分店无任何权力。（2）集团有统一创建权，分店有各自修改权。（3）集团有统一创建权，分店有各自创建和修改权。最好是都能支持，开篇也说过不同集团的运营模式差异比较大，就算同一集团下的分店也可能是不同的模式，比如一些是直营的，一些是加盟的。基础参数配置基础参数的配置也是运营管理中的重要一块，比如会员管理，一般连锁店之间的会员是通用的，那会员的设置规则就需要由集团统一控制了。还有一些参数的控制，比如各分店的地址等基础信息，储值赠送规则，流程参数控制等。这些权力的上收能保证各分店服从集团的调配，避免私下搞运营活动。04总结之前连锁类的需求一直是用集团后台的方式来实现的，最近有人提问说，为什么不在一个系统里面用组织结构树来实现呢？听着也挺合理的。我分析了下，还是用集团后台的方式实现成本最小，也比较好理解。当然也有缺点：管理者在集团后台只能看到总况，想要看明细数据还是要去各系统。但从场景的使用频率来说，这样的设计还是较为合理的，毕竟没有一个完美的解决方法。END司马特小分队是由几位志同道合的资深产品经理打造，把自己多年的经历和产品经验分享给更多的产品经理。
我们在星球成立了“B 端产品经理之家”，汇集了 200+来自教育、医疗、电商等行业的小伙伴,每天都有各种产品话题讨论，也有行业专家答疑解惑。
更是有多位小伙伴，通过我们改简历和模拟面试，成功拿到心仪的offer。每天不用 1 块钱，得到的是可见的成长。
悄悄的说，回复「星球」，会有 50 元优惠券哦往期精彩回顾
疫情期间，在线问诊的成长与发展
好的产品，得一手抓模式，一手抓数据
智能随访系统：补齐诊后随访的短板
原文链接：http://www.wanshiruyi.cc/news/6711.html，转载和复制请保留此链接。
以上就是关于连锁型客户，该如何用最小成本解决复杂需求刀客家族的女人结局全部的内容，关注我们，带您了解更多相关内容。
以上就是关于连锁型客户，该如何用最小成本解决复杂需求刀客家族的女人结局全部的内容，关注我们，带您了解更多相关内容。
特别提示：本信息由相关用户自行提供，真实性未证实，仅供参考。请谨慎采用，风险自负。
