14 タレント・オブジェクトのロード

この章の内容は次のとおりです。

目標、目標プランおよび目標プラン・セットのロード: 概要

HCMデータ・ローダーを使用すると、目標、目標プランおよび目標プラン・セットの各オブジェクトをロードできます。これらのオブジェクトのほとんどは、他のオブジェクトへの依存性があります。次の表は、ターゲット環境に存在する必要がある他のオブジェクトを示しています。目標、目標プランまたは目標プラン・セットとともにこれらのオブジェクトの一部またはすべてをロードする場合は、表に示すロード順序に従います。

オブジェクト オブジェクトのロード順序 注記

目標プラン

  1. 就業者およびプライマリ・アサイメント

  2. 適格プロファイル

  3. 組織

  4. 目標プラン文書タイプ

  5. 目標プラン

  • 関連する目標プランをアップロードする前に、レビュー期間がターゲット環境に存在する必要があります。

  • 組織目標プランでは、組織が必要です。

  • IncludeInPerfDoc属性がYに設定されている場合は、目標プラン文書タイプ・コンポーネントが必要です。

目標プラン・セット

  1. 目標プラン

  2. 就業者およびプライマリ・アサイメント

  3. 適格プロファイル

  4. 目標プラン・セット

  • 関連する目標プラン・セットをアップロードする前に、レビュー期間がターゲット環境に存在する必要があります。

  • 目標プラン・セット・オブジェクトは、目標プランを参照できます。

目標(ライブラリ)

  1. コンテンツ項目

ライブラリ目標は、コンテンツ項目としてロードされます。

目標(組織)

  1. 就業者(ライン・マネージャ)

  2. 組織

  3. 目標プラン

  4. 目標

組織目標の場合:

  • ライン・マネージャが組織所有者です。

  • 目標プランは必須です。

目標(テンプレート)

  1. 就業者(人事担当者)およびアサイメント

  2. 目標プラン

  3. 目標

目標プランは必須です。

目標(就業者育成)

  1. 就業者

  2. コンテンツ項目

  3. 目標

就業者育成目標が目標プランに関連付けられることはありません。

目標(就業者パフォーマンス)

  1. 就業者およびアサイメント

  2. 目標プラン

  3. コンテンツ項目

  4. 目標

就業者パフォーマンス目標は、目標プランに関連付ける必要があります。

目標のロード: 説明

目標は、従業員および組織の目的を表します。このトピックでは、目標を正常にロードするために理解する必要がある目標オブジェクトの側面について説明します。

目標タイプ

次の表は、HCMデータ・ローダーを使用してロードできる目標のタイプを示しています。

目標タイプ 説明

組織目標

特定の組織のマネージャによって作成されます。

テンプレート目標

目標プランで使用されます。

就業者目標

マネージャまたは人事担当者によって就業者に割り当てられます。次の2つのタイプの就業者目標が存在します。

  • 育成目標

  • パフォーマンス目標

注意: HCMデータ・ローダーを使用してライブラリ目標をロードすることもできます。ライブラリ目標は、プロファイル・コンテンツ項目としてロードします。他の目標オブジェクトからライブラリ目標を参照できます。

Goal.datファイルで目標をロードするときに、GoalTypeCode属性を含めることができます。この値は、HRG_GOAL_TYPE参照タイプを使用して検証されます。組織目標の場合は、GoalTypeCodeをデフォルト値のPERFORMANCEにする必要があります。

目標コンポーネント

目標のロード時に指定できるコンポーネントは、目標タイプによって異なります。次の表は、各コンポーネントを指定できる場合を示しています。

目標コンポーネント 目標タイプ

目標

すべて

目標処理

すべて

目標プラン目標

  • 就業者パフォーマンス目標

  • 組織目標

  • テンプレート目標

目標ターゲット結果

  • 就業者目標

  • テンプレート目標

目標指標

すべて

注意: 育成目標で指定できる目標指標コンポーネントは1つのみです。

