階層を作成するためのユーザーファイルの準備（CX）

階層を作成するためのユーザファイルの準備について

CXダッシュボードにユーザーをインポートする際は、いくつかの重要な点に留意してください。たとえば、すべてのインポートに以下の列が必要です。

• 名: ユーザの名。
• 姓: ユーザーの姓。
• 電子メール: ユーザーの電子メールアドレス。この詳細が最も重要です。電子メールは、各ユーザーのユーザー名として、またはユーザー管理にすでに存在するユーザーを記憶する方法として機能します。
• ユーザー名：組織で SSO が使用されている場合は、［ユーザー名］列を含める必要があります。#brandId は自動的に末尾に追加されるため、この列には電子メール列と同じ情報が含まれている必要があります。
• 言語: この列は技術的にはオプションです。ただし、これを含める場合は、ここに表示されているように言語を大文字化し、各ユーザの値を言語コードで入力するよう注意する必要があります。

また、CSV/TSVファイルに含めるユーザー属性またはユーザーデータのカスタム列に影響するため、プロジェクトに適した階層を選択したことを確認する必要があります。たとえば、親 – 子階層ファイルには社員 ID とマネージャー ID の列を含める必要がありますが、レベルベースの階層ファイルには異なる Level 列を含める必要があります。

親子階層のファイルの準備

親子階層は、最も一般的に使用される種類の階層です。これらは、HR データが書式設定されているために従業員 ID の一覧および各従業員が報告するマネージャがある場合に最適なオプションです。

ファイルの構築が完了し、階層を作成する準備ができたら、「親子階層の生成」を参照してください。

必要なメタデータ

親子階層を作成するには、次の 2 つのメタデータ列を含める必要があります。

• EmployeeID: 参加者の従業員 ID です。ランダムに生成された新しい ID を作成するのではなく、会社の人事部門が内部的に割り当てた ID を使用することをお奨めします。
• ManagerID: 参加者のマネージャーの従業員 ID です。

社員とマネージャーの ID を追加する際には、いくつかの重要な点に留意してください。

• すべての参加者には、一意の従業員 ID も必要です。複数の参加者が同じ ID を共有することはできません。
• すべての参加者にマネージャーが必要です。唯一の例外は、階層に含める会社の最上位メンバー（CEO など）です。この個人が誰の部下にも報告しないことを示すには、manager 列を空白のままにします。
• 個々の社員の [従業員 ID] 列と [マネージャー ID] 列は同じにできません。従業員は自分自身に報告しません。
• すべてのマネージャー ID は、社員にリンクし直す必要があります。既存の従業員 ID に対応していないマネージャー ID を持つ参加者は、不明なマネージャーに割り当てられます。不明なマネージャーにユーザーが割り当てられると、そのユーザーの下にある階層のメンバーも破損することに注意してください。この問題を解決するには、データをマニュアルで修正し、階層を再生成する必要があります。
• 循環ロジックに注意してください。John Doe が Jane Smith に報告し、Jane Smith が Joseph Miller にレポートした場合、Joseph Miller は John Doe に報告できません。あなたのマネージャーのマネージャーを管理することはできません。

オプションのメタデータ

参加者リストのアップロード時に、任意のメタデータを追加することができます。各社員の誕生日から所属事務所の場所まで何でも含めることができる。ただし、親子階層の書式設定に役立つ 2 つのオプションのメタデータがあります。

• 組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。
  ヒント：同じ名前の別のチームがありますか？または、同じ部署内に別々のチームとマネージャーのレポートが存在しますか。個別の組織ユニット ID 項目を設定することで、同じ組織ユニットテキストを再利用することができます。たとえば、ある営業マネージャは組織ユニット ID 001 で販売というチームを実行し、別の販売マネージャは組織ユニット ID 002 で販売というチームを実行することができます。

  組織ユニット ID は、マネージャが複数のチームに属する場合にも役立ちます。つまり、マネージャが John Doe で、John Doe がチーム A およびチーム B のマネージャである場合は、ユニット ID 項目で自分が属するチームを指定することができます。

• 組織ユニットの説明: 階層の作成時に、ユニット名が自動的にマネージャに付けられます。組織ユニットの説明設定では、代わりにユニットの名前または説明に基づいてユニットに名前を付けることができます。

組織ユニットの説明は、基本的に、指定した組織ユニット ID に対して指定された名前であり、ユニット別にフィルタリングまたは展開すると、ダッシュボードのユニットのラベルとして表示されます。カラムには必ずしも同じ正確な値が含まれている必要はありませんが、ID は数値ですが、Description は記述です。たとえば、組織 ID 2 の組織ユニットの説明はヨーロッパの部署である可能性があります。

レベルベース階層のファイルの準備

レベルベース階層は、HR データに、階層の上から下まで、従業員が管理する各レベルが含まれている場合に適しています。レベルベース階層では、必ずしも社員のマネージャーを把握する必要はありません。プロジェクトに含める各社員の指揮系統を把握するだけで済みます。このデータ形式は、さまざまなレベル、場所、または職務上の詳細区分に基づいて従業員データを編成する会社によく見られます。

ファイルの構築が完了し、レベルベース階層を作成する準備ができたら、「レベルベース階層の生成」を参照してください。

必要なメタデータ

定義する組織のレベルごとに個別の列が必要です。参加者に対して最後に入力されたレベルは、階層における参加者の位置を示します。上位の場合は、通常、第 1 レベル列が入力されますが、残りの列は入力されません。

マネージャーメタデータ

レベルベース階層でマネージャを単位に割り当てる場合は、2 つの異なる方法があります。

• マネージャ: この列は、参加者がマネージャであるかどうかを示します。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは、マネージャーを示すために “yes” を使用しますが、参加者がマネージャーであることを示す列の値が 1 つであれば、”1″、”manager”、または任意の形式を使用することもできます。
  例：以下の図では、Sammy Stanage に対して定義された最下位レベルは、カスタマーサクセスの役割を担っているレベル 1 です。マネージャー列の「はい」は、カスタマーサクセスのマネージャーであることを示しています。一方、Jeff Brown の最後のレベルはエンジニアリング内の従業員エクスペリエンスです。つまり、エンジニアリング部門では、従業員エクスペリエンスレベルの責任者です。
  
• マネージャーレベル：マネージャーレベルは、管理している特定のレベルを呼び出すことでマネージャーを特定する手段です。前の例では、同じ値 (“yes”) は参加者がマネージャーであるかどうかを示していますが、Manager Level の場合は、レベルごとに異なる値があります。
  例：下の画像では、ジェフ・ブラウンの「マネージャーレベル」は、エンジニアリングにおけるレベル 1 のマネージャーではなく、従業員エクスペリエンスにおけるレベル 2 のポジションのマネージャーであることを示す 2 です。
  

オプションのメタデータ

組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。レベルごとに ID を指定できるように、実行するレベルと同じ数の組織ユニット ID を含める必要があります。

以下のスクリーンショットでは、レベル 2 のユニットは組織ユニット ID 2 の列に対応しています。Employee Experience エンジニアリングチームはユニット 201 で、Customer Experience エンジニアリングチームは 224 です。

FAQ