职位和岗位概念辨析及在HR管理中的应用

摘要:我的老公众号曾经写过一篇文章谈“职位”和“岗位”的区别，这两个概念在有些情境下混用有其合理性，但的确是两个不同概念，在企业HR管理体系中发挥不同的作用。相当多管理者和HR工作者对这两个概念是不清晰的，以下抛砖引玉，跟业界朋友探讨。首先明确，为

我的老公众号曾经写过一篇文章谈“职位”和“岗位”的区别，这两个概念在有些情境下混用有其合理性，但的确是两个不同概念，在企业HR管理体系中发挥不同的作用。相当多管理者和HR工作者对这两个概念是不清晰的，以下抛砖引玉，跟业界朋友探讨。

首先明确，为统一起见，本文以下将Job称为“职位”，将position称为“岗位”。在不少HR知识体系中（例如我反复阅读的主流HR管理和工业组织心理学教材）并不太强调Position的概念，主要内容都是围绕着Job展开的，所以，“职位”、“岗位”概念的区分，也许是个伪问题；但是，在HR管理实践中，这个概念区分却是客观存在的。Job和Position的使用或者翻译在不同场合也五花八门，歧义甚多，例如在PeopleSoft中文版中，将Job称为“职务”，将Position称为“职位”；又例如有些大公司HR术语体系中，不用Job，而用Position这个词表示职位的意思；HR咨询公司和企业用于薪酬决策而开展的、基于计点法的职位价值评估，有些叫Job Evaluation，有些叫Position Evaluation，他们评的对象究竟是一回事吗？

事实上，不少国外组织对这两个概念是清楚定义的。例如下图是某大学的定义，里面提到，虽然这两个概念经常互换使用，主要区别是：

job是关键职责的集合，包括干什么工作，需要什么样的知识、技能，绩效衡量标准是什么，职位评估通过参考市场同类职位付薪水平来决定企业的薪水等级；
Position对每个员工是一一对应的，用来做预算和发薪记账（注意，job对应薪水等级，例如薪级区间10-13万元是记到一个job上，而Position上记录的是这个Position具体薪水是多少，例如12.5万元），也记录这个员工更详细的工作职责（注意：这可以对应到我们常用的管理术语中，“职位描述”跟Job相关，而“岗位职责”跟Position相关）。

企业究竟有哪些职位，职位的定义是什么，并对职位进行归类，这是职位分析（Job analysis）的过程。职位分析是对企业的“工作”[比岗位和职位更小的“工作单元”是任务（Task）] 进行编码的过程。区分并定义一个职位，从区别性和颗粒度来说，需要服从管理目的，并没有一定之规。这个原理非常象做ERP对物料进行编码，编码规则制定需要考虑到库存、财务、成本、生产计划等诸多因素，例如有两种物料，外观、性能完全一样，在生产上可以互相替换，但是供应商不同、采购价格不同，这算是一个物料（一个编码），还是两个不同的物料（两个编码），ERP应用上，这两种做法都可以处理，但是在库存价值评估、库存、采购等业务流程上就会有所区别。企业职位分析的管理目的很多，传统上是薪酬管理，而现在越来越多用于人才发展，即每一职位的任职资格、绩效标准和职业发展路径，例如同样软件工程师，做Java技术的软件工程师和做.Net技术的软件工程师工作性质都是一样的，只是技能、任务不同，算是一个职位还是两个职位？如果是大型软件开发组织，付薪水平、职业发展有较大差别，也许可以分成两个职位，如果是综合性信息技术公司，在付薪水平和职业发展上区别不大，就没必要分成两个了。

对job和Position的辨析，有三个来源：

一、学术规范：

职位分析在工业和组织心理学的学术上有一套规范（如下图），在现实中，很少有企业或者HR咨询项目会按照这种方式进行职位分析。这是一种在组织内由下往上的做法，就像画一棵树，先画叶子，后画树枝，最后画树干，即先分析有哪些职位（类似的工作组合），分解这些职位上的具体任务（Task），然后对职位进行归类，这种方式从效率、成本上来说都不太可行。

