Tinyfool的开发日记(blog)

　　我所在的公司是一个小公司，以前的人事管理都是手工进行的，所有人员的信息都是记录在某一个本子上面的。在公司很小的时候，这样的工作方式没有看出来有什么问题。现在公司有管理人员近百名，工人近千人，而且由于产品的特性，公司的人员流动率相当的高，慢慢的人事部门发现原有的管理方式已经没有办法正常运转了。比如，发工资当时也是手工计算的，于是每次工人工资的计算都要花掉两三天的时间，而且最后给不出来一个工资条，工人应该拿多少钱，到底为什么拿这么多钱，没有一个说法，工人们收到工资的时候就会有许多的怨言。

　　于是在三四个月前，我开始帮助人事管理部门做了一个人事管理和工资结算的软件，由于时间紧，而且我对这类管理不是很懂，所以这个软件做出来还是有很多毛病的，先后几乎改动了30多次，有些是人事部门的需求改变，有些是去除代码中的逻辑错误等等。但是总之值得欣慰的是，现在我们已经有了一个包含所有工人信息的数据库，而且基本上还是在正常的运转。

　　公司有一个食堂，每餐的用餐人数大约是100-400人次，主要是供应中餐，偶尔会有晚餐和夜宵。根据老板的意图，公司给所有出勤的工作人员准备一顿免费的工作餐。这个用意还是很不错的，但是实施起来还是出现了很多困难。
　　最早的时候，公司的做法是每个人根据出勤情况，在月底发给补助，标准为一个工作日给4元钱补助。然后，食堂的午饭采用3元和4元两种标准，大家在食堂买饭。这样做的立意很好，但是后来发现了一些问题。问题就是发现很多工人（主要是外地打工人员），经常不在公司吃饭，干脆饿一顿，这样为了节省餐费补助（看这有点不可思议吧，但是对很多外地女工来说，一个月大约80元的餐费补助也不是小钱）。公司的工作还是很辛苦的，这些刻意省钱的工人发生过多次在上班时候晕倒的情况，后来调查发现她们经常不吃中饭来省钱。公司领导知道这个问题以后，决定一定要解决这个问题，就是说要保证发给员工的餐费补助只能用来吃饭而不是省下来。第二个问题，就是公司的工作量是很不均匀的，一个工人这个月出勤天数是20天，下个月可能只有15天，而餐费补助和工资一起发的办法，实际上只能发给工人上月的餐费补助。相对另一些工人，刚刚来到这里打工的女工，他们往往在发第一个月工资前，身上没有多少钱，去食堂吃饭都是奢侈的。这个问题公司也想解决，是否能够在公司出勤一天，马上就给他补助呢？
　　这个问题其实还是相当复杂的，每天基本上出勤人数是100-400左右，也就是说每天发出去的餐费补助在400-1600之间，这个多现金发到那么多人手里面，是相当麻烦的。如果按照每天发补助的模式，管理部门的工作量将大大提高，而且出现问题的几率也大大提高。另一个问题就是，一旦现金发给了工人，那么就无法控制这个钱是用来吃饭还是别的。
　　在解决这个问题上面，公司最后决定采用射频卡售饭系统，补助发放到卡里。于是公司购买了北京某公司的射频卡售饭系统，并买了相当数量的射频卡。购买这个射频卡系统时，我作为技术部门的监督全程参与。买来以后这个系统的安装调试也是由我来负责的。安装很容易，然后我们给公司所有的员工注册了卡，并每人在里面预先放了50元。但是这个方案后来也遇到了一些困难，在第一笔50元钱用完以后，很多人开始用钱买饭，这个系统开始崩溃，因为相对来说，拿着钱去食堂加卡是比较麻烦的。
　　但是不管怎么说从技术上讲，这个射频卡还是很稳定的，虽然他没有给我们提供二次开发的接口。于是，后来我们又从同一家公司购买了射频卡考勤系统，使用的是相同类型的射频卡，但是考勤机和食堂的卡机还是有些区别的。后来，我们还从这家公司购买了射频卡门禁系统作为我们的安全系统的一部分。这三套射频卡系统都采用的是同一种类型的射频卡，实际上我们给每个人只发一张卡。他需要什么功能，我们就在那个系统上面给他开通这个功能。
　　于是，管理部门提出，能不能只要工人早晨在考勤机上面打卡，我们就在食堂的账号上面给他加上4元钱。这个工作我做了一下，程序本身并不复杂，但是遇到了一些程序外的因素。比如，我们设定7:30到10:00是打卡上班的时间，但是发现很多工人由于班车早到7:30前就已经打卡了，这样他们的账号就不能得到4元钱，而很多工人昨天晚上来上班的，今天下午才下班，所以他们在早晨没有打开，这些问题都和程序没有什么关系，但是确实是影响系统的使用。还有一些工人，比如动力机房的工人，办公室那边的工人，他们都不从现在的考勤地点上班，所以他们的以前都不打卡的。这也造成了一些问题。