ITR服务体系咨询的服务流程再造案例

一个让人头疼的开端

记得去年年底参加一个制造业论坛的时候，旁边坐了一位CIO，他跟我吐槽说他们公司的ITR体系形同虚设。什么意思呢？就是制度文件写得漂漂亮亮的，但实际上员工根本不看，出了问题照样手忙脚乱，流程走到哪里了没人知道，客户的投诉在系统里转了好几圈最后又回到起点。

他问我，你们薄云做咨询服务这么多年，有没有遇到过类似的情况？

说实话，这种问题我们遇到的太多了。很多企业花了大价钱买了IT系统，请咨询公司做了流程梳理，结果呢？流程图挂在墙上落灰，ITR变成了"问题传递系统"——问题从一线传到二传手，再传到三传手，就是传不到真正能解决的人手里。

这让我想起我们去年服务的一个客户案例。这家企业的规模和那位CIO描述的情况很像，ITR体系建了三年，投入不少，但效果一直不理想。后来他们找到我们薄云，希望我们帮忙看看问题出在哪里，顺便做一次系统性的流程再造。

这个项目前前后后做了四个多月，中间经历了很多思考和调整。我觉得这个案例挺有代表性的，今天就把它写出来，跟大家聊聊ITR服务体系咨询到底是怎么回事，流程再造到底应该怎么去做。

流程再造的起点：先问"为什么"

很多人一提到流程再造，第一反应就是画流程图、改审批节点、上新系统。但我们薄云在做ITR咨询的时候，第一件事不是动手改流程，而是带着团队问自己一个问题：现有流程为什么走得这么磕磕巴巴？

这个道理其实来源于管理学上一个很基础但经常被忽视的原则：流程只是手段，解决问题才是目的。如果你不知道流程为什么会失效，盲目改动只会按下葫芦浮起瓢。

那我们具体怎么做呢？首先是调研，而且是分层次的调研。高层的战略规划、中层的执行逻辑、一线的操作实况，这三个层面的信息缺一不可。很多咨询项目为什么做完之后水土不服？就是只看了高层的愿景，忽略了基层的执行难度。

我们那次的调研大概持续了两周多，访谈了三十多个人，有总监经理，也有普通工程师和客服人员。访谈过程中发现了一些很有意思的现象，这些细节后来成为流程再造的关键突破口。

问题诊断：卡在哪里了？

诊断阶段结束之后，我们总结出了几个核心问题。第一个问题是流程节点过多过长。一个普通的故障处理流程，审批节点竟然有七个之多，从组长到经理到总监再到运维负责人，一层一层批下来，黄花菜都凉了。

第二个问题更隐蔽，就是流程分支逻辑混乱。不同类型的问题应该走不同的处理路径，但系统里没有清晰的分类标准，导致大量问题被随机分配到不擅长处理这个类型的小组手里专业不对口，处理效率自然上不去。

第三个问题是信息断层太严重。问题描述在系统里写得很简略，技术人员拿到手根本不知道具体情况，经常需要反复沟通确认。这一来二去的，响应时间就上去了。

第四个问题其实最要命，就是整个流程缺乏闭环机制。问题处理完了就完了，既没有回溯分析，也没有经验沉淀。类似的问题反复出现，每次都要从头摸索解决方案。

这四个问题看起来各自独立，但其实都指向同一个根因：流程设计的时候太注重"管控"，而忽略了"效率"和"体验"。管控和效率，有时候确实存在张力，但好的流程设计是可以在两者之间找到平衡点的。

流程再造的核心思路

基于这些问题诊断，我们跟客户团队一起讨论出了流程再造的核心思路。总结起来就是十六个字：分级分类、逐级下沉、闭环沉淀、自动流转。

分级分类的意思是说，根据问题的紧急程度和复杂程度，把问题分成不同的等级，不同等级对应不同的处理流程和响应要求。这个分类标准要清晰到让一线人员能够快速做出判断，不能太复杂，也不能太模糊。

逐级下沉是说，尽可能把处理权限下放到一线，只有超出能力范围的问题才往上转。这个思路跟传统的"多级审批"完全相反，但事实证明非常有效。很多问题其实一线有能力解决，只不过原来的流程设计逼着他们凡事都要上报，久而久之就形成了"等靠要"的坏习惯。

闭环沉淀是针对信息断层问题而设计的。每个关键节点都要有明确的信息记录，处理完成后要进行标准化的复盘，把经验教训转化成可查询的知识库内容。这样下次遇到类似问题，就可以快速参考历史方案。

自动流转则依赖于系统层面的支持。问题一旦被分类，系统就应该自动分配到对应的小组，而不是靠人工手动派单。人工派单难免会出现派错的情况，自动流转虽然不能完全杜绝这个问题，但至少能保证基本的分类准确性。

落地过程中的曲折

