深耕软件领域三十年:从技术到需求,再到数字化转型的思考

点击上方 MES百科 关注我们

e-works鼓励原创，如需投稿请参看首页“原创投稿”说明。

自1995年走出大学校门，我便扎根计算机软件行业，一路深耕至今已走过三十余个春秋，兼具甲方与乙方双重从业经验。三十年的职业历程里，先后亲历程序员、系统分析师、项目经理、软件售前顾问、项目总监等多个核心岗位，每个角色都分别工作多年，积累了丰富的一线实践经验。其中，系统分析师与项目经理这两个岗位，更让我对软件项目顺利落地的全流程有了最为深刻的体悟，也让我始终围绕一个核心课题不断探索——如何实现软件项目的精益实施？

当下，国内制造业管理软件行业竞争日趋激烈，行业利润不断被压缩，精益实施早已不是可选方案，而是软件项目实现良性盈利、长久发展的核心路径，即便精益理念常被很多人误认为专属于制造业，但其内核适用于所有行业的项目管理与落地实践，以及我们的日常生活。

刚步入职场的前四五年，我始终以程序员的视角深耕技术领域，笃定软件技术是项目的核心，全然忽略了对行业业务知识的主动探索。所有的工作精力，都集中在软件开发工具、算法逻辑、数据库应用、软件架构等纯IT技术的钻研上，对于业务知识的了解，仅仅是为完成代码编写、项目实施而被动接收，对客户的真实需求与实际应用场景也只是浅尝辄止。这也导致我对项目业务的认知，始终是零散、碎片化的，无法从全局视角把控需求的完整性与逻辑性，彼时的我，甚至单纯将软件开发等同于代码的编写与修改，陷入了单一的技术思维闭环。

随着IT技术经验的不断积累，我逐渐打破了固有的认知，真正明白软件技术从来都是服务于业务需求的工具，技术本身只是实现需求的手段。在如今的制造业应用软件项目中，只要需求清晰明确，技术团队是很容易找到对应的解决方案的；可一旦业务需求模糊不清、缺乏系统性规划，后续的软件编码工作就会陷入无休止的修改和返工，要么是随着对需求认知的深化不断调整已完成的代码，要么是彻底推翻原有方案重新开发。这种被动局面，不仅让程序员疲于应对重复劳动，也大幅拖慢项目进度、增加项目成本。也正是从这一刻起，我彻底转变工作思路：软件项目中，技术并非核心，精准把握用户的源头需求才是重中之重。后续担任系统分析师与项目经理期间，我也将工作重心放在了全面、深度挖掘用户源头需求上。

这里所说的源头需求，绝非简单收集甲方各部门管理者提出的需求清单，其核心是精准洞察企业决策者的战略布局、贴合企业现场生产管理的全流程、覆盖各类真实生产的应用场景。很多时候，在软件系统正式上线前，甲方自身也无法清晰梳理出全部详细需求，这就需要软件供应商分别在售前咨询和合同签订后的需求详细调研阶段，用专业的方法引导客户、深挖源头需求，最终与客户共同明确项目实施范围、划分阶段实施计划。若是等到系统上线后，才根据实际使用情况零散补充、调整需求，必然会出现项目范围偏移、实施方向偏差，让整个项目陷入被动，难以顺利推进。

2006年，我正式涉足制造业软件开发领域，此后无论担任项目经理还是系统分析师，每一个制造业软件项目，我都亲自牵头开展深度需求调研；即便后来任项目总监，统筹多个项目，也始终紧盯每个项目的业务流程与源头需求挖掘。在长期的需求调研实践中，我形成了一套严谨的工作逻辑：首先与企业负责人、各部门核心管理者深度沟通，精准把握企业整体数字化战略目标、价值导向，以及分解到各部门的执行路径与考核指标；其次深入生产车间现场，全程仔细观摩生产作业方式、现场操作规范、物料流转方式、生产管理模式，逐一与一线员工、班组长、车间主任、生产经理、计划员、设备管理员、仓管等不同岗位人员交流核实，同时联动销售、采购、财务、人事等职能部门，全面梳理企业生产成本构成，打通企业战略目标逐层落地的全链路。需要特别强调的是，部分生产场景需在不同产品的生产过程中才能完整呈现，因此车间一线的观摩调研，往往需要反复开展，才能实现全场景覆盖，避免需求遗漏。

