共用方式為

準備組織數據檔上傳

  • 發行項

進階深入解析應用程式可以透過下列兩種方式之一來取得組織數據：透過預設設定 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、Finance、Sales 和 Marketing
  • 位置屬性，例如城市、州、國家/地區和地區，如您的組織所定義
  • 描述其工作的屬性，例如遠端、全職員工或廠商

這些屬性大部分都可在 HR 資訊系統內使用。

階層式共同作業

在組織階層的參考中，搜尋共同作業行為的模式也很常見。 您也可以量化經理與個別參與者之間的共同作業，以及組織中較高和較低層級之間的共同作業。

下列概念對於這種分析很有説明：

  • IC 或經理 – 員工是個別參與者或經理。
  • 組織階層 – 例如，該員工報告結構中員工上方所有主管的名稱;每個管理員都可以儲存為個別的屬性。
  • Layer – 例如，員工在組織階層中的位置，其中第0層 = 公司中最高領導者。
  • Span – 例如，指派給員工的直接報告數目。
  • 層級 – 例如，資深主管、VP、主管、CVP。

這些屬性大部分也會在 HR 資訊系統中找到。

共同作業、參與和成果數據

最後，您可能想要考慮將共同作業行為模式與員工參與分數或其他效能結果數據系結在一起。 此數據可能包括銷售配額取得或效能評等。 此數據通常位於傳統 HR 資訊系統外部，不論是在個別的 HR 資料存放庫中，還是在企業營運系統中。

步驟 2 - 瞭解要包含哪些數據

若要取得進階深入解析應用程式的完整功能，您必須提供幾項必要的屬性，如屬性參考中所述。 此外，您能為群組提供最多 100 個選擇性屬性，並以有趣和自訂的方式篩選資料。

組織數據的範例包括作業系列、作業角色、組織和企業營運。 此數據會在個別層級提供給進階深入解析應用程式，這表示這些屬性會為數據集中的每個人提供內容。

要包含的員工

至少包含擁有 Viva Insights 授權之所有員工的組織數據。 即使您計劃只針對子群組收集共同作業數據，也就是公司內的特定目標母體擴展，最好將您公司中的每個人納入數據上傳。

例如，如果行銷人員經常與產品開發中的人員通訊，但應用程式只有關於營銷組織的 HR 數據，您就無法建立報告來顯示行銷在產品開發中花費的時間。

如果您無法包含組織中的每個人，則要包含的最小值是收集共同作業數據的所有人員。 此最小值可讓您分析此母體中群組之間的共同作業模式，但不能在此母體擴展以外的群組之間分析。

包括所有授權員工

系統管理員必須負責維護最新且完整的組織數據。 在這項工作中，「完成」代表兩件事：包含適當人員的數據，並包含這些人員的正確屬性。

包含組織中所有授權員工的原因是，如果遺漏其組織數據，分析師在 [ 分析 ] 頁面上建立查詢時，就無法依該數據進行篩選。 因此，數據遺失的員工會從分析師執行的分析中排除。

重要事項

請確定Microsoft 365 系統管理員已將授權指派給您想要包含在報告中的所有員工。 即使您在組織數據檔中包含員工，他們也需要授權才能顯示在報表中。 如需授權和報表的詳細資訊， 請參閱當用戶顯示在查詢結果中時。

除了在上傳組織數據時包含所有授權員工之外，我們建議您也包含未授權的員工，如 先前所述。

步驟 3 - 取得組織數據的導出

格式化並上傳組織資料之前，您必須從一或多個來源取得它。 您的主要來源是管理貴組織人力資源資訊系統的小組。 此小組需要為您提供個別員工的 HR 屬性數據匯出。

此外，您的分析師可能需要業務成果的相關數據。 若是如此，您必須連絡可存取包含此資訊之數據存放區的企業營運擁有者。 例如，此資料可能包括：

  • 特定工作組的效能檢閱數據。
  • HR 在 HR 資訊系統外部擷取的員工參與分數。
  • 銷售或其他配額取得數據，可提供更多效能檢視。
  • 員工問卷數據。

取得此數據之後，您必須將它結構化，以便在上傳至應用程式之後成功處理。

步驟 4 - 結構化組織數據

取得匯出的數據之後，請將其結構化為正確的格式。

新增必要、保留的選擇性屬性和自定義屬性

您可以在組織資料檔中新增三種屬性類型：必要、保留選擇性和自定義。

必要

在 .csv 上傳中提供下列屬性作為數據行標頭，如下所述。

  • EffectiveDate
    • 請確定 EffectiveDate 數據 行在所有數據列中都有值。 如果您在上傳時未提供 EffectiveDate 數據行，則上傳數據的日期會變成預設 的 EffectiveDate。
  • PersonId
  • ManagerId
  • 組織 (區分大小寫的)
保留選擇性

