共用方式為


準備組織資料檔案上傳

Viva Insights Web 應用程式可以透過下列兩種方式之一取得組織數據:透過 Microsoft Entra ID (這是預設設定),或透過您作為系統管理員上傳的組織數據檔。 在本文中,我們將討論第二個選項,即組織數據檔案。 請繼續閱讀,以瞭解身為系統管理員,在上傳組織數據之前,您需要執行哪些動作來識別、收集和結構化數據。

若要瞭解一般組織數據,請瞭解 Microsoft Entra ID 會自動與 Viva Insights 同步處理哪些數據,並取得 Viva Insights 系統管理體驗中 [組織數據] 頁面的概觀,請參閱 Viva Insights 中的組織數據

重要事項

如果您啟用「平行」資料擷取,您可以 同時使用 Entra 和資料檔案上傳。 然後,如果您決定停止對某些屬性使用 Entra,您可以恢復為僅使用手動資料檔案。 深入了解

準備組織資料

當您準備好開始使用組織資料檔案時,下列各節會引導您完成資料準備程式:

  1. 確定您要分析的趨勢 – 決定您需要了解哪些趨勢以提高工作效率。 找出這些趨勢之後,您最好選擇要使用哪些組織資料。
  2. 知道要包含哪些資料 — 一些資料屬性是必需的,許多是選用的。 在選用選項中,選擇最適合您分析目的的屬性。
  3. 取得組織資料的匯出 – 讓系統管理員從組織的 HR 系統匯出 HR 資料。 或者,如果您的分析需要,請包含企業營運資料。
  4. 建構組織資料 – 若要成功驗證您的資料,您必須先在上傳的 .csv 檔案中正確建構資料。
  5. 上傳組織資料檔案 – .csv 檔案準備就緒之後,您可以將其上傳至 Viva Insights Web 應用程式,在驗證和處理之後,即可進行分析。

要了解要提取哪些組織數據,您首先需要決定要了解的工作場所趨勢。 例如,在即將到來的分析中,您可能想要檢查不同員工區段或群組之間的共同作業。 您需要先定義這些群組,您可以透過多種方式執行此操作:

  • 依組織資料
  • 依組織階層層級
  • 依效能、參與度或其他企業營運資料

已定義的群組可用於下列分析範例:

群組之間的協作

常見的分析案例是尋找不同員工群組之間的共同作業模式。 例如,您可能想知道您的產品行銷團隊與您的銷售團隊交談了多少。

在定義共同作業模式時,區隔母體的屬性有助於考慮,例如:

  • 工作系列或角色屬性,例如職業、職能、紀律和工作代碼
  • 組織、業務線或成本中心,例如 HR、財務、銷售和行銷
  • 位置屬性,例如城市、州、國家和地區,由您的組織定義
  • 描述其工作的屬性,例如遠端、全職員工或廠商

這些屬性中的大多數都可以在人力資源信息系統中使用。

分層協作

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

下列概念對此類分析很有幫助:

  • IC 或經理 – 員工是個人貢獻者還是經理。
  • 組織階層 – 例如,該員工報告結構中員工上方所有經理的姓名;每一個管理程式都可以儲存為個別屬性。
  • — 例如,員工在組織階層中的位置,其中第 0 層 = 公司的最高領導人。
  • 跨度 – 例如,指派給員工的直接下屬數目。
  • 級別 – 例如,高級經理、副總裁、總監、CVP。

這些屬性中的大多數也存在於人力資源資訊系統中。

協作、參與和結果數據

最後,您可能想要考慮將共同作業行為模式與員工敬業度分數或其他績效結果資料連結起來。 此資料可能包括銷售配額達成或績效評等。 這些數據通常位於傳統人力資源信息系統之外,無論是在單獨的人力資源數據存儲庫中還是在業務線系統中。

步驟 2 - 知道要包含哪些資料

若要從 Viva Insights Web 應用程式取得完整功能,您必須提供數個必要的屬性,如屬性參考中所述。 此外,您能為群組提供最多 100 個選擇性屬性,並以有趣和自訂的方式篩選資料。

