通过

准备组织数据文件上传

  • 项目

高级见解应用可以通过以下两种方式之一获取组织数据：通过Microsoft Entra ID（默认设置）或通过你作为管理员上传的组织数据文件。 在本文中，我们将讨论第二个选项，即组织数据文件。 请继续阅读，了解在上传组织数据之前，作为管理员需要执行哪些操作来识别、收集和构造数据。

若要大致了解组织数据，请了解哪些数据Microsoft Entra ID自动与Viva Insights同步，并大致了解高级见解管理体验中的“组织数据”页，请参阅 Viva Insights 中的组织数据。

重要

上传包含组织数据的 .csv 文件后，将无法切换回使用 Microsoft Entra ID。 需要定期上传 .csv 文件，使组织数据保持最新状态。

准备组织数据

准备好开始使用组织数据文件时，以下部分将指导你完成数据准备过程：

  1. 确定要分析的趋势 - 确定需要了解哪些趋势以提高工作效率。 确定这些趋势后，可以更好地选择要使用的组织数据。
  2. 知道要包含哪些数据 - 需要一些数据属性，其中许多属性是可选的。 在可选属性中，选择最适合分析目的的属性。
  3. 获取组织数据的导出 - 让管理员从组织的 HR 系统导出 HR 数据。 （可选）包含业务线数据（如果分析需要）。
  4. 组织数据结构 - 若要成功验证数据，首先需要在上传的 .csv 文件中正确构造数据。
  5. 上传组织数据文件 – .csv 文件准备就绪后，将其上传到高级见解应用，在验证和处理后，该文件可供分析。

步骤 1 - 确定要分析的趋势

若要了解要提取哪些组织数据，首先需要确定想要了解的工作场所趋势。 例如，在即将发布的分析中，可能需要检查不同员工细分或不同组之间的协作。 需要首先定义这些组，可以通过各种方式执行此操作：

  • 按组织数据
  • 按组织层次结构级别
  • 按性能、参与度或其他业务线数据

下述分析示例可以使用已定义的组：

组之间的协作

常见的分析方案是查找不同员工组之间的协作模式。 例如，你可能希望了解你的产品市场营销团队与销售团队进行交谈多少。

在定义协作模式时，可以考虑用于细分总体的属性，例如：

  • 工作系列或角色属性，如职业、职能、学科和工作代码
  • 组织、业务线或成本中心，如人力资源、财务、销售和市场营销
  • 位置属性，如组织定义的城市、州、国家/地区和区域
  • 描述其工作的属性，例如远程、全职员工或供应商

大多数属性在 HR 信息系统中可用。

分层协作

通常，根据组织的层次结构来查找协作行为模式。 还可以量化经理与个人参与者之间的协作，以及组织中的高层和下级之间的协作。

以下概念有助于进行此类分析：

  • IC 或经理 - 员工是个人参与者还是经理。
  • 组织层次结构 - 例如，员工报告结构中员工上方的所有经理的姓名;每个管理器可以存储为单独的属性。
  • 层 - 例如，员工在组织层次结构中的位置，其中第 0 层 = 公司中的最高领导。
  • 范围 – 例如，分配给员工的直接下属数。
  • 级别 - 例如，高级经理、VP、董事、CVP。

大多数属性还位于 HR 信息系统中。

协作、参与和结果数据

最后，你可能想要考虑将协作行为模式与员工参与度分数或其他绩效结果数据相提并举。 此数据可能包括销售配额实现或性能分级。 这种数据通常不通过传统 HR 信息系统提供，提供在单独的 HR 数据存储库或业务线系统中。

步骤 2 - 了解要包含的数据

若要从高级见解应用获取完整功能，需要提供多个必需属性，如 属性引用中所述。 此外，你可以提供最多 100 个可选属性，以有趣的方式和自定义方式对数据进行分组和筛选。