下列屬性是目前用來計算、篩選和群組數據之屬性的保留數據行標頭。 根據特定的Power BI 樣本，可能需要與下列清單不同的屬性。

  • LevelDesignation
  • FunctionType
  • HireDate
  • HourlyRate
  • Layer
  • SupervisorIndicator
  • WeeklyBadgeOnsiteDays
  • 位置

注意事項

屬性在檔案中可以是任何順序。 不過，這些必要屬性和保留屬性的名稱不能做為任何新自定義屬性的名稱。

自訂屬性

自訂屬性是您想要定義以用於篩選和分組數據的任何其他屬性。 當您上傳這些屬性時，分析師可以在建置查詢時使用這些屬性。 若要瞭解如何上傳自定義屬性，請參閱 上傳組織數據 (先上傳) 。

注意事項

  • 系統中允許的屬性總數上限為105，其中包含五個必要屬性。
  • 所有數值欄位 (例如必要的屬性 「HourlyRate」，) 必須是 「number」 格式，而且不能包含逗號或貨幣符號。

提示

如需格式化檔案的詳細資訊，請移至我們的 檔案規則和驗證錯誤 一文。

匯出檔案 .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. 您的數據源會依 EffectiveDate 追蹤電子郵件地址變更。
  2. EntraID “A” 的電子郵件地址從 BoSmith@contoso.comBoJames@contoso.com 變更為 。 這項變更會使用 EffectiveDate 記錄在 HCM 系統中。

範例：

  1. 04/14/2024：EntraID “A” 的電子郵件地址從 BoSmith@contoso.comBoJames@contoso.com 變更為 。 這項變更會記錄在 HCM 來源系統中，其中具有 EffectiveDate 04/14/2024 的新 BoJames@contoso.com 數據列。

  2. 這是 2024/04/15 從 HCM 來源系統導出的快照集：

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

  3. 04/16/2024：在快照集日期導出的檔案上傳於 Viva Insights

    • 在 [進階設定] 下選取 [EffectiveDate]

    • 這可確保上傳檔案中提供的對應 EffectiveDate 會追蹤電子郵件地址變更。

      • 從 04/01/2024 到 2024/04/14， BoSmith@contoso.com 是用來擷取 EntraID “A”
      • 從 2024/04/14 開始， BoJames@contoso.com 用來擷取 EntraID “A”

      深入瞭解如何使用 EffectiveDate 在一段時間內提供數據。

選項 2：選取日期

適用於：您的數據源不會追蹤電子郵件地址變更。 選取日期上的電子郵件地址會用於所有過去日期。

  1. 如果您最近從中匯出數據，請選取今天的日期。
  2. 否則，請選取較舊的日期。

案例 1

  1. 您的數據源不會追蹤電子郵件地址變更，而且您最近已從中匯出數據。
  2. EntraID “A” 的電子郵件地址已變更，而您希望新的電子郵件位址符合整個歷程記錄數據的 “A”。

範例：

  1. 04/14/2024：EntraID “A” 的電子郵件地址從 BoSmith@contoso.comBoJames@contoso.com 變更為 。

  2. 2024/04/15 從 HCM 來源系統導出的快照集：

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

  3. 04/16/2024：在快照日期導出的檔案會在 Viva Insights 中上傳。

  4. 從下拉式清單中選取 04/16/2024

    • 這可確保 2024/04/16 上的電子郵件地址 (例如， BoJames@contoso.com) 用來擷取所有過去日期的 EntraID “A”。

案例 2

  1. 您的數據源不會追蹤電子郵件地址變更，而且您最近未匯出任何數據。
  2. EntraID “A” 的電子郵件地址已變更，而您希望舊的電子郵件位址符合整個歷程記錄數據的 “A”。

範例：

  1. 2024/04/20 從 HCM 來源系統導出的快照集：

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

  2. 04/25/2024：EntraID “A” 的電子郵件地址從 BoSmith@contoso.comBoJames@contoso.com 變更為 。

  3. 05/10/2024：在快照集日期導出的檔案會在 Viva Insights 中上傳。

    • 從下拉式清單中選取 04/20/2024 ，而不是 04/25/2024 或 05/10/2024。
    • 這可確保 2024 年 4 月 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 位址或電子郵件別名。 對於CEO，這可以保留空白。 電子郵件 sally@contoso.com 必要