在多年的项目实操中，经过多次实践验证与经验沉淀，我总结出一个关键结论：搭建项目各方统一的沟通语言，是高效挖掘源头需求的核心。基于这一结论，我在多个项目中实践并提炼出数字化业务流程沟通体系，将其作为甲乙双方所有项目干系人沟通需求的统一标准。

数字化业务流程，并非工业企业业务部门独立输出的纯业务流程。若直接沿用业务部门提供的原生业务流程，软件实施团队需二次与业务方反复沟通理解、深度梳理、甄别校验，再进一步界定IT可落地实现与暂无法落地的边界内容，这无疑会抬高软件项目的沟通协作成本，拉长需求对齐与共识达成周期，极易造成前期调研效率低下，不精益。

数字化业务流程，以深度吃透企业生产现场全流程、吃透真实生产管理逻辑为基础，融合精益生产管理理念与自动化技术，依托工业互联网平台底座以及各类IT软硬件工具，统筹规划形成的标准化业务流程。它搭建起一套面向所有项目干系人、通俗易懂、一步到位的高效沟通与协同体系，既能显著提升前期需求挖掘的深度、效率与精准度，又能有效规避开发、实施阶段因供需双方需求认知偏差、客户随意变更需求，引发的代码反复调整、方案频繁返工、迭代失控等一系列项目风险。

随着对制造业多领域业务认知的不断深化，我的行业认知再次升华：在软件项目前期规划阶段，需求也并非最终的核心，真正的核心是底层的哲学思维和系统工程。制造业细分领域众多，不同行业、不同产品的生产现场繁杂多样，企业管理模式也各有差异，想要快速吃透各类生产流程与业务场景，需要强大的归纳、总结、推理与演绎能力，尤其是在软件产品需求梳理过程中，精准提炼不同项目的共性与差异性，更离不开这种底层哲学逻辑支撑，以及系统工程思维，因为有的客户单部门需求是零散的，需要站在整个工厂业务和数据流角度统一规划，而且，数字化转型中软件项目也不能仅仅站在软件的角度去思考，还要将精益理念和自动化设备一并考虑。

这也让我深刻意识到，优秀的软件项目经理，绝不是单纯的IT技术人员就能胜任；软件项目的成功落地，也绝非仅依靠IT技术就能实现。项目经理只有深度熟悉客户生产管理全流程、全面掌握各类实际应用场景，才能在项目全生命周期中，对项目质量、实施进度、业务范围、运营成本、潜在风险进行精准把控。在项目前期，由项目经理牵头开展深度需求调研，输出数字化业务流程与功能清单，再由业务顾问完成《需求规格说明书》，二者分工协作、相辅相成。因为，项目前期需求调研阶段，项目经理无需每日与各方频繁沟通，只需定期同步进度，完全有充足的时间与精力主导需求调研工作，保障需求挖掘的专业性与全面性。

回望中国制造业信息化数十年的发展历程，行业先后迭代出多种软件开发模式与管理体系：从早期的结构化开发、面向对象编程，到后来的敏捷开发、DevOps运维一体化；从ISO、CMMI等标准化流程的落地推行，到组件化、平台化技术架构的升级优化，各类软件系统在产业实践中不断探索前行。但即便发展至今，行业依旧面临一个难以破解的痛点：国内ERP（涵盖国产与海外品牌）整体实施成功率始终偏低，仅维持在30%-40%，高失败率、项目延期、过度定制、浅层应用成为行业普遍现象。这一困境并非ERP独有，APS高级排程、MES生产制造执行、WMS仓储管理、HR人力资源等各类工业软件，在实施过程中也大多陷入反复整改、周期拉长、验收困难、甚至项目烂尾的窘境。面对这一行业难题，我们不得不深入反思：问题的核心根源究竟是什么？

