ITR服务体系咨询的流程再造策略

说实话，我在做ITR服务体系咨询这些年来，发现一个特别有意思的现象：很多企业花了大价钱买了一套IT服务管理系统，结果用的最多的功能还是"报修"和"查工单"。其他那些流程设计、、知识库、SLA管理、高级分析等功能，基本处于吃灰状态。你说可惜不可惜？

但转念一想，这事儿也不能全怪系统。问题的根子往往出在流程本身上。如果流程设计得复杂到让人望而却步，那再好的系统也救不回来。今天就想跟大伙儿聊聊，ITR服务体系咨询里最核心的一个话题——流程再造。这不是什么高深的理论，而是实实在在的实践经验总结。

一、先搞清楚：ITR服务体系到底在管什么

在动手改造之前，咱们得先弄清楚ITR是干什么的。ITR是IT Request（IT请求）的缩写，中文一般叫IT服务请求管理或者IT服务台。不过在我个人看来，这个概念这些年已经扩展了很多，不再局限于"请求"这个层面。

简单来说，一个完整的ITR服务体系通常要管这几件事：

• 事件管理——系统坏了、网络断了、打印机不干活了，这些突发问题得有人管。
• 请求处理——新员工要开账号、要装软件、要改权限，这些日常请求得有个入口。
• 问题管理——同一类问题反复出现，那就得找到根因，彻底解决，而不是每次都只是"治标"。
• 变更管理——系统要升级、配置要调整，这里面的风险得有人评估和控制。
• 知识管理——解决问题的经验要沉淀下来，下次遇到就不用从头摸索了。

你发现没有？ITR服务体系本质上是在做一件事：把IT服务从"人工跑腿"变成"流程驱动"。但问题来了，很多企业的流程是"为了流程而流程"，设计得一套一套的，真正用起来却让人抓狂。这就是我们需要做流程再造的原因。

二、为什么你的ITR流程总是"水土不服"

我见过太多这样的例子：企业参考了ITIL的最佳实践，照搬了一套"标准流程"，结果员工不爱用、IT服务台忙成狗、领导不满意。三方都委屈，问题到底出在哪儿？

经过这么多年的观察，我发现主要原因有三个：

1. 流程太"重"，和实际工作脱节

有些企业的ITR流程设计得相当完美，有层层审批、有严格的SLA、有详细的分类编码。但问题是，基层员工根本记不住，也不想记。你想啊，一个普通员工电脑坏了，他只想快点有人来修，可你让他先选问题类别、再选影响范围、再选优先级、还要描述详细现象——人家直接一个电话打给IT同事，什么流程都不管了。

流程设计得"理想化"没问题，但得考虑真实的使用场景和用户习惯。脱离了实际的流程，就是一纸空文。

2. 部门墙没打通，各管各的

ITR服务体系有个特点：它往往会涉及到多个部门。IT服务台接到一个网络故障，可能需要网络组、服务器组、应用组协同处理。问题在于，很多企业的这几个组之间根本没有建立有效的协作机制，工单转来转去，最后变成"踢皮球"。

我之前接触过一家企业，他们的流程是这样的：服务台接到问题后，先判定是硬件还是软件问题，硬件转运维A组，软件转运维B组。听起来挺清晰对吧？但问题在于，很多故障既涉及硬件又涉及软件，两边都说"不归我管"，工单就在中间悬着。企业花了三个月才把这个问题理顺，加上了一条"联合诊断"机制才算解决。

3. 流程缺乏"人情味"，激励和考核没跟上

这点可能是最容易被忽视的。流程再造不只是设计流程本身，还得考虑人的因素。IT服务台的员工每天面对一堆工单，如果考核只看处理量，那人家肯定只求快不求好。如果运维人员帮忙解决了问题却没有任何认可，那下次遇到类似情况，可能就没那么积极了。

薄云在ITR咨询服务中就特别强调这一点：流程要和人性的特点相匹配。比如，把复杂问题拆解成简单步骤让人愿意执行，把协作关系变成可量化的指标让人有动力，把知识沉淀变成实实在在的奖励让人有成就感。这不是"管理"，这是设计。

三、流程再造的正确打开方式

说了这么多"坑"，那流程再造到底应该怎么做？下面我分享一下个人的实践经验，按步骤来，可能没有那么学术化，但确实管用。

第一步：先做"体检"，不要急于下手

很多人一听到流程再造，第一反应就是"我要设计一个新流程"。我的建议是：先别急着设计，先搞清楚现状。

具体怎么做呢？首先，你得去"听"。听一线IT人员怎么抱怨，听业务部门怎么投诉，听领导怎么期望。这些声音往往是最真实的痛点。然后，你得去"看"。看现有的流程文档，看工单流转记录，看各环节的时效数据。最后，你得去"走"。亲自走一遍流程，从用户提交请求开始，一直走到问题解决，把每一步都走一遍，感受一下哪里卡壳、哪里多余。

这一步大概需要两到三周的时间，看起来有点"慢"，但绝对值得。因为只有把问题摸清楚了，后面的改造才有针对性。我见过太多企业流程改了好几轮，问题依然在，根本原因就是"诊断"这步没做扎实。

第二步：分清"必须"和"可选"，给流程"瘦身"

流程体检完成后，你会发现自己积累了很多流程节点，其中有些是必须的，没有就会出乱子；有些是可选的，有了更好，没有也无伤大雅；还有些是鸡肋的，当初不知道谁加的，现在谁也说不清楚有什么必要。