主流的HR教材使用如下的职位分类术语：

二、企业实践：

根据我自己的经验，大多数HR咨询项目做职位分析是在组织内由上往下分解的，大致逻辑是根据业务战略、业务类型和业务价值链，确定职位的第一级分类（通常叫“职类”），即先画树干；然后考虑到与战略匹配的组织能力要求以及实际各部门的工作情况，设计第二级分类（通常叫“序列”），一些复杂的组织也许还要设计“子序列”，即再画树枝；最后在序列之下，结合职级（Job grade或Job level），确定各个Job，即“叶子”。这种做法是跟学术化的JA方法反过来的，更直观、便于操作。

这种方式之下，做一个职位的区分和确定时，通常有两种做法：一是“职位=序列X职级”，例如：管理咨询顾问序列、职级第八级，则“八级管理咨询顾问”就是一个职位，一个企业如果有60个序列，7个职级的话，则总Job数不会多于60X7=420个，只要序列和职级架构不变，不会创建新的job code；二是部分结合对具体工作的定义，先从上到下定义序列框架，又具体定义一个职位，再归类到一个“序列X职级”之下，这种情况下，即使序列/职级架构不变，企业仍然可以随时创建新的Job Code，并且将其归类到一个序列和职级之下。

在我的职业经历中，我工作过的几家大型外企采用的是第一种做法，例如八级管理咨询顾问（job title是管理咨询经理），无论是从事战略咨询或者人力资源咨询工作，即使在招聘等环节，可能会有不同的“职位描述”，但是job code其实是一样的。而广受关注的华为职位体系，看起来是采用前述第二种方法：

三、先进HR信息系统

SAP、Peoplesoft这些系统本身蕴含了管理哲理，也反映了不少大型跨国公司的实践，因为必须落地使用，通过信息系统定义的概念更为严谨。以传统SAP HR为例，职位（Job）是指一组任务的工作集合。[Jobs are general classifications of tasks that are routinely performed together]；岗位（Position）：每一组织单元（组织结构每一层级）上的“位子”。[Positions are the individual employee assignment in the enterprise. Positions are occupied by persons]. Job和Position的关系是：

一个Job有若干个Position ；
Position承继了所属Job的所有Task，也可以为Position另外指定Task（这也体现了信息系统的学术渊源，不过很少有企业会从下往上进行职位分析，所以很少有企业使用Task功能）
组织单元之间的关系是汇报关系，position属于组织单元
Position（而不是Job）由员工持有，由员工持有；原则上一个Position上是一个员工，少数情况下有多人兼岗，或岗位空缺；
人是通过Position跟Job以及OU建立联系的（Position是SAP HR系统中OM组织管理和PA人事管理的桥梁）
成本中心被分配到Position（及组织单元）上

这种关系体现了SAP的严谨性。早期的SAP HR没有职位分类体系，近些年，SAP HR新推出的TM人才管理模块，提供了功能范围、职位族等两级职位分类，并且提供了能力素质（Competency）对象，可以赋予到不同的职位层级，形成这个层级的职位剖象，即能力要素和任职资格。

PeopleSoft不愧于从诞生开始就定位于“人力资本管理软件”，提供了从job function到position的五级分类，这个分类模式非常接近华为的做法。它的Position和Job两者的基本概念定义，PeopleSoft和SAP是类似的（也会细到基本没人用的Task），但是在人与job/position连接的关系上，PeopleSoft要灵活很多。它既可以象SAP那样严谨，人属于position, position属于组织单元并被job定义；也可以不启用position，人直接属于Job以及组织单元，适合于流动性较大，经常因人设岗的企业，或者人员管理相对较为粗放的企业（这可能是中国大多数互联网公司HR信息系统选择使用PeopleSoft的原因）；一个企业组织中，这两种人和职位关系的模式还可以混合使用。

PeopleSoft通过Profile Management建立职位属性的层级关系（Hierarchy），下级承继上级的属性及属性内容，最典型的属性就是能力素质（competency），作为这个职位或这类职位的任职资格。这种承继关系，PeopleSoft里叫Syndication，SAP里叫Inherent。