目標アクセス

  • 就業者目標

目標連携

  • 就業者パフォーマンス目標

  • 組織目標

プロファイル・オプション

次の表は、目標コンポーネントを正常にロードするために、有効化してYに設定する必要があるプロファイル・オプションを示しています。

プロファイル・オプション オプションによって有効になるもの

HRG_ENABLE_GOAL_ALIGN

目標連携コンポーネントの目標の連携

HRG_ENABLE_GRANT_ACCESS

目標アクセス・コンポーネントの共有目標

HRG_ENABLE_OUTCOMES

目標ターゲット結果コンポーネントの目標ターゲット結果の作成

HRG_ENABLE_TASK

目標処理コンポーネントの目標タスクの作成

  • プロファイル・オプションを有効にするには、「プロファイル・オプションの管理」タスクを使用します。

  • プロファイル・オプションの値を設定するには、「管理者プロファイル値の管理」タスクを使用します。

「設定および保守」作業領域で両方のタスクを実行します。

目標の削除

HCMデータ・ローダーを使用して、目標オブジェクトを削除できます。親目標オブジェクトを削除すると、次の子コンポーネントも自動的に削除されます。

  • 目標アクセス

  • 目標処理

  • 目標連携。この場合はGoalIdまたはAlignedGoalIdによって、削除する目標が識別されます

  • 目標プラン目標

  • 目標ターゲット結果

必要に応じて、子コンポーネントを個別に削除することもできます。

HCMデータ・ローダーを使用して親目標を削除しても、目標指標コンポーネントが自動的に削除されることはありません。親目標を削除する前に、目標指標コンポーネントを明示的に削除する必要があります。次のGoal.datファイルの例では、目標指標コンポーネントを削除します。親目標は、ソース・キーによって識別されます。

METADATA|GoalMeasurement|SourceSystemId|SourceSystemOwner|GoalId(SourceSystemId) 
DELETE|GoalMeasurement|GoalMeasurement_001_SSID|VISION|WorkerGoal_001_SSID

次のGoal.datファイルの例では、目標指標以外のある目標とその子コンポーネントを削除します。目標は、ソース・キーによって識別されます。

METADATA|Goal|SourceSystemId|SourceSystemOwner 
DELETE|Goal|WorkerGoal_001_SSID|VISION

目標のロード: 例

このトピックでは、HCMデータ・ローダーを使用して就業者目標と組織目標をロードする方法について、例を示して説明します。

就業者目標の作成

次のGoal.datファイルの例では、就業者のアクティブなパフォーマンス目標を作成します。このファイルの内容は、次のとおりです。

  • ユーザー・キー属性WorkerPersonNumberおよびWorkerAssignmentNumberによって、就業者とその関連するアサイメントが識別されます。

  • ユーザー・キー属性AssignedByPersonNumberによって、目標を作成する人事担当者またはライン・マネージャが識別されます。

  • 目標プラン目標コンポーネントを指定する必要があります。

注意: 育成目標の場合は、目標プラン目標コンポーネントは必要ありません。
METADATA|Goal|SourceSystemId|SourceSystemOwner|GoalName|Description|StartDate|TargetCompletionDate|WorkerPersonNumber|WorkerAssignmentNumber|StatusCode|GoalSourceCode|AllowKeyAttrUpdateFlag|IncludeInPerfdocFlag|AssignedByPersonNumber 
MERGE|Goal|WorkerGoal_001_SSID|VISION|WorkerGoal_001|WorkerGoal_001_Desc|2015/01/01|2015/12/31|8153787|EEEE8153787|Not started|HR|Y|Y|8153756 
METADATA|GoalPlanGoal|SourceSystemId|SourceSystemOwner|GoalId(SourceSystemId)|GoalPlanName|GoalPlanStartDate|GoalPlanEndDate|PriorityCode 
MERGE|GoalPlanGoal|GoalPlanGoal_001_SSID|VISION|WorkerGoal_001_SSID|GP_009_01|2015/01/01|2015/12/31|Medium