组织数据的示例包括作业系列、作业角色、组织和业务线。 此数据在单个级别提供给高级见解应用，这意味着这些属性为数据集中的每个人提供上下文。

要包括的员工

至少包括拥有Viva Insights许可证的所有员工的组织数据。 最好在数据上传过程中包括公司中的每个人，即使你计划仅收集子组（即公司内的特定目标群体）的协作数据。

例如，如果市场营销人员经常与产品开发人员通信，但应用仅包含有关市场营销组织的人力资源数据，则无法创建报告来显示市场营销部门在产品开发方面花费的时间。

如果您无法包括您的组织中的每个人，则包含的最小值是正收集协作数据的所有人员。 此最小值使你可以分析此总体内各组之间的协作模式，但无法分析此总体之外的组之间的协作模式。

包括所有许可员工

管理员负责维护最新和完整的组织数据。 在此任务中，“完成”意味着两件事：包含合适的人员的数据，以及这些人员的正确属性。

在组织中包括所有许可员工的原因是，如果缺少其组织数据，分析师在 “分析 ”页上生成查询时无法按该数据进行筛选。 因此，数据缺失的员工将被排除在分析师执行的分析之外。

重要

确保 Microsoft 365 管理员已将许可证分配给要包含在报表中的所有员工。 即使你在组织数据文件中包含员工，他们也需要许可证才能显示在报表中。 有关许可和报表的详细信息，请参阅 当用户显示在查询结果中时。

缺少数据的通知

如果应用检测到一个或多个许可员工缺少数据，它会通过“ 数据连接 ”选项卡右上角的弹出通知来提醒管理员。

上传缺少的组织数据

若要上传此缺失数据，管理员可以执行以下步骤：

  1. 在弹出通知上，选择“ 下载 ”以下载包含缺少组织数据的许可员工姓名的 .csv 文件。
  2. 打开 .csv 文件。
  3. 追加这些员工的缺失数据。 这意味着添加属性 (列) ，以与以前的上传一致的方式描述员工。
  4. 上传文件。 有关详细信息，请参阅 上传组织数据 (后续上传) 。

除了在上传组织数据时包括所有许可员工外，我们建议你还包括未授权的员工，如 前文所述。

步骤 3 - 获取组织数据的导出

在格式化和上传组织数据之前，需要从一个或多个源获取数据。 主要来源是管理组织的 HR 信息系统的团队。 此团队需要为单个员工提供 HR 属性的数据导出。

此外，你的分析员可能需要有关业务结果的数据。 如果是这样，则需要联系有权访问包含此信息的数据存储的业务线所有者。 例如，此数据可能包括：

  • 特定工作组的性能评审数据。
  • HR 在 HR 信息系统之外捕获的员工参与度分数。
  • 提供更多性能视图的销售或其他配额达到数据。
  • 员工调查数据。

获取此数据后，需要对其进行构造，以便在将数据上传到应用后成功处理。

步骤 4 - 构建组织数据

获取导出的数据后，将其构造为正确的格式。

添加必需属性、保留的可选属性和自定义属性

可以在组织数据文件中添加三种类型的属性：必需、保留可选和自定义。

必需

在上传 .csv 中，以列标题的形式提供以下属性（完全如下所述）。

  • EffectiveDate
    • 请确保 EffectiveDate 列在所有行中都有值。 如果在上传中未提供 EffectiveDate 列，则上传数据的日期将成为默认 的 EffectiveDate。
  • PersonId
  • ManagerId
  • 组织 (区分大小写)
保留可选

以下属性是当前用于计算、筛选和分组数据的属性的保留列标题。 根据特定的 Power BI 模板，可能需要以下列表中的不同属性。

  • LevelDesignation
  • FunctionType
  • HireDate
  • 按小时收费
  • Layer
  • 主管
  • WeeklyBadgeOnsiteDays
  • Location

注意

属性可以在文件中按任意顺序排列。 但是，这些必需属性和保留属性的名称不能用作任何新自定义属性的名称。

自定义属性