組織資料的範例包括工作系列、工作角色、組織和業務線。 此數據會在個別層級提供給 Viva Insights Web 應用程式,這表示這些屬性會為資料集中的每個人提供內容。

應包括的員工

至少包含具有 Viva Insights 授權之所有員工的組織數據。 最好將公司中的每個人納入資料上傳的一部分,即使您計劃只收集子群組(即公司內的特定目標母體)的協作資料。

例如,如果 Marketing 中的人員經常與產品開發中的人員溝通,但應用程式僅具有有關 Marketing 組織的 HR 資料,則您無法建立報告來顯示 Marketing 在產品開發上花費的時間。

如果您無法包含組織中的每個人,則至少要包含的是正在收集共同作業資料的所有人員。 此最小值可讓您分析此母體內群組之間的共同作業模式,但無法分析此母體外部群組之間的共同作業模式。

包括所有持牌員工

系統管理員有責任維護最新且完整的組織數據。 在此任務中,「完整」意味著兩件事:包含正確人員的資料,以及包含這些人員的正確屬性。

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

重要事項

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

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

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

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

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

  • 特定工作組的績效評估數據。
  • 人力資源部門在人力資源資訊系統之外擷取的員工敬業度分數。
  • 銷售或其他配額達成資料,可提供更多績效檢視。
  • 員工調查數據。

取得此資料之後,您必須建構資料,以便在將資料上傳至應用程式後成功處理。

步驟 4 - 建構組織資料

取得匯出的資料之後,請將其建構為正確的格式。

新增必要、保留的選用和自訂屬性

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

必要

在 .csv 上傳中提供下列屬性作為欄標題,與下面所寫的完全相同。

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

下列屬性是目前用來計算、篩選和分組資料之屬性的保留欄標題。 根據特定的 Power BI 範本,可能需要下列清單中的不同屬性。

  • 等級指定
  • FunctionType
  • 僱用日期
  • 小時費率
  • Layer
  • 主管指標
  • 每週徽章現場天數
  • 位置

注意事項

屬性在檔案中可以是任何順序。 不過,這些必要和保留屬性的名稱不能用作任何新自訂屬性的名稱。

自訂屬性

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

注意事項

  • 系統中允許的屬性總數上限為 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 檔案之後,您可以透過組織資料頁面>資料連線資料中樞頁面,將它上傳至 Viva Insights Web 應用程式。

如果這是您第一次上傳組織資料,請參閱 上傳 組織資料 (第一次上傳) 。 如果這不是第一次,請參閱上傳 組織數據 (後續上傳)

成功上傳資料後,應用程式會執行更多驗證和處理以完成佈建。

上傳組織資料 .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,則會使用上傳日期作為預設日期。

案例

  1. 您的資料來源會依 EffectiveDate 追蹤電子郵件地址變更。
  2. EntraID “A” 的電子郵件地址從 BoSmith@contoso.com 變更為 。BoJames@contoso.com 此變更會使用 EffectiveDate 記錄在 HCM 系統中。

範例:

  1. 2024 年 4 月 14 日:EntraID 「A」的電子郵件地址從 BoSmith@contoso.com 變更為 。BoJames@contoso.com 此變更會記錄在 HCM 來源系統中,並以 EffectiveDate 04/14/2024 的新 BoJames@contoso.com 列記錄。

  2. 這是2024年4月15日從HCM來源系統匯出的快照:

    PersonId EffectiveDate Organization
    BoSmith@contoso.com 04/01/2024 美國廣播公司
    BoJames@contoso.com 04/14/2024 美國廣播公司
  3. 2024 年 4 月 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 年 4 月 14 日:EntraID 「A」的電子郵件地址從 BoSmith@contoso.com 變更為 。BoJames@contoso.com

  2. 2024 年 4 月 15 日從 HCM 來源系統匯出的快照:

    PersonId EffectiveDate Organization
    BoJames@contoso.com 04/01/2024 美國廣播公司
  3. 2024 年 4 月 16 日:快照集日期匯出的檔案會在 Viva Insights 中上傳。

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

    • 這可確保 2024 年 4 月 16 日的電子郵件地址 (例如, BoJames@contoso.com) 用於擷取所有過去日期的 EntraID 「A」。

