如何才能比业务更“懂-懂-懂”业务呢？一个流程优化案例来说明

（图片来源：摄图网）

作者|罗甘霖  来源|罗肯锡(ID：luckinsey)

引言：

流程人要懂业务，这个“懂”是几个意思？

一个企业如果要做好流程，一定是“流程+业务”，流程人要懂业务，业务人也要懂流程，双方在一起才能产生化学反应。

如果流程人不懂业务，只知道强套流程模板，业务心理是不接受的，最后变成两张皮，束之高阁，落满灰尘。

如果业务人不懂流程，只知道强调各种特殊性和能力之不足，不肯接纳流程的规范和主业务流的约束，最后体系与能力皆得不到改进提升。

业务人懂一点流程的理念和方法就好了，不需要成为流程专家；而且，这些也都是流程部门要去培训赋能的。

那么，流程人懂业务，要懂到什么程度呢？

很多企业的领导会提要求：流程管理部要比业务部门还懂业务！

业务部门整天沉浸其中，而流程部门置身事外，如何还能比他们更懂业务呢？

这也太难了！

但如果用结构化的思维来分析，这里的“懂业务”显然是有深意的，分三个层面来看：

1、懂业务的哪方面？

2、懂到什么程度？

3、哪些可以不用太懂？

以下结合一个流程优化案例，来说明这个“懂”的深意。

《重量开发流程优化案例，懂与不懂差别大》

1、发现问题，梳理业务现状、影响及建议

那一年，罗老师在做研发员工访谈的时候，有人提到一个问题：

公司好像对车型重量信息不够重视，缺乏像成本管控那样精细的管理机制。

这导致，相比竞品，我们车型整备重量普遍缺乏竞争力。

我问：这对公司和客户的影响是什么呢？

第一：车重，原材料成本会高；

第二：上牌超重，会有合规风险；

第三：车重会加大油耗，减少载重，增加客户使用成本；

这些会导致车型竞争力降低，影响公司市场销售。

我一听心头一凛，感觉这里面有故事，继续问道：现在车型重量信息是怎么管控的？

我们工程师在PLM系统里要填一个零部件重量信息，但是是选填项。

最后车型开发完成，从系统导出整车重量时，会发现很多零部件重量数据缺失，或者数据明显跟状态不匹配，导致整备重量信息失真。

这时候需要查找图纸，找开发人员和试制人员，逐个确认补充，耗时耗力。

就这个事，我一个车型得统计一个星期，太浪费了，这个工作做得没有价值。

做流程优化久了，看见这种改进机会，眼里是会放光的。

我继续问道：这个重量信息流程，您觉得要如何改进呢？

建议公司加强轻量化管理，在产品研发流程中建立轻量化管控机制和流程，将PLM系统重量信息选填项调整为必填项，并且纳入产品开发质量绩效考核。

我感觉钓了条大鱼，这哥们真的是懂业务，从问题到影响到建议，给我分析得清清楚楚的。

这样的项目能错过吗？当然不能！

2、流程进一步调研，核实问题同时找BP

罗老师于是开始推动这个重量开发流程的优化。

那，到底要怎么做呢？ 

第一步是要核实问题真实存在，不偏不倚，再亮眼的问题也需要彻底的调研；

第二步是找一个归口责任部门，作为流程优化的BP，不能流程管理部门单干；

由于问题吹哨人是产品开发部门的项目管理员，领导指定他们部门来牵头统计各个车型的重量信息，我初步判断这个流程应该是由他们来归口负责。

罗老师于是找到产品开发部门的领导调研沟通，领导说，确实存在这样的问题。

由于系统导出数据质量差，上报数据屡屡跟实际偏差太大，他们部门被安排做这个事情，也想过很多招，但目前人工线下统计还是最快最准确的。

部门项目管理员按照整车系统结构，去调度各个系统分别统计、核实、汇总，一个车型几十个系统和几千个零部件，统计工作量很大。

而且，公司每年有几十个基础车型和数百个孪生车型开发试制，每个车型都需要做一遍，没有捷径。

此外，零部件重量信息缺乏数据库积累，无法对标改进，减重只能朝关键零部件硬发力，不能全面实施轻量化开发。

我倒吸一口冷气，真是没想到，轻量化是汽车行业大势所趋，这一个小小的重量信息管控问题，竟然成了影响公司战略的不确定性因素之一。

我于是问该领导，您觉得这个问题应该如何改进呢？

他没有提出明确的想法和建议，让我们去找技术管理部门。

我感觉他们这个部门不太想管这个事情，事后查职能职责确实也不归他们负责。

当然，其他的部门也没找到重量管理的职责。

第一步的问题是核实了，但第二步的归口责任部门没找到。

3、找不到流程归口责任部门，流程优化怎么推进？

职能职责是缺失的，接下来要怎么办呢？罗老师陷入了沉重的思考。

如果找不到业务部门主动来承担这个流程的责任，那就会出现本文开头的难题。

流程部门先要自己往前推，要考验我们“懂业务”的程度了！

①第一种情况：非常懂

对该业务的认识从广度到深度，基本不输业务执行人。

因为流程人此前有类似经验或本身就是业务出身。

这时候，可以全部自行完成：构建一套全新流程，定义清楚职能职责及流程详细设计，讨论认可之后颁行推动即是。

②第二种情况：懂基本面

理解业务的大致框架，业务流程的主要逻辑及角色职能分布，也清楚基本的问题和改进方向。

因流程人此前做过该领域的架构设计和集成关系视图，也频繁参与该领域的业务讨论及流程改进，但不曾留心于业务执行的细节。

这时候，不能完全自己做，要先找到业务BP。

比较保险的是，流程部门先做业务痛点分析，提出归口管理职责的建议，然后上会交由相关部门讨论，并报领导决策。

