eHR需求分析报告.docx

eHR需求分析报告.docx

《eHR需求分析报告.docx》由会员分享，可在线阅读，更多相关《eHR需求分析报告.docx（24页珍藏版）》请在冰点文库上搜索。

eHR需求分析报告

XXX集团股份有限公司

信息化项目一一eHR系统

需求调研分析报告

提交日期:

修改日期:

文控编号:

客户项目经理：

日期：

用友项目经理：

期:

文档控制

更改记录

日期作者版本更改记录

审核人

姓名

职位

版本

审核时间

复制号

姓名

版本

备注

、、亠

注意：

由于文档控制的需要，请您在收到这份文档的拷贝时，将您的姓名填入以上表格中相应的位置。

1.调研总结错误!

未定义书签

.调研报告的目的.错误!

未定义书签

.调研活动的总结.错误!

未定义书签

2.组织机构管理错误!

未定义书签

.概述.错误!

未定义书签

.组织架构.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.岗位的管理体系.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.职务的管理体系.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.编制管理.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

3.人员信息的管理错误!

未定义书签

.概述.错误!

未定义书签

.人员类别管理.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.员工编码以及员工基本信息的管理.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.员工基本信息项目设置及维护.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.人事信息的预警.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

4.人员变动管理错误!

未定义书签

.概述.错误!

未定义书签

.员工转正管理.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.人员调配管理.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.人员离职管理.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

.调配、离职业务的统计报表.错误!

未定义书签

原型业务描述错误!

未定义书签

需求分析错误!

未定义书签

5.人员合同管理错误!

未定义书签

.原型业务描述.错误!

未定义书签

.需求分析.错误!

未定义书签

6.薪酬社保管理错误!

未定义书签

.概述.错误!

未定义书签

.原型业务描述.错误!

未定义书签

薪酬体系错误!

未定义书签

社保错误!

未定义书签

其他福利错误!

未定义书签

劳务费错误!

未定义书签

.需求分析.错误!

未定义书签

1.调研总结

1.1.调研报告的目的

本调研报告是就本次XXX集团人力资源系统调研活动的总结。

其中描述了XXX集团管理的现状与各职能业务的基本情况、管理作业流程与项目的特别需求。

用友项目组与XXX

集团eHR项目组将依据本调研报告提供的需求及资料制定系统应用解决方案。

其中所列需求部分并不表示已承诺满足，具体解决需在应用解决方案设计阶段进行详细讨论与确认。

双方项目经理签署确认本报告所述内容是真实可靠的。

1.2.调研活动的总结

为了全面细致地了解XXX集团人力资源的业务细节，并将业务规则与系统进行匹配，以便形成系统应用解决方案，用友软件公司项目组通过整体访谈、资料分析、产品演示、个别确认的形式，对XXX集团人力资源部总体及各具体业务内容作了详细调研。

本次业务调研主要是按照一期项目实施的范围，重点对组织架构、人员信息、人员变动、合同管理、薪酬管理、福利管理六个部分进行了调研。

时间管理、招聘管理、培训管理、绩效管理四个方面进行了简单调研。

整个项目实施单位范围（包括二期模块）：

北京XXX集团（集团）股份有限公司集团本部，包括人员由集团统一管理的其他七家公司：

北京公司、上海公司等。

2.组织机构管理

2.1.概述

组织机构管理是指对机构日常业务的管理和机构信息的维护，是HR业务的基础，主要

业务包括：

a）集团基础架构、集团内公司目录、部门管理体系、岗位管理体系、职务管理体系的

设置和管理。

b）机构的设立、变更和撤销管理

c）部门、岗位编制的核定及管理

d）各岗位继任人选管理。

e）虚拟组织管理。

2.2.组织架构

2.2.1.原型业务描述

XXX集团集团是涵盖房地产开发、物业管理、商贸代理、综合投资业务的大型集团企业，存在同班人马管理多家公司的情况，员工的工资发放公司、社保缴交公司与员工合同签署公司可能都不在同一公司。

但从人力资源日常管理的角度，实行人员的集中管理，包括北京XXX集团（集团）股

份有限公司、北京当代广告有限责任公司、北京荟宏房地产开发有限责任公司、北京建铭房地产开发有限公司、北京凯韦诚投资管理有限责任公司、北京丸博国际商务咨询有限公司、北京兆泽房地产开发有限责任公司、北京丰铭置业有限责任公司八家公司。

下属的物业、商业、和即将成立的酒店管理公司，工资发放、绩效考核等人力资源管理均自主进行。

XXX集团的组织机构图如图1所示。

