Lattice 在 2024 年的《績效管理現狀》報告中指出,採用持續反饋(continuous feedback)機制的公司,員工參與度高出 31%,而績效評估的主觀性降低 45%。但問題在於,當反饋來自多個來源(自評、同儕、主管、下屬)、多種格式(評分、文字反饋、OKR 完成情況)、多個時間點(季度、半年度、年度)時,管理者很難從中提煉出清晰的洞察。結果往往是「最近效應」(recency bias)主導——管理者只記得過去一個月的表現,而忽略了整個評估週期的整體趨勢。
Adobe 在 2012 年廢除傳統的年度績效評估後,引入了一套名為「Check-in」的持續對話機制。但這並不等於放棄數據驅動——相反,他們建立了一個中央儀表板,聚合來自 1:1 會議記錄、專案反饋、技能評估、客戶滿意度等多源數據,為每位員工生成一張「績效雷達圖」。結果是經理人在進行晉升或調薪決策時,能基於更全面的視角,而不是單一的年度評分。數據顯示,這一轉變將員工對績效評估公平性的認同度從 58% 提升到 83%。
Starling Elevate 的案例更具說服力:他們用一套結合 Lattice 與 Claude 的聚合系統,將績效評估的準備時間從平均每份 4 小時縮短到 45 分鐘,同時將管理者引用具體事例支持評估結論的比例從 35% 提升到 92%。做法很簡單:定義五個核心維度(技術能力、協作精神、領導潛力、學習成長、業務影響),從多個系統自動抓取相關數據,用 AI 提取關鍵主題與趨勢,生成一張可視化的績效儀表板。這不是魔法,這是把模糊的「我覺得他表現不錯」變成具體的「他在這五個維度的得分與趨勢如下」。
為什麼這個場景值得自動化
三個核心痛點:數據碎片化(反饋分散在多個系統中,管理者需要手動收集與整理);偏見難察(最近效應、光環效應、相似性偏見潛移默化影響判斷,但當事人往往不自知);缺乏趨勢視角(單一時點的評分無法反映成長軌跡或退化信號)。
照這個配方做完,你會得到四樣東西:一份版本化、經人資確認的五維度評估框架;每位員工一張「多源反饋聚合儀表板」,包含評分趨勢、關鍵主題、具體事例;一個團隊層面的對比分析視圖;以及全程的審計軌跡。
邊界:這個流程不輸出「晉升/不晉升」或「調薪幅度」。它輸出的是「結構化的績效洞察」,結論由管理者與人資共同決定。
工具組合與前置準備
| 工具 | 在流程裡做什麼 |
|---|---|
| Lattice / 15Five | 績效管理平台:收集自評、同儕評、主管評、OKR 完成情況、1:1 會議記錄;作為主要數據源 |
| Workday | HRIS 系統:提供員工基本信息、職位歷史、薪酬數據、培訓記錄 |
| Claude | 長文本理解與主題提取:從文字反饋中提取關鍵主題、情感傾向、具體事例;生成結構化摘要 |
| Tableau / Power BI | 數據可視化:生成績效雷達圖、趨勢線、團隊對比圖 |
| Dify(可選) | 工作流編排:連接 Lattice、Workday、Claude,實現數據自動抓取與聚合 |
三者的定價與免費額度以官網為準;要自建還是用現成平台,判斷方法見自建還是採購。
資料前置:績效數據在公司裡屬於高敏感資料。動工前確認三件事:哪些資料可以自動化處理(問人資與資訊安全);要不要去識別化(在測試環境中使用假資料或聚合數據);訪問權限如何控制(只有直屬主管與人資能看到完整數據)。分級方法見企業資料安全基本盤。
材料準備:五維度評估框架草案(見下文);現有績效評估模板(如果有);兩三位員工作為測試樣本。評估框架由人資牽頭,與各部門主管共同確認——它是聚合分析的尺,尺不能在運行時才現場發明。
一、定義五維度評估框架
績效評估分為五個核心維度,每個維度有明確的定義與評分標準:
維度一:技術能力(Technical Competence)
定義:完成工作所需的專業知識、技能熟練度、問題解決能力。
評分標準:
- 5 分:專家級,能解決複雜技術問題,並指導他人
- 4 分:熟練,能獨立完成大部分任務,偶爾需要協助
- 3 分:合格,能完成常規任務,複雜任務需要指導
- 2 分:待提升,常規任務也需要協助
- 1 分:不合格,無法完成基本任務
數據源:自評、同儕評、主管評、代碼審查記錄(工程師)、專案交付質量、客戶反饋
維度二:協作精神(Collaboration)
定義:與團隊成員、跨部門夥伴合作的能力,溝通效率,衝突處理方式。
評分標準:
- 5 分:主動促進團隊協作,能有效化解衝突,提升整體效率
- 4 分:積極參與團隊合作,溝通順暢
- 3 分:能完成必要的協作,但較被動
- 2 分:協作時常有摩擦,影響團隊效率
- 1 分:難以與他人合作,經常引發衝突
數據源:同儕評、1:1 會議記錄、跨部門專案反饋、Slack 互動分析(可選)
維度三:領導潛力(Leadership Potential)
定義:無論是否有管理職稱,是否展現出影響力、決策能力、培養他人的意願。
評分標準:
- 5 分:自然領袖,能激勵他人,做出艱難決策,主動培養新人
- 4 分:展現領導特質,能在小型專案中帶領團隊
- 3 分:有領導潛力,但需要更多機會與指導
- 2 分:較少主動承擔領導責任
- 1 分:迴避領導責任,不願做決策
數據源:主管評、下屬評(如有)、專案領導經驗、導師活動記錄
維度四:學習成長(Learning & Growth)
定義:主動學習新知識、新技能,並將所學應用於工作的能力。
評分標準:
- 5 分:持續學習並分享,帶動團隊整體能力提升
- 4 分:主動學習新技能,並成功應用於工作
- 3 分:按要求參加培訓,學習速度一般
- 2 分:學習動力不足,技能更新緩慢
- 1 分:抗拒改變,拒絕學習新事物
數據源:培訓記錄、證照獲取、自評、主管評、開源貢獻、技術分享次數
維度五:業務影響(Business Impact)
定義:工作成果對公司業務目標的實際貢獻,包括收入增長、成本節約、效率提升等。
評分標準:
- 5 分:顯著推動業務目標,貢獻可量化且影響重大
- 4 分:對業務有明確貢獻,能部分量化
- 3 分:完成本職工作,但對業務的直接影響有限
- 2 分:工作成果與業務目標關聯性弱
- 1 分:工作未能達成預期目標
數據源:OKR 完成情況、專案 ROI、客戶滿意度、主管評、自評
關鍵設計原則:
- 每個維度都有明確的定義與評分標準:避免主觀解讀,確保不同管理者對同一表現給出相近的評分。
- 每個維度都有多源數據支撐:不依賴單一來源,減少個人偏見的影響。
- 評分與文字反饋並重:數字便於比較,文字提供上下文。兩者缺一不可。
- 版本化:評估框架給編號與生效日期,修改需要人資與管理層核準。之後每一份評估輸出都標注所用的框架版本。
二、多源數據自動抓取與聚合
數據源整合:
| 數據類型 | 來源系統 | 抓取方式 | 頻率 |
|---|---|---|---|
| 自評/同儕評/主管評 | Lattice / 15Five | API | 每次評估週期 |
| OKR 完成情況 | Lattice / Jira / Asana | API | 每週 |
| 1:1 會議記錄 | Lattice / Notion / Google Docs | API / Webhook | 每週 |
| 培訓記錄 | Workday / LinkedIn Learning | API | 每月 |
| 代碼審查記錄 | GitHub / GitLab | API | 每週 |
| 客戶反饋 | Salesforce / Zendesk | API | 每月 |
| Slack 互動分析 | Slack API | API | 每月(可選) |
聚合邏輯:
FOR 每位員工 DO
1. 從 Lattice 抓取最近一個評估週期的所有評分與文字反饋
2. 從 Workday 抓取培訓記錄與職位歷史
3. 從 GitHub 抓取代碼提交與審查記錄(如適用)
4. 從 Salesforce 抓取客戶反饋(如適用)
5. 將所有文字反饋合併,送入 Claude 進行主題提取
6. 計算每個維度的平均分數(自評、同儕評、主管評加權平均)
7. 生成績效儀表板
END FOR
加權平均示例:
技術能力維度:
- 自評:4 分(權重 20%)
- 同儕評平均:3.5 分(權重 30%)
- 主管評:4 分(權重 50%)
加權平均 = 4 × 0.2 + 3.5 × 0.3 + 4 × 0.5 = 3.85 分
權重由人資預先定義,通常主管評的權重最高,因為主管對員工的整體表現有更全面的視角。
三、AI 主題提取與具體事例生成
Claude 提示詞骨架:
任務:從以下文字反饋中,提取每個維度的關鍵主題、情感傾向、具體事例。
輸入:
- 維度名稱(例如:技術能力)
- 所有相關的文字反饋(自評、同儕評、主管評)
輸出:
1. 關鍵主題(3-5 個):例如「問題解決能力強」「代碼質量高」「需要加強文檔撰寫」
2. 情感傾向:正面 / 中性 / 負面
3. 具體事例(2-3 個):從反饋中提取具體的事件描述,保留原文引用
4. 改進建議(如有):從反饋中提取建設性的改進建議
紀律:
- 只使用給定反饋中的內容,不憑空編造
- 具體事例必須附原文引用,方便覆核
- 如果反饋中沒有某維度的內容,輸出「無相關反饋」
輸出示例:
維度:技術能力
關鍵主題:
1. 問題解決能力強(正面)
2. 代碼質量高(正面)
3. 需要加強文檔撰寫(建設性)
情感傾向:正面
具體事例:
1. 「在 Q3 的支付系統重構專案中,張三獨立解決了多個併發問題,
確保系統按時上線。」(主管評,2026-09-15)
2. 「代碼審查中,張三的代碼很少需要返工,註釋清晰。」(同儕評,李四,2026-08-20)
改進建議:
1. 「建議增加技術文檔的撰寫,方便團隊其他成員理解系統架構。」
(同儕評,王五,2026-09-01)
價值:管理者在寫績效評估時,不需要再翻閱大量的文字反饋,而是直接引用 AI 提取的關鍵主題與具體事例。這不僅節省時間,更重要的是確保評估結論有據可依,減少主觀判斷。
四、績效儀表板與可視化
個人績效儀表板:
每張儀表板包含以下元素:
- 績效雷達圖:五個維度的得分以雷達圖呈現,直觀顯示優勢與劣勢。
- 趨勢線:過去 4 個評估週期的每個維度得分變化,顯示成長或退化信號。
- 關鍵主題雲:從文字反饋中提取的關鍵主題,字體大小表示出現頻率。
- 具體事例列表:每個維度 2–3 個具體事例,附原文引用與來源。
- 改進建議匯總:從所有反饋中提取的建設性建議,按優先級排序。
團隊對比視圖:
管理者可以看到團隊內所有成員的績效對比:
- 團隊平均雷達圖:團隊在五個維度的平均得分,與公司基準線對比。
- 散點圖:橫軸為技術能力,縱軸為業務影響,每個點代表一位員工。幫助識別「高技術低影響」或「低技術高影響」的異常值。
- 熱力圖:團隊成員在各個維度的得分熱力圖,快速識別團隊整體的優勢與劣勢。
- 晉升候選人名單:根據五維度得分與趨勢,自動推薦潛在的晉升候選人(需人工覆核)。
Tableau 整合:將聚合後的數據匯入 Tableau,利用其強大的可視化能力生成交互式儀表板。管理者可以篩選部門、職位、評估週期,動態查看不同群體的績效分佈。
五、人工覆核與決策支持
- 誰覆核:直屬主管初步覆核,人資最終審核。
- 覆核什麼:AI 提取的主題與事例是否準確?評分是否合理?有沒有遺漏重要反饋?有沒有明顯的偏見(例如對某位員工的評價過於負面,但數據不支持)?
- 決策支持:儀表板不提供「晉升/不晉升」的建議,而是提供結構化的洞察。管理者基於這些洞察,結合業務需求、團隊結構、預算限制等因素,做出最終決策。
- 留紀錄:每位員工的最終評估結果、評估人、日期、使用的框架版本,全部保存在 Lattice 或 Workday 中。這是稽核紀錄,是日後爭議處理的唯一依據。
偏見檢測:系統自動標記以下異常情況,供人資複查:
- 某位員工的自評與主管評分差異過大(> 2 分)
- 某位員工的同儕評分高度不一致(標準差 > 1.5)
- 某位主管給出的評分分佈異常(例如全部給高分或全部給低分)
- 某一群體(性別、年齡段、種族)的平均評分顯著低於其他群體
這些不是定罪,而是信號——它們提示人資需要進一步調查,是否存在系統性偏見或評估標準不一致的問題。
六、持續改進與框架迭代
每一輪績效評估結束後做一次複盤,三個檢查:
- 評分一致性檢查:不同管理者對相似表現的評分是否一致?如果不一致,說明評分標準需要更明確,或需要進行校准訓練(calibration session)。
- 主題提取準確性:AI 提取的關鍵主題與具體事例是否準確?如果誤報率高,說明提示詞需要調整。
- 框架效度檢查:五個維度是否能全面反映員工的績效?有沒有遺漏重要維度(例如創新能力、客戶導向)?有沒有冗餘維度(兩個維度高度相關,可以合併)?
一個清醒的期待:自動化不會消除偏見,它只是讓偏見更易被發現。績效評估的核心仍然是人與人的對話,自動化確保的是「對話基於事實而非印象」。
落地檢查表(分4週)
| 週次 | 任務 | 負責人 | 驗收標準 |
|---|---|---|---|
| 第1週 | 定義五維度評估框架 | 人資 + 各部門主管 | 完成框架 v1,經各方確認,每個維度有明確定義與評分標準 |
| 第1週 | 設定數據源與整合方案 | 人資 + IT | 確認 Lattice、Workday、GitHub 等系統的 API 接入方式 |
| 第2週 | 搭建數據抓取與聚合流程 | IT + 人資 | 能自動抓取 5 位測試員工的多源數據,並正確聚合 |
| 第2週 | 測試 AI 主題提取功能 | 人資 + Claude | 從 10 份文字反饋中提取主題與事例,準確率 > 85% |
| 第3週 | 小批量試運行(10–15 位員工) | 人資團隊 | 生成績效儀表板,主管覆核,收集反饋,調整提示詞與框架 |
| 第3週 | Tableau 儀表板開發 | IT | 儀表板能正確顯示個人與團隊視圖,支持交互篩選 |
| 第4週 | 正式啟用與監控 | 人資團隊 | 開始處理真實績效評估,每日監控數據質量,每週複盤 |
| 第4週 | 首輪複盤與框架迭代 | 人資團隊 | 完成評分一致性檢查、主題提取準確性評估,修訂框架 v2 |
常見誤區
- 過度依賴評分:數字便於比較,但無法捕捉細微差別。必須結合文字反饋與具體事例。
- 忽略趨勢視角:單一時點的評分無法反映成長軌跡。必須查看多個評估週期的變化。
- 不加權平均:自評、同儕評、主管評的重要性不同,簡單平均會扭曲真實表現。必須設定合理權重。
- 不檢測偏見:如果不去主動檢查評分分佈的異常,系統性偏見會一直存在。偏見檢測是自動化流程的關鍵組成部分。
- 一次性設置,永不更新:業務模式、團隊結構、評估標準都在變化,框架也應定期更新。至少每年複盤一次。
- 忽略具體事例:沒有具體事例支持的評分等於主觀印象。AI 提取的事例必須附原文引用,方便覆核。
- 儀表板過於複雜:儀表板的目的是提供洞察,不是展示所有數據。保持簡潔,聚焦關鍵信息。
- 期待 AI 做決策:模型只提供結構化的洞察,決策責任在管理者與人資身上。
下一步
- 績效評估後的發展計畫制定:員工入職自動化檢查清單(參考其中的導師制度與發展追蹤)
- 合規性文件的自動化審查:合規性審查與政策更新追蹤
- 資料分級與安全基本盤:企業資料安全基本盤
- 招聘階段的自動化篩選:AI簡歷篩選與候選人評分系統
- 先判斷哪些環節根本不該自動化:什麼時候不該用 AI
- 想把編排流程親手搭一遍:不寫程式做出你的第一個 AI 工作流
- 會議紀要自動轉行動項:會議紀要自動轉行動項並分派