本文将从人力资源系统的最基础模块——组织架构入手，结合企业管理过程中的实际案例由浅入深设计相关的产品方案。希望读完本文之后，可以让你对企业的正常运转有更深的认识。

企业运转的基础是合规合法注册公司，再根据公司经营目标拆分部门，根据各部门内的岗位编制招聘对应的人员，这样就完成了初步的组织架构搭建，即“公司-部门-人员”的数据关系。

企业组织架构的调整通常意味着公司发展规划的调整，例如腾讯在2018年9月30日完成的重大组织架构调整，这次调整把之前的 7 大事业群业务进行了重组，新增了云与智慧产业事业群（CSIG）和平台与内容事业群（PCG）。除此之外，腾讯还首次对外宣布成立技术委员会。

图 腾讯930组织架构调整

一、公司管理

集团型公司经常会因为业务需要、税收优惠等原因注册相关经营范围的公司，对于中小型企业来说，主体公司通常只有一个。本文主要是针对集团型多公司多部门场景设计相关​产品方案。​

图 公司信息

人力资源系统内先将公司信息作为基础资料维护，并作为底层数据对公司内部其他相关系统提供数据接口，比如员工劳动合同会涉及到甲方公司信息、财务报销会涉及到费用发生公司、资金统计时需要将资金归集到对应公司下。

公司相关的开立、变更、注销都是由人力资源系统内部统一维护，并对外提供标准服务。PS：​但这里可能会出现公司在6月初注销，但6月底还需要将6月发生的费用入账，故在设计各系统之间数据交互时要根据实际场景而定。

注意：这也是中台系统设计的思路，即不断下沉通用性、可复用的部分，将系统之间解耦，减少独立维护，重复开发的成本，相对于单独设计一套中台系统，中后台产品经理更多的时候是应用中台产品的设计思路到​不同量级的需求中去。​

公司简称：主要是为了沟通和后台系统展示，比如人人都是产品经理的备案公司是“深圳聚力创想信息科技有限公司”，全称展示的话会让本来就拥挤的页面空间更加紧张，所以简写为“深圳聚力”就会好很多。

公司编码：为每一个公司设置一个唯一标识，可以直接使用对应记录的主键ID，也可以使用一定的规则，例如“GS001”，便于系统之间做数据交互。

法人姓名、注册地址、统一社会信用代码属于公司的基本信息，是否需要取决于企业内部管理需求。

经营地址：即企业实际办公地址，对于分散的企业而言也可以作为员工考勤打卡的地址，可能有多个等情况。

编制人数、在岗人数主要是公司人力资源管理作用，可以为企业决策者提供直观的数据支持。

上级公司：主要是为了建立集团旗下各公司间的母子关系，甚至相关的控股比例等，同样是为企业决策者提供数据支持。

原型示例-新增公司

二、部门管理

图 部门管理

企业内部的部门管理相对于公司管理就复杂而繁琐得多，部门之间的结构都是采用树形，即每一条部门记录本身都有一个id和一个pid，其pid又对应其其父级id。例如：『产品部』的id为3，pid为1，其子部门『app产品部』的id为5，pid为3，这样通过pid与id关联就建立了父子级部门关系。

图 父子级关系

部门级别：根据企业规模设置级别，例如事业群为一级部门，小组为五级部门，中间还有事业部、中心、部门等层级结构。切记不要用部门有几层父级来计算其本身属于几级。

上级部门：即选择父级部门，建立id与pid之间的关系。

部门名称、部门排重名：即部门的名称，公司内可能存在重名的部门，例如A和B部门下都有测试部，这个时候就需要增加字母之类的方式区分开每一个部门，非必要，主要取决于业务需要。

原型示例-新增部门

当部门之间的父子级关系建立完成、各部门的排序、部门负责人无误之后，整体展示如下图所示：

图源：Edraw

一般来说人员之间的汇报关系需要单独维护，而不是直接使用各部门的负责人。在部门管理过程中可能会存在一个部门下部门经理拆分为两个小组分别管理，但是小组关系并没有体现在架构上，所以直接使用部门负责人时难以满足此种灵活调配等场景，当然具体情况需要根据企业需求而定。

当架构信息更新后还需要及时通知到相关业务系统、及时通讯工具等，例如部分企业是在自研系统内完整组织架构调整，就需要及时通知到对应的企业微信、钉钉、邮箱群组等第三方平台。

详见：企业微信-部门数据接口

部门数据的应用场景很多，而且部门架构也是公司战略方向的体现，所以有部分公司（尤其是高速发展的公司）会将架构信息做为机密数据，只有指定员工才能看到完整的架构信息，所以在设计时还要根据企业需要，考虑架构信息的数据安全方案。

三、岗位管理

图 岗位管理

企业经营过程中会对不同的工种做划分，根据企业要求会出现不同细化程度的分级、分类。

主要会应用于人力统计、招聘信息发布等场景。相对完善的企业内部会有一套完整的岗位配置，不同的职类职群对应了该岗位下的晋升路线，例如：初级产品经理P6-高级产品经理P7-资深产品经理P8。

HR会根据公司的战略规划，为不同的业务设定不同的部门并配置相应的岗位。例如：A公司计划开展区块链业务，那么会先注册区块链相关经营范围的公司（XX区块链公司）、同时设立相关的部门（市场部、产品部、技术部），再配置相应的岗位（市场经理*1，产品经理*2，研发工程师*6），制定不同的岗位需求、工作内容，再发出招聘需求，从而将公司的战略逐步拆分至实施的人员。

四、群组管理

图 群组管理

群组主要是针对公司内部非实际行政架构的组织，与部门内管理有相似部分，大部分EHR系统不会单独设立此模块。例如腾讯930宣布成立了『技术委员会』，其中的人员可能都是各个事业群内的技术管理人员，平时有部门内的工作内容，在涉及到重大技术变更时，需要『技术委员会』的人员参与决策。

例如：大佬A本身担任区块链项目总负责人，也担任公司的「创意设计委员会」的委员。前者是实际的部门归属，后者只是“名义”上的职位。

除了可以支持委员会之类的数据维护以外，包括公司内部俱乐部也可以使用“群组”的方式维护。不同的群组内可以建立对应的角色，例如：技术委员会内可以建立委员长、委员、记录员等角色信息。

群组的建立更方便企业对内部员工做多维度的灵活管理，一方面可以摆脱组织架构的硬性限制，另一方面可以快速支持公司的业务需要、紧急动员小组之类的使用。

五、总结

本节主要说明了“公司-部门-人员”的关系，这部分属于人力资源系统内的基础资料维护，在初期设计时尽量倾向于将服务收口。在设计公司、部门等长期需要与其他系统同步的数据时，要更多考虑其数据的同步效率、安全性，增强容错。

扩展阅读：手把手带你从零搭建人力资源系统（0）

参考资料：36Kr：腾讯组织架构调整这一年

作者：产品超人，公众号：pmdog996，个人微信：chenhot1。五年中后台产品经验，目前转行武术产品经理。

本文由 @产品超人 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议