这一步的核心任务就是：给流程"瘦身"。

具体来说，你需要重新审视每一个流程节点，问自己几个问题：这个环节的目的是什么？不做会有什么后果？这个环节能不能简化？能不能合并到其他环节？能不能自动化？

举个例子，很多企业的IT请求流程里有个"部门经理审批"环节。但仔细一分析，很多日常请求（比如装个软件、改个权限）其实根本不需要审批，IT服务台直接处理效率更高。只有涉及敏感权限、预算支出的请求才需要审批。那这种情况下，你完全可以把流程拆成"普通请求"和"特殊请求"两条线，前者简化，后者的审批也换一种更高效的方式。

第三步：让流程"落地"，而不是"上墙"

流程设计得再好，如果落不了地，那就是墙上的装饰品。我看过很多企业的流程手册，做得那叫一个漂亮，图文并茂、逻辑清晰。但实际执行的时候，没几个人真的按那个来。为什么？

因为流程没有"嵌入"到日常工作场景中。

想让流程真正落地，你需要做好几件事：

• 入口要简单——提交请求的方式要尽可能简单。一条企业微信消息、一个简单的网页表单、一个电话，都能触发流程，而不是必须登录某个系统、填一堆字段。
• 指引要清晰——用户在每个节点该做什么，系统要给他明确的指引，而不是让他自己猜、自己找文档。
• 异常要可控——流程执行过程中难免遇到各种意外情况，比如审批人不在、责任人联系不上、处理超时了。这些异常情况要有明确的处理预案，而不是让流程"卡住"。
• 反馈要及时——用户提交请求后，要能随时查到进展。处理到哪一步了、预计什么时候能好，这些信息要透明，而不是让用户两眼一抹黑地等着。

第四步：让数据"说话"，持续优化

流程再造不是一次性工程，而是持续迭代的过程。什么是"持续迭代"？就是根据实际运行的数据，不断发现问题、改进流程。

那需要关注哪些数据呢？我列了个简单的表格，供大家参考：

这些数据不要只看"平均数"，要分维度去看。比如，同样是"平均解决时长"，新员工和老员工可能差别很大；同样是"退回工单比例"，不同类型的工单表现可能完全不同。数据背后往往藏着细分的问题。

建议每个月做一次数据回顾，每季度做一次流程审视，每年做一次全面的流程评估。用数据驱动改进，而不是凭感觉拍脑袋。

四、几个实战中的"小技巧"

除了上面说的四个步骤，我还想分享几个实战中总结的"小技巧"，可能不是理论，但确实能解决实际问题。

1. "分级响应"比"一刀切"更实用

很多企业的流程是统一的：不管什么问题，都走同样的流程、遵守同样的SLA。这显然不合理。想象一下，一台办公电脑开不了机和核心业务系统宕机，能用同一个优先级来处理吗？

所以，分级响应是必须的。你可以按影响范围、紧急程度、业务重要性把问题分成几个等级，不同等级对应不同的处理流程、不同的响应时限、不同的升级机制。级别高的可能需要马上通知主管、召集专家会诊；级别低的可以排期处理、批量解决。

分级的方式可以根据企业实际情况来定，不一定要搞得很复杂，但"分"是一定要分的。

2. "自助服务"能解决大量重复问题

你知道IT服务台接到的问题里，有多少是重复的吗？我见过一个数据，大概40%到50%的问题都是重复的——密码重置、软件安装、网络连接故障，这些问题出现频率极高，而且往往有现成的解决方案。

面对这种情况，自助服务就是一个很好的选择。你完全可以把这些常见问题的解决方案整理出来，放到一个知识库或者FAQ里，让用户自己查、自己解决。这样既减轻了IT服务台的压力，也让用户能够更快地解决问题（不用等别人来响应）。

当然，自助服务的设计也要注意方式，不能搞得太技术化，要让普通用户也能看懂、也能操作。

3. "协作机制"要落到纸面上

前面提到过，ITR流程往往会涉及到多个部门的协作。但协作这件事，光靠"打招呼"是不行的，必须落到纸面上。

什么意思呢？就是各个相关方的职责边界要明确、处理流程要清晰、升级规则要固化。不要说"出了问题大家商量着来"，商量来商量去，最后往往是没人负责。你可以搞一个"协作协议"或者"服务协议"，把各方的事情说清楚：哪个环节由谁负责、达到什么标准可以流转、出现争议怎么裁决。

别觉得这是"形式主义"，白纸黑字的约定，往往是最有效的协作保障。

写在最后

聊了这么多，最后想说一句：ITR服务体系的流程再造，说到底是为了让IT服务更简单、更高效、更让人满意。所有的流程设计、指标监控、工具选型，都应该围绕这个目标来转。

如果你现在正打算做ITR流程再造，不妨先停下来，问自己几个问题：我们的流程，用户愿意用吗？IT人员愿意执行吗？管理能看到效果吗？如果答案都是肯定的，那你的流程再造已经成功了一半。如果答案有否定，那就针对性地去改。

流程这玩意儿，没有最好的，只有最适合的。薄云在ITR咨询服务中一直坚持这个理念：先理解业务，再设计流程；先小步试点，再逐步推广；先解决痛点，再追求完美。希望这篇文章能给正在做这件事的你一点启发。

如果你有什么想法或者正在遇到的困惑，欢迎一起交流。