你想“防患于未然”，有人却嫌你小题大作，怎么办？

1 一个“防患于未然”的建议

有读者跟我讲了一件事：

他是某企业的售后工程师，因为下游的客户事关民生，产品一旦出了问题后，一个团队就需要火速赶往客户现场，忙得焦头烂额，常常连续24小时合不上眼，最后还要被客户骂，公司信誉也受损。

不过，他在与客户的交流中发现，这些大问题出现之前，几乎都有一些类似的前兆，如果当时与客户沟通，一个工程师当场就能解决。

因此，他向部门经理提议，这种事件应该防患于未然，可以让客服部主动定期电话回访客户，发现有问题的迹象，当时就派人过去排查。

部门经理把他表扬了一番后，结果没有任何后续行动。今天他刚刚经历了一次事故处理，晚上怎么也想不通为什么会这样？上司也是从基层提上来的内行专家，明明有更好的业务流程，还是要坚持老办法，他的上司是不是不称职？这家公司是不是没救了？

这位读者提出了一个“防患于未然”的方案，却没有得到任何响应，如果他说的完全属实，这就是一个体现大体系运作的某些特点的典型案例，在模糊了一些行业公司背景后，我特意拿出来解剖一下这个现象。

大家可以先想一想，如果你是这个部门经理，如果这个建议本身也是合理的，你会接受这个建议吗？

2 为什么所有人都不满意

如果是一家中小型的企业，这个建议很快会被管理层采纳，它并不复杂，而且效果一眼可见，就算考虑成本的问题，也可以在部分客户上先试行。

但如果是一家部门众多，业务繁杂的大公司，实行严格的KPI考核（或者OKR，随便你叫什么啦），那结果很可能如这位读者反馈的那样。

不妨来分析一下这个建议的流程，对哪些部门有影响，首先是客服部门要增加回访的内容和频次。

KPI的设计虽然复杂，但每个部门总有一个“聚焦点”，起到纲举目张的作用，只要做好它，至少完成60~80%的考核目标。

客服部门的核心动作是等客户“上门”，然后快速分派给相关人员处理的部门，其“聚焦点”一般是这类客户的满意度，无论是提高响应速度，简化反馈流程，还是加强与其他部门的沟通，都是围绕“客户满意度”的提升来进行。

所以，客户回访并非核心工作的一部分，它通常是出于公司内控的要求，对于客户而言，甚至是一种打扰。

这个部门最大的矛盾是，如何在有限的人员和刚性的预算范围内，解决无穷无尽的其他部门造成的问题。

那么按照这个新流程，客服人员要占用核心业务的时间和人力资源，投入到非核心业务，自然没有这个意愿。

不过，客服部门并不一定是真正的问题，因为无非是增加了几次回访，或者在已有的回访中加几个问题。既然工作可量化，如果公司要求实施，反而可以借机突破部门预算的硬约束，很多客服部门的经理对此反而求之不得。

真正的阻力反而更可能出自于这位工程师所在的售后技术支持部门。

在一个庞大的体系中，体现一个部门重要性的，无非是这个部门能创造多少利润、掌握多大的预算，还有——某些时刻，别人有多么需要你。

最后一点实际上是紧急性，从管理学的角度上说，紧急性不等于重要性，会议马上要开了，材料还没有打印好，打印机又坏了，这就是典型的紧急而不重要。但在大部分人的观感体验中，紧急性跟重要性是划等号的。

事实上，作为一个既不创造利润，也不掌握预算的部门，售后技术支持部门的重要性正是通过紧急事务的处理来体现的。出了事，你是牛逼哄哄的工程师，没事的时候，你就一修电脑的。

如果按新的流程，工程师的出差量大大增加，但解决的都是小事，所以，从公司的角度看，部门的预算大大增加，但重要性（其实是紧急性）却大大下降了。嗯，部门裁员风险系数急升。

从部门员工的角度看，满意度也未必提升，出差更频繁了，可相当一部分并没有什么问题。相比之下，之前虽然忙得焦头烂额，可大家都会觉得自己很重要，客户也会把你当成“大救星”，完成工作之后的成就感很高。当然，客户满意度下降，下次再也不买你的产品了，但这是公司的事，是业务部门的问题，反而客户对自己的满意度提升了，之前还有过客户把售后工程师高薪挖过去的事情。

那么客户的满意度会提升吗？大概率也不会，新的流程下，工程师处理的都是“小问题”，客户根本不知道这些问题如果不解决会造成多大的后果，自然满意度也不会提升，反而会觉得你们的回访太频繁了，打扰了我们的正常工作。

分析到这儿，如果你是售后技术支持部门的经理，你的选择是什么呢？

我猜很多读者会将这种现象总结为“官僚主义”，但这种大而化之上升为道德批判的做法，虽然痛快，却不解决实质性问题。

之所以说大公司更可能造成这样的结果，因为大系统都是以部门（或产品线）为单位分头运作，每一个部门只需要管理好自己的内部目标就行了；至于负责协调各部门的高管，其视野更多聚焦于核心战略，而非具体业务流程，只要不出大的问题，一个有漏洞但有序的系统，总比职责不清的系统好吧？

我在上一篇文章《不充分的均衡：如何找到捡钱的机会》中说到“系统性均衡”的概念：一个能运行的系统，必然是各方形成均衡的系统，但均衡不代表有效率。如果读这篇文章的读者是某大公司的高管，我几乎可以肯定，你的员工也发现过类似的问题，但出于上述的原因，只会发发牢骚。