案例 2

  1. 您的資料來源不會追蹤電子郵件地址變更,而且您最近沒有匯出任何資料。
  2. EntraID “A” 的電子郵件地址已變更,而且您想要將舊電子郵件地址與整個歷程資料的 “A” 相符。

範例:

  1. 2024 年 4 月 20 日從 HCM 來源系統匯出的快照:

    PersonId EffectiveDate Organization
    BoSmith@contoso.com 04/01/2024 美國廣播公司
  2. 2024 年 4 月 25 日:EntraID 「A」的電子郵件地址從 BoSmith@contoso.com 變更為 。BoJames@contoso.com

  3. 2024 年 5 月 10 日:快照集日期匯出的檔案會上傳至 Viva Insights。

    • 從下拉式清單中選取 04/20/2024 ,而不是 04/25/202405/10/2024
    • 這可確保 2024 年 4 月 20 日的電子郵件地址 (例如, BoSmith@constoso.com) 用於擷取所有過去日期的 EntraID 「A」。

啟用部分資料擷取

若要啟用部分資料擷取,請選取 上傳有效資料列 並排除具有無效資料的資料列。 此設定只會上傳包含有效值的資料列,並針對因錯誤而未擷取的資料列顯示警告。 根據預設,此設定為關閉狀態。

在提供資料之前檢閱驗證詳細資料

根據預設,您的上傳會在完成處理後自動用於洞察。 若要防止這種情況發生,請選取 檢 閱驗證詳細資料,再提供資料。 如此一來,您就可以檢閱驗證報告,並決定是否在驗證 提供資料。 選取 [確認] 以提供資料。

屬性參考

本節包含您在上傳至 Viva Insights Web 應用程式之組織數據檔中使用的屬性相關資訊。

注意事項

如果您將 Viva Insights 中的數據與 Microsoft 365 中的組織數據功能共用,則會共用下列部分屬性。 不過,任何包含 Microsoft_ 的屬性都無法在 Viva Insights 中使用。 深入了解 Microsoft 365 中的組織數據

注意事項

「OnsiteDays」欄位現在是「WeeklyBadgeOnsiteDays」。 請參閱下表以了解更多信息。

