互联网技术服务岗的KPI，到底该按工单量还是按解决率来定？

每次聊到技术服务岗位绩效考核方案，总有人觉得这事儿简单，随便弄弄就行。等到真上手了才发现到处是坑。这篇就把那些容易忽略的细节捋一捋。 互联网科技维护岗的KPI，到底该按工单量还是按解决率来定？ 具体来说，科技保障岗位绩效考核方案这类问题，现场见过不少。上周四下午，在科技路一家做SaaS的客户那儿，我蹲在他们运维主管老赵旁边看他抽检。说起来简单，做起来要留心。老师傅从工具箱摸出把游标卡尺，卡着一块刚换下来的售后器导轨支架量壁厚——1.8mm，比国标1.6mm多了两丝。老赵咂咂嘴：“别小看这两丝，上回图便宜换的那批，1.5都不到，机柜共振嗡嗡响，甲方差点把工单系统给我们掀了。”这话让我一下想到他们工艺团队正在吵的那份工艺维护岗位绩效考核方案。 老赵的团队二十来号人，做的是本地公司的IT运维和系统集成。上个月定KPI，运营总监拍桌子要按工单量算，说多劳多得。科技组长梗着脖子要按解决率，说修得快不如修得稳。实际操作别忽略。两拨人从会议室吵到茶水间，最后老赵把烟一掐：“你们谁去跟甲方解释，为什么工单量上去了，投诉也跟着上去了？” 从实际操作来看，说白了，按工单量定KPI，最容易养出“刷单”的毛病。我见过一个保障商，工程师一天跑八个现场，每个现场拍张照就走，工单系统里得漂漂亮亮，可甲方设备该宕机还宕机。原因不复杂。后来他们改科技保障岗位绩效考核方案模板，把“一次解决率”和“返修率”权重拉高，工单量只占三成，老师傅们反而愿意多花二十分钟把根因查清楚。这道理跟量壁厚一个样——你光数装了多少根导轨没用，得看装上去的那根扛不扛得住共振。 可解决率也不是万灵药。这点很多人忽略了：解决率高的工程师，往往挑软柿子捏。简单的密码重置、网络重启，解决率百分之百。碰上数据库迁移、老旧系统对接这种硬骨头，能拖就拖。所以互联网技法支持岗位KPI设计里，得加一条“工单难度系数”或者“复杂工单占比”，不然老手全去干轻活，新手被硬活砸得离职。我见过最实在的办法，是让组长每周抽半天复评工单，按难度打标签，月底算绩效时加权。麻烦是麻烦，但比拍脑袋公平。 换个角度看，还有个行业里的妥协点得报个忧。不少本地保障商为了省事，直接拿工单系统的“关闭时长”当解决率算，结果工程师学精了——先点关闭，再慢慢修。甲方那边看着工单了，设备其实还瘫着。所以工艺保障团队绩效考核办法里，较好把“甲方确认”和“48小时无返修”作为条件，别光看系统里的绿灯。这也是常见误区。老赵他们现在就这么干，虽然月底统计多花半天功夫，但至少没人敢玩“假”。 落到执行上，我给老赵的建议是：别急着定比例，先拿量尺的劲儿去量两周工单。让组长把每张工单的难度、耗时、返修情况手工记一遍，看看你们团队到底是被“量”拖垮的还是被“质”卡住的。随后问师傅一句话：“这张单子给你算多少分，你觉得公道？”老师傅的直觉，比任何绩效考核方案模板都准。至于工单量和解决率的权重，三七开还是四六开，得看你们接的是标准化运维还是定制化集成——标准化偏量，定制化偏质。这步不能省。别小看这两丝偏差，KPI定歪了，老师傅的手感就没了。