和勤人力洞察作品
（全文5200字）
中后台部门人效衡量是个难题，通常认为的原因在于中后台部门的产出很难量化衡量，也很难像前台部门那样有明确的财务数据。这与中后台部门的绩效管理存在较高难度的原因是相似的。
那么，在这种情况下，我们应当如何对中后台实施有效的人效管理呢？
01
跳出自设的逻辑陷阱，从根本点上重新思考
很多人感到中后台人效管理难度大，有如下几方面原因，我们逐一分析：
（一）中后台部门工作难以或无法衡量
有一句话，叫做“如果不能衡量，就无法管理”。德鲁克这句话本身没有问题，但总是在理解上会产生歧见。常见的两个倾向，一是绝对化，二是短期化。
所谓绝对化，就是“衡量”必须通过财务量化指标，如果做不到这一点，那就是“不能衡量”。而企业是一个系统，最终才表现为财务产出，而系统运作的各个环节和过程，并非都能有直接的财务产出。因此，要全面理解可衡量，其含义不仅仅是财务角度的衡量，还有各种非财务角度。
所谓短期化，就是要求在短期内进行衡量。有些中后台工作在短期内无法衡量，这是由不同类型工作发挥作用的机制和周期所决定的。但如果我们将时间周期适当加长，就可以发现，很多工作的可衡量性增强了。比如，从1年或者半年的周期而不是按月度，对人力部门考察关键岗位空缺时间、人才适配度、继任人选准备度等指标，可以非常清楚地看到人力部门的工作成效。
（二）中后台人效衡量具有很强的相对性
越是深入到不同企业，越是会发现人效衡量的相对性，即不同行业、企业发展阶段、业务模式、技术条件、管理机制等各种因素都会对人效产生深刻影响。因此，不同企业之间的人效比较需要特别注意这些差异，需要仔细鉴别是否具有可比性。
而其中，中后台人效的比较，相较于企业总体人效和业务一线的人效来说，受前述因素影响更大、相对性更强，需要更加注意。
当然，不管怎样的差异，即使完全不同两家企业，也可以进行投入产出效率的比较，否则不同上市公司的投资价值就无法比较了。但是，这种“终极”比较的最大问题是，通过比较看到了差距，但是却难以找到改善的切入点。
（三）人效管理的核心在于人效提升，人效衡量也是过程
我们应当将人效管理的注意力放到提升上，而不仅仅是衡量，从根本上来说，人效衡量仍然是手段，人效提升才是根本目的。
因此，不要止步于人效的精确衡量，更要着眼于人效提升；更不要停留于对某一局部人效的衡量，要着眼于整个系统的人效提升。可能存在一种极端的情况，从某一局部看起来人工成本增加了，但如果从整个系统来看，人效却提升了。中后台在一定程度上即具有这种特征。
02
回归中后台的本质来谈中后台人效
企业中后台的发育程度是企业组织成熟度的标志，企业组织都是从业务部门开始逐渐扩展的，最开始可能根本没有中后台职能部门；而随着企业发展，越来越认识到职能体系对业务的支撑作用，才逐渐分化和发展出职能部门。可见，中后台从产生之日起，就不是与市场直接发生交易关系，而是作为一线业务部门的支撑而存在的。
因此，如果过度孤立地强调中后台的人效，极有可能产生的一个不利的后果，就是割裂组织整体的系统性、削弱组织总体效能。
正如我们看到的一些企业实施的破碎式的降本增效，给每个部门和业务环节都设立了一定比例的降本目标，短期内可能达成了成本下降的目标，而从长期来看，恰恰会降低产出效率。这种孤立地衡量中后台人效的方式，实际上与这种“破碎式基本增效”之间，只是“五十步笑一百步”的关系。
我们仍然要坚持从系统的视角、更全面地看待中后台的人效问题。
03
中后台部门的人效衡量思路和指标
当然，前面所说的各项内容，并不是说中后台不需要衡量人效，而是说要从系统的角度来看待这个问题。具体来说，中后台的人效应当如何衡量呢？
（一）首要的是结构合理。对于一个发育健全的组织来说，中后台规模和人工成本绝非越小越好，而是与前台保持合理的比例结构，才是最佳状态。因此，首先应当建立与业务规模适配的中后台，也就是说，中后台、前台部门以及中后台各部门之间，在人数、人工成本的比例上，保持合理的结构。
至于相互之间各自的比例关系到底是多少才是合理的，恐怕很难找到一个公认的数字，因为企业之间存在很大差异，在企业的不同发展阶段也会表现出较大的不同。
有人将中后台部门人员、人工成本占比称为“组织体脂率”，这种说法非常形象，但是需要注意，一定的体脂率是必要的、健康的，只有过高的体脂率才是问题。
因此，现实可行的标准主要来自于如下方面：一是自身的纵向比较，无论是人数还是人工成本，都不应当在短期内快速增长，除非有特定的任务目标、管理变革等可以做出合理性解释；二是就中后台部门对前端业务的支撑作用是否有力，进行定性评估。
（二）其次是不断地效能提升。中后台部门需要不断地提升效能，具体的衡量方式主要是如下方面：
一是中后台部门直接业务产出。请注意，这里要使用各部门直接业务产出来进行衡量，比如新入职人员数量，就是衡量人力招聘团队的重要指标，当然如果精细化的话，需要对不同职级人员分别统计或者计算工作当量，比如利用新入职人员薪酬总额除以企业平均薪酬所得到的比率来计算新入职人员工作当量。很多中后台工作都可以找到类似的指标。
二是中后台部门支撑的业务规模。比如常用的人力资源服务比，即HR与企业人员总量之间的比值，为了计算精确也发展出了全时当量的概念，将非全时工作人员也折算为全时。再如，有企业会使用研发团队所支撑的产品营收规模作为衡量不同产品线研发团队人效的指标，但影响产品营收的因素太多，只能作为相对的衡量指标。
三是业务流程效率。即针对中后台部门所掌控的业务流程的效率进行具体衡量，如岗位空缺填补平均时间可以作为衡量招聘产出效率的重要方式，再如招聘漏斗实际上就是对业务效率的重要衡量方式。
（三）再次是胜任度评估。对于中后台部门，最关键的是支撑业务的能力，只有对前端业务提供有效的支撑，才能够提升业务效率和规模，从而提高企业整体效能。因此，应当注意对中后台部门的胜任度评估。
具体来说，要从业务需要和企业下一阶段发展要求的角度出发，明确对中后台各部门的能力要求。 比如，企业下一阶段要进行新区域拓展，除了业务部门要制定相应业务计划外，中后台部门也必须从组织架构设置、人员招聘、考勤管理、绩效和薪酬、信息系统、周报日报、资金汇总、财务审批等一系列方面提供支持、建立体系，从而为更大规模的区域拓展提供保障。 也就是说，企业要围绕业务发展所需的能力，对各部门的胜任力进行评估。 |
（四）再次针对业务瓶颈做专项提升。通过胜任度评估，就可以发现中后台需要改善或提升的方面，将这些问题解决就可以提升整体业务效率，这是瓶颈管理理论和实践所证明的。
（五）特定部门的豁免。在对中后台人效进行管理的时候，要注意对一些特殊性质部门予以豁免，比如审计监察部门。这类部门与其他部门不同，即其工作产出不能以高低来衡量，而主要与组织对该项工作的判断和期望有关，因此重点是做好适当投入，明确工作重点即可。
04
中后台的人效衡量与提升思路，以某企业科技部门为例
下面以某企业中后台的科技部门为例，具体做一分析：
（一）基本情况
随着业务线上化、企业数据安全、合规监管等一系列要求越来越高，该企业科技部门逐渐发展、规模日益扩大。但随之而来的则是企业对科技部门人效的关注度越来越高，科技部门的人员规模是否合理成为各方关心的问题。
该企业科技部门的主要工作是以信息化技术开发APP应用和维护业务系统，以服务前端业务。怎样才能够对科技部门的人效进行有效测量呢？于是想到了常用的代码量、BUG率等指标，希望能够利用诸如人均代码量、千行代码BUG率等对科技团队人效进行度量。
但是，科技部门的HRBP又感觉不对劲儿，于是我们有了一次沟通讨论。
（二）问题分析
从我曾经的产品经理经验来说，代码量和BUG率当然都能够在一定程度上说明工作数量和质量，但并没有抓住科技部门的关键产出。那么什么才是科技部门的关键产出呢？以该企业某个APP功能的改版来说，其关键产出应当是该APP改版后相较于之前客户点击量、停留时间等指标的改善，进而影响到业务转化率和复购率的提升，并最终作用到相应业务收入的增长上来。这才是APP的改版的最终产出。
那么接下来的问题是，业务部门和科技部门之间的分工界面在哪里，决定了如上述分析中科技部门的产出应该定位在何种程度上。比如，业务部门只提出大概的需求，科技部门负责具体实现方案的设计和编码实现；还是业务部门直接提出非常具体的功能要求，科技团队只负责具体的编码实现。很显然，如果是前者，科技部门应当对客户点击、停留时间负责；而如果是后者，科技部门只能对相应功能的实现负责，即更加偏重技术性能。
的确，这家企业也出现了业务部门和科技部门之间一定程度的“冲突”，业务部门并不了解信息技术，虽然要求十分具体，但往往脱离实际；再加上业务和科技之间“语言”上的障碍，导致需求经常变动、调整，双方互不买账。业务部门认为科技部门不懂业务，科技部门认为业务部门瞎指挥、想法变来变去。
（三）基本解决建议
到底应该怎么办呢？我认为这种情况下，根本不应当将人效衡量置于突出位置，而应当进一步理顺组织和流程。所谓理顺组织，重点是明确职责界面、调整职位设置和人员配置；在流程上，则需要在职责界面清晰、岗位设置和人员配置完备的基础上，梳理完善开发业务流程。
理顺组织 | 1.职责界面：（1）科技部门要与业务部门共同梳理确认业务需求，明确调整后的业务目标；（2）在此基础上，科技部门提出解决方案，制作系统原型，提交业务部门确认，再进入系统开发。职责界面清晰化，避免业务去做不擅长的产品设计，集中在业务需求明确上。 2.组织与职位设置：组织模式上，存在两种方式（1）为不同的业务部门配置专属技术团队，承接相应业务；（2）采用项目制，根据业务部门需要临时组成包括产品、前后端和测试工程师的项目组。 对于业务需求较多和较重要的业务，可采用方式（1），提供专属服务，同时提高产品发展的连续性，提供持续迭代和运维服务；对于一般业务，可采用方式（2），根据需要组织人员。 在职位设置上，（1）针对重点产品设置固定的产品经理，保证产品的持续性和思路的统一性；（2）加强项目经理的业务需求边界管理职责，避免陷入需求不清、随意更改的怪圈；（3）加强基础平台管理能力，逐步统一开发规范，增强标准组件复用性和代码规范性。 3.人员配置：从现有项目经理中选拔1名产品经理，作为试点，成熟后逐步推广。 |
完善流程 | 1.开发流程优化：建立包括业务需求、需求确认、需求分析、概要设计、详细设计与确认、代码开发、系统测试、试上线、正式上线的业务流程。 2.数据记录提升：在前述过程中，要做好各阶段关键节点数据的记录，特别是业务需求概要、需求规格说明书、系统DEMO、测试用例，并记录计划工时、实际工时、需求变更及导致的新增工时、测试缺陷及其分级（如高中低）、分类（按原因分类如需求缺陷、设计缺陷、编码缺陷、测试缺陷等；按性质分类如功能缺陷、性能缺陷、体验缺陷、安全缺陷、兼容性缺陷等），记录缺陷处理结果（如不修复、未修复、已修复）和相应处理时间。 |
工作平台 | 引进和完善开发管理平台，如阿里云效、禅道或其他平台，并根据自身业务需要进行配置。 |
（四）持续跟踪优化
在前述工作的基础上，可以逐步推进开发相关统计分析，从而为人效分析和提升提供更多的数据基础：
1.科技部门内部运营分析
（1）工时分析：对计划工时和实际工时进行比较分析，还要深入到各业务功能及其责任人进行分析；对每个员工的工时利用率进行分析；对业务需求变更导致的工时增加进行分析。
（2）缺陷分析：对缺陷等级、类别和所属人员、业务功能进行交叉分析；对缺陷消除结果及其处理时间进行分析。
（3）通过缺陷分析对开发各阶段的工作质量进行分析，如需求缺陷过多显然是因为与业务部门的需求沟通存在问题，这就是提升效率的关键。
（4）人员分析：从人员角度对工时利用率、工作完成及时性、缺陷数量及其处理时间、合理化建议数量等进行分析，从而可以清晰地看到具体人员的工作质量和能力。
2.科技部门直接产出分析
重点对业务功能是否达成了当初提出需求时的目标进行分析，比如解决性能问题、解决点击路径问题、停留时间等等，这些都可以通过系统后台数据清晰地看到。
3.科技部门业务支撑分析
重点分析产品改版上线后是否达成了业务部门的目标，如点击量、业务转化率等。这个层面受到多方面因素影响，因此只能作为重要的参考。
人效分析的目的是为了发现问题从而进行针对性的改善。作为提供业务支撑的中后台部门，对其人效管理的着眼点更应当着力在组织优化、人员配置、流程改善、技术提升等方面，促进中后台人效的持续提升。当然，也必须看到，数据在总后台人效提升中的重要作用，数据体现了业务的结构化程度，通过数据可以找到人效改善的切入点。