如果有一位同仁,他工作到5月31日並且於當天辦理離職,而且公司的薪資應該要支付到5月31日,那麼在離職分析中,他的離職應該算是5月還是6月呢?

一般來說,大部分台灣設計的系統概念上都有個邏輯的錯誤,所有的異動紀錄都是用生效日,包含部門異動與晉升等,但唯獨離職這個異動紀錄是用最後工作日,可能是為了薪資結算的方便,所以才會很直覺的採用這樣的做法。並且系統會把這個日期存在一個稱為『離職日』的欄位。導致採用這些系統的企業在進行離職分析時都是用這個日期來計算,就會把5月31日當天還在工作的人員算在5月31日離職,讓整個離職分析造成很大的錯誤。

為什麼說這樣是錯誤的呢?我們用下圖常做的人員流動圖來做為解釋,不管任何情況,下列的計算式一定必須是恆成立的:

本月底人數 = 上月底人數 + 新進人數 + 轉進人數 – 轉出人數 – 離職人數

如果我們把5月31日最後工作日的人算成5月離職的人數,但是他也存在5月31日在職名單中,也就是本月底人數,那麼這個恆等式就不會成立,這也是在企業分析離職上最容易出現的錯誤。

之前有幾次的將台灣系統轉換為Peoplesoft以及SAP HCM系統的經驗,導入初期都會需要花一些功夫和系統使用單位溝通,因為他們習慣紀錄的是最後工作日,但是在新的系統都要做調整。

如果是一直用台灣HR系統的企業,好像還沒有倖免的,都是會有計算錯誤的狀況發生,我都會要求進行調整,但是相對都會有很大的effort,因為過去幾年的月報與資料都需要隨之變更,否則將會讓history comparison出現落差。

HR要更精準地來看待自己掌管的資料以及跟同仁溝通的文字,如果立場不夠明確而沒有辦法說清楚講明白,甚至在邏輯上有存在謬誤的話,那麼很容易在溝通的時候產生誤會,並且逐漸失去自己的credit。

曾經看過一家公司是用SAP HCM的系統,但是卻在離職分析時,在系統建立hard code去把離職生效日減一天計算,並且又花effort去把上個月底的在職名單剃除這些在最後工作日在月底最後一天的人。聽說是因為之前曾經在報資料review離職的時候被主管challenge:『 這兩個同仁是去年底離職(實際上是最後工作日12月31日),怎麼可以算到今年來呢?你們HR的資料有問題。』所以就花了很多effort做了這樣的調整。後來有一次在Review Head Count Budget的時候,又被主管Challenge:『這兩個是在6月1日離職,為什麼不在上個月底的在職名單呢?你們HR的資料有問題。』結果系統又被調整回去原來的狀況。

有了這個新觀念,趕快回去確認自己離職分析的資料邏輯是否有問題,免得讓你在關鍵時候,因為這一個環節而前功盡棄。


Apollo人資系統,員工內部轉調清晰記載,並有Dashboard視覺化提供基本人資數據,滿足企業掌握組織脈絡高效管理,輔佐企業進行組織盤點,實現組織變革。


筆者

簡士評  James Chien

MAYO Human Capital  CEO

期望透過雲端的平台技術,解決華人企業的人才管理與接班計畫,

將是MAYO面對世代人力革新策略上交出的一張雲端成績單。

筆者

簡士評  James Chien

MAYO Human Capital  CEO,期望透過雲端的平台技術,解決華人企業的人才管理與接班計畫,將是MAYO面對世代人力革新策略上交出的一張雲端成績單。