OFBiz业务培训(02)-人力资源PPT课件

OFBiz业务培训人力资源hongs企业可能想要的信息 企业需要雇用谁？雇用历史是什么？ 公司中都有哪些职位？ 这些职位需要填补吗？如果需要，谁来填补什么位置？他或她的职责是什么？ 谁向谁报告？ 这些职位的工资支付费用是多少？ 谁得到过提升？什么时候？ 企业提供多少福利？给谁提供？ 这些福利的成本是多少？ 求职申请的状况如何？ 雇员的技能是什么？ 雇员都有什么业绩？ 需要什么优惠、扣除和工资信息来处理工资册？ 都有什么样的求职者？他们有多少可以成为雇员？ 人员更新率是多少？人员更新的原因是什么？目录 1标准人力资源模型 2雇用 3职位定义 4职位类型定义 5职位履行情况和跟踪 6职位报告 7工资确定和支付历史 8福利跟踪 9工资册信息 10雇员申请 11雇员技能和资格 12雇员表现 13雇用终止 14小结1标准人力资源模型 在许多教材中出现的一个基本雇员模型称为EMP DEPT（雇员部分）模型。标准EMP DEPT模型 雇员 部门2雇用 雇用是当事人关系的一个子类型，并且表示雇员的当事人角色和内部组织之间的一种关系。 这里假设企业只对跟踪它自己的雇员感兴趣。如果模型也需要容纳外部组织的雇员，那么雇用实体应是雇员和雇主之间的关系。雇用数据模型 当事人关系(雇用) 当事人关系状态类型 当事人关系类型 当事人角色(人角色:雇员；组织角色：内部组织)雇用实体模型 雇用继承当事人关系的属性，因为它是两个当事人之间的一种关系。 用起始日期(FROM_DATE)表示关系的起始日期或雇用日期，用终止日期(THRU_DATE)表示雇用的最后日期。 当事人关系状态（STATUS_ID)，每个雇用将有一个状态，例如：活动的、不活动的、待解决的、终止。3职位定义 职位表示企业中的一个工作岗位，这个工作岗位可能在一段时间内由多个人来占据。在一些企业中，这也被称为FTE，即全职职位。职位模型 职位 预算项目 职位责任 责任类型 职位类型 有效职责职位定义 在图9-3中，对定义职位的实体进行建模，职职位位实实体体包含跟踪任意给定工作职位所需的基本信息。职职位位类类型型实实体体为进一步定义工作和对工作进行分类提供信息，而预预算算项项目目为批准一个工作职位提供一种可能的手段。实实体体责责任任类类型型、有有效效职职责责和职职位位责责任任为赋予职位什么样的职责和跟踪职位职责提供一种机制。3.1职位 企业想跟踪的关于某个职位的数据显示在图9-3中。预计起始日期和预计终止日期用于计划。这个数据是关于企业某个人来承担组织中的某个角色的第一个标志。如果职位是不定期限的，那么预计终止日期就是空的。 实体中的各种标志可以用于定义一个人被雇用来承担某个职位的特殊情况。这个人是按月发工资还是按小时发工资呢？全职的还兼职的？临时的还是永久性的？职位的免除还是不免除是按照公平劳动标准法（Fair Labor Standards Act,FLSA）来执行呢？这些问题的答案对福利管理员和工资人事部门非常重要。另外，一旦了解了这些信息，模型就用一个实际起始日期和实际终止日期来跟踪它们。3.2职位认定 首先，企业中已经存在的工作职位一般是经过批准的职位，并且以某种方式获得资金支持。在这个模型中，职位是通过一个预算项目获得批准的。而一个预算项目可以批准多个职位或为多个职位提供资金。例如，可以为程序员设立一个预算项目。这个预算项目的金额一般为企业中所设立的多个程序员职位提供资金。如果一个职位和预算建立了联系，那么，该职位就认识是“被认定的”，此时，影响预算项目的预算状态就获得了批准。3.3职位类型 每个工作空缺代表职位实例的一次出现，这些空缺可能会有一些通用特性，例如，工作的头衔或工作类型的描述。这些通用的特性可以用一个通用的职位类型来描述。实体职位类型保存和所有职位相关的信息，这些职位一般对应一种工作。3.4职位职责 在图中显示的实体还有责任类型、有效职责和职位责任。这些实体都可以对各种工作职责进行定义，确认哪种职责适合于不同的职位类型，哪种职责可以赋予一个特定的职位。注意有效职责和职位责任都有属性起中日期和终止日期。这样允许企业赋予、改变工作和职位的职责，并对这些职位职责进行历史性的跟踪。为此，要给出非常详细的工作描述，同时也允许随时进行改变。职位实体4职位类型定义 一些企业需要对他们所拥有的职位类型进一步的分类。在图模型中，任选实体职位类型类别是职位类型和职位分类类型的交叉实全。利用这些实体可以对职位类型进行额外的分类。因为，有可能一段时间之后，一个职位类型被重新分类，所以用具有属性起始日期和终止日期的职位类型类别实体来支持职位类型和职位分类类型之间的多对多关系。职位类型定义 职位类型 职位类型类别 职位分类类型 组织角色职位类型实体5职位履行情况 图9-5给出一个模型，该模型允许企业在组织内部跟踪每个人的职位历史。它包括踊跃职位履行和职位状态类型的实体。该模型需要职位实体和人员实体来体现上下文关系。组织也用来提供关于招聘公司的一些信息。 职位履行 职位 当事人（组织、人员） 职位类型 职位状态类型5.1职位履行情况 一个人可以在不同的时间区段内或同时任职于多个职位。相反，一个职位也可以由多个人在不同的时间区段内来任职（甚至通过工作共享来同时任职）。职职位位履履行行实实体体为保存这个动作的历史提供了一种非常灵活的方式。属性起起始始日日期期和终终止止日日期期允许企业维护这个数据的精确历史信息。这是一个解决多对多关系的便捷而有效的方法，这种多对多关系实际存在于人员和职位之间。 职职位位履履行行实实体体的另一个特性就是它能能记记录录在在工工作作分分享享情情况况下下的的雇雇员员任任务务，而不会与FTE或“人头计数”混淆。这主要是由于这个一个事实，这这个个实实体体的的主主健健是是从从职职位位继继承承下下来来的的一一个个键键（职职位位标标识）识）、从从人人员员继继承承下下来来的的一一个个键键（当当事事人人标标识）识）和和属属性性起起始始日日期期的的结结合合体体。对于这样由三部分组成的主键，它可以记录在同一个时间区段内处理同一个职位上的多个人。当然，这是否可行需要通过实现一些业务规则来控制。如果一个企业从来没有工作分享，那么模型中就可以删掉和人员的关系，从复合键中删掉当事人标识。如果这样做了，那么，同一个时段内，模型就只能允许一个人占据一个职位（即使在这种情况下，也需要一些业务规则）。 注意来自组织以外的一个人占据一个合法职位也是可能的，例如签约人。因为这个模型显示职位履行必须由一个人来接收，而不是一个雇员，因此它比标准模型更灵活，更能处理这种情况。为了确定一个人是一个雇员还是来自企业外部的一个人，可以使用当事人关系实体。因为包含这样的信息，所以当事人关系也可以用来强化业务规则，例如，职位是否可以由外来人员担任。5.2职位状态类型 职位状态履行标识一个职位的当前状态。当一个职位首次被标识，那么它就处理“为计划”的状态。当企业决定需要履行该职位时，那么它就改变为“活动的”或“空缺的”状态。如果企业决定不再需要这个职位了，那么状态就变为“不活动的”或“关闭的”。“履行”状态不应作为一个值，因为这个信息是从职位履行实体中导出来的。5.3招聘组织 从职位上来说，招聘公司是什么？这个通过职位和组织之间的关系很容易跟踪。没有招聘的企业，就没有职位的需求。5.4其他考虑 有一些其他信息在这个模型中体现得并不明显，比如，一个人如何能实际获得一个空缺的职位。事实上，面试过程可以通过当当事事人人通通信信事事件件模型来跟踪。一次面试是一个通信事件目标类型，它所具有的面试记录存储在通信事件实体中。职位履行6职位报告 大多数模型显示一些人要向另一些人进行报告，并且被另一些人管理。职位报告模型通过改变一个人的职位指派来处理这种情况。职位报告关系 职位报告结构 职位职位报告结构 9-6的模型显示了实体职位报告结构，它连接职位然后再返回到自己。属性起始日期和终止日期允许跟踪组织随时间的变化，正如前面讨论的那样。其中的属性主标志有助于对灵活的矩阵类型结构进行建模。在这些情况下，某种职位可以同时向多个职位进行报告。这个指示器允许企业指明哪个报告关系是最重要的。 无需改变人们的报告关系，老的职位报告关系将会过期（用终止日期）并且新的记录会添加进去以显示一个修订的结构。以这种方式，企业很容易实现新报告结构，并且同时可以保存以前结构的精确历史。 在大企业中，对组织结构的改变可能会影响成千上万的人。通过设计一种体制、仅仅改变职位的报告会关系，而不是所涉及的实际当事人，就可以在长时间的运营中几乎不需要更新，数据也能更加清楚。7工资确定和支付历史 图是一个扩充的工资模型，该模型处理非常结构化的组织，例如，政府，或者结构化不强的组织，例如，小私营企业。模型利用实体职位类型费用、范围类型、周期类型、工资级别和工资幅度可以做到这些。另外，该模型也包括允许跟踪工资历史的实体和关系（即支付历史和雇用）工资确定和历史 职位类型费用 职位类型 费用类型 工资幅度 支付级别 周期类型 支付历史 雇用7.1职位类型费用 工作计划中定义的职位类型费用和类型费用实体为各种类型的职位提供成本和标准费用，以便为工作计划获得合适的成本估计。这一小节将对这个实体的使用进行扩充，吸收其他类型的职位费用以跟踪标准工资费用和范围。 职职位位类类型型费费用用实体可以用于为一个特定职位类型记录允许的或可接受的工资作工资范围。这个信息可以供经理在雇用过程中商谈工资时参考。属性起始日期和终止日期用来维护这些标准的历史。7.2工资级别和工资幅度 存储在这个实体中的附加信息可能还包括工资级别和工资幅度，它们在有一个预定义的、高度结构化的工资系统的企业（例如，联邦政府）中使用。这要通过引用一个结构化的工资计划表来完成。这些计划表的类型通常有两个层次：级别和幅度。工工资资幅幅度度实实体体包括一个金额属性并且一般在一个工资级别的上下文中描述。 在表9-8所显示的数据中,有几件事情需要注意.首先,在职位类型费用的费用列没有值,因为当使用一个级别体制时,金额直接从工资幅度中获得.当然需要应有一些业务过程以保证不为费用填值,否则就会有矛盾信息出现。在实现这个模型并和一个支付计划表一起使用时，这个属性可以省略。相反，当为一个企业实现这个模型时，却不使用计划表，职位类型费用的费用属性是强制的。 第二，注意终止日期也是空的。这说明这样的一个要领随着时间的推移，一个先定的工资级别和幅度的金额可以增加，但是和职位类型费用相关的幅度赋值不需要改变。在这种情况下，工资费用记录中没有什么可改变的，这就表示工资在增加。换句话说，无需输入一个终止日期，创建一个新记录显示支付的增加，因为支付增加是通过对工资幅度信息的更新来反映的。支付费用样本7.3支付历史和实际工资 由支付历史表示的实际工资或支付和人员有关，而不是和职位或职位类型有关。事实上，它和雇用相关（它是当事人关系的子类型），并且它存在于雇主和雇员之间。 工资不和职位相关，因为一个人员所占据的职位可能随时间发生变化，但这并不意味着工资也将自动地改变。有时，会赋予一个人员很多责任并且将他（或她）放在一个较高的职位上，但直到他（或她）展示了他（或她）在这人职位上超凡的能力，才给他（或她）提升工资。我们再次考虑工作分享的情况。如果支付和职位有关，两个人将必须获得同样的工资。这将限制企业按照不同的技能和经验水平为不同的当事人支付不同工资的灵活性。 依赖于企业的特性，工资由实际的金额与到工资幅度的任选关系来表示。不像职位类型费用的费用属性，金额总是记录在支付历史中以确保在给定时间区段内为一个人人应该支付多少工资而不会出现混凝土乱。也要注意因为这是给一个人的实际支付费用的一条记录，而不是一个可能费用的列表，在任意选定的时间区段内，对一个人来说，只能有一条这样的记录。和这条记录相关的周期类型由企业如何看这个数据来决定。工资确定和支付历史8福利定义和跟踪 除了工资或支付以外，大部分企业通过各种福利提供报酬。这些福利包括假期、健康或人寿保险、病假、或退休计划。这些福利的成本可以部分地或全部地由企业来承担。图9-8展示了一个福利跟踪的简单模型。它包括在每个周期类型的一个雇用中关于每个福利类型的当事人福利信息。图8福利跟踪 当事人福利 福利类型 周期类型 雇用8.1雇用 和支付历史类似，当事人福利也和当事人关系的子类型雇用相关，而不是和当事人或人员相关，因为福利是和一个特定的雇主与雇员关系相关联的。在一个大型多公司企业中，众可以从一个公司调到另一个公司，所以，有时在他们职业生涯的不同时期，他们的福利来自不同的组织。如果企业想在该组织低层次级别上跟踪福利成本，那么将成本简单地和雇员进行关联是不够的。为什么不将福利直接和雇员以及组织进行关联呢？通过使用雇用，企业将会加强业务规则，该规则将防止像签约人这样的非雇员意外地获得福利。 为了保险目的，有必要确定一个人在多个组织中的福利（通过此人的雇用实例来完成）。企业的雇员中有一部分可能有两份兼职工作；了解每份工作所提供的福利以避免福利重复非常重要（福利协调问题）。这对决定哪一种保险政策用于生病也是很有用的。在帮助保险公司控制成本时，信息是至关重要的。8.2当事人福利 在当事人福利中，可能有几条企业希望跟踪的信息。首先是起始日期和终止日期。这允许通过时间进行福利跟踪。另外，企业可能想跟踪福利的实际成本和实际雇主支付百分比。有了这些信息，不仅可能计算雇员的成本，也可能计算企业的成本。另一个属性可用时间用来跟踪有效的离岗时间，例如，假期和病假。8.3周期类型 注意表9-10中包括了周期类型。这是决定和实体周期类型之间关系的结果。这个信息主要用来个性成本属性。没有它，就没有所报告金额的上下文关系，也就无法精确地确定企业成本。另外，它也用于类型的上下文关系，如表中显示的“假期”和“病假”。当事人福利数据8.4福利类型 企业提供的各种被列在实体福利类型中。数据样本包含在表9-10中。除了福利的标识之外，这个实体也存储一个标准的雇主支付百分比，这个数据可以用来计算和具有特定福利的所有雇员相关的成本。 雇主承担福利所占的百分比不仅饮食在福利类型中，而且也包含在当事人福利和职位类型中，这样就可以在不同的细节级上记录这个信息。因此，需要应用某些业务规则。下面是一个可能的规则集：n如果实际雇主支付百份比在当事人福利中存在，那么以该数字为准。n如果这项是空的，那么使用与其当前职位相关联的职位类型的福利百分比（正如在职位履行中说明那样）。n如果这两个数值都是空的，那么使用福利类型中的雇主支付百分比。福利跟踪实体9工资册信息 一个标准的人力资源模型需要考虑的另一事项就是工资册。没有工资册，就不会有长时间为企业服务的人力资源！这个模型考虑对于许多人来说工资册中最重要的部分：正确地获得工资。关于工资册的信息饮食在如下的实体：雇员、内部组织、支付方法类型、工资支付个人方式、支票、扣除和扣除类型。图9工资册信息 扣除 支付：支出、支票、收入 扣除类型 工资支付个人方式 雇员 内部组织 周期类型 支付方法类型9.1雇员 与福利和工资一样,所有工资册信息都和雇员和内部组织有关。这些关系表示对支付与当事人的关系进行更具体的建模。这种关系是强制关系，因为如果没有雇主（内部组织）和雇员或类似关系，那么就不会有对支票的需求。以这种关系为基础，业务规则就可以确保系统内部不是任何一个当事人都可以签发支票。9.2支付方法类型 对应接收报酬的方法，现在雇主可以具有许多给雇员发薪的选择。这些选择的基本形式在实体支付方法类型中给予描述，正像支付模型一节给出的描述那样。它能存储数据，例如“现金”、“支票”和“电子数据”，依赖于一个企业的工资管理部门的能力，所有或任何一个这些选项都可能提供给雇员。9.3工资支付个人方式 有这样的可能，一个雇员希望他的工资一部分以支票的形式支付，另一部分以现金的形式支付。其他人可能想把他们的钱分开并且以电子形式存在不同的银行中。一些雇员也可能希望将标准扣除也记录在每张支票上。 为了处理这信息，模型包括实体工资支付个人方式。因为一个雇员可以随时改变支付方式，所以模型要包括起始日期和终止日期。所需要的其他信息包括总支付的百分比或一个固定方式到扣除类型的关系来维持。如果支付的类型是“电子的”，那么需要路由号码、账号和银行名称 以成功地完成交易。这些都是以属性而不是实体的形式存储的，因为企业可能不想或没有办法将它们作为自己的实体来维护。每个工资支付个人方式可能是为某种周期类型而定义的。例如，一个意料之中的特殊标准扣除可能专门用于支付周期“每年”、“每月”、“每周”的类型。 注意工资支付个人方式的主键是一个简单的序列号，该序列号是由雇员和内部组织（聘用企业）的主键混合而成的。需要这样做是因为不同的信息将记录在工资支付个人方式芝体中，当然，这也取决于工资支付个人方式的类型。9.4支票 既然支付的方法已经建立，是考虑实际支付的时候了。支票实体包含了一个企业需要记录的关于需要支付给它的雇员支票的基本信息。正像在图中看到的那样，这个实体从支付中继承了它所需要的属性，即支付标识、支付参考号码（是一个支票号和电子转账号）、有效日期（支票日期或电子转账日期）、金额和一个可选项备注。 一个支票的金融账号信息在对一张支票存款之后可以确定，可以利用支付金融账号数据模型。这项信息和支付转账号码一起将包含唯一识别一张特殊支票的信息以及了解它存在什么地方的信息。甚至电子存款支票也需要一个源账号和支票号码，这会显示在一张纸上以备确认。有效日期是工资册支付发布的实际日期。在电子存款的情况下，这可以与银行的入账日期对应或不对应。金额是作为支付实体的一部分记录下来的，并且由支票作为支付的总数来继承。支票的净金额能通过从支票中提取的金额以及记录在扣除实体的相关实例中的金额计算出来。9.5扣除和扣除类型 扣除实体存储了关于各种扣除的信息，这些扣除出现在特殊的支票上。扣除类型实体包含一个扣除的合法类型表，这些扣除是企业所允许的或者是法律所要求的。其中包括“联邦税”、“FICA”、“州税”、“401K”、“退休”、“保险”或“自助福利计划”。 扣除类型可以应用到实际的工资册支出上，当它们和扣除相关时。这些扣除表示从实际的工资册支票（或电子转账）中扣除钱的实例。扣除类型也可以用于提供标准扣除。工资册10求职申请 每个雇用都可能从一个求职申请开始。可能需要保存这些申请以确保它们经过正确的审查和处理。这种信息也能为招聘过程提供有价值的分析，并产生有用的信息，例如，接收多少份申请，从什么地方接收（申请源），以及雇用率等等。 图9-10提供了一个数据模型，该模型显示了求职申请的有关信息。每个求职申请可以对应一个职位。这个关系是可选的，因为申请者可能只要求被雇用，而不知道有哪些具体的职位。每个求职申请可以有一个求职申请状态类型和它关联，例如，“接收”、“审查”、“归档”、“拒绝”、“公正通报候选项人”等等。每个求职申请也可以来自于一个求职申请源类型，例如，“报纸”、“人事提名”、“”等等。每个申请都来自县城仅来自一个人员，这个人就是候选人。申请也可以由一个人员查阅，这个人就是候选人的查阅人。图10求职申请 求职申请 人员 求职申请源类型 求职申请状态类型 职位求职申请11雇员技能和资格 人力资源的一个重要方面就是保持对人和组织的技能、资格、培训水平的跟踪。这种信息有助于将当事人按照他们的技能和资格安排到最合适的职位上。 图9-11提供了一个模型，该模型不仅可以帮助维护雇员的技能、资格和培训信息，而且可以帮助维护所有的人和组织的技能、资格和培训信息，这对他们非常有用。每个当事人可以有一个或多个当事例资格或当事人技能实体，因为跟踪这些信息在对一个人或/或一个组织进行评定以指派其职责时是很有用的。为了保存人们所具有的培训水平信息，每个人员可以有一个或多个人员培训实例，这可以说明他或她参加了哪些培训计划。简历实体记录了一个或多个关于每个当事人的背景和资格的正文描述。 可能有人认为，资格、技能和简历应该和人员相关联，而不是和当事人相关联。其实，组织也可以有被认证的资格和它们专长的技能，以及描述它们才能的简历。图11雇员技能和资格 当事人资格 当事人 当事人技能 人员培训 简历 资格类型 技能类型 培训类别类型雇员技能和资格12雇员表现 人力资源的一部分功能就是跟踪雇员随时间变化的工作效果。一般对雇员定期进行评价，关于雇员评估所对应的备注和记录将被保存下来。 图提供了一个数据模型，该模型维护了表现的审查和记录信息，这种信息为对雇员进行审查提供了手段。每个雇员可以是一个或多个表现审查的接受者。接受者是接受表现审查的人。每个雇员表现审查来源于且仅能来源于一个有责任审查的经理。如果企业需要跟踪多个能执行特定审查的经理，那么这种关系就可能是多对多关系。每个雇员表现审查由表现审查项目组成，这些项目表示表现审查中可能提出的各种问题，例如“评估雇员的敏捷性”或“描述雇员的团队风格”。每个表表现现审审查查项项目目表示特定的项目，该项目和审查相关，并伴随一个可能的等级（由于等级类型的关系描述），此外，还有一个备注（如果项目只要求一个描述，那么一些项目可能就没有等级，而只有一个备注）图12a雇员表现 表现审查项目 表现审查项目类型 等级类型 表现审查 支付历史 支票 职位 表现记录 表现记录类型 当事人角色雇员表现 每个雇员可能是一个或多个表现记录的接受者，该记录是对一个雇员的表现进行归档的另一种机制。 图9-12a中维护的信息在大多数企业中对雇员是强制的。也可以对这个模型进行扩充，以包括关于其他人的这些信息。例如，如果企业需要的话，也可能对签约人进行表现审查。一些企业甚至跟踪对组织的表现审查，也就是说，为它们提供物品和服务的那些组织。为了对模型进行扩充，可以将表现记录和表现审查与人员或是当事例建立关系，这取决于组织是否也将接受表现审查和表现记录。 加薪、红利、晋升、降级都是表现审查中可能出现的重要信息。因此，支付历史、支票和职位实体都和审查有关。工资上的加薪和扣薪保存在支付历史的实例中，并且也可能会受到表现审查的影响。红利将被作为一张支票保存下来，并且可能在表现审查中出现。一个职位受到一个表现审查的影响，因为如果审查和每个职位相关的话，那么它可能导致晋升或降级。图12b雇员表现-替代模型 表现审查项目 表现审查项目类型 评估类型 通信事件目的 支付历史 支票 职位 通信事件目的类型 通信事件 通信事件状态类型 当事人关系 联系机制类型 通信事件角色 通信事件角色类型替代模型 图9-12a模型的一个替代模型如图9-12b所示。这个模型保存表现记录和表现审查信息，表现审查是通信事件目的的子类型，相应的通信事件用于描述一个雇用的当事人关系的目的。这个模型也用于这样的事实，即一个表现记录或表现审查可以用于通信事件中的任何当事人。例如，表现记录或审查可以用于签约人，该签约人具有一个通信事件角色：“被审查了的签约人”。 表现记录和审查将被看作通信事件类型吗？答案是肯定的，因为许多同样的属性和关系是可应用的。然而第一个模型（图9-12a）是将表现记录和表现审查作为分离的实体来处理的，因为它们实际不上非常敏感，并且很有可能分开保存。建模者需要决定哪个模型对于企业建模最合适。雇员表现13雇用终止 被解雇可以说是不幸也可以说是幸运，这取决于你如何看待这个问题，总之，我们需要跟踪终止雇用雇员的信息。终止日期、终止原因、终止类型以及可能的后果（例如解雇声明）都是要获取的重要信息。 图9-13可以获得关于雇员雇用终止的信息。正如前面所描述的那样，雇用实体是当事人关系的子类型，该关系是一个雇员和一个内部组织之间的关系。当雇用结束，当事人关系的终止日期存储终止日期。关于终止，当事例关系状态类型的“终止”实例现在用于表示雇用已经结束。终止类型存储什么类型的终止会发生，例如，“辞职”、“辞退”或“退休”。终止原因保存一定的描述来解释终止的原因和情况。例子包括“不服从 ”、“找了新工作”、“无表现”、“搬迁”等等。图13雇员雇用终止 解雇声明 解雇声明状态类型 当事人关系 当事人关系状态类型 终止类型 终止原因 当事人角色雇员雇用终止 解雇声明保存关于解雇声明的信息，它和雇员的终止相关。声明日期显示对解雇声明归档的日期。描述提供关于声明背景的信息和与解雇声明状态类型的关系，解雇声明状态类型保存声明是否“归档”、“未决”、“接收”、“拒绝”或其他重要状态。如果需要一个状态历史，那么模型就需要包括在解雇声明和解雇声明状态类型之间的一个多对多关系中。和解雇声明相关的其他信息取决于企业的需求，例如，所涉及的各种当事人、关于声明的记录、涉及声明的金额等等。 注意雇员本人还没有被“终止”很重要（除非人去世），尽管那是表达这个事实的一般手段。雇用才是已经终止的事情。这就是为什么用当事人关系状态类型来记录终止状态而不用当事人状态的原因，当事人状态只用来记录有关当事人的信息，而不考虑任何关系（这可用来记录每个人是否“死亡”）。雇用终止14 小结 这章讨论了企业运营更复杂的方面之一：跟踪和管理人力资源信息。所涉及的模型允许一个企业更有效地跟踪职位和与雇员及签约人相关的任务。另外，模型还包括用于以下各个方面的元素，它们是职位分类、报告结构、决定支付费用、跟踪和企业相关人员的工资历史、福利跟踪、工资册信息、求职申请、雇员技能、雇员表现和雇员雇用终止。人力资源总体模型期待您的关注，下载文档可以自由编辑！