ライブラリ目標に対する就業者目標の作成

次のGoal.datファイルの例では、就業者のライブラリ目標に対するアクティブなパフォーマンス目標を作成します。HCMデータ・ローダーでは、ライブラリ目標から値が取得されることはありません。かわりに、就業者目標のロード時にこれらの値を指定する必要があります。ReferenceContentItemName属性は、存在する必要がある、ライブラリ目標のユーザー・キーです。

METADATA|Goal|SourceSystemId|SourceSystemOwner|GoalName|Description|StartDate|TargetCompletionDate|WorkerPersonNumber|WorkerAssignmentNumber|StatusCode|GoalSourceCode|AllowKeyAttrUpdateFlag|IncludeInPerfdocFlag|AssignedByPersonNumber|ReferenceContentItemName 
MERGE|Goal|WorkerGoal_002_SSID|VISION|WorkerGoal_002|WorkerGoal_002_Desc|2015/01/01|2015/12/31|8153787|EEEE8153787|Not started|HR|Y|Y|8153756|ZHRG-Completing Learning Path

組織目標の作成

次のGoal.datファイルの例では、ライン・マネージャの組織目標を作成して公開します。このファイルの内容は、次のとおりです。

  • ユーザー・キー属性AssignedByPersonNumberによって、組織目標を所有するライン・マネージャが識別されます。組織目標を組織に公開するには、PublishedFlag属性をYに設定します。

  • GoalSourceCode属性はOrganization ownerに設定されます。組織目標では、この値は必須です。

  • 目標プラン目標コンポーネントを指定する必要があります。

METADATA|Goal|SourceSystemId|SourceSystemOwner|GoalName|Description|StartDate|TargetCompletionDate|OrganizationName|StatusCode|GoalSourceCode|AllowKeyAttrUpdateFlag|AssignedByPersonNumber|PublishedFlag 
MERGE|Goal|OrganizationGoal_001_SSID|VISION|OrganizationGoal_001|OrganizationGoal_001_Desc|2015/01/01|2015/12/31|Vision Corporation Enterprise|Not started|Organization owner|Y|8153786|Y 
METADATA|GoalPlanGoal|SourceSystemId|SourceSystemOwner|GoalId(SourceSystemId)|GoalPlanName|GoalPlanStartDate|GoalPlanEndDate|PriorityCode 
MERGE|GoalPlanGoal|GoalPlanGoal_002_SSID|VISION|OrganizationGoal_001_SSID |GP_009_01|2015/01/01|2015/12/31|Medium

目標プランのロード: 説明

目標プランは、就業者のグループに対する目標の一括割当に使用されます。このトピックでは、目標プランを正常にロードするために理解する必要がある目標プラン・オブジェクトの側面について説明します。

就業者に対する目標の割当

目標プラン・オブジェクトをロードしたときに、プランが自動的に就業者に割り当てられることはありません。次のいずれかの方法で、目標プランを就業者に割り当てることができます。

  • 「目標プランの管理」タスクを使用して、目標プラン割当をスケジュールします。

  • 目標プランの目標プラン割当コンポーネントをロードします。

一括要求コンポーネント

一括要求コンポーネントによって、目標プランの要求者が識別されます。RequestSubmissionDateReqSubmittedByPersonNumberなどの属性を指定することによって、目標プラン自体でプランの要求者を識別できます。この場合、一括要求コンポーネントが自動的に作成されるため、指定する必要はありません。ただし、次の場合は、目標プランの作成時に一括要求コンポーネントを指定する必要があります。

  • 目標プラン・オブジェクトでプランの要求者を識別しない場合。

  • 一括要求レコードにソース・キーを関連付ける場合。

    ソース・キー・オブジェクトを使用して、後でデフォルトのソース・キーを更新することもできます。

  • 一括要求コンポーネントの子コンポーネントをロードする場合。

    一括要求コンポーネントの子コンポーネントによって、目標プランが割り当てられる従業員のグループが識別されます。