答案依旧是：源头需求。若是在软件项目前期需求调研阶段，无法以客户熟悉的生产管理流程、实际应用场景为核心，将精益生产、自动化改造、设备数据采集、企业资源管理等实际需求，与IT软件功能、硬件配套、网络部署、大数据、人工智能等技术手段深度融合，明确各阶段实施内容与落地方法，梳理出贴合企业实际的数字化业务流程并与客户反复对标确认，那么就只能在软件上线后，零散、无序地调整需求、修改代码，最终导致项目面目全非、停滞不前、无法结案，彻底失去落地价值。

俗话说“出来混，迟早是要还的”。软件系统最终都是要融入企业个性化的生产与管理流程，脱离实际流程和场景的软件，终究无法发挥应有价值。当下，太多制造业软件项目经理、业务顾问，在前期需求调研中存在严重的认知与行为误区：他们缺乏深入车间一线、反复调研生产场景的耐心，一味站在IT技术视角，坐在客户办公室内收集用户需求清单、组织用户部门负责人座谈、演示现有软件产品功能后，便闭门造车完成《需求规格说明书》（有的项目，该需求文档干脆就是拿别的项目文档或标准模板稍作修改即算完成）。即便后续开展需求文档评审，也常因评审人员不熟悉企业生产现场、不了解技术与业务的融合逻辑，导致评审流于形式，无法为后续开发提供真正有效指导。这种脱离实际的需求文档传递到开发环节，即便开发人员拥有高学历、过硬的技术能力，最终产出的软件系统也只会是僵化的“专家系统”，无法适配企业实际运营需求，自然难以落地。

更值得警惕的是，诸多项目因需求偏差、管理失当而失败后，相关从业者并未总结教训、优化方法，反而将失败的实施经历当作所谓的“行业经验”，沿用固化的工作模式开展新项目，最终陷入“项目延期、验收失败、再延期”的恶性循环。究其根本，是从业者未能打破思维定式、摆脱错误路径依赖，没有将失败教训转化为改进方案，才让行业痛点持续存在。

从根源来看，很多软件供应商始终没有树立“以客户为中心”的服务理念，当下制造业软件行业，迫切需要实现从“供给侧”向“需求侧”的核心转型。回顾早期ERP实施历程，供应商大多要求客户适配软件固有流程，极力规避定制化开发；后续MES、WMS、QMS和HR等工业软件推广，不少供应商依旧延续这一思路，导致大量项目推进受阻、无疾而终。

软件的本质是服务，必须立足客户实际生产与管理流程，即便企业现有流程存在优化空间，也应在尊重现状的基础上实施精益改善。但在实际市场竞争中，部分销售人员、售前顾问为拿下项目，采用低价竞标、过度承诺的方式，项目签约后，又因成本限制省略核心的流程梳理环节，或是不具备专业的流程梳理能力，无法满足客户个性化需求，让项目合作的初始愿景彻底落空。在此也想提醒甲方企业，商业合作始终遵循“一分价钱一分货”的原则，过低的报价无法支撑专业的实施服务，最终不仅无法实现数字化转型目标，还会造成企业资源的浪费。

若是强行要求客户迁就软件的固定流程，必然会出现软件与生产业务脱节的问题，再加上部分软件本身封闭僵化、操作繁琐、漏洞频发，很容易引发客户方使用人员的抵触情绪，最终导致软件被弃用。现实中，不少企业在推行ERP、MES、HR等软件时，反复陷入“实施—停用—再实施”的怪圈，不仅耗费大量人力、财力、物力，还严重影响正常生产运营。由此可见，从供给侧转向需求侧，以客户真实需求为核心开展项目实施，是制造业软件行业发展的必然趋势。

另外，针对数字化转型与工业软件的关系，有观点认为，没有工业软件就不可能实现数字化转型。该说法需要辩证看待。企业在尚未部署专业工业软件的阶段，依靠流程梳理、表单电子化、手工数据归集，依然可以启动数字化转型，但这类转型停留在浅层，难以形成持续的数据闭环。

数字化转型的根基是经过统筹设计的数字化业务流程，工业软件则是将这套流程落地固化、自动运行的关键载体。如果缺少PLM、ERP、MES、WMS、QMS等工业软件，跨工序、跨部门、跨供应链的大规模业务协同、虚实交互很难落地。简言之：可以无软件启动转型，但深度数字化转型离不开工业软件的支撑。

活动预告

⇩