集中管理的七家公司，基本采用的是树形层级式管理。

XXX集团部门管理体系较为清晰，目前包括总裁办公室、人力资源部、法律合约部、财务资金部、规划设计部、计划管理部、工程管理部、合同预算部、材料采购部、前期管理部、推广销售部、商业营运部、写字楼酒店部、策划发展部、战略投资部、董事会办公室、审计稽查部、西单项目部、雅宝路项目部19个部门。

图1XXX集团组织机构图

根据公司组织架构业务分类，分为P序列（项目开发序列）、R序列（投资收益序列）、C序列（渠道服务序列）。

1）P序列：

指公司在房置地价值链中负责房置地产品开发的产出部门，包括规划设计

部、工程管理部、前期管理部、合同预算部、材料采购部

2）R序列：

指公司在房置地价值链中负责房置地产品出售或持有经营的收益部门。

包括策划发展部、推广销售部、商业营运部、写字楼酒店部。

3）C序列：

指公司在房置地价值链中为产出和经营部门提供渠道和服务的职能部门。

包括战略投资部、审计稽查部、董事会办公室、总裁办公室、财务资金部、人力资源部、计划管理部。

2.2.2.需求分析

1）问题及需求：

XXX集团的组织架构后续还有可能变化，主要是部门的汇报关系发生变化，在系统中如何实现

需求分析：

系统支持部门、岗位的上下级关系定义及修改。

2）问题及需求：

有的部门暂时没有人员，比如商业营运部。

在系统中如何处理需求分析：

如果是正式规划的部门，可以在系统实施过程中将该部门搭建于组织体系中，以后有业务需要时，人员可以直接入职、调配到该部门。

如果尚不确定该部门是否设置，在系统的公司目录中可以暂不设置该部门，系统支持对部门的设立及变更等操作。

2.3.岗位的管理体系

2.3.1.原型业务描述

XXX集团对岗位的管理有比较严格的要求，每个岗位都有明确岗位说明书。

新员工入职一个月内，在签订劳动合同的同时，还需要签署相应的岗位说明书、工作目标责任书等。

2.3.2.需求分析

1）问题及需求：

公司对某些特定的岗位有一定的继任人管理，在系统中如何实现需求分析：

系统中岗位管理模块下有一个节点为：

继任人选维护，在此节点我们可以完成某一个岗位继任人员的维护，一个岗位可以有多个继任人选。

2）问题及需求：

目前公司对每个岗位都有岗位说明书，在系统中如何做到对岗位说明书的记录，如何详细的记录这个岗位有什么岗位任职说明等信息。

需求分析：

系统中的岗位信息包括主集信息以及子集信息，主集信息又包括岗位基本情况和岗位任职资格。

子集信息包括岗位办公设备、岗位发展计划等。

对岗位相应的职责说明在主集中的岗位任职资格页签可以记录，主要包括：

学历要求、性别要求、年龄要求、专业背景要求等信息的维护。

此外每个岗位信息系统还支持上传5M的附件。

子集

信息名称可以修改。

2.4.职务的管理体系

2.4.1.原型业务描述

XXX集团规划以职务和岗位双向维度来管理人员，目前还没有形成完善的职务簇以及职务。

从现状来看，相同的岗位可以对应不同的职务。

相同的职务也可以对应不同的薪酬级别。

2.4.2.需求分析

1）问题及需求：

目前XXX集团的职务体系尚在规划，因此在系统实施过程中对职务暂不设置，但希望系统提供职务管理的功能。

需求分析：

系统支持对职务簇及职务的管理，并提供了职务基本情况和职务任职资格描述。

职务簇是具备同样属性要素、但存在量差的岗位集合，同一个职务簇中不同的个体，存在等级、重要性、目标等的差异。

处于相同职务簇的群体，我们会用同样的管理方式去管理，如培训、考核、资源调配、薪酬设计等等。

2.5.编制管理

2.5.1.原型业务描述

XXX集团目前是由集团统一对八家公司进行编制管理，编制控制到岗位级。

按照部门、岗位制订编制数。

2.5.2.需求分析

1）问题及需求：

公司内劳务人员、集团外借调等人员是不占编的，在系统中如何处理此类问题。

需求分析：

本系统在进行编制管理时可进行人员类别占编设定。

在系统搭建时可以建立劳务人员、集团外借调等人员类别，在编制设置时将此类人员设置为不占编。

3.人员信息的管理

3.1.概述

人员信息是HR管理的基础。

人员信息管理的内容主要包括：

1、人员类别管理。

2、人员编码管理。

