組織のデータ ファイルのアップロードを準備する
高度な分析情報アプリは、既定の設定である Azure Active Directory または管理者がアップロードする組織データ ファイルを使用して、2 つの方法のいずれかで組織データを取得できます。 この記事では、2 つ目のオプションである組織データ ファイルについて説明します。 組織のデータをアップロードする前に、管理者がデータを特定、収集、構造化するために必要な操作を確認するために読み上げました。
組織データ全般については、Azure Active Directory がViva Insightsと自動的に同期するデータを確認し、高度な分析情報管理者エクスペリエンスの [組織データ] ページの概要については、「Viva Insightsの組織データ」を参照してください。
重要
組織のデータを含む.csv ファイルをアップロードした後は、Azure Active Directory の使用に戻ることはできません。 組織のデータを最新の状態に保つために、.csvファイルを定期的にアップロードする必要があります。
組織データを準備する
組織のデータ ファイルの操作を開始する準備ができたら、次のセクションでデータ準備プロセスについて説明します。
- 分析する傾向を特定する – 職場の効率を向上させるために学習する必要がある傾向を決定します。 これらの傾向を特定したら、使用する組織データをより適切に選択できます。
- 含めるデータを把握する – いくつかのデータ属性が必要であり、多くは省略可能です。 オプションの中から、分析目的に最適なものを選択します。
- 組織データのエクスポートを取得する – 管理者に組織の人事システムから人事データをエクスポートさせます。 必要に応じて、分析に必要な場合は、基幹業務データを含めます。
- 組織のデータを構造化する – データを正常に検証するには、最初にアップロードするファイルthe.csv正しく構造化する必要があります。
- 組織のデータ ファイルをアップロードする – .csv ファイルの準備ができたら、高度な分析情報アプリにアップロードします。検証と処理の後、分析に使用できるようになります。
分析する傾向を特定する
抽出する組織データを把握するには、まず、学習する職場の傾向を決定する必要があります。 たとえば、今後の分析では、異なる従業員セグメントまたはグループ間のコラボレーションを調べることができます。 最初にこれらのグループを定義する必要があります。これはさまざまな方法で行うことができます。
- 組織データ別
- 組織階層レベル別
- パフォーマンス、エンゲージメント、またはその他の基幹業務データ別
定義されたグループは、次の分析例で使用できます。
グループ間でのコラボレーション
一般的な分析シナリオは、従業員の異なるグループ間のコラボレーションのパターンを見つけることです。 たとえば、製品マーケティング チームが営業チームとどの程度話しているかを知りたいとします。
母集団をセグメント化するための属性は、次のようなコラボレーションのパターンを定義する際に考慮するのに役立ちます。
- 職業、関数、規範、ジョブ コードなどのジョブ ファミリまたはロールの属性
- 人事、財務、営業、マーケティングなどの組織、基幹業務、またはコスト センター
- 組織で定義されている都市、州、国、地域などの場所属性
- リモート、フルタイムの従業員、ベンダー、パートタイムまたはフルタイム、組織内での在任期間、現在のロールの在任期間など、自分の仕事を表す属性
これらの属性のほとんどは、人事情報システム内で入手できます。
階層的なコラボレーション
また、組織の階層を参照してコラボレーション動作のパターンを求めるだけでなく、マネージャーと個々の共同作成者間、および組織内の上位レベルと下位レベルとレイヤー間のコラボレーションを定量化することも一般的です。
この種の分析では、次の概念が役立ちます。
- IC またはマネージャー - 従業員が個人の共同作成者かマネージャーか。
- 組織階層 – たとえば、その従業員のレポート構造の従業員より上のすべてのマネージャーの名前。各マネージャーは、個別の属性として格納できます。
- レイヤー – たとえば、階層 0 が会社のトップ リーダーである組織階層での従業員の位置です。
- スパン – たとえば、従業員に割り当てられた直接レポートの数。
- レベル – シニア マネージャー、VP、ディレクター、CVP など。
これらの属性のほとんどは、人事情報システムにも存在します。
コラボレーション、エンゲージメント、および成果のデータ
最後に、コラボレーションの行動パターンを従業員エンゲージメント スコアや、売上クォータの達成や高/低パフォーマンス評価などの他のパフォーマンス成果データに結び付ける方法を検討できます。 このデータは、多くの場合、従来の人事情報システムの外部で、個別の人事データ リポジトリまたは基幹業務システムで見つかります。
含めるデータを把握する
高度な分析情報アプリから完全な機能を取得するには、「属性リファレンス」で説明されているように、いくつかの必須属性を指定する必要 があります。 さらに、最大 100 個の省略可能な属性を指定して、興味深いカスタムの方法でデータをグループ化およびフィルター処理できます。
組織データの例としては、ジョブ ファミリ、ジョブ ロール、組織、基幹業務、コスト センター、場所、地域、レイヤー、レベル、直接レポートの数、マネージャーなどがあります。 このデータは、個々のレベルで高度な分析情報アプリに提供されます。つまり、これらの属性は、データセット内の各ユーザーにコンテキストを提供します。
含める従業員
少なくとも、Viva Insights ライセンスを持つすべての従業員の組織データを含めます。 サブグループ (つまり、社内の特定のターゲット母集団) についてのみコラボレーション データを収集する予定がある場合でも、データアップロードの一部として社内のすべてのユーザーを含める方が良い場合があります。
たとえば、マーケティング担当者が製品開発のユーザーと頻繁に通信するが、アプリにマーケティング組織に関する人事データしかない場合、マーケティングが製品開発に費やしている時間を示すレポートを作成することはできません。
組織内のすべてのユーザーを含めることができない場合、最小限含めるのは、コラボレーション データが収集されているすべてのユーザーです。 この最小値を使用すると、この母集団内のグループ間のコラボレーション パターンを分析できますが、この母集団外のグループ間では分析できません。
ライセンスを持つすべての従業員を含む
組織のデータを最新の状態に維持し、完全に管理するのは管理者の責任です。 このタスクでは、"完了" とは、適切なユーザーを含み、それらのユーザーに適した属性を含むデータという 2 つのことを意味します。
組織内のすべてのライセンスを持つ従業員を含める理由は、組織のデータが不足している場合、アナリストが [分析 ] ページでクエリを作成するときに、そのデータでフィルター処理できないことです。 そのため、データが欠落している従業員は、アナリストが実行する分析から除外されます。
不足しているデータの通知
1 人以上のライセンスを持つ従業員のデータが見つからないことがアプリで検出された場合は、[ データ接続 ] タブの右上隅にあるポップアップ通知を通じて管理者に警告します。
不足している組織データをアップロードする
この不足しているデータをアップロードするには、管理者は次の手順に従います。
- ポップアップ通知で、[ ダウンロード ] を選択して、組織のデータが不足しているライセンスを持つ従業員の名前を含む.csv ファイルをダウンロードします。
- .csv ファイルを開きます。
- これらの従業員の不足しているデータを追加します。 これは、以前のアップロードと一致する方法で従業員を記述する属性 (列) を追加することを意味します。
- ファイルをアップロードします。 詳細については、「 組織データのアップロード (後続のアップロード)」を参照してください。
組織データのアップロードにライセンスを持つすべての従業員を含めることに加えて、 先ほど説明したように、ライセンスのない従業員も含めることをお勧めします。
組織データのエクスポートを取得する
組織のデータを書式設定してアップロードする前に、1 つ以上のソースから取得する必要があります。 主なソースは、組織の人事情報システムを管理するチームです。 このチームでは、個々の従業員の人事属性のデータ エクスポートを提供する必要があります。
さらに、アナリストはビジネス成果に関するデータを必要とすることがあります。 その場合は、この情報を含むデータ ストアにアクセスできる基幹業務所有者に問い合わせる必要があります。 たとえば、このデータには次のものが含まれます。
- 特定の作業グループのパフォーマンス レビュー データ。
- 人事情報システム外の人事情報から獲得した従業員エンゲージメントのスコア
- パフォーマンスに追加のビューを提供する売上またはその他のクォータ達成データ。
- 従業員のアンケートのデータ。
このデータを取得した後、アプリにアップロードした後に処理を成功させるには、データを構造化する必要があります。
組織データを構造化する
提供するデータを特定したら、アップロードする正しい形式にエクスポートする必要があります。 最初に、データは UTF-8 でエンコードされた.csv ファイル内にあり、少なくとも、作成に必要な属性のセットを含める必要があります。この属性は、ファイル内の任意の順序で指定できます。
ファイル名には英数字 (文字と数字) のみが含まれている必要があり、スペースや特殊文字は含めず、たとえば、FileName2.csv。
必須の属性
次の属性を列ヘッダーとして指定します。次に示すとおりに、.csvアップロードします。
- EffectiveDate
- EffectiveDate 列にすべての行に値があることを確認します。 アップロードに EffectiveDate 列を指定しない場合、データをアップロードした日付が既定の EffectiveDate になります。
- Personid
- Managerid
- 組織 (大文字と小文字が区別されます)
予約済みの省略可能な属性
次の属性は、現在データの計算、フィルター処理、およびグループ化に使用されている属性の予約列ヘッダーです。
- LevelDesignation
- FunctionType
- HireDate
- HourlyRate
- Layer
- SupervisorIndicator
- OnsiteDays
- Location
注:
属性は、ファイル内の任意の順序で指定できます。 ただし、これらの必須属性と予約属性の名前を、新しいカスタム属性の名前として使用することはできません。
カスタム属性
カスタム属性は、データのフィルター処理とグループ化に使用するために定義する追加の属性です。 これらの属性をアップロードすると、アナリストはクエリの作成時にそれらを使用できます。 カスタム属性をアップロードする方法については、「 組織データのアップロード (最初のアップロード)」を参照してください。
注:
- システムで許可される属性の合計数は 105 で、これには 5 つの必須属性が含まれます。
- すべての日付は、MM/DD/YYYY の形式にする必要があります。
- すべての数値フィールド (必須属性 "HourlyRate" など) は"数値" 形式である必要があり、コンマやドル記号を含めることはできません。
詳細については、「属性の説明とデータ カバレッジの要件」を参照してください。
.csv エクスポート ファイルの例
有効な.csvエクスポート ファイルのスニペットの例を次に示します。
PersonId,EffectiveDate,HireDate,ManagerId,LevelDesignation,Organization,Layer,Area Emp1@contoso.com,12/1/2020,1/3/2014,JuniorMgr1@contoso.com IC,Sales,8,Southeast Emp2@contoso.com,11//1/2020,1/3/2014,Mgr1@contoso.comジュニア IC,Sales,8,Southeast Emp3@contoso.com,12/1/2020,1/3,2014,Manager,Mgr2@contoso.com,Sales,7,Northeast Emp4@contoso.com,10/1/2020,8/15/2015,Mgr3@contoso.com,Support,Sales,9,Midwest Emp5@contoso.com,11/1/2020,8//2015 年 15 月、Mgr3@contoso.comサポート、販売、9、中西部 Emp6@contoso.com、2020 年 1 月 1 日、8 月 15 日、Mgr3@contoso.comサポート、Sales、9、Midwest
属性の詳細については、「属性リファレンス」セクションを 参照 してください。
組織のデータ ファイルをアップロードする
ソース .csv ファイルを作成した後、[ 組織データ] ページ > の [データ ハブ ] または [ データ接続 ] タブを使用して、高度な分析情報アプリにアップロードできます。
組織データを初めてアップロードする場合は、「組織データの アップロード (最初のアップロード)」を参照してください。 初めてではない場合は、「 組織データのアップロード (後続のアップロード)」を参照してください。
データが正常にアップロードされると、アプリは追加の検証と処理を実行してプロビジョニングを完了します。
組織のデータ.csvファイルをアップロードする頻度
少なくとも月に 1 回は従業員データをアップロードして、データを最新の状態に保ち、分析に関連するようにすることをお勧めします。 従業員データのアップロードが成功するとすぐに、更新されたデータをユーザーがアプリで分析情報として表示できるようになります。
特定の期間にわたるデータを提供します。
既定では、Viva Insightsには、測定された従業員の会議データとメール データが 1 年間含まれます。 組織データは、アップロード ファイル内の各行に関連付けられた有効な日付をViva Insightsするために提供されます。
現在の日付の時点で人事情報システムから組織データのポイントインタイム エクスポートを行うと、その単一時点の従業員の人口の画像が表示されます。 プロビジョニング中のデータの再現性を最大限に高めるには、過去 13 か月間の組織データ エクスポートを指定する必要があります。 このデータは、1 つのファイルまたは一連のファイルで指定できます。
実際の動作を次に示します。 測定された従業員ごとに、13 行の個別の行が作成されます。 これらの各行には、データがプルされた各月の有効日が含まれます。 各月の有効日が不可能な場合は、1 つの時点を指定できます。 その場合は、有効日を現在の月の最初の日 (1 年前) に設定します。 たとえば、プロビジョニングが 2020 年 10 月に発生した場合、すべての行の有効日を 2019 年 10 月 1 日に設定する必要があります。
従業員コラボレーション アクティビティは、コラボレーション アクティビティの日付より前の最新の組織データ スナップショット ( EffectiveDate に基づく) にマップされます。
属性参照
このセクションには、高度な分析情報アプリにアップロードされた組織データ ファイルで使用する属性に関する情報が含まれています。
属性 (列ヘッダー) | 説明 | データ型 | 値の例 | 必須または予約済み |
---|---|---|---|---|
Personid | 従業員レコードの一意識別子。 従業員のプライマリ SMTP アドレスまたはメール エイリアスを指定できます。 | メール | joe@contoso.com |
必須1 |
Managerid | 従業員のマネージャーの一意の識別子。 マネージャーのプライマリ SMTP アドレスまたは電子メール エイリアスを指定できます。 | メール | sally@contoso.com |
必須 |
組織 | 従業員が属する内部組織。 より実用的な分析情報を得る場合は、一意の組織が少なすぎるか、または多すぎるを使用しないようにします。 | 文字列 | Financial Planning and Analysis |
必須 |
EffectiveDate | 特定の属性値が従業員に適用される日付。 この属性は、異なる EffectiveDate を持つ同じ属性の別のレコードが指定されるまで適用されます。 EffectiveDate がアップロードされていない場合は、アップロード日が既定で使用されます。 | DateTime | 12/31/2021 |
必須2 |
LevelDesignation | 組織内の従業員の経験、管理レベル、または年功序列を表すレベル。 より実用的な分析情報を得る場合は、一意の LevelDesignation 値の使用が少なすぎるか、または多すぎるのを避けてください。 | 文字列 | Director |
予約済み 3 |
FunctionType | 従業員が実行するジョブ関数。 より実用的な分析情報を得る場合は、一意の FunctionType の使用が少なすぎるか、または多すぎるのを避けてください | 文字列 | Finance Management |
Reserved |
HireDate | 従業員が雇用を開始した日付。 従業員が複数の雇用日を持っている場合は、最新の雇用日を使用することをお勧めします。 | DateTime | 12/31/2021 |
Reserved |
HourlyRate | 従業員の給与は、時給 (米ドル) として表されます。 | 倍精度浮動小数点数 | 25.25 |
Reserved |
Layer | 組織の最上位リーダーからの距離として表される、組織階層内の従業員の位置。 たとえば、CEO はレイヤー 0 にあります。 より実用的な分析情報を得る場合は、一意のレイヤーの使用が少なすぎるか、または多すぎるのを避けてください。 | 整数 | 2 |
Reserved |
SupervisorIndicator | IC (個人共同作成者)、Mngr (マネージャー)、または Mngr+ (マネージャーのマネージャー) としての従業員のマネージャーの状態。 | 文字列 | IC |
Reserved |
OnsiteDays | 従業員が会社の主要な作業現場から働いている週の平均日数。 オンサイト日は、バッジ データやその他のソース (たとえば、従業員がオンサイトで働く予定の日数を示す人事システムのタグ) に基づいて作成できます。 | 文字列 | 4 |
Reserved |
Location | 従業員のオフィスの場所。 | 文字列 | Burbank |
Reserved |
My_Custom_attribute (例: Parking_space) |
作成する属性 | 文字列 | 15D |
N/A (カスタム)4 |
1. 必須フィールドを含める必要があります。 各必須フィールドには、各行に空白以外の値が必要です。
2. アップロードに EffectiveDate 列を含めない場合、アップロード日は既定の EffectiveDate になります。
3. これらの予約フィールドを含める必要はありません。 ただし、使用する場合は、これらの列名を保持します。 予約フィールドの値を指定すると、以前にアップロードした値が置き換えられます。
4. カスタム属性を含める必要はありません。 ただし、追加する場合は、必要な属性または予約済み属性と同じ名前を付けることはできません。
属性のメモと推奨事項
一部の属性は、母集団のサブセットにのみ存在します
含める属性を選択すると、ある組織に対して一部の属性値が設定される場合がありますが、他の属性値は設定されません。 たとえば、アップロードに販売組織にのみ適用される売上クォータ達成データが含まれている場合、このデータを使用して、営業外の従業員をフィルター処理およびグループ化することはできません。
多すぎる一意の値
属性の一意の値が多すぎて、グループ化やフィルター処理に使用できる場合があります。 たとえば、ジョブ関数またはコードがあまりにも狭く定義されている場合は、グループ全体の役に立つビューが得られない可能性があります。 属性に数百個の一意の値があり、値ごとに母集団グループが小さい場合、属性は役に立たない可能性があります。
少なすぎる一意の値
逆に、有用なフィルター処理のために属性が広く定義されている場合があります。 たとえば、組織が完全に米国に存在し、従業員ごとの人事レコードに常に米国と等しい国コードが含まれている場合、その属性は役に立ちません。
冗長な属性
一部の属性は、同じデータを表し、分析のために不要な冗長データを提供する場合があります。 たとえば、人事データには、従業員のコスト センター ID とコスト センター名の両方が含まれる場合があります。 どちらも同じ情報を少し異なる形式で表しているため、"わかりやすい" 名前の情報のみを含める必要があります。
基幹業務データ
人事データとは異なり、基幹業務データの場合、データのアップロードの一部として社内のすべてのユーザーを含める必要がない場合があります。 分析するシナリオを把握すると、決定に役立ちます。 たとえば、エンゲージメントが低い従業員と比較して、エンゲージメントが高い営業組織の従業員間でコラボレーション パターンを比較するとします。 より広範なコラボレーション パターンを特徴付けることができるように、すべての従業員の人事データが必要になりますが、スコア値を使用して特定のレポート出力をグループ化およびフィルター処理するため、Sales 組織内の従業員のエンゲージメント スコア データのみが必要です。
有効な値と形式
任意のデータ行または列に属性に無効な値がある場合、ソース ファイルが固定されるまでアップロード全体が失敗します (または、マッピングによって値が有効になる方法で属性の検証の種類が変更されます)。
フィールドの見出しのルール
すべてのフィールド ヘッダーまたは列名は、次の必要があります。
- 先頭が文字である (数字ではない)。
- 英数字 ( Date1 など、文字と数字) のみが含まれます。
- 先頭または末尾の空白文字や特殊文字 (@、#、%、 &など、英数字以外) はありません。
フィールドの値のルール
データ行のフィールド値は、次の書式設定規則に準拠している必要があります。
- 必須の EffectiveDate および HireDate フィールド値は、MM/DD/YYYY の形式である必要がある
- 必須の PersonId フィールド値と ManagerId フィールド値は、有効なメール アドレスである必要があります (例:
gc@contoso.com
) - 必須のレイヤー フィールドの値は数字のみを含める必要がある
- 必要な HourlyRate フィールドの値には数値のみを含める必要があります。これは、アプリが計算とデータ分析のために米ドル単位であると想定します
フィールドの値の文字のルール
次のフィールド ルールは、フィールド値の文字に適用されます。
- フィールドの値には、日本語の文字などの 2 バイト文字を含めることができます。
- 行のフィールド値の最大文字数は 128 KB で、約 1024 x 128 文字です。
- フィールド値では、"新しい行" (\n) 文字は使用 できません 。