从LTC到IPD的产品开发协同思考

fuhe

针对协同，在过去的项目咨询和实施中经历的最多，企业也从简单到CAD设计协同到设计工艺协同，已经扩大到集成产品开发团队协同，甚至更扩大的从市场需求到产品规划，再到产品开发和产品交付，从市场端来，最终又回到市场的协同——这两三年经历了多个更大范围端到端的业务拉通和IT实现的项目，让我也体会到企业更大范围协同时的数据孤岛，以及通过有效的数字化手段和工具提升的可行性。

协同的改善随着跨部门的范围越来越大，改善的难度也越来越大；当不同的部门对业务管理和产品数据有不同的诉求时，如何通过对价值链和数据链的分析，进行合理的业务建模，确保业务的顺利衔接，确保数据的贯通(这个好像是一个很简单的事情，但实际在企业访谈过程中，发现了大量的过程重复的数据处理工作)；最近几年研究学习BOM比较多，因此以BOM为例，层级统计分析了从市场阶段对BOM需求，一直延续到售后运维，不同的部门都在吐槽BOM质量低，即使是行业头部企业，也收集到超过100条问题。

翻了一下过去的公众号，发现已经针对产品平台化设计写了好几篇，但有一些网友问，或在企业咨询实施时也有类似疑问，我们为什么要进行产品平台化模块化设计，到底会给企业带来什么效益？平台化开发[/需要企业有很大的投入，但价值在短期内确很难体现，从产品的迭代优势、市场优势和成本优势进行说明，但讲完了发现企业响应者甚微；后来在一家沟通时，站在市场和营销的视角分析对产品数据的需求，分析如何进行产品开发快速响应交付，即站在从商机到合同到产品/解决方案交付的视角，梳理BOM对业务的支撑，获得了企业的认可，所以当山重水复疑无路时，站在需求者的视角想一想，也许就是柳暗花明又一村了。

这块其实也没有多么高深的业务理论，就是LTC业务，不过在以前的很多针对LTC的业务中，更多关注商机的获取，订单的确定，产品的交付和合同回款，整个过程更加倾向于商务/订单而非产品，但随着企业产品的客户化定制增多，如何在前期就精准基于企业能力识别需求与产品的差异，并且按照差异快速可控的设计，实现订单BOM的准确交付，我认为这是站在产品管理视角，分析LTC业务，并且串联上下游业务耦合和协同的重点，也是LTC实施的重点，否则LTC就很有可能漂浮在企业的营销服业务的顶层，无法向下扎根。

但是对于企业来说，实施产品平台化开发，以及LTC流程的实施向产品开发扎根并不是一件容易的事情；首先要确保企业在实施LTC业务时，不要仅仅当成一个业务梳理和过程文档交付的项目来推进，因为这些年的确见多很多将IPD和LTC都实施成为项目管理，好像使用了项目管理的WBS将各种交付物落地了就达到诉求；其实这种情况，我们假设将过程分为4步骤的话，那也仅仅是入门，只是在内部贯彻了IPD和LTC的理念，并未真正的带来多大的改善，尤其是从数字化视角的量变聚集引起质变的价值链。我在企业协助IPD和LTC落地时，更喜欢先从更宏大的视角定义这个业务耦合，然后在此基础上，拆解协同过程中业务诉求和数据诉求，在定义协同的业务部门和数据目标，并且通过不断的，持续的拉通上下游的业务，逐步向从市场来到市场去的端到端业务贯通(这对企业的发展至关重要，因此企业必须深刻认识到这一点，并将持续改进作为长期战略目标，不断推进和更新迭代。只有这样，企业才能保持竞争力并取得长期成功。)

为了在自己的知识和能力范围内，更好的策划和定义产品开发与LTC的协同，在过去的两年中，我翻了好多本关于LTC的书籍，LTC流程变革的一大亮点就是大幅提升了标前引导的质量，以此在项目期间高质量地管理客户的项目需求。华为以前在这个阶段做得不够好，过去的标前引导不正式或效果不佳，过于依赖员工的个人能力。IBM曾经流传一句话：“如果你不能去控制客户的需求，那么你93%会失去这个项目。”需求是项目的游戏规则，一个项目的质量在客户的正式需求形成前就被决定了。因此在面向LTC的业务过程中，定义的“铁三角”组织就至关重要，在这个过程中我最关注解决方案的定义，因为向前衔接了客户的诉求，向后定义了交付的要求。解决方案在商机阶段就逐步输出，并通过商机确认和合同确认逐步推进。第二种情况更容易理解，暂且质量和效率先不说，但第一种情况就很少见，尤其是在标前阶段的定义。在标前引导阶段，企业对两种来源的商机的处理逻辑会略有差别

2024年我计划在这方面投入更多的研究和探索，不仅是为了将自己的经验与企业的实践融合，更是探索自己总结的方法的可落地性；将解决方案和产品数据定义的阶段向前迁移，面向商机进行分析，不仅是为了更好的满足交付的需求，也是更好的在前期识别客户偏好、精准对手的产品战略，便于企业能有更多的精力和投入改善产品开发，提升从商机到合同的转换效率和质量(当然也包括在这个过程中，对产品性能指标、成本质量、运维指标的偏差分析等)。基于这种更细致的管理方式，不仅要求前端的市场营销需要更精益，产品研发更需要转向精益，才能获取价值链的精益，再加上数字化的加持，才能如虎添翼(前提是必须是虎，要是狐，那就弱了......)

在已经实施IPD和LTC的企业，若没有进行真正的变革，尤其从电子化/信息化转向数字化，获得的改善就不是很大，这里很大的阻力就是“忙”，担心改变或变革的不确定性对现状造成影响；我在一些企业沟通时，有些工程师或领导直接告诉我们：至少目前业务还能运行，你能确保你的方案一定能对我带来提升，要是影响交付你能负责？是不是忙中添乱？对于这种状况，很多时候我会是保守的，逐步的改善总比不改善好，推动愿意改善的人员先进行改善，建立更多标杆影响这些“忙人”；当然在新的2024年，我也会从更多的视角分析从IPD到LTC，以及LTC到IPD的项目实施中的思考，希望能获得更多志同道合的指正和认同。