您的“从入职到离职 - 职位管理”数据模板
您的“从入职到离职 - 职位管理”数据模板
这是我们针对从入职到退休 - 岗位管理的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 针对您的事件日志 data 的标准化结构。
- 推荐用于全面分析的属性和活动。
- 适用于各种源系统的指南。
从入职到退休 - 岗位管理属性
| 名称 | 描述 | ||
|---|---|---|---|
| Event 时间 EventTime | 职位管理流程中特定活动发生的精确日期和时间。这代表了活动的开始时间。 | ||
| 描述 Event Time 是记录活动发生确切时刻的 timestamp。它为整个流程提供了时间轴背景,使得 event 能够按正确顺序排列,从而重构真实的流程流转情况。 此 timestamp 是所有基于时间的分析的基础。它用于计算活动间的周期时间、识别审批步骤的持续时间,并测量从岗位创建到填补的总前置时间。准确的 timestamp 对于“岗位管理周期时间”仪表板和“平均岗位审批周期时间”等 KPI 至关重要。 为何重要 这对于按时间顺序排列 event 以及计算所有基于时长的指标(如周期时间和前置时间)至关重要。 获取方式 通常在源系统内的系统日志、事务记录或文档创建和更改日期字段中找到。 示例 2023-04-15T10:30:00Z2023-06-21T14:05:12Z2024-01-10T09:00:00Z | |||
| 岗位ID PositionId | 组织内特定职位的唯一标识符。这是职位管理流程的主要 Case ID。 | ||
| 描述 职位 ID 是分配给每个职位的唯一键,用于区分彼此。它是连接职位生命周期(从申请到最终关闭)所有活动和事件的中心纽带。 在流程挖掘中,每个事件日志必须有一个 Case ID,以便将相关活动分组到单个流程实例中。通过将职位 ID 用作 Case ID,分析师可以追踪每个职位的完整端到端历程。这实现了流程流的可视化、单个职位周期时间的计算,以及对常见路径或偏差的识别。 为何重要 这对于将所有相关活动归集到单个流程实例中至关重要,从而实现对每个岗位生命周期的端到端分析。 获取方式 通常在职位管理或人力资源信息系统 (HRIS) 模块的标题或主记录中找到。 示例 POS-0012586003491-FINMKTG-SR-ANALYST-2 | |||
| 活动名称 ActivityName | 在职位管理流程中,特定时间点发生的业务事件、任务或状态变更的名称。 | ||
| 描述 “活动名称”描述了岗位管理生命周期中采取的单个步骤或操作。这些活动构成了流程图的基石,代表了关键 event,如“岗位请求已发起”、“预算审批已通过”或“岗位已关闭”。 在分析中,追踪这些活动可以实现整个流程流的可视化。它有助于识别事件序列、发现流程变体,并精准定位瓶颈或返工循环(例如反复出现的“岗位请求已送回返工”活动)。活动名称的清晰性和一致性对于构建准确且易于理解的流程模型至关重要。 为何重要 此属性是构建流程图、识别瓶颈以及了解职位生命周期中事件顺序的基础。 获取方式 根据 HR 或岗位管理系统中的事件日志、状态变更表或交易代码生成。 示例 岗位请求已发起经理审批已通过岗位已填补岗位已重分类 | |||
| 最后数据更新 LastDataUpdate | 表示流程挖掘数据集中此事件数据最后一次刷新或更新的时间戳。 | ||
| 描述 此属性记录数据集上次从源系统更新的时间。这是一个元数据字段,为所分析数据的时效性和现势性提供了重要背景。 分析师利用此信息了解分析所涵盖的时间范围,并确认其使用的是最新可用数据。对于持续的流程监控,了解上次更新时间对于确保仪表板和 KPI 反映当前的运营状态,以及确保得出的结论基于及时信息至关重要。 为何重要 它向分析师告知 data 的及时性,确保分析结果具有相关性并基于最新的可用信息。 获取方式 此时间戳通常在数据提取和转换 (ETL) 过程中生成并存储。 示例 2024-07-20T02:00:00Z2024-07-19T02:00:00Z2024-07-18T02:00:00Z | |||
| 源系统 SourceSystem | 提取事件数据的系统名称或标识符,例如核心 HRIS 或专门的招聘模块。 | ||
| 描述 “Source System”属性识别流程数据的来源。在许多组织中,“从入职到离职”流程跨越多个应用,例如用于职位管理的核心 HR 系统和用于招聘的独立申请人追踪系统 (ATS)。 在合并来自不同来源的数据以创建统一流程视图时,指定源系统至关重要。它有助于数据验证、排查集成问题,并了解不同系统对整体流程的贡献。这可以揭示在系统交接时发生的延迟或数据差异。 为何重要 它提供了关于 data 来源的背景信息,这对于数据验证以及分析跨多个集成系统的流程至关重要。 获取方式 此信息通常在数据提取的元数据中可用,或者可以在数据转换过程中作为静态值添加。 示例 Workday HCMSAP SuccessFactorsOracle Fusion HCMDynamics 365 HR | |||
| 岗位状态 PositionStatus | event 发生时岗位的当前或历史状态,例如“开放”、“已填补”、“已冻结”或“已关闭”。 | ||
| 描述 “岗位状态”表示岗位在其生命周期中所处的状态。该属性是动态的,随着流程的推进而变化。例如,岗位可能最初为“待审批”,然后变为“开放 - 招聘中”,接着变为“已填补”,最后变为“已关闭”。 此属性对于基于状态的分析以及“陈旧与非激活岗位分析”等仪表板至关重要。通过分析在各状态下停留的时间,组织可以识别瓶颈,例如长期处于“开放”状态的岗位。它还有助于容量规划并了解整个人才储备库的健康状况。 为何重要 它支持分析岗位在各状态下停留的时长,这对于识别陈旧岗位和管理人才规划至关重要。 获取方式 通常存储在主职位记录中,并随着状态变更活动的发生而更新。 示例 开放 - 招聘中等待审批已填补已冻结已结案 | |||
| 成本中心 CostCenter | 岗位成本所属部门或组的财务代码或标识符。 | ||
| 描述 “成本中心”是一个财务维度,将岗位与组织会计科目表中的特定预算实体关联起来。它用于与员工人数和人事支出相关的财务规划、预算编制和报表。 从 Process Mining 的角度来看,成本中心允许从财务视角分析岗位管理流程。它有助于识别某些成本中心是否经历了更频繁的岗位变更、更长的审批时间,或是否与更高的招聘成本相关。这对于预算执行分析以及了解岗位管理决策的财务影响特别有用。 为何重要 它将岗位与财务实体关联,从而支持按预算区域分析流程绩效和成本。 获取方式 可在 HR 或 ERP 系统的岗位记录中的财务或组织分配详情里找到。 示例 CC-451001002-FIN-US78345SALES-WEST | |||
| 用户名称 UserName | 执行活动或与事件相关的用户的名称或唯一标识符。 | ||
| 描述 “User Name”识别执行流程中特定任务的个人员工,例如经理、人力资源业务合作伙伴或预算所有者。这可能是申请职位、审批步骤或修改职位详情的人。 此属性对于任何有关资源绩效、工作负载分布和合规性的分析都至关重要。它有助于回答诸如“哪些用户处理的申请最多?”或“特定审批人是否存在延迟?”等问题。它还用于职责分离分析,以确保关键任务不由同一人执行。 为何重要 它支持分析工作负荷分配、用户表现和合规性,有助于识别培训需求或资源限制。 获取方式 通常在事务详情、变更日志或审计轨迹中可用,通常通过用户 ID 关联。 示例 j.doeEmily.WhiteU789123陈大卫 | |||
| 经理姓名 ManagerName | 招聘经理或职位所属上级经理的姓名。 | ||
| 描述 “经理姓名”识别了将在新岗位上监督员工的个人。这通常是发起请求的人,也是审批和招聘流程中的关键利益相关者。 此属性是“审批瓶颈分析”仪表板的核心。通过按经理对活动进行分组,可以识别出可能成为流程瓶颈的个人(无论是由于工作负荷过重还是需要额外培训)。这还有助于了解管理层在流程中的参与程度和决策模式。 为何重要 它能识别岗位的关键利益相关者,从而支持分析审批延迟和特定经理的流程模式。 获取方式 可在岗位详情中找到,通常作为汇报结构或组织分配的一部分。 示例 Robert SmithMaria Garcia陈伟Priya Patel | |||
| 结束时间 EndTime | 表示活动完成的时间戳。用于计算单个活动的处理时间。 | ||
| 描述 虽然“事件时间”标志着活动的开始,但“结束时间”标志着活动的完成。两者之间的差值代表了该特定任务的处理时间或持续时长。对于瞬时发生的事件,结束时间可能与开始时间相同。 在分析中,此属性对于确定流程中哪些特定活动消耗的时间最多至关重要。它有助于识别低效步骤并支持详细的瓶颈分析。例如,通过分析审批步骤的结束时间,组织可以确定哪些审批耗时最长,并据此集中力量进行改进。 为何重要 它支持计算单个活动的处理时间,有助于识别哪些特定任务最为耗时。 获取方式 通常在系统事件日志或交易数据中与开始时间并列。它也可以推导为后续 event 的开始时间。 示例 2023-04-15T11:05:14Z2023-06-21T14:10:00Z2024-01-10T09:00:00Z | |||
| 职位名称 JobTitle | 与该职位相关的正式职衔,例如“高级软件工程师”或“市场经理”。 | ||
| 描述 “职位名称”描述了岗位的角色或职能。虽然一个职位名称可能对应多个岗位,但此属性为所管理的岗位性质提供了重要背景。 按职位名称或更广泛的职类进行分析,可以揭示特定角色类型的模式。例如,与初级岗位相比,高级或高度专业化的角色可能具有更长的审批周期或更复杂的招聘流程。这些信息对于定制招聘策略和设定合理的时间表非常有价值。 为何重要 它提供了关于角色的背景信息,支持分析不同职位类型、级别或职能之间的流程差异。 获取方式 存储在岗位主数据中,通常链接到 HR 系统中的中央职位目录或职位说明。 示例 高级会计产品经理数据科学家HR业务伙伴 | |||
| 部门 Department | 岗位所属的部门、业务单元或组织单位。 | ||
| 描述 “部门”属性通过将每个岗位分配到特定的业务部分(如“财务”、“工程”或“销售”)来提供组织背景。这支持在公司的不同领域之间对岗位管理流程进行细分和比较。 在分析中,按部门进行筛选或分组是一种强大的技术。它有助于识别流程绩效的差异,例如某些部门的审批时间较长或返工率较高。这些见解可以指导有针对性的流程改进方案,并挖掘高绩效部门的最佳实践,以便在全公司范围内分享。 为何重要 它支持跨业务单元的流程对比,有助于识别效率、合规性和成本方面的差异。 获取方式 可在 HR 系统中的岗位主数据或组织管理模块中找到。 示例 财务研发市场营销客户支持 | |||
| 变更原因 ChangeReason | 当岗位请求被拒绝、送回返工或其属性被修改时提供的依据。 | ||
| 描述 “变更原因”记录了流程中特定(通常是非标准)event 的解释。这包括拒绝请求的原因、重分类的依据,或请求退回给发起人修改时提供的备注。 这些定性 data 对根本原因分析极具价值。它解释了流程偏差背后的“原因”。例如,通过分析拒绝原因,可以发现岗位请求中的普遍问题,如缺少预算信息或职位描述不清晰。这一见解是提高“一次成功率”和降低“岗位返工率”的关键。 为何重要 它为理解返工、拒绝和其他偏差提供了关键背景,从而支持针对性的根本原因分析和流程改进。 获取方式 通常在与拒绝、返工或修改事务相关的评论字段、备注或特定原因代码字段中找到。 示例 预算未获批准选定的职位说明有误组织调整请求详情不完整 | |||
| 地点 Location | 职位所在的物理位置、地理位置或区域。 | ||
| 描述 “地点”属性指定了与职位相关的办公室、城市、省份或国家。这些地理信息是了解招聘流程和人力资源分布区域差异的关键。 通过地点维度分析流程可以揭示重要洞察。例如,它可以发现由于当地劳动力市场状况、各国不同的审批层级,或某些地区增加步骤的合规要求而导致的周期时间差异。这种分析支持全球流程标准化工作,同时兼顾必要的本地化差异。 为何重要 它支持地理分析,以揭示流程效率、招聘需求和合规要求在不同地区的差异。 获取方式 作为组织详情的一部分存储在岗位主数据中。 示例 美国纽约德国柏林新加坡伦敦办公室 | |||
| 招聘需求ID RequisitionId | 与职位关联的招聘申请的唯一标识符,将其与招聘流程相连接。 | ||
| 描述 招聘申请 ID 是连接职位管理流程和招聘流程的桥梁。一旦职位获批并准备填补,通常会创建招聘申请以正式启动招聘活动。 包含此标识符对于实现“从入职到离职”周期的真实端到端视图至关重要。它允许将职位创建和审批数据与下游招聘数据(如候选人寻访、面试和录用)连接起来。这种关联使得分析从最初申请到候选人入职的总填补时间成为可能。 为何重要 它将岗位与招聘流程关联,从而支持对整个人才获取生命周期进行更广泛的端到端分析。 获取方式 通常由申请人追踪系统 (ATS) 或招聘模块生成,并链接到核心 HRIS 中的职位记录。 示例 REQ-2024-05-201JR102345R-0098778553 | |||
| 职类 JobFamily | 对具有相似职能、技能或属于同一专业领域的岗位进行的高层级分组。 | ||
| 描述 “职类”是将相关职位名称进行分组的一种分类方式。例如,“软件工程师”、“QA 测试员”和“运维工程师”都可能属于“工程”职类。这提供了一种比具体职位名称更宏观的分类和分析维度。 在分析中使用职类可以获取人才趋势和流程效率的战略视角。它能帮助组织对比不同部门(如“财务”与“IT”)的岗位管理生命周期。这有助于发现职能特定的瓶颈或最佳实践,并为战略性人才规划提供依据。 为何重要 通过对相似职位进行分组来实现高层级分析,有助于了解不同公司职能部门的流程趋势。 获取方式 在组织的职位目录或架构中定义,并作为属性存储在职位说明或岗位记录中。 示例 工程部财务与会计销售人力资源 | |||
从入职到退休 - 岗位管理活动
| 活动 | 描述 | ||
|---|---|---|---|
| HR 审批已通过 | 代表人力资源部门的最终批准,确认该岗位符合公司政策、职等和薪酬架构。这通常是正式创建岗位前的最后一道审批。 | ||
| 为何重要 作为最后的关口,这一阶段的延迟可能会成为主要瓶颈。分析此步骤对于了解 HR 运营中的流程效率和合规执行情况至关重要。 获取方式 这作为职位创建工作流中最终审批任务的完成而被捕获,通常由 HR 合作伙伴或管理员执行。 捕获 在工作流历史中识别 HR 特定审批任务完成时的 timestamp。 事件类型 explicit | |||
| 岗位已停用 | 职位被设为失效状态,通常发生在员工离职且没有立即补人计划时。失效职位会从活跃组织架构图中移除,但在系统中保留以供历史参考。 | ||
| 为何重要 此活动有助于管理人力编制并确保组织架构图的准确性。职位空缺到停用之间的时间可以反映劳动力规划的效率。 获取方式 这是根据职位记录的状态更改为“失效”或“已停用”以及相应的生效日期来推断的。 捕获 当岗位状态变更为表示不再激活的值时,捕获其 timestamp。 事件类型 inferred | |||
| 岗位已关闭 | 代表从组织架构中永久消除或归档该岗位。这是岗位生命周期中的最后一个 event,意味着它将不再被使用。 | ||
| 为何重要 这是终结活动,完成了职位的生命周期。分析已关闭的职位对于了解长期组织设计和战略性裁员非常重要。 获取方式 这通常是“关闭”或“取消”职位的明确操作或业务流程,从工作流日志或状态变更历史中捕获。 捕获 查找“关闭岗位”业务流程的完成 event,或查找最终状态变更为“已关闭”或“已消除”的记录。 事件类型 explicit | |||
| 岗位已创建 | 标志着在获得所有必要批准后,在核心 HR 系统中正式创建了岗位记录。该岗位现在正式成为组织架构的一部分,并拥有唯一的标识符。 | ||
| 为何重要 这是一个关键里程碑,标志着审批阶段的结束和职位活跃期的开始。从“申请启动”到“职位创建”的时间是一个关键绩效指标。 获取方式 这是从主 HR 数据表中主要职位记录或对象的创建时间戳捕获的。 捕获 使用主职位表或对象中的“创建日期”或“系统创建时间”时间戳。 事件类型 explicit | |||
| 岗位已填补 | 代表招聘流程的成功结果,即已有候选人入职或内部员工已调入该岗位。该岗位现已被占用。 | ||
| 为何重要 这是职位生命周期中的一个关键成功里程碑。衡量从“职位激活”到“职位填补”的时间是整体招聘时间指标的重要组成部分。 获取方式 此事件在成功完成将员工 ID 链接到职位 ID 的“入职”或“人员配置”业务流程后捕获。 捕获 使用将员工分配到该职位的入职或调动操作的生效日期。 事件类型 explicit | |||
| 岗位已激活 | 标志着岗位正式开放并可用于人员配置操作(如发布职位申请)的时刻。这表示该岗位已准备好进入招聘流程。 | ||
| 为何重要 此事件是职位管理到人才招聘的关键交接点。激活已创建职位所需的时间可以凸显运营准备方面的延迟。 获取方式 这通常根据职位记录的状态字段更改为“活跃”、“空缺”或类似状态,以及该变更的生效日期来推断。 捕获 当岗位状态码变更为表示已激活且开放招聘的值时,捕获其 timestamp。 事件类型 inferred | |||
| 岗位请求已发起 | 标志着岗位管理流程的正式开始。当用户(通常是招聘经理)通过 HR 系统提交新岗位或补缺岗位的请求时,会捕获此 event。 | ||
| 为何重要 此活动是衡量整个职位创建周期时间的主要起点。分析这些申请的数量和时间有助于资源规划,并了解组织增长或重组的趋势。 获取方式 此事件通常从工作流系统或记录新职位申请表提交的审计日志表中捕获。 捕获 识别岗位请求记录的创建 event 或相关业务流程工作流中的起始步骤。 事件类型 explicit | |||
| 岗位属性已修改 | 代表对现有岗位的描述性属性所做的任何更改,例如其名称、部门或地点。此类活动通常发生在岗位创建之后。 | ||
| 为何重要 岗位创建后的频繁修改可能表明初始数据质量存在问题或组织不稳定。分析这些变更不仅有助于了解审批后调整的性质,还能掌握其发生的频率。 获取方式 此活动通常通过跟踪职位记录的系统审计日志或变更历史表中的更改来推断。 捕获 通过监控变更日志或使用岗位数据的前后快照来检测关键字段的修改。 事件类型 inferred | |||
| 岗位已冻结 | 表示已激活的岗位已被暂时挂起,防止对其进行任何招聘或其他人员配置操作。这通常是由于预算调整或战略优先级变更引起的。 | ||
| 为何重要 跟踪职位的冻结时间和原因可以深入了解组织的波动情况和预算冻结。它有助于识别处于空缺状态但未被填补的“陈旧”职位。 获取方式 这是根据核心 HR 系统中职位状态更改为“冻结”、“暂停”或“中止”来推断的。 捕获 当岗位状态更新为反映“冻结”或“挂起”状态时,捕获其 timestamp。 事件类型 inferred | |||
| 岗位已重分类 | 这是一项重大更新,涉及岗位基本分类的变更,例如职类、职等或职级。这比简单的属性修改更为关键,可能需要独立的审批流程。 | ||
| 为何重要 重分类会影响薪酬、职业路径和组织架构。追踪这些 event 有助于分析组织设计变更和职位架构的敏捷性。 获取方式 这可以通过专门的业务流程捕获,或者从职位记录变更历史中特定职位分类字段的更改中推断。 捕获 查找“职位重分类”工作流的完成情况,或跟踪“职位说明”、“职等”或“职位代码”等字段的变更。 事件类型 explicit | |||
| 岗位招聘已发起 | 表示已激活岗位的招聘流程已正式开始。这通常以创建与该岗位关联的职位申请为标志。 | ||
| 为何重要 此活动连接了职位管理流程与招聘流程。分析职位激活与招聘启动之间的时间可以揭示交接过程中的潜在差距。 获取方式 通常在招聘模块中创建新的招聘申请记录并链接回特定职位标识符时捕获。 捕获 使用与职位 ID 关联的招聘申请记录的创建时间戳。 事件类型 explicit | |||
| 岗位请求已送回返工 | 表示审批人已将岗位请求退回至之前的步骤以进行修改或澄清。此操作在流程中创建了一个循环,要求发起人修订并重新提交请求。 | ||
| 为何重要 此活动是衡量返工和流程效率低下的直接指标。返工循环频率过高表明需求不明确、数据输入错误或部门间协作不力。 获取方式 这是大多数工作流系统中的明确操作,当审批人选择“退回”或“请求修订”选项时,会记录在事件日志中。 捕获 捕获工作流状态恢复到前一步骤或记录了特定“退回”操作的 event。 事件类型 explicit | |||
| 岗位请求被拒绝 | 表示岗位请求已在流程的任何阶段被审批人正式拒绝。对于该请求而言,这是一个终结 event,后续将停止所有进展。 | ||
| 为何重要 跟踪拒绝情况有助于量化“一次通过率”,并揭示申请失败的原因,如预算限制或战略不一致。这种分析可以提高未来申请的质量。 获取方式 当审批人选择“拒绝”或“驳回”操作时,这会明确记录在工作流历史中。 捕获 识别与“已拒绝”状态相关的 timestamp,或执行“拒绝”工作流操作时的 timestamp。 事件类型 explicit | |||
| 经理审批已通过 | 代表第一级审批,由请求经理或部门负责人完成。这确认了团队或部门内对该岗位的业务需求。 | ||
| 为何重要 跟踪此步骤有助于识别审批流程初始阶段的瓶颈。此处的延迟会显著影响整体职位填补指标。 获取方式 这通常记录为职位申请工作流历史中的特定状态更新或审批任务完成事件。 捕获 在工作流日志中捕获当经理的审批任务被标记为“已完成”或“已批准”时的 timestamp。 事件类型 explicit | |||
| 预算审批已通过 | 这是一个关键里程碑,由财务部门或预算负责人确认新岗位资金可用且已分配。此步骤验证了该请求在财务上的可行性。 | ||
| 为何重要 此活动对财务治理至关重要,有助于分析与预算相关的延迟。了解财务审批的周期时间可以揭示预算编制或预测流程中的问题。 获取方式 通常作为工作流中一个独特的审批步骤完成事件捕获,通常分配给财务角色的用户。 捕获 查找表示“预算审批”或“财务审核”步骤已完成的工作流事件日志。 事件类型 explicit | |||