目標プランの削除

HCMデータ・ローダーを使用して、目標プラン・オブジェクトを削除できます。ただし、就業者に割り当てられた目標プランは削除しないでください。親目標プラン・オブジェクトを削除すると、次の子コンポーネントも自動的に削除されます。

  • 目標プラン文書タイプ

  • 一括要求

    注意: 一括要求コンポーネントを削除すると、その子コンポーネントが自動的に削除されます。

必要に応じて、子コンポーネントを個別に削除することもできます。

HCMデータ・ローダーを使用して親目標プラン・コンポーネントを削除しても、目標プラン目標と目標プラン割当のコンポーネントが自動的に削除されることはありません。親目標プランを削除する前に、これらのコンポーネントを明示的に削除する必要があります。次のGoalPlan.datファイルの例では、目標プランGP_001_01をテンプレート目標TemplateGoal_001とリンクする目標プラン目標コンポーネントを削除します。

METADATA|GoalPlanGoal|SourceSystemId|SourceSystemOwner|GoalPlanExternalId 
DELETE|GoalPlanGoal|GPG_001_01_SSID|VISION|GP_001_01

次のGoal.datファイルの例では、テンプレート目標TemplateGoal_001 (SourceSystemId: TemplateGoal_001_SSID)を削除します。

METADATA|Goal|SourceSystemId|SourceSystemOwner 
DELETE|Goal|TemplateGoal_001_SSID|VISION

次のGoalPlan.datファイルの例では、目標プランGP_001_01とその関連する子レコードを削除します。

METADATA|GoalPlan|GoalPlanExternalId 
DELETE|GoalPlan|GP_001_01

目標プランのロード: 例

このトピックでは、HCMデータ・ローダーを使用して目標プラン・オブジェクトをロードする方法について、例を示して説明します。

目標プランの作成

次のGoalPlan.datファイルの例では、一括要求コンポーネントのない目標プランをロードします。この場合、ReqSubmittedByPersonNumber属性とRequestSubmissionDate属性に渡された値を使用して、目標プランの一括要求レコードが自動的に作成されます。

METADATA|GoalPlan|GoalPlanExternalId|GoalPlanName|GoalPlanTypeCode|GoalPlanActiveFlag|EnableWeightingFlag|StartDate|EndDate|EnforceGoalWeightFlag|GoalAccessLevelCode|IncludeInPerfdocFlag|ReqSubmittedByPersonNumber|RequestSubmissionDate|ReviewPeriodName 
MERGE|GoalPlan|GP_001_01|GP_001_01|ORA_HRG_WORKER|A|Y|2015/01/01|2015/12/31|Y|HR specialist and manager|N|8153756|2015/09/20|Default Review Period - Vision Corporation Enterprise

文書タイプを指定した目標プランの作成

次のGoalPlan.datファイルの例では、IncludeInPerfdocFlag属性がYに設定された目標プランを作成して、文書タイプを割り当てます。

METADATA|GoalPlan|GoalPlanExternalId|GoalPlanName|GoalPlanTypeCode|GoalPlanActiveFlag|EnableWeightingFlag|StartDate|EndDate|EnforceGoalWeightFlag|GoalAccessLevelCode|IncludeInPerfdocFlag|ReqSubmittedByPersonNumber|RequestSubmissionDate|ReviewPeriodName 
MERGE|GoalPlan|GP_001_02|GP_001_02|ORA_HRG_WORKER|A|Y|2016/01/01|2016/12/31|Y|HR specialist and manager|Y|8153756|2016/10/04|Default Review Period - Vision Corporation Enterprise 
METADATA|GoalPlanDocTypes|GoalPlanExternalId|DocTypeName 
MERGE|GoalPlanDocTypes|GP_001_02|Annual Evaluations

