5个步骤，教你解决工资问题

————选自相关媒体网络的新闻报道，报道中的观点不代表劳律通顾问中心的观点

　　去年入职这家公司，今年的三月份开始负责人力资源部。着手工作遇到的第一个挑战，就是工资出错太多，员工意见很大。做过工资的人都知道，算工资是件很简单又繁琐的事，要把工作做到百分百准确，很不容易，尤其是没有系统作为支撑人数又很多异动情况又很复杂的情况下，而如果核算工资的人本身没有财务，人事或者行政背景，对数据也不敏感，那就更麻烦了。现在面临的就是这样的局面，负责工资的小华（他当然不叫小华）从前是做系统运维的，很勤勉也很努力，他几乎把整个月的时间都花在了算工资上，并开发了一套他自己的工资报表，他认为这套报表能够准确的核算出工资，但结果并不理想，这也让他很郁闷。

　　因为不知道是哪些问题导致了这一结果，在跟进解决工资问题上，采用的步骤是这样的：

　　首先，熟悉原有的工资报表，了解它的结构以及勾稽关系。

　　通过对过去几个月的工资报表进行分析，大概知道了小华的核算思路。总结他的思路是这样：每个月由他来统计所有的异动数据，每个异动数据单独编在工资表的附件（工资备忘录）里，做工资的时候去查这个附件，根据附件的数据直接把核算值落到工资表中。这个思路有两个问题，其一：第一手的异动数据并不完全在他手里，由他来统计经常出现漏统情况，其二，统计出来的异动数据折合出的工资数在迁入工资表时，无法做验证；其三、当月的异动数据次月哪些需要删除哪些需要保留，没有做清晰的记录。

　　其次，审核过去几个月的工资表，加上员工的反馈，就出现的错误数据和当事人探讨，询问原因。

　　这样做是非常有必要的，在长达两个月的时间里，我和小华一起分析了数十个做错的数据，最后得出两个结论：其一，对于已统计出的各种异动，工资采用何种算法，他没有清晰的认识，比如说，一个当月转正的人绩效工资应该怎么算，基本工资应该怎么算，他了解的并不透彻，当然这并非是他一个人的原因，公司一直没有这方面的规定，所以只能凭着感觉算。其二，他本身薪酬方面的知识不够，对数据的含义没有深刻的认识，换言之，他对工资不敏感，看不到数据背后的薪酬含义（对于这一点，举个简单的例子，一个对工资数据敏感的人，看到基本工资里出现了781或者629这样的数据，他就应该立刻想到，这里一定发生了某种异动，因为1或者9这种值，是较少会出现在标准工资的尾端的，对于这一点，各位也可以回查自己的工资看下。这是一个有趣的现象，其产生有另外的原因，它跟薪酬体系的设计有关，将来有机会再分享一下心得。）

　　得出这两个结论的过程对我们都是一个磨练意志的过程，因为问题太多了而且基本都集中在他身上，又没有其他的书面资料可以参考（所有的算法都在他脑子里），这使得每一次问题的研究都变成了质证甚至审判，我不停的问，为什么会错？为什么要这么算？同样的异动情况上次你用的算法是a这次为什么用了b？你的依据是什么？没有依据你为什么要这么做？你是上帝吗？你凭什么决定别人的工资是m不是n？有一度我几乎摧毁了他的自信和尊严，也因为看到一个蓬勃积极的人变得萎靡不振而怀疑自己是不是做错，尤其我还是空降的管理人员，对情况也还不了解。为此向导师征求意见，导师说，解决问题的先决条件是找到问题产生的根源，当根源在人的身上时，这会变成一个很复杂的过程，但是，要达成一致意见才能行动，在向一致意见靠拢的过程中，则要始终秉着一颗良善的心，并抱定解决问题而不是发现问题的初衷。这一建议，我如实写在这里，也分享给那些正在经历着我或小华角色的人。

　　这两个步骤做完以后，对工资问题的分析基本已经做完了。

　　接下来开始设计报表。

　　设计逻辑是：先用一张异动表，把当月所有的异动情况全部统计入内，并在异动表内核算出对应的工资额，做工资的时候，只需要把异动表内各张sheet的异动额逐一迁入工资表内，并在每个迁入值处做好备注，说明异动原因，就可以了。只要当月的异动情况统计全了，核算也正确，迁入过程无误，就可以确保工资表是准确的。每月的异动虽然情况多，但分摊到二十多张表里的时候，数量就小了，这个时候只要把算法控制好，出错的几率就很小，而为了监控迁入过程，确保迁入数据和异动数据一致，还单独做了一个验证算法模型，规范认为可能出错的每一个迁入动作。

　　先做了一个异动统计表，专门用来统计各种各样的异动数据，每种异动一张sheet，整个异动表有22张sheet，统计了目前既存的22种异动类型（比如入职，离职，转正，调岗，调薪，五险，两金，个税，工会费等），规定以后出现新增的异动类型，就在后边继续增开sheet。

　　在设定每张sheet的字段时，只取和工资核算有关的数据，其他的一概不取，比如入职，有部门，时间，姓名，入职日期，试用期工资就可以了，其他的不用。因为整张表唯一的用途就是核算工资，和这一用途无关的其他信息都不需要录入。整个异动表按月排列，最近一个月的异动表的有之前所有月份的异动数据，以便于查找。当月存在该迁入的数据事后发现未迁入的，就用红色字体标注在当月最末下月起始点处，便于下月发现。

　　所有异动对工资的影响，都在异动表里先算出来，并汇总出总数。把各项异动类型对应的算法设计出来，并固定好，薪酬专员只需要输入具体的值（比如在职工作日，工资标准数），就可以自动算出结果。

　　在异动表数据的统计上，也不再是做薪酬的人全部统计，而由异动数据产生的第一责任人负责统计（举个例子说就是入离职的数据由办理入职的人提供，转正的数据由负责转正工作的人提供），在月底统一汇总给薪酬专员，这样的分工我认为更合理，它能使数据准确度提高。实际情况也确实如此。

　　然后改进工资表。

　　因为几个下属控股的子公司和总公司人员是交叉在一起的，工资数据也要由部门统一做，从前的做法是每个公司工资表都单独做，完了以后再汇总成总表，总表和各公司分表都需要审核，且保持一致，并送不同部门，之前经常出现工资总表和各子公司分表数据不一致的情况。现在将这一逻辑改正过来，变成先做总表，再做分表，只有总表和异动表数据做了完全迁入且验证无误以后，才能拆表形成分表，如果总表数据出现纰漏，必须重新拆表，不能在已拆的分表里边改。为使拆分过程快速，在总表增设了一个公司字段，用于筛选拆表。

　　此外，为了确保上月的异动数据在下月能被有效的处理（清除或者保留），工资表内所有迁入的异动值都必须要有备注，写清楚产生原因以及标准值应该是多少，下月做工资的时候，先清理上月工资表所有备注，把备注清理完（验证模型也会监控清理过程，确保清理无误），才能迁入新数据。

　　把这两张表做出来以后，试算了两个月，并不断改进。通过严谨的数据比对和返查，工资数据质量明显提高了，出错率大幅降低。第二季度的满意度调查，从前对工资核算的抱怨没有再出现。

　　这个时候，开始考虑下一个问题：找谁来接手，以及如何保证工资的质量不会因为转交出去了而降低？

　　从性质上来说，改进工资表和设计异动表，都是技术领域的活儿，现在要考虑的是管理领域的工作，即：如何选择以及培养工资表的接班人。这一步如果行的不好，工资就会变成一个交不出去的工作。