メインコンテンツにスキップ
Loading...
Skip to article
  • Customer Experience
    Customer Experience
  • Employee Experience
    Employee Experience
  • Brand Experience
    Brand Experience
  • Core XM
    Core XM
  • Design XM
    Design XM

階層概要


Was this helpful?


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The feedback you submit here is used only to help improve this page.

That’s great! Thank you for your feedback!

Thank you for your feedback!


階層について

階層を使用すると、組織の従業員体系をクアルトリクスにアップロードできます。これらは従業員エンゲージメントプロジェクトの主要な機能であり、これらを適切に設定すると、ダッシュボードにマネージャまたはユニット別にデータが表示されます。

階層はエンゲージメントダッシュボードとCXダッシュボードに追加できますが、ライフサイクルプロジェクトやアドホック従業員調査プロジェクトには追加できません。

静的 vs. CXダッシュボードの動的な階層

注意:この情報は、組織階層をCXダッシュボードプロジェクトに追加する場合にのみ関連します。エンゲージメントプロジェクトを使用している場合は、このページの次のセクションにスキップすることができます。

組織階層をCXダッシュボードに追加するには、データセットにユーザーの一意の識別子が含まれている必要があります。インポートされたデータプロジェクトにデータをアップロードする場合は、CSV ファイルに各ユーザーの一意の識別子を含む列を含めるのと同じくらい簡単です。

ただし、アンケートプロジェクトで作業している場合は、ダッシュボードにマッピングする前に、正しい情報がアンケートに含まれていることを確認する必要があります。これには 2 つの方法があります。

静的階層

静的階層を使用すると、追加の埋め込みデータとして階層情報をアンケート回答データに直接追加できます。つまり、データの収集後に階層に対して調整が行われた場合、階層更新は今後の回答データにのみ反映されます。これは、階層情報がアンケートの回答時に追加されるためです。

詳細については、静的階層を参照してください。

動的階層

動的階層を使用すると、アンケートの回答自体ではなく、ダッシュボードデータに階層をリンクできます。その結果、階層が変更されると、ダッシュボードデータに反映されます

階層情報は、応答の一意の ID を階層の一意の ID と一致させることで、応答にリンクされます。その後、階層情報がダッシュボードデータと照合されます。階層が更新されるたびに、自動的にダッシュボードデータと照合され、動的な更新が可能になります。

動的階層を実装するには、まず、階層内のユーザの一意の ID と一致する一意の ID が応答に含まれていることを確認してください。詳細については、動的階層を参照してください。

回答に一意の識別子が表示されたら、ステップに従って組織階層をCXダッシュボードに追加します

データに最適な階層の選択

階層の 2 つの主要タイプは、親 – 子 (CX|EE) およびレベルベース (CX|EE) です。親子階層とレベルベース階層の両方で、組織の構造を生成し、社員のリストに基づいてマネージャーを識別することができます。ただし、選択する階層のタイプは、会社の組織構造とほとんど関係がなく、最も便利なデータに関係しています。

親子 vs. レベルベース階層

親子階層(CX|EE)は、エンゲージメントプロジェクトで最も一般的に使用される階層の種類であり、一般的に簡単に設定できます。親子階層は、各社員の HR データに一意の ID とマネージャーの ID が含まれている場合に最適です。

例: データのスプレッドシートがあります。各行は従業員です。各従業員には、従業員 ID の列と、マネージャの ID の列があります。

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

例: Barnaby は販売オペレーションチームのメンバーです。このチームは、Employee Experience 製品を販売する部門に所属する販売部門に所属しています。従業員データファイルの Division 列に Employee Experience、Department 列に Sales、次の列に Sales Operations があります。

レベルベース階層が親子階層よりも優れているのは、階層が不完全なプロジェクトを実行する場合です。たとえば、会社全体ではなく、少数のチームのみでプロジェクトを実行しているとします。親子階層では、すべての従業員とすべてのマネージャを組織ユニットに配置することで、コマンドチェーンが決定されます。従業員が不足している場合は、ユニットの破損や異動が発生する可能性があります。一方、レベルベース階層では、各従業員が最上位までのレポートライン全体を含む行で定義されます。指揮系統がまだあるからといって、何人か行方不明になっても大丈夫。

一方、マネージャーの定義に関しては、親子がはるかに単純に構築できる。レベルベース階層でそれらにロールアップされるマネージャおよびデータを特定することもできますが、そのためには、データに列を追加する必要があり、マネージャは管理するユニットまでコード化する必要があります。

階層の生成方法

クアルトリクスが背後にある階層を構築する方法に関心がありますか?参加者ファイル (CX|EE) をアップロードすると、各行が異なる従業員を表します。Qualtricsがリストを下に移動すると、各社員が識別され、その社員に添付された情報(マネージャー、組織ユニット、レベルなど)を使用して、組織内の所属するユニットを特定します。

例: ファイルの最初の行には、従業員 Jane Doe に関する情報が含まれています。彼女の ID は i322 で マネージャーの ID は i205 です
  1. マネージャ i205 のユニットを登録し、その中に Jane を配置します。
  2. ファイルを下に移動すると、従業員 i205 は Barnaby Smith という名前になります。ここで、Jane が所属するユニットが Barnaby によって運営されていることがわかっているため、”unit for manager i205″ を “Barnaby Smith” に変更します。
  3. さらに、Barnabyのマネージャーが誰なのかを見ることができ、この情報を利用して、彼が管理するユニットと部下となるユニットを階層内の適切な位置に配置することができる。

ファイルは、特定の順序 (最低従業員から最高従業員など) で書き込む必要はありません。ファイル内の社員リストが下に表示されるため、Qualtricsは階層をまとめます。最も重要なことは、階層内の必要な従業員がすべて存在し、指揮系統に対する循環ロジックがないことです (たとえば、Barnaby のマネージャは、すでにジェーンのマネージャである場合、Jane になることはできません)。

追加階層タイプ

親子階層とレベルベース階層のほかに、2 種類の階層があり、使用頻度はかなり低いが、プロジェクトのニーズに適合する場合があります。

  1. スケルトン階層: このオプションは、直属の部下を把握していない (またはその ID を公開したくない) が、マネージャーを把握している場合に最適です。この階層は、すべての社員と下のリストではなく、マネージャーおよびマネージャーが実行するユニットのリストを中心に構成されているため、親 – 子およびレベルベース階層とは大きく異なります。
  2. アドホック階層 (CX|EE): アドホック階層は、開始するのに最低限必要な最小限の参加者情報しか必要ないため、より簡単に思えることがよくあります。ただし、親子階層とレベルベース階層の利点は、参加者データ(CX|EE)の詳細ファイルを作成した後、階層を終了するだけで、いくつかのスイッチをフリップするだけで済みます。一方、アドホック階層では、すべての参加者を正しい階層単位にマニュアルで配置し、すべてのマネージャと単位をマニュアルで設定する必要があります。通常、この方法は推奨されません。ただし、参加者リストが非常に小さい場合を除きます。

よくある質問

当サポートサイトの日本語のコンテンツは英語原文より機械翻訳されており、補助的な参照を目的としています。機械翻訳の精度は十分な注意を払っていますが、もし、英語・日本語翻訳が異なる場合は英語版が正となります。英語原文と機械翻訳の間に矛盾があっても、法的拘束力はありません。