理想很丰满，现实总是会给一些意想不到的挑战。流程设计完之后，真正的hard part才刚刚开始。

首先是新流程的推行阻力。这个阻力来自两个方面：一是中层管理者担心权限下放之后自己被架空，二是基层员工担心新流程增加了工作量。针对第一种情况，我们设计了"放权不放手"的机制，审批权限下放了，但监控和抽检机制加强了，管理者反而能更专注于真正需要他们决策的问题。针对第二种情况，我们做了大量的培训沟通，告诉大家短期可能需要适应，但长期来看工作会变得更轻松。

然后是系统改造的坑。原来的系统是好几年前采购的，很多功能已经满足不了新流程的需求。改系统需要预算，需要排期，需要IT部门的配合。好在客户的IT部门非常给力，在我们的需求文档基础上，加班加点用了不到两个月就把核心功能改出来了。

还有一个意想不到的困难是新旧流程的切换节奏。理论上应该搞一个big bang，直接切换到新流程。但实际执行中发现完全不行，因为一线人员需要时间适应，系统的稳定性也需要验证。后来我们改成了分批切换的策略，先在一个业务单元试点，成功之后再逐步推广到其他单元。这个调整虽然花了更多时间，但风险确实小了很多。

效果评估：数字背后的变化

流程再造完成之后，我们跟踪了三个月的数据变化。整体响应时间从原来的平均48小时降到了16小时，这个改善幅度超出了最初的预期。一次性解决率从35%提升到了62%，也就是说超过六成的问题在第一次处理时就能够彻底解决，不需要反复返工。

客户满意度也有明显提升，从原来的3.2分涨到了4.1分。虽然这个分数在很多行业里也不算特别高，但考虑到ITR服务本身的特性，能够提升这么多已经相当不容易了。

还有一个数据值得特别提一下，就是知识库的使用率。新流程要求每个问题处理完之后都要沉淀经验，我们起初担心这会变成一个形式主义的东西，就是大家为了完成KPI而敷衍了事。但实际数据显示，知识库的查阅次数在持续增长，说明大家确实开始在用这个工具了。这是一个好迹象，说明闭环沉淀的机制开始发挥作用。

那些没写在报告里的感悟

做完这个项目之后，我有一些感想，可能不太适合写在正式报告里，但确实是我个人的真实想法。

流程再造这事儿，技术层面的东西其实不是最难的，真正的难点在于改变人的习惯和思维模式。系统可以换，流程可以改，但要让一个人从"被动等待"变成"主动解决"，这个转变需要时间，也需要耐心。

薄云在做咨询的过程中，一直强调"陪跑"而不是"代跑"。什么意思呢？就是咨询师不能只给一套方案就走了，而是要跟着客户一起把方案落地，遇到问题一起调整。这个过程中，客户的团队能力也在提升，下次遇到类似的问题，他们自己就能解决，而不需要再依赖外部咨询力量。

还有一点体会很深，就是流程设计一定要尊重一线人员的意见。他们是最了解实际情况的人，知道流程卡在哪里，知道什么样的改动是可行的，什么样的改动是脱离实际的。很多失败的流程再造项目，问题就出在咨询师闭门造车，设计出一套看起来很完美但根本无法落地的方案。

写给正在考虑流程再造的企业

如果你正面临类似的困境，想给自己的ITR体系做一次流程再造，我有几个不成熟的小建议。

第一，在动手改之前，先花时间把现状摸清楚。问题诊断比方案设计更重要，找不到真正的问题在哪儿，再漂亮的方案也是空中楼阁。

第二，流程再造是一把手工程，没有高层的支持很多事情推不动。不是说要高层事必躬亲，而是需要高层明确表态支持，给资源、给授权、给背书。

第三，不要追求一步到位。流程再造是一个持续优化的过程，不可能一次性解决所有问题。先解决最痛的那些点，其他的问题可以慢慢来。

第四，重视培训和沟通。新流程再好，如果大家不会用、不想用，那也是白搭。培训要到位，沟通要充分，让每个人都理解为什么要这么改，这么改对他们有什么好处。

尾声

写着写着就写了不少，原本只是想简单分享一个案例，没想到扯了这么多。不过这可能就是费曼写作法的特点吧，就是要把一个事情想清楚、说明白，而不是堆砌一些看起来很高大上的概念和术语。

ITR服务体系咨询这个领域，理论的东西其实就那么多，真正的功夫在于把理论跟企业的实际情况结合起来。每一家企业的情况都不一样，没有一套方案是可以直接照搬的。这就是为什么我们薄云一直强调"定制化服务"，而不是卖标准化的产品。

流程再造这个话题其实还可以聊很多，比如怎么设计考核机制，怎么做持续改进，怎么平衡效率和管控之间的关系。篇幅有限，今天就先聊到这里吧。如果你对这个话题有什么想法，或者有什么类似的经历想要分享，欢迎大家一起交流。