业务总监说：“我要一匹跑得快的马。” BA翻译成文档：“用户需要一个四条腿的运输工具。” IT开发出来：“这是一只四条腿的乌龟，虽然慢，但是它系统稳定，不会崩溃。”
为什么企业数字化转型最大的障碍是“甲方IT团队”在过去的二十年里，我以咨询顾问的身份走进过上百家企业的战略会议室，也以供应链总监的身份亲自操盘过数亿规模的数字化项目。 我观察到一个极其普遍却又讳莫如深的现象：企业高喊数字化转型的口号，斥巨资引入先进的系统，但最终的效果往往是业务效率不达预期，一线员工甚至怨声载道。 当我们一层层剥开这个洋葱，试图寻找核心病灶时，往往会发现一个令人尴尬的事实：那个本应是数字化转型“推手”的IT部门，正在演变成转型路上最大的“路障”。 这听起来很刺耳，甚至有些反直觉。但在商业逻辑面前，我们必须保持绝对的诚实。今天，我用逻辑刀法，为你解剖这个隐藏在技术光环下的结构性顽疾。 一：技术本位主义——由于“听不懂”而产生的傲慢 数字化转型的本质是什么？ 很多人认为是把业务搬到线上，是无纸化，是数据大屏。错。数字化转型的本质，是用数据的颗粒度重构商业的逻辑链。 然而，在绝大多数传统企业（甲方）的IT团队眼中，数字化被简化为“软件开发”或“系统采购”。这种认知偏差，导致了第一层障碍：语言体系的完全割裂。 1. 代码逻辑 vs. 商业逻辑 IT工程师的世界是确定的、线性的、逻辑闭环的（0和1）。而供应链的世界是波动的、非线性的、充满灰度的（库存周转、突发塞港、供应商违约）。 当业务部门提出一个需求，例如“我们需要一个灵活的库存调拨规则”，IT部门的第一反应往往不是“这个规则背后的商业目的是为了降低呆滞库存”，而是“这个逻辑在数据库里怎么建表？会不会破坏现有架构的完整性？” 这种思维差异导致了一个可怕的后果：IT团队倾向于把复杂的商业现实，削足适履地塞进他们“完美”的技术架构中。 在IT的眼中，世界是由代码和架构图组成的；但在残酷的商业战场上，世界是由转瞬即逝的机会和锱铢必较的利润组成的。当代码逻辑凌驾于商业逻辑之上，系统就变成了业务的枷锁。 2. “翻译”过程中的信噪比流失 在传统的组织架构中，业务与IT之间往往隔着一层厚厚的墙，需要“需求分析师”（BA）来传话。 这就是经典的“传声筒效应”。IT团队离炮火太远，他们听不到前线的枪声，只能听到后方安全屋里的键盘声。 这种物理和心理上的距离，使得IT团队交付的产品，往往在上线的第一天就已经过时。 二：深层次的利益冲突——“造轮子”的诱惑与权力的边界 如果说认知差异是无心之失，那么利益冲突则是更为隐蔽的“结构性障碍”。 我在BCG做顾问时，曾评估过一家大型零售企业的WMS（仓储管理系统）选型。业务部门倾向于购买成熟的商业SaaS软件，因为迭代快、最佳实践多；而IT部门则强烈建议“自研”。 理由听起来冠冕堂皇：数据安全、自主可控、定制化程度高。但如果深挖其背后的动因，你会看到不一样的东西。 1. 简历驱动开发 对于甲方的IT人员来说，维护一套现成的SaaS系统，在职业履历上是平庸的。但如果是“从0到1架构了一套中台系统”，或者是“运用了最新的微服务架构重构了ERP”，那么他的身价就会倍增。 这就导致了IT部门有着天然的冲动去“造轮子”。 他们会夸大外部系统的局限性，过分强调企业业务的特殊性，从而争取巨大的预算来进行内部开发。 结果呢？企业花费了数倍于购买SaaS的资金，养了一支庞大的开发团队，最后做出了一个功能简陋、bug频出、维护成本极高的“烂尾楼”。 笔者也曾亲眼目睹，一个IT产研团队是如何说服老板，公司的业务是如何特殊，无法使用市面上的运输管理系统。然后自研5年，做了一个无法生成对账单，调度需要导入Excel，通过“教育”用户使用各种数据清洗处理以及识别错误代码的方式，勉强维持“能跑”的TMS系统。 不要让你的IT团队为了润色他们的简历，而拿公司的战略资源做实验场。在这个SaaS极度成熟的时代，非核心业务的盲目自研，是对股东资产的犯罪。 2. 对“控制权”的迷恋 数字化转型必然伴随着权力的再分配。数据就是新的权力。 传统的IT部门习惯于做“守门人”。他们通过控制数据的访问权限、控制系统的修改配置流程，来确立自己在公司内部的地位。 当业务部门希望尝试敏捷开发、希望引入低代码平台让业务人员自己搭建应用时，IT部门往往会跳出来反对。他们会祭出“信息安全”、“数据孤岛”、“合规性”这三座大山来压制业务部门的自主性。 这实际上是一场权力的保卫战。 IT部门恐惧失去对技术的垄断权，他们害怕一旦业务人员掌握了数字化工具，IT部门就会沦为单纯的“网管”。 据Gartner的研究数据显示，超过60%的数字化转型项目失败，并非因为技术不成熟，而是因为组织内部的文化阻力和政治博弈。而IT部门这种对控制权的迷恋，正是最大的阻力来源。 三：无法调和的速度矛盾——敏捷业务遇上瀑布式开发 供应链是一个对速度要求极高的领域。在跨境电商行业，市场风向一周一变，物流政策一月一改。我们需要的是“即插即用”的特种部队战术。 而很多传统的甲方IT团队，沿用的依然是工业时代的“瀑布式开发”流程：需求评审 -> 立项 -> 排期 -> 开发 -> 测试 -> 上线。这个周期通常以“月”甚至“季度”为单位。 1. 完美的系统 vs. 可用的系统 IT工程师追求的是“完美”。他们容不得代码有瑕疵，容不得架构不优雅。这是一种工匠精神，但在商业上往往是致命的。 业务部门需要的是一个MVP（最小可行性产品）。也许它界面很丑，也许它后台还要人工跑数，但只要它能在这个月帮我把货物发出去，它就是好系统。 IT部门的“洁癖”，扼杀了业务的“生机”。 他们会因为这周发版有风险，而拒绝上线一个紧急的营销功能，导致公司错失销售额。在他们的KPI里，系统稳定性（SLA）是100分，而公司少赚的钱，与他们无关。 2. 响应机制的僵化 你是否经历过这样的场景：你想在系统中增加一个报表字段，于是你提了一个工单。 IT回复：请走OA审批，并由部门经理、IT经理、架构师评估工时。 两周后，对方告诉你排期已经排到下个季度。 这种僵化的响应机制，逼得业务部门只能用Excel、用飞书文档、用微信群来解决问题。于是，企业花大价钱上的系统被架空，真正的业务在Excel里流转，而不是在ERP里。 这就是所谓的“影子IT”泛滥的根本原因。 四：破局之道 批判不是目的，建设才是初衷。 既然我们已经拆解了IT成为障碍的根源：认知错位、利益冲突、速度矛盾。那么，解决方案也必须从这三个维度入手，进行一场组织层面的“外科手术”。 1. 重新定义CIO的职能 企业的一号位必须明确：CIO（首席信息官）不仅仅是管电脑和服务器的，更必须是半个业务专家。 我建议所有企业的CIO和IT高管，每年必须有20%的时间在“听炮火”。去仓库搬箱子，去销售一线听电话，去供应商工厂看产线。 不懂业务流程的IT，没有资格写代码。 所有的技术架构，必须服务于商业架构。 2. 推行“业技融合”的组织架构 打破“业务提需求-IT做开发”的这种甲乙方关系。在我的团队里，我推行的是“产品经理责任制”。 每一个数字化产品（如WMS、OMS）都由一个既懂供应链又懂技术的产品经理（PM）负责。IT开发人员不再是坐在总部的"格子间"，而是被派驻到业务线，与运营人员坐在一起办公。 只有当程序员亲眼看到仓库打包员因为系统卡顿而不得不加班到深夜时，他才会明白“性能优化”这四个字背后的伦理重量。 3. 拥抱“公民开发”时代 这是解决IT瓶颈的终极武器。 随着低代码和AI技术的发展，技术门槛正在急剧降低。企业应该鼓励业务人员成为“公民开发者”。让懂业务的人，自己利用低代码平台搭建简单的应用、报表和流程。 IT部门的角色，应该从“把关人”转变为“赋能者”。你们的任务不是替业务做每一个功能，而是搭建好基础设施、制定好数据标准、提供好安全底座，然后把积木交给业务人员，让他们自己去搭建城堡。 真正的数字化转型，不是让IT部门变得更庞大，而是让每一个业务人员都具备数字化的思维和能力。当人人都是产品经理时，转型才真正开始。 结语 在供应链管理的哲学里，我们讲究“全局最优”而非“局部最优”。 如果一个企业的IT部门，在技术指标上做到了极致，拥有最漂亮的代码和最稳定的服务器，但企业的业务响应速度却因为流程繁琐而变慢，那么这个IT部门就是在做“局部最优”，实际上是在损害系统的“全局最优”。 各位CEO、供应链总监、业务负责人，请审视你们身边的IT团队。 他们究竟是你们攻城略地的武器，还是束缚手脚的枷锁？ 如果是后者，请不要犹豫。推倒那堵墙，打破那个傲慢的技术黑箱。因为在数字化浪潮席卷之下，留给传统企业犹豫的时间，已经不多了。 关于作者： 20年供应链+物流老兵，曾穿梭于麦肯锡、BCG的会议室，也曾在宝洁、亚马逊的仓库里搬过箱子。专注拆解供应链背后的商业逻辑。欢迎关注《供应链纵横》。