自定义属性是要定义用于筛选和分组数据的任何其他属性。 上传这些属性时，分析师可以在生成查询时使用它们。 若要了解如何上传自定义属性，请参阅 上传组织数据 (首次上传) 。

注意

  • 系统中允许的最大属性总数为 105，其中包括五个必需属性。
  • (的所有数字字段（如必需属性“HourlyRate”) ）都需要采用“数字”格式，并且不能包含逗号或美元符号。

提示

有关设置文件格式的详细信息，请转到我们的 文件规则和验证错误 一文。

示例 .csv 导出文件

下面是有效 .csv 导出文件的示例片段：

PersonId,EffectiveDate,HireDate,ManagerId,LevelDesignation,Organization,Layer,Area Emp1@contoso.com,12/1/2020,1/3/2014,Mgr1@contoso.com,Junior IC,Sales,8,Southeast Emp2@contoso.com,11/1/2020,1/3/2014,Mgr1@contoso.com,Junior IC,Sales,8,Southeast Emp3@contoso.com,12/1/2020,1/3/2014,Mgr2@contoso.com,Manager,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/15/2015,Mgr3@contoso.com,Support,Sales,9,Midwest Emp6@contoso.com,12/1/2020,8/15/2015,Mgr3@contoso.com,Support,Sales,9,Midwest

有关属性的详细信息，请参阅 属性参考 部分。

步骤 5 - 上传组织数据文件

创建源 .csv 文件后，可以通过 “组织数据”页 > “”数据中心 “或” 数据连接 “选项卡将其上传到高级见解应用。

如果这是你第一次上传组织数据，请参阅 上传组织数据 (首次上传) 。 如果这不是第一次，请参阅 上传组织数据 (后续上传) 。

成功上传数据后，应用将执行更多验证和处理以完成预配。

.csv 文件上传组织数据的频率

建议每月至少上传一次员工数据，以使数据保持最新和分析相关。 员工数据上传成功后不久，更新的数据将可供用户在应用中查看为见解。

一段时期内处理的数据

默认情况下，Viva Insights包括测量员工一年的会议和电子邮件数据。 组织数据提供给Viva Insights，其生效日期与上传文件中的每一行相关联。

如果从当前日期开始从 HR 信息系统执行组织数据的时间点导出，则会获得该单一时间点员工人数的图片。 为了在预配期间获得最大的数据保真度，应提供过去 13 个月中的每一个月的组织数据导出。 此数据可以在单个文件或文件序列中提供。

下面是实际操作方式。 对于每个测量员工，你将有 13 个单独的行。 其中每一行都包含拉取数据的每个月份的生效日期。 如果无法提供每个月的生效日期，则可以提供一个单一时间点。 在这种情况下，请将生效日期设置为本月的第一天（一年前）。 例如，如果预配是在 2020 年 10 月发生的，则所有行的开始日期应设置为 2019 年 10 月 1 日。

