所有異動對工資的影響，都在異動表里先算出來，并匯總出總數。以下是小編為大家推薦的五步解決工資問題相關文章，希望能幫到大家，更多精彩內容可瀏覽(yjbys.com/hr)。
我去年入職這家公司，今年的三月份開始負責人力資源部。著手工作遇到的第一個挑戰，就是工資出錯太多，員工意見很大。做過工資的人都知道，算工資是件很簡單又繁瑣的事，要把工作做到百分百準確，很不容易，尤其是沒有系統作為支撐人數又很多異動情況又很復雜的情況下，而如果核算工資的人本身沒有財務，人事或者行政背景，對數據也不敏感，那就更麻煩了�，F在我面臨的就是這樣的局面，負責工資的小華(他當然不叫小華)從前是做系統運維的，很勤勉也很努力，他幾乎把整個月的時間都花在了算工資上，并開發了一套他自己的工資報表，他認為這套報表能夠準確的核算出工資，但結果并不理想，這也讓他很郁悶。
因為不知道是哪些問題導致了這一結果，在跟進解決工資問題上，我采用的步驟是這樣的：
首先，熟悉原有的工資報表，了解它的結構以及勾稽關系。
通過對過去幾個月的工資報表進行分析，我大概知道了小華的核算思路。我總結他的思路是這樣：每個月由他來統計所有的異動數據，每個異動數據單獨編在工資表的附件(工資備忘錄)里，做工資的時候去查這個附件，根據附件的數據直接把核算值落到工資表中。這個思路有兩個問題，其一：第一手的異動數據并不完全在他手里，由他來統計經常出現漏統情況，其二，統計出來的異動數據折合出的工資數在遷入工資表時，無法做驗證;其三、當月的異動數據次月哪些需要刪除哪些需要保留，沒有做清晰的記錄。
其次，審核過去幾個月的工資表，加上員工的反饋，就出現的錯誤數據和當事人探討，詢問原因。
這樣做是非常有必要的，在長達兩個月的時間里，我和小華一起分析了數十個做錯的數據，最后我們得出兩個結論：其一，對于已統計出的各種異動，工資采用何種算法，他沒有清晰的認識，比如說，一個當月轉正的人績效工資應該怎么算，基本工資應該怎么算，他了解的并不透徹，當然這并非是他一個人的原因，公司一直沒有這方面的規定，所以只能憑著感覺算。其二，他本身薪酬方面的知識不夠，對數據的含義沒有深刻的認識，換言之，他對工資不敏感，看不到數據背后的薪酬含義(對于這一點，舉個簡單的例子，一個對工資數據敏感的人，看到基本工資里出現了781或者629這樣的數據，他就應該立刻想到，這里一定發生了某種異動，因為1或者9這種值，是較少會出現在標準工資的尾端的，對于這一點，各位也可以回查自己的工資看下。這是一個有趣的現象，其產生有另外的原因，它跟薪酬體系的設計有關，將來有機會再分享我的心得。)
得出這兩個結論的過程對我和他都是一個磨練意志的過程，因為問題太多了而且基本都集中在他身上，又沒有其他的書面資料可以參考(所有的算法都在他腦子里)，這使得每一次問題的研究都變成了質證甚至審判，我不停的問，為什么會錯?為什么要這么算?同樣的異動情況上次你用的算法是a這次為什么用了b?你的依據是什么?沒有依據你為什么要這么做?你是上帝嗎?你憑什么決定別人的工資是m不是n?有一度我幾乎摧毀了他的自信和尊嚴，我也因為看到一個蓬勃積極的人變得萎靡不振而懷疑自己是不是做錯，尤其我還是空降的管理人員，對情況也還不了解。我為此向導師征求意見，導師告訴我，解決問題的先決條件是找到問題產生的根源，當根源在人的身上時，這會變成一個很復雜的過程，但是，要達成一致意見才能行動，在向一致意見靠攏的過程中，則要始終秉著一顆良善的心，并抱定解決問題而不是發現問題的初衷。這一建議，我如實寫在這里，也分享給那些正在經歷著我或小華角色的人。
這兩個步驟做完以后，對工資問題的分析基本已經做完了。
接下來我開始設計報表。
我的設計邏輯是：先用一張異動表，把當月所有的異動情況全部統計入內，并在異動表內核算出對應的工資額，做工資的時候，只需要把異動表內各張sheet的異動額逐一遷入工資表內，并在每個遷入值處做好備注，說明異動原因，就可以了。只要當月的異動情況我統計全了，核算也正確，遷入過程無誤，就可以確保工資表是準確的。每月的異動雖然情況多，但分攤到二十多張表里的時候，數量就小了，這個時候只要我把算法控制好，出錯的幾率就很小，而為了監控遷入過程，確保遷入數據和異動數據一致，我單獨做了一個驗證算法模型，規范我認為可能出錯的每一個遷入動作。
我先做了一個異動統計表，專門用來統計各種各樣的異動數據，每種異動一張sheet，整個異動表有22張sheet，統計了目前既存的22種異動類型(比如入職，離職，轉正，調崗，調薪，五險，兩金，個稅，工會費等)，我規定以后出現新增的異動類型，就在后邊繼續增開sheet。
在設定每張sheet的字段時，只取和工資核算有關的數據，其他的一概不取，比如入職，有部門，時間，姓名，入職日期，試用期工資就可以了，其他的不用。因為整張表唯一的用途就是核算工資，和這一用途無關的其他信息都不需要錄入。整個異動表按月排列，最近一個月的異動表的有之前所有月份的異動數據，以便于查找。當月存在該遷入的數據事后發現未遷入的，就用紅色字體標注在當月最末下月起始點處，便于下月發現。
所有異動對工資的影響，都在異動表里先算出來，并匯總出總數。我把各項異動類型對應的算法設計出來，并固定好，薪酬專員只需要輸入具體的值(比如在職工作日，工資標準數)，就可以自動算出結果。
在異動表數據的統計上，也不再是做薪酬的人全部統計，而由異動數據產生的第一責任人負責統計(舉個例子說就是入離職的數據由辦理入職的人提供，轉正的數據由負責轉正工作的人提供)，在月底統一匯總給薪酬專員，這樣的分工我認為更合理，它能使數據準確度提高。實際情況也確實如此。
然后我改進工資表。
因為幾個下屬控股的子公司和總公司人員是交叉在一起的，工資數據也要由部門統一做，從前的做法是每個公司工資表都單獨做，完了以后再匯總成總表，總表和各公司分表都需要審核，且保持一致，并送不同部門，之前經常出現工資總表和各子公司分表數據不一致的情況。現在我將這一邏輯改正過來，變成先做總表，再做分表，我規定只有總表和異動表數據做了完全遷入且驗證無誤以后，才能拆表形成分表，如果總表數據出現紕漏，必須重新拆表，不能在已拆的分表里邊改。為使拆分過程快速，我在總表增設了一個公司字段，用于篩選拆表。
此外，為了確保上月的異動數據在下月能被有效的處理(清除或者保留)，我規定工資表內所有遷入的異動值都必須要有備注，寫清楚產生原因以及標準值應該是多少，下月做工資的時候，先清理上月工資表所有備注，把備注清理完(驗證模型也會監控清理過程，確保清理無誤)，才能遷入新數據。
把這兩張表做出來以后，我試算了兩個月，并不斷改進。通過嚴謹的數據比對和返查，工資數據質量明顯提高了，出錯率大幅降低。第二季度的滿意度調查，從前對工資核算的抱怨沒有再出現。
這個時候，我開始考慮下一個問題：找誰來接手，以及如何保證工資的質量不會因為我轉交出去了而降低?
從性質上來說，改進工資表和設計異動表，都是技術領域的活兒，現在要考慮的是管理領域的工作，即：如何選擇以及培養工資表的接班人。這一步如果行的不好，工資就會變成一個交不出去的工作。