評価における PAR の追跡およびルーティングと完了

従業員リクエスト、監督者リクエスト、および HR リクエストの各コンポーネントは同一です。違いは、各グループがアクセスできるデータのタイプのみです。これは、セキュリティオプションと許容されるアクションによって決まります。

注: PAR の追跡およびルーティングに必要な情報は、従業員を採用する際に入力するものと同種の情報です。両方について、同じページを使用します。

従業員、監督者、および人事部門担当者が利用可能なアクションやデータは、代行機関が決定します。アクションの例としては、リクエストの作成、承認や許可の発行、アクションの最終決定などが挙げられます。また、作成者にアクションを差し戻したり、詳細を問い合わせたり、アクションの取消、キャンセル、修正を行ったりする作業も当てはまります。これらのケースに対する決定は、承認フローコンポーネント (GVT_WIP_ACTIVITY) を使用して行います。

従業員がリクエストできるのは、各自許容されているアクションのみです。したがって、ユーザーには、家族手当/福利厚生の変更や退職などの一部のオプションのみが表示されます。監督者は、これらのアクションだけでなく、その他の特定のアクションのリクエスト、承認、および許可を行うことができます。監督者がページを開くと、昇格、降格、特別任務、配置転換、賞与や報奨など、代理機関が指定している内容がリストに全て反映されます。監督者は、アクションを作成者に差し戻して詳細を確認したり、リクエストを却下して非アクティブとしてレンダリングしたりすることもできます。

人事部門担当者は、考えられる全てのアクションの開始、承認、および最終決定を行う権限を持っています。したがって、人事部門担当者は、従業員や監督者が通常開始できない採用や在職期間変更などに加え、サイクルのあらゆるフェーズにおける人事異動関連アクションの全てにアクセスできます。処理サイクルが既に完了した最終決定済アクションの場合、キャンセルや修正の権限を持つのは人事部門のみです。

PAR プロセスは、柔軟性と修正機能の両方を兼ね備えています。既存の人事異動の前に有効日が設定された新規人事異動を処理し、純粋なユーザー定義環境でリクエストのコードを定義できます。

米国連邦政府の顧客の場合、従業員データを追加、更新、または変更するには、PAR を作成します。承認プロセスを通して PAR を自動的に送信、ルーティング、および追跡するには、PAR WIP (処理中) ステータスコードを割り当てます。このコードは、リクエストサイクルにおける位置を示し、その送信先を決定するものです。

PAR の自動ルーティング

評価者は、リクエストステータスを変更し、ページを保存することによって、受領確認と承認を行い、ワークフローを通して PAR を転送します。各評価レベルは、情報が完成しているかどうか、また必要な記入票が添付されているかどうかの検証として機能します。評価者は自分自身のコメントを入力することもできます。代行機関は、リクエスト作成から、必要な数の各種評価を経て、最終的に人事部門での完了に至るまでのリクエストサイクルをリクエストタイプごとに設定し、ルーティングできます。

PAR ステータスの選択

リクエストをオープンし、一部のデータを入力し、後で完成させる場合は、リクエストをオープンし、PAR ステータスとして開始を割り当てます。追加情報の収集中、リクエストは独自のドメインおよびコントロール内に保持されます。評価対象として送信する準備が整うまで、必要なだけ再検討できます。

リクエストデータが完成し、自動ルーティング評価サイクルに進む場合は、PAR ステータスとしてリクエスト済を割り当ててリクエストを送信します。そのためには、リクエストを公認とします。作成者によって送信されたリクエスト済アクションは、ワークフローによって取得され、処理の関係者に自動的にルーティングされます。その後、許可/承認担当者がそのメリットを評価します。その後の評価サイクルでは、代行機関の要件に従い、特定の監督者や管理者によって第 1 承認および第 2 承認と評価され、2 次管理者によって承認済/署名済と評価され、最終的に処理済 (人事部門による処理) ステータスに変更されます。

