| |||||||||||||||||||||||||||
本文整理了两位资深HR对过往HRBP经历的自述，读来受益匪浅。
来源:章法森言(ID:johnsonzhang0807)
来源:冬存夏取(ID:HR_View)
在我的14年职业生涯中，有幸在一家外资企业做过2年的BP；BU是整个公司的服务中心，汇报对象是服务中心的运营总监。
这个BP岗位的主要职能是培训、企业文化建设以及组织发展这3项职能。HR常规模块中招聘和薪酬不做，因为整个公司的“成本中心文化”，这两个较大的具有成本特性的权力，由总部HR统一管理，不下放到BU。在业务部门的HR跟总部的HR之间没有汇报关系，只是协同关系。
现在回想这2年在业务层做HR的经历，我用“熔炉”来概括，即痛苦，也是难能可贵的成长。今天用故事的形式，来跟大家做一个分享。
故事从入职的第一天开始说起........
熔炉点1: 没有成本中心的日子
入职第一天，免不了跟老板（Line Manager）聊聊，见面之后，简单的寒暄，就要开始说正题了，老板（运营总监）的几句话，在入职的第一天，给了我强烈的震撼，瞬间感觉“坑”不小，她说：
- 你没有成本中心，你以后每个月的成本都要分摊给有成本中心的业务，而让那些业务负责人确认你的成本划入，是你需要进行的沟通工作，以及需要面临的挑战。
- 不要问你可以招多少人，你和你的团队（如果有的话），只要别人接受你们的成本，就都OK，这个要看你自己的本事了。
- 你不仅要把成本摊出去，可以的话，我希望你能成为BU的盈利增长点，成为服务解决方案的一部分，你要能把自己卖出去，把你的团队卖出去！
在这个背景下，我开始了自己的BP之旅；最初我分摊培训工作量的成本，用了一个算法，即基于培训产量的消费性分摊来进行这部分工作成本的划分，开始一段时间，每到月底的成本分摊邮件一发出去，就有成本中心的负责人来问：这你产量怎么计算的？ 为何我们会有这些产量？ 为何成本会那么多？
2年前我去这家公司的时候，1个人； 2年后，我离开这家公司的时候培训团队，我不算5个人！
我把培训作为解决方案卖给了客户，最初每次分摊成本，都会有人来质疑，后来我的分摊不会被人质疑，我说多少就多少！ 有几个月事情多懒得算了就均摊也没什么事 ：）
尤里奇的HR思想的核心：HR的价值是什么？
作为一个HR，你没有成本中心，就意味着别人要埋单你的成本！没人会平白无故滴买单成本COST，业务部门买单的是价值VALUE！ 你创造了什么样的价值，别人会Buy in？
价值是一种感知， 别人如何感知你的价值？这个过程需要用时间去换空间，用实践去积累信任！
HR没有成本中心，以及高度的“成本中心文化”，是好还是不好，这里不做讨论，但作为一种机制，的确逼着当时作为HR的我去思考HR的价值问题！What‘s the Right Things ？
熔炉点2：被投诉“不懂业务”
我入职的第一个月，就被一个同在一个BU下面的，汇报同一个老板的，来自Operation Function的Manager投诉了。她给老板写了封邮件，里面写道：
“Johnson是一个不错的HR，总体上比较优秀，但是，他完全不懂我们的业务！”
也不知道是有意识还是无意识，老板把这封邮件转给了我！那时候，我年轻气盛，暗暗告诉自己：我会证明我不仅懂业务，我真要懂起来，比你还懂！
当时比较多的学习行为是去看行业中最知名的媒体和教材，后来还尝试去投稿，自己在离开该公司（离开这个行业）1年里，陆续在这个行业的主流媒体上累计发表了文章21篇，将自己在这个行业中的实践方法论进行了分享！
之后3年内，每年都接到这个行业的主流论坛的演讲发言的邀请，只出席过一次，只为向那段岁月致敬！
那段时间，我做过一些PPT，会分享在百度文库里赚积分去下载文档，去年2次有人下载到了文档（6年前的作品了），联系我做这个行业的咨询项目！
一个HR要支持好业务，必须去学习业务，这个需要投入；实践的投入和学习的投入（都是时间的投入），在实践的过程中，让业务部门来感知所谓的“懂业务”！
很多人问我如何看待这个行业的人力资源管理，我说：太阳底下没有新鲜事，所谓的行业特殊性都是普世的方法论在实践中的应用，然后在细节上会有些操作技巧和特殊的情境。 这些细节的把握，需要投入！
一直都超级喜欢德鲁克的话：管理是实践！在实践中，我们去把握管理的关键变量！ 当你把关键点找出来了，能帮助业务团队解决问题了，别人当然能够感觉你的专业！
熔炉点3: 工作就是要“解决问题”
在BU里做培训，跟在职能属性的HR做培训，完全两种风景！我把培训分为两种目的：“营造氛围”和“解决问题”！
在职能属性的HR部门，很多时候我们的培训更多属于氛围导向；而在业务层，更多的培训活动属于解决问题！因为，老板会在业务发生问题的时候，让培训出面去解决！
加上“成本中心”的文化导向，这个挑战可想而知，你不解决问题，你怎么摊成本啊！这逼着我在那段时间，想明白了很多“基本面”的问题，看清了很多事情的本质！至今，我都会说，很多培训的价值观，都是在这个时期树立的。
在业务层面，做培训，我归纳为两个思维：
一个是Outside In，自外而内从业务问题看到培训目标；
另一个是Inside Out，自内而外从培训目标看到环紧系统；也在那个阶段，自己去看了很多绩效改进HPT／HPI的书。
熔炉之后的感悟：
三个熔炉点是自己这段BP旅程中体验印象最深刻的地方，现在回头反思，感觉它们对应的是作为HRBP的三个核心要素：价值创造，信任关系，专业技术，有交点，交点在实践中形成。
HRBP的使命是什么？ 我经历了这些熔炉之后，概括为：
以创造价值为理念和导向，基于我们的专业技术，在实践的过程中去积累我们的信任关系，从而和业务团队一起去创造更多的价值，从而形成价值的良性循环！
用一个模型概括如下：
让一个HRBP成长的，不是岁月，是经历，之后经历过熔炉版的经历，我们才能理解HRBP的精髓！
前不久一位朋友要做一个演讲，她问我我对于HRBP和传统HR的不同点是如何看的，我说，基本可以用一个词来概括，那就是member，In-Group member 还是 Out-group member。
很多时候在传统的function模式中间，HR扮演的是Out-group member角色，但一些公司里面，HRBP扮演的则是In-Group member角色。
也就是说，对于企业管理团队而言，他们把HRBP放到了什么位置上（但多数情况下，这个位置并不是HR可以通过努力寻求的），HRBP作为业务伙伴，对于业务的参与达到了什么样的程度，决定了这个HRBP的模式对于业务的帮助能有多大。
那么，既然HRBP是IN还是OUT的事情我们决定不了，就暂时不去讨论它。我们只讨论一下，当企业把HRBP定位在In-group member的情况下，HRBP是怎样看业务的呢？
我自己的经验是，看业务主要看三个方面：。
首先声明一点，以下案例来自于虚构的公司和人员，请勿对号入座。
1、商业模式：
案例：“云XX”红包业务逻辑HRBP是如何看的？
某公司决定在开放式智能手机开放平台中进行生态的构建。在当时还没有手机淘宝APP的情况下，开始尝试在这个平台上投放一款“云XX”APP，“云XX”自有的运营团队负责各种商品资源的接入，以及在手机端不断进行促销等活动，提升APP的用户使用粘度，打造一个移动互联网时代的新购物端口。公司对这个APP寄予了很大的期望，希望在移动互联网到来的时候，形成一个不同于淘宝PC端的新物种。
“云XX”采用1元购物、秒杀等活动促销方式，大概在团队组建2个月左右，就拿到了很漂亮的运营数据，包括商家接入、会员运营、活动策划、产品设计等等方面，这一业务也因此获得了高度的关注。
当时的业务会议中间，团队负责人反复在强调一个业务逻辑：目前的“云XX”在进行会员运营和活动运营的时候，是零成本的。
这一观点也获得团队成员的高度认同，以及公司高管的认同。但当HRBP在与业务团队的leader沟通中间，发现业务leader在反复强调一个观点：“云XX”的活动中，客户和商家都是获利的；……
那么，问题来了：APP是零成本的，客户和商家也都是盈利的……这可能么？我们画了下面的一个逻辑图：
那么，下一个问题来了：“云XX”的9元红包，有人买单吗？谁买单呢？HRBP走访当时公司财务负责人后，答案是公司的确在给“云XX”红包买单。
后来，在一次这个团队业务的会议上，HRBP作为这个团队的In-group member把这个问题提出来，同时团队把前面作出的红包发出规划和财务部提供的对比数据拿出来，经过计算，确认如果继续按照这一业务逻辑进行“云XX”红包业务的话，公司需要为此投入接近1.6亿元的成本。
会后HRBP把详细的分析给到HRBP老板，经HRBP团队向公司建议，最后公司决定撤销“云XX”业务。
实际的情况远比上述复杂，否则也不会那么多人没能第一时间找出成本的问题所在。但我想说的是，在这个案例中间，HRBP是作为集团战略助手的角色出现的，需要深入到业务的商业实现模式中间，从商业实现的角度来分析和判断业务逻辑，采集和验证必要的数据，从而帮助高层作出决策。
2、战略落地：业务思维转型HRBP是怎么敲边鼓的？
某“微公司”在从PC端向移动端做产品转型的时候面临一个尴尬的局面，公司不管如何转，产品都还带着原来的影子；公司后来决定大胆启用新人，从思路上跳出原来的模式，用移动化的思维重构现有以PC端逻辑为主的产品、找到产品和运营的突破点。
当时新老板刚刚履职不久，公司内部团队包括他从A分公司带过来的手机产品团队以及原来的“微公司”运营团队。
很快我们发现一个问题，我们HRBP团队所支持的原“微公司”团队总监们，总觉得弄不懂新老板在说什么，或者说在会议上他们总觉得自己已经完全明白了老板的意思，但一回来到工位上，就不知道自己要干啥……
HRBP们花了大量的时间和各个层面的人聊天，聊天中间就有人提出了这个问题，有人说这是由于A分公司和“微公司”的风格不同导致的，也有人说新老板更重视他从A分公司带来的团队，想要把“微公司”原来的人替换掉……
有点管理常识的人都知道这是胡话，但这一胡话的出现意味着这是一个严重管理危机。我们和老板的助理聊天，也验证了前面的问题，同时，她认为更加严重的是，“微公司”的总监们总是不能理解老板的意图，但老板的意图是什么呢？她也说不出来……问题似乎变成了一个无头绪的毛毛球，越来越严重，解决方案在哪里呢？
我们首先尝试组织会议，把来自两个分公司的总监和老板助理拉到一个会议室，罗列出来大家普遍觉得不满意的工作事项，逐项找出行动计划和里程碑；然后第二天的追踪发现，离开会议室后大家又觉得那天的讨论不够深入，拿出来的计划不可行……
我们再次尝试用背对背的方式做访谈和沟通，由HRBP单独找A分公司的总监、单独找“微公司”的总监、单独找老板助理，锁定大家觉得不满意的工作事项和问题……然后几天后的验证，仍然发现这个方式也不行，印象里那个时候由于反复挑战某一项工作，还导致了一个总监的情绪问题……这条路也行不通。
连续碰壁让我们不得不坐下来再次研究问题。我们面临的问题确实存在么？答案是肯定的；我们面临的问题可以定义吗？答案似乎是否定的；我们面临的问题可以罗列和衡量吗？答案是绝对否定的……
经过讨论，我们这个HRBP小团队决定更大胆一些，抛弃以往我们常见的管理学中间严谨的表格追踪式办法，改用不可衡量、不可定义的方法，同时我们的目标改成：人对了就什么都对了……
后面发生的事情听起来不太符合常理：经过和业务团队几名总监的讨论，大家同意在一段时间内总监们盲目信任我们，每天要完成HRBP的一个不合理要求，不问为什么的无条件完成。
是个什么要求呢？就是我们要求“微公司”的总监们，每天和老板说一句与工作无关的话，可以通过QQ，可以通过私信，可以通过邮件或者电话，但必须是与工作无关的，而且每天HRBP要检查作业；实在没话说，说一句“吃了么”也可以，但必须获得老板的回应，哪怕是“吃过了”……
经过大概也就一、两周的时间，从每天一句生硬的对话，到满屏的对话，到忽然有一天一个总监跑过来和我们说，我知道老板要的是什么了……
我们也不知道变化如何发生的……更神奇的是，我们当时就问他，你给我们说说老板想要的是什么？他居然很高兴的回答我们说，这个说不清楚的，但是我就是知道了。
那之前的问题呢？是因为老板没说清楚还是其他原因呢？他很开心的说，老板不用说清楚就是那么回事，谁也没办法说的很清楚的……然后没多久就有了新的产品和运营方式，新产品和方式不仅老板满意、业务团队也非常满意。
在这个事件事后让我沉思好久，业务是通过各种管理手段和方法把公司的战略落地来实现的，但如果这中间的确存在一些无法描述、无法定量衡量的内容的时候，我们该如何做？
近现代的管理学多数发端于工业文明出现后的时代，所有的内容都进行了细分和定量、评价，但中国古代的管理学是怎样的呢？中国的管理学似乎从来没有进行过细分和各种定量式的评价。所以呢，既然我们在中国，有一些问题我们可能真没必要进行细分和评价，面对说不清楚的业务战略，面对说不清楚的落地路径，从头到尾都不用弄清楚，所谓道可道非常道。
3、业务流程和协同：研发和产品的协同HRBP是如何看的？
移动互联网公司都会遇到一个问题，产品和研发之间总是有着说不清、道不明的牵扯与恩怨。微信里面总少不了研发对产品的各种吐槽，和产品对研发的各种无奈。段子我们总是能看得很开心，但如果实际工作中间遇到类似的问题，就不那么有趣了。
常见的移动互联网公司中，产品团队需要背负公司的线上收入的指标，因此，每个月都在绞尽脑汁不断寻找新收入的可能性，这就给研发团队带来一个问题：每个月产品都要更新，并且经常是更新到核心业务逻辑。
研发团队对产品性能直接负责，任何研发逻辑上的变动都牵一发动全身，能少做一个调整就尽量少做一个调整，任何调整都需要经过严谨的开发排期、测试后才能上线。简单的业务落地过程是这样的：
理想的情况就是：
每个功能都按照一定的软件版本周期排入计划，在不同的时间段完成研发测试并发布。现实中间却往往存在不能按时完成的情况，或者某一功能由于例如公司要求、实际业务时机的需要，进行发版时间的调整，从而对研发产生极大的压力。
在某家公司任职的时候，突然在一段时间内连续出现了几次研发小事故，我们和研发团队的负责人沟通，他觉得问题都在可控范围内，问题在于最近的节奏太快；研发团队内的同学们，普遍也觉得都还是胜任愉快的，只不过最近工作压力太大、太累，所有的问题都来自于在一段时间内连续出现了功能调整和发版调整，过了这段时间就会好了……
我们HRBP团队就团队这个问题和状态召集了一次讨论，我们私底下没有研发团队那么乐观，我们达成的共识是：
对于创业型的产品和研发团队来说，这种功能调整和发版调整预计会在很长一段时间成为常态，这段时间预计不会很快过去……
那么，如何解决功能调整、版本调整给团队带来的压力问题呢？等这段时间过去肯定不是办法。
通过头脑风暴，我们找到一个岗位，在传统的软件研发企业，通常会有一个岗位叫项目经理，后来有一些公司里面有一个角色叫版本管理，也有的公司把这个职责放在QC，也有的公司里面叫做PM，但他不是通常意义上的产品经理，是专门负责版本、功能、进度等协调工作的，他的工作角色相对于研发人员来讲，更加侧重人际，但他会非常理解研发的各种情况。
所以，HR团队决定给研发团队配备一个项目经理的角色，主要承担研发团队的节奏管理和进度沟通。但和研发head沟通，他并不看好这个岗位的设置；尤其是这个角色还会用到自己团队的人工成本预算的情况下。
HRBP决定不管大家的观点，从解决问题出发，先找人，再谈成本。经过一段时间的搜寻，HR锁定了候选人，团队Head和候选人沟通后，也觉得可以尝试一下。
然后就是这个人的到来迅速帮助团队解决了和产品团队之间的协同问题，并把研发团队中间大量消耗管理人员时间的业务追踪工作承担起来。我离职之后，还接到研发Head的电话，特别谈到这个岗位的锁定，帮助团队解决了大问题。
每个人都有每个人的经验，最有趣的就是，在不同的公司由于构成业务团队的人是具备不同经验和不同背景的，这些不同会给我们带来非常有意思的、也许是让人眼前一亮的成果。
不要被公司的组织结构图束缚住，也不要被一个个岗位的名称束缚住，用心去感受业务的难点和需求，一定会有一个适合你们的业务解决方案在那里等着你。
好像有谁说过，HRBP是水，业务是骨肉。如果我们真心把自己当成是In-group member的水，就要记得，中国的古话说的是：兵无常势水无常态。把自己融到业务里面去，变成业务里面的水，随时补充到需要的地方。
再次强调一下：出于保护个人隐私和企业商业秘密需要，以上均为虚构的企业和人员；文中观点是作者本人观点，仅供参考。欢迎就HRBP工作内容共享交流，共同进步，本人不对非HRBP业务部分的工作内容发表任何意见。
你认为做HRBP不容易在哪？
(来源：SOHU)
京公网安备 110105001605号