組織 員工所屬的內部組織。 如需更多可採取動作的深入解析，請避免使用太少或太多唯一的組織。 字串 Financial Planning and Analysis 必要
EffectiveDate
  • 給定屬性值適用於員工的日期。 屬性會套用到指定具有不同 EffectiveDate 之相同屬性的另一筆記錄為止。 如果未上傳 EffectiveDate，則會使用上傳日期作為預設值。
  • 管理員 可以選取 DataType 作為 DateTime_MM/DD/YYYY 或 DateTime_DD/MM/YYYY。
  • 如果選取的數據類型DateTime_MM/DD/YYYY，則支援MM/DD/YYYY、MM/DD/YYYY，後面接著更多文字，例如 “time”、“MM-DD-YYYYY、MM-DD-YYY 或 YYYY-MM-DD。
  • 如果選取的數據類型是DateTime_DD/MM/YYYY，則支援 DD/MM/YYYY、DD/MM/YYYY，後面接著更多文字，例如 “time”、“D/MM/YYYYY、D/MM/YYY、DD-MM-YYYYY、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。
    		•  DateTime 12/31/2021 必要2
    LevelDesignation 代表員工在組織內經驗、管理層級或年資的層級。 如需更多可採取動作的深入解析，請避免使用太少或太多唯一的 LevelDesignation 值。 字串 Director 保留3
    FunctionType 員工執行的作業函式。 如需更多可採取動作的深入解析，請避免使用太少或太多唯一的 FunctionTypes 字串 Finance Management 保留
    HireDate
  • 員工開始僱用的日期。 如果員工有多個僱用日期，最好使用最新的僱用日期。
  • 管理員 可以選取 DataType 作為 DateTime_MM/DD/YYYY 或 DateTime_DD/MM/YYYY。
  • 如果選取的數據類型DateTime_MM/DD/YYYY，則支援MM/DD/YYYY、MM/DD/YYYY，後面接著更多文字，例如 “time”、“MM-DD-YYYYY、MM-DD-YYY 或 YYYY-MM-DD。
  • 如果選取的數據類型是DateTime_DD/MM/YYYY，則支援 DD/MM/YYYY、DD/MM/YYYY，後面接著更多文字，例如 “time”、“D/MM/YYYYY、D/MM/YYY、DD-MM-YYYYY、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。
    		•  DateTime 12/31/2021 保留
    HourlyRate 員工的薪資以美金表示每小時費率。 雙精度浮點數 25.25 保留
    Layer 員工在組織階層中的位置，以其與組織最高領導者的距離表示。 例如，執行長位於第 0 層。 如需更多可採取動作的深入解析，請避免使用太少或太多唯一的圖層。 整數 2 保留
    SupervisorIndicator 員工的經理狀態為 IC (個別參與者) 、 Mngr (管理員) 或經理) 的 Mngr+ (管理員。 字串 IC 保留
    WeeklyBadgeOnsiteDays 員工每周從公司的主要工作站工作的平均天數。 必須是介於 0 和 7 之間的數位。 WeeklyBadgeOnsiteDays 可以根據徽章數據或其他來源，例如，HR 系統中的標籤，顯示員工計劃到現場工作的天數。 雙精度浮點數 4 保留
    位置 員工的辦公室位置。 字串 Burbank 保留
    CountryOrRegion  員工工作的國家或地區。  字串 Japan 保留
    My_Custom_attribute
    (範例： Campus)     		您建立的屬性 字串 West N/A (自定義) 4

    1.您必須包含必要的欄位。 每個必要欄位都需要每個數據列的非空白值。

    2.如果您的上傳未包含 EffectiveDate 數據行，則上傳日期會變成預設 的 EffectiveDate。

    3.您不需要包含這些保留欄位中的任何一個。 不過，如果您使用它們，請保留這些數據行名稱。

    4.您不需要包含自定義屬性。 不過，如果您新增它們，它們的名稱就不能與任何必要或保留的屬性相同。

    屬性附註和建議

    某些屬性只存在於母體的子集

    選擇要包含的屬性時，可能會為一個組織填入某些屬性值，但不會填入其他組織。 例如，如果上傳包含僅適用於銷售組織的銷售配額取得數據，您就無法使用此數據來篩選和分組銷售外部的員工。

    太多唯一值

    有時候屬性有太多唯一值，無法用於分組和篩選。 例如，如果作業函式或程式代碼定義太窄，可能無法為您提供整體群組的實用檢視。 如果屬性具有數百個唯一值，而導致每個值的母體擴展群組較小，則屬性可能沒有用處。

    唯一值太少

    相反地，有時屬性定義太過廣泛，無法進行有用的篩選。 例如，如果您的組織完全位於 美國，而每位員工的 HR 記錄包含一律等於美國的國家/地區代碼，則該屬性將不會有用。

    備援屬性

    某些屬性可能代表相同的數據，並提供不必要的備援數據進行分析。 例如，HR 數據可能同時包含成本中心標識碼和員工的成本中心名稱。 因為兩者都以稍微不同的格式表示相同的資訊，所以請只包含名稱更「方便使用」的資訊。

    企業營運資料

    不同於 HR 數據，針對企業營運數據，您可能不需要將公司中的每個人納入為數據上傳的一部分。 瞭解您想要分析的案例可協助您決定。 例如，假設您想要比較銷售組織中具有高參與度的員工與低參與度員工之間的共同作業模式。 雖然您想要為所有員工提供 HR 數據，以便描述更廣泛的共同作業模式，但您只需要銷售組織中員工的參與分數數據，因為您使用分數值來分組和篩選特定報表輸出。