这是一个让很多 IT 负责人想不通的现象。公司花了不少钱,上了一套正经的 IT 服务台系统,本来是想告别过去工单靠微信、记录靠脑子的混乱。系统上线了,实施顾问配置了流程,全员也做了培训。但几个月之后回头看,工程师们处理工单还是习惯先在自己的 Excel 表里记一笔,系统里的工单要么是下班前补录的,要么干脆空着。服务台系统成了一个昂贵的摆设。IT 负责人很困惑:系统该有的功能都有,为什么工程师就是不用?是不是大家执行力有问题,要不要发个通知强制要求?但问题的根源,往往不在工程师身上,而在于系统有没有真正理解工程师每天的工作方式。一套服务台系统能不能落地,不取决于它的功能清单有多长,而取决于工程师打开它的第一眼,看到的是不是自己最需要的东西。这篇文章就来聊聊,一套真正能让工程师用起来的 IT 服务台,到底应该做对哪几件事。一、工程师为什么用 Excel:不是抗拒系统,而是系统不够顺手要解决这个问题,先得理解工程师为什么会自发地用 Excel。仔细观察就会发现,工程师用 Excel,不是因为抗拒新系统,而是因为 Excel 在某些方面比系统更顺手。第一,Excel 能让工程师一眼看清自己手上的活。打开表格,哪些工单待处理、哪些快超时了、哪些今天必须完成,一拉到底全看到了。而很多服务台系统,工程师要看清自己的待办,需要在不同菜单之间点来点去,逾期的工单在一个地方,待审批的在另一个地方,指派给自己的任务又在第三个地方。信息越分散,工程师就越倾向于用一张自己的表来汇总。第二,Excel 能让工程师按自己的习惯组织信息。每个工程师对工单优先级、处理顺序都有自己的判断,Excel 可以随意排序、标记、加备注,灵活度高。如果系统的视图是固定的、僵化的,工程师就会觉得不如自己的表好用。第三,Excel 没有操作负担。在系统里更新一张工单,可能要点开工单、找到字段、修改、保存好几步;在 Excel 里改一个单元格,一秒钟的事。当系统的操作成本明显高于 Excel,工程师自然会选择阻力更小的方式。理解了这三点,解决方向就清晰了:让系统在看清工作组织信息操作便捷这三个方面都做得比 Excel 更好,工程师就没有理由再回到 Excel。二、工程师工作台:让登录第一眼就看清全部待办替代 Excel 的核心,是给工程师一个聚合的工作视图——登录系统的第一个界面,就把他关心的所有信息聚合呈现,不需要再去各个菜单里翻找。这个视图应该包含工程师每天最关心的几类信息:我有多少未解决的工单,哪些已经逾期,哪些今天必须处理,有没有需要我审批的请求,有没有指派给我的任务和变更。这些信息聚合在一个界面里,工程师一眼就能掌握自己当前的全部工作负载,做出处理优先级的判断。下面是 ServiceDesk Plus 的技术员门户界面,可以看到这种聚合视图是怎么呈现的。左侧的我的一览表直接列出了逾期的请求、今天必须处理的请求、未解决的请求、已批准和未经批准的变更、待解决和未指派的问题,每一类后面都带着实时的数字;中间是我的任务清单,按计划开始时间排列;右侧是我的所有待处理审批,请求审批和变更审批分类展示。工程师不需要在系统里东翻西找,登录后这一屏就是他一天工作的全景图。ServiceDesk Plus 技术员门户:工程师登录后一屏看清待处理工单、任务与待审批,替代自建 Excel当系统能比 Excel 更清晰、更实时地展示工程师关心的信息,工程师就会逐渐把工作重心转移到系统里。这是服务台落地的第一块基石——先让工程师愿意打开系统、依赖系统,后面的数据完整性、流程规范化才有可能。三、统一入口:把分散的请求收拢到一个地方工程师用 Excel 的另一个深层原因,是请求的来源太分散。有的请求从邮件来,有的从企业微信来,有的是用户打电话报的,有的是路过工位时口头交代的。工程师为了不漏掉任何一个,只好用一张自己的表把所有来源的请求都登记下来,作为一个总账。解决这个问题,需要让 IT 服务台成为所有请求的统一入口。无论用户通过自助服务门户、邮件、企业微信、钉钉还是电话提交请求,所有请求都自动汇聚到同一个工单系统里。工程师在一个地方就能看到全部待处理的工单,不需要再用 Excel 去手工汇总不同渠道的请求。统一入口带来的不只是工程师的方便,更是 IT 服务管理的规范化。每一个请求进入系统,就有了唯一的记录、明确的责任人、可追溯的状态。请求不会再因为发在某个群里被消息淹没而遗漏,处理过程也不会因为记在某个工程师的私人 Excel 里而无法被团队和管理者看到。当请求的入口统一了,IT 服务的数据基础才算真正建立起来。四、SLA 自动管理:把盯着截止时间这件事交给系统工程师在 Excel 里标记工单的优先级、记录每张工单的截止时间,本质上是在用人工的方式管理 SLA。但人工管理 SLA 有两个绕不开的问题:一是容易遗漏,工单数量一多,人脑和手工表格都难以全面跟踪;二是缺乏预警,往往是工单已经超时了,才在某次翻表时发现。IT 服务台系统的价值,正是把 SLA 管理自动化。为不同优先级的工单分别设定响应时限和解决时限,系统自动跟踪每一张工单的 SLA 状态,在即将超时前主动发出预警,超时之后按预设规则自动逐级升级,确保没有任何一张工单会因为被遗忘而无声无息地超时。下面是 ServiceDesk Plus 的 SLA 配置界面,以一条高优先级工单的规则为例。响应时限设定为 30 分钟,解决时限设定为 8 小时;并且可以勾选不管是否为工作时间都应解决不管是否为节假日都要响应等选项,精确控制计时规则。更关键的是下方的逐级升级策略:启用一级升级,在逾期前 1 小时升级给工单所有者并提醒;启用二级升级,在逾期后升级给支持组经理并将优先级调为极高;启用三级升级,继续上报给部门经理。每一级升级触发的时间、通知的对象、自动调整的优先级和处理级别,都可以精细配置。ServiceDesk Plus 的 SLA 配置:设定响应/解决时限,并配置逾期前后逐级升级的通知与处理规则有了这套自动化的 SLA 管理,工程师不再需要自己盯着每张工单的时间,系统会主动告诉他该先处理哪一张、哪一张快要超时。这比工程师在 Excel 里手动维护一列截止时间要可靠得多,也让 IT 服务的响应速度从依赖个人自觉,变成了由系统保障的制度化能力。对管理者来说,SLA 达成率也终于有了准确的数据来源,而不是基于一堆补录的、不完整的工单去估算。五、从工程师补录到工程师主动用:服务台落地的关键把工程师从 Excel 拉回系统,靠的不是行政命令,而是让系统在每一个环节都比 Excel 更省力。几个关键点值得 IT 负责人重视。第一,工作视图要聚合、要顺手。工程师登录第一眼就能看到自己的全部待办,这是替代 Excel 的基础,前面已经详细讲过。第二,操作要尽量简单。接单、更新、关闭工单的步骤越少越好。如果处理一张工单要点开七八个层级,工程师就会嫌麻烦。支持拖拽操作的看板(Kanban)视图,可以让工程师直接拖动工单来改变状态、调整优先级或重新指派,把操作成本降到最低。第三,系统要主动替工程师减负。SLA 自动跟踪和预警、工单自动分类和路由、相关知识库文章自动推荐——这些自动化能力的共同作用,是把工程师从用脑子记、用 Excel 记中解放出来。系统帮他记住该记的、提醒该做的、推荐该用的,工程师只需要专注于解决问题本身。第四,持续观察数据,验证系统是否真的被用起来。一个直观的判断标准是:工单是在问题处理过程中实时更新的,还是下班前集中补录的?前者说明系统真正融入了工作流程,后者说明工程师还在用 Excel 当主战场、系统只是应付检查。这个信号,比任何功能清单都更能反映服务台的落地质量。当系统在这几个方面都做得比 Excel 更省力,工程师就会自然而然地把工作重心转移到系统里。工单数据完整了、实时了、准确了,IT 服务的管理、分析和持续改进,才真正有了可靠的地基。IT 服务台系统的价值,从来不在于它的功能列表有多长,而在于工程师愿不愿意每天打开它、用它来工作。一套能让工程师发自内心觉得比我自己那张 Excel 还好用的服务台,才是真正落地、真正能为 IT 服务管理创造价值的服务台。本文中展示的技术员工作台、SLA 自动升级等界面,来自 ManageEngine 的ServiceDesk Plus。它把工程师聚合工作视图、多渠道统一工单入口、SLA 自动跟踪与逐级升级、知识库、看板视图等能力整合在同一个平台,原生支持 ITIL 流程,设计目标就是让工程师愿意主动用、而不是被迫补录。对于正在为系统买了却没人用发愁的 IT 团队,可以申请试用,亲自体验工程师端的实际使用顺手程度。