3、员工基本信息项目设置及维护。

4、人事信息预警。

5、统计分析报表应用。

XXX集团目前对人事信息的管理基本是通过手工管理，有些业务到很难进行有效的管理监控，尤其是需要对人事信息进行查询、统计分析时，工作量大，还难以保证结果的准确性。

3.2.人员类别管理

3.2.1.原型业务描述

在系统中不同状态的人员所涉及的业务不同，系统初始将人员分为：

在职人员、解聘人员、离退人员、调离人员、其他人员五大类。

系统根据每大类人员的业务特点，做了一定的控制。

每大类人员具体含义是：

在职人员：

指在册的正式员工。

解聘人员：

曾经在本公司任职，合同到期或其他原因解聘的员工。

XXX集团

离退人员：

曾经在本公司任职，现在由于离休、退休等原因离开的员工。

调离人员：

曾经在本公司任职。

现在调离到其他公司的员工。

即使员工属于内公司间调动，对于调出公司来说，该员工依然是调离人员。

其他人员：

本公司管理人事关系，但是并不真正属于本公司的在职员工。

目前XXX集团公司的人员分类如表1所示：

表1XXX集团人员分类表

序号

归属范围

人员类别

1

在职员工

在岗

合同制员工

试用期人员

实习生

返聘离退人员

劳务人员

借出人员

从集团外部借调人员

不在岗

长期病休假人员

休产假人员

工伤人员

待岗人员

2

解聘人员

辞职人员

与公司解除劳动合同

不予公司续订劳动合同

辞退人员

不予员工续订劳动合同

公司与员工解除劳动合同

3

离退员工

退休人员

离休人员

4

调离人员

调离人员

5

其它人员

其它人员

系统中的人员分类，建议在上述分类的基础上根据人事统计需要进行适度修改。

在进行人员类别规划时，有两点要求必须要满足：

（1）任何一个员工都能对应到某一个人员类别；

（2）任何一个员工不能同时属于多个人员类别。

人员类别的划分要求可以方便的对不同状态的人员进行统计，同时需要对调配离职状态中的人员进行跟踪管理。

人员分类不必太细，否则系统操作会变得比较复杂。

3.2.2.需求分析

1）问题及需求：

公司目前存在休假人员，特别是休产假以及长期病假的人员，在建立人员类别时是否可以建立休假人员的类别。

需求分析：

系统是支持建立休假人员类别的。

是否需要建立新的人员类别，还要看这类人员在处理业务时有什么特殊性。

（1）目前在XXX集团的编制管理中休产假及长期病假这类人员的薪资发放不同于在岗员工。

如果将休假人员设为独立的人员类别，在薪资项目公式设置时，可以以人员类别作为判断条件。

（2）如果人员在休假期间，由别人来承担其工作，休假人员空出相应的编制。

那么在系统中建立休假人员类别，并在设置公司编制时把休假人员设置为不占编人员，员工需要休假时做相应的调配，将人员属性变为休假人员，即可实现对编制的灵活管理。

3.3.员工编码以及员工基本信息的管理

3.3.1.原型业务描述

目前公司对员工编码没有统一的规则，员工也没有在用的人员编码。

在花名册中可以体现员工的姓名、身份证号、户口性质、职称、学历、专业等一些基本信息。

3.3.2.需求分析

1）问题及需求：

是否可以按照人员所在的部门进行人员编码的编制员工编码是否可以自动生成

需求分析：

系统目前支持人员编码的自动生成以及手工录入，每个员工在系统中对应唯

一编码，可以根据人员编码随时跟踪员工的各类信息情况，对系统本身数据查询及业务

管理起到重要作用。

如果人员编码中体现部门编码，则人员发生调动以后，人员编码并不发生改变，就表示不了之前的信息了。

建议人员编码用流水号来完成。

2）问题及需求：

人员换岗后会影响到人员编码的变化吗

需求分析：

人员编码在系统中作为人员的唯一标识，在人员进行相应业务时人员编码也不会随着业务变化。

3）问题及需求：

人员离职以后，其人员编码是否会重新分配

需求分析：

人员离职后，系统仍保留该人员的信息。

人员编码不会再重新分配给其他员工。

4）问题及需求：

公司上市或申请某些资质时，需要对公司内具有各种专业资格、等级证书的人员进行统计，比如：

工程师、会计师等。

能否在系统中方实现这一功能，并且可以搜索同类专业资格信息。

需求分析：

系统支持通过子集信息记录人员的职称记录、国家职业资格等信息，可以记录每个人的多条记录，每条记录里又可以包含多项信息，如：

