员工的汇报关系是HR系统中一个重要的关系，用于很多的流程和业务处理，例如：

1）用于HR流程审批，如休假申请审批、加班申请审批、员工调配审批；

2）用于HR业务处理，如上级经理对下属员工的绩效考核、奖金的分配，根据员工汇报关系可以提取一个经理的所有直接下级员工做处理：绩效评分或者分配绩效奖金；

3）用于查询，如上级经理查询直接和间接汇报给自己的下属员工信息；

4）用于报表分析和统计，如在员工花名册中列示员工的直接上级经理和再上一级经理，统计每个员工的直接下属人数，统计一个机构下每位经理的平均直接下属人数（控制范围）

       如何在HR系统中搭建员工汇报关系模型，从而达到数据维护方便、简单，数据维护工作量小，而且便于读取、使用和理解，是一个值得深入探讨的话题。

      综合起来，主要有以下几种建模方式：

       对于一职位一人的系统，可以直接按职位搭建职位的汇报关系，通过职位找到职位的任职人，然后生成员工的汇报关系。比如SAP  ＨＣＭ系统就可以这样去搭建。

      如果有员工除了主要职位外，还有一到多个兼职职位，此时员工就处在几条汇报关系链中，系统仍然可以正确处理。

　　对于一岗位多人的系统，如果对于管理岗位是单独建立的，也可以使用按岗位搭建汇报关系方法，最后生成员工的汇报关系。这里有几个前提条件：

　　１）如果HR部门有一个经理，两个副经理，若干个其他下属岗位，如薪酬管理岗、培训管理岗位、招聘管理岗位和考核管理岗，如果副经理和其他下属岗位都是汇报给经理岗位，则可以建一个经理岗位，一个副经理岗位，薪酬管理岗、培训管理岗、招聘管理岗、考核管理岗各一个。经理岗位上一位任职者，副经理岗位上有两位任职者，薪酬管理岗、培训管理岗、招聘管理岗、考核管理岗分别有一到多个任职者。

　　　此时，可以搭建如下的岗位汇报关系：

　　

　

　　２）如果是薪酬管理岗和考核管理岗汇报给一位HR副经理，培训管理岗和招聘管理岗汇报给另一位HR副经理，则需要建立两个HR副经理岗位，此时，可以搭建如下的岗位汇报关系：

   　

　　此时，已经不是严格意义上的一岗多人，其实是一个混合型方案，也就是一些岗位是一岗多人，一些岗位是一岗一人，特别是管理岗位，也就是通俗意义上管人的岗位（People Manager），一般需要按一岗一人建模。

       当然，如果把HR副经理１岗位叫做薪酬考核副经理，把HR副经理2岗位叫做招聘培训副经理，也可以认为是严格意义上的一岗一人，但HR经理、薪酬考核副经理、招聘培训副经理岗位均只能有一位任职者，否则，下属员工汇报的 上级就不唯一。

        总体原则，有下属汇报的管理岗位一定是一岗一人，没有下属汇报的岗位可以是一岗多人。

