前面分享的一篇文章别再骂 IT 不行：你的数字化转型，根本没让业务对结果负责 | 如何彻底解决业务与 IT 的权责错位？
前面分享的一篇文章别再骂 IT 不行：你的数字化转型，根本没让业务对结果负责 | 如何彻底解决业务与 IT 的权责错位？多年来“业务牵头”的数字化转型始终落不了地，难道没人质疑这套思路从一开始就想当然、走不通？
其一，屁股决定脑袋，业务本位主义和部门墙本就是转型最大障碍，各业务条线各自为政，没人能站在全局统筹规划。
其二，数字化本质是变革，是打破职能分工、基于流程的业务与权责重构，没人愿意主动革自己的命。
其三，多数业务部门既不愿投入精力梳理，也没能力站在全局想清、提准真实需求，骑马的人，怎么可能摸透开车的逻辑？
其四，传统IT若不肯穿透业务，只会走向低端边缘化，脱离实际流程和应用场景的技术毫无价值。
老方法出不了新结果，唯有成立桥接业务与IT的流程或变革部门，才有可能破局，最终关键还是看顶层的认知与决心。
我仔细研读了该条留言，留言非常有水平，每一句都戳中了国内企业数字化转型的现实痛点。研读后，我的核心结论是：“业务牵头、IT 赋能” 从来不是想当然的理论，恰恰相反，绝大多数企业落不了地，根本不是方法错了，而是从一开始就理解错了、执行歪了 ， 把 “业务价值牵头” 做成了 “业务部门分头拍板”，把治理层面的顶层设计，做成了职能层面的分工甩锅。
01.
业务本位主义、部门墙，谁来总体筹划？
首先要纠正一个最普遍的误解：“业务牵头” ≠ “单个业务部门分头牵头”。很多人把这句话理解歪了：上 CRM 就让销售部自己定，上 MES 就让生产部自己拍，上 SRM 就让采购部自己说了算。这样搞下去，必然是各自为政、部门墙林立、烟囱系统遍地，这不是 “业务牵头”，是 “业务分权”，本质是顶层治理缺位。
第一层：经营层牵头
也就是老板、总经理、业务副总站在公司整体经营视角，定数字化的战略方向、优先级、资源分配，做全局筹划。这正是 ISO 38500 和 COBIT 里治理层（EDM 域）的核心职责 ， 全局统筹的人，从来就不该是中层业务部门，而必须是最高决策层。
第二层：业务部门担责
在全局方向已定的前提下，各业务部门对自己领域的业务结果、数据质量、落地推广负责。
很多企业落不下去，根源是顶层把本该自己担的全局筹划责任，直接甩给了中层业务部门，最后搞成 “各扫门前雪”，反过来骂 “业务牵头不行”。这不是方法的问题，是责任放错了位置。
02.
变革要革自己的命，谁愿意主动做？
所以 “业务牵头” 从来不是让业务部门自己发起革命、自己砍自己的权，而是治理层定变革方向，业务侧担落地责任，IT 侧做能力支撑。数字化转型的变革动力，永远不可能来自中层，必须来自顶层。流程重构、权责调整、利益再分配，这些事必须是董事会、总裁办拍板定调、强势推动，不可能指望某个部门负责人主动动自己的奶酪。是在既定的变革方向下，把业务流程跑通、把基础数据理准、把一线推广落地、把最终业务结果拿到 ， 而不是让业务自己决定 “要不要变革”。很多企业的闹剧就在于：老板自己不下定变革决心，不敢碰利益格局，把变革的锅全甩给业务部门和 IT 部门，最后推不动了，说一句 “业务不配合”“IT 能力差”。这本质是顶层逃避责任，和 “业务牵头” 这个方法本身无关。
03.
业务想不清楚需求，骑马的人想不出开车的需求
他们把 “业务牵头” 理解成了 “业务要把需求写得明明白白，IT 照着做就行”。业务牵头，牵的是 “业务目标和业务价值” 的头，绝不是 “系统功能细节” 的头。
骑马的人不需要懂怎么造车，他只要说清楚三件事：我要去哪里、要多快、拉多少货。对应到数字化里，就是：要解决什么业务痛点、要拿到什么量化结果、要支撑什么业务目标。而 “车怎么造、发动机怎么选、底盘怎么设计”，也就是系统功能怎么设计、技术方案怎么做，本来就是 IT 的专业职责。“IT 赋能” 的真正含义，从来不是被动等着业务喂需求，而是主动穿透业务场景，把业务模糊的痛点、朴素的目标，翻译成专业的系统需求和技术方案。很多企业搞反了：逼着业务写功能清单，IT 坐等需求上门，最后做出来东西不对味，互相指责。
04.
传统 IT 不穿透业务，只会死路一条
“业务牵头、IT 赋能” 本来就不是让 IT 当甩手掌柜、守着自己的技术一亩三分地，恰恰是对 IT 部门提出了更高的要求：不能只懂代码、懂服务器，必须懂业务流程、懂经营逻辑、懂一线场景。脱离业务的技术，没有任何价值。但这里必须划清一条边界：IT 要懂业务，是熟悉业务逻辑，是为了更好地用技术支撑业务，不是替业务做决策、替业务担结果。
IT 可以给业务提方案、给建议、甚至引导数字化认知，但最终 “这件事值不值得做、结果有没有达成” 的第一责任人，必须是业务侧。
纯技术宅的 IT，脱离业务，只会做工具人，必然边缘化；
让 IT 背锅的企业，把业务价值的责任全压给 IT，最后必然做成 “为了技术而技术”。
健康的状态永远是：
业务对价值负责，IT 对交付负责，双向奔赴，而不是单向甩锅。
最后说说读者提到的 “成立桥接部门、流程 / 变革部门”， 这个思路完全正确，我比较赞同这个思路，而且这恰恰是成熟治理体系里的标准配置，不是对 “业务牵头” 的否定，而是落地的必要补充。这个桥接部门，无论是叫流程变革管理部、数字化变革办公室，还是 PMO，它的核心作用就是补位：
补全局筹划的位：站在公司整体视角做流程重构、架构规划，破解单个部门的本位主义，代替业务部门做全局设计；
补需求翻译的位：把业务模糊的痛点、零散的诉求，梳理成标准化的业务需求和价值目标，填补业务和 IT 之间的认知鸿沟；
补变革推动的位：承接顶层的变革决心，跨部门协调推动，啃落地推广的硬骨头。
但即便有了这个桥接部门，依然替代不了一个核心原则：最终的业务价值、数据质量、使用效果，第一责任人还是业务部门。
桥接部门是润滑剂、助推器，不是背锅侠，也替代不了业务侧的主体责任。
05.
写在最后
所以回到最初的问题：不是 “业务牵头” 这个方法想当然、走不下去，是太多企业只学了半句口号，从来没真正搭好配套的治理体系。他们把顶层该扛的责任往下甩，把 IT 该做的赋能往外推，把本该协同的事做成了互相甩锅，最后得出一句 “这个方法不行”。老方法之所以得不到新答案，往往是因为很多人从来没真正用对过这个方法。真正的落地，从来不是喊一句 “业务牵头” 就完事，而是一套完整的组合拳：
顶层先站出来，定方向、推变革、担最终责任；
中间搭好桥接组织，破部门墙、梳全局流程、理清晰需求；
业务锚定价值结果，IT 穿透业务场景，各归其位，各担其责。
说到底，拼的确实是老板的认知和决心, 因为 IT 治理的第一责任人，永远在最高层。
