6个月，4次返工，500万成本：老板怒拆部门墙！
叶小钗约 14 分钟关注公众号回复1，加我微信
这是管理课程《揭秘公司治理框架》的第四章《机制的顶层设计——高管》、第五节《组织架构与PMO体系》
前情回顾：
第一节我们介绍了高管的评价模型及其重要的六件事； 第二、三、四节，我们介绍了最为重要的三件工作：信息通道建设、文化建设、上升通道建设；
而无论是信息的传递，还是任务的评价，都是依赖于组织架构运转的，所以我们今天的重点是组织架构与PMO体系。
组织架构的本质
公司存在的意义是通过管理确保团队高效完成任务，但随着目标复杂化和团队规模扩大，效率往往下降。
公司问题的根源在于目标难度和组织规模，精英人才的加入导致理念不合、派系斗争、资源争夺等问题，且团队规模扩大引发沟通误解、信息失真等信息问题。
此外，人才种类多样化使得评价机制失效，难以准确评估专业人才的贡献。
大公司的问题
以上问题很常见，比如1998年9月20日， IBM顾问向任正非阐述了对华为管理问题的十大诊断：
一、缺乏准确、前瞻的客户需求关注，反复做无用功，浪费资源，造成高成本； 二、没有跨部门的结构化流程，各部门都有自己的流程，但部门流程之间是靠人工衔接，运作过程被割裂； 三、组织上存在本位主义，部门墙高耸，各自为政，造成内耗； 四、专业技能不足，作业不规范； 五、依赖个人英雄，而且这些英雄难以复制； 六、项目计划无效且实施混乱，无变更控制，版本泛滥
其实华为的问题总结下来也就两个事：
规模扩张引起的管理掌控力下降、跨部门协作难度指数级上升； 专业瓶颈导致的难度；
组织架构的目的
综上，两个因素制约了团队发展：
专业壁垒导致的瓶颈：没办法拿到员工的真实评价； 规模大了导致的失控：信息传递因客观原因出问题了；
其实只要能客观的评价每个人，那么派系问题可以得到很好的缓解。
而组织架构的出现只有一个目标：最求最高人效比，全局最优。
执行力三要素分别是：能力、信息、意愿，意愿对应着公司的奖励机制，也就是员工的上升通道建设，而上升通道的本质又会回到员工在公司客观评价问题。
员工能力是可面试的，但能力高并不等于产出高，如何在复杂的系统里面客观的评价员工，特别是专业向员工，这会变得很重要。
因为，没有客观评价，奖励就到不了正确的地方，那只能引起进一步雪崩。
所以组织架构，他真实要解决的问题是两个：
第一是公司信息传递问题； 第二是公司体系员工的客观评价问题；
因为所有的公司动作，全部会围绕着组织架构产生，接下来我们一一拆解。
组织架构：信息与评价问题
前面我们说过信息是战略与执行的载体，其流动直接影响效率。
随着组织规模扩大，信息在上下传递中易失真：向上时被美化压缩，向下时因利益扩散变形。
层级越多，信息失真越严重，最终导致决策与执行偏差，因此，扁平化架构能减少传递层级，降低信息失真，提升沟通与决策效率。
上述问题我们在信息通道建设做了深入探讨，这里重点讨论评价问题
首先，专业不一致带来的误解与冲突，其本质也是一种信息差，难以评价是公司管理困难的第二个根源性问题，这里回到那个经典案例：
线上有个BUG，前端和后端各自认为是对方的问题，互不相让。
10分钟的事拖了一个小时，最终双方Leader介入，为组员争辩，导致一个简单问题耗费了一整天。
上述案例在每个公司都经常发生，导致这个问题的根源是：对专业员工任务的难以评价。
就比如这个BUG，到底是前端的BUG，还是后端的BUG是非常难以界定的，他就像平衡木的两端，坐哪边都不对。
而且BUG涉及惩罚，所有人都很敏感，这种问题就只能管理看情况处理，用机制、文化去规避。
实际工作中，可评价部分的工作占60%，还有40%是偏灰色、不好评价的部分，如何处理这40%不好评价就是管理最大的价值。
其次，所有的专业类工种，一方面会有很多基建需求，另一方面他们会有一个上升阶梯，所以站在评价、建设、培养的角度，这里面弯弯绕绕很多，外行很难看明白。
所以在组织架构上，专业类一般会被聚焦在一起，方便资源最大化。
至此，我们可以得出企业组织架构的目的与需要解决的问题了：
目的：人效最高； 问题：信息效率以及公正评价；
到这里，我们再一起来解析几个经典组织架构，大家会变得更清晰。
三种常见组织架构
一、职能线
在这个架构下，项目多由上游部门发起，产品、技术承接，最后交互运营。
这个架构的优势很清晰：
各个部门会十分重视自己的基础建设； 团队上升通道清晰，凝聚力较强； 各种培训体系会比较健全，员工专业能力方面可以得到保证； 部门内人员调配比较灵活；
总结下来就一句：这是更关注长期建设的组织结构，适合做基建，提升员工能力，适合50人左右的团队。
比如技术部门50人以内，就特别适合这个架构。
二、项目线
随着团队人数增多，公司达到500人、部门达到100人的时候，上述架构的问题会逐渐暴露，以技术部门为例：
因为部门人数过百，技术老大开始无力关注所有项目； 部门依旧更关注专业技能提升，多数情况项目虽然能得到及时的完成，但是整体部门表现出对业务不太关注的态度，进一步因项目认知不足而产生一系列考虑不充分而需要返工的浪费问题； 部门内的技术基建项目与业务项目难以很好的区分，公司会认为技术部门过多关注技术基建，而且技术也说不清楚技术基建的价值； 项目多了后，不太吃香的项目（脏活累活、技术含金量低）开始被嫌弃，可能得不到很好的支持，而技术部门嘴特别硬，上下游矛盾加大； ......
整体来说就是，技术建设依旧好，但是业务项目推动不足，这会导致上游部门极其不满。
在这个基础上，公司会引导组织结构往项目型发展：
这个架构的优点非常清晰：
项目所需资源得到了绝对的满足，项目推进速度会有基础保障； 项目积累包括项目管理方法论、项目文档等都得到了很大加强；
相对着，缺点也非常清晰：
项目经理领地意识很强，宁愿团队空转也不会释放资源给其他项目组，他们会最大限度的保证自己的项目成功； 多数项目是临时性项目，一旦项目结束，项目经理倒是可以带新的项目，但员工就不好处理了； 又因为项目经理不会关注基建，他们会将员工当干电池使用，项目可能是成功了，但团队梯队却坏掉了； 长此以往，员工首先在专业性上没有期待，其次会担心基本的生存情况，这种既没有生存权又没有发展权的状态，难以持久； 最后，项目经理更关注个人成功，项目间的资源共享或信息传递会有很大问题；
总结下来就一句：更专注眼前，拿到目标，忽视长期。
并且项目经理很难对所有工种进行专业上的评价和帮助，真实执行起来项目风险还是不小；多数员工会感受到自己是执行项目的机器，项目组氛围会很差。
所以，这种人效低、杀鸡取卵的架构，公司见势不妙又会在这个基础上提出矩阵架构。
三、矩阵线
这个架构的优点很清晰：
既兼顾了公司基建，又兼顾了项目目标； 当遇到专业性问题的时候，项目组员可以直接求助专业线Leader；
但缺点也很清晰：项目组员有两个Leader，这会让其迷糊。
而且这个架构最大的问题是如何考核，这里表面是考核问题，其本质是职能线Leader与项目线Leader的资源与权利之争。
而这里权力之争的核心是什么，我们继续衍生。
评价=权利
家庭是最小单元的团队，按理说应该亲密无间，但有了孩子后，许多家庭却陷入婆媳矛盾的漩涡。原因何在？答案是评价权。
在家庭中，丈夫、妻子、婆婆之间难以互相评价，唯一能被评价的往往是孩子。于是，谁掌握了孩子的评价权，谁就掌握了家庭的话语权。
评价权不仅能衍生出更多评价行为，还能通过不断发酵，形成权力博弈。
因为其特点是：弱势评价屈服于强势评价。
例如，丈夫对妻子“懒惰”的行为的评价是弱势的，而妻子对丈夫因工作忽视孩子的评价则是强势的。一旦丈夫试图批评妻子，往往会遭到“不管孩子”的反击，甚至翻出旧账。
结果，妻子掌握了家庭的核心评价权。
争夺评价权的本质是：评价意味着规则的解释权，其背后是博弈空间的争夺。
但并非所有问题都值得争夺评价权。例如：孩子挑食、光脚走路等问题，很容易达成一致，有明确的“标准”；
而孩子拖沓、饮食选择、衣物清洗等问题，因缺乏统一标准，往往成为评价权争夺的战场。
综上，缺乏标准的地方，正是评价权争夺的核心。
站在员工角度，工作可分为两类：确定性任务与不确定性任务。
确定性任务即：目标明确，标准清晰，过程可以量化或用固定流程完成的任务。比如生产线工人、客服人员、行政岗位等。
不确定性任务即：涉及创意、决策或需要在灰色地带处理问题，难以直接量化或拥有明确标准的任务。比如项目经理、产品经理、研发人员、高管等。
不确定性任务的好坏很难评价，这极大的依赖于经验与专业性。
所以，管理的价值也就在此：管理更多是在管理不确定性
也就是在不确定性中尽量提出客观的评价
其次，这也造成了两个现象：
岗位工作要求的不确定性越高，其公司定价越高； 不确定性越高的岗位，其对忠诚度的要求越高；
HR团队的意义
回归公司场景，公司里面有个岗位其实是很神奇的，因为他完全是游离于问题之外的一个组织，其名称为：HR。
如前所述，公司场景下，最根源的问题之一是：客观评价问题。
为什么很多事情都在扯皮，那是因为那些事情都有一定专业性，其中存在壁垒、存在信息差、存在权衡利弊。
这意味着这些事情没有标准，里面有很多可解释空间。
但无论从专业角度还是从业务深入参与角度，HR在这些事件里面可以说都是毫无存在感的！
于是这里奇怪的点就出现了：在职责上，他们竟然具有对各部门评价的权利，这里的逻辑是什么呢？
逻辑很简单：监察，更进一步是第三方监督，公司担心部门人为引起信息差、滥用资源。
因为只要有解释空间存在，就意味着可操控、可被影响，那么这种评价传递上去，就很可能是失真的结果，这会进一步引起：
项目风险避重就轻，或直接隐瞒上报； 问题员工不被批评，甚至得到奖励； 最终当然是大量资源浪费，公司人效降低；
只不过因为HR确实难以起到三方监督的作用，所以在公司大了后，整个组织架构很容易走向矩阵式架构，或者在这个阶段引入PMO体系。
PMO体系
就有效评价来说，职能线架构必定是最优解，只不过他很容易引起部门墙。比如以下案例：
针对一个临时的项目难点，1部门提出A方案，需要2部门执行； 2部门提出更优的B方案，需要3部门执行； 3部门提出更优的C方案，需要1部门执行； 1部门又搞出了最简单的D方案，需要几个部门一起各自完成其中一部分； 下面的专家都闹起来了，为啥我的方案不被采纳，而且其他部门老甩锅给我。
销售有意见了，为啥进度那么慢。各部门也有理由：我方案出来了，没人听我的，都在说按我方案来事情早做完了。
于是怎么办呢？PMO体系在这个阶段会被提出。
经济学十大原理：政府有时可以改善市场结果。
部门墙源于本位主义，靠部门负责人的胸怀格局很难避免，这个时候一定要有更上层组织出现，避免“公地悲剧”的出现。
对于项目负责人来说，在职能型组织，是很蛋疼的，因为权力都在职能部门老大手里，他首先调动不了资源，其次对项目人员没有考核权。
这里的结果就是项目进度变得不可控，但这又符合逻辑：
职能线在员工专业力积累上绝对优于项目制，企业初期采用职能线有助于员工归属感和成长感。但随着规模扩大，单一职能线会导致技术员工只关注专业，忽视业务，进而影响项目执行。
而且专业职能线负责人很容易将部门做成自己的“后花园”，“拥兵自重”，大家长式的管理方式，容易造成很多黑盒。
黑盒得不到关注，就得不到客观的评价，久而久之，必将导致冗余与巨大浪费，这时候PMO体系就出现了：
什么是PMO
PMO(Project Management Office)项目管理办公室。
核心职责是定义和维护项目管理标准，确保项目的成功实施。
PMO承担的职责可能包括项目治理、项目协调、资源管理、风险管理、质量控制以及提供项目工具和模板等。
其实，PMO在不同阶段，其意义是不一样的，比如下面所述：
项目标准化：建立项目管理的最佳实践和标准。 项目支持：为项目经理和团队提供培训、工具和方法支持。 项目监督：监控和评估项目进展，确保项目符合既定的目标、时间表和预算。 资源管理：协调和分配项目资源，包括人力、财力和物资。 风险管理：识别、评估和管理项目风险。
PMO的核心确实是项目管理，但项目管理不是PMO的精髓。
PMO体系其实是一种变革方式
所有不涉及奖励机制与评价体系变化的PMO体系，都是项目管理方法论的知识应用，仅此而已。
所以，PMO这个部门，在不同公司，有不一样的“地位”：
PMO知识传递，一些公司仅仅PM需要一个组织负责做项目管理相关知识培训即可； 辅助类PMO，一些公司仅仅PM需要一个组织辅助职能线一号位做好项目管理即可，他们主要工作是打杂，比如协调、文档书写、组织会议； 主导类PMO，一些公司PM拥有组员部分考核权，直接对项目成败负责；
除了常规的项目管理，以上的核心差别就是：PM（项目负责人）是否具有考核权。
考察一个公司PMO的建设情况可以简单由此着手：
PM是否具有其他部门员工的考核权； 整个基于项目的考核体系是不是合理，项目负责人与职能线负责人考核权的占比是多少； 是否有完善的PMO体系方法论（项目管理、复盘、考核，三位一体）； 是否有完善的工具支撑；
部门墙与PMO体系
PMO体系的诞生，其实是为了解决部门墙问题。
要建立完整的PMO体系，一定要从考核权着手，涉及考核就涉及公司利益重塑
所以说：PMO体系的建立，是一次企业的自我变革
OKR体系与PMO体系
很多公司其实在用OKR体系在进行项目管理。但每当我询问，是否用OKR的结果进行考核的时候，对方又给出了否定的答案。
当我进一步问他们用什么作为考核时候，他们又会回到胜任力（专业能力）。
最后询问OKR的意义时候，他们多会反馈，会重点参考OKR的执行考核！
所以，他们就是在用OKR结果进行考核，只不过OKR官方文章一直在反对直接用于考核，所以有些掩耳盗铃，毕竟员工80%的精力都在执行OKR，不用他的结果考核，用什么...
其实，OKR体系与PMO体系，都可以归类到由考核员工专业能力到关注员工项目执行情况的变革方式。
这没什么区别，甚至可以认为OKR体系就是一种PMO体系。
PMO与组织结构
完整的PMO体系的是一场企业变革。变革是要重新分配利益的，其一定是企业一号位工程。
所以从汇报关系来说，这个组织负责人一定要汇报给CEO，甚至由VP或者CXO牵头执行。
PMO体系其核心为评价份额的再分配，这个再分配其实不是要把职能线Leader将死。
因为职能线Leader也会成为项目负责人，他同时也拥有了考核其他部门员工的权利。
站在大型跨部门项目来说，这是一次重大的进步，而对于原Leader来说，却不一定是削弱。
所以，PMO体系的初期推动可能会受到阻碍，但沟通得宜其实也还好，除非强烈反对者，本身之前就是个大地主。
下面给一个简单的考核案例参考。
考核案例
公司推出了一个新的跨部门项目，旨在开发一款移动应用，从设计、开发到测试和上线，项目周期为6个月。
项目考核权重设定
项目负责人（PM）：70% 职能线Leader：30%
开发Leader：10% 测试Leader：10% 设计Leader：10%
CEO对项目整体评价：9.0（满分为10）
项目负责人（PM）：王鹏的评分（满分100）
李明：85 王伟：80 赵丽：90 周敏：85 孙婷：88
职能线Leader评分（满分100）
开发Leader（李华）的评分：
李明：80 王伟：75
测试Leader（张强）的评分：
赵丽：88 周敏：82
设计Leader（陈芳）的评分：
孙婷：90
最终考核得分计算
结语
组织架构与PMO体系的核心目标始终围绕着解决信息传递与员工评价这两大难题。
随着企业规模的扩展，专业壁垒和规模失控成为制约团队发展的关键因素，专业壁垒导致评价困难，而规模失控则引发信息传递的失真。
PMO体系的引入，本质上是矩阵式架构的延伸，旨在通过重新分配考核权，打破部门间的利益格局，促进信息高效流动和员工的客观评价。
部门墙，某种程度上源于专业评价需求的必然产物。
不同专业领域的员工在评价标准上存在天然的信息差，这种差异往往导致部门间的隔阂与协作障碍。
通过PMO体系的建设，企业可以在保持专业职能线的同时，打破壁垒，增强跨部门协作，确保项目高效执行。
综上，相信大家对于组织架构的深层含义有了更清晰的认识，今天的内容就到这。