離職分析 ：最後工作日 VS 離職生效日 | 人資 KPI 專欄
離職分析 ：最後工作日 VS 離職生效日 | 人資 KPI 專欄 一文，由 MAYO Human Capital 創辦人 James 分享他多年管理所見，和你一起探究人資的未來。
離職分析 ：常見計算錯誤
如果有一位同仁，他工作到 5 月 31 日並且於當天辦理離職，而且公司的薪資應該要支付到 5 月 31 日，那麼在離職分析中，他的離職應該算是 5 月還是 6 月呢？
一般來說，大部分台灣設計的系統概念上都有個邏輯的錯誤，所有的異動紀錄都是用「生效日」，包含部門異動與晉升等，但唯獨離職這個異動紀錄是用「最後工作日」，可能是為了薪資結算的方便，所以才會很直覺的採用這樣的做法，並且系統會把這個日期存在一個稱為「離職日」的欄位。
導致採用這些系統的企業在進行離職分析時都是用這個日期來計算，就會把 5 月 31 日當天還在工作的人員算在 5 月 31 日離職，讓整個離職分析造成很大的錯誤。為什麼說這樣是錯誤的呢？我們用人員流動圖來做為解釋，不管任何情況，下列的計算式一定必須是恆成立的：
本月底人數 = 上月底人數 + 新進人數 + 轉進人數 – 轉出人數 – 離職人數
如果我們把 5 月 31 日最後工作日的人算成 5 月離職的人數，但是他也存在 5 月 31 日在職名單中，也就是本月底人數，那麼這個恆等式就不會成立，這也是在企業分析離職上最容易出現的錯誤。
人資系統沒有注意到的問題
之前有幾次的將台灣系統轉換為 Peoplesoft 以及 SAP HCM 系統的經驗，導入初期都會需要花一些功夫和系統使用單位溝通，因為他們習慣紀錄的是最後工作日，但是在新的系統都要做調整。
最後工作日 VS 離職生效日
如果是一直用台灣人資系統的企業，好像還沒有倖免的，都是會有計算錯誤的狀況發生，我都會要求進行調整，但是相對都會有很大的 effort ，因為過去幾年的月報與資料都需要隨之變更，否則將會讓 history comparison 出現落差。
HR 要更精準地來看待自己掌管的資料，以及跟同仁溝通的文字。如果立場不夠明確而沒有辦法說清楚講明白，甚至在邏輯上有存在謬誤的話，那麼很容易在溝通的時候產生誤會，並且逐漸失去自己的 credit。
Peoplesoft、SAP 也沒有倖免於難
曾經看過一家公司是用 SAP HCM 的系統，但是卻在離職分析時，在系統建立 hard code 去把離職生效日減一天計算，並且又花 effort 去把上個月底的在職名單剃除這些在最後工作日在月底最後一天的人。
聽說是因為之前曾經在報資料 review 離職的時候被主管 challenge：『 這兩個同仁是去年底離職 (實際上是最後工作日 12 月 3 1日)，怎麼可以算到今年來呢？你們 HR 的資料有問題。』
所以就花了很多 effort 做了這樣的調整。後來有一次在 Review Head Count Budget 的時候，又被主管 Challenge：『這兩個是在 6 月 1 日離職，為什麼不在上個月底的在職名單呢？你們 HR 的資料有問題。』結果系統又被調整回去原來的狀況。
有了這個新觀念，趕快回去確認自己離職分析的資料邏輯是否有問題，免得讓你在關鍵時候，因為這一個環節而前功盡棄。
