系统上线了，业务为什么还在用Excel？
如果你在制造企业推过数字化，下面这个场景大概率不陌生。
IT团队花了三个月，把业务流程梳理清楚，数据标准定明白，系统也搭好了。上线那天，业务部门的反应通常是礼貌而疏离——"好，我们用用看"。然后呢？用了一周，有人开始绕过系统走老路；用了一个月，业务方自己搞了套Excel表格另起炉灶；等IT回过头来问数据怎么对不上，得到的回答是："你们系统数据源有问题。"
做之前参与不深，做之后问题不断。这个循环在不少企业里反复上演。
更耐人寻味的是，如果你去问业务方："标准化到底该谁来做？"很多人会反问你："不是你们IT的事吗？你们建系统，你们定规则，我们用就行了。"
这句话听起来理所当然，但你细想就会发现问题——业务流程是业务方每天在走的，数据是业务方每天在产生的，规则却要IT来定。这就好比你天天做饭，菜谱却要让装修厨房的人来写。
业务标准化，为什么总变成IT的独角戏？
第一层
频次错位：两边看到的不是同一幅画面
要回答这个问题，得先看一个几乎被所有人忽略的细节：频次。
IT人员天天泡在系统里，每个功能按钮摸过几百遍，对他们来说，操作一套系统就像吃饭用筷子一样自然。但业务人员呢？一个车间统计员可能每天录产量，但一个月才做一次结账调整；一个部门主管可能两周才打开一次经营看板。你让偶尔才碰一次的人，去理解天天用的人设计的操作逻辑，中间的认知鸿沟比想象的大得多。
IT觉得"这不很简单吗，三步就搞定了"，业务觉得"我光记住点哪个菜单就花了半天"。两边对"难用"的定义完全不在一个频道上——一个闭着眼都能操作，一个光找到按钮就花了半天。
这种频次差异直接导致了一个认知错位：IT觉得标准化是"把简单的事情定好规则"，业务觉得标准化是"把本来就烦的事情变得更烦"。 一个觉得在帮忙，一个觉得在添乱。
所以当IT满怀热情地拿着一套标准流程来找业务方"对齐"时，业务方的冷淡不是态度问题。你站在他们的位置想一想：一套偶尔才用一次的流程，要花两天去学，学完还不一定对——这笔账谁都会算。与其学一套不熟悉的"标准动作"，不如继续用自己那套虽然土但闭着眼都能完成的Excel。
频次错位还制造了一个更深层的后果：双方对"标准化是谁的事"的理解天然分叉。 IT天天跟系统打交道，自然觉得系统里的规则就是自己的地盘，标准化是"我把规则定好，你们来执行"。业务方只是偶尔才处理一次这类业务，自然容易觉得系统是IT的东西，标准化是"你们的事，我只是被要求配合用一下"。
不是谁懒，不是谁推诿。是角色结构决定了，两边看到的是完全不同的画面。
当然，频次不是唯一原因，考核机制和组织分工同样重要。但它往往是最先让业务与系统产生距离的那一步。
第二层
责任模糊：结构留了缝，人就会往缝里钻
但频次错位只是第一层。真正让"IT独角戏"变成死循环的，是第二层结构问题：责任边界的事前模糊。
有一种场景在数据治理项目里几乎成了标准剧情：业务部门撇开项目组自己搞，等做出来发现数据对不上，回头就来一句——"你们数据源有问题。"
你仔细品这句话。它的潜台词是：数据是IT的，数据不对就是IT的锅。但数据是谁产生的？是一线业务人员。录入规则是谁定的？如果没有IT参与，那就是业务自己定的。自己定的规则、自己录的数据，出了问题却归咎于"数据源"——而数据源恰恰又是业务自己的操作产生的。
这不是甩锅技巧有多高明，而是责任边界从一开始就没有被钉死。
在大多数项目里，责任边界是怎么划的？口头划的。开会时大家点头说"这个归业务，那个归IT"，散会后各自理解，执行时各干各的，出了问题各说各的。口头共识是最脆弱的契约——因为它经不起任何一次实际冲突的考验。
更麻烦的是，这种模糊不是静态的，它会蔓延。一开始只是一两个环节说不清归属，慢慢地，整片灰色地带越长越大：哪些数据该业务录、哪些该系统抓、出了问题谁先查——每一个说不清的环节，都变成了两边都不认领的真空。而真空不会自己消失，它只会在某次汇报被质疑、某次盘点对不上的时候，突然炸开。
"等着IT来做"的心态，就是在这些缝隙里越长越壮的：做之前，业务觉得"反正IT会管"；做之后，业务觉得"反正IT会负责"。中间那段本该属于业务的空间，被灰色地带一点一点吞噬干净。
那怎么把缝堵上？不是靠口头共识，而是靠四个动作：
- 1.明确关键数据的业务Owner——到具体的人，而不是笼统地写"业务部门负责"；
- 2.固化流程、口径和异常责任清单——上线前签署，白纸黑字而不是散会点头；
- 3.限定试运行的范围、时间和风险底线——允许试错，但不能无限期"先跑跑看"；
- 4.对每次数据差异进行分类归因——源头录入、口径定义、接口处理还是看板计算，找到根因。
四件事做到位，灰色地带才能被一寸一寸收回来。
甩锅不是态度差。是结构留了缝，人就会往缝里钻。
第三层
痛感催化：标准化不是被教会的，是被"痛"出来的
说到这里，一个更根本的问题浮上来了：既然频次错位和责任模糊都是结构性的，那IT能做什么？把规则定得更细？把培训做得更扎实？
单独做这些，并不能解决问题。责任机制、改变意愿和运行反馈，缺一不可。
为什么？因为所有这些做法都默认了一个前提：业务方会主动配合。但这个前提本身就是错的。频次错位容易让业务方把标准化理解成IT的事，责任模糊让他们有了观望和甩锅的空间——在这两个结构性问题没解决之前，再细的规则、再扎实的培训，都是在推一堵往你这边倾斜的墙。
这里有一个反常识陷阱，不少IT管理者都容易踩进去：标准化不是被教会的，是被"痛"出来的。
你拿着一套精心设计的标准流程去找业务方，跟他们说"这样改效率更高、数据更准、以后省事"。他们听完点头，回去照旧。不是他们不信你，而是你描述的"以后省事"太抽象了——他们此刻没有痛感，你的标准就是一张贴在墙上的纸。
真正让业务方主动要标准化的，是他们自己撞了墙。
比如一个车间统计员，一直用手写表格记数据，觉得又快又方便。你跟他说系统录入更规范，他不理你。直到某天月底盘点，三个班次的数据对不上，他翻了三天纸质单据才找到源头——那一刻他比谁都希望有一套标准流程，能让数据自动对上。
再比如一个部门主管，自己拉了套看板，直到向领导汇报时数字被当场质疑，才发现自己的看板连数据口径都没定义清楚——那一刻他比谁都渴望有一套标准规则。真实问题，是推动标准化最有效的催化剂之一。
但这里必须说清楚一个分寸：痛感产生的是改变意愿，不是正确标准。
业务撞了墙，不等于他们知道墙是怎么来的。月底盘点对不上数据，统计员可能归因于"系统不好用"，而不是意识到自己的录入流程有问题。更不用说，在制造企业里，让业务"痛"的代价可能是实打实的——库存差异、质量追溯断链、交付延迟，甚至安全事故。把"让业务撞墙"当作方法，风险不可控。
所以更准确的说法是：标准化很难只靠培训推动，它通常需要由真实问题触发，再通过共同复盘和机制设计来完成。痛感只是起点，不是终点。
这也解释了为什么，试图在上线前一次性定完所有规则，通常走不通。规则在前，真实问题在后，中间隔着一层"我还没碰到问题为什么要改"的天然抵触。当然，安全、质量、合规和财务控制等领域的规则必须先定，不能试错。但对于可以迭代的业务流程，与其在上线前一次性定死，不如先跑、再调、后固化。这样形成的标准不再是外部强加的，而是从业务实践中长出来的。
规则不是从天上掉下来的，是从泥地里踩出来的。
收束
把业务从观众变成主角
回到最初的问题：业务标准化，到底该谁来做？
答案可能让IT管理者不太舒服：不是IT来做，也不是IT能说服业务来做。 但也不是简单地把球踢给业务就完事了。
"IT搭台、业务唱戏"这个说法很形象，但在制造企业里，标准化很少是两方的事。业务定义业务事实和规则，IT把规则转化为系统能力，质量、财务等职能部门分别把控各自领域的专业口径，管理层裁决跨部门冲突并对标准执行负责。某些主数据、权限管理、审计追溯和跨部门流程，也不能完全交给一线业务自己决定——这些恰恰需要IT和管理层共同兜底。
所以IT的角色更准确地说，是搭台子的人：台搭得稳不稳，数据通不通、系统跑不跑得起来——这是IT的活，得扛住。但台上唱什么戏、怎么唱，只有一线业务自己清楚。
真正该发生的不是"IT教业务做标准化"，而是创造条件让业务自己长出标准化的需求。怎么做？先让业务在可控范围内跑起来——限定范围、时间、风险底线。跑的过程中，真实问题会自己暴露出来。这些真实的摩擦，比一百次培训都管用。但暴露问题只是第一步，接下来需要共同复盘——业务定义规则，IT提供工具，管理层确认责任——最后把被验证过的做法固化进系统。
标准化不是IT的独角戏，也不是业务的自由发挥。它是一套共同发现问题、共同定义规则，并由各方对自己的环节负责的机制；其中，业务必须对业务规则和源头数据承担最终责任。
把业务从观众变成主角，靠的不是说服，也不是放任他们撞墙，而是让他们在可控的范围内，自己碰到问题、自己参与解题、自己认下规则。
