人力资源管理系统.docx
- 文档编号:6071313
- 上传时间:2023-01-03
- 格式:DOCX
- 页数:36
- 大小:420.53KB
人力资源管理系统.docx
《人力资源管理系统.docx》由会员分享,可在线阅读,更多相关《人力资源管理系统.docx(36页珍藏版)》请在冰豆网上搜索。
人力资源管理系统
1人力资源管理系统建模过程分析
1.1人力资源管理的需求
本部分用自然语言对系统进行描述。
假设用户单位是一家企业公司,公司有职工
近2000人,公司原来的人力资源管理方式主要以人工管理为主,个别业务用计算机
处理。
为了提高工作效率和决策水平,公司准备开发一套人力资源管理系统,以取代
原来的人工处理方式。
本系统的开发目标是:
为人力资源管理部门提供一个全面的信
息管理系统,通过系统可以比较容易地获得所需的关于组织体系、薪酬福利成本、人
力资源状况等静态数据,也可以方便地获得各种变动信息来进行趋势预Nt371。
在企业
内实现信息依据权限的共享,人力资源管理的Et常业务在信息系统的协助下变得高效
快捷。
为了开发本系统,首先要理解人力资源管理功能,通常人力资源管理系统包含
以下模块,各模块功能简述如下
(1)组织机构管理。
主要管理集团下属的各级公司以及公司下属的各级部门,
处理公司和部门的新建、合并、撤销业务,为公司、部门提供信息维护,统计分析功
能,支持输出组织机构图。
(2)职位管理。
主要管理职务分析后每个职位的职位描述、任职资格、后备人员、以及各职位的任职情况、超编情况、空缺情况,并按部门提供职位表和空缺职位表。
(3)人力资源规划。
重要用于管理人力资源规划和机构编制,并提供人力资源规划表、机构编制表。
(4)绩效考评。
根据职务分析,将员工分为不同层面、不同类别,分别设计考评标准。
对业绩、能力、态度等进行月份、季度、年度考评,对考核数据提供统计分析功能,为薪酬、奖惩、培训开发等方面提供依据。
(5)人事管理。
主要负责完成对在职员工、解聘员工、离退员工的基本信息、任职情况、组织变动、奖惩情况等档案数据的维护、统计分析,晋升、降职、辞职、辞退、退休等人事变动业务的处理,并提供各类员工信息卡片、信息报表。
(6)劳动合同管理。
全面管理员工劳动合同的签订、变更、续订、中止、接触全过程。
并针对不同时期,不同的合同版本,提供版本管理,以及对于到期合同提供自动提示。
(7)招聘管理。
对编制招聘计划、发布招聘信息、采集应聘信息、招聘甄选、通知面试、聘用这一过程进行全面管理。
(8)培训管理。
管理采集培训需求、编制培训计划、发布培训信息、维护培训档案、评估培训结果这一过程,以及对培训资源进行管理。
并对培训情况提供查询统
计分析功能。
(9)薪资管理。
提供对企业员工薪资标准的设定,员工工资定级,工资调整的申请、审批,工资核算发放,自动计算社会保险等代扣代缴项目,经费计划、统计分析等。
(10)福利管理。
提供员工的各项福利基金的提取和管理功能,包括定义基金类型,设置基金提取条件,进行基金的日常管理,并提供统计分析。
因本论文偏向于理论研究及篇幅限制,以下内容仅以招聘管理模块为例论述建模过程。
关于招聘管理事务描述如下:
本公司招聘组织的管理方式是这样的:
人才招聘工作由人力资源部参考用人部门意见,负责拟定招聘计划并组织实施,用人部门参与招聘测评的技术设计和部分实施工作。
人力资源需求计划的制定通常在每年初人力资源部根据公司的整体计划编制年度人力资源需求计划,报总经理办公会审批。
人力资源需求计划制定方法如下:
(1)制定人力资源需求计划的基本依据:
未来组织结构的预测、人员供求关系、现有人员的调配培训等。
(2)人员需求预测要综合考虑公司战略、可能获得的财务资源、竞争对手的人才政策、管理变革可能导致的公司规模变化、员工流动等因素造成的人力资源需求的变动。
(3)人员供给预测要综合考虑内部人才和外部人才供给情况。
人力资源部建立内部人才库,信息包括每位员工的绩效记录及评价、职业兴趣、教育背景、工作经验、培训课程、外语水平、具备的技能和证书等。
进行内部人才供给预测时要调用内部人才库,判断内部人员是否与所需工作相匹配。
在内部供给无法满足需求的情况下进行外部供给预测,外部供给预测要根据总体经济状况、全国和地方劳动力市场状况和拟招聘职位的市场状况进行判断。
(4)人力资源部在人力资源需求与供给预测的基础上,制定出年度的人力资源需
求计划。
招聘计划应包括招聘人数、招聘标准(年龄、性别、学历、工作经验、工作能力、
个性品质等)、招聘经费预算、招聘具体行动计划等。
招聘流程分为如下工作环节:
提出人员需求、拟定招聘计划、发布招聘公告、人员筛选录用、招聘工作评估。
其中人员筛选录用环节又可分为以下过程:
(1)初步筛选。
报名截止后,根据招聘岗位的要求,由人力资源部会同各用人部门进行初选。
审查求职者的个人简历和求职表,并根据收集到的求职者信息建立外部
人才库。
(2)初试。
人力资源部向初选合格的求职者发面试通知,并要求其面试时提供学历、证书、身份证等相关证件的原件。
初试由人力资源部人员和用人部门共同组成。
人力资源部对应聘人员的智力、品德和综合素质进行初试和评价,用人部门从工作经验与能力对应聘人员进行初试和评价。
(3)复试。
复试由复试小组进行。
复试小组一般由以下三方面人员组成:
一、用人部门代表;
二、人力资源部部长;三、资深专业人士。
一般岗位的招聘可无资深专业人士,专业技术人才和管理人才的招聘必须有资深专业人士参加。
高级专业技术人才和管理人才由总经理负责面试,人力瓷源部负责协调。
重要岗位的复试可以考虑采取笔试的形式,由人力资源部和用人部门共同组织进行。
(4)复审。
通过复试的应聘人员由用人部门的主管领导进行审核,并签署意见。
所有拟录用的人员应经总经理最后签字批准。
(5)录用。
人力资源部根据应聘人员体检结果,对体检合格者办理录用手续。
对社会应聘人员发试用通知书,并到相应劳动部门办理劳动手续;对被录用的应届毕业生向其所在高校发接受函,签定就业协议书。
同时,人力资源部将面试结果通知落选的应聘者。
(6)报到。
被录用员工必须在规定时间内向公司报到。
如在发出录用通知15天内不能正常报到者,可取消其录用资格。
特殊情况经批准后可延期报到。
(7)试用。
试用期的人员,尚不属于公司正式员工。
在此期间,本人可以随时提出辞职。
试用人员如不能胜任本职工作或工作中出现重大失误,公司有权随时将其辞退。
(8)转正。
试用期满后的员工,经考核合格,人力资源部应在试用期满一星期前向使用部门书面征询意见。
1.2体系结构设计
在2.1节介绍了软件体系结构在软件开发中的作用以及目前应用最广泛的信息系统的体系结构——B/S结构和C届结构。
B/S结构最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。
只要有一台能上网的电脑就能使用,客户端零维护。
系统的扩展非常容易,只要能上网,再由系统管理员分配一个用户名和密码,就可以使用了。
甚至可以在线申请,通过公司内部的安全认证(如cA证书)后,不需要人的参与,系统可以自动分配给用户一个账号进入系统。
人力资源管理系统作为单位信息化的一个重要组成部分,它的应用无论是现在还是将来都有着十分重要的意义。
随着信息化的发展,无纸化办公的推广,人力资源管理系统的功能还会不断完善、扩展。
采用B/S软件体系结构可以在本管理系统基础上进一步开发,满足单位进一步发展。
因此,本系统采用B/S软件体系结构。
1.3建模过程
要成功地建立一个软件系统的模型,离不开建模语言、软件过程和建模工具三方面的支持。
对于人力资源管理系统实例,本论文选择uMI作为建模语言,选择PowerDesigner作为建模工具,采用Rational统一过程(RUP)软件开发过程。
软件过程描述的是傲什么、怎么做、什么时候做以及为什么要做,描述一组按某种顺序完成的活动,在已产生的软件过程中,Rational统一过程(RUP)是目前最具有普遍意义的开发过程。
RUP的核心思想是:
用例驱动,迭代化开发。
人力资源管理系统实例的建模过程吸取RUP的思想,鉴RUP的过程成分“需求分析”及“分析与设计”中的工作流程,将建模过程划分为以下5个活动。
(1)设计用例模型:
设计用例模型是开发过程的起点,用例模型驱动着系统的整个开发过程。
(2)设计实体类模型:
类模型是面向对象分析的核心,类图是定义其它图的基础。
用例就是通过类之问的交互来实现的。
(3)设计接口类模型:
接口类模型描述活动者与系统交互的界面。
(4)设计窗口结构:
窗口结构描述窗口之间的关系。
在设计用户接口原型之前,首先要设计窗口结构。
窗口结构与UMI_不直接有关。
(5)设计动态模型:
动态模型描述每一个用例路径所涉及的若干对象的交互行为。
动态模型非常重要,其作用或价值与面向过程方法中的软件结构图相当。
迭代式的开发是一个循环往复的开发过程。
但是,为节省篇幅,在开发过程中不作过多的迭代假设。
1.4设计用例模型
用例模型是开发过程的起点,并驱动建模全过程。
用例模型包括系统的用例图及用例描述。
2系统用例模型
通过设计系统顶层的用例模型,可使建模人员从总体上对系统功能有一个了解。
在设计系统用例模型之前,先要识别活动者和用例,然后才能建立用例模型。
1、活动者识别
活动者是系统分析员与用户交流的起点,也是项目获得后续产品的关键。
通常情况下,活动者是指使用系统功能的人,但也可以是其他外部的系统包括软件系统和硬件设备。
总之,凡是与系统进行信息交换(包括数据信息和控制信息的交换)的外部事物,都可以是系统的活动者。
识别活动者需要系统分析员与系统用户进行广泛深入的交流以明确系统的范围、系统的作用以及与系统交互的外部事物等,这个过程不可能一次完成,可能会需要往复多次。
可以通过向用户询问以下问题来识别系统活动者
谁,什么对系统运行产生的结果(值)感性趣?
谁/什么将会改变系统的数据?
谁/什么要从系统中得到信息?
谁/什么要与系统交互?
这些问题的答案往往包含了所有与系统有关联的用户,进一步分析这些用户即可
识别系统的活动者。
通过前面3.1节对人力资源管理的系统描述可知,在系统的顶层上可以识别出8
类活动者:
(1)公司主管(4)培训部门(7)系统管理员
(2)人力资源部(5)财务处(8)应聘人员
(3)用人部门(6)公司工会
2、用例识别
能否成功地开发一个项目,在很大程度上取决于能否采用一种对于项目组人员和用户来说都非常直观的方式定义系统的需求。
用例就是目前定义系统需求的最佳方式
用例识别是应用UML进行面向对象分析的关键的一步,是后续工作的前提。
用例是面向目标的,它代表的是系统将做什么,而不是系统将怎么做。
它相当于一个容器,一个满足系统各种交互的容器。
识别出用例并不总是很直观的。
可以从事件表中
来识别用例,一旦事件被定义,用例的定义就变得简单了。
活动者是事件的主体,事
件从系统活动者中寻找。
事件可以按照下面的格式来定义:
主语+动词+宾语
其中:
主语一表示已被识别出来的活动者,例如人力资源部;
动词——表示动作,例如规划、管理、考评;
宾语一表示动词涉及的目标,例如劳动合同或人事档案。
由此,生成用例的过程如图1所示。
图1用例的生成过程
事件表中的每个事件并不总是对应一个用例。
可能有些事件是相近或相同的,如果多个事件有共同点或者多个事件的最终目标相同,那么就可以将这些事件合并为一个事件。
系统层的用例识别过程如下:
通过前面对人力资源管理的系统描述,按照上面介绍的用力识别方法,可以从系统顶层得到系统层事件表I枷,
表3-1中的描述短语是从系统层识别出的用例。
它们是:
(1)管理组织机构
(2)管理招聘
(3)管理职位
(4)规划人力资源
(5)考评员工绩效
(6)管理人事档案
(7)管理劳动合同
(8)管理培训
(9)管理员工薪资
(10)管理员工福
(11)管理系统权限
(12)登录系统
(13)修改个人资料
识别出用例以后,就可以画出系统的用例图,如图3—2所示是当前分析得到的系
统层的用例图。
图2系统层的用例图
44、用例描述
一个用例对应并描述一个完整的功能。
路径是用例中事件的步骤。
一个路径也称为一个场景。
每一个用例包含多种路径,每一个路径由一系列业务步骤组成。
如果用例的粒度太粗,一个路径甚至一个业务步骤也可以定义为一个用例;如果用例的粒度太细,则一个用例只有一条路径,这会导致某一功能支离破碎。
因此要合理掌握用例的粒度。
路径有3个层次:
主要的、可选的和例外的。
主路径是用例中最通常情况下发生的路径;可选路径是合法的但不是经常发生的路径;例外路径是不按设想顺序进行的路径,是应用程序中必须要捕获的错误情况。
用例描述了系统做什么,但没有规定怎么做,即用例图没有显示不同的路径,只显示了活动者与用例之间的关系。
因此,需要为用例配上结构化叙述的文体。
为了统
一格式,每个项目应该使用一个用例模板。
在论文中,系统实例使用如下所示的用例模板来描述用例。
用例模板
用例名称(用例名)
用例目标(用例在系统中的目标)
级别(概要任务/首要任务/子功能)
活动者(此用例的活动者)
状态(未定义路径/只定义了初始路径/路径定义完成)
前件条件(用例执行前系统应具有的状态)
成功后件(用例成功执行后系统应具有的状态)
主路径(用例主路径的名称)
可选路径(用例的可选路径)
例外路径(用例的例外路径)
这个模板描述了一个用例的主要方面。
下面以管理招聘用例为例说明用例模板的用法。
用例名称管理招聘;
用例目标制定年度人力资源计划及招聘计划,发布招聘公告,管理员工筛选过程及评估工作;
级别子功能;
活动者人力资源部,公司主管,用人部门;
状态只定义了初始路径;
前件条件人力资源部登录系统;
成功后件管理整个招聘过程;
主路径用人部门提出人员需求,人力资源部拟定招聘计划,公司主管审批招聘计划,人力资源部发布招聘公告,人力资源部筛选录用应聘者,人力资源部评估招聘工作;
可选路径特殊人员员招聘;
例外路径无。
其它用例描述从略。
3员工招聘管理模块用例模型
对系统顶层识别出的员工招聘管理用例进一步细化,从而建立比较详细的员工招
聘管理用例模型。
1、活动者识别
通过3.1节对员工招聘管理功能模块的文字描述,与系统发生交互的实体有总经
理、人力资源部、人力资源部部长、用人部门、用人部门主管领导、应聘人员、复试
小组、用人部门代表、资深专业人士和劳动部门。
总经理直接与系统交互参与招聘管
理,可以识别为活动者:
总经理:
人力资源部和人力资源部部长与系统直接进行交互,
二者的目标相同,可识别为一个活动者:
人力资源部;用人部门、用人部门代表和用
人部门主管领导与系统直接进行交互,三者的目标相同,可识别为一个活动者:
用人
部门;应聘人员参与系统交互,可以识别为一个活动者:
应聘人员;劳动部门参与系
统交互,可以识别为一个活动者:
劳动部门;资深专业人士不参与系统交互,不能识
别为活动者,复试小组虽然与系统直接交互,但它由用人部门代表、人力资源部部长、资深专业人士组成,不能识别为活动者。
综上所述,员工招聘管理功能模块共识别出
5类活动者。
(1)总经理(4)应聘人
(2)人力资源部(5)劳动部门
(3)用人部门
2、用例识别
根据前面介绍的用例识别方法,下面来定义事件。
通过已识别的活动者并结合对员工招聘管理功能模块的文字描述,将表3-1系统层事件中的管理招聘事件细化,可以得到表3—2所示的管理招聘事件表。
表3-2中的描述短语是从系统层的员工招聘管理用例中识别出的子用例。
他们是:
(1)提出人员需求(6)发布招聘公告
(2)制定人力资源需求计划(7)登记个人简历和求职表
(3)审批人力资源需求计划(8)参与员工筛选录用
(4)拟定招聘计划(9)评估招聘工作
(5)审批招聘计划
3、员工招聘管理用例模型
用例识别出来以后,就可以画出员工招聘管理用例模型,如图3-3所示。
4、用例描述
用例名称提出人员需求;
用例目标根据本部门的具体情况,制定本部门的年度人员需求计划并提交到数据库:
级别子功能;
活动者用人部门;
状态只定义初始路径;
前件条件用人部门登录系统;
成功后件用人部门登录系统后可以编辑、修改、查看、删除本部门的人员需求计划;
主路径用人部门登录系统后编辑、修改、查看、删除本部门的人员需求计
划并提交到数据库中;
可选路径1、修改并提交;2、查看:
3、删除;
例外路径无。
其它用例这里不再描述。
图3员工招聘管理用例模型
3.4.3参与员工筛选录用用例细化
由于上述员工招聘管理用例模型中的参与员工筛选录用用例与多个活动者有关,
因此该用例图还需进一步的细化。
1、活动者识别
通过3.1节对员工招聘管理功能模块的文字描述,与参与员工筛选录用发生交互的实体有总经理,人力资源部,人力资源部部长,人力资源部人员,用人部门,用人部门代表,用人部门主管,用人部门的主管领导,员工所在部门部长,求职者,“拟予聘任”的人员,“拟予复试”的人员,通过复试的应聘人员,应聘人员,拟录用的人员,体检合格者,社会应聘人员,被录用的应届毕业生,被录用员工,员工,落选的应聘者,试用期的人员,劳动部门,资深专业人士,复试小组,小组成员和公司。
总经理直接与系统交互参与招聘管理,可以识别为活动者:
总经理;人力资源部,人力资源部部长和人力资源部人员与系统直接进行交互,三者的目标相同,可识别为一个活动者:
人力资源部;用人部门,用人部门代表,用人部门主管,用人部门的主管领导和员工所在部门部长与系统直接进行交互,他们的目标相同,可识别为一个活动者:
用人部门;求职者,“拟予聘任”的人员,“拟予复试”的人员,通过复试的应聘人员,应聘人员,拟录用的人员,体检合格者,社会应聘人员,被录用的应届毕业生,被录用员工,员工,落选的应聘者,试用期的人员与系统直接进行交互,其目标相同,可识别为一个活动者:
应聘人员;劳动部门直接与系统交互参与招聘管理,可以识别为活动者:
劳动部门;资深专业人士和公司没有直接与系统交互参与招聘管理,不可识别为活动者;复试小组和小组成员虽然与系统直接交互,但它由用人部门代表、人力资源部部长、资深专业人士组成,不能识别为活动者。
综上所述,员工招聘管理功能模块共识别出5类活动者。
(1)总经理(3)用人部门(5)劳动部门
(2)人力资源部(4)应聘人员
2、用例识别
根据前面介绍的用例识别方法,下面来定义事件。
通过已识别的活动者并结合对
员工招聘管理的文字描述,将表3-2中的参与员工筛选录用事件细化,可以得到表3.3
所示的参与员工筛选录用事件表。
可得到下列用例:
(1)初步筛选简历和求职表
(2)建立外部人才库
(3)发送面试通知
(4)填写初试测评表
(5)填写复试记录表
(6)填写复试结果推荐书
(7)审核并签署复审意见
(8)签字批准拟录用人员
(9)检查体检结果
(10)办理劳动手续
(11)发送试用通知书
(12)填写员工登记表
(13)签定试用劳动合同
(14)征询试用意见
(15)出具试用意见
(16)填写转正定级审批表
(17)填写试用期工作小结
(18)填写考核意见
(19)批准考核意见
(20)签订正式劳动合同
4、参与员工筛选录用用例模型
用例识别出来以后,就可以画出参与员工筛选录用用例模型,如图4所示。
图4员工筛选录用用例模型
4、用例描述
用例名称初步筛选个人简历和求职表:
用例目标对个人简历和求职表进行初步筛选,根据个人资料将不合格者删除,勉强合格者加入人才库,合格者准备面试;
级别子功能;
活动者人力资源部,用人部门;
状态路径定义完成;
前件条件人力资源部登录系统;
成功后件对应聘者个人简历和求职表进行初步筛选并分类;
主路径对个人简历和求职表进行初步筛选,根据个人资料将不合格者删除,勉强合格者加入人才库,合格者准备面试;
可选路径无:
例外路径无。
其它用例这里不再描述。
5基于UML的人力资源管理系统建模
5.1设计实体类模型
类是面向对象方法的一个全新的概念,类模型是面向对象分析的核心脚l。
实体类是系统需要持久保存的对象,最终要映射到数据库。
实体类模型用类图描述。
在实体类模型的设计过程中,首先识别出实体类,接着识别出类及类之间的关系,然后画出类图,最后识别类的属性与操作。
5.2识别方法
识别类的方法通常使用的识别方法是名词识别方法一般来说,描述问题域实体都用名词或名词短语。
应用名词识别方法时,要从系统描述中找出名词、名词短语或名词性代词,因为它们往往对应着对象(类)。
其中单数名词可以识别为对象,而复数名词则可以识别为类,但是要注意,并不是每个名词都对应着一个对象(类),可能有的名词只是其他对象的一个属性,也可能几个名词对应着一个对象(类)。
要看找出的名词是否都应该成为系统的对象(类),考察其是否有与该对象(类)
6识别过程
首先从3.1节系统文字描述中找出用来描述问题域实体的名词。
根据招聘管理事务描述可以得到以下名词:
总经理,人力资源部,用人部门,劳动部门,求职者,“拟予聘任”的人员,“拟予复试”的人员,通过复试的应聘人员,应聘人员,拟录用的人员,体检合格者,社会应聘人员,被录用的应届毕业生,被录用员工,员工,落选的应聘者,试用期的人员,部门,部门人员需求,年度人力资源需求计划,招聘计划,招聘公告,个人简历,求职表,面试通知,初试测评表,复试记录表,复试结果推荐书,复审意见,拟录用人员,体检结果,劳动手续,试用通知,员工登记表,试用劳动合同,试用意见,转正定级审批表,试用期工作小结,考核意见,正式劳动合同下面对上述名词进行分析,从而得到实体类。
总经理,人力资源部,用人部门,劳动部门属于系统的用户,可以识别为一个类:
用户;求职者,“拟予聘任”的人员,“拟予复试”的人员,通过复试的应聘人员,应聘人员,拟录用的人员,体检合格者,社会应聘人员,被录用的应届毕业生,被录用员工,员工,落选的应聘者,试用期的人员,拟录用人员,个人简历可以识别为一个类:
应聘者;部门可以识别为一个类:
部门;部门人员需求可以识别为一个类:
部门人员需求;年度人力资源需求计划可以识别为一个类年度人力资源需求计划;招聘计划可以识别为~个类:
招聘计划:
招聘公告可以识别为一个类:
招聘公告;求职表可以识别为一个类:
求职表;面试通知可以识别为一个类:
面试通知;初试测评表可以识别为一个类:
初试测评表;复试记录表可以识别为一个类:
复试记录表;复试结果推荐书可以识别为一个类:
复试结果推荐书;复审意见可以识别为一个类:
复审意见:
体检结果可以识别为一个类:
体检结果:
试用通知可以识别为一个类:
试用通知;员工登记表可以识别为一个类:
员工登记表:
试用劳动合同可以识别为一个类:
试用劳动合同;试用意见可以识别为一个类:
试用意见;转正定级审批表可以识别为一个类:
转正定级审批表;试用期工作小结可以识别为一个类:
试用期工作小结;考核意见可以识别为一个类:
考核意见:
正式劳动合同可以识别为一个类:
正式劳动合同。
6.1.类的关联
要建立类模型,不仅要识别出类,还要识别出类与类之间的关系。
通常显式的关系可以从用例中找到,而隐式的关系在用例中没有明确的说明,这需要认真的分析。
6.2招聘管理功能模块子系统类图
根据上面分析的表4_1和表舢2可以得到招聘管理功能模块子系统实体类类图,
6.3设计接口类模型
接口类模型描述系统活动与系统交互的界面,在UML建模过程中通常用类图和
包图来描述。
设计接口类模型,首先要识别出接口类,然后再识别出接口类之间的关
系。
它是应用程序的“可视区”,也是系统与外界的隔离层。
识别接口类可以从用例去识别,用例驱动接口类设计。
用户接口直接与用例相连,
用户是通过用户接口发起和终止用例的。
由于用户接121直接面向用户,设计过程中要
反复与用户商量,充分理解用户的要求。
在将用例映射到用户界面时,要根据用户的
需要对用例进行适当的组合。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 人力资源 管理 系统