职场薪闻

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

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

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

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

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

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

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

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

　　接下来我开始设计报表。

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

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

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

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

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

　　然后我改进工资表。

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

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

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

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

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