KPI專欄：最後工作日 VS 離職生效日

一組特種部隊要出任務，你覺得成功的關鍵是什麼？是具領導能力的隊長、訓練有素的成員還是先進精良的裝備，這些可能都很重要，但是沒有情報任務是很難成功的，如果情報是錯誤的，那麼再容易的任務都將註定失敗。

在KPI專欄中，我將會提醒你一些HR在數字中容易犯的錯誤與迷思，往往這些小地方，將鑄成未來不可收拾的大麻煩。
-------------------------------

最後工作日與離職生效日

如果有一位同仁，他工作到5月31日並且於當天辦理離職，而且公司的薪資應該要支付到5月31日，那麼在離職分析中，他的離職應該算是5月還是6月呢？在許多公司，我常常看到HR犯了這樣相同的錯誤，如果是用台灣人資系統的公司，通常會算在5月份，如果是用Peoplesoft或SAP HCM的公司，通常會算在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的資料有問題。』結果系統又被調整回去原來的狀況。

『你們HR的資料有問題！！』這句話好像常常聽到Line Manager在講，常常因為這句話，讓你有再好的提案也沒有辦法繼續說下去。所以有了這個新觀念，趕快回去確認自己離職分析的資料邏輯是否有問題，免得讓你在關鍵時候，因為這一個環節而前功盡棄。


---------
圖片來源：flickr / PEOSoldier