採用から退職まで：役職管理のデータテンプレート

アクティビティ名は、ポジション管理のライフサイクルにおける1つの手順や実行されたアクションを表します。これらのアクティビティはプロセスマップの構成要素となり、「ポジション申請開始」「予算承認受領」「ポジション終了」などの主要なイベントを示します。

分析では、アクティビティを追跡することで、プロセス全体の流れを可視化できます。イベントの順序を確認し、プロセスのバリエーションを見つけ、ボトルネックや、「ポジション申請が修正のため差し戻される」といった手戻りのループを特定できます。正確で一貫したアクティビティ名は、理解しやすいプロセスモデルを構築するうえで欠かせません。

この属性は、プロセスマップの作成、ボトルネックの特定、ポジションのライフサイクルにおけるイベント順序の把握に欠かせません。

人事システムまたはポジション管理システムのイベントログ、ステータス変更テーブル、トランザクションコードから生成されます。

イベント時刻は、アクティビティが実行された正確な時点を記録するタイムスタンプです。プロセス全体の時系列を示し、イベントを正しい順序に並べることで、実際のプロセスフローを再現できます。

このタイムスタンプは、時間に基づくすべての分析の基礎となります。アクティビティ間のサイクルタイムの計算、承認手順にかかる時間の特定、ポジション作成から充足までの全体的なリードタイムの測定に使われます。正確なタイムスタンプは、「ポジション管理サイクルタイム」などのダッシュボードや、「ポジション承認サイクルタイムの平均」などのKPIに欠かせません。

イベントを時系列に並べ、サイクルタイムやリードタイムなど、期間に基づくすべての指標を計算するために欠かせません。

通常、ソースシステムのシステムログ、トランザクションレコード、または文書の作成日・変更日フィールドにあります。

ポジションIDは、各ポジションに割り当てられる一意のキーで、他のポジションと区別するために使われます。ポジションの初回申請から最終的な終了まで、1つのポジションのライフサイクルに関するすべてのアクティビティとイベントをつなぐ中心的な情報です。

プロセスマイニングでは、関連するアクティビティを1つのプロセスインスタンスにまとめるため、すべてのイベントログにケース識別子が必要です。ポジションIDをケースIDとして使うことで、分析担当者は各ポジションの開始から終了までの流れを追跡できます。これにより、プロセスフローの可視化、ポジションごとのサイクルタイムの計算、一般的な経路や逸脱の特定が可能になります。

関連するすべてのアクティビティを1つのプロセスインスタンスにまとめ、各ポジションのライフサイクルを最初から最後まで分析するために欠かせません。

通常、ポジション管理システムまたは人事情報システム（HRIS）モジュールのヘッダーや主要レコードにあります。

ソースシステム属性は、プロセスデータの取得元を示します。多くの組織では、採用から退職までのプロセスが複数のアプリケーションにまたがっています。たとえば、ポジション管理には基幹人事システムを使い、採用には別の応募者追跡システム（ATS）を使う場合があります。

統合されたプロセスビューを作成するために異なるソースのデータを組み合わせる際、ソースシステムの指定が重要になります。データ検証、連携の問題のトラブルシューティング、各システムがプロセス全体にどのように関与しているかの把握に役立ちます。また、システム間の引き継ぎで発生する遅延やデータの不一致も明らかにできます。

データの取得元を把握できるため、データ検証や、複数の連携システムにまたがるプロセスの分析に役立ちます。

通常、データ抽出のメタデータに含まれているか、データ変換時に固定値として追加されます。

この属性は、ソースシステムからデータセットが最後に更新された日時を記録します。分析対象のデータがどの程度新しいかを把握するための重要なメタデータ項目です。

分析担当者はこの情報を使って、分析対象の期間を確認し、利用可能な最新データに基づいて作業していることを確かめます。継続的なプロセス監視では、最終更新日時を把握することが欠かせません。ダッシュボードやKPIが業務の現在の状態を反映し、適時性のある情報に基づいて判断できるようになります。

データの適時性を確認できるため、分析の関連性を保ち、利用可能な最新情報に基づいて分析できます。

通常、データ抽出・変換（ETL）プロセスで生成され、保存されます。

