我们都知道企业数字化转型建设工作都是以需求为中心来进行的，信息部门及软件公司都认为需求关乎成败，只要需求收集的彻底，数字化转型就成功了一半，但理想很丰满现实却很骨感，在业务需求上存在如下问题：
1. 业务部门不配合，需求收集难;
2. 业务部门基础能力有限，难以提供价值需求;
3. 业务部门需求杂乱，什么功能都想实现;
4. 信息部门或软件公司能力有限，难以梳理出价值需求;
在需求收集过程中，最重要的莫过于业务部门对于需求的理解，在大部分的传统企业中由于对数字化的认知问题，业务部门总是认为数字化建设是信息部门的事，所以当进行需求收集时业务部门总是说：对于数字化系统我们没什么要求，你们看着办!处于一种莫不关心的状态，但当信息部门将系统上线后，接来下业务部门又会说：这不是我们要的功能，系统无法满足我们的业务需求!从而导致系统上线后难以应用，这就是需求收集难而造成的应用难!
所以在这种情况下，信息部门要学会引导，从蛛丝马迹的线索中抓取价值需求点，引导业务部门提供更多的线索，从而拼凑除完整的需求路线图。
当前部分传统企业数字化转型建设面临的最艰难的问题莫过于信息部门一头热的现象，信息部门由于职责所在对数字化建设的热情十分高涨，而业务部门处于“事不关己高高挂起”的状态，以数字化太专业为由，婉拒来自于信息中心或者软件公司的需求调研活动，所以业务部门真实的需求自然也难以获取，在这样需求如此失真的状态下，数字化建设变成了以技术为核心，完全脱离了业务，结果自然也实施难、落地更难，大部分情况下是在实施阶段就已烂尾了。
而对于这种一头热的现象，究其原因最大的问题还是在于企业数字化战略的重视程度问题，并没有引起企业全员对于数字化的重视，技术与业务部门也没有就建设及实现路径达成共识，所以说数字化建设共识很重要。
这个时候有人会问，是不是业务部门需求旺盛，数字化建设就一定能成功呢?
不一定!
业务部门想利用数字化技术提升管理，但不一定知道如何做、如何来实现，只有一个想象中的美好，满眼的期待!
在数字化建设过程中我们也经常遇到这样的情况就是：业务部门什么都想要，什么功能都想统统的实现，什么中台、什么共享中心，我都需要!但这是好事吗?
对于软件企业来说是好事,因为离KPI的目标更近一步!
但对企业来说，不一定是好事!
在数字化转型建设过程中要注意的是需求一定以企业当前的管理现状为基础，看似大而全的方案实际上是能力的陷阱，所以这个时候对企业高层及信息部门的判断能力提出了挑战，要以企业实际能力为基础控制数字化建设贪大求全的欲望，需求并不是越多越好，方案并不是越大越好，适合自己的才是最好的，所以面对众多的需求信息部门要学会判断、梳理并制定实现策略，最好的需求实现方法莫过于按照达成的战略共识分步走、分步实现。
数字化之所以失败，往往就是企业不以当前能力为基础，在需求实现上贪大求全，比如动不动就玩平台化、系统要全模块，结果实际的管理根本没有驾驭系统的能力，最后的结果就是要么业务部门抱怨产品功能太复杂、不好用，难以应用，陷入重复建设的陷阱;要么就是仅仅应用了一两个功能模块，造成大量的功能浪费。
所以当面对大量的业务需求时，信息部门需要的是冷静的对待，勿进入规模化的陷阱，大部分的需求对于业务部门而言也有可能是模糊的、不明确的，因为业务对如何实现并不关心，只想要结果;业务也对系统的实现逻辑不关心，因为他认为那是信息部门要做的事情，殊不知一张报表的背后是几十甚至上百个逻辑计算，业务部门在大部分情况下总是无视技术开发、实现的难度，只想着今天提出需求明天就马上实现，所以信息部门应学会制定需求管理策略，不能在需求管理上打乱仗，在任何数字化项目开工建设前一定要与业务部门达成共识，同时信息部门也要学会对大量的业务需求进行清洗、筛选，具体可从如下方面进行考虑：
第一，需求实现的难易及复杂程度;
第二，需求实现的时间周期;
第三，需求实现的成本;
第四，需求的轻重缓急;
需求关乎企业数字化转型建设的成败，因此在业务需求实现的策略上，老杨建议信息部门一定要遵循“先易后难，逐步推进的原则”，部分规模企业的信息部门因其技术实力雄厚，因此喜欢做需求多、规模大、时间跨度长一般以年为单位的项目，以凸显其技术实力，但这样做恰恰落入了规模化陷阱，在过程中如缺乏对需求的管控能力，又会遭遇业务部门需求反复、朝定夕改的问题，这种情况下会导致项目建设迟迟无法落地，最后导致信息部门的成果、价值体现难。
综上所述，企业数字化建设成与需求也败于需求，因此信息部门对于需求的判断与把控非常重要，一方面要引导需求、提炼需求，另一方面当面对大量的需求时又要学会对需求的清洗，以价值为中心实现对需求实现的时间、成本以及进度的控制。