説明や追加情報が必要な場合、評価者はステータスとして詳細情報確認のための差戻しを選択できます。作成者に差し戻すと、プロセスが再開されます。評価者は、未承認ステータスを割り当てることによってリクエストを却下し、完全にプロセスを停止できます。評価サイクル中、作成者は、WIP ステータスのリクエストを取り消すこともできます。

処理中のリクエストをキャンセルしたり、変更して再送信できるのは、作成者のみです。他の監督者、管理者、および人事部門担当者はリクエストデータの変更権限を持たないため、リクエストをキャンセルする必要がある場合は、作成者に差し戻す必要があります。

ユーザーが WIP ステータスを選択し、PAR ステータスコードを割り当てた場合、そのコードはリクエストのステータスと位置を示します。また、ワークフローで承認サイクルを通してリクエストをルーティングおよびモニターできるようになります。

ここでは、評価サイクルの一般的な例を紹介しますが、代行機関は必要に応じて別の設定を使用することができます。

PAR の概要

画像: PAR の開始、リクエスト、および承認のプロセスの例

この図は、サンプルプロセスの概要を示しています。この例では、従業員、監督者、または人事部門担当者が PAR を開始し、承認申請のために送信します。その後、PAR は複数のレベルの承認プロセスを経て、最終的に承認または却下されます。

リクエストの却下または差戻し

画像: 完了前の PAR の差戻しまたは却下の例

この図は、リクエストが却下されたときのビジネスプロセスの例を示しています。この例では、リクエストを開始ステータスに戻して、作成者が必要に応じて変更して再送信できるようにしています。再送信されたリクエストは、標準の承認サイクルを再び経ることになります。

注: 差戻し/却下ステータスは用意されていますが、ワークフローはこの機能に含まれていません。

リクエストのキャンセル、修正、または取消

リクエストのキャンセル、取消、または修正は特定の状況でのみ行うことができます。

開始者は、最終承認の前であればいつでもリクエストを取り消すことができます。
リクエストの承認後は、開始者または人事部門のいずれかがリクエストをキャンセルできます。完了したリクエストを修正できるのは人事部門のみです。

画像: PAR のキャンセル、修正、または取消の例

次の図は、リクエストのキャンセル、修正、または取消が許可されている人を示しています。

PAR ステータスコードの識別

次に、システムに付属のサンプルデータに設定されている各 WIP ステータスおよび PAR ステータスコードの定義を示します。