那么，这个系统性的问题有没有解决的可能呢？

3 谁来解决“尚未发生的问题”

大家还记得《扁鹊见蔡桓公》这篇课文吗？

扁鹊第一次见蔡桓公的时候，说“君有疾在腠理，不治将恐深”，蔡桓公很不高兴地说自己没病，等扁鹊走了，蔡桓公说了一句古今通用的话“医之好治不病以为功”。

因为医生常常充当了“乌鸦嘴”，所以很多人都不喜欢医生随便说话，蔡桓公这句话算是客气的，我猜下面的人已经开始上书了：“身为医生，不好好看病，枉议政治，分明是秦国的带路党”，所以后来蔡桓公一死，扁鹊真的跑到秦国去了。

真正的好医生，应该告诉人们如何不生病，如何改掉那些可能导致大病的坏习惯，但人们感谢的，往往是那些在你生了大病后，帮你治好的“神医”。

如果你是医生，你选择做哪一种医生呢？

所以，“防患于未然”这类事，不能让下面的人去做，原因有三：

第一，它不明确，基层员工没有权限，容易被人说闲话；

第二，它不紧急，没有动力；

第三，它的解决方案不确定，基层员工承担的风险太大。

但“防患于未然”，大部分高管也做不了，因为它“治”的是“未来的病”，比治现在的病更需要有丰富的业务经验，还要了解系统的实际运作情况。

这正是难点所在，专业人员看得到问题，也能解决问题，但没有权限和协调能力，高管有权限和协调能力，但看不到问题，也无法解决问题。

前一节也说了，企业的中层经理既有专业也有权限，但他们出于利益考虑，往往不愿意去解决“尚未发生的问题”。

所以一个系统性的问题，没办法靠任何一个部门或人的力量去解决，只能通过系统性的方法去解决，其中容易想到的，是建立激励机制，广开言路，鼓励基层员工提出合理化建议，并建立相应的负责人制度。

不过，很多公司也喜欢搞这种“征集合理化建议”的活动，结果往往沦为形式，原因何在呢？

4 为什么你得不到合理化建议？

一家大公司的各项制度都是长期实践后沉淀下来的，它们不一定最合理，但大部分都是有效的，因外部环境的变化而出现的业务流程改进需要，并不常见。

更重要的是，能够提出合理化建议的员工，既有丰富的工作经验，又刚好看到了问题所在，并能系统性的提出解决方案，大部分员工并不具备这个能力。

如果一家公司公开鼓励员工对现有制度提出合理化建议，可以想象，高层们收到的大部分是以下两类建议：

第一类是大而无当的高层战略，比如什么“公司未来十年规划万言书”

第二类是对现有制度的强调，比如什么“赶快颁布禁止陪酒令，请老板立即回复”

往往越是没有工作经验的员工，越喜欢提这两种建议。

合理化建议，只能是发现了什么就说什么，不能“直接悬赏”，管理层会被无用的信息淹没，还会让中层经理更尴尬。

真正有效的方法是高层利用工作碎片时间，直接与基层员工进行日常沟通，场合不要太正式，茶歇、午餐、会议间隙、电梯间，等等，目的性也别太强，以闲聊为主，也别指望员工给出具体解决方案，更多是了解情况，然后将你觉得重要的问题留给中层经理去形成一个可执行的方案。

我们需要一个“广开言路”的企业文化，但不需要一个绕开系统的“激励机制”，激励不是万能的，体系化管理还是企业的核心。

当然，这里设想的是一个很理想的企业高管，但回到现实，比如开头的那位基层员工如果并没有遇到这样的企业，那应该怎么办呢？

5 好方案需要好时机

首先，必须肯定，你确实可以跟上司提出完整的解决方案，但不要越级，更不应掺杂个人诉求。

只是，不要抱太大的希望，前面的分析已经告诉你了，如果一个问题的答案是显而易见的，但就是人人都绕开它，那么十有八九它是系统性的问题，可能有无数的人看到，也曾有人尝试解决，最后都无功而返。

你还有更好的时机，就是当此事造成重大损失，公司的高层开始不得不关注解决方案的时候，此时提出，可能是一个更好的时机。

可能有读者认为，这个思路已经有点“办公室政治”的味道了。但如果从善意的一面去理解，开头那位读者的部门经理之所以搁置建议，可能也在等待一个更合适的解决问题的时机。

在大企业运作中，高管层常常有一些不切实际的经营战略，相比之下，中层经理往往更了解业务执行中的实际问题 ，但最好的方法不是指出“尚未出现的问题”，而是采用“不争论，先落实，不抢头”的务实态度，尽量将问题控制在可控的范围内，等到那些执行得比较激进的部门出现大的危机后，大家已经对问题有了共识之后，再提出合理的解决方案，那时就是顺水推舟了。

所以，你也并非无事可做，你首先要做好你自己份内的工作，不管它是不是有效率；你其次可以成为一个观察者和思考者，从中得到一些经验；更重要的是，要相信自己，能系统性思考解决方案的员工，都是优秀的员工，当你晋升到可以处理此类事件的位置上时，你可以比你的上司和老板做得更好。

本文来自微信公众号 “人神公奋”（ID：tongyipaocha），作者：人神共奋，36氪经授权发布。