职业资格名称、批准单位、取得时间等。

通过设置查询条件，可以实现同类专业资格信息的搜索。

3.4.员工基本信息项目设置及维护

3.4.1.原型业务描述

员工基本信息项目是人员基本信息管理的重要部分。

员工基本信息的管理分成三部分：

一部分是员工当前的个人信息，是对员工当前一些状态的反映。

例如：

身份证号码、性别、出生日期、政治面貌等信息。

另外一部分是管理与员工工作相关的状态信息，例如：

员工所属的单位、部门、岗位、人员类别、到职日期等信息。

其次还有记录员工记录集合的若干子集信息。

目前XXX集团对员工信息的维护主要是：

序号、姓名、性别、部门、身份证号、入职日期、试用期、试用终止日期、户口性质、手机号、合同状况、岗位、职称、学历、专业、生日、户口所在地、现住址、工资所属、保险所属、合同所属、专业类别、年龄、email、

年龄段、合同到期时间等信息。

3.4.2.需求分析

1）问题及需求：

系统中能否记录员工的档案转入日期。

需求分析：

系统支持对人员信息项的自定义添加。

2）问题及需求：

在系统中能否区分哪些人员的档案存放在公司。

需求分析：

可以在人员信息中添加一个字段来标识员工档案是否转入公司，就可以方便时按照这个条件进行查询统计。

3）问题及需求：

在人员信息中能否体现员工的职务级别。

需求分析：

人员信息中可以体现员工的职务簇以及职务级别，同时可以按岗位序列、岗位等级来维护。

职务簇是具备同样属性要素、但存在量差的岗位集合，同一个职务簇中不同的岗位，存在等级、重要性、目标等的差异。

处于相同职务簇的群体，我们会用同样的管理方式去管理，如培训、考核、资源调配、薪酬设计等等。

简而言之职务簇就是岗位的分类，具备同样特征的岗位形成了职务簇。

4）问题及需求：

希望在人员信息中能够显示员工的属相，并且能够根据员工的生日自动生成，不需要手动输入。

需求分析：

在系统中通过添加自定义信息项“属相”，并且在单据模板中进行配置，可以实现这一要求。

3.5.人事信息的预警

3.5.1.原型业务描述

XXX集团目前对人事信息的管理基本是通过手工管理，有些业务到很难进行有效的管理

监控，因为有些业务到期了很难进行有效监控和准确地掌握。

3.5.2.需求分析

1）问题及需求：

公司为过生日的员工发放福利，希望系统能提供相应的生日提醒。

需求分析：

系统的标准功能即可实现员工的生日预警。

2）问题及需求：

当女员工年满50和55岁，男员工年满60岁时，系统能够提前两个月进

行预警。

需求分析：

如果系统中记录了员工的准确生日，系统能够进行设置，根据生日进行计算，按照要求的条件发出预警。

4.人员变动管理

4.1.概述

人员变动管理主要用来管理员工在单位内发生的各类异动信息，包括人员类别、部门、岗位、职务等的变化情况。

主要业务包括：

转正业务、调配业务、离职业务，涉及的变动业务类型有：

转正、离职、任免、调动等。

4.2.员工转正管理

4.2.1.原型业务描述

目前XXX集团的员工转正管理分为两个步骤：

第一步是在试用中期会有一次中期考核；第二步是在试用期满前10天时提出转正申请。

试用中期的考核如果没有通过，则试用期即结束，员工办理离职，如果通过则继续试用。

试用期满前的转正申请需报相关领导审批，审批通过则转正成功。

4.2.2.需求分析

1）问题及需求：

员工转正目前存在试用中期考核，在系统中如何实现需求分析：

在系统中转正管理并没有对试用期考核做预置处理。

建议通过设置预警条件，提示业务人员需要对试用人员进行中期考核。

4.3.人员调配管理

4.3.1.原型业务描述

涉及到工作信息变更的人员变动，在系统中都可以作为人员调配处理。

从这个意义上

看，目前XXX集团相关的调配类型及业务流程如下：

（1）任命

1）人力资源部根据公司人事任命计划或部署征询部门负责人、分管领导及本人意见，发起审批程序，具体审批流程为：

部门申请--业务部门分管领导（如有需要）--人力资源部经理审核--审核总裁或董事长审批（根据授权管理手册，同员工入职）。

任命调薪审批完成之后，需向新职员本人发送薪酬福利变化通知，并抄送其部门负责人、主管领导。

2）由人力资源部发出职位任命的红头文件。

3）总裁办根据职务变化视需要调整邮箱、制作名片。