適格基準を指定した目標プランの作成

次のGoalPlan.datファイルの例では、一括要求コンポーネントと適格プロファイル・オブジェクト・コンポーネントを含む目標プランを作成します。

METADATA|GoalPlan|GoalPlanExternalId|GoalPlanName|GoalPlanTypeCode|GoalPlanActiveFlag|EnableWeightingFlag|StartDate|EndDate|EnforceGoalWeightFlag|GoalAccessLevelCode|IncludeInPerfdocFlag|ReviewPeriodName 
MERGE|GoalPlan|GP_001_04|GP_001_04|ORA_HRG_WORKER|A|Y|2016/01/01|2016/12/31|Y|HR specialist and manager|N|Default Review Period - Vision Corporation Enterprise 
METADATA|MassRequest|GoalPlanExternalId|ReqSubmittedByPersonNumber 
MERGE|MassRequest|GP_001_04|8153756 
METADATA|EligibilityProfileObject|GoalPlanExternalId|EligibilityProfileName|RequiredFlag 
MERGE|EligibilityProfileObject|GP_001_04|Goals_EligibilityProfile_Software Developer 4|Y

目標プラン・セットのロード: 説明

目標プラン・セットは、就業者のグループに対する関連する目標プランの一括割当に使用されます。このトピックでは、目標プラン・セットを正常にロードするために理解する必要がある目標プラン・セット・オブジェクトの側面について説明します。

就業者に対する目標プラン・セットの割当

目標プラン・セットは、ロードしたときに自動的に就業者に割り当てられることはありません。次のいずれかの方法で、目標プラン・セットを就業者に割り当てることができます。

  • 「目標プラン・セットの管理」タスクを使用して、目標プラン・セット割当をスケジュールします。

  • 目標プラン・オブジェクトの目標プラン割当コンポーネントをロードします。このアプローチは、法的エンティティ間の就業者の異動の後で目標を割り当てる場合などに使用できます。

一括要求コンポーネント

一括要求コンポーネントによって、目標プラン・セットの要求者が識別されます。RequestSubmissionDateReqSubmittedByPersonNumberなどの属性を指定することによって、目標プラン・セット自体でプランの要求者を識別できます。この場合、一括要求コンポーネントが自動的に作成されるため、指定する必要はありません。ただし、次の場合は、目標プラン・セットの作成時に一括要求コンポーネントを指定する必要があります。

  • 目標プラン・セット・オブジェクトでプランの要求者を識別しない場合。

  • 一括要求レコードにソース・キーを関連付ける場合。

    ソース・キー・オブジェクトを使用して、後でデフォルトのソース・キーを更新することもできます。

  • 一括要求コンポーネントの子コンポーネントをロードする場合。

    一括要求コンポーネントの子コンポーネントによって、目標プラン・セットが割り当てられる従業員のグループが識別されます。

目標プラン・セットの削除

HCMデータ・ローダーを使用して、目標プラン・セット・オブジェクトを削除できます。親目標プラン・セットを削除すると、次の子コンポーネントも自動的に削除されます。

  • 目標プラン・セット・プラン

  • 一括要求

注意: 一括要求コンポーネントを削除すると、その子コンポーネントが自動的に削除されます。

すでに就業者に割り当てられた目標プラン・セットは削除しないでください。

次のGoalPlanSet.datファイルの例では、目標プラン・セットとその子コンポーネントを削除します。

METADATA|GoalPlanSet|GoalPlanSetExternalId 
DELETE|GoalPlanSet|GPS_006_01

目標プラン・セットのロード: 例

このトピックでは、HCMデータ・ローダーを使用して目標プラン・セット・オブジェクトをロードする方法について、例を示して説明します。

目標プランを含む目標プラン・セットの作成

次のGoalPlanSet.datファイルの例では、目標プラン・セットを作成して、2つの目標プランを含めます。

