-
Customer Experience -
Employee Experience -
Brand Experience -
Core XM -
Design XM
参加者ファイルのインポート準備 (EX)
参加者ファイルの準備について
参加者を従業員エンゲージメントプロジェクトにインポートする際は、いくつかの重要な点に留意してください。たとえば、すべてのインポートに以下の列が必要です。
- 名: 従業員の名。
- 姓: 従業員の姓。
- メール: 従業員のメールアドレス。この詳細が最も重要です。電子メールは、各参加者のユーザー名として、またはディレクトリにすでに存在するユーザーを覚えておくための手段として機能します。
注意: 参加者ファイルの電子メールフィールドを空白のままにすると、個人情報を入力するためのプレースホルダとして、UniqueID@BrandID.fake という形式を使用して人工電子メールが生成されます。生成されるメールは仮想メールであるため、メールが有効なアドレスに更新されるまで、EX配信は参加者に送信されません。
- UniqueIdentifier：会社が望む識別子で参加者を指定します。内部数値 ID からユーザー名まで、EmployeeID 列の繰り返しに使用できます (ただし、これが組織内で一意であり、他のプロジェクトでは誰とも共有されない場合に限ります)。
ヒント：詳細については「一意の識別子」サポートページを参照してください。
また、CSV／TSVファイルに含める参加者データのメタデータまたはカスタム列に影響するため、プロジェクトに適した階層を選択したことを確認する必要があります。たとえば、親 – 子階層ファイルには社員 ID とマネージャー ID の列を含める必要がありますが、レベルベースの階層ファイルには異なる Level 列を含める必要があります。このページの階層ごとに含める必要があるメタデータを参照します。
最初に正しいメタデータを含め忘れた場合は、それで問題ありません。参加者のメタデータは、リンクされたセクションの手順に従ってファクトの後にいつでも更新することができます。
親子階層の参加者のインポート
親子階層は、最も一般的に使用される種類の階層です。これらは、HR データが書式設定されているために従業員 ID の一覧および各従業員が報告するマネージャがある場合に最適なオプションです。
ここをクリックして、親子階層のテンプレートにアクセスします。
必要なメタデータ
親子階層を作成するには、次の 2 つのメタデータ列を含める必要があります。
- EmployeeID: 参加者の従業員 ID です。ランダムに生成された新しい ID を作成するのではなく、会社の人事部門が内部的に割り当てた ID を使用することをお奨めします。
- ManagerID: 参加者のマネージャーの従業員 ID です。
例: 下の画像では、John Doe の EmployeeID は 1 であるため、EmployeeID カラムは 1 になっています。Jill Davis、Sammy External、Joseph Miller は John Doe に直接レポートするため、ManagerID カラムには 1 と表示されます。
ヒント：技術的には、任意にEmployeeIDとManagerIDに名前を付けることができます。たとえば、組織で “従業員番号” という用語が優先される場合、または “QID” のような特別な用語がある場合は、列にこれらの名前を自由に指定してください。重要なのは、親子階層を生成するときに、これらのコンセプトを含めて正しいフィールドに入力することです。
社員とマネージャーの ID を追加する際には、いくつかの重要な点に留意してください。
- 親 – 子階層の生成時に、データの一意の ID 列を従業員 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 が認識され、適切にマッピングされます。
ヒント：同じ名前の別のチームがありますか？または、同じ部署内に別々のチームとマネージャーのレポートが存在しますか。個別の組織ユニット ID 項目を設定することで、同じ組織ユニットテキストを再利用することができます。たとえば、ある営業マネージャは組織ユニット ID 001 で販売というチームを実行し、別の販売マネージャは組織ユニット ID 002 で販売というチームを実行することができます。
組織ユニット ID は、マネージャが複数のチームに属する場合にも役立ちます。つまり、マネージャが John Doe で、John Doe がチーム A およびチーム B のマネージャである場合は、ユニット ID 項目で自分が属するチームを指定することができます。
- 組織ユニットの説明: 階層の作成時に、ユニット名が自動的にマネージャに付けられます。組織ユニットの説明設定では、代わりにユニットの名前または説明に基づいてユニットに名前を付けることができます。
組織ユニットの説明は、基本的に、指定した組織ユニット ID に対して指定された名前であり、ユニット別にフィルタリングまたは展開すると、ダッシュボードのユニットのラベルとして表示されます。カラムには必ずしも同じ正確な値が含まれている必要はありませんが、ID は数値ですが、Description は記述です。たとえば、組織 ID 2 の組織ユニットの説明はヨーロッパの部署である可能性があります。
例：下の画像では、John Doe は 2 つの異なるチーム（欧州部門と先導調査）を管理しています。組織ユニット説明列には、これらのチームのうち、3 人の直属の部下が属するチームが指定されます。Jill Davis と Joseph Miller は European Division に所属していますが、Sammy External は Lead Investigation にあります。
レベルベース階層の参加者のインポート
レベルベース階層は、HR データに、階層の上から下まで、従業員が管理する各レベルが含まれている場合に適しています。レベルベース階層では、必ずしも社員のマネージャーを把握する必要はありません。プロジェクトに含める各社員の指揮系統を把握するだけで済みます。このデータ形式は、さまざまなレベル、場所、または職務上の詳細区分に基づいて従業員データを編成する会社によく見られます。
ここをクリックして、レベルに基づく階層のテンプレートにアクセスします。
必要なメタデータ
定義する組織のレベルごとに個別の列が必要です。参加者に対して最後に入力されたレベルは、階層における参加者の位置を示します。上位の場合は、通常、第 1 レベル列が入力されますが、残りの列は入力されません。
マネージャーメタデータ
レベルベース階層でマネージャを単位に割り当てる場合は、2 つの異なる方法があります。
- マネージャ: この列は、参加者がマネージャであるかどうかを示します。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは、マネージャーを示すために “yes” を使用しますが、参加者がマネージャーであることを示す列の値が 1 つであれば、”1″、”manager”、または任意の形式を使用することもできます。
例：以下の図では、Sammy Stanage に対して定義された最下位レベルは、カスタマーサクセスの役割を担っているレベル 1 です。マネージャー列の「はい」は、カスタマーサクセスのマネージャーであることを示しています。一方、Jeff Brown の最後のレベルはエンジニアリング内の従業員エクスペリエンスです。つまり、エンジニアリング部門では、従業員エクスペリエンスレベルの責任者です。
- マネージャーレベル：マネージャーレベルは、管理している特定のレベルを呼び出すことでマネージャーを特定する手段です。前の例では、同じ値 (“yes”) は参加者がマネージャーであるかどうかを示していますが、Manager Level の場合は、レベルごとに異なる値があります。
例：下の画像では、ジェフ・ブラウンの「マネージャーレベル」は、エンジニアリングにおけるレベル 1 のマネージャーではなく、従業員エクスペリエンスにおけるレベル 2 のポジションのマネージャーであることを示す 2 です。
オプションのメタデータ
組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。安定した組織ユニット ID を含めると、階層データをマニュアルでマッピングする必要がなくなります。ID が認識され、適切にマッピングされます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。レベルごとに ID を指定できるように、実行するレベルと同じ数の組織ユニット ID を含める必要があります。
以下のスクリーンショットでは、レベル 2 のユニットは組織ユニット ID 2 の列に対応しています。Employee Experience エンジニアリングチームはユニット 201 で、Customer Experience エンジニアリングチームは 224 です。
スケルトン階層の参加者のインポート
スケルトン階層は、マネージャの ID は把握しているものの、直属の部下は把握していない場合に使用されます。直属の部下の一覧とその上のコマンドチェーンを中心に階層を編成するのではなく、マネージャーとロールアップ先のユニットの一覧を作成します。
ここでは、開始するスケルトン階層の例を示します。CSV／TSVを作成し、各マネージャーを含む行を作成します。スケルトン階層を構築するには、少なくともマネージャ情報が必要です。
マネージャーごとに、マネージャーの名、姓、メール、、および追加する任意の追加メタデータの列を追加します。次に、以下のメタデータを追加する必要があります。
- 組織ユニット ID: 従業員が管理するユニットの ID。
- 上位単位 ID: この単位のすぐ上にある単位の ID。これは、従業員の直属ユニットです。
- 組織の説明：このメタデータはオプションです。これにより、従業員が管理するユニットの名前を作成することができます。チーム名や、マネージャの名前も指定できます。
例: 以下の例では、IT 部門はエンジニアリングがネストされている大きな部門です。John Doe は IT のマネージャであるため、組織ユニット ID 列に 1 と表示され、IT のユニット ID が 1 であることが示されます。Geoff Brown と Jill Davis はエンジニアリングのマネージャであるため、IT がエンジニアリングの親単位であることを示す親組織 ID は 1 です。
回答者と回答者の対比回答者以外
回答者は、アンケートに回答できる参加者です。回答者以外とは、アンケートにアクセスできない参加者のことです。一部の参加者を回答者以外にするのは、一部の参加者がダッシュボードの結果を表示したり、組織の階層を検証し、アンケートには記入させないようにする場合に役立ちます。
追加する参加者がプロジェクトの回答者であるかどうかを判断するには、［回答者］というヘッダーを追加し、次の値のいずれかを使用します。
- 0 – 回答者以外
- 1 – 回答者
データに［回答者］列を含めない場合、すべての参加者がデフォルトで回答者として設定されます。
最大文字とサポートされる文字
各フィールドの最大文字数
- 名: 各名に対して 50 文字。
- 姓: 姓ごとに 50 文字。
- 電子メール: 各メールに 100 文字。
- UniqueIdentifier: 一意の識別子ごとに 100 文字。
- その他すべてのメタデータ: メタデータ名の上限はそれぞれ 90 文字、値の制限は 1000 文字です。
サポートされていない文字
次の文字は、メタデータ名または値のいずれでも使用できません:
|
&
;
$
%
< >
( )
{ }
*
+
,
`日付などの項目の値にはスラッシュ ( / ) を使用できますが、メタデータ項目名では使用できません。