ポジションステータスは、ライフサイクル上のポジションの状態を示します。この属性は、ポジションがプロセスを進むにつれて変化します。たとえば、「承認待ち」から「募集中：採用中」、次に「充足済み」、最後に「終了」へと変わります。

この属性は、ステータスに基づく分析や、「滞留・非アクティブポジション分析」などのダッシュボードに欠かせません。各ステータスにとどまっている時間を分析することで、「募集中」のまま長期間動かないポジションなどのボトルネックを特定できます。また、要員計画や人材パイプライン全体の健全性を把握する際にも役立ちます。

各状態にポジションがとどまる期間を分析できるため、長期間動きのないポジションの特定や要員計画に役立ちます。

通常、主要なポジションレコードに保存され、ステータスを変更するアクティビティの発生時に更新されます。

マネージャー名は、新しいポジションの従業員を管理する担当者を識別します。多くの場合、この担当者が申請を開始し、承認および採用プロセスにおける主要な関係者となります。

この属性は、「承認ボトルネック分析」ダッシュボードの中心となります。アクティビティをマネージャー別にグループ化すると、業務量や追加研修の必要性によってプロセスのボトルネックになっている可能性のある担当者を特定できます。また、プロセスにおける管理職の関与や意思決定の傾向を把握する際にも役立ちます。

ポジションの主要な関係者を特定し、承認の遅延やマネージャーごとのプロセス傾向を分析できます。

通常、ポジションの詳細情報にあり、レポート構造または組織割り当ての一部として記録されます。

ユーザー名は、プロセス内の特定のタスクを実行した従業員を識別します。たとえば、マネージャー、人事ビジネスパートナー、予算責任者などです。ポジションを申請した人、手順を承認した人、ポジションの詳細を変更した人が該当します。

この属性は、リソースのパフォーマンス、業務量の配分、コンプライアンスに関する分析に欠かせません。「最も多くの申請を処理しているユーザーは誰か」「特定の承認者に遅延が発生していないか」といった問いに答えられます。また、重要なタスクが同じ担当者によって実行されていないことを確認する職務分掌分析にも使われます。

業務量の配分、ユーザーのパフォーマンス、コンプライアンスを分析し、研修の必要性やリソース不足の特定に役立ちます。

通常、トランザクションの詳細、変更ログ、監査証跡にあり、ユーザーIDを介して関連付けられていることが多い項目です。

原価センターは、ポジションを組織の勘定科目表にある特定の予算単位に関連付ける財務上の区分です。人員数や人件費に関する財務計画、予算編成、レポーティングに使われます。

プロセスマイニングでは、原価センターによってポジション管理プロセスを財務の観点から分析できます。特定の原価センターでポジション変更が頻繁に発生しているか、承認時間が長いか、採用コストが高いかを確認できます。予算遵守の分析や、ポジション管理の意思決定が財務に与える影響の把握に特に役立ちます。

ポジションを財務単位に関連付け、予算領域ごとのプロセスパフォーマンスとコストを分析できます。

人事システムまたはERPシステムのポジションレコードにある財務または組織割り当ての詳細にあります。

イベント時刻がアクティビティの開始を示すのに対し、終了時刻は完了を示します。2つの時刻の差が、そのタスクの処理時間または所要時間になります。瞬時に完了するイベントでは、終了時刻が開始時刻と同じになる場合があります。

分析では、プロセス内でどのアクティビティに最も時間がかかっているかを特定するために、この属性が役立ちます。非効率な手順の特定や、詳細なボトルネック分析にも利用できます。たとえば、承認手順の終了時刻を分析すれば、どの承認に最も時間がかかっているかを把握し、改善の取り組みを集中させられます。

個々のアクティビティの処理時間を計算できるため、特に時間のかかるタスクを特定できます。

システムのイベントログやトランザクションデータで、開始時刻とともに記録されていることが多い項目です。後続イベントの開始時刻から算出することもできます。

職務名は、ポジションの役割や機能を示します。1つの職務名に複数のポジションが存在する場合もありますが、この属性によって管理対象となる役割の性質を把握できます。

職務名やより広い職種群でプロセスを分析すると、特定の役割に固有の傾向を明らかにできます。たとえば、シニア職や高度な専門性を要する職務では、初級職と比べて承認サイクルが長く、採用プロセスが複雑になる場合があります。この情報は、採用戦略の調整や現実的なスケジュールの設定に役立ちます。

