採用から退職までのポジション管理用データテンプレート
採用から退職までのポジション管理用データテンプレート
これは採用から退職まで:ポジション管理向けの汎用プロセスマイニング用データテンプレートです。より詳しい手順については、システム別のテンプレートをご利用ください。
特定のシステムを選択- イベントログデータの標準構成
- 詳細な分析に推奨される属性とアクティビティ
- さまざまなソースシステムに対応するガイダンス
採用から退職までのポジション管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | ポジション管理プロセスで、特定の時点に発生した業務イベント、タスク、またはステータス変更の名前です。 | ||
| 説明 アクティビティ名は、ポジションのライフサイクルにおける個々の手順や操作を表します。これらのアクティビティがプロセスマップの構成要素となり、「ポジション依頼の開始」「予算承認の受領」「ポジションの終了」などの主要なイベントを示します。 分析では、アクティビティを追跡することで、プロセス全体の流れを可視化できます。イベントの順序を把握し、プロセスのバリアントを見つけ、ボトルネックや手戻りの繰り返しを特定するのに役立ちます。たとえば、「ポジション依頼の修正差し戻し」が何度も発生している状況を確認できます。正確でわかりやすいプロセスモデルを作成するには、アクティビティ名を明確かつ一貫したものにすることが大切です。 重要な理由 プロセスマップの作成、ボトルネックの特定、ポジションのライフサイクルにおけるイベントの順序の把握に欠かせない属性です。 入手先 人事システムやポジション管理システムのイベントログ、ステータス変更テーブル、またはトランザクションコードから生成されます。 例 ポジション申請の開始マネージャーの承認ポジションの充足ポジションの再分類 | |||
| イベント時刻 EventTime | ポジション管理プロセスの特定のアクティビティが発生した正確な日時です。アクティビティの開始時刻を示します。 | ||
| 説明 イベント時刻は、アクティビティが発生した正確な時点を記録するタイムスタンプです。プロセス全体の時系列を示し、イベントを正しい順序に並べて、実際のプロセスフローを再現できます。 このタイムスタンプは、時間に基づく分析の基礎となります。アクティビティ間のサイクルタイムや承認手順にかかる時間を算出し、ポジションの作成から充足までのリードタイムを測定するために使います。正確なタイムスタンプは、「ポジション管理のサイクルタイム」などのダッシュボードや、「ポジション承認の平均サイクルタイム」などの重要業績評価指標(KPI)に欠かせません。 重要な理由 イベントを時系列に並べ、サイクルタイムやリードタイムなど、所要時間に基づく指標を算出するために欠かせません。 入手先 通常、ソースシステムのシステムログ、トランザクションレコード、または文書の作成日・変更日フィールドにあります。 例 2023-04-15T10:30:00Z2023-06-21T14:05:12Z2024-01-10T09:00:00Z | |||
| ポジションID PositionId | 組織内の個々のポジションを識別する一意のIDです。ポジション管理プロセスの主要なケース識別子として使用されます。 | ||
| 説明 ポジションIDは、各ポジションをほかのポジションと区別するために割り当てられる一意のキーです。依頼の開始から最終的な終了まで、1つのポジションのライフサイクルに関わるすべてのアクティビティとイベントを結び付けます。 プロセスマイニングでは、関連するアクティビティを1つのプロセスインスタンスにまとめるため、各イベントログにケース識別子が必要です。ポジションIDをケースIDとして使うと、分析担当者は各ポジションの一連の流れを最初から最後まで追跡できます。これにより、プロセスフローを可視化し、個々のポジションのサイクルタイムを算出して、よく見られる経路や逸脱を特定できます。 重要な理由 関連するすべてのアクティビティを1つのプロセスインスタンスにまとめ、各ポジションのライフサイクルを最初から最後まで分析するために欠かせません。 入手先 通常、ポジション管理または人事情報システム(HRIS)モジュールのヘッダーや主要レコードにあります。 例 POS-0012586003491-FINMKTG-SR-ANALYST-2 | |||
| ソースシステム SourceSystem | イベントデータの抽出元となったシステムの名前または識別子です。基幹人事情報システム(HRIS)や採用管理モジュールなどが該当します。 | ||
| 説明 ソースシステム属性は、プロセスデータの取得元を示します。多くの組織では、採用から退職までのプロセスが複数のアプリケーションにまたがります。たとえば、ポジション管理には基幹人事システムを、採用には別の応募者追跡システム(ATS)を使う場合があります。 複数のソースからデータを集めてプロセス全体を把握するには、ソースシステムを指定することが重要です。データの検証や連携時の問題の調査に役立つほか、各システムがプロセス全体でどのような役割を担っているかを把握できます。また、システム間の引き継ぎで発生する遅延やデータの不一致を見つける手がかりにもなります。 重要な理由 データの取得元を把握できるため、データの検証や、複数のシステムにまたがるプロセスの分析に役立ちます。 入手先 通常、データ抽出ファイルのメタデータに含まれています。データ変換時に固定値として追加することもできます。 例 Workday HCMSAP SuccessFactorsOracle Fusion HCMDynamics 365 HR | |||
| 最終データ更新 LastDataUpdate | プロセスマイニング用データセットのイベントデータが最後に更新または再読み込みされた時刻を示すタイムスタンプです。 | ||
| 説明 この属性には、ソースシステムからデータセットが最後に更新された時刻が記録されます。分析対象データの新しさや最新性を把握するためのメタデータです。 分析担当者はこの情報を使って、分析対象期間を確認し、利用可能な最新のデータを使っているかを確かめます。プロセスを継続的に監視する場合、最終更新時刻を把握することが欠かせません。ダッシュボードや重要業績評価指標(KPI)が業務の現状を反映していること、また、結論が最新の情報に基づいていることを確認できます。 重要な理由 データがいつ時点のものかを分析担当者が把握できるため、分析の妥当性を保ち、利用可能な最新情報に基づいて検討できます。 入手先 通常、データ抽出・変換(ETL)プロセスで生成、保存されるタイムスタンプです。 例 2024-07-20T02:00:00Z2024-07-19T02:00:00Z2024-07-18T02:00:00Z | |||
| コストセンター CostCenter | ポジションにかかる費用の配賦先となる部門やグループを示す財務コードまたは識別子です。 | ||
| 説明 コストセンターは、ポジションを組織の勘定科目体系における特定の予算単位に紐付ける財務上の区分です。人員数や人件費に関する財務計画、予算編成、レポーティングに使われます。 プロセスマイニングでは、コストセンターを使って、ポジション管理プロセスを財務の観点から分析できます。特定のコストセンターでポジションの変更が頻繁に発生しているか、承認に時間がかかっているか、採用コストが高いかを把握できます。予算の遵守状況を分析し、ポジション管理の判断が財務に与える影響を理解するうえで特に役立ちます。 重要な理由 ポジションを財務上の単位に紐付け、予算領域ごとのプロセスパフォーマンスやコストを分析できます。 入手先 人事システムまたはERPシステムのポジションレコードにある、財務または組織上の割り当て情報に記載されています。 例 CC-451001002-FIN-US78345SALES-WEST | |||
| ポジションのステータス PositionStatus | イベント発生時点でのポジションの現在または過去のステータスです。「募集中」「充足」「凍結」「終了」などがあります。 | ||
| 説明 ポジションのステータスは、ライフサイクルにおけるポジションの状態を示します。この属性は、ポジションがプロセスを進むにつれて変化します。たとえば、「承認待ち」から「募集中」に進み、「充足」を経て、最終的に「終了」となる場合があります。 この属性は、ステータスに基づく分析や、「長期未更新・非アクティブなポジションの分析」などのダッシュボードに欠かせません。各ステータスにとどまる期間を分析すると、「募集中」のまま長期間進展しないポジションなど、ボトルネックを特定できます。また、人員計画や人材パイプライン全体の状況を把握するのにも役立ちます。 重要な理由 ポジションが各状態にとどまる期間を分析できるため、長期間更新されていないポジションの特定や人員計画の管理に役立ちます。 入手先 通常、ポジションのメインレコードに保存され、ステータスを変更するアクティビティが発生するたびに更新されます。 例 募集中承認待ち充足凍結終了 | |||
| マネージャー名 ManagerName | 採用マネージャー、またはポジションの直属の上司の名前です。 | ||
| 説明 マネージャー名は、新しいポジションに就く従業員を監督する人を示します。多くの場合、依頼を開始する人であり、承認や採用プロセスにおける主要な関係者です。 この属性は、「承認ボトルネック分析」ダッシュボードの中心となります。アクティビティをマネージャーごとにグループ化すると、業務量や追加研修の必要性が原因で、プロセスのボトルネックになっている可能性のある人を特定できます。また、プロセスにおける管理職の関与や意思決定の傾向を把握するのにも役立ちます。 重要な理由 ポジションに関わる主要な関係者を特定し、承認の遅延やマネージャーごとのプロセスの傾向を分析できます。 入手先 ポジションの詳細情報にあり、報告系統や組織上の割り当て情報の一部として記載されていることがよくあります。 例 Robert SmithMaria GarciaChen WeiPriya Patel | |||
| ユーザー名 UserName | アクティビティを実行したユーザー、またはイベントに関連付けられたユーザーの名前や一意の識別子です。 | ||
| 説明 ユーザー名は、マネージャー、人事ビジネスパートナー、予算責任者など、プロセス内の特定のタスクを実行した従業員を識別します。ポジションを依頼した人、手順を承認した人、ポジションの詳細を変更した人などが該当します。 この属性は、リソースパフォーマンス、業務量の分布、コンプライアンスに関する分析に欠かせません。「最も多くの依頼を処理しているのは誰か」「特定の承認者に関連する遅延があるか」といった疑問に答えるのに役立ちます。また、重要なタスクを同じ人が実行していないことを確認する職務分掌の分析にも使われます。 重要な理由 業務量の分布、ユーザーのパフォーマンス、コンプライアンスを分析し、研修の必要性やリソース不足の特定に役立ちます。 入手先 通常、トランザクションの詳細、変更ログ、監査証跡にあり、多くの場合ユーザーIDと紐付いています。 例 j.doeEmily.WhiteU789123David Chen | |||
| 終了時刻 EndTime | アクティビティが完了した時刻を示すタイムスタンプです。個々のアクティビティの処理時間を算出するために使います。 | ||
| 説明 イベント時刻がアクティビティの開始を示すのに対し、終了時刻は完了した時点を示します。この2つの時刻の差が、そのタスクの処理時間または所要時間です。瞬時に完了するイベントでは、終了時刻と開始時刻が同じ場合があります。 分析では、プロセス内で特に時間がかかっているアクティビティを特定するうえで、この属性が役立ちます。非効率な手順を見つけ、ボトルネックを詳しく分析できます。たとえば、承認手順の終了時刻を分析すると、どの承認に最も時間がかかっているかを把握し、改善に取り組む対象を絞り込めます。 重要な理由 個々のアクティビティの処理時間を算出できるため、特に時間がかかっているタスクを特定できます。 入手先 システムのイベントログやトランザクションデータで、開始時刻とともに記録されていることがよくあります。次のイベントの開始時刻から算出することもできます。 例 2023-04-15T11:05:14Z2023-06-21T14:10:00Z2024-01-10T09:00:00Z | |||
| 職務名 JobTitle | ポジションに紐付く正式な職務名です。「シニアソフトウェアエンジニア」や「マーケティングマネージャー」などがあります。 | ||
| 説明 職務名は、ポジションの役割や職務内容を示します。同じ職務名のポジションが複数存在する場合もありますが、この属性から管理対象となる役割の内容を把握できます。 職務名やより大きな職種グループごとにプロセスを分析すると、特定の役割に固有の傾向が見えてきます。たとえば、上級職や専門性の高い職種では、初級職に比べて承認に時間がかかったり、採用プロセスが複雑になったりする場合があります。こうした情報は、採用戦略の調整や現実的なスケジュールの設定に役立ちます。 重要な理由 役割の背景を把握できるため、職種、職位、職務機能によるプロセスの違いを分析できます。 入手先 ポジションのマスターデータに保存され、人事システム内の職務カタログや職務プロファイルに紐付いていることがよくあります。 例 シニア会計士プロダクトマネージャーデータサイエンティスト人事ビジネスパートナー | |||
| 部門 Department | ポジションが属する部門、事業部門、または組織単位です。 | ||
| 説明 部門属性は、各ポジションを「財務」「エンジニアリング」「営業」など、組織内の特定の部門に割り当て、組織上の位置付けを示します。これにより、会社の部門ごとにポジション管理プロセスを分けて比較できます。 分析では、部門で絞り込んだりグループ化したりすることで、プロセスのパフォーマンスの違いを特定できます。たとえば、特定の部門で承認に時間がかかる、手戻り率が高いといった傾向を把握できます。こうした分析結果は、対象を絞ったプロセス改善の取り組みに役立ちます。また、パフォーマンスの高い部門のベストプラクティスを組織内で共有する手がかりにもなります。 重要な理由 異なる事業部門のプロセスを比較し、効率性、コンプライアンス、コストの違いを特定できます。 入手先 人事システムのポジションマスターデータまたは組織管理モジュールにあります。 例 財務研究開発マーケティングカスタマーサポート | |||
| 勤務地 Location | ポジションの勤務地となる物理的な場所、地域、または拠点です。 | ||
| 説明 勤務地属性は、ポジションに紐付くオフィス、都市、州、または国を示します。地域ごとの採用プロセスの違いや人員配置を把握するうえで重要な情報です。 勤務地ごとにプロセスを分析すると、重要な傾向が見えてきます。たとえば、地域の労働市場の状況によるサイクルタイムの違い、国ごとに異なる承認階層、特定地域でプロセスに追加されるコンプライアンス要件などを把握できます。この分析は、必要な地域差に配慮しながら、グローバルなプロセスの標準化を進めるのに役立ちます。 重要な理由 地域ごとのプロセス効率、採用需要、コンプライアンス要件の違いを把握するための地理的な分析に役立ちます。 入手先 組織情報の一部として、ポジションのマスターデータに保存されています。 例 米国ニューヨークドイツ・ベルリンシンガポールロンドンオフィス | |||
| 変更理由 ChangeReason | ポジション依頼の却下や修正差し戻し、または属性の変更時に記録される理由です。 | ||
| 説明 変更理由には、プロセス内で発生した特定の、通常とは異なるイベントの説明が記録されます。依頼を却下した理由、職務を再分類した根拠、変更のため依頼を申請者に差し戻した際のコメントなどが含まれます。 この定性的なデータは、根本原因の分析に役立ちます。プロセス逸脱が起きた理由を把握できるためです。たとえば、却下理由を分析すると、予算情報の不足や職務内容の不明確さなど、ポジション依頼によくある問題が見えてきます。こうした分析結果は、「初回合格率」の向上や「ポジションの手戻り率」の低減に役立ちます。 重要な理由 手戻り、却下、その他の逸脱の背景を把握し、根本原因の分析とプロセス改善の対象を絞り込めます。 入手先 通常、却下、手戻り、変更のトランザクションに関連付けられたコメント欄、メモ、または理由コードのフィールドにあります。 例 予算が承認されていない誤った職務プロファイルが選択された組織再編依頼の詳細が不完全 | |||
| 求人依頼ID RequisitionId | ポジションに紐付く求人依頼の一意の識別子です。採用プロセスとの関連付けに使います。 | ||
| 説明 求人依頼IDは、ポジション管理プロセスと採用プロセスを結び付けます。ポジションの承認後、採用可能な状態になると、通常は採用活動を正式に開始するために求人依頼が作成されます。 採用から退職までの流れを最初から最後まで把握するには、この識別子が欠かせません。ポジションの作成・承認データを、候補者の募集、面接、オファーなど、その後の採用データと結び付けられます。これにより、最初の依頼から候補者の入社日までの採用所要期間を分析できます。 重要な理由 ポジションと採用プロセスを結び付け、人材獲得のライフサイクル全体をより広い視点で分析できます。 入手先 通常、応募者追跡システム(ATS)または採用モジュールで生成され、基幹人事情報システム(HRIS)のポジションレコードに紐付けられます。 例 REQ-2024-05-201JR102345R-0098778553 | |||
| 職種グループ JobFamily | 職務内容、必要なスキル、または専門分野が共通する職務をまとめた大分類です。 | ||
| 説明 職種グループは、関連する職務名をまとめる分類です。たとえば、「ソフトウェアエンジニア」「QAテスター」「DevOpsエンジニア」は、いずれも「エンジニアリング」の職種グループに属する場合があります。個々の職務名より広い単位でポジションを分類、分析できます。 分析に職種グループを使うと、人員の傾向やプロセス効率を戦略的な視点から把握できます。「財務」と「IT」など、異なる職務機能間でポジション管理のライフサイクルを比較できます。職務機能に固有のボトルネックやベストプラクティスを見つけ、人員計画に役立てることができます。 重要な理由 類似する職務をまとめて大きな単位で分析できるため、企業内の異なる職務機能におけるプロセスの傾向を把握できます。 入手先 組織の職務カタログや職務体系で定義され、職務プロファイルまたはポジションレコードの属性として保存されます。 例 エンジニアリング財務・会計営業人事 | |||
採用から退職までのポジション管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| ポジションの作成 | 必要な承認がすべて完了した後、人事の基幹システムにポジションレコードが正式に作成されたことを示します。ポジションは組織構造に正式に加わり、一意の識別子が付与されます。 | ||
| 重要な理由 承認段階の終了と、ポジションのライフサイクルの開始を示す重要な節目です。「申請開始」から「ポジション作成」までの時間は、重要業績評価指標の1つです。 入手先 人事の主要なデータテーブルにあるポジションレコードまたはオブジェクトの作成タイムスタンプから取得します。 記録 主要なポジションテーブルまたはオブジェクトの「作成日」または「システム作成日時」のタイムスタンプを使用します。 イベントタイプ explicit | |||
| ポジションの充足 | 採用が成功し、候補者が採用された、または社内の従業員がそのポジションに異動したことを示します。ポジションは充足された状態です。 | ||
| 重要な理由 ポジションのライフサイクルにおける重要な成功の節目です。「ポジション有効化」から「ポジション充足」までの時間は、採用までの期間を測定するうえで欠かせない要素です。 入手先 従業員IDとポジションIDを紐付ける「採用」または「人員配置」の業務プロセスが正常に完了した時点で、このイベントが記録されます。 記録 従業員をポジションに割り当てる採用または異動の発効日を使用します。 イベントタイプ explicit | |||
| ポジションの有効化 | ポジションが正式に募集可能となり、求人申請の掲載などの採用活動に利用できる状態になった時点を示します。採用プロセスを開始できる状態です。 | ||
| 重要な理由 ポジション管理から人材獲得への重要な引き継ぎ点です。作成済みのポジションを有効化するまでの時間から、業務開始の準備における遅延を把握できます。 入手先 通常、ポジションレコードのステータスが「アクティブ」、「募集中」などに変更されたことと、その変更の有効日から特定します。 記録 ポジションのステータスコードが、採用可能な有効状態を示す値に変更された時点のタイムスタンプを記録します。 イベントタイプ inferred | |||
| ポジションの無効化 | ポジションを非アクティブにします。従業員の退職後、すぐに後任者を補充する予定がない場合などに行われます。非アクティブになったポジションは、組織図から除外されますが、履歴を確認できるようシステムには保持されます。 | ||
| 重要な理由 このアクティビティは、人員数の管理と組織図の正確性の維持に役立ちます。ポジションが空席になってから無効化されるまでの期間は、人員計画の効率性を示す指標になります。 入手先 ポジションのレコードでステータスが「非アクティブ」または「廃止」に変更されたことと、対応する発効日から判断します。 記録 ポジションのステータスが、アクティブではないことを示す値に変更された時刻を記録します。 イベントタイプ inferred | |||
| ポジションの終了 | 組織構造からポジションを恒久的に削除、またはアーカイブすることを示します。ポジションのライフサイクルにおける最終イベントであり、今後使用されないことを意味します。 | ||
| 重要な理由 ポジションのライフサイクルを完了する最終アクティビティです。終了したポジションを分析することで、長期的な組織設計や戦略的な人員削減について理解を深められます。 入手先 通常は、ポジションを「終了」または「廃止」する明示的な操作や業務プロセスです。ワークフローのログやステータス変更履歴から記録されます。 記録 「ポジションの終了」業務プロセスの完了イベント、またはステータスが最終的に「終了」か「廃止」に変更された記録を確認します。 イベントタイプ explicit | |||
| ポジション申請の開始 | ポジション管理プロセスの正式な開始を示します。通常、採用マネージャーが人事システムから新規または後任のポジションを申請した時点で、このイベントが記録されます。 | ||
| 重要な理由 ポジション作成全体のサイクルタイムを測定する際の主な開始点となるアクティビティです。申請の件数やタイミングを分析すると、リソース計画や組織の成長・再編の傾向を把握しやすくなります。 入手先 通常、ワークフローシステムや監査ログテーブルから取得します。新しいポジション申請フォームの提出が記録されます。 記録 ポジション申請レコードの作成イベント、または関連する業務プロセスのワークフローにおける最初の手順を特定します。 イベントタイプ explicit | |||
| 人事部門の承認 | 人事部門による最終承認を示します。ポジションが会社のポリシー、等級、報酬体系に沿っていることを確認します。通常、ポジションが正式に作成される前の最後の承認です。 | ||
| 重要な理由 最終段階のゲートウェイにあたるため、ここでの遅延は大きなボトルネックになる可能性があります。この段階を分析することは、人事業務の効率とコンプライアンス遵守を理解するうえで重要です。 入手先 通常、人事担当者または管理者が行う、ポジション作成ワークフローの最終承認タスクの完了として記録されます。 記録 ワークフロー履歴から、人事部門の承認タスクが完了した時点のタイムスタンプを特定します。 イベントタイプ explicit | |||
| ポジションの再分類 | 職種群、等級、レベルなど、ポジションの基本的な分類を変更する大幅な更新を示します。単純な属性変更よりも影響が大きく、独自の承認プロセスが必要になる場合があります。 | ||
| 重要な理由 再分類は、報酬、キャリアパス、組織構造に影響する可能性があります。こうしたイベントを追跡すると、組織設計の変更や職務体系の柔軟性を分析できます。 入手先 専用の業務プロセスから取得するか、ポジションレコードの変更履歴にある特定の職務分類項目の変更から特定します。 記録 「ポジション再分類」ワークフローの完了を確認するか、「職務プロファイル」、「等級」、「職務コード」などの項目の変更を追跡します。 イベントタイプ explicit | |||
| ポジションの凍結 | 有効なポジションが一時的に保留され、採用やその他の人員配置ができない状態を示します。予算の変更や戦略上の優先順位の見直しが原因となることがあります。 | ||
| 重要な理由 ポジションが凍結された時期と理由を追跡すると、組織の変動や予算凍結に関するインサイトが得られます。募集可能な状態でありながら採用が進んでいない、長期間放置されたポジションも特定できます。 入手先 人事の基幹システムで、ポジションのステータスが「凍結」、「保留」、「一時停止」に変更されたことから特定します。 記録 ポジションのステータスが「凍結」または「保留」を示す状態に更新された時点のタイムスタンプを記録します。 イベントタイプ inferred | |||
| ポジションの採用開始 | 有効なポジションについて、人材獲得プロセスが正式に開始されたことを示します。通常、そのポジションに紐づく求人申請が作成された時点で記録されます。 | ||
| 重要な理由 ポジション管理プロセスと採用プロセスをつなぐアクティビティです。ポジションの有効化から採用開始までの時間を分析すると、引き継ぎにおける問題を特定できます。 入手先 通常、採用管理モジュールで新しい求人申請レコードが作成され、特定のポジション識別子に紐づけられた時点で記録されます。 記録 ポジションIDに紐づく求人申請レコードの作成タイムスタンプを使用します。 イベントタイプ explicit | |||
| ポジション属性の変更 | 既存のポジションの説明的な属性、たとえば役職名、部門、勤務地などに加えられた変更を示します。通常、ポジションの作成後に発生します。 | ||
| 重要な理由 作成後に頻繁な変更がある場合、初期データの品質に問題がある、または組織が不安定である可能性があります。変更を分析すると、承認後の調整の内容や頻度を把握できます。 入手先 通常、ポジションレコードの監査ログや変更履歴テーブルを追跡して、このアクティビティを特定します。 記録 変更ログを確認するか、ポジションデータの変更前後のスナップショットを使って、重要な項目の変更を検出します。 イベントタイプ inferred | |||
| ポジション申請の却下 | プロセスのいずれかの段階で、承認者がポジション申請を正式に却下したことを示します。申請の終了イベントであり、それ以降の進行は停止します。 | ||
| 重要な理由 却下を追跡すると、「初回承認率」を定量化し、予算上の制約や戦略との不一致など、申請が承認されなかった理由を明らかにできます。この分析は、今後の申請の質を高めるのに役立ちます。 入手先 承認者が「却下」または「拒否」のアクションを選択した時点で、ワークフロー履歴に明示的に記録されます。 記録 「却下」ステータスに関連付けられたタイムスタンプ、またはワークフローの「却下」アクションが実行された時点を特定します。 イベントタイプ explicit | |||
| ポジション申請を差し戻し | 承認者が、修正や確認のためにポジション申請を前の段階に差し戻したことを示します。申請者は内容を修正して再申請する必要があるため、プロセスにループが生じます。 | ||
| 重要な理由 このアクティビティは、手戻りとプロセスの非効率を直接示します。手戻りのループが頻繁に発生する場合、要件が不明確である、データ入力ミスがある、部門間の認識が一致していないといった問題が考えられます。 入手先 多くのワークフローシステムでは明示的なアクションとして記録されます。承認者が「差し戻し」または「修正依頼」を選択した時点で、イベントログに記録されます。 記録 ワークフローのステータスが前の段階に戻ったイベント、または「差し戻し」アクションが記録されたイベントを取得します。 イベントタイプ explicit | |||
| マネージャーの承認 | 申請したマネージャーまたは部門長が行う、最初の承認段階を示します。チームまたは部門におけるポジションの必要性を確認します。 | ||
| 重要な理由 この段階を追跡すると、承認プロセスの初期段階にあるボトルネックを特定できます。ここでの遅延は、採用充足までの期間に大きく影響する可能性があります。 入手先 通常、ポジション申請のワークフロー履歴に、特定のステータス更新または承認タスクの完了イベントとして記録されます。 記録 ワークフローログで、マネージャーの承認タスクが「完了」または「承認済み」になった時点のタイムスタンプを記録します。 イベントタイプ explicit | |||
| 予算の承認 | 財務部門または予算責任者が、新しいポジションに必要な資金が確保され、割り当てられていることを確認する重要な節目です。この段階で、申請の財務面での実現可能性を確認します。 | ||
| 重要な理由 財務ガバナンスに欠かせないアクティビティであり、予算に関する遅延の分析にも役立ちます。財務承認のサイクルタイムを把握すると、予算編成や予測プロセスの問題が明らかになることがあります。 入手先 通常、ワークフロー内の独立した承認手順の完了イベントとして記録され、財務担当のユーザーに割り当てられます。 記録 「予算承認」または「財務確認」の手順が完了したことを示すワークフローイベントログを確認します。 イベントタイプ explicit | |||
データ抽出ガイド
データの抽出方法はシステムによって異なります。詳しい手順は、
準備はできましたか?
汎用テンプレートを使うか、特定のシステム向けガイドを選んでデータ抽出を始め、採用から退職までのポジション管理を分析しましょう。
採用から退職までのポジション管理を今すぐ効率化
人員構成を明確に把握し、エラーを減らしてコストをすばやく最適化できます。
クレジットカード不要、5分でセットアップできます。