在对国内制造企业实施自动化、数字化、智能化仓储或制造项目中，实施方包括硬件商或集成商对其中工业软件（如仓储WMS、制造MES、设备运维等）的实施难点和解决途径普遍缺乏正确的认识。
他们虽然相信工业软件有一定复杂性，但感觉自己面对的场景相对简单，只要硬件到位了，软件集成实现并不困难，一开始，他们往往找一家便宜的软件外包公司来实施，随着层出不穷的项目变化和适配要求，外包公司无力应付，无法通过验收，用不起来，造成项目烂尾；踩了些坑后，一些有实力的厂商决定自己搭团队来做，结果花费巨大而收效不足，即使长期亏本投入，仍深陷客户需求难以满足的泥潭。这种试图不花多少工夫解决工业项目落地问题，或是试图通过短期投入快速切入工业软件领域，都与行业实际情况是不相符的。这些失败的根源，主要是没有把工业领域内的项目实施复杂度高、适配要求多、中间变故多、而核心人才奇缺这些情况认识清楚，更难以应对这些挑战。
如果认清这些事实，则可以理解国内工业领域实施何以会出现大量严重延期甚至烂尾项目，就会明白为什么方案总是难以适配不同的场景需求，就会明白为什么铺上大量人力仍然解决不了问题，
而只有在可适配能力（并不是堆各种产品功能）、快速应对变化能力和有效解决问题能力上下大功夫，让资深业务顾问直接交付系统原型，让核心研发直通现场环境开发和调试疑难问题，让架构团队设计沉淀通用组件，重构不同角色的职责、减少信息在不同角色中的传递损失，优化对高频迭代的支持，等等的措施，才能适应万变需求、才能项目成功落地拒绝烂尾、才能真正赋能工业制造业。
必须这样，才能树立工业领域从业人员的信仰，如若干互联网成功企业之于全行业的影响，才能真正将散落在各处、在混沌中各自苦战的行业人才和从业者的组织起来，让专业人才发挥最大的效力，让现场各种问题在萌芽阶段就被解决，看似善战者无赫赫之功，才能推动工业项目实施的革命，促进制造业快速转型升级。
在判断工业领域项目落地特点时，需要认识到以下这些要点：
一、工业项目实施领域长期缺乏人才且人才非常分散。实施中主要涉及三类人才，工业领域业务顾问、工业软件研发工程师和工业系统架构师。
工业领域目前是比较封闭的，首先是业务领域知识适应范围小，懂的人不多，且需要在现场长期摸爬滚打才摸的清，因而能理解客户需求的业务顾问就很少；其次是技术封闭，存在很多通用性较低的技术、协议，造成了一定技术门槛，技术对接时沟通交流都费劲，很多功能耗费巨大，仍然研发不出或不稳定；再加上实施环境的封闭，比如很多场合不通外网、甚至不允许带手机电脑，而如果不深入现场解情况，别说解决问题了，连理解是什么问题都困难。从业务领域知识和技术上都非常吃经验，经验不足，多少人力填入也是白送，解决不了问题。加上这些年来，实体行业在吸引人才方面存在劣势，不仅工业现场环境较差，而且从业待遇低，相关企业和从业人员在领域内的积累很难有效建立。这就能理解，尽管一些企业招了大量人员，也做的非常辛苦，仍然难以被客户认可、看不到希望。
二、在本来就缺乏人才的情况下，实施时采用的思维和方法沉旧或不合适，导致现场适配能力差、无力应对变化、无法解决问题。
做需求设计时，受限于业务人才稀缺，懂行的业务顾问往往只做售前，出个ppt方案拿下项目后就转战别处，后面交付脱节严重偏离自然在情理之中；好些的能把蓝图设计做完，然后丢给开发顾问就等验收了。
而往往需求从客户到顾问会损失大半，再到开发那边理解后已经所剩无几了。这里本质问题是分工不合理和沟通不畅。
根据高内聚、低耦合的原理，不同角色间的任务分工应使相互间的沟通内容最小化，而且即使必须的沟通，也需要让各角色使用一致的概念（模型），才能增强沟通效率、减小认知损耗。
有经验的业务顾问往往只参与售前，后续业务顾问（或直接由开发）拍脑袋做方案，凭假想做开发，交付出来的成果可想而知。反馈周期以数月计。上线即返工。
在项目进入开发阶段后，受限于开发人才稀缺，在现场的都是新手，现场开发经验不足，复杂沟通与开发搞不定（比如对接多种软硬件系统，接口多，协议多）。有经验的开发远程指导，但仍受限于网络、现场环境复杂度，沟通、开发、测试效率低下。到了试运行或上线后，现场总有些疑难问题难以重现、长期无法解决，比如用一段时间当机，偶尔出错等。技术解决不了，客户不满，给客户留下产品不行、技术不行的映像。而另一方面，真正开发人才却难以触达绝大多数现场情况，合作如隔靴搔痒，使不上力。
这里存在的问题深入来看，一方面技术架构对场景下复杂问题的封装差，导致现场业务理解或技术实施都会反复踩坑做无谓的耗费，另一方面在交付架构上对直达现场和高频迭代的支持几乎没有。
再往底层来看，仍然是技术架构和交付架构人才的缺乏，导致研发人员白白耗费了大量精力事倍功半。
三、项目周期极长，风险极大，上线后工作仍然极其繁重
工业项目中涉及的软硬件合作方往往非常多，系统协同对接非常复杂，沟通上存在很大风险。常常存在有些问题各方均不愿意承担从而无法落实解决（多解决问题，不会多得费用，只会多得麻烦）。
若以整体交付为目标，就要求供应商能有全局观和奉献精神，比如经常遇到硬件不支持一些特性，或可通过工业软件定制来弥补硬件的先天不足，促成项目适配落地。
项目落地时各种未预料的变故极多，有些项目做着做着甲方、乙方、合作方的相关人员都全部换了一轮，都还没能上线用起来。
好不容易熬到上线用起来，仍然存在大量的变更、运维工作，尤其是在上量之后，一些疑难杂症很可能最终断送这个项目，让客户挥泪舍弃、重新再做一遍替换掉。
认清这些个事实，促使我们要采用更加适配的战略战术。其核心一定要用好各类人才，尤其因工业项目最讲求现场感，需要有各种措施保障和加强各类人才参与到工业现场的深度。
一、业务顾问直接交付原型系统。别家业务顾问还在润色文档修改流程图，这边已经构建原型系统给关键用户试用并迭代七八回了，这是不是降维打击？
假想某个运维系统在需求调研后，发现客户也讲不清楚，业务顾问只能根据自己的经验加上脑补，写出蓝图方案来让客户确认，然后交给开发。客户拿着精心编制的蓝图文档很难提出有价值的问题，漫长的开会确认后，研发拿到蓝图，再经过漫长的开发，到交付时才发现差之远矣，然后返工折腾，一个轮回下来三个月，几轮下来双方都心力交瘁。
如果让顾问与客户直接拿着原型系统快速调整呢？当然速度要快，花几小时最多一两天就完成系统原型，客户体验后会直接说出这里或那里操作不对，两三次后，业务框架即可基本定型；很多不复杂的功能都可以不用研发参与了，而只有当出现必须复杂编程解决的定制逻辑时，研发才介入。
那么怎样让非专业开发出身的业务顾问能短周期里交付专业的原型系统并高频迭代出生产系统呢？建模思想、二开平台、低代码等都是业界方案，但能不能灵活，这就要看架构组的功力和企业的文化了。
这里重构了业务顾问与研发的协作模式，由业务顾问来交付，研发不再是大量开发系统功能，而只负责将复杂定制逻辑配置到系统模块中，另一方面，二者在架构组的协助下，通过抽象设计，沉淀出产品共性特性形成行业解决方案，以及沉淀出技术组件赋能其它垂直行业。
二、核心研发直通现场开发和调试疑难问题。假想一个远在东南亚的实施场景出了故障，需要核心技术人员诊断。你家研发还在抱怨本地环境正常啊、重现不了，要求去拿备份数据库、要求模拟现场通讯，一通操作下来，数周过去还是摸不着头脑，最后只好让现场人员凑和用了；而这边已经直连到生产环境，实时调试出问题原因，早已线上解决掉了。
这里要注意工业项目不同于很多互联网项目，前者往往实施人员极少，一两个开发搞定所有事情，而后者往往是几百号人开发维护着一个线上环境。
那么能不能支持直接现场、实时调试？工业现场可是很多连网都不通的，或是网络信号非常差。研发能不能直通过去、和在家里一样顺畅地实时解决问题？这也是区分实施能力、最佳实践经验的重要一环了。
举个软件升级的例子，你还在与客户预约升级时间，用1M带宽上传新的1G的软件升级包，等着之后安装重启服务（结果很可能弄半天发现还有问题哦，重新再来！），我早已经1秒推送升级完甚至直接线上实时更新完了，在线验证后发现有些新问题，然后又迭代一轮、二轮、解决了，是不是降维打击？你还在电话里讨论哪个配置可能不太对，教现场如何改如何观察，我已经逛街时抽了个空拿手机线上改好配置代码等着观察日志了。
这些战术都需要厚重的技术和经验积累下才能实行。
三、让架构团队沉淀通用组件。见过很多公司包括一些业内知名的大公司在做实施时，有不少常用功能，比如从某个PLC硬件读写数据，研发也只是找个库从0开始做开发，结果开发很快，但稳定性一直不好，遇到网络抖动、断电、并发等各种情况，程序当机，现场三天两头出故障。而类似这些坑在每个项目上一遍遍的踩，白送了无数人头。
工业项目最讲究稳定可靠、出现各种异常都不需要人为干预，从测试能用到能经年累月稳定使用还存在巨大的差距。
你还在安排人员忙着四处救火、收集各种案例编写培训资料、开会强调有哪些坑点，我这边已经提炼出组件并合并推送到其它项目了，实施人员都不必知道各种坑。
伴随着工业革命大趋势，工业数字化智能化转型项目的实施方法论也正在革命，传统打法无力支撑，新的实施方法论将更加适配工业项目独特的特点，促进生产力的提升，而正如生产力决定生产关系的规律所预示，新方法论的研究推广高潮必将马上到来，势不可挡，如同远方海上一艘航行的大船，已经露出了尖尖桅杆，如同高山之巅一轮朝日，映红了天空喷薄欲出。