等领导决策后，再协同该归口责任部门一起往下做。

③第三种情况：只懂大逻辑

基本不清楚业务运营管理的细节，只了解其在价值链上的大致位置和主要业务目标。

流程人此前不曾经历或没引起关注。

这时候，完全不能自己干，先要一步步调研核实，对业务有一定的了解了，才可以继续向前推进。

最重要的是先找到业务的地图，可以是一份文件，但最好是一个人。

所谓“懂业务”基本上可以分为以上三种情况，需要安排不同的推进策略。

最重要的策略，罗老师其实反复说过，那就是找业务BP。

4、到底懂还是不懂，自知之明很重要！

罗老师自我评估，对于重量开发流程，懂的程度介于②③之间，还不能贸然行动。

它的难度在于：重量信息作为产品的一个属性，重量开发不是一个独立的流程，而是一套深度嵌入于整车开发流程的二级流程。

它需要搭建一套全新的重量目标管理模式、明确流程主要阶段、角色及职责，然后设计流程框架和集成关系视图，最后完成流程详细设计文件。

最重要的是，这套流程输出的重量属性，要与整车开发的各个阶段及开发验证状态完美匹配，稍有差错，会增加工作量导致开发人员很抗拒，或者重量信息填报不准再次失真。

所以说，这个流程完全自己设计，难度是极其大的。

说句题外话：业务不难懂，自知甚为难！

5、找到了流程责任部门，接下来怎么办？

我们只能继续去找流程责任部门，哪怕是找到一个能指引业务地图的人也行。

根据产品开发部门领导的建议，罗老师决定找技术管理部门相关领导聊一聊。

这个部门是负责产品开发项目的技术标准管理、过程质量管理、开发绩效评价的，他们如果也不愿意管，那这个事情真的很难办了。

为了应对最坏的局面，罗老师准备了很多话术，尤其是要把重量开发流程和轻量化战略的关系捋一捋。

但是居然很意外，我刚说清楚了问题及建议，领导就答应了，他们来负责这个流程的优化，让我们提供指导意见。

我当然满口答应，流程文件模板我们来提供，并且全程参与支持。

接下来就是跟领导沟通下大概的改进方向及思路，以及要输出的文件内容和工作计划。

这又到了要考验“懂业务”的程度了，还好是有备而来。

我建议：

1、改进方向上建议学习成本管理的方法和机制，建立一套完整的重量目标管理流程；

2、明确重量信息的强制填报要求，并且融入现有整车开发流程，使之不增加开发人员额外的工作量；

3、正向策划分解重量目标要求，事后通过目标达成和数据质量进行考核，纳入产品开发质量绩效考核，先占各系统主任一个比较小的考核比重。

在这里，罗老师没有提流程管理的那一套东西，说的都是业务能听得懂的话。

领导表示认可，安排了具体的人员跟我对接，跟他我才需要讲到具体的流程设计。

不管懂与不懂，做流程优化的难度都是存在的。

第一：一定要多沟通，不要轻易放弃，说不定峰回路转了呢？

第二：提前做好准备，不要临场随意发挥，否则再好的改进机会，也可能因触发一些隐秘点而被自己搅黄！事后只能拍大腿。

第三：抓住关键点，坚持妥协优化策略，不重要的事项都可以随缘让步，不用追求完美！

6、 如何才能实现“流程+业务”1+1＞2的效果呢？

领导安排的这个对接人很专业，罗老师只说了一遍，他就明白了大概的意思，很快编制下发了一个重量开发流程试行规范，包括以下内容：

①管理要求及模式：重量作为重要属性建立公司级管理机制，明确重量目标管理的业务模式，包括策划分解、偏差调整、目标达成的过程。

②流程角色：整车架构经理作为产品重量属性负责人，负责目标策划、分解、评审及达成；

再也不用产品开发部门项目管理员去做线下统计了，如果要统计也是整车架构经理去做，他们更专业更有判断力。

③流程阶段及活动任务：整车开发各个阶段的重量信息的状态及填报要求；

④绩效评价：技术管理部门根据整车架构经理提报的数据和建议，对各系统主任进行考核。

⑤IT系统调整：同时下了一个项目，要求IT部门评估PLM系统重量属性设置，调整为必填属性，并建立逻辑勾稽关系，避免瞎填乱报。

以上这些流程详细设计，其实都是业务自己完成的。

罗老师提供了方向及模板，业务输出了全套流程成果，达成了“流程+业务”1+1＞2的效果。

所以无论何时，罗老师都建议：

流程的详细设计，最好还是业务部门来完成。

即使那个接口人不专业，你也需要把他培训出来。

一来，流程部门没有必要那么深入业务的普遍细节，要适当给业务授权，他们自己做的流程，后续执行起来更容易；

另一方面，流程部门即使真懂那么深，也没有那么多精力去做详细的流程设计，还有更多更重要的高阶流程设计优化的事情等着呢。

7、总结：流程人懂业务，要懂得“恰到好处”

最后总结一下，几个观点：

1、“懂业务” 不是为了懂业务而懂业务，是为了更好地牵引业务！

2、懂业务，只是要“懂”而已，不是要你全知全能！

3、不懂当然不行，但懂得越多越深未必就越好！

流程人懂业务，要懂得“恰到好处”，正所谓：

增之一分则太长，减之一分则太短；

著粉则太白，施朱则太赤。

此中深意，要靠领悟，哈......

各位，领导要求“懂业务”，懂哪些、懂到什么程度、哪些不用太懂，你们搞懂了吗？

（以上案例纯属虚构，如有雷同，概不负责）

编者按：本文转载自微信公众号：罗肯锡(ID：luckinsey)，作者：罗甘霖