作为一名数字化顾问，我在过去十年里参与了上百家企业的数字化转型项目。不管是制造业巨头、零售连锁品牌，还是金融机构，我几乎在每一个项目启动会上，都会听到类似的声音：
"业务部门根本说不清楚他们要什么！" "需求变来变去，上个月刚定好的方案，这个月又推翻了。" "等系统上线了，他们才说这不是他们想要的。"
而业务部门的回应往往是：
"IT听不懂我们在说什么。" "你们做的系统根本不好用，跟我们实际工作流程对不上。" "我们也不知道技术上能做到什么程度，怎么提需求？"
这几乎成了一场永无止境的拉锯战。更令人沮丧的是，即便双方都怀着善意，投入了大量的时间和预算，最终交付的系统常常未能达到预期效果。
问题究竟出在哪里？
我花了很长时间才想明白这件事。
真相是：让业务部门提出"正确的数字化需求"，这本身就是一个伪命题。
一、为什么说这是一个伪命题？
先别急着反驳我，听我讲一个真实的案例。
我服务过一家中型制造企业，老板想做"生产管理系统"。于是CIO组织了一场需求调研会，把生产部、质量部、仓储部的负责人叫到一起，问他们："你们需要系统实现什么功能？"
会议开了三个小时，记录了一大堆需求：要能追踪每个工单、要看到设备状态、要自动计算良品率、要跟ERP打通、要支持移动端扫码……看起来挺全面的。
系统开发了半年，上线试运行，结果生产主管用了一天就打电话过来："不行，这系统没法用。"
问题出在哪？他们提的需求"不对"吗？不是的——系统确实实现了他们列出的每一项功能。问题在于：他们只描述了"想要什么"，而没有描述"实际是怎么工作的"。
真实的车间场景是这样的：一个操作工可能同时管三台设备，每半小时巡查一次，看到异常先自己判断，处理不了才往上报。而系统设计的流程是"发现异常→系统上报→主管审批→下达指令"，结果操作工发现实际情况根本走不通这个流程。
你看，业务部门并没有说错什么，他们只是遗漏了那些"习以为常"的工作方式。因为他们太熟悉自己的工作，以至于意识不到有些东西需要被说出来。
二、业务部门提不出正确需求的四个根本原因
原因一：知识的诅咒
心理学家用"知识的诅咒"来描述一种现象：一旦你知道了某件事，就很难想象不知道它是什么感觉。
对于每天沉浸在业务流程中的业务人员来说，很多事情已经内化成肌肉记忆了。他们大脑里的工作流程是这样的："看到A情况→自动判断→执行B操作"，但当他们向IT人员描述时，通常只会说"我们要能处理A情况"——中间那个"自动判断"的环节，他们觉得是常识，没必要说。
但数字化系统恰恰卡在"怎么判断"这个环节上。 系统需要明确的规则和逻辑，不能靠"我觉得差不多就行"。
顾问视角：真正的问题不是业务人员"说不清楚"，而是他们不知道"哪些是系统需要知道的"。需要的是一名"翻译官"——能把业务流程翻译成系统逻辑的人。
原因二：看不到"应该是什么"
亨利·福特有句名言："如果我问客户想要什么，他们会说想要更快的马。"
业务部门提需求时，往往基于现状来做"改进型想象"——把现有流程做得更快一点、更自动化一点。他们很难跳出自己的认知框架，去想象一个完全不同、更好的工作方式。
我遇到过一家零售企业，门店销售提需求说："能不能做个功能，让我们把每天的销售数据手动录入系统？"实际上，他们完全可以直接对接POS机自动获取数据。但一线员工从来没用过自动对接，他们根本不知道有这个可能性。
数字化转型的尴尬在于：最有能力想象未来的技术人员，不了解业务；最了解业务的人员，不知道技术能做什么。
顾问视角：解决之道不是让业务人员学技术，或让技术人员学业务，而是创造一种机制，让两类人能够深度对话、共同创造，而不是"你提需求，我来实现"的流水线模式。
原因三：组织边界造成的盲区
我曾经在一家集团企业做项目，市场部、销售部、客服部分别提出了各自的需求，看起来都很合理。但当我把三个部门的需求放在一起看时，发现了一个严重的问题：
市场部要的客户标签体系，和销售部的客户分级标准用的是两套分类逻辑 客服部的退换货流程，完全不考虑销售部的已审批折扣如何处理 三个系统各建各的客户主数据，同一个客户在三个系统里是三条不同的记录
这不是"需求错误"，而是"组织盲区"。 每个部门站在自己的视角看问题，需求本身是自洽的，但合在一起就是灾难。
这种情况太普遍了。数字化系统天然具有"穿透"特性，它会穿透部门墙，把原本各自独立运行的流程串在一起。而传统的需求调研方式，恰恰是按部门分别收集需求，这从一开始就埋下了冲突的种子。