员工协作活动根据协作活动日期之前的 EffectiveDate) 映射到最新的组织数据快照 (。

高级配置 - 配置电子邮件地址以查找相应的 EntraID 进行处理

Viva Insights使用电子邮件地址查找相应的 EntraID 进行处理。 使用此高级配置，可以选择Viva Insights应用于获取每个电子邮件地址的 EntraID 的日期。

选项 1：EffectiveDate

在以下情况下适用：数据源通过 EffectiveDate 跟踪电子邮件地址更改

EffectiveDate 是给定属性值适用于员工的日期。 属性将应用，直到指定具有不同 EffectiveDate 的同一属性的另一条记录。 如果未上传任何 EffectiveDate，则上传日期用作默认值。

方案 1

  1. 数据源通过 EffectiveDate 跟踪电子邮件地址更改。
  2. EntraID“A”的电子邮件地址已从 BoSmith@contoso.comBoJames@contoso.com 更改为 。 此更改使用 EffectiveDate 记录在 HCM 系统中。

示例：

  1. 2024/04/14：EntraID“A”的电子邮件地址已从 BoSmith@contoso.comBoJames@contoso.com 更改为 。 此更改记录在 HCM 源系统中，其中包含一个新行， BoJames@contoso.com 其中包含 EffectiveDate 04/14/2024。

  2. 这是快照 2024/04/15 从 HCM 源系统导出的：

    PersonId EffectiveDate 组织
    BoSmith@contoso.com 04/01/2024 ABC
    BoJames@contoso.com 04/14/2024 ABC

  3. 2024/04/16：在快照日期导出的文件在 Viva Insights

    • 在“高级配置”下选择“EffectiveDate”
    • 这可确保电子邮件地址更改由上传文件中提供的相应 EffectiveDate 跟踪。
      • 从 04/01/2024 到 04/14/2024， BoSmith@contoso.com 用于提取 EntraID“A”
      • 从 2024 年 4 月 14 日开始， BoJames@contoso.com 用于提取 EntraID“A”

详细了解如何使用 EffectiveDate 在一段时间内提供数据。

选项 2：选择日期

在以下情况下适用：数据源不跟踪电子邮件地址更改。 所选日期的电子邮件地址用于过去的所有日期。

  1. 如果最近从中导出了数据，请选择今天的日期。
  2. 否则，请选择较旧的日期。

方案 1

  1. 数据源不会跟踪电子邮件地址更改，你最近从中导出了数据。
  2. EntraID“A”的电子邮件地址已更改，并且你希望新电子邮件地址与整个历史数据的“A”匹配。

示例：

  1. 2024/04/14：EntraID“A”的电子邮件地址已从 BoSmith@contoso.comBoJames@contoso.com 更改为 。

  2. 2024 年 4 月 15 日从 HCM 源系统导出的快照：

    PersonId EffectiveDate 组织
    BoJames@contoso.com 04/01/2024 ABC

  3. 2024/04/16：在快照日期导出的文件在 Viva Insights 中上传。

  4. 从下拉列表中选择 04/16/2024

    • 这可确保 2024 年 4 月 16 日的电子邮件地址 (例如， BoJames@contoso.com) 用于提取所有过去日期的 EntraID“A”。

方案 2

  1. 数据源不会跟踪电子邮件地址更改，并且你最近未导出任何数据。
  2. 已更改 EntraID“A”的电子邮件地址，并且你希望旧电子邮件地址与整个历史数据的“A”匹配。

示例：

  1. 2024/04/20/20 从 HCM 源系统导出的快照：

    PersonId EffectiveDate 组织
    BoSmith@contoso.com 04/01/2024 ABC

  2. 2024/04/25：EntraID“A”的电子邮件地址已从 BoSmith@contoso.comBoJames@contoso.com 更改为 。

  3. 2024/05/10：在快照日期导出的文件在 Viva Insights 中上传。

    • 从下拉列表中选择 04/20/2024 ，而不是 04/25/2024 或 05/10/2024。
    • 这可确保 2024 年 4 月 20 日的电子邮件地址 (例如， BoSmith@constoso.com) 用于提取所有过去日期的 EntraID“A”。

场景 3

  1. 数据源不会跟踪电子邮件地址更改，并且你最近没有导出数据。
  2. 已为 EntraID“A”回收Email地址，并将其分配给 EntraID“B”。 你希望电子邮件地址与整个历史数据 (EntraID“B”) 的新人员匹配。

示例：

  1. 2024/04/20/20 从 HCM 源系统导出的快照：

    PersonId EffectiveDate 组织
    BoSmith@contoso.com 04/01/2024 ABC

  2. 2024/04/22：EntraID“A”的电子邮件地址已从 BoSmith@contoso.comBoJames@contoso.com 更改为 。

  3. 2024/04/25：删除Email地址BoSmith@contoso.com。

  4. 2024/04/29： BoSmith@contoso.com 分配给另一个 EntraID“B” (例如，电子邮件地址) 回收。

  5. 2024/05/10：在快照日期导出的文件在 Viva Insights 中上传。 它包含电子邮件地址 ，该地址 BoSmith@contoso.com属于 EntraID“B”，但以前属于 EntraID“A”

    • 从下拉列表中选择 04/29/2024 ，而不是 04/20/2020、 04/25/2024、 04/22/2024 或 05/10/2024。
    • 这可确保 2024 年 4 月 29 日的电子邮件地址 (例如， BoSmith@constoso.com) 用于提取所有过去日期的新 EntraID“B”。
      • 如果从下拉列表中选择“ 04/20/2024 ”，则 2024/04/20 的电子邮件地址 (例如， BoSmith@constoso.com) 提取所有过去日期的 EntraID“A”。 在这种情况下，电子邮件地址与整个历史数据的上一个人匹配。

属性引用

本部分包含有关在上传到高级见解应用的组织数据文件中使用的属性的信息。

注意

如果与 Microsoft 365 中的组织数据功能共享Viva Insights中的数据，则会共享下面列出的某些属性。 但是，包含 Microsoft_ 的任何属性在Viva Insights中都不可用。 详细了解 Microsoft 365 中的组织数据。

注意

“OnsiteDays”字段现在是“WeeklyBadgeOnsiteDays”。 有关详细信息，请参阅下表。

Viva Insights映射字段 说明 数据类型 示例值 必需或保留
PersonId 员工记录的唯一标识符。 它可以是员工的主要 SMTP 地址或电子邮件别名。 电子邮件 joe@contoso.com 必需1
ManagerId 员工经理的唯一标识符。 它可以是经理的主要 SMTP 地址或电子邮件别名。 对于首席执行官，这可以留空。 电子邮件 sally@contoso.com 必需
组织 员工所属的内部组织。 若要获取更多可操作的见解，请避免使用太少或过多的唯一组织。 String Financial Planning and Analysis 必需
EffectiveDate
  • 给定属性值应用于员工的日期。 属性将应用，直到指定具有不同 EffectiveDate 的同一属性的另一条记录。 如果未上传任何 EffectiveDate，则默认使用上传日期。
  • 管理员可以选择“dataType”作为“DateTime_MM/DD/YYYYY”或“DateTime_DD/MM/YYYY”。
  • 如果所选数据类型DateTime_MM/DD/YYYY，则它支持 MM/DD/YYYY、MM/DD/YYYYY，后跟更多文本，如“时间”、“MM-DD-YYYY”、“MM-DD-YYY”或 YYYY-MM-DD。
  • 如果所选数据类型为 DateTime_DD/MM/YYYY， 它支持 DD/MM/YYYYY、DD/MM/YYYYY，后跟更多文本，例如“时间”、“D/MM/YYYY”、“D/MM/YYY”、“DD-MM-YYYY”、“DD-MM-YYY”或 YYYY-DD-MM。
  • 如果所选数据类型为 DateTime_MM/DD/YYYY 或 DateTime_DD/MM/YYYY，则它支持 2012 年 3 月 14 日星期三;2012 年 3 月 14 日;2012 年 3 月 14 日;或 14-Mar-12。
    		•  日期时间 12/31/2021 必需2
    LevelDesignation 表示员工在组织内的经验、管理级别或资历的级别。 若要获取更多可操作的见解，请避免使用过多或过多的唯一 LevelDesignation 值。 String Director 保留3
    FunctionType 员工执行的工作职能。 若要获取更多可操作的见解，请避免使用太少或过多的唯一 FunctionType String Finance Management Reserved
    HireDate
  • 员工开始就业的日期。 如果员工有多个雇用日期，则最好使用最近的雇用日期。
  • 管理员可以选择“dataType”作为“DateTime_MM/DD/YYYYY”或“DateTime_DD/MM/YYYY”。
  • 如果所选数据类型DateTime_MM/DD/YYYY，则它支持 MM/DD/YYYY、MM/DD/YYYYY，后跟更多文本，如“时间”、“MM-DD-YYYY”、“MM-DD-YYY”或 YYYY-MM-DD。
  • 如果所选数据类型为 DateTime_DD/MM/YYYY， 它支持 DD/MM/YYYYY、DD/MM/YYYYY，后跟更多文本，例如“时间”、“D/MM/YYYY”、“D/MM/YYY”、“DD-MM-YYYY”、“DD-MM-YYY”或 YYYY-DD-MM。
  • 如果所选数据类型为 DateTime_MM/DD/YYYY 或 DateTime_DD/MM/YYYY，则它支持 2012 年 3 月 14 日星期三;2012 年 3 月 14 日;2012 年 3 月 14 日;或 14-Mar-12。
    		•  日期时间 12/31/2021 Reserved
    按小时收费 雇员的工资以美元为单位的小时费率表示。 双精度 25.25 Reserved
    Layer 员工在组织层次结构中的位置，表示为与组织最高领导人的距离。 例如，CEO 位于第 0 层。 若要获取更多可操作的见解，请避免使用太少或过多的唯一层。 整数 2 Reserved
    主管 员工作为 IC (个人参与者) 、Mngr (经理) 或 Mngr+ (经理) 经理的经理身份。 String IC Reserved
    WeeklyBadgeOnsiteDays 员工每周在公司main工地工作的平均天数。 必须是介于 0 和 7 之间的数字。 WeeklyBadgeOnsiteDays 可以基于锁屏提醒数据或其他来源，例如，HR 系统中的标记显示员工计划在现场工作的天数。 双精度 4 Reserved
    Location 员工的办公室位置。 String Burbank Reserved
    CountryOrRegion  员工工作的国家或地区。  String Japan Reserved
    My_Custom_attribute
    (示例： 校园)     		创建的属性 String West 不适用 (自定义) 4

    1. 需要包含必填字段。 每个必填字段需要每行的非空白值。

    2. 如果上传时未包含 EffectiveDate 列，则上传日期将成为默认 的 EffectiveDate。

    3. 您不必包括这些保留字段中的任何一个。 但是，如果使用它们，请保留这些列名称。

    4. 无需包含自定义属性。 但是，如果添加它们，则它们不能与任何必需或保留属性的名称相同。

    属性备注和建议

    某些属性仅存在于一部分总体中

    选择要包含的属性时，某些属性值可能会填充为一个组织，可能会填充其他属性值。 例如，如果上传包含仅适用于销售组织的销售配额实现数据，则不能使用此数据对销售人员以外的员工进行筛选和分组。

    唯一值太多

    有时，属性具有太多唯一值，要用于分组和筛选。 例如，如果作业函数或代码定义得过窄，则可能无法提供整体组的有用视图。 如果属性具有数百个唯一值，导致每个值具有少量总体组，则该属性可能没有用。

    唯一值过少

    相反，有时属性定义得太过宽泛，难以进行有用的筛选。 例如，如果你的组织完全驻留在 美国并且每个员工的 HR 记录包含始终等于美国的国家/地区代码，则该属性将无用。

    冗余属性

    某些属性可能表示相同的数据，并提供不必要的冗余数据进行分析。 例如，人力资源数据可同时包含成本中心 ID 和员工的成本中心名称。 由于两者以略有不同的格式表示相同的信息，因此仅包含具有更“用户友好”名称的一个。

    业务线数据

    与人力资源数据不同，对于业务线数据，可能无需将公司中的每个人作为数据上传的一部分。 了解要分析的方案将帮助你决定。 例如，假设你要比较销售组织中员工之间的协作模式，这些员工的参与率与参与度较低的员工不同。 虽然你需要所有员工的 HR 数据，以便可以描述更广泛的协作模式，但你只需要销售组织中员工的参与度分数数据，因为你使用分数值对特定的报表输出进行分组和筛选。