METADATA|GoalPlanSet|GoalPlanSetExternalId|GoalPlanSetName|Description|GoalPlanSetActiveFlag|StartDate|EndDate|ReqSubmittedByPersonNumber|RequestSubmissionDate| ReviewPeriodName 
MERGE|GoalPlanSet|GPS_002_01|GPS_002_01|GPS_002_01|A|2015/01/01|2015/12/31|8153756|2015/09/28|Default Review Period - Vision Corporation Enterprise 
COMMENT Assign two goal plans without worker or eligibility profile assignment to the goal plan set 
METADATA|GoalPlanSetPlan|GoalPlanSetExternalId|GoalPlanExternalId|Weighting 
MERGE|GoalPlanSetPlan|GPS_002_01|GP_001_02|60 
MERGE|GoalPlanSetPlan|GPS_002_01|GP_001_03|40

この例では、目標プラン・セットに一括要求コンポーネントはありません。そのため、ReqSubmittedByPersonNumberRequestSubmissionDateの属性値を使用して、目標プラン・セットの一括要求レコードが自動的に作成されます。

一括要求コンポーネントを含む目標プラン・セットの作成

次のGoalPlanSet.datファイルの例では、一括要求コンポーネントを含む目標プラン・セットを作成します。この場合の目標プラン・セット・コンポーネントには、ReqSubmittedByPersonNumber属性とRequestSubmissionDate属性を指定しません。

METADATA|GoalPlanSet|GoalPlanSetExternalId|GoalPlanSetName|Description|GoalPlanSetActiveFlag|StartDate|EndDate|ReviewPeriodName 
MERGE|GoalPlanSet|GPS_001_02|GPS_001_02|GPS_001_02|A|2016/01/01|2016/12/31|Default Review Period - Vision Corporation Enterprise 
METADATA|MassRequest|GoalPlanSetExternalId|ReqSubmittedByPersonNumber 
MERGE|MassRequest|GPS_001_02|8153756

一括要求コンポーネントと一括要求階層コンポーネントを含む目標プラン・セットの作成

次のGoalPlanSet.datファイルの例では、一括要求コンポーネントと一括要求階層コンポーネントを含む目標プラン・セットを作成します。

METADATA|GoalPlanSet|GoalPlanSetExternalId|GoalPlanSetName|Description|GoalPlanSetActiveFlag|StartDate|EndDate|ReviewPeriodName 
MERGE|GoalPlanSet|GPS_001_04|GPS_001_04|GPS_001_04|A|2016/01/01|2016/12/31|Default Review Period - Vision Corporation Enterprise 
METADATA|MassRequest|GoalPlanSetExternalId|ReqSubmittedByPersonNumber 
MERGE|MassRequest|GPS_001_04|8153756 
COMMENT Assigning goal plan set GPS_001_04 to manager and reports 
METADATA|MassRequestHierarchy|GoalPlanSetExternalId|ManagerAssignmentNumber|CascadingLevel 
MERGE|MassRequestHierarchy|GPS_001_04|EEEE8153786|999999

タレント・プールのロード: 例

タレント・プールは、就業者のグループです。タレント・プールは、特定の目的でプール・メンバーの育成を管理するために使用します。たとえば、タレント・プールで後任プランの見込み候補者を追跡したり、タレント・プールに基づいてタレント・レビュー会議を作成することができます。このトピックでは、HCMデータ・ローダーを使用してタレント・プールを作成および管理する方法について、例を示して説明します。

タレント・プールの作成

タレント・プールでは、ジョブ、ジョブ・ファミリ、モデル・プロファイル、ポジション、部門および等級の任意の組合せを参照できます。これらのオブジェクトでは、タレント・プールの目的を定義でき、その処理には影響を及ぼしません。ただし、これらを参照するタレント・プールをロードする前に、これらがターゲット環境に存在する必要があります。次のTalentPool.datファイルの例では、ジョブのタレント・プールを作成します。タレント・プールとその関連するジョブの両方を識別するために、ソース・キーが使用されます。

