“平台战略”这些年说的很多，词挺时髦的，不过做起来并不容易。个人的体会来看，做起来不容易其实并不是技术本身多复杂，而是这项工作太繁琐。今天整理平台化实施的思考，更体会到“知易行难”一词的含义。
平台化模块化的目的：谈“平台战略”首先还是要搞清楚实施“平台战略”的目的——降成本。平台首要目的是增加零部件的共用，减少零部件的数量，产生的不仅仅是规模效应，更重要的是成熟的系统反复用降低了开发、验证的投入，也降低了质量成本支出的风险。实施平台战略必须要以降低综合成本为目的，否则就没有意义，这是工作开展的前提。
从开发流程上看平台化模块化的实施：集成式产品开发强调“纵向异步、横向同步”，整个开发框架中包含了产品规划、产品开发、技术及平台开发三个层次，对“纵向异步”的一个层面的理解可以认为是这三个层次开发的“纵向异步”。我记得华为的研发里曾说过一个“技术货架”的概念，技术及平台的开发要与产品开发相独立，在技术及平台开发成熟了才进行产品的开发，也就是说产品开发过程中可以在“技术货架”上选用成熟的平台、模块等等，以确保产品开发周期的可控。所以，技术及平台开发本身就是产品研发体系及流程的一部分，其实现在很多产品开发问题频出很重要的原因就是重视产品开发，忽视技术开发。IPD里面也高度强调了CBB共用模块的概念，基于平台和技术研发的核心理念就是①基于平台的异步开发模式和CBB重用策略，②技术开发与产品开发分离。
到底是自上而下还是自下而上？平台化模块化实施理论上有两条途径，一是“自下而上”，就是自己梳理一下现在产品的情况，做减法，降低现有零部件的数量；二是“自上而下”，指一开始规划就考虑到各种情况，打造一个超级平台，给定约束，以后只能这么干了。理论上两种途径都是可以实现的，但现实中这两个途径并不是对立的，而是相互补充的。“自下而上”的资源梳理是见效最快的零部件通用化方式，通过这种方式把零部件库建起来是实施平台化的基础，但是老这样被动地“自下而上”也不行，产生的效益会很有限。“自上而下”则能够从顶层规划的角度去逐步地约束零部件的数量，让产品开发一开始就有这个概念。例如，一款动力总成预测需要在几款产品上都可以搭载，一开始布置的时候就要几款车型都一道布置一下，定义清楚各分组的约束，这样虽然只验证一款产品，但由于开发约束定义清楚了，向其他几款产品拓展时可能就不需要再进行验证了。平台化模块化不是一蹴而就的事，而是要融入到日常工作中，不断地通过自下而上、自上而下的多轮迭代，找到最优解。
主动还是被动：读《技术的本质》一书时提到了技术发展的“路径依赖”，其实这反映出来的是产品开发过程中被动“零部件通用化”的一个现象，也就是说，同一个人做设计，会习惯地重复使用自己过去的方案，从而使“零部件通用化”得以实现。但这是一种被动的实施。今天我们谈产品的平台化、模块化及零部件的通用化是要将个人路径依赖产生的零部件通用化转变成一种主动的甚至是制度上规定的、流程上约束的产品开发过程中的设计方案出台模式。所以，衡量一个企业的零部件通用化做得怎么样，绝不是拿出几个零部件共用的例子就算是开展零部件通用化了，而是要看看是否将被动的路径依赖转化为主动的选择，这其中虽然结果可能是一样的，但长远来看其意义大不一样。
最后谈点个人经历的体会：
1、我一直梦想着能像华为公司说的那样，把技术开发都提前储备，当产品要用的时候就像在货架上拿一样方便，但是，到目前为止，这还只是一个梦想；
2、模块化实际上每个公司都在做，而且几乎每个公司都可以举出一些例子证明自己其实是有部件或模块通用，但是，缺乏顶层设计思维的被动模块化是无法产生大的效益的；
3、模块化设计只有通过对过去设计的精细化梳理，系统的顶层设计，持续不断的迭代优化，才能取得巨大的进步，而这需要的不仅仅是执行力，还要有耐心和时间；
4、任何公司推平台化最大的问题就是最终执行者是否愿意花功夫，是否能够接受一轮又一轮地对过去每一种设计的分析，对最终选择方案的研讨，这需要耗费大量的精力；
5、对于客车来说，BB、GB件居多，设计人员对技术的细节了解不够，如果要推行，必须调动供应商的资源，必要时可以采用驻点工程师的制度。根据我过去的经验，主动与供应商进行这样深层次沟通，以期达到多个车型共用零部件的目的这样的事情供应商也是非常欢迎的；
6、平台化、模块化是一个整车各系统不断僵持、不断磨合、不断妥协的过程，是一个非常繁杂的管理管理工作。设计部如果缺乏锐意进取的文化，是没有办法完成的。
知易行难，产品的平台化、模块化实施本身不是技术问题，而是技术管理的成熟度问题。最重要的是，无论做什么，都不能光靠搞运动拉动，而要系统的规划，精心的实施。
