摘要：作为管理者，每次月度经营会上，你一定听过老板或上级说过这样的话：我们要横向拉通、我们要跨部门协同、我们要打破部门墙、我们要跨团队作战等等。
01
你天天强调横向拉通
为何跨部门之间冲突不断
作为管理者，每次月度经营会上，你一定听过老板或上级说过这样的话：我们要横向拉通、我们要跨部门协同、我们要打破部门墙、我们要跨团队作战等等。
然而，事与愿违，实际情况却常常是：
市场部说产品部配合不及时；产品部说技术部资源不给力；技术部说销售乱承诺，需求无底线；销售部门说支持部门太官僚，扯皮严重；各自都有理，各自都在忙，但想要的结果就是没达成等等。更常见的情况是：在会上，明明大家都已经达成共识了，但一到执行环节，还是各做各的。遇到问题就推，遇到分歧就扯，就算是发现了项目的坑。也绝不事先提醒和告知其他部门，直到对方踩坑，依然是一副“与我何干”的样子。
强调了半天，横向拉通依然遥遥无期。
为什么会这样？真相是：你以为“横向拉通”靠的是态度，其实是要靠机制。
靠嘴说、靠会议讲、靠领导盯，横向拉通根本不可能。
如果没有机制，没有共识，没有配套的组织体系设计，再多的“横向拉通”口号，也都是空谈。
之所以这么讲，是因为我们发现了跨部门之间横向拉通失败的3个原因。
02
横向协同失败的三大根因：
不是态度问题，而是系统问题
在企业调研中，我们发现，很多企业跨部门之间横向拉通失败，看起来好像是部门与部门之间相互不配合，但真正的底层原因在于部门之间的系统性障碍没有被解决。这主要体现在三个层面：
1、指标不一致：KPI打架，协同只会内耗
事实上，很多企业部门之间的KPI指标设计，从一开始就埋下了冲突的种子。比如：
销售部门往往会盯着签单，而法务部门最要紧的KPI则是合规与风险最小；研发部门往往会看重创新，而交付部门最看重的是快速交付与服务满意度；
生产部门往往会看重成本和效率，而质检部门最看重的则是质量与标准等等。
尽管大家的KPI最终都会在公司目标层面达成一致，然而，大多数情况下，大家还是先紧着自己部门的KPI
从人性的角度讲，这其实很正常。只不过，当每个部门都优先考虑自己部门的KPI的时候，所谓横向拉通必然失败，冲突和“打架”就成了常态。
这不是态度问题，这是机制问题。
2、职责不清晰：协同边界模糊，没人愿意背锅
按说，公司早就有了各部门的职责分工，本不该出现横向拉通拉通的问题。然而，再明确的职责分工，也赶不上外部市场环境的变化。尤其是当行业进入内卷，技术变化万千，客户需求总不“靠谱”的时候，“灰色地带”就成为跨部门之间的常态，到底谁负责，就成为一个棘手但必须马上解决的问题。比如：
需求变更到底谁拍板？产品部门还是客户部门；项目延期是交付的问题，还是支持部门不给力；报价方案被客户吐槽，是销售的问题，还是需求信息不对称等等。现实中，每个部门几乎都能“自证清白”，然而，到底该谁负责，往往存在巨大的争议。最终，要么靠上级的权威，“强迫”某部门来负责，要么陷入相互推诿的恶性循环，最终无人解决问题。
这不是能力不够，而是机制不明。
3、节奏不同步：步调不一致，好事也搞砸
有人问，如果KPI一致、职责清晰，是不是横向拉通就没问题？
当然不是。即便是指标一致、职责清晰，各部门之间也会因为“节奏不同步”问题导致协同失败。比如：
前端签了客户，但后端还没准备好方案；运营部门要上线市场活动，但技术部门压根还没排期；刚给客户进行完系统培训，产品就推了大版本更新等等。有时一线业务部门跑的快，而中后台支持部门却掉了链子；有时支持部门提前规划行动，但一线业务部门却不领情，最后大家都觉得“对方不靠谱”。
其实，这也不是配合不够，而是机制不匹配。
那么，什么样的机制，能促进跨部门之间的横向拉通？
03
不是不想做横向拉通
而是机制没有设计好
事实上，很多时候，企业各部门之间的横向拉通问题并非出于意愿度，而是因为企业没有设计好“横向拉通机制”。
什么叫横向拉通机制？
就是能让跨部门之间的项目协同、任务安排能够更顺畅运行起来的机制安排。一般包括共同目标、统一节奏、权责分配、资源协调等在内的一整套机制体系。它至少具备3点：
1、是共识机制，而非命令机制
不是谁要做决定，而是各部门要基于同一个目标、同一套逻辑做判断、做决策。
最典型的机制是OKR（Objectives and Key Results），各部门先构建统一目标和节奏，然后才是基于统一目标的分工与协作。目标是一致的，分共是明确的，逻辑和原则是清晰的，遇到问题很好解决，因为有共识机制存在。
2、是角色机制，而非救火机制
在跨部门协作过程中，尤其是重要项目和任务，在每个协同环节，都要明确：
谁是责任人（Owner）；谁是支持人（Support）；谁有否决权（Decision Maker）；谁是被告知者（Informed）。在项目管理领域，RACI责任分配矩阵（Responsibility Assignment Matrix）也是经常被应用的责任识别与分配工具，通过以下4个角色定义，来尽可能划清责任边界。包括：
R（Responsible）责任者：即负责执行任务的角色，他负责具体项目操控项目，解决问题；A（Accountable）决策者：即对任务负全责的角色，只有经过他同意或签署之后，项目才能得以进行；
C（Consulted）被咨询者：即拥有完成项目所需的信息或能力的人员；
I（Informed）被通知者：即应被及时通知结果的人员，但一般不必向他咨询或征集意见等。
有了RACI模型，跨部门之间至少有了责任（角色）分工，扯皮的事就会少很多。
3、是事前对齐机制，而非事后救场机制
跨部门之间真正高效的协同与拉通，是用机制做到“事前对齐”，而不是“事后救场”。比如：
每周的协同项目会；每月的OKR Review会议；每个版本上线前的协同预演；每一次战略目标变更的同步机制等等。不是出了问题才去拉通，而是在机制里就“自动对齐”，这才是横向拉通的关键。
04
他山之石：
优秀企业是如何做的
案例1：腾讯“作战室机制”
腾讯曾在多个战略项目中，采用“作战室”形式打破部门墙。
一个跨部门协作项目（如微信支付推广），会临时组建“作战室”，成员包括产品、市场、运营、技术等部门关键人员，按项目目标挂钩OKR与激励机制，并配备独立资源和通道。
机制亮点：
临时组织独立权责，打破原部门“本位主义”；项目与绩效强绑定，协同不再是“搭把手”；高频同步机制，确保各部门信息流统一。最终，不靠“喊口号”，靠机制达成协同闭环。
案例2：特斯拉的“软件-硬件一体化开发机制”
在传统汽车公司中，硬件工程团队与软件研发团队往往各自为战，导致产品开发周期长、体验割裂、协同困难。而特斯拉则彻底打破了这种“前后台割裂”的旧模式，推动软件与硬件的“共创机制”。
在FSD（自动驾驶）开发过程中，特斯拉组建了跨部门研发团队，包括芯片设计、电机控制、传感器算法、整车架构、AI视觉等多个岗位，所有人围绕“功能上线”这一目标展开并行工作。
机制亮点：
软件、硬件、算法团队协同并进，打通开发节奏；工程师直接参与问题闭环，减少层级沟通；将版本迭代机制嵌入整车更新，实现全链路高效协同。特斯拉的这种组织架构，早已超越了传统“功能部门制”，转而采用“项目中心制”，本质上是一种机制性协同能力的构建。
案例3：苹果的“横向职责矩阵”
在乔布斯之后，苹果没有沿用传统的事业部制，而是保留了其“功能型组织”结构，但在核心产品项目中，建立了强力的横向协同机制。
以iPhone为例，每一代产品从设计、芯片、系统、交互、销售到宣传，都由来自不同职能团队的核心成员组成项目组，每个人同时对自己的部门主管和项目负责人负责，职责“矩阵式”交叉。
机制亮点：
职能归属明确，但在项目中横向协同紧密；项目经理权责清晰，拥有调配资源的“临时指挥权”；所有关键评审节点定期同步，推进节奏高度一致等等。这种“统一的职责体系+项目驱动的协同机制”，使得苹果能够持续推出高完成度、跨学科高度融合的产品。
05
实操指南：
5个动作构建跨部门横向拉通机制
作为管理者，你不能指望所有协同都靠自己盯，也不能把“拉通”当成口头禅。真正有效的协同管理，需要机制化设计。以下五个动作，可以帮助你实现跨部门横向拉通：
动作1：统一目标，拆解为跨部门的共赢KPI。比如：
不要让部门KPI打架，建立“共享指标”（如客户NPS、交付周期等）；以项目或业务线为单位，横向分解目标；或者用OKR系统将多个部门目标绑定成一个链条。动作2：设立跨部门项目Owner和RACI矩阵。比如：
所有跨部门任务设定明确Owner（最终负责人）；引入RACI机制（全文有介绍），分清每个人的角色；执行中落实责任人例会与节点评估。动作3：同步节奏，建立例行协同拉通机制。比如：
周会设专门协同模块，解决跨部门信息流问题；大项目设置“协同进展日报/周报”机制；每月召开横向Review会议，评估协作效率与问题。动作4：设计协同拉通流程接口和协议。比如：
类似API文档，协同双方应明确需求格式、输入内容、输出节点等；每项任务设定标准交付物与验收机制；对关键协同路径设置可追踪指标。动作5：将协同绩效纳入部门及个人考核。比如：
协同结果好坏，不是“额外加分项”，而是基础评分项；部门协作效率设为专项评价维度；优秀协同案例给予内部曝光与激励。组织越大，协同拉通越难。你要做的，不是再强调一万次“要协同”，而是把协同流程与机制做扎实。
你说呢？
来源：清新教育