WIP ステータス	PAR ステータスコード	定義
開始	`INI`	アクションがオープンされたが、リクエストとしてまだ送信されていないことを示します。さまざまな理由で、作成者は、リクエストを開始した後、そのアクションに関する作業を完了するのにさらに時間やデータが必要であることに気付く場合があります。作成者は、`開始`ステータスを割り当てることによって、送信の準備が整うまでリクエストをオープンのままにしておくことができます。監督者は、職務コードなどの必要書類の作成にさらに時間が必要になった場合、`開始`ステータスを割り当てることによって、作業がまだ進行中であることを示すことができます。
リクエスト済	`REQ`	リクエストを送信するには、`リクエスト済`ステータスを割り当てます。ほとんどのリクエストは、承認申請のために 1 次監督者に自動的に送信されます。ただし、家族手当/福利厚生の変更リクエストは例外です。このタイプのリクエストは処理対象として人事部門 (HR) 職員に直接送信されるようにシステムを設定できます。または、人事部門がリクエストの作成者となっている場合は、そのリクエストを処理対象として人事部門担当者に直接送信できます。
第 1 承認	`1st`	1 次評価者は、`第 1 承認`ステータスを割り当てることによって、リクエストを次の評価レベルに転送します。
第 2 承認	`2nd`	1 次評価者は、`第 2 承認`ステータスを割り当てることによって、リクエストを次の評価レベルに転送します。
承認済/署名済	`SIG`	2 次評価者は、`承認済/署名済`ステータスを割り当てることによって、リクエストを処理対象として人事部門担当者に転送します。
人事部門による処理	`PRO`	人事部門担当者のみが`人事部門による処理`ステータスを割り当てることができます。最初にリクエストを評価および完了した後で、適切な異動区分コード、法務当局、および備考を追加できます。最終承認を表す場合は、PRO ステータスを割り当てます。そのリクエストは実際のイベントになります。 PRO は最終のステータスであり、誰も変更できません。実際のイベントになったリクエストは、給与計算、福利厚生、インターフェイスレポートなどの領域でさらに検討および処理できるようになります。
詳細情報確認のための差戻し	`RET`	評価者は、プロセス中の任意の時点で、`詳細情報確認のための差戻し`ステータスを割り当てることによって、詳細情報や説明を求めることができます。また、"詳細情報が必要です" などのコメントを追加することもできます。リクエストは作成者に差し戻されます。差戻しのリクエストを受け取った作成者は、情報を追加し、`リクエスト済`ステータスを再び割り当てて、プロセスを再開します。
取消	`WTH`	リクエストの元の作成者は、なんらかの理由で差し戻されたリクエストを取り消すことができます。人事部門は、無効と判明したリクエストやなんらかの理由で不要になったリクエストを取り消すことができます。注: 処理済または却下済のリクエストは取り消すことはできません。
未承認	`DIS`	評価者は、プロセス中の任意の時点で、`未承認`ステータスを割り当てて、[コメント] フィールドに理由を入力することによって、リクエストを却下できます。この場合、リクエストは作成者に差し戻されて、キャンセルされるか、変更されて再送信されます。
修正済	`COR`	人事部門担当者に限り、承認サイクルが完了し、最終決定されたリクエストの修正権限を持ちます。
キャンセル済	`CAN`	人事部門担当者は、承認サイクルが完了し、最終決定されたリクエストのキャンセル権限を持ちます。`キャンセル済`ステータスになると、アクティブリクエストシステムからリクエストが削除され、追跡レコード履歴のみが残ります。また、差し戻されたリクエストを受け取った作成者は、`キャンセル済`ステータスを割り当てることができます。

PeopleSoft ヒューマンリソース管理 USF 機能には、PAR を管理するための個別テーブルが用意されており、各アクションが人事部門によって承認および完了されるまで、これらのテーブルにデータが保持されます。個別テーブルに保持されるレコードについては、PAR プロセスがまだ完了しておらず、システムの残りの部分からは存在が認識されません。完了後、システムテーブルに対してデータが自動的に更新され、PeopleSoft 給与計算、福利厚生管理、勤務管理のプロセスなど、他のプロセスが有効化されます。

PAR プロセスの概念をサポートするために、これらのレコードの全てに有効日が設定され、各レコードと共通キーが関連付けられています。3 つのレコード (GVT_JOB、GVT_PERS_DATA、および GVT_EMPLOYMENT) が 1 つとして機能するため、ユーザーがデータコントロールページに行を挿入すると、3 つのレコード全てに行が挿入されます。

PAR が承認プロセスを問題なく進み、人事部門によって完了として処理され、実際のイベントになった時点で、3 つの対応するレコード (JOB、PERS_DATA_EFFDT、および EMPLOYMENT) にコピーできるようになります。プロセスは即座に完了し、ユーザーはその他のテーブルの更新を認識しません。

ただし、PAR アクションにシステム日より後の有効日が設定されている場合は、アクションが保存されたときにのみ JOB が更新されます。PERSONAL_DATA および EMPLOYMENT は、アクションの日付がシステム日と等しい場合にのみ更新されます。これは、GVT_JOB に対応する JOB に有効日が設定されているためです。したがって、有効日が将来の日付に設定されたアクションを受け取っても、その日付になるまでは無視されます。