　　 岗位汇报关系建模如下：

        
                                                                 

     使用岗位去搭建汇报关系，优点在于：

      1）日常有人事变动的时候数据维护量少，只有在有新增岗位、撤销岗位、岗位汇报关系变动的时候才需要维护系统；如果是员工入职、调动（岗位变动、兼职）和离职时，不需要因为汇报关系维护系统；

      2）反映了企业人力资源管理中基于岗位管理的管理思维，不是基于人去管理。

     而这种方法的缺点是：和基于员工直接搭建汇报关系相比，需要通过岗位的汇报关系中的岗位读取到任职者才能生成员共的汇报关系，逻辑上似乎绕了一道弯子，但因为是用程序去自动读取和处理，用户感觉不到后面的处理逻辑。对于一岗多人的情形，对管理岗位可能需要拆分为一岗一人，否则难以反映企业的实际汇报关系。

     

       如果给部门（单位）定义了负责职位（岗位），也可以通过这个关系生成员工的汇报关系。生成算法：

       1）部门的所有直接下属岗位汇报给部门的负责岗位；

       2）部门的负责岗位汇报给部门的直接上级部门的负责岗位；

      但前提条件是一个部门（单位）只能分配一个负责职位，而且该部门的所有直接隶属岗位的任职者都汇报给负责岗位的任职者。

       还是以上述的HR部门为例，如果指定HR经理岗是HR部门的负责岗位，如果下属HR部门的下属所有岗位的任职者都是汇报给HR经理，则可以使用部门负责岗位关系生成员工的汇报关系。如果说薪酬管理岗和考核管理岗汇报给酬考核副经理，招聘管理岗和培训管理岗汇报给招聘培训副经理，就不能使用负责岗位关系生成员工的汇报关系。

       如果只把HR经理指定为HR部门的负责岗位，这时候薪酬考核副经理、招聘培训副经理和薪酬管理岗、考核管理岗、招聘管理岗和培训管理岗都是汇报给HR经理，反映不出来薪酬管理岗、考核管理岗汇报给薪酬考核副经理、招聘管理岗和培训管理岗汇报给招聘培训副经理的关系。

     如果只把HR经理、薪酬考核副经理和招聘培训副经理都指定为HR部门的负责岗位，一方面薪酬管理岗、考核管理岗、招聘管理岗、培训管理岗就有三个上级汇报岗位，而且也体现不出来薪酬考核副经理和招聘培训副经理汇报给HR经理的关系。而且只有HR经理汇报给公司总经理的关系有问题，变成HR经理、薪酬考核副经理和招聘培训副经理都汇报给公司总经理。

      因此这种方式的使用有局限性，只能适合于一些部门和岗位设置简单、汇报关系清晰的业务情景：如

     1）每个部门只有一个负责岗位；

     2）该部门的所有直接隶属岗位的任职者都汇报给部门负责岗位的任职者；

     3）部门负责岗位如果没有任职者， 可以默认是用该部门的直接上级部门的负责岗位的任职者为汇报人；也可以临时指定一个其他平级部门的岗位为该部门的负责岗位，也就是支持岗位的跨部门负责。

      此种建模方式的优点是： 数据维护量最小，不论是上线时的数据导入，还是日常的数据运维。主要包括：

      1）部门负责岗位的指定；

      2）跨部门临时负责岗位的指定。

       直接通过员工搭建汇报关系，这个是最直接的，但汇报关系搭建和维护的工作量大，

      1）系统上线时的汇报关系整理和初始化导入；

      2）有员工入职、调动、离职的时候需要维护；

      3）如果有经理入职、调动、离职的时候要维护和变动的数据更多；

      还要考虑是否保持汇报关系的历史数据，还是指保存最新数据，如果历史数据不保存，查询报表的历史数据的时候，员工的上级和上上级经理的信息可能变得不正确。

      如果员工有两个上级，一个直接上级 ，一个间接上级，使用这种方法，就需要记录两个上级，一个直接上级员工，一个间接上级员工，后者可以有也可以没有。  

      在输出汇报关系图的时候，可以使用直接汇报关系，可以使用间接汇报关系。

   

4、除了以上三种方案，还有一种方案混合方案

    1） 汇报关系使用方法1或者2构建；

    2）使用一个自动处理工具程序，自动生成员工的汇报关系库，也就是方法3） 的维护结果，这样员工的实际汇报关系在数据库中存放，当不需要手工维护，而是系统通过岗位间的汇报关系或者部门的负责岗位关系生成的。 

    3） 这个程序可以调度为后台作业，每天晚上运行，自动生成员工汇报关系库；但是如果是员工在当日上午和下午发生入职、异动、离职等人事调配活动，需要等到晚上运行工具程序的时候才能同步员工汇报关系库。

    4） 一种可行解决办法是在发生入职、异动、离职等人事调配活动的时候，自动同步受影响的员工到员工汇报关系库，或者手工针对发生人事变动的员工运行上述工具程序。

    5） 员工汇报关系库的表结构如下表所示：