役割の背景を把握できるため、職務の種類、レベル、機能によるプロセスの違いを分析できます。

ポジションマスターデータに保存され、人事システム内の中央職務カタログまたは職務プロファイルに関連付けられていることが多い項目です。

部門属性は、各ポジションを「財務」「エンジニアリング」「営業」など、組織内の特定の領域に割り当て、組織上の背景を示します。これにより、会社の異なる領域間でポジション管理プロセスを分類し、比較できます。

部門でフィルタリングまたはグループ化すると、プロセスのパフォーマンスの違いを特定できます。たとえば、特定の部門で承認時間が長い、または手戻り率が高いといった傾向を把握できます。この情報は、対象を絞ったプロセス改善の取り組みや、成果の高い部門のベストプラクティスを組織全体で共有する際に役立ちます。

異なる事業部門間でプロセスを比較し、効率、コンプライアンス、コストの違いを特定できます。

人事システムのポジションマスターデータまたは組織管理モジュールにあります。

勤務地属性は、ポジションに関連するオフィス、都市、州、国を示します。この地理情報は、地域ごとの採用プロセスの違いや人員配置を把握するうえで重要です。

勤務地別にプロセスを分析すると、重要な傾向を明らかにできます。たとえば、地域の労働市場の状況によるサイクルタイムの違い、国ごとに異なる承認階層、特定地域で手順を増やすコンプライアンス要件などを確認できます。必要な地域差に対応しながら、グローバルなプロセス標準化を進める際にも役立ちます。

地理的な分析により、プロセス効率、採用需要、コンプライアンス要件における地域差を明らかにできます。

組織の詳細情報の一部として、ポジションマスターデータに保存されます。

変更理由は、プロセス内で発生した特定の、通常とは異なるイベントの説明を記録します。申請を却下した理由、再分類の根拠、変更のため申請者に差し戻す際のコメントなどが含まれます。

この定性的なデータは、根本原因分析に非常に役立ちます。プロセスからの逸脱が起きた「理由」を把握できるためです。たとえば、却下理由を分析すると、予算情報の不足や職務内容の不明確さなど、ポジション申請に共通する問題を明らかにできます。この情報は、「初回承認率」の向上や「ポジション手戻り率」の低減に役立ちます。

手戻り、却下、その他の逸脱の背景を把握できるため、対象を絞った根本原因分析とプロセス改善が可能になります。

通常、却下、手戻り、変更のトランザクションに関連付けられたコメント欄、メモ、または専用の理由コードフィールドにあります。

求人申請IDは、ポジション管理プロセスと採用プロセスをつなぐ橋渡しとなります。ポジションの承認が完了し、充足の準備が整うと、通常は採用活動を正式に開始するために求人申請が作成されます。

この識別子を含めることは、採用から退職までのサイクルを真に最初から最後まで把握するうえで重要です。ポジションの作成・承認データと、候補者の募集、面接、オファーなどの採用データを関連付けられます。この連携により、初回申請から候補者の入社日までの採用充足期間を詳細に分析できます。

ポジションと採用プロセスを関連付け、人材獲得ライフサイクル全体をより広い範囲で分析できます。

通常、応募者追跡システム（ATS）または採用モジュールで生成され、基幹人事情報システムのポジションレコードに関連付けられます。

職種群は、関連する職務名をまとめる分類です。たとえば、「ソフトウェアエンジニア」「QAテスター」「DevOpsエンジニア」は、すべて「エンジニアリング」という職種群に属する場合があります。特定の職務名よりも広いレベルで、ポジションを分類・分析できます。

職種群を分析に使うと、人員の傾向やプロセス効率を戦略的な視点から把握できます。「財務」と「IT」など、異なる機能間でポジション管理のライフサイクルを比較することも可能です。これにより、機能ごとのボトルネックやベストプラクティスを明らかにし、戦略的な要員計画に役立てられます。

類似する職務をまとめて上位レベルで分析できるため、企業内の異なる機能にまたがるプロセスの傾向を把握できます。

組織の職務カタログまたは職務体系で定義され、職務プロファイルまたはポジションレコードの属性として保存されます。