4）人力资源部当月工资核算时检查变动情况。

（2）内部调动

1）调动协商：

由调出部门和调入部门协商决定员工调动，填写《员工内部调动审批表》，报人力资源部审核。

2）审批：

人力资源部签署调动意见并报调入、调出部门主管领导审核，报总裁或副董事长审批。

3）薪资调整（如有）：

自《员工内部调动审批表》审批生效之日起开始执行。

4）劳动合同变更：

人力资源部与被调动人协商变更劳动合同相应的岗位、薪资。

5）工作交接：

被调动人在调动日期前，跟原部门做好工作交接。

部门交接记录抄送人力资源部备案。

6）报到：

被调动人在调动当日，到新部门报到。

（3）调薪

1）奖惩调薪

a）调薪方式：

通常为调整薪酬级别、档别。

b）调整发起：

员工个人、员工所在部门提出调整薪资申请，所在部门填写《薪资调

整审批表》。

c）审批：

人力资源部审核—员工所在部门主管领导审核—公司高层按权限审批。

d）人力资源部与当事人进行劳动合同变更。

e）人力资源部相关人员根据《薪资调整审批表》进行工资核算变更，自下月起执行。

2）年度调薪

a）年度调薪计划报批：

人力资源部提报－分管领导审核－公司总裁或副董事长审核－董事长审批。

b）向员工发出薪酬变动通知。

c）人力资源部工资核算执行。

调动又可以细分为晋升、平调和降职。

调配的基本流程是：

调动协商——＞审批——＞

薪资调整（如有）——＞劳动合同变更——＞工作交接——＞报到。

1-4级员工与5-9级员工所经历的审批流程略有不同。

1）1-4级的员工：

由人力资源部组织，总裁（PandC序列）或副董事长（R序列）提名（并审批），然后由董事长审批。

2）5-9级的员工：

由部门申请，人力资源部审核，然后报主管副总裁审批，再报总裁（PandC序列）或副董事长（R序列）审批。

4.3.2.需求分析

1）问题及需求：

在调配过程中一般员工（5-9级）和公司领导（1-4级）调配时走的审批流程不同，在系统中如何处理

需求分析：

系统支持设置不同的审批流，但目前HR系统并不是全员应用，考虑到领导是否愿意实时登陆HR系统来处理这些审批，建议将部分审批在0A系统中完成，按照审批结果在HR系统中进行相应操作。

4.4.人员离职管理

4.4.1.原型业务描述

XXX集团将离职区分为主动离职和被动离职两种类型，申请发起人和审批流程不同。

都需要向上报批，并且1-4级员工和5-9级员工审批流程不同。

获批后进行离职工作交接、结算费用、离职访谈、离职考核。

都完成以后方可在最近一个发薪日发放员工工资和绩效。

4.4.2.需求分析

1）问题及需求：

系统中能否对离职人员的信息进行查询能否对离职原因进行统计分析需求分析：

系统支持对离职人员信息的查看和对离职原因的统计。

为了便于计算机统计，需要对离职原因进行梳理，并设置到系统中。

2）问题及需求：

在进行完离职手续的审批后还要进行离职手续的办理流程，如工作的交接、费用的核实、劳动合同解除等问题，在系统中如何体现。

需求分析：

离职审批完后的工作交接单可以在系统中完成，记录离职流程的相关结果。

系统不能自动计算该员工费用结算方面的事项。

在系统中对人员进行离职处理时，可以联查该员工的劳动合同，以便对合同进行相应的处理操作。

3）问题及需求：

离职审批和离职手续办理流程可以实现自动流转否

需求分析：

离职审批和离职手续办理流程无法实现在系统中自动流转。

用友HR系统主要是处理标准的离职业务，人员离职时变更人员的类型，记录离职结果。

对于离职业务的相关流程审批及内控管理建议在0A实现，将结果手工维护到HR系统中以便查询及对比分析。

4.5.调配、离职业务的统计报表

4.5.1.原型业务描述

每月27日左右，人力资源部将当月的人员增减、调动、转正等情况汇总，生成《新入员工工资表》、《员工变动情况表》、《工资说明》（如有），交给人力资源部负责工资核算的人员作为工资核算依据。

每月上旬，针对上月27-31日的变化，将给财务的报表做最新调整，并根据人员变化，向公司领导提供上月的《员工变动情况表》、《XXX集团人员表》。

4.52需求分析

1）问题及描述：

暂无。

5.人员合同管理

5.1.原型业务描述

劳动合同管理涉及的内容包括：

建立劳动合同及岗位协议、保密协议、培训协议；对