Viva Insights 對應欄位 描述 資料類型 範例值 必要或保留
PersonId 員工記錄的唯一識別碼。 它可以是員工的主要 SMTP 位址或電子郵件別名。 電子郵件 joe@contoso.com 必填1
ManagerId 員工經理的唯一識別碼。 它可以是管理員的主要 SMTP 位址或電子郵件別名。 對於執行長來說,這可以留空。 電子郵件 sally@contoso.com 必要
組織 員工所屬的內部組織。 如需更多可操作的見解,請避免使用太少或太多的唯一組織。 字串 Financial Planning and Analysis 必要
EffectiveDate
  • 給定屬性值適用於員工的日期。 屬性會套用,直到指定具有不同 EffectiveDate 的相同屬性的另一筆記錄為止。 如果未上傳 EffectiveDate,則會使用上傳日期作為預設日期。
  • 管理員可以選取 [資料類型] 作為 DateTime_MMDDYYYY 或 DateTime_DDMMYYYY。
  • 如果選取的資料類型為DateTime_MMDDYYYY,則支援 MMDDYYYYY、MMDDYYYY,後面接著更多文字,例如 “時間”、“MMDDYYYYY、MMDDYY 或 YYYYMMDD。
  • 如果選取的資料類型為DateTime_DDMMYYYY,則支援 DDMMYYYYY、DDMMYYYYY,後面接著更多文字,例如「時間」、「DMMYYYY、DMMYY、DDMMYYYYY、DDMMYY 或 YYYYDDMM」。
  • 如果選取的資料類型為DateTime_MMDDYYYY或DateTime_DDMMYYYY,則支援 2012 年 3 月 14 日星期三;2012 年 3 月 14 日;2012 年 3 月 14 日;或 14 年 3 月 12 日。
  • DateTime 12/31/2021 必要2
    等級指定 代表員工在組織內的經驗、管理層級或資歷的層級。 如需更多可操作的深入解析,請避免使用太少或太多的唯一 LevelDesignation 值。 字串 Director 保留3
    FunctionType 員工執行的工作職能。 如需更多可操作的見解,請避免使用太少或太多的唯一 FunctionType 字串 Finance Management 保留的
    僱用日期
  • 員工開始受僱的日期。 如果員工有多個聘僱日期,最好使用最近的聘僱日期。
  • 管理員可以選取 [資料類型] 作為 DateTime_MMDDYYYY 或 DateTime_DDMMYYYY。
  • 如果選取的資料類型為DateTime_MMDDYYYY,則支援 MMDDYYYYY、MMDDYYYY,後面接著更多文字,例如 “時間”、“MMDDYYYYY、MMDDYY 或 YYYYMMDD。
  • 如果選取的資料類型為DateTime_DDMMYYYY,則支援 DDMMYYYYY、DDMMYYYYY,後面接著更多文字,例如「時間」、「DMMYYYY、DMMYY、DDMMYYYYY、DDMMYY 或 YYYYDDMM」。
  • 如果選取的資料類型為DateTime_MMDDYYYY或DateTime_DDMMYYYY,則支援 2012 年 3 月 14 日星期三;2012 年 3 月 14 日;2012 年 3 月 14 日;或 14 年 3 月 12 日。
  • DateTime 12/31/2021 保留的
    小時費率 員工的工資以美元為單位的小時費率表示。 雙精度浮點數 25.25 保留的
    Layer 員工在組織層次結構中的位置,表示為他們與組織最高領導人的距離。 例如,執行長位於第 0 層。 若要獲得更多可操作的見解,請避免使用太少或太多的唯一圖層。 整數 2 保留的
    主管指標 員工的經理狀態為 IC (個人貢獻者) 、 Mngr (經理) 或 Mngr+ (經理) 的經理。 字串 IC 保留的
    每週徽章現場天數 員工每週在公司主要工作場所工作的平均天數。 必須是介於 0 和 7 之間的數字。 如果您不追蹤員工在公司主要工作地點工作的天數,請使用「-1」。 WeeklyBadgeOnsiteDays 可以基於徽章資料或其他來源,例如,人力資源系統中的標籤顯示員工計劃在現場工作的天數。 雙精度浮點數 4 保留的
    位置 員工的辦公地點。 字串 Burbank 保留的
    CountryOrRegion  員工工作的國家或地區。  字串 Japan 保留的
    My_Custom_attribute
    (範例: 校園)
    您建立的屬性 字串 West 不適用 (自訂) 4

    1. 您需要包含必填字段。 每個必填欄位的每一列都需要非空白值。

    2. 如果您在上傳時未包含 EffectiveDate 欄,則上傳日期會變成預設的 EffectiveDate

    3. 您不必包含任何這些保留欄位。 不過,如果您確實使用它們,請保留這些資料行名稱。

    4. 您不需要包含自訂屬性。 不過,如果您確實新增它們,則它們不能與任何必要或保留的屬性具有相同的名稱。

    屬性附註和建議

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

    選擇要包含的屬性時,可能會為一個組織填入某些屬性值,但不會為其他組織填入。 例如,如果上傳包含僅適用於您的銷售組織的銷售配額達成資料,則您無法使用此資料來篩選和分組銷售以外的員工。

    太多唯一值

    有時,屬性有太多唯一值,無法用於分組和篩選。 例如,如果工作職能或程式碼定義太窄,則可能無法為您提供整體群組的有用檢視。 如果屬性有數百個唯一值,導致每個值的母體群組較小,則該屬性可能沒有用處。

    唯一值太少

    相反地,有時屬性的定義太寬泛,無法進行有用的篩選。 例如,如果您的組織完全位於美國,且每位員工的人力資源記錄包含的國家/地區代碼始終等於美國,則該屬性將沒有用處。

    備援屬性

    某些屬性可能代表相同的資料,並提供不必要的冗餘資料進行分析。 例如,人力資源資料可以同時包含員工的成本中心 ID 和成本中心名稱。 由於兩者都以略有不同的格式表示相同的信息,因此僅包含名稱更“用戶友好”的一個。

    企業營運資料

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