我的案例

某快餐连锁巨头的供应商，车间里按工序计件。月底发工资，每个工人的钱由两块组成：这个月做了多少件，乘以每件的工价；再加上工龄工资。

第一块靠数，第二块靠算。数在班组长手里，算在人事手里，两张表合到一处，才是一张工资条。勤哲 Excel 服务器在这家企业做的事，就是把“数”和“算”接在一根线上。

听起来简单。但只要车间的完工数和人事的工价表分属两处，每个月就会有几天时间花在对数上：数量对不上、工序叫法不一致、有人漏报、有人重复报。

计件工资的第一块基石是工价。哪道工序、按什么单位计、单价多少，必须先落成一张表。这张表定下来，后面所有的计算才有依据；它也最忌讳口头约定——同一道工序今天一个价、明天一个价，工资就没法解释。

第二块基石是人。员工信息里除了姓名、岗位，还有一个容易被忽略的字段：入厂时间。它当时看着没用，算工龄工资的时候就全靠它。

这两类基础数据都可以用电子表格批量导入，有变动时改一次，其他表单直接引用。同一个工价只维护一处，同一个员工只建一次档，这是后面不返工的前提。

录入方式没有标准答案，取决于车间的节奏。

一种是每批次完工就扫二维码，边做边记，数据最及时，但对现场配合要求高；一种是把当班的完工单攒起来，办公室集中录入，人多、单量大时效率高；还有一种是用手机 APP 录，人不必回到电脑前。

这家客户选的是第三种。为了让车间的人愿意用，模板只保留了必要字段，全部设成单一数据项——能点选的不让打字，能默认的不让填。字段少了，录错的概率也就低了。

如果手上已经有一批整理好的电子表格，也可以直接批量导入，不必一条条重录。

算工资这一步，很多企业是用 Excel 公式做的：把完工导出来，把工价 VLOOKUP 进去，再乘一遍。当月做完就丢，下个月重来一次。

勤哲换了个做法：建一个数据库视图，把完工数量和工序工价按工序关联起来，乘法在视图里完成。工资结果通过自定义报表呈现，录入的那一刻，数就已经算好了。

好处有两层。一是快：不用等月底集中算。二是可查：某个人某一天做了哪几道工序、各多少件、按什么单价算的，能一层层点开看到明细，不必再解释“这个数是怎么来的”。

工龄工资的规则不复杂，但手工算很磨人。这家企业为了鼓励熟练工留厂，定的是：满一年每月 100 元，每多一年加 50 元，封顶 550 元。

规则一旦写进系统，就变成了一个按入厂时间推算的函数：谁的工龄到了哪一档、这个月该发多少，系统自己判断。人事不用再拿计算器一个一个算，也不会因为某个人忘了调档而少发。

这类“小规则”最能体现系统的价值。它不产生新的业务，只是把一件每年都要重复、又容易出错的事，变成一次配置。

回头看这个项目，它没有复杂的流程引擎，也没有跨系统集成。基础数据导进去之后，日常只剩一个动作：录完工数量。剩下的计算、汇总、明细，都是系统在跑。

成本低、模板设置简单、功能够用、操作简单——这四句评价听起来平淡，但对中小企业来说，恰恰是最实际的四条标准。买得起的系统很多，用得下去的不多。

更值得注意的是它的可改性。计件单价会调、工龄规则会变、工序会增减，这些都不需要找开发商排期，企业自己改一下表就能跟上。

计件工资只是入口。勤哲这套底子，往后可以接产量统计、工序良率、班组考核——先让一个每个月都要疼一次的地方不疼了，再谈别的。