乐于分享
好东西不私藏

很多公司说自己扁平,AI 一进来就露馅

很多公司说自己扁平,AI 一进来就露馅

很多公司都喜欢说自己管理扁平。

老板办公室门一直开着。

员工有事可以直接找老板。

群里沟通也很快。

部门之间看起来没那么多层级。

但真到一件具体事情上,情况经常不是这样。

一个客户急着要报价。

销售在群里问价格。

技术说配置要确认。

采购说库存要看一下。

财务提醒这个客户回款慢。

老板最后来一句:

“先按之前那个方案走。”

表面上,大家都在一个群里,沟通很扁平。

但真正的决策还是要等老板。

谁能定价?

谁能判断风险?

谁能决定要不要给折扣?

谁负责把这次报价规则沉淀下来?

这些问题没人说清。

这就不是扁平。

这只是把层级藏进了微信群。

伪扁平最怕 AI 进来

以前这种组织方式还能凑合。

因为人会猜。

老销售知道老板话里的意思。

技术知道哪些问题最好别多说。

财务知道哪些客户要盯紧。

采购知道哪类库存截图发出来就行。

很多规则不写出来,也能靠熟人关系跑下去。

但 AI 进来以后,这些隐性规则就会暴露。

AI 不知道“按之前那个方案走”到底是哪一个方案。

不知道“这个客户比较特殊”特殊在哪里。

不知道“先给个优惠”能优惠到什么程度。

也不知道“你看着办”到底是谁负责。

它可以帮你整理聊天。

可以帮你生成报价说明。

可以帮你把会议纪要写得很完整。

但只要决策权、责任边界和沉淀位置不清楚,AI 还是进不了真正的流程。

它只能在外围打转。

真扁平不是少几个领导,而是规则能不能说清楚

很多人理解扁平,容易理解成“少几层领导”。

但我在企业现场看到的情况是:

层级少,不一定扁平。

如果所有事情最后都要等老板拍板,那组织一点也不扁平。

只是审批路径从系统里搬到了微信里。

真扁平不是谁都能说话。

而是常见事情有清楚规则。

谁可以定价。

谁可以给折扣。

谁可以承诺交期。

谁负责升级异常。

谁把结果记录下来。

这些规则清楚以后,团队才不用每件事都往老板那里挤。

AI 也才知道自己该读什么、提醒谁、把结果写到哪里。

否则,所谓扁平只是在好听的时候扁平。

一到责任和决策,就又回到“领导说了算”。

这也是很多数字化系统失败的老问题

以前上系统时,这个问题就已经出现过。

公司说要流程透明。

结果系统里设计了审批流,员工还是先在微信里问领导:

“这个我能不能提?”

公司说要数据沉淀。

结果关键判断还是写在聊天里,系统里只补一个结果。

公司说要协同办公。

结果真正有冲突的时候,还是要等老板在群里拍板。

最后系统变成一个补记录的地方。

AI 现在也会遇到同样的问题。

如果企业只是把 AI 接进群里,让它总结、提醒、生成材料,但真正的权责关系没变,它也会变成一个更聪明的记录员。

看起来很忙。

但没有改变组织怎么运转。

后来看书时,我想到了“伪扁平”这个词

最近读《超级组织》时,有一处讲到组织结构和协作方式,我马上想到很多企业所谓的扁平管理。

我自己的判断是:

很多企业不是不想扁平。

而是只做到了沟通扁平,没有做到决策扁平。

大家可以在一个群里说话。

但谁能做决定,谁承担结果,谁沉淀规则,仍然没有变。

AI 进入以后,这个问题会更明显。

因为 AI 不靠人情理解组织。

它靠规则、资料、上下文和任务状态工作。

如果组织表面扁平,实际权责模糊,AI 只会不断碰到墙。

不要先问 AI 能不能自动推进

现在很多人谈 AI 协作,很容易问:

能不能自动派任务?

能不能自动提醒?

能不能自动推进流程?

这些问题当然重要。

但在伪扁平组织里,我会先问另一个问题:

这件事现在人能不能不用问老板就推进?

如果人都不能,AI 也很难。

因为 AI 自动推进的前提,是组织已经把规则讲清楚。

哪些事可以直接处理。

哪些事必须升级。

哪些事需要老板拍板。

哪些事只需要记录。

哪些事处理完以后要复盘。

这些边界不清,自动化越多,越容易制造新的混乱。

企业管理者今天可以先做一个小检查。

找一条最常见的流程,比如报价、售后、请款、项目延期。

然后问团队:

这件事在什么情况下不需要老板确认?

什么情况下必须升级?

谁有权做决定?

决定之后记录在哪里?

下次类似情况能不能直接复用?

如果这些问题答不出来,先别急着说自己扁平。

也别急着让 AI 自动推进。

先把权责和规则写清楚。

扁平不是少几层汇报关系。

扁平是让常见事情不用每次都重新请示。

如果你也在思考 AI 进入组织以后会暴露哪些问题,可以去看看中信出版的《超级组织》。

适合一边读,一边对照自己公司那些“看起来很扁平,其实全靠老板兜底”的流程。


如果你也在思考:在变化快、事情多、信息又杂的环境里,个人或团队,怎样把事情一步步坐稳,不返工、不翻车,几年后还能用得上,那我们关注的,其实是同一个问题。
这些年在一线项目中反复踩坑后,我逐渐把一些“容易出问题的地方”和“更稳的做法”,整理成了一套可以反复使用的判断与结构也写进了书和方法论里。

更多数字化转型内容在 

我是 石巍|Will
企业数字化顾问

长期参与制造、测试、交付相关的一线项目,见过不少团队系统没少上、流程没少改,但问题依旧反复出现的场景。

后来我才意识到,很多问题不是工具不行,而是顺序错了、风险被放到了后面。围绕这些反复出现的问题,我把经验整理成了 Script-as-Test(测试资产前置)模型并在《Jira Consulting 101》以及 ObAsset《从混乱到结构》体系中持续迭代。

我不做“只卖工具或设备”的方案,更关注事情怎么做,才不返工、不翻车、还能长期复用