先搭组织架构，还是先理清权责

一个反复出现的现象

企业花了大力气重画组织架构图：部门合并、层级压缩、汇报关系理顺。新架构宣布三个月后，跨部门的事情还是要在老板那里拍板，会还是开不完。

原因通常不是架构画错了，而是架构往前走了，权责没跟上。部门改了名字，但一件事由谁提出、谁决策、谁执行、谁验收，没有重新约定。

组织架构回答的是"谁管谁"，权责流程回答的是"一件事怎么交接完"。前者是静态归属，后者是动态运行。

如果先把架构定死，再往里补权责，就只能让流程去迁就既有的部门边界——而部门边界往往是历史形成的，并不一定贴合当前的业务流。结果是流程绕着部门走，而不是部门服务于业务。

更稳的做法是先画出业务的真实流向，再依据流向对暴露的问题做权衡取舍。具体而言：

从客户提出需求开始，到交付收款结束，把所有环节按实际发生的顺序列出来，标出每个环节的当前负责部门。

标出跨部门的交接点。这些点上出现的等待、返工、扯不清楚，就是权责需要定义的位置。

对每个接口明确：谁有权拍板、谁提供意见、谁只需被告知。一件事情上只能有一个拍板的人。

依据业务流显露出的不合理设计做调整，此时调整都有明确的改进理由，不再是无依据的翻牌。

不是所有事情都要逐条规定。真正值得写清楚的是下面四类——它们占了日常推诿的绝大多数：

也有例外。如果企业当下的主要障碍是层级过多造成的响应迟缓（比如一个审批要过五道手），或者明显因人设岗导致资源分散，那么可以先做结构性调整，把层级压缩到合理范围，再回去补权责。

判断标准：如果把某个中间层级拿掉，业务运转会不会明显出问题。答案是"基本不会"，说明这个层级的存在本身就需要重新审视。

组织是给别人看的图，权责是自己用的表。先看懂一件事是怎么跑完的，再去决定人怎么摆——这个顺序省下来的，是之后无数次协调会的时间。