我们做项目都知道，客户做项目之初会做整个信息化规划，关于业务需求的定义也和我们供应商达成一致。而一旦进入实施阶段后，它的需求经常发生波动甚至偏离。软件系统项目是以客户需求为核心，如果需求一改再改，轻则项目延期，成本升高，重则背离原有的信息化架构和设计，系统逻辑变得复杂混乱，最终导致实施失败。相信无论是咱们客户还是软件公司都不愿意陷入这样的“双输”局面。

先来分析一下造成需求不稳定的因素有哪些，我们认为至少包含三点：

第一，是需求界定模糊，业内经常说PLM系统是一把手工程，企业高层往往从战略层面制定了“降本增效”的目标，而具体如何实践降本增效却没有明确的定义。一旦目标设定的不明确，或是想在实施过程中才去细化目标到具体业务，就会造成需求细化之后，出现系统建设前期未考虑的因素，造成需求波动，增加了项目执行难度。

第二，也是最普遍的一种现象，客户内部意见难以统一，每个业务部门你一言我一语，说得好像都有道理，就变成今天要这个功能，明天又不要了。又或是企业本身行业发展较快，市场对企业的要求变化导致需求变更，企业不得不改变PLM建设思路，来适应市场要求。

第三，是不同部门对PLM系统功能期望不一致。最典型的，一个企业中研发和生产两个部门对PLM的理解就有很大区别。研发部门希望利用PLM控制版本，提高研发效率，更深层次希望能激发产品创造性和产品的附加价值。而生产部门更关注PLM系统与生产流程的对接，强调生产物料和工艺传递的准确性。最好还能根据现场工况调整工艺路线，并有结果记录。

所以，需求不稳定是企业的常态，作为我们PLM供应商如何直面实施过程需求变化的挑战，则是我们要给客户树立成功信心的关键所在。

海思的应对策略从四点出发：

第一，做好前期需求调研与规划。

除了洞悉企业领导与信息化整体规划外，深入业务部门和基层，与设计、工艺、生产、采购等人员讨论具体业务流程，将企业的研发管理一网打尽。定制需求框架并明确阶段性规划，按项目时间轴设立阶段性目标，并强化沟通和共识，引导企业所有业务部门朝着一个建设主线与思路共同努力。

第二，确立需求变更管理机制。

PLM管企业研发项目和数据，那么建设PLM系统本身也要遵循严格的流程管理机制。这和企业研发产品的思路不谋而合。那好理解了，企业研发产品需求怎么管，我们就怎么管，需要对可行性、必要性、和经济性论证，由客户与供应商共同决策，使得最终结果科学可行。

第三，项目按阶段实施，随时反馈调整。

海思建议的PLM实施原则为：小步快走，逐层深入。定完整体系统框架后，先从业务部门关注的功能点，比如设计工具集成、图文档管理、技术状态控制等等，打好基础。再对整个企业关注的物料管理环节优化，使得研发、物资、生产物料数据贯通，最后融合数据分析和管理过程优化，自下而上地形成完整管理模型。在过程中，注重阶段反馈的收集，并针对性对系统功能应用优化，确保实时关注企业需求，贴合企业需求，达成需求与实现结果的一致。

前三条都是针对执行管理角度如何优化过程，尽量预防和减少不必要的需求变更情况。而企业的PLM建设是一个长期过程，需求的变化和延展是必然的，所以，我们要从系统建构层面去适应客户的需求波动现状。这也引出我们核心的第四点策略，系统底层建构的灵活性。

海思PLM利用先进的底层数据管理技术——MDA技术，支持企业构建可持续优化的产品数据模型，适应不断变化的需求。可在不影响整体PLM运行的情况下进行功能的添加或升级。系统建模开发简单、快捷，可由客户指派专人参与我们线下免费提供的培训服务，提高建模开发能力，并由客户自主维护实现PLM业务功能的定制和落地。