有一些事，永远不会有人向领导汇报
The following article is from 人神共奋 Author 人神共奋
(资料图)
作者： 人神共奋
来源：人神共奋（ID：tongyipaocha）
01
一个忙碌的上午
这是一个忙碌的上午，每个人都在卖力的工作。但他们真的在工作吗？让我们按下暂停键。
小张已经忙了一个早上了，她觉得自己还是很有条理的，这种有条理的忙碌感让他觉得内心充实。她会把每件工作按照紧急程序进行一个大致的排序，一件件处理，但是判断依据呢？只是自己的一个感觉而已。
她最讨厌别人催他工作，那些工作在别人看来是否紧急，她不在乎，自己只是工作当中的一个环节而已，把自己该做的事做完，别的管不着。
再来看一看老王。老王的工作已经接近尾声了，却故意放慢了工作节奏，原因很简单，下一项工作需要等前面的小张把她的那一部分工作做完，但刚才问了，小张还没有开始做。
如果现在就把手上的工作处理完，他就会显得无所事事，这不好。没有人关心工作流程，只要他没有在干活，别人就会认为他在偷懒。
还有小李，小李的工作需要老王配合，他是个没有安全感的人，不停地催促老王，至于这个项目是否比别人的更急，他才不管呢。
小李的工作做完之后还需要小赵处理，但是他也不在乎小赵有没有时间，他最在乎的是自己是不是全部门效率最高的那一个人，因为这个关系到他下半年能否升级？
小李的方法是不停地抱怨别人的效率不高。这样一来，别人一旦遇到他的活就会赶紧把它做好，以免被他说。虽然小李真的成了全部门效率最高的员工，但代价是所有跟他无关的项目，都会被耽搁。
可以说，大部分公司的 " 工作流 " 体验都是如此，不但无法提升效率，还激化了人际矛盾。
到底是哪里出错了？
02
工作的上下游关系
工作流上的关系有三种：一是统筹协调，二是监督支持，三是上下游关系——后者也是最主要的关系，比如记者采完稿给编辑、商务拓展找到意向客户后给客户经理、产品经理向程序员提产品需求，等等——好的 " 工作流 " 就是把 " 工作原料 " 一步步地变成工作成果。
大部分的工作合作关系中，都有主动请求与被动配合的两种角色：有上游主动，下游配合的，比如服务员报上菜单，大厨才能烧菜；也有下游主动提需求，上游配合，最后由下游审核的，比如产品经理对产品功能提出改动需求，工程师执行完成后，交给产品经理审核。
如果真的按工作流顺利跑下来，那结果自然是皆大欢喜，年终考评升职的升职、加薪的加薪。
实际上，很少有任务能照着设计好的 " 工作流 " 顺畅地跑一遍，每次不是这里沟通出了问题，就是那里多了意想不到的需求。整个流程，上下游在不同阶段中，主动与被动的角色会交换好几次，比如工程师觉得需求不明确，工作被打回，产品经理觉得又有新需求补充，要调整方案；明知需求发生变化，有些人也不会打破 " 工作流 " 立刻通知团队成员，一定要等到同事的工作做完了，才告诉大家这个噩耗。
甚至可以说，" 没有意外 " 才是让人感到意外的事。
在团队配合中，如果始终站在自己的立场上看工作流，结果无非两种：一是 " 对方态度不积极 "；二是 " 对方能力差 "。
再加上个人绩效诉求，人人都要放大自己的部分，最好的办法就是，平时多给工作流上的伙伴 " 挑刺儿 "，别人多承担一点责任，你就多一点业绩。
流程不但可以用来抱怨，更重要的是 " 保护自己 "。比如说，如果你在某任务的最后一个环节，你发现由于前面的流程被拖了下来，导致你不可能按时完成任务，很多人的第一个念头并不是 " 想办法挽救 "，而是立刻发邮件通知相关的人，以撇清自己的责任，最重要的是——抄送上司。
于是，除了一部分 " 抱怨者 " 之外，团队中大部分都是被工作流支配的 " 被动配合者 "——来了活就做，做完就丢到下一个环节，只对工作职责负责，不对任务执行结果负责。
就算你可以把 " 抱怨者 " 看成是一个团队的害群之马，可那些 " 被动配合者 " 才是大多数人。
所以真正需要对流程负责的人，是部门经理。
03
有一些事，永远不会有人汇报
工作流程优化可能是部门经理最核心的工作——还是加上之一吧。
如果你是一个几十个人的部门的负责人，你看见下属带着客户进公司，你可以装作没看见；会议室里的新业务谈判正在进行，供应商正在拍桌子，你可以装作没看见；技术的几个同事对某个方案的细节产生了分歧，你仍然可以装作没看见。
反正按流程，最后下属总要向你汇报，如果不汇报，说明一切顺利且你已经充分授权了，只要你不是故意推诿，一个好的组织可以自行解决大部分的问题，领导的介入反而让事情横生枝节。
但有一些事件，不会有人向你汇报，不会有人告诉你流程有问题，下属和客户只会告诉你 XXX 工作效率太低，XXX 下班后就联系不上了。
一提到工作流，很多人就想起管理学中的 " 工作流程再造 "，但这不是部门经理的事，任何流程的改革都会涉及到其他业务部门，" 工作流程再造 " 是整个公司底层业务逻辑的根本性变革，并不是部门经理能解决的。
部门经理考虑的是工作流程优化，是在不推翻业务流的前提下，尽可能提升效率。
这就要求部门经理抛开人的问题，只在技术工程的层面找问题。
04
工作流的问题在于找到瓶颈
虽然中国的高层领导中，工程师出身的人特别多，但这只是因为理工科出身的人比文科生听话好管，整个工作文化、管理文化呈现出深厚的 " 道德倾向 "，强调人的主动性，无视技术性的因素。
而工作流的优化首先应该抛开人的能力问题，回归技术问题和工程问题。
原因在于，工作流的根本问题不在于人，任何部门都有一些瓶颈环节，以现有的技术水平，不管是砸钱还是加人，都无法提高效率，人的能力也有问题，但不是根本问题。
这个瓶颈环节前的工作，大量被积压；这个瓶颈环节后的员工，没有足够工作量，又得假装工作，反而干扰了其他环节的正常工作。
工作流的优化应该围绕这个瓶颈环节，提高工作流的通过效率：
1、尝试瓶颈前置
类似于 " 以产控销 "，把效率最低的瓶颈环节放在第一位，以约束非瓶颈环节的无效工作，来控制整个工作流程的成本，类似丰田生产方式中的 " 看板管理 "。
把效率最高环节的效率降下来，只是一个 " 控制成本 " 的权宜之计，而治本之道，仍然是要在无法提升 " 瓶颈部门 " 产能的情况下，提高 " 通过瓶颈 " 的效率。
一条大马路的 " 通行效率 " 通常低于总宽度相同的几条小马路，后者可以让司机有通过选择权，所以对瓶颈环节改造最好的方法是 " 切碎 "。
2、对瓶颈环节设计各种分流方案
比如把品控等环节前置，业务早期大部分都是无效的咨询、方案，但每一件都要按流程走到它的 " 终点 "，这些无效业务同样耗用了 " 瓶颈环节 " 的工作时间，把品控等环节前置，或两次品控，虽然增加了运营成本，但好处是降低了瓶颈环节的 " 无效业务流量 "。
比如按业务紧急程度分流。
工厂的订单一般都不是先来后到的，而是分紧急程度，让有些订单 " 插队 "，但大部分公司的业务往往没有这个紧急度评估的常规环节，这就导致一个人连夜加班赶出来的工作成果，却在下一个环节的同事的电脑里睡了一个礼拜的大觉，而他在做一件对他而言很紧急，但对公司而言却一点也不急的事。最后，客户催得急的业务还在走流程，客户没那么急的业务已经完成了。
只是这个分类不光要看紧急程度，也要看是否需要经过瓶颈环节，不需要进入 " 瓶颈环节 " 的，正常处理；需要进入 " 瓶颈环节 " 的，按紧急程度分类，保证 " 最紧急的任务 " 优先通过 " 瓶颈环节 "。
只要能从业务流的角度观察，类似的方法还有很多，虽然都是小修小补，但在无法改变瓶颈的情况下，累加在一起也可以大大提高整体的效率。
当然，以上方法都有一个问题，都是需要人来进行主观判断的，这就涉及到一个问题，谁来判断？谁有权决策？授权的范围是什么？
首先，这个人不可能是部门经理，他管不了那么细。
所以说，流程优化虽然是一个技术工程，但归根到底还是用人的问题。
05
" 业务发动机 " 员工
适合承担这个角色的，就是职场上被视为 " 发动机 " 的团队成员，他们职位不高，却常常成为 " 工作流 " 的推动者，他们关注结果，注重沟通，愿意承担责任并且为之付出。
因为具备未来管理者的潜力，这一类员工未来也更有机会在企业脱颖而出。
有一个公式：团队业绩 = 成员能力 + 人岗匹配 + 协同工作。
从积极的一面讲，" 协同工作 " 可以比单打独斗创造更高的效益，是一个 " 正和博弈 "，所以人人离不开团队合作。
但员工真正到了业绩评估时才发现，" 团队配合 " 只是其中的一项，而且很难评估，主要还是看 " 成员能力 "。所谓的 " 团队配合 " 是指在团队配合中突出个人的作用，所谓的 " 协同绩效 " 是指利用团队资源实现自己的业绩。
一位员工平衡团队配合与个人工作能力的关系，是评估适合的 " 业务发动机 " 人选的主要依据。
大公司竞争激烈，小圈子众多，太过循规蹈矩的员工，常常因缺乏关注而丧失晋升机会；而个人能力强的人，通常内心只相信自己的判断；但作为团队的一员，又要学会掩饰自己的竞争本能。为了实现自己的想法，在努力影响其他成员，说服团队的同时，也要付出必要的妥协。
" 团队协作 " 能力强者在 " 非管理者 " 中有下面的特征：
善于活跃团队气氛，善于发现团队其他成员的长处；
在沟通中，聚集共同目标、有建设性的解决方案，不做无益争论；
能够跳出团队，找到解决问题的关键人物，也能与公司高层沟通，巧妙地运用这些外部力量，完成团队的目标……
" 团队意识 " 不是什么高尚的品德，而是一个人身处优秀企业时的一种目光长远的理性选择，是在自己还没有成为团队领导者的时候，证实自己潜者力的好方法。
换句话说，部门经理在自己设想的工作流程优化方案，却找不到合适的 " 发动机 " 员工时，首先要思考一件事：你的企业对于员工而言，是否值得为之延迟满足的付出。（本文完）
不懂汇报，工作等于白做
标签：
