現在AI正在蓬勃發展,「數據分析」也越來越受到各個領域的重視,在近年來的人力資源領域也一樣,甚至在外商或是較大型的公司,「People Analyst」這樣子以數據分析為主要角度切入人力資源領域的職位,也正在逐漸受到重視。
但我缺發現一件事情,業界、學界也好,都會非常強調「怎麼分析數據」,但好像很少聽到有人會對於「怎麼建制數據」做論述。
在之前協助建制公司的招募系統的時候,我就遇到這個困擾——PM、工程師不懂人資,人資不懂資料庫和程式邏輯,導致做出來的系統要處理數據分析時,卻很難被有效運用——資料建制不全或重複、資料難以清洗...…。
想把這段經歷當中我得到的解答,分享給大家。
在做數據分析時,往往最花時間的並不是製作圖表、尋找Insight,而是「蒐集與清洗資料」。儀表板類型的任務還好,進行完第一次之後就是隨時迭代優化,但專案性質的數據分析任務……按照我的經驗,在清洗、蒐集資料,往往需要花到整體60%~80%的時間。
細究原因,好像可以歸咎到一句「資料建制的不夠好」。但為什麼不夠好?要建置哪些資料、這些資料長什麼樣子、資料之間彼此之間的關聯,每一件事情好像都需要重新處理。
當資料可以用正確、有邏輯的方法做建制,那這些時間勢必可以被大量減少。
這兩個是我在規劃招募系統時接觸到的名詞。我沒有打算詳細的解釋這兩者的意含與用法(就不獻醜了,請大家放心)。
這兩個有幾個共同點,其中最重要的是「都需要辨識出資料中的主要元素,以及他們之間的邏輯關係」。這也是這篇文章最主要想要聊的東西。
在招募系統中,一個求職者就應該是一筆資料。在這筆資料當中可能有各式各樣的,跟這位求職者「本身」相關的資訊:
以上是我列出來可能會需要建制的資料,當然實際需要的資料會依據公司本身招募需求而定。
對於職位而言,我都會建議用「一個蘿菠一個坑」的概念來設計系統。這樣子在後續進行資料分析與利用時,才可以完整進行。例如,現在某個部門有「兩個工作內容完全相似」的職位,但是對系統而言是兩個獨立的職位——只是內容一樣。
原則上在職位中的資料內容,會與「工作說明書」上的內容基本相同。只是需要注意的是,我們會需要盡量針對這些內容做「資料結構化」——比方說「部門」,應該就不會同時在資料庫中紀錄「設計部」和「設計部門」,而會是單一的資料。
順帶一題,職位職稱、Job Descriptiion大多數時候不會拿來作為分析使用,比較像是「紀錄」或是「參考」性質的資料。
流程就是指「在招募流程中會發生的事情」,最重要的大概有這幾項:
當然在「流程」這個要素當中,可能會產生出大量的衍生資料,面試可能會有面試紀錄、流程可能會需要紀錄面試的邀約狀態、不同種類的面試會有不同樣貌的面試結果……。但這些都會作為「流程」這個要素的附屬資料而有所關聯。
在招募系統當中,「流程」是連接求職者與職位的核心:
「每一個流程,都表示一個求職者對於一個職位的申請歷程,以及在這個歷程中發生的事件。」
也可以說,「招募」這件事情就是利用「流程」,將「求職者」與「職位」連結起來。因此,當以系統的概念去看待招募時,「一位求職者」在「一個職位」當中,可能會進行「多個流程」。
我在示意圖當中,在「求職者」與「職位」當中畫了一條顏色比較淡的線,這條線表示我建議每位求職者都應該會有「一個或以上」的職位——在正常的招募流程當中,應該要因事設人,幫求職者設定(或是依據他投遞的)目標職位來進行招募流程,在流程當中更改都沒有關係——但不是沒有對應到任何職位就進行招募流程。
數據分析是一門用來提供Insight、解決問題的困難技術,但往往會有一件困難的事情:我們還不知道要解決什麼問題,就得先建置數據。否則,當真的要解決問題時再來建置數據往往為時已晚。
要如何建置出遇到問題能派的上用場的數據——解法就是,盡可能的建置完整、符合邏輯的數據與系統架構。並且當架構符合邏輯時,哪怕要做系統的修改、增減,會變得容易許多(這件事情我深有體會……),也才能夠讓數據發揮它們的最大價值。
如果你認同我的內容有所幫助,
歡迎在「方格子」或是「Linkedin」給我一個愛心or讚!
如果你認為我的內容可以幫助到更多人,
歡迎在各種管道進行分享!
如果你想要給我回饋或是有任何想法,
歡迎在「方格子」或是「Linkedin」留言告訴我!