採用ビジネス プロセス ガイドライン
概要
採用ビジネス プロセス(BP) は、 Workdayヒューマン キャピタル マネジメント (HCM) の基本的なワークフローであり、社員を組織に新しく採用するために必要なタスク、承認、システム アクションのシーケンスを調整します。以下を制御します。
- 処理内容 (ステップとサブプロセス)
- 誰が (各ステップを担当するセキュリティ グループ)
- 採用イベントのタイミング (操作の順序)
適切に設定された "採用" ビジネス プロセスにより、データの正確性が確保され、適切なタイミングで適切なステークホルダーが関与する。また、アカウントの作成や通知などのタスクが自動化される。
各採用プロセスは、ビジネス プロセス定義のインスタンスです。リクルーティング、報酬、福利厚生、およびコア (人事) HR データを接続する中央ハブとして機能し、候補者から社員へのシームレスな移行を実現します。Workdayにはデフォルトの定義が用意されていますが、ほとんどの組織では、さまざまな母集団 (国、従業員タイプ、または監督組織ごと) に合わせた複数のルール ベースの定義が作成されます。
サブプロセス
"採用" ビジネス プロセスには、特定のタスクを処理するサブプロセスが複数含まれています。
- 報酬の申請 (採用): このサブプロセスにより、新規採用者の給与とその他の報酬コンポーネントが決まります。
- Workdayアカウントの作成: 新規採用者のWorkday アカウントが生成され、システムへのアクセス権が付与されます。
- オンボーディング: 採用の完了後にこのプロセスをトリガ、以下のような新規採用タスクを管理できます。
- 税フォームの記入。
- ドキュメントのレビュー
- 福利厚生への登録。
- 身元調査: このプロセスは、新規採用がリクルーティングではないため、 Workdayで身元調査を行いたい場合にのみ適用可能です。
統合テンプレート
Workdayビジネス プロセスの統合テンプレートとは、複数の異なるサブプロセス (給与、賞与、統合株式など) のデータ入力画面を 1 つのユーザー インターフェイスにまとめる設定です。ビジネス プロセスに、プロセスの開始時に単一のロールに複数の関連する初期設定アイテムがある場合に、オプションとしてこのテンプレートを使用し、開始ステップとして開始ステップを追加することで、開始者のジョブを簡素化できます。
以下のサブビジネス プロセスは、一括請求で使用できます。以下のサブビジネス プロセスが統合テンプレートに確実に表示されるようにするには、関連するドメインに対する
表示権限
および変更
権限をユーザーに付与します。
- 政府 ID の編集
- 勤務開始日の変更
- 従業員の組織割当の変更
- 社員への労働協約の割当
- 支給グループの割当
- 支払オプション登録イベント
- 報酬関連のサブビジネス プロセス
前提条件
採用トランザクションを開始には、ターゲットの監督組織で以下の前提条件を満たしている必要があります。
- セキュリティ: 以下のアクションステップに対する権限を特定のセキュリティ グループにグラントように、ビジネス プロセス セキュリティ ポリシーを設定します。
- 開始アクション: "採用" プロセスを開始できるユーザーを指定します。一般的なセキュリティ グループには、リクルーター、HR 管理者、HR パートナーなどがあります。
- レビューと承認のステップ: 採用トランザクションを承認できるユーザーを指定する。主要なセキュリティ グループには、マネージャ、HR パートナー、報酬パートナーなどがあります。
- すべて表示: 処理中または完了した採用トランザクションを表示できるユーザーを指定する。一般的なセキュリティ グループには、HR 管理者、HR 監査人、システム実装者などがあります。ビジネス プロセスを開始できるロールに "すべて表示"権限を付与し、すべての検証が正しく実行されるようにします
- 該当するセキュリティ ドメインのリストを表示するには、"業務分野のドメイン セキュリティ ポリシー" レポートにアクセスし、"Staffing"、"Core Compensation"、"Organization and Roles" の各業務分野を選択します。
- 人材配置モデル:監督組織には、以下の人材配置モデルが割り当てられている必要があります。
- ポジション管理: 承認済みのオープンで使用可能なポジションが監督組織 ""に存在する必要があります。この特定のポジション() に対して、"採用" アクションを開始。
- 職務管理: 任意で、監督組織の採用要件を設定できます。設定されていない場合は、職務管理組織 ()への従業員の採用時にジョブ詳細を定義します。概念: 人材配置モデルを参照してください。
- 職務プロファイル: 以下のような詳細を指定して、必要なジョブプロファイルを作成します。
- 職務内容
- マネジメント レベル
- 報酬等級
- 支給レート タイプ
- その他の資格条件
- 応募者の追跡: 正式に採用される前に候補者を追跡する場合は、応募者ステータス、評価方法、リクルーティングソースを設定します。
- 採用ビジネス プロセスを編集: 採用ビジネス プロセスのステップ、条件、通知を定義します。これには、 "Workdayアカウントの作成" のようなサービスステップの設定も含まれます。
- 任意のフィールドの設定: "採用" ビジネス プロセスのどのオプション フィールドで "" を非表示しないにするか、表示専用にするか、特定のセキュリティ グループに対して必須にするかを決定します。
プロセス開始者
適切なセキュリティ権限を持つユーザーがいずれかの "社員の採用" タスクを開始すると、"採用" ビジネス プロセスがトリガ。Workday、このタスクにはいくつかのバリエーションが用意されており、プロセスに最適なものを選択できます。
例: 一部のタスクバージョンでは、既存の応募者、元従業員、学生を検索して重複レコードが作成されないように、拡張された検索機能を提供しています。概念: "社員の採用" 開始アクションを参照してください。
このプロセスは以下から開始できます。
- 検索バーに「社員の採用」と入力します。
- 職務補充依頼の関連アクション メニュー
- 監督組織の関連アクション メニュー。
- 未補充の"ポジション" の関連アクション メニュー
- "内定" または "雇用契約" ビジネス プロセスからの "採用可能" ステータス。
制限事項
- 訂正とインテグレーション: "採用" プロセスからトリガように設定したイベント駆動型インテグレーションでは、最上位の "採用" イベントに加えた訂正によってのみ再トリガされます。サブプロセス内でのみ訂正を行った場合、インテグレーションが再度トリガされることはありません。例: メインの採用の完了後に "報酬の申請 (採用)" で報酬を訂正する場合
- 設定の複雑性: 高度な設定が可能であるため、初期設定が複雑になり、組織内の採用プロセスを十分に理解する必要があります。
- 差戻しオプション: "差戻し"アクションを使用して、訂正のためにビジネス プロセスを"開始" ステップまたは "レビュー" ステップに差し戻すことができます。このアクションにはビジネス プロセス定義 ()のレビューまたは承認ステージが完了していない場合、アクセスできます。
- オンボーディングを区別: "採用" プロセスと "オンボーディング" を区別する。採用プロセスは社員がシステムに参加することを重視しており、オンボーディングは新規採用の体験を提供し、採用後のタスクを完了することを目的としています。
- オートコンプリート機能:ビジネス プロセスワークフローでは、オートコンプリートは差戻しをサポートしていません。サービス ステップは常に実行されますが、それらのサービスステップに関連付けられている通知はすべてWorkdayされます。設定の考慮事項: 人材配置イベントのオートコンプリートを参照してください。
- 完了した "採用" イベントの訂正: 福利厚生の登録などの関連イベントが、自動的に再トリガされることはありません。行った特定の変更によっては、従業員レコードが正確に更新されるように、特定のサブプロセスを手動で開始必要がある場合があります。
- 従業員の開始日の訂正: このビジネス プロセスは臨時従業員には使用できません。送信後に取り消すこともできません。
共通ビジネス プロセス ワークフローとガイドライン
"採用イベント"ビジネス プロセスの一般的なワークフロー設定パスは次のとおりで、ステップは一般的な順序で処理されます。
パス 1: 標準ワークフロー設定
これは最も一般的な設定であり、複雑な応募者要件なしの一般的な社員採用のプロセスを表しています。
パス 2: 採用 - 身元調査サブプロセスの設定
このパスでは、正式な身元調査がプロセスにおける必須のステップとして統合されます。採用ポリシーの遵守を徹底するため、身元調査が正常に完了するまで採用を進めることができません。
パス 3: 統合オンボーディング ワークフロー設定を使用した採用
この設定パスは、"採用" プロセスを他の重要なオンボーディングサブプロセスにつなげ、新規採用と社内チームにシームレスな End to End のオンボーディングエクスペリエンスを提供します。
パス 4: 組合または労働協約の設定を使用して採用
このパスは、新規採用者を労働協約に割り当てる必要がある組織にとって、報酬や福利厚生、その他のジョブ詳細に影響を与える可能性があります。
パス 5: オートコンプリート
このパスにより、採用プロセスが効率化され、標準化された大量の採用プロセスにおける手動でのデータ入力が削減され、手動の介入が最小限に抑え必須ます。例: 季節雇用従業員、小売業のスタッフ。
オートコンプリートを有効にすると、承認、関連手続きアイテム、レビュー ステップなど、ビジネス プロセスの特定のステップが省略されます。プロセスがこれらのステップに依存している場合は、このワークフローを使用する前にその影響を考慮してください。
オートコンプリートが有効かどうかは、リクルーティングプロセスの実行中に入力されるデータが正確かどうかにかかっています。"採用" イベントの必須フィールドがリクルーティングまたは "人材配置フィールドのデフォルト値" から自動入力されていない場合、このプロセスではオートコンプリートは実行されません。標準の手動ワークフローに戻ります。
総合承認の共通ビジネス プロセス ワークフロー
以下は、総合承認の一般的なワークフロー設定パスであり、ステップが一般的な順序でリストされています。
統合ステップのレビューおよび承認を許可するセキュリティ グループを指定します。"採用" ビジネス プロセス セキュリティ ポリシーを設定し、これらの統合ステップに対する権限をこれらのセキュリティ グループにグラント。一時的なセキュリティ グループには、給与計算セキュリティ グループなどがあります。
Path1: 単一レビューアの統合承認
これは最も頻繁に行われるケースです。複数のサブプロセスが、HR パートナーや採用マネージャなどの承認者に設定されている 1 つのタスクにまとめられます。これにより、レビューアは採用イベントの全体像を把握できるようになります。
パス 2: 統合チェーンを使用した階層的承認
複数のレベルのマネジメントが採用とその関連詳細を承認する必要がある場合は、統合承認チェーンが最良の方法です。これにより、総合承認のメリットと承認チェーンのメリットが統合されます。"総合承認チェーン" ステップは、"マネージャ" のようなロール ベースのセキュリティ グループに割り当てられます。承認タスクは、単一のアイテムとして開始者のマネジメント階層を上位にルーティングされます。
ワークフロー ステップ
"採用" ビジネス プロセスワークフローをビルド際に使用される一般的なステップ タイプは以下のとおりです。
- 開始
- ステップの順序: すべてのビジネス プロセスで常に最初のステップにする (ラベル "A")。
- グループ: リクルーター、HR パートナー、HR 管理者、またはリクルーティング (内定または雇用契約) またはインテグレーションの一環として、リクルーターごとの設定も可能です。その設定は、"採用" ビジネス プロセス セキュリティ ポリシーで管理されます。
- を指定: 該当なし。このステップにより、プロセスが開始されます。
- ステップ タイプのガイドライン:
- ベスト プラクティス: 検索機能が強化された "社員の採用" タスクを使用して、重複レコードが作成されないようにする。新しいレコードを作成する前に、既存の応募者または元従業員の検索方法についてユーザーに研修を実施する。
- ユースケース: このステップにより、"採用" ワークフローが開始されます。開始者は、応募者とその補充ポジションを特定するために必須コア情報を入力します。たとえば、応募者の名前、職務補充依頼、予定採用日などです。
- 例:リクルーターは、オープン ポジション ""に候補者を採用する必要があります。"社員の採用"タスクを使用して候補者名を検索します。候補者が元インターンであり、システムに応募者レコードがあることが検索。リクルーターが既存のレコードを選択して採用プロセスを開始と、一部の候補者情報が自動入力されます。
- 条件ルール ガイドライン:開始ステップの条件ルールは、開始者に提供する情報がすべて網羅されているようにする検証メカニズムとして機能します。
- ベスト プラクティス: 開始のセキュリティを単純にする。ロール ベースのセキュリティを使用して、適切なユーザーに開始権限をグラント。
- 例: 米国内のユーザーのみが標準の "採用" プロセスを開始ようにするには、セキュリティ ポリシーに次のルールを追加します: ユーザーの勤務地が "米国" です。
- アクション
- ステップの順序: 開始ステップの後、完了ステップの前または後に配置します。
- グループ: 報酬パートナー、HR パートナー、給与計算管理者、社員 (セルフ) など、ワークフローの一部としてデータを入力またはレビューする必要があるロール。
- を指定: "報酬の申請 (採用)"、"個人情報の変更" など、このステップでトリガれるサブプロセスを指定します。
- ステップ タイプのガイドライン:
- ユース ケース:新規採用から特定の情報や追加情報を収集するために、別のビジネス プロセス(サブプロセス) を呼び出して使用する最も一般的なステップ タイプの 1 つ。
- 例: "新規採用に関する質問票の記入" というラベルの付いたアクションステップが、新規採用のインボックスに転送されます。
- 条件ルール ガイドライン:
- ベスト プラクティス:条件ルールを使用してプロセスを効率化し、関連するタスクだけがユーザーに表示されるようにします。これにより、混乱や不要な作業を回避できます。
- ユースケース: データに基づいてステップを動的に実行する場合。
- 例: サインイン賞与が提示される場合にのみ、"一時金支払のリクエスト" アクションステップをトリガします。
- 詳細については、を参照してください概念: アクション ステップ-
- 承認
- ステップの順序: 通常、主要なすべてのデータ入力ステップが完了した後、最後の完了ステップの前に配置できます。
- グループ: 採用マネージャ、マネジメント レベル +1 (マネージャのマネージャ)、HR マネージャなど、トランザクションを承認する権限を持つロール。
- "" を指定:承認チェーン ()を設定して、特定のレベルに達するまでトランザクションをマネジメント階層を上書きすることができます。
- ステップ タイプのガイドライン: このステップは、トランザクションを検証するための正式なゲートとして機能します。承認者は、採用を承認、差し戻し (訂正のために前のステップに進める)、または却下できます。これにより、会社のポリシーを監督し、遵守することができます。
- ベスト プラクティス
- 主要なデータ入力ステップがすべて完了した後、ビジネス プロセスの最後の完了ステップの前に承認ステップを配置します。
- 詳細ルーティングを設定して、承認者が自身の取引を承認できないようにします。ルーティング制限を "イベント対象を除外" に設定し、"代替ルーティング セキュリティ グループ" を "除外されるユーザーを基準にするマネージャ" に設定します。
- 開始者が承認者である場合、Workdayステップはスキップされます。承認が必要な場合は、"総合承認" ステップを使用します。
- ビジネス プロセスがより大きなプロセス内のサブプロセスである場合は、親ビジネス プロセスの承認を統合します。これにより、各サブプロセスで個別の承認ステップが必要なくなります。
- ユース ケース:新規採用の報酬パッケージについて、マネージャにサインオフしてもらう。
- 例: HR マネージャが報酬パッケージを申請した後、ビジネス プロセス部長に承認タスクが送信され、レビューとサインオフが行われます。
- 条件ルール ガイドライン:
- ベスト プラクティス
- 採用プロセスに時間がかかりすぎて複雑な承認チェーンを作成しないようにする。条件ルールを使用して、標準の採用、例外以外の採用の承認をバイパスする。
- ほとんどの承認ステップで、"現在の割当先が開始者または事前承認者でなかった" という標準条件ルールを使用します。これにより、同じユーザーがすでに開始または承認したトランザクションを承認する必要がなくなります。
- ユース ケース: 例外に対して追加の承認を要求する場合。
- 例: ファイナンス パートナーの承認ステップに、"採用が財務部門" AND "申請の年間給与" > 150,000 USD という条件ルールを追加できます。
- 詳細については、を参照してください概念: 承認ステップ-
- オートコンプリート
- ベスト プラクティス:
- オートコンプリートは、多くのステップをスキップように設計されていますが、常に実行したいアクションがある場合があります。"通常どおりにルーティング"を使用して、残りのプロセスがオートコンプリートされた場合でも、どのステップを実行するかを指定します。インテグレーションとサービス ステップは常に通常の経路で処理されます。
- 採用を行うための必須フィールドがすべて、リクルーティングから採用イベントに正しくマッピングされて自動入力されることを確認してください。人材配置フィールドのデフォルト値を活用し、可能な限りデータを自動入力する。例:ジョブ変更では"採用の理由"は必須フィールドです。このフィールドが常に入力されるようにするには、"内定"ビジネス プロセスの入力を必須にします。
- "採用" イベントのさまざまなサブプロセス ("支給グループの割当"、"報酬の申請 (採用)"、"一時金支払のリクエスト" など) でオートコンプリートを有効にすることもできます。
- 社内採用に "職務の変更" 統合テンプレートを使用している場合は、親プロセスTO DO、そのテンプレート内のすべてのサブプロセスに対してオートコンプリートを設定する必要があります。
- オートコンプリートを選択して適用するには、ルール ベースのビジネス プロセス定義を使用します。次に、オートコンプリートをトリガする条件を指定できます。例: 小売業のポジションについてはオートコンプリートを有効にし、手動での監督と承認が必要なエグゼクティブ レベルの採用についてはオートコンプリートを有効にしないルールを作成します。
- 候補者を"採用可能" ステータスに移動すると、直ちにオートコンプリート プロセスがトリガされるため、リクルーティングワークフローを調整する必要がある場合があります。柔軟性を管理ため、候補者を実際の開始日に近い "採用可能" に移動することを検討する。
- 候補者の "採用可能" ステータスの移行を担当するセキュリティ グループ (リクルーターまたは主リクルーター) に、"採用"イベントを開始および完了するために必要な権限があることを確認します。これには、"採用" プロセスのビジネス プロセス セキュリティ ポリシーと "職務への応募" ビジネス プロセスの動的完了ステップの設定が含まれます。
- 詳細については、を参照してください概念: ビジネス プロセスのオートコンプリート-
- 完了
- このステップは、メインワークフローが終了したことを示します。完了ステップが実行されると、採用はすべて承認されたとみなされ、後続のステップ (インテグレーション、アーカイブ、通知など) は、コア プロセスを保留することなく実行できます。ステップをレビューし、採用が承認済とみなされるために必須最終アクションを"いずれ" に設定するべきかを特定します。多くの場合、これはシーケンスの最後の承認ステップです。グリッド ""でこのステップの行を探し、そのステップの関連アクション メニューから選択します。各ビジネス プロセスの完了ステップは 1 つだけです。別のステップがすでに完了ステップとして設定されている場合、そのWorkdayは自動的にオフになり、現在選択したステップに指定が適用されます。ベスト プラクティス
- 承認ステップとレビュー アクション ステップはすべて、完了ステップの前に配置する必要があります。
- タレント データ (写真、学歴、職務履歴) の追加など、従業員がレコードを完全に作成する必要があるステップは、多くの場合、"完了" ステップの後に配置されます。
- "Workdayアカウントの作成"サービスステップは、"完了" ステップの後に配置できます。
- 多くの場合、"総合承認チェーン" などの承認ステップは "完了" ステップとして設定されます。これにより、マネージャは採用がシステムで確定される前に、1 つのタスクですべての採用と報酬の詳細を承認できるようになります。
詳細については、を参照してください概念: 完了ステップ-
- 総合承認
- ビジネス プロセス定義内で、標準の承認または承認チェーン ステップの代わりに総合承認ステップを追加できます。このステップ タイプでは、ビジネス プロセス内の先行する複数のアクションステップが承認者の 1 つのインボックス アイテムにまとめられます。たとえば、"採用" ビジネス プロセスでは、新規採用者のジョブ詳細、組織割当、報酬についてマネージャが個別の承認を受ける代わりに、"総合承認" ステップによって、これらすべてを 1 つの統合タスクにバンドル (bundle)ことができます。その後、承認者は1 つのスクリーニングですべての詳細をレビューし、承認できます。
- 総合承認チェーン
- ビジネス プロセス定義内で、標準の承認または承認チェーン ステップの代わりに統合承認チェーン ステップを追加できます。このステップは、総合承認の機能と承認チェーンを組み合わせたものです。複数の承認アイテムを 1 つのタスクにグループ化するだけでなく、最上位に到達するか終了条件が満たされるまで、そのタスクをマネジメントや組織階層の上位に転送する処理も行います。
- 以下について、これらのステップを追加することを検討してください。
- 同等のタスク: グループ化するアイテムの性質が似ている場合、統合が最も効果的です。これにより、承認者はすべてのアイテムに一貫したレビュー プロセスを適用できるようになります。
- 承認のスキップ:承認者がトランザクションの開始者と同じ場合は、標準の承認ステップが自動的にスキップされることがあります。総合承認ステップを使用することで、承認タスクが意図したとおりに生成され、転送されるようにするための回避策として機能します。
- 通知の削減: 複数の承認リクエストを 1 つのタスクにまとめることで、承認者に送信される通知の数が大幅に減り、「インボックスでの過重労働」を回避し、注意が必要なタスクに集中できるようにします。
- ステップの条件の明確な定義:条件ルールを使用して、統合ステップが適切な場合にのみトリガされるようにします。たとえば、トランザクション数が特定の閾値を超えた場合にのみ、総合承認を使用するルールを設定できます。
- 十分にテストする:総合承認ステップを含むビジネス プロセスを導入する前に、十分にテストを行い、期待どおりに処理されることや、承認者のUXが明確で直感的であることを確認します。承認者が統合ビューを簡単に操作し、必要に応じてアイテムを承認または却下できることを確認する。例: 新規採用者のジョブ詳細とその報酬に関する承認を 1 つのタスクにまとめることで、新規採用者がジョブ情報と報酬パッケージの両方をレビュー、承認できるようにします。
- "総合承認" ステップを "報酬の申請" ステップの後に追加し、"採用" イベントと "報酬の申請" イベントの両方が含まれるように設定します。
- サービス
- ステップの順序: どこにでも配置できますが、 "Workdayアカウントの作成" のような重要なサービスは通常、最終承認の後、あるいは完了ステップの直前に配置されます。
- グループ: システム (Workday)。Workdayにおいて、この「システム」は、ビジネス プロセス実行ユーザーと呼ばれる具体的で、設定可能なセキュリティ 原則です。
- を指定: 提供されているWorkdayバックグラウンド プロセスのリストから選択します。
- ステップ タイプのガイドライン:
- ベスト プラクティス:
- 手動の介入なしで、自動化されたシステム レベルのアクションを実行するために使用されます。"採用" ビジネス プロセスにおける最も一般的なユースケースは"Workdayアカウントの作成" サービスです。このサービスにより、新しいユーザー アカウントが生成され、 Workdayにサインインできるようになります。
- カスタムのサービス ステップ タイプを作成することはできません。Workdayが提供するサービスのリストから選択します。
- "アクション" から "サービス" などの既存のステップ タイプを変更することはできません。該当するステップを削除し、正しいタイプの新しいステップを追加してください。
- 条件ルール ガイドライン:
- ベスト プラクティス: 各サービスの関数を理解してから、ビジネス プロセスに追加する。ユーザー ベースのセキュリティ ロールを割り当てる前に、 Workday アカウントを作成するなど、サービスステップを論理的に配置します。
- ケースを使用:採用日が近くになるまで"Workdayアカウントの作成" サービスが実行されないようにするなど、システムアクションが発生するタイミングを制御します。
- 例: "Workdayアカウントの作成" サービスステップで、次のルールを追加します: (採用日から今日の日付を引いた結果) は 7 以下です。これにより、開始日から 1 週間以上前にアカウントが作成されることはありません。
- 詳細については、を参照してください概念: サービス ステップ-
- 関連手続き
- ステップの順序:ビジネス プロセス内の任意の順序で追加できます。
- グループ: すべてのロール。多くの場合、"Employee as Self"、"採用マネージャ"、または "IT サポート" や "施設維持管理費" などのサポート チームに割り当てられます。
- を指定: 指示を入力できます (リッチ テキストとハイパーリンクを使用)
- ステップ タイプのガイドライン:
- ベスト プラクティス:
- 関連手続きステップを使用して、データ入力を伴わない単純なタスクやリマインダーを割り当てることができます。これらのステップは、 Workday外で発生するタスクや、専用のビジネス プロセス ステップが存在しないタスクのチェックリストアイテムとして機能します。を参照チェックリストの作成-
- 明確で実用的な指示を入力します。タスクで特定のページに移動する必要がある場合は、"TO DO" の説明にナビゲーション パスを含めます。
- 条件ルール ガイドライン:
- ベスト プラクティス: 明確でアクション可能な指示を入力します。期日を使用して、ユーザーがタスクに優先順位を設定できるようにします。関連する "TO DO" をプロセス フローでまとめてグループ化します。
- ユース ケース: 条件付きでタスクを割り当てる場合。
- 例: 採用マネージャが法人クレジット カードをリクエストするための "関連手続き" で、次の条件ルールを追加できます: 職務レベルがディレクター以上です。
- 詳細については、を参照してください概念: 関連手続きステップ-
インテグレーション
インテグレーション設定では、主に Workday のサードパーティ給与計算用イベント駆動型インテグレーションを利用します。スケジュールされた主インテグレーションの実行を待つのではなく、"採用"ビジネス プロセスが完了すると、採用情報がサードパーティの給与計算ベンダーに即時に送信されます。このサービスは、主なPECI(PECI) コネクタで有効にします。"採用" ビジネス プロセスのステップが設定され、従業員イベントがWorkdayからサードパーティの給与計算ベンダーに自動的に送信されます。ベンダーがデータを検証し、エラーがあればすぐに訂正できるようにエラーを返します。
- ステップの順序: インテグレーションは、ワークフロー内の複数のステップで発生することができます。このステップは通常、すべての承認が完了した後、プロセスが完了する前に実行されます。
- グループ。システムによって実行されます。インテグレーションを実行するために必要なセキュリティ権限を持つ、事前設定済みのインテグレーション システム ユーザー (ISU) を割り当てる必要があります。
- "" を指定: 実行する特定のインテグレーション システムを選択します。これには、法人カードプロバイダと同様に構築済みのWorkdayコネクタがあるか、 Workday Studio、エンタープライズ インターフェイス ビルダー (EIB )、コア コネクタを使用したカスタム構築インテグレーションが含まれます。
- ステップ タイプのガイドライン:
- ユース ケース: 新規採用者に当日のレポートを作成するよう求める政府規制に対応新しい社員に給与計算処理情報をすぐに提供し、サードパーティの給与計算システムで遅延なく正しく設定されるようにするサードパーティの給与計算ベンダーに情報の検証を許可し、エラーがあればすぐに訂正できるようにすることで、給与計算エラーを削減する。
- ベスト プラクティス:実装前に、給与計算ベンダーを通じて 2 つの必須エンドポイント (1 つは送信用、1 つは取得用) を構築し、テストを行うことを確認してください。サンドボックス環境でインテグレーションを十分にテストする。タスクをアクティブに監視し、インテグレーションエラーの潜在能力性を迅速に解決できるセキュリティ グループに、レビュー ステップを割り当てます。
- 例: "採用" ビジネス プロセス定義にステップを追加するには、次のようにします。
- "採用" ビジネス プロセス定義にアクセスし、 を選択します。
- 支給グループの割当ステップが完了ステップとして設定されていることを確認します。
- 行を追加して、以下の詳細を指定します: オーダー: c、タイプ: サービス、指定: サードパーティの給与計算システムへの社員データの送信
- 別の行を追加して、以下の詳細を指定します。順序: d、タイプ: アクション、指定: サードパーティ給与計算システムのイベント駆動型インテグレーションのレビュー、グループ: 給与計算管理者
- "OK"を選択して、変更を保存します。
- 条件ルール ガイドライン:
- ベスト プラクティス: 監査入力条件のあるビジネス プロセスステップを設定しないでください。これにより、イベント駆動型インテグレーションが予定通りに実行されないシナリオが作成される可能性があります。実行を制御するには、この目的で設計された特定のレポート フィールドを使用します。
- ユース ケース:条件ルールの一般的なケースは、有効日が将来の日付の採用について、インテグレーションが実行されないようにすることです。これは、下流システムで将来の日付のトランザクションを処理できない場合に役立ちます。
- 例: 将来日付の採用をスキップには、"サードパーティの給与計算システムへの社員データの送信" ステップで条件ルールを作成します。ルールの条件"" で、レポート フィールド"Is Event Driven Integration Transaction Future Effective"を使用してください。このフィールドの値が "いいえ" の場合にのみステップを実行するように設定します。
- 詳細については、を参照してくださいインテグレーションの作成 (ステップ)-
ルーティング修飾子
従業員に複数のポジションまたはトランザクションがあり、割当の変更があった場合に、ビジネス プロセス ステップを特定のセキュリティ グループに転送する必要がある場合に、ルーティング修飾子を使用します。
ルーティング修飾子がビジネス プロセス定義内の特定のステップに追加されます。ルーティング修飾子をコース ステータスかどうかは、ビジネス プロセスおよびステップ タイプによって異なります。
- "行レベル" 修飾子は、行レベルのルーティング () をサポートするビジネス プロセスの "承認" ステップおよび "総合承認" ステップに適用でき、ステップで少なくとも 1 つのセキュリティ グループが "積集合型" セキュリティ グループである場合。
一般的なルーティング修飾子には以下があります。
- 行レベル:購買請求書などの複数の行がある取引の承認ステップに使用されます。各行のコンテキストに基づいて、関連する "積集合" セキュリティ グループ ()が承認のために転送されます。
ベスト プラクティス
:
- "System"業務分野の以下のドメインへのセキュリティ アクセス権が付与されていることを確認します。
- Business Process Administration
- Manage: Business Process Definitions
- 承認チェーン: 複数のポジションを持つ従業員の "承認チェーン" ステップで組織ベースのルーティングが有効になっている場合、Workdayは組織 ""のすべてのマネージャにルーティングされます。これを防ぐには、このステップでルーティング修飾子を設定します。
- Workday変更の動作:ビジネス プロセス ステップの割当変更時に、ルーティング修飾子は無視されます。割当が変更されたタスクは、新しい割当先 ()の標準ルーティングに従う。
- ルーティング要件の設定 (必要な場合):ルーティング制限を定義して、特定の個人をワークフローから除外できます。必要に応じて、代替ルーティングを使用して別のセキュリティ グループを特定します。
- 変更を保存:ルーティング修飾子と追加設定を設定したら、変更を保存して新しいルーティングルールを適用します。
- 行レベルのルーティングの積集合型セキュリティ グループと併用: "行レベル" ルーティング修飾子を使用する場合、ステップが少なくとも 1 つの積集合型セキュリティ グループに割り当てられ、ロールの交差する部分に基づいてWorkdayが正しい承認者にルーティングされるようにします。 -
- ビジネス プロセスのサポートの確認: ルーティング修飾子は、すべてのビジネス プロセスで使用できるわけではありません。設定する特定のビジネス プロセスで、目的の修飾子が使用できるかどうかを確認してください。これはビジネス プロセス定義で確認できます。
- 主ポジションおよび追加ポジションの修正率をサポートするプロセスの例としては、"連絡先変更"、"ID 情報の編集"、"パフォーマンス レビューの開始"、"能力開発プランの開始" などがあります。
- "現在" および "申請" の修正をサポートしているプロセスの例としては、"職務の変更"、"補助職務の追加"、"内定" などがあります。
ユース ケース
:以下のシナリオでは、ビジネス プロセス ステップにルーティング修飾子を追加することを検討してください。
- 行レベルの承認: 異なるコスト センターの行がある購買請求書など、異なるコンテキストを持つ複数の行を含む可能性のある取引の場合、"行レベル"ルーティング修飾子を承認ステップまたは "総合承認" ステップで使用できます。これにより、各行のコンテキストに基づいて、各行が適切な承認者に送られます。
通知
システム通知
システム通知は、ビジネス プロセスイベントに対してWorkdayによって生成されるデフォルトのアラートです。すべてのシステム通知は、ビジネス プロセスの
"通知"
タブで確認できます。Workday特定の通知を無効にすることができますが、多くの場合、通知プリファレンスをユーザー レベルで管理するか、より対象を絞ったアラートについてカスタム通知を使用することをお勧めします。ビジネス プロセス システム通知の設定を参照してください。
グローバル通知設定は、
"テナント設定の編集 - 通知"
タスクで管理されます。カスタム通知
ビジネス プロセスの任意のステップで開始できるカスタム通知を作成して、イベント、必須アクション、またはステータスの変更についてユーザーにアラートができます。通知を作成するには、ビジネス プロセス定義の各ステップに移動し、そのステップの関連アクション メニューから選択します。カスタム通知の作成を参照してください。
- ガイドラインとベスト プラクティス:
- 採用プロセスが完了したら、採用マネージャに通知します。
- "採用" ビジネス プロセスの完了時にトリガされるカスタム通知を作成します。新規採用の氏名、開始日、マネージャ名で E メールをパーソナライズします。
- 新規採用について IT 部門に通知し、必要なハードウェアとソフトウェアを準備できるようにする。
- ユース ケース:
- 採用完了時のマネージャ通知
- 新規採用にようこそメールを送信
- 設備のプロビジョニングに関する IT 部門通知
- 例:
- 採用マネージャセキュリティ グループ ()に送信される "採用" BP の完了ステップでトリガようにカスタム通知を設定します。メッセージには、新規採用者、社員 ID、開始日、ポジション ()を含めることができます。
- "[New Hire Name] チームへようこそ！" という件名の通知を設定します。E メールの本文には、初日の詳細、会社の新規採用ポータルへのリンク、マネージャ ()の連絡先情報が記載されています。
- 採用ビジネス プロセスで、ITチームの特定のセキュリティ グループに送信されるカスタム通知を設定します。通知には、特定のステップを入力することでトリガされ、新規採用名、事業地 ()、職務名 ()などの詳細が含まれます。
課題と解決策
このセクションには、一般的な問題と、それに対応する原因および解決策が記載されています。
出庫 | 原因とソリューション |
|---|---|
"採用" ビジネス プロセスの未割当タスク | 原因: 指定されたセキュリティ グループにユーザーが含まれていない未割当タスクが含まれているか、無効なWorkdayアカウントを持つユーザーのみが含まれています。 例:
ソリューション: この問題が発生したステップを表示する "未割当タスク " レポートにアクセスします。"Pre Employee as Self"セキュリティ グループを追加して、テストを実行します。 |
統合テンプレートを使用する場合、レビューまたは承認は機能しません。 | 原因: "採用" ビジネス プロセス定義 ()で、統合レビューまたは承認ステップがステップ b として設定されていません。 ソリューション: "採用" BP 定義を編集し、"社員の採用のレビュー" などの主要なレビュー/承認ステップを順序 b に移動します。これにより、開始から統合レビュー ページに移行するまでのシームレスなフローが実現します。 |
誤ってトリガされたサブプロセスに関するカスタム通知 親の "採用"イベントが訂正されると、報酬が変更されていない場合でも、"報酬の申請 (採用)" に関する通知がトリガされます。 | 原因: システムが親イベントの訂正を検出し、すべてのサブプロセスで通知をトリガします。そのサブプロセス内でのみ変更が行われたかどうかを判断することはできません。 ソリューション: これは設計どおりに機能します。この動作に注意してください。これで問題が発生した場合は、通知を親の "採用" プロセスに移動し、サブプロセス データに関する条件に基づいてトリガすることを検討してください。 |
採用開始ステップに検証を追加できません 最初の "採用" スクリーニングで、国民 ID などの必須フィールドが未入力場合、エラーメッセージが表示されます。 | 原因:開始ステップで新しい応募者レコードを作成している可能性があり、ステップが送信されるまでは検証するフィールドがシステムに存在しない。 ソリューション:開始ステップ ""に検証を含めようとしないでください。代わりに、開始の直後にアクション ステップを追加し、開始者に戻してください。例: 個人情報の変更またはレビュー ステップ。 この 2 番目のステップに検証ルールを適用します。 |
重複社員レコード | 原因: 応募者、元従業員、または臨時従業員としてシステムにすでに存在する個人について、新しい社員レコードが作成されます。 ソリューション: 既存の個人の高度な検索機能が含まれる "社員の採用" タスクのバージョンを使用します。新しい応募者レコードを作成する前に、常に個人を検索するようにユーザーに訓練する。監査を定期的に実行し、重複レコードを特定して統合。 |
誤ったデータが入力されました | 原因: ユーザーが採用プロセスで誤った情報 (開始日や名前のスペルなど) を入力したとします。 ソリューション: エラーを検出できる場合は、データ検証ルールを使用します。重大なエラーについては、完了済みの "採用"イベントの "訂正" アクションを使用してデータを修正する必要がある場合があります。データの正しい入力方法について、ユーザーに明確な指示と研修を提供します。 |
停止状態の処理 | 原因: 割り当てられたユーザーが不在であるか、アクションを実行していないため、ビジネス プロセスのステップが滞っています。 ソリューション: 主要なロールの委任を設定し、ユーザーが利用できない場合にタスクを自動的にリダイレクトできるようにします。"ビジネス プロセスのステータス" レポートを使用して、採用イベントの進捗状況をモニタリングし、ボトルネックを特定します。必要に応じて、タスクを別のユーザーに割当変更できます。 |
承認の誤り | 原因:ビジネス プロセスで承認者が誤った担当者にルーティングいるか、承認が必要ない場合に承認が必要となります。 ソリューション:ビジネス プロセス定義と承認ステップの条件ルールをレビューします。承認ステップに割り当てられているセキュリティ グループが正しく設定されており、条件ルールによってデータが正確に評価されていることを確認します。 |
エラー: 申請の組織、ポジション ()、ヘッドカウント要件、または選択された職務補充依頼は、現在補充できていないため、このビジネス プロセスは完了できませんでした。 | 原因: "採用" イベントに関連付けられているポジションに、"採用可能" というラベルが "いいえ" に設定されています。 ソリューション:ポジションを使用するには、以下の条件をすべて満たしている必要があります。
|
ビジネス プロセスのステップがイベント中に入力されていません | 原因:ビジネス プロセスでオートコンプリートが有効になっています。 例: 採用 BP の一部である "追加データの編集" ステップは、採用 BP でオートコンプリートが有効になっているため、"採用" イベントプロセス レコードに表示されません。 ビジネス プロセスにオートコンプリートが設定されている場合、親イベントの一部の部分がWorkdayされます。 |
ここにリストされていない問題については、 Communityでナレッジ記事を検索することをお勧めします。最良の結果を得るには、以下のことを行ってください。
- 二重引用符を使用して、プロセスの正確な名称を検索します。例: "採用ビジネス プロセス"。
- 以下の検索フィルタを選択して、最初の結果を絞り込みます。
- コンテンツ グループ: 記事
- コンテンツ タイプ: ナレッジ記事
- "ソート基準" フィルタを使用して、関連性または新しい順に結果を表示します。