整车开发流程第一章-整车开发概览
“ 最近看到不少文章写产品开发流程，发现其中很多都是属于供应商交流的，属于泛泛而谈而非真正的产品开发流程，其中也不少通用流出的GVDP，这个是产品开发流程大概流程都描述出来了，但好像是比较老的版本，思考是不是我们也来共享一些最新的汽车开发的流程，但想了很久，第一怕侵犯知识产权，第二其实流程还牵扯到职责分工可能一个简单的流程框架和解释是不能够完全表达出精髓，所以也就纠结很久，或许以后有机会再分享吧。但是汽车开发流程是汽车开发的软实力对于汽车稳健高效开发至关重要，觉得很有必要写点什么然后搜寻了不少资料发现《
AutomotiveDevelopment Processes
-ProcessesforSuccessfulCustomerOriented VehicleDevelopment》
这本书写的还不错是供职于宝马和克莱姆森大学（Clemson University）Julian Weber写的，他没有直接从开展开发工作流程出发，他出发点是以客户需求为导向然后展开开发流程，我们试着去翻译然后结合自身经验去解读这本书或许可以给国内从事汽车开发的人多一些启发know why and know how”
前言：
Julian Weber写这本书的时候正是08年全球金融危机，这个时候各大主机厂倒闭裁员，貌似和现在2019有那么一点类似。不但越来越多的主机厂和相关配套供应商思考怎么投放正确的车型到市场，市场到底需要什么样的车辆；同时各种咨询公司，媒体，甚至政府相关都在思考汽车如何被开发出来的。他当时写这本书的主要目的是从大概上不但让从业人员也让非从业人员能够了解到汽车开发的过程。
在卡尔本茨，迈巴赫，戴姆勒发明汽车一百多年之后，乘用车的概念并没有改变太多，虽然零部件经历了大量的优化。汽车还是由动力驱动然后通过传动系统到半轴再到轮胎，然后通过悬架让车辆稳定和舒适的行驶；再通过转向系统转动前轮实现控制，最后通过驾驶员和乘客坐在座椅上和前面显示屏与汽车交互。
然而发生巨大改变的是汽车开发流程，当初设计汽车只需要一个或者几个工程师全部开发完。但现在需要不同领域的专家高度交叉协助完成。这样汽车开发过程变成许多去中心化的子流程交互交互复杂的过程，许多汽车管理层都希望有一个详尽的流程，但这是不切合实际的如果有的话那么他出现了可能立马就过时了，这就是为什么很多主机厂的开发流程一直都是再发展和变化的，所以开发流程总是迭代更新的现在网络上看到的都是非常老的流程。另外一方面汽车的需求一定是根据经验，偏好，和当前潮流的结合体而不是跟随一个一成不变的详细计划。即使是当前最有效率的主机厂他的流程也是高度特殊的没有固定章法适用其他主机厂。比较最终汽车都是关乎于人。
正是这种双重挑战，技术整合成整车通过各个零部件，同时协调来自于不同公司不同领域的甚至不同文化和社会背景的人。这样让汽车开发变得如此的具有挑战性和吸引力。所以Julian Weber这本书的基础是，第一是客户相关的车辆性能，第二是开发人员个人目标，他们的想法以及如何协作。
书总共有八个章节，第一个章节就是本文需要介绍的
整车开发项目概览Vehicle Development Projects - An Overview
1.1
—
整车开发项目分类
Categories of Vehicle Development Projects
汽车行业开发通常是以项目形式组织，但是项目开发中关系到的技术内容，财务，时间跨度差异非常大，驱动项目大小的主要内容总结如下：
开发的级别
开发内容
开发创新度
配置以及不同市场版本
1.1.1 开发级别
开发级别主要为了描述项目的开始位置，从而确定所需要的工作量和所需资源通常开发的级别包括：
全新开发，从草图开发，造型和零部件都是从重新设计开发，通用件和借用件通常不可见的，行业内汽车的生命周期是7年，意思是车辆每七年要全新开发一次，重新开发需要大量的物力去计划，设计，测试因此是最费力的项目
变种开发，在现有平台和架构上面重新设计一款车，但是很多零部件和系统都坚持最小的改动，他的原则是客户第一眼肯定认为这是一款全新车型，他们意识不到这款车型源自于哪款车。
子车型开发，子车型开发与变种车型开发恰好相反，他们呈现的就是来自于一个系列，通常是上车体的差异，例如轿车下面衍生的酷派车型，旅行车，敞篷车。这种开发通常除了平台架构共用还包括大量的内外饰，这种项目的大小主要取决于子车型是否已经在基础车型开发时候已经规划在车型线里面。
改款升级开发，如之前全新车型讲过一般全新开发车7年的周期，其中每隔几年还需要进行改款升级保持销售卖点。他一般包括外形更新facelift，内饰升级增加颜色等等，主要是在维持低成本开发投入下增加新鲜度和卖点
年度改款开发，年度改款车型一般是降本和提高质量，通常是开发车型上市之后一些质量反馈和降成本点子的捆绑。
1.1.2 开发内容
开发内容是基于对开发级别的物理和软件进行进一步解读，主要看开发的复杂度，越多复杂的改变意味着越多的投入到开发，评估和验证过程中。开发内容主要包括：
零件的数量
电控单元的数量
软件代码的数量
1.1.3 开发的创新度
汽车产品的科技创新度是一个主要的吸引潜在客户的点，当然他们的开发投入增加不但牵扯到设计，更牵扯到关于稳健的测试，确保创新产生的新问题在提交客户手上得到优化和解决。
例如全新材料的使用，例如某款车型在前车结构由于轻量化等创新技术使用，那么他的碰撞，腐蚀等评估验证都需要重新进行从而带来大量的评估验证实验确保创新的稳健。
1.1.4 配置以及不同市场版本
配置以及不同市场的版本主要是由于他们之间产生的复杂度。每个版本直接产生的不同关联验证。一般豪华品牌通常提供一些列自由组合的选配，从而让顾客自由选择自己所需。虽然这些选配能够提供车辆的满意度并触发购买，但他们增加了成倍所需的验证工作。
从选项中减少复杂性的第一种方法是捆绑它们。例如，如果可以选择三级立体声系统（无、低、高）和三级导航系统，则这些功能有九种设计组合。由于高立体声与无导航组合或无立体声与高导航组合的接受率通常很低，因此仅提供三个立体声/导航捆绑包可能是有意义的：无/无、低/低、高/高-从而节省了六个组合的评估工作。
一些日本主机厂遵循的策略是只评估最常选择的20%可能的组合，这通常代表超过95%的订购车辆。如果客户选择了之前未经评估的配置，则会立即对其进行评估，从而导致该车辆的交付时间稍有延迟。
除了客户方面的配置，还有不同市场的特殊法规，所以还要考虑不同市场版本，例如不同的安全和排放标准，但一般主机厂都大致考虑三个版本，欧洲市场，北美，右舵市场。
1.2
—
平台以及车型序列
Platforms and Model Lines
一个被行业广泛认可汽车开发更快和低成本的既定方法是在不同车型和平台上共用零件，共享标准化的模块例如电子电器模块，底盘，动力模块到不同的车型，品牌，子车型甚至不同主机厂。这样做有如下好处：
减少零部件设计和验证的时间和成本
减少工装夹具的需求，减少设计，生产，装配和保养的时间和成本
增强质量通过使用成熟和熟悉的零部件
应用平台架构主要使用在不可见或者无车辆可见差异性的地方。平台以及车型序列就是集中使用这些零部件的两种常见策略方式。
1.2.1 平台
平台是共用一系列通用零部件在不同的车辆上面，甚至可以是不同的品牌上面。他的目的是通过共用这些零件同时使车型达到最大的差异化。但许多niche 车型（小众车型）例如跑车或者SUV 将不会很经济如果不是共用现有车型架构。
或许当代最一致性的平台战略是来自于大众：例如Golf 的PQ34平台被4个品牌13个不同款的车使用 其中动力，转向，悬架甚至下车体，内饰都被共用，然后使用上车体，部分可见内饰定制化从而实现差异化，甚至有些差异化就是品牌标签，例如大众和斯柯达的方向盘就是方向盘上的品牌标签差异。
3 Engine, gear box, engine mount, front axle, steering gear, steering column, gear control, pedal system, rear axle, brake system, fuel system, exhaust, wheels, tires, front body structure, bulk head, lower body structure, rear body structure, seat frames, platform harness.
1.2.2 车型系列
对于平台车型来讲，你很难通过外表来识别他们是否共用同一平台，但车型系列他表达的是让你不但从技术上，甚至从外表上你都能感觉到他们是一个家族的，例如宝马3 家族。
过去，车型系列产品是根据第一台成功车型进行再设计和衍生的，在这个过程中很多被认为共用的零部件不得不进行更改，这样破坏了成本预期。然而真正高效经济的车型系列设计，是在第一条车设计的时候就已经做好了车型计划，他们共用零件的计划。基本上计划都已经做在第一台车上市的时候其他都不能随意改动，基础车型的下车体必须设计能够证明灵活的适用于车型系列的上车体。即使是基础车型投产了若干年，这个一致性计划战略必须保持否则盈利模型得不到保障。
1.2.3 副作用以及约束
虽然一个一致性很好的平台肯定对整车开发提供成本和时间的优势，但如果整车集成优化和调教的潜力有限（整车集成调教例如动态驾驶性能在不改变零部件物理结构时候进行汽车性能的定义）则会对整车性能性格（可以说是vehicle attributes 或者vehicle characteristics）产生负面影响。从整车角度出发好的差异化定义是在真正共用件（不改变的传动轴和轮辋）和可调教零件（例如减震器，发动机悬置，轮胎等）之间。所以这种更精细的方法需要更深入的了解各种零件对于车辆性能，性格的影响（车辆性能和性格是人类感知汽车的感觉，例如驾驶感觉，驾驶舱舒适性，主动安全，等等第七章我们会谈到）。这也是唯一一种方式优化产品同时保持开发流程高效。
1.3
—
产品开发流程
The Product Evolution Process (PEP)
产品开发流程也叫，产品投放市场的时间过程，总结所有的设计，测试，量产活动和事件。
为了指导产品开发计划，每个主机厂都有自己详细的流程，被称作“秘密配方secret recipe”。他们定义了里程碑，详细定义交付物，定义流程链条和角色，虽然每个主机厂的流程都是不同的并且高度机密的但是行业内总体都是以上讲到的。
要彻底讨论开发流程，必须从不同的维度看，如果从时间线上来看，策略阶段到系列支持。如果从流程角度，从零部件设计到集成过程再到支持流。一般V 型结构能清楚展示我们是在系统设计还是集成。
1.3.1 开发流程各个阶段
整车开发的第一个阶段是产品策略阶段。他可以大体认为，什么车型，什么时间导入到市场，创造和更新产品策略意味着持续长时间的计划规划过程。
项目策划以及开发前期都是一个持续的过程，但他们不是实际的项目工程开发阶段。我们下一章会具体讲到。
虽然每个主机厂叫法可能不同，但大致的项目开发主要区块为三个：初始阶段，概念阶段，系列开发阶段。如下图所示：
初始阶段，设定计划
概念阶段，达成一致的技术和财务目标
系列开发阶段，实现既定的目标
系列支持阶段，优化质量和成本保持产品吸引度。
1.3.2 产品开发流程
1.3.2.1 零部件开发流程
开发设计能力中心CoCs（宝马的叫法Center of competence）是零部件开发专家们集合的统称，例如座椅CoC 他们就是座椅专家们能进行座椅的概念，设计，测试以及和供应商合作等等。通过定义几何结构、指定材料、规划制造过程，将规范转换为系列部件，最终将系统发布到系列产品中，并在系列产品中使用。设计人员对零件满足规定要求的能力承担责任。一般主机厂分为如下六个零部件中心：
动力部门：发动机，驱动电机，变速箱，差速器，驱动轴，半轴，冷却系统，排气系统
底盘部门：轴，悬架，转向，制动，轮胎等
车身结构：车身结构（前部，底部，后部），钣金，门盖，门。
外饰部门：前后保，窗，门开关机构，外饰塑料件
内饰部门：仪表台，内饰板，地毯，座椅，空调等。
电子电器：传感器，执行机构，线束，电控单元，驾驶辅助，娱乐导航，电子安全系统等。
组织上，汽车外形总体设计部门属于造型设计，他们直接汇报给董事局，他同样包含美学相关零部件A面的设计，例如仪表的A面，轮毂的款式等等。
1.3.2.2 整车集成流程
整车集成流程通常用来定义和开发整车的性能和性格，与零部件工程师完全相反，他们不拥有任何零件，但他们评估和定义整车的性能和性能并且把他们的需求以及技术指导推荐反馈到零部件设计流程中。通过这些他们掌控零部件设计流程，以下六个主要就是整车集成流程：
几何集成，可以认为整车布置，定义和规定各个零部件区域，管理布置冲突和间隙（4.2会讲到）。
性能集成，站在客户角度验证和签发整车性能例如，动态，驾驶舱舒适性，被动安全等等（第七章会讲到）。
系统集成，系统集成是整车E/E系统的功能集成：需求管理、配置和变更管理以及开发、生产和服务方面的软件集成。由于其在过去十年中的重要性，系统集成与性能集成分开（5.2.6会讲到）。
生产集成是验证与生产有关的车辆特性以及提供所需的生产环境（8.1会讲到）。
服务集成是对与服务有关的车辆特性的验证，例如维修和维护的适用性（8.2会讲到）。
1.3.2.3 支持流程
为了能够开发产品，设计和集成过程需要额外的支持过程。人力资源必须在适当的时间和地点为人们提供发展项目所需的技能。特别是
项目管理团队成员的选择对于开发项目的成功至关重要。
财务部必须检查和提供预算，控制项目费用，以确保成本稳定。
采购部为采购的零部件或工程服务选择有能力的供应商，并通过分析和谈判价格为项目的财务作出贡献。
开发项目中的一项重要任务（尽管通常被低估）是内部沟通。内部沟通不仅为项目开发的所有成员提供必要的信息，而且为他们提供内部新闻或成功案例，可以形成真正的团队精神，从而支持项目的成功实现。
1.3.3 V 型开发流程
V型系统作为系统工程开发的基础，可以更深入地理解车辆开发项目过程中创造和分析过程的相互作用。从所需整车性能和特性的规范开始，V型模型中的向下走（沿V型的第一段）代表分解和规范-从整车要求到系统设计和仿真，再到零部件规范、零部件设计和评估。右边向上的一段代表 从零部件的验证到整合的签发。
和IT 系统相反，汽车开发需要几轮的样车装配和测试从而确保产品的成熟度，每一轮样车装配，都代表了一个小的产品实现过程。因此整车的V模型下面有很多小系统的V模型支撑。
1.4
—
开发项目管理
Vehicle Project Management
开发项目管理，是组织和管理资源（如资金、人员、材料、能源、空间等），使项目在规定的目标（范围、质量、时间和成本）内完成。它包括产品和过程开发过程中的计划、控制和决策。根据IEEE 1490（2003），项目管理的九个学科是：
集成管理
范围管控
时间管理
成本管控
质量管控
人力资源管理
信息交流管理
风险管控
采购管理
如前所述，车辆开发项目由里程碑构成，并附有规定的可交付成果。与其他项目管理方法相比，汽车项目管理通常设定里程碑，要求参与项目的所有过程达到一致的产品开发共同状态。
里程碑和相应项目状态的一个很好的例子是样车制造的开始。在日期设置上，设计CoC必须发布一组由集成过程签署的一致的部件。此外，生产过程必须协调，并与当天发布的车辆完全匹配。只有这种方法才能制造出最高质量的样车，从而在开发过程中获得尽可能高的信息价值。随着项目由一系列这些里程碑构成，所有活动都相应地同步。因此，它们也被称为同步点。为了确保所有的子过程都在同步点之间的正确路径上，他们又由许多小的签发和检查点。
1.5
—
全球开发项目
Aspects of International Development Projects
为了在日益全球化的商业环境中保持竞争力，汽车公司越来越多地跨越地区、社会文化和技术边界开展工作。采取全球行动使这些公司能够：
通过销售和服务其产品提高营业额
通过利用本地生产技术和人力资源高效生产其产品
通过在本地采购零部件降低运输成本和进口关税
通过花钱减少货币波动带来的风险与他们赚取的货币相同（自然对冲）
通过让当地工程师参与，更好地设计产品以满足当地需求
通过增加潜在供应商和开发合作伙伴提升市场地位
汽车行业全球化的这一战略要求原主机厂和供应商双方的设计工程师进行合作：能够在新市场销售汽车，必须考虑和评估它们是否符合当地条件和法规（例如，导航系统只能在汽车开发和制造国进行测试）。在国外工厂生产新车时，产品流程优化需要当地工程师参与问题解决过程。同样地，本地供应商的工程师也必须被集成到在主机厂的工程中心执行的车辆开发过程中。协同工程是充分利用全球化商业潜力的关键之一。要使其在现实中发挥作用，必须查明和处理好障碍。
两个主要障碍中的第一个是社会文化差异。文化首先是通过语言、衣着、习惯等进行接触，然后更广泛地通过思想、未言明的假设和价值观进行接触。例如，在美德团队中，基本的心理差异与个人主义和集体主义以及避免不安全感有关。个人主义者把注意力放在自己身上，而集体主义者把群体放在个人的前面。美国人比德国人更注重个人主义。在避免不安全感方面，美国人对安全的需求要少得多，对个人创业思维和个人能力更有信心。德国人是正式的，想用系统的过程，美国人是非正式的，想即兴发挥。德国人想花点时间做出决定；美国人想立即得到结果，即使是基于最少的信息量。
这些差异再次出现在语言和交流过程中：一般来说，美国人更简单、精确、非正式、幽默和友好；德国人更复杂、详细、正式、含蓄和直接。最后，当我们考虑跨越大西洋的通讯时，距离会产生必须被认识和克服的障碍。例如，在走廊里没有机会讨论某个话题。合作伙伴必须努力建立沟通渠道。传播媒介本身并不容易捕捉到受众的情绪，例如，由于使用电子邮件将思想翻译成文本的不完整性，常常会产生误解。因此，协作要求当事方加大沟通力度，意识到可能出现的问题，因此在澄清要点、要求详细解释以避免误解方面发挥积极作用。
除了“软”的社会文化差异外，商业环境也存在差异：必须考虑技术、教育和法律事实，以确保成功的国际合作：
技术边界条件：气候差异可能对胶合等制造工艺的转移产生负面影响；电力供应不仅在电压上不同，而且在频率和稳定性上也不同；对工人的专业教育可能需要对如何在不同国家进行详细描述。
材料和标准零件：不同国家的工程师喜欢不同的材料，并收集了有关使用这些材料进行制造、加工和设计的专门知识。虽然也有其他材料，但它们通常很贵，而且被认为有点异国情调。紧固件、执行器、软管、密封剂等标准零件在尺寸、几何形状和规格/性能方面有所不同。
开发标准：材料性能、试验、公差和制造工艺由不同的标准规定，例如在欧洲，根据DIN/EN/ISO，在美国，根据SAE、ASTM。
法律背景：国际合作的一个重要边界条件是提供适用法律的法律制度。忽视当地法律体系的特殊性，对外国公司来说，可能是非常高的风险，不仅涉及产品责任。其他重要的法律差异领域包括专利法、医疗保健或营业税。
总之，公司必须考虑到不同文化、技术和法律方面的差异，必须权衡合作可能带来的收益和克服上述合作障碍。另一方面，协作带来了不同背景和经历的人的集体思维过程。解决方案的丰富性通常是可以预期的，而为开发产品的市场量身定制产品可以提高市场接受度和渗透性，从而提高公司的声誉和市场份额。
总的来说Julian Weber 对于产品开发流程的概述还是比较全的，从整车开发分类到平台和产品线再到流程，管理。非常明确的把整车开发的主线以及周边讲清楚。一个产品开发流程需要考虑到以上的东西，不是简单分享一个流程而已，一般明白背后的东西你就能更多的知道为什么，知道怎么做。