贝壳找房 | 如何从0到N搭建HRSSC？
9月13日，“取势 明道 优术 2023 易才CTG智慧人力畅享季 北京站”成功举办，易才与众多HR伙伴们一同深度探索人力资源共享服务世界。当天，易才特别邀请到优秀合作客户企业 贝壳找房的HRSSC负责人韩昀珈女士，带来了《贝壳人力资源共享服务如何从0到N》的主题分享，共同学习贝壳共享服务如何从零开始，发展成无限可能的进阶之路。
下面就跟随小编一起回顾一下精彩内容：
注：文末可下载讲师PPT完整版
01 初期面临的挑战与HRSSC搭建背景
贝壳当时面临的状况是业务变革快速。人力资源管理团队从服务千人到服务万人，人员分布从全国几城到几十城，业务快速扩张的诉求要求一个月的时间，所有人必须全部到位。我们的初始团队从只需负责北京一地的基础工作，到全面负责全国人员的基础人事管理??入职、合同签约、离职、社保缴纳，薪酬管理，当时面临的挑战非常大。
人力在业务端的挑战也不小。那个时候我们城市的人力伙伴，每天都在加班加点，白天与业务一起开会，晚上再去做一些基础的入转调离工作。我们当时做了万人的合同改签，还是用纸质的劳动合同。给大家下发模板，跟进改签，回收后审核，大概用了几个月的时间。
通过对当时遇到问题的梳理，我们从组织和人力管理的维度，去了解对HRSSC的诉求是什么？从公司的视角，就是要数清楚人，准确发工资。而人力管理的核心诉求是，能够从大量繁冗的基础人事工作中摆脱出来，能有更多的时间与业务人员进行沟通，比如招聘关键人才，设置薪酬结构，搭建企业文化。
02 HRSSC体系搭建阶段
第一阶段，线上化建设。保证基础的一些人事工作能够全部线上化闭环到全国所有的城市人员。我们当时提了两个目标。第一个目标是选好核心人事系统，也就是Core HR系统。第二个目标是做一些核心场景的筛选，也就是哪些场景是必须先要去做线上化的。
前面提到了公司的诉求，要把人头管准，发薪的数字能够百分之百精准，要先解决数据源头的问题。所以，我们首先上线的是入离职管理流程。
在18年的时候，我们陆续上线了电子签和AI入职，把整个入职的流程全部线上化，保证大家在入职当天都能签一份准确的合同，大家的入职日都是准确的。然后才能为后面的一系列工作，包括离职、算薪发薪打好数据基础。入离职上线之后，我们就逐步推进了考勤系统、调岗与薪酬系统的陆续上线。第一阶段大概经历了两年的时间，但在这过程当中，我们是一边建系统一边开始进行第二阶段。
第二阶段，集中化交付。系统上线使用之初，城市的人力伙伴都很欢迎，因为他们觉得效率有提升，有改变。我们原先在城市端的人员入职都没办法在门店里面直接办理，需要到城市的职能总部集中办理。入职线上化之后，我们所有的经纪人可以在门店自助就完成入职手续的办理，所以刚开始大家都是很开心的。但是一段时间之后，各地很多个性化的诉求就开始提出来了，他们都希望通过系统去实现，但是系统没有办法去承载这么多诉求。
我们在当时做了一个抉择，把一些可以通过一定规则约束，可以基于系统去做集中处理、审核、咨询的工作集中到了天津。让城市HR有更多精力去做HRBP、COE、辅助业务的工作。
第二阶段的核心追求是人效支持比。那两年整个贝壳的业务跟人员规模在快速扩张，在这个过程当中，HR团队基于系统和集中化交付，用更少的人力去支持更多的员工，实现了我们的支持比的持续提升。
第三阶段，服务内部市场化。到了2022年，系统建设日趋成熟，已经可以满足HRSSC的基础运转了。然后我们就在思考，我们到底还能为这个组织带来什么样的价值？我们还能做哪些事？到了这个阶段，我们想的就是做好服务的品质，然后让我们的管理更进一步地规范化。因此，在当时引入了一个概念叫服务内部市场化。
因为有一些公司做了类似的实践，我们就一边学习一边思考。为了凸显我们的服务价值，让我们能够了解城市端真正的诉求是什么，能够有更多的反馈给到我们，让我们做一些真正有用的改变，我们就采用了定价。
定价有一个前置条件，就是需要把成本核算得非常清晰，因为如果你不能够厘清HRSSC投入成本的话，你也就无从定价，你也没办法说服业务方去接受这个价格。所以我们对成本项做了完整的梳理，我们把自己定义为内部的供应商。作为服务的提供者，我们会把我们所有的业务成本、人工成本、还有外部供应商，比如说易才，他们的服务成本，技术成本，做一个全成本的核算，基于这个成本再做定价。
在这个阶段，我们更多的就是成本导向。通过基础数据说服老板，当前的模式是最优的，对于公司来讲也是最划算的一个选择。
第四阶段，行业赋能。在服务市场化的基础上，我们开始考虑通过贝壳的平台去做一些行业的赋能。我们为什么这么做？因为我们在行业上还存在着很多用工管理的规范性较差的企业，它们在用工、财税方面抗风险能力是很低的。我们也发现这个行业里面确实存在了太多这样的问题，那我们门店的这一套规范的管理体系有没有可能去面向平台来去做这样的一种赋能跟使用？所以，我们投入了很多的时间精力放在了行业服务。
03 HRSSC内部的三支柱组织模式
随着贝壳HRSSC的不断升级，我们在内部又延伸出了HRSSC的三支柱组织模式。企业可能都有HR三支柱，那为什么在HRSSC这个领域里还要再去分出三支柱呢？核心是因为我们要支持的人员太分散了，规模太大了。在这种情况下，我们内部的组织模式也需要按照大家的能力属性、岗位职责去做一些类似的划分，否则运行起来一定是低效的。所以我们在HRSSC内部也会定义出三类人群。
第一类人群，就是后台，我们内部叫HRSSC的COE，这些人可能更多的是做体系规划与数字化管理、系统建设以及规则的一些管理。这个团队要求人员在他所在的领域模块之内纵向深度要足够扎实，专业度要非常强。因为他在全国范围内碰到的特殊case是非常多的，而且他在这个模块要与其他模块的协同性非常强，需要他调用很多的专业知识。
第二类有一个比较大的运营团队，是天津的HRSSC，这个其实是我们真正的共享中心，他们base在天津。更多的是把我们原来城市端的一些工作，还有就是原来在北京团队里面的一些基础事务性工作，去做一个集中化的管理和支持。
最后第三类，我们还有一个区域团队，定义为SSC-BP。在管理上，团队分成两类，在战略城市由总部直管，在其他城市则是虚线汇报，总部从专业线的维度对他们进行考核，实线汇报对象是城市的HR负责人。
来自讲师PPT
在规划的时候，首先要清楚HRSSC要为公司解决的问题是什么，把这个问题解决好了，才能跟公司去申请更多的资源。
2业务层：HRSSC亦是业务体，时刻保持对一线的感知
贝壳一直把HRSSC当成一个业务体来看，当然不可否认它肯定是一个人力的职能单元。但是它是未来最有可能做内部市场化的，所以我们一直强调要有一线的手感，而且我们平常确实会跟大量的一线员工或者城市的HR做对接。HRSSC跟COE比起来，核心的优势就是在前端、在一线，城市发生了什么他们是最清楚的。所以我们要求在所有过程当中，特别是在团队模式里面，越是偏后台的角色，越要让他跑到前端，去了解在共享的交付团队和前端的区域团队发生的事情是什么。
3系统层：立足长远，也要能解决当下的问题
系统层要解决长期和短期的问题，我们尽可能地立足长远，不要给未来埋坑。在解决当下问题时，如果其中可能影响未来的流程建设，就一定要前置思考，有可能是一个接口，有可能是一个功能，通过前置判断，保证系统的建设是长期持续的。
4团队层：分工与协作是必然的选择，各有所长，因势利导
大家可能会根据工作内容做一些分组，组与组之间、人与人之间的分工与协作要多关注，可能要通过绩效的牵引，或者一些激励、反馈，让他们能够把边界缝隙尽可能地拟合起来，这样他们才能各自发挥出各自的优势。
