我造了一座湖，
而那裡的湖面，總是澄清。
約莫兩個多月以前，
我來到一個陌生的聚落，
接下一項尋找水源的重大任務。
這個聚落裡，
散落著許多不同的地塊。
每一塊土地，
都有不同的海拔、地質與歷史。
有些地塊蘊藏豐富的水源，
有些地塊容易開挖，
有些地塊甚至已經留下了取水的痕跡。
但卻沒有任何一塊土地，
能夠同時滿足所有條件，
穩定提供安全、乾淨且值得信任的飲用水源。
我手拿著名為 Gemini 的十字鎬，
開始開挖一座名為「招募數據庫」的 SQL Server 地塊。
這時，
人資長開來一台名為 Claude Code 的挖土機（型號：Max 20）。
他率性地把我的十字鎬丟到一旁，
說：「開挖吧！公司給你資源！」
於是，我開始了挖掘的動作。
一個月後，
湖水從地層自然湧出。
只是，水質並不如預期。
我嘗試使用 DBeaver、MSSQL，
一層一層拆解土壤成分與地層結構；
也開始和當地人訪談，
理解這片土地過去發生了什麼。
資料清洗了一次、兩次、三次……
直到超過 12 次。
始終沒有辦法取得真正乾淨的水源。
第二個月，
挖土機轉向隔壁村。
那裡有一塊距離不遠的「人事績效資料庫」SQL Server 地塊。
嘗試從不同維度，
掘取乾淨、穩定，
同時保有資訊價值的水源。
這時，人資長又率性地說：
「你怎麼不造個 MCP Server 來濾水呢？」
我突然明白。
問題或許從來不只是：
「水乾不乾淨？」
而是：
我們有沒有一套方法，
讓每一個人，都能在自己的權限範圍內，取得他真正需要的水？
於是，第三個月開始。
我在兩座地塊的中央，
建立了一座集水站。
透過 Google OAuth 的角色分權，
讓五個不同角色的夥伴，
依照各自的權限，
取得不同層級的資料。
MCP Server 的濾芯橋接，
讓每一次「取水」，
都有規範、有邊界，也有紀錄。
最後，以 Claude Code CLI 作為水龍頭。讓夥伴不需要學會 SQL，也不需要知道資料藏在哪一張 Table。
只需要用人類的語言，
說出他真正想知道的問題。
湖的另一端，
每天早上 09:00，
Windows 工作排程器會自動啟動。
將最新且經過去識別化處理的資料，
以 Apache Parquet 格式抽取進湖中。
最後，透過 DuckDB 進行資料查詢，結合 LLM 的分析，讓資料從湖中流向不同的應用場景。
同時，自動產出：
・人資長每日戰情室
・資料湖健康度報告
・數據取用稽核報告
在湖的更遠處，
我也開始看見下一階段的輪廓。
從 Data Lake，
流向 Data Warehouse。
再從 Data Warehouse，
沉澱成不同用途的 Data Mart。
讓同一片湖水，
經過不同的沉澱、整理與分流，
最終流向不同的決策場景。
就這樣。
HR Data Lake，
一座人資動態資料查詢系統，
正式出現了。
現在，你可以問它：
「這個月離職率為什麼上升？」
「哪一個事業群的人才流失風險最高？」
「幫我整理今年的績效評核結果。」
「如果以 Dave Ulrich 的 HR Value Proposition 來看，
我們現在的人才策略缺少了什麼？」
甚至可以問：
「如果我是這個事業群的主管，
我現在最應該做的人才決策是什麼？」
它不會越過資料邊界，
也不會忽略角色權限。
它只是把原本散落在不同系統、
不同資料庫、不同報表裡的資料，
重新整理成一個人可以理解，
也可以進一步思考的答案。
這大概就是我理解的：
AI × HR × Data
AI 不只是幫 HR 寫一封信。
也不只是幫 HR 做一份簡報。
而是讓 HR 開始有能力，
從「描述發生了什麼」，
走向「理解為什麼發生」，
最後進入：「我們接下來應該做什麼？」
造湖的過程中，
我想起人資長曾經告訴我的一段話：
「資料被一次利用，能產出資訊；
當資訊被分析後，能產出知識；
而大量的知識，才能匯聚成智慧與決策思維。」
我造了一座 HR 資料湖。
在不遠處，
依稀望見它將成為：
「人才投資決策支援系統。」
在湖面之上，
是我們看得見的數據。
湖水之下，
是長年累積的組織記憶。
而湖水流過不同的河道，
經過不同的沉澱與整理，
最終抵達的，
是每一個需要做出決策的人。
真正重要的，
從來不是湖有多大。
而是當我們需要做出重要決策時，
能不能從這座湖裡，
取出一杯真正乾淨的水。
而那裡的湖面，總是澄清。
湖畔的空氣，也總是充滿寧靜。