METADATA|TalentPool|SourceSystemOwner|SourceSystemId|PoolName|PoolTypeCode|Description|OwnerPersonId(SourceSystemId)|Status|JobId(SourceSystemId) 
MERGE|TalentPool|VISION|TP_T1|Job Chief Exec|TALENT|Talent pool description|1008|A|93079

常にPoolTypeCode属性をTALENTに設定します。Status属性を含める必要があります。値を指定しない場合、デフォルトのステータスはA (アクティブ)です。タレント・プールを非アクティブ化するには、ステータスをI (非アクティブ)に設定します。

タレント・プール・コンポーネントによって、タレント・プールと最初のプール所有者が定義されます。追加のプール所有者を指定するには、タレント・プール所有者コンポーネントを使用します。追加のプール所有者はオプションですが、複数の所有者をお薦めします。タレント・プール所有者は、アプリケーションでタレント・プールを表示できます。タレント・プール・メンバー・コンポーネントを使用して、プール・メンバーを定義します。次のTalentPool.datファイルの例では、プール・メンバーを含むタレント・プールを作成します。タレント・プールを識別して外部オブジェクトを参照するために、ソース・キーが使用されます。

METADATA|TalentPool|SourceSystemOwner|SourceSystemId|PoolName|PoolTypeCode|Description|OwnerPersonId(SourceSystemId)|Status 
MERGE|TalentPool|VISION|TP_T2|Member Talent Pool|TALENT|Talent pool description|1011|A 
METADATA|PoolMember|SourceSystemOwner|SourceSystemId|PoolId(SourceSystemId)|MemberId(SourceSystemId) 
MERGE|PoolMember|VISION|TP_PM_T2_1012|TP_T2|1012 
MERGE|PoolMember|VISION|TP_PM_T2_1013|TP_T2|1013

タレント・プール名の翻訳

次のTalentPoolTranslation.datファイルの例では、既存のタレント・プールの名前を翻訳します。ここでは、ソース・キーによって既存のレコードが識別されます。

METADATA|TalentPoolTranslation|SourceSystemOwner|SourceSystemId|PoolName|Language 
MERGE|TalentPoolTranslation|VISION|TP_T1|Spanish Translated Pool Name|ES 
MERGE|TalentPoolTranslation|VISION|TP_T1|French Translated Pool Name|FR

次のTalentPoolTranslation.datファイルの例では、既存のタレント・プールの名前を翻訳します。ここでは、ユーザー・キーによって既存のレコードが識別されます。

METADATA|TalentPoolTranslation|BasePoolName|PoolStatus|PoolName|Language 
MERGE|TalentPoolTranslation|Job Chief Exec|A|Spanish Translated Pool Name|ES 
MERGE|TalentPoolTranslation|Job Chief Exec|A|French Translated Pool Name|FR

タレント・プールの削除

タレント・プールは、HCMデータ・ローダーを使用して削除できません。ただし、次のことができます。

  • タレント・プールを非アクティブにします。

  • 1人以上のプール所有者を残して、タレント・プール所有者を削除します。

  • タレント・プール・メンバー・コンポーネントを削除します。

次のTalentPool.datファイルの例では、既存のタレント・プール所有者コンポーネントを削除します。ここでは、ソース・キーによってプール所有者レコードが識別されます。

METADATA|PoolOwner|SourceSystemOwner|SourceSystemId 
DELETE|PoolOwner|VISION|TP_PO_T2_3423|TP_PM_T2_1013

タレント・プロファイル・データのロード: 説明

タレント・プロファイル・オブジェクトには、タレント・プロファイル、コンテンツ項目、コンテンツ項目関係、教育機関および評点モデルがあります。このトピックでは、HCMデータ・ローダーを使用して正常にロードするために理解する必要があるタレント・プロファイル・オブジェクトの側面について説明します。

タレント・プロファイルのロード

タレント・プロファイルには個人プロファイルとモデル・プロファイルがあります。個人プロファイルには、就業者のスキル、資格、成果およびキャリア志向に関する情報が含まれます。モデル・プロファイルには、ジョブまたはポジションに必要なスキルおよび資格に関する情報が含まれます。HCMデータ・ローダーを使用して、個人プロファイルとモデル・プロファイルの両方をロードできます。

次の表では、タレント・プロファイル・オブジェクトの一部のコンポーネントに関する主要情報を要約しています。

コンポーネント 説明

プロファイル項目

コンテンツ項目のデータを保持します。コンテンツ項目とは、コンテンツ・ライブラリ内のコンテンツ・タイプに属するスキル、資格および資質です。たとえば、コミュニケーション・スキルはコンピテンシ・コンテンツ・タイプのコンテンツ項目である場合があります。プロファイル項目コンポーネントは、プロファイル内で一意にする必要があります。

ヒント: 重複するプロファイル項目には、同じ資質と重複する開始日および終了日が含まれます。

プロファイル・キーワード

個人プロファイル内の専門分野および関心分野のキーワードを保持します。

モデル・プロファイルには無効です。

プロファイル関連

ジョブまたはポジションにモデル・プロファイルをリンクします。次のルールが適用されます。

  • HCMデータ・ローダーを使用してプロファイルをアップロードする場合、モデル・プロファイルをジョブ・ファミリまたは組織にリンクすることはできません。このため、これらの構造用にロードするモデル・プロファイルは、情報目的専用になります。

  • 1つのジョブやポジションを同じプロファイルに複数回関連付けることはできません。

個人プロファイルには無効です。

1人の個人は1つの個人プロファイルのみ持つことができます。個人プロファイルの作成対象である個人への参照を指定する必要があります。モデル・プロファイルには個人参照を指定しないでください。

コンテンツ項目のロード

コンテンツ項目はコンテンツ・タイプの特定のオカレンスです。関連付けられたコンテンツ・タイプおよびそのフィールド・プロパティは、コンテンツ・ライブラリにコンテンツ項目をロードする前にターゲット環境に存在する必要があります。コンテンツ・タイプのフィールド・プロパティは、コンテンツ項目について収集できる情報を示します。

コンテンツ項目関係のロード

コンテンツ項目関係は、2つのコンテンツ項目間の関係を定義します。コンテンツ項目は、別のコンテンツ項目の親にも子にもなることができます。次のルールが適用されます。

  • 2つのコンテンツ項目が異なるコンテンツ・タイプに属している必要があります。

  • 同じ2つのコンテンツ項目間に複数の関係を作成することはできません。たとえば、コンテンツ項目Aをコンテンツ項目Bの親と子の両方にすることはできません。

  • コンテンツ項目とそれ自体の間に関係を作成することはできません。

  • コンテンツ項目関係の開始日および終了日は、関連付けられたコンテンツ項目の日付範囲外にしないでください。

  • 関連付けられたコンテンツ・タイプ間の関係は、関連するコンテンツ項目をロードする前にターゲット環境に存在する必要があります。

教育機関のロード

教育機関とは、就業者が自分のプロファイルに教育情報を追加するときに選択する学校、単科大学、総合大学またはその他の組織です。たとえば、第三者から教育機関のリストを入手する場合があります。HCMデータ・ローダーを使用して、この情報をアップロードできます。

次の地理構造は、参照する教育機関をロードする前に、ターゲット環境に存在する必要があります。

  • 都道府県または州

評点モデルのロード

評点モデルを使用し、個人プロファイル内のスキルおよび資質のパフォーマンスおよび熟達度に基づいて、就業者を評点付けします。評点モデルを使用して、モデル・プロファイル内の項目のターゲット熟達度レベルを指定することもできます。ロードする子の評点レベルおよび評点カテゴリ・コンポーネントと同じファイルに親の評点モデルコンポーネントを含める必要があります。