DevOps赋能软件定义汽车
本帖最后由 FYIRH 于 2022-5-26 13:17 编辑在与整车企业数字化转型和DevOps落地的过程中，最大的难点在于改变人的理念，或者改变制造企业从高层或中层的管理思维。某种程度上实现技术的方案或搭建技术框架，相对容易推进。因为整车的制造型企业目前仍然是严格的科层式的管理。从具体业务经办人员，数量庞大的供应商，基层&中层管理者，业务流程基本都是线下的，并没有显性化的内容。企业信息化的阶段，我们只需要提供软件工具，但是在数字化转型过程中，我们要把线下的流程线上化，让know-how流转起来，形成企业内部的数据流进而驱动业务创新，这个是困难且严峻的课题。
以上介绍完背景，开始我今天的演讲，分三个部分，第一个是软件定义汽车时代，这部分主要讲整车企业目前的业务需求，刚才提到了整车企业业务域从采购、研发到营销，需要全链条拉通业务价值。
第二部分是在与整车企业合作过程中怎么将DevOps端到端交付在项目中的落地路径与实践。
第三部分是未来展望，整车企业对于未来的业务，他们有哪些期待。我们从数字化转型或从业务系统的构建的角度，怎么给他们提供支撑。
一、软件定义汽车的时代
汽车行业是积淀非常深厚的行业，无论流程的经验还是业务的经验。这是1771年由意大利工程师发明的内燃机车，这台车是奔驰，而且这辆奔驰是电动化的，不要认为汽车的电动化是很新的概念，因为从1886年开始奔驰就在走电动化的道路。这个是福特的T型车，汽车生产行业里很多生产实践是从这里来的。特斯拉进入这个行业确实产生了颠覆性的影响，汽车企业都在学习它的实践，所以后边很多数字化的实践也是从特斯拉的实践参考而来的。
在理解汽车行业前要对供应链有深刻的认识，会造成很多目前汽车企业很多的困局和亟需改变的地方。这是Tier1的供应商，他们是将整个集成比如说传动域也好，EPS也好，提供给整车供应厂商。这样的供应链会带来什么结果呢？一是，供应商缺乏差异化的欲望，只有共通化成本才会低。二是，产品变革慢，因为反应链条太长，所以传统车企只能以年或者数年为单位进行产品迭代。
当前汽车行业的发展趋势是什么呢，是软件定义汽车。汽车从一个硬件和机械定义的产品，逐渐向数字化生态化转变，在这个过程中，整车企业需要解决两个关键问题：一个是品牌力，用自己的IP聚焦人气；另一个是功能差异化，如何在万物互联的背景下实现个性化功能。
无论特斯拉，还是传统IT巨头，例如百度、阿里等入局了之后，他们用互联网思维做了很多事情，基于这样的新的尝试的基础上，汽车厂家对未来也有相对比较清晰定位。第一个是整车的产品，第二个是增值服务，大家如果定特斯拉的话，可以另加购买定制化的软件增值服务。第三，车不再作为一种固定资产，而是作为一种可以随时呼叫的出行服务-MaaS，比如说根据目的地的一些推荐，一些其他的增值服务，未来整车企业希望往这三个方向上进一步发展和努力的。
在这个过程中，整车企业目前正在做的尝试主要是五个方面，第一个是新鲜感的强IP，特别是国产整车企业，纷纷推出自己的高端品牌。后两点是打破通过4S店销售，这是一个消费领域的变革。关于正向研发体系，在国内以前很多厂商做的最多的事是拆车，买了辆进口车型，买回来以后拆开看看是什么样的，现在对于国内整车企业来说，建立自有的研发中心，实现产品研发的正向流程是亟待解决的问题。
另外一个是敏捷响应业务需求，刚才听到了敏捷响应业务需求对汽车行业来说到底有什么价值，我个人理解有两点，刚才也提到了，通过软件投放，比如说特斯拉有一个很好的例子，刹车距离是50米，后来特斯拉进行了刹车系统的OTA，经过了OTA系统之后缩短了很多，从娱乐系统角度来说可以更新的和增值的更多了。
现在的车企也是在探索中的状态，我个人理解现在主要三个方面，第一个是组织架构，越来越多整车企业成立了自己的研发中心，一般会按照比如说电子电器架构，车联网、新能源，传动，设立专门的研发部门。
第二个是招聘，大规模的招聘软件研发人员，买了很多的研发工具，比如说造型设计、研发测试都在大量在投入。
整车企业做了以上措施之后是不是足够了呢？其实发现痛点有很多。第一个是缺乏顶层的数字化转型框架，整车企业的研发体制，是以域来划分的，比如说动力域、传动域，或者说软件域，各自做各自的，一定无法产生1+1等于2，或者1+1大于2的作用，买了很多研发的设备都是重复建设，老板觉得花了很多钱，招了很多人，但是真的能形成战斗力吗。
以上是他们在数字化转型过程达到端到端价值交付的痛点做了一个整合，以下是我们提炼的关键性的做法。主要有四点。
第一个是牵引整车企业做全局性的数字化战略。第二个是在整个业务架构方面，怎么从临时的项目型的团队向领域型的团队做变更，做逐渐的改善。第三点是坚固合规性和敏捷的研发过程，在制造业里面，需要强调的一直是标准化的研发流程怎么去定义怎么去落地的问题。第四点是通过业务驱动的价值，相关的一些数字化系统的实践，后续我的介绍也从这四个角度展开。
首先从数字化转型的第一步，得有高层介入决定数字化转型的战略和定位，这是很多整车企业或制造型企业做推动的时候最缺乏的。无论是业务流程重构，还是跨领域的数据采集，没有企业高层的参与和部署是做不下来的。然后从整个企业的架构，数据开发和运维角度来说，也需要跨部门的协同建立数字化转型的组织，才能够推进下去。
从组织的角度，各个层次的人员都加入进来，第二部分要设计覆盖整体业务流的过程，整车研发是链条非常长的，从车辆企划到营运，各个层面都会参与，并不局限于整个域内，而是整个过程的协同，从数字化转型过程，也需要构建基于企业级各个部门的协同。
二、DevOps落地实践
在这个过程中会采取一些数字化愿景确立，数字化方案落定的方法论，通过内部调研，外部输入，外部收入会广泛的收取客户、供应商的心声，包括行业洞察，设定数字化转型的标杆，最后推出企业的数字和愿景和数字化转型的路线图，划定三到五年的长期战略。
基于这样的过程之后会得出整车企业的数字化蓝图，整体结合各个企业的现状，会得出这个企业的愿景，包含了当前的年产量是多少，市场份额占领多少，从品牌的角度来说，以一个什么样的品牌或什么样的竞争力来在市场上出现，围绕整车企业的企划、研发、生产、营销，在这四大域里达到什么样的目的，实现什么样的价值。为了达到这样的价值，需要跨越整车企业集团平台的协同部门，在架构、数据治理、资源管理和风险管理做怎么样具体的落地措施，从组织的文化，人才的建设，怎么样支撑整体的数字化的战略，这是最后在数字化转型之前，最后整体拉齐认识的目标。
以上是我们从整体的数字化架构构想的内容，包括实施的措施，下面是具体落实到人，需要稳定的领域团队来推动整个数字化转型和敏捷落地的过程。首先再提一个康威定律，这是目前我们接触到的企业的实际情况，在这个企业里有一个IT部门，支撑着上面的业务部门，业务部门有成品的导入和定制化的开发，一般有一个什么样的设想，找一个外部的供应商团队，把这个想法一讲，供应商负责需求的定义，及开发后期改造的过程。企业IT部门只是提供基础的运营平台，保证基础的云服务等等。如果是以上的架构，很典型的是竖井化的领域阻碍，应用交付标准不明确，质量无法有效管理，也就是1+1小于2的效果。
在垂直领域里划出领域域，只是负责相关功能的实践和技术演进的迭代。以整车的造型设计为例子：整车的造型涉及到整车的外形的设计，比如说车门、翼子板的设计，这里面会用到很多现在主流的CAE，3DS的工具来做相关的设计和演进。以前整车企业做造型设计的时候有一个油泥模型设计的环节，但是现在会完全通过数字化的手段，来把造型的设计在整个3D空间里做实现，通过工具赋能，将业务团队的精力聚焦在怎么逐步提高数字化仿真造型和仿真造型的精确度上，而将相关的共通服务，文件管理，放到企业级服务里面，在业务域内实现功能的迭代和强化。
基于这样的构想，在整车企业会构建三种类型的团队，第一种是业务领域团队，聚焦特定领域的技术研发，持续为业务领域创造价值，通过反馈进行改善。
第二点是基础架构团队，聚焦于整体企业级数字化平台的组件的开发，怎么为大家提供项目管理平台，流程设计平台，以及相关的权限管理平台，提高整体平台运营的安全性、稳定性。
在企业数据治理团队，会进行数据胡的标准的定性，进来的业务数据怎么进行统一的编码，进行数据的管控，形成企业的过程资产，支撑各个业务域作业效率的提升。
第三点怎么在研发过程中落实合规性和敏捷的研发过程。这个是传统车企的企业研究院的现有架构，大家可以看到，在整车研发域是整车级的研发中心，下面有设计开发部、产生管理部，不同的车型来了以后会分配到各个车室里面进行管理，这是组织架构的现状。这些科室之间一直在重复建设，比如说车企相关的软件测试的设备，硬件测试的设备，原代码管理的平台，各自为政，各自做各自的，相关的交付，科与科之间的交付是线下流程，如果关键人员离职了，很有可能相关的资产就流失了。
这个也是我们在前期做的调研结果，在研发过程中，从成本角度来说，整个车辆研发占40%的时间，导入量34%，整个车辆研发流程数字化转型对于车企价值提升效果是非常明显的。这里面需要解决的问题是刚才提到的断头的链路，没有标准的实验库和数据，依赖个人经验做的一些事情。
改进的思路，总结下来是三点，首先建立整体的研发框架，例如以IPD为主体框架的研发体系。在软件和硬件部分，同时引入数字化的基础设施。
怎么把研发数据或产品数据，从产品构想一直到售后拉通起来呢，就是靠BOM-物料清单，经过这么多年的迭代和发展，物料清单的文档已经能够成为车企研发的主轴，比如说BOM数据会加入树状的结构，把每个节点再打开，会形成零部件的表，软件在车辆中的比重越来越大，在很多车企里也加入了软件的BOM信息，再往下的时候，BOM表里会加入工艺信息，简单分为冲压、铸造、锻造，相关的BOM零件，进行了机关焊接这些工艺的过程也会加入这个信息里，再往下到了制造线，具体BOM表会结合物料信息，发动机的编号，完成整个生产环节的信息的组装，再往下游传递，会加入比如说4S店的销售信息，保险信息，维修信息，通过BOM表的演化，从整个车辆的研发设计到生产制造到销售的信息都加进去，为了达成这一点，需要数字化的支撑平台和BOM的数据平台，最后这些数据根据权限分发到不同的部门，包括会分发到外部的供应商。
第二点是怎么做车企功能研发这块，现在是以车辆为单位进行研发，新车会做一个构想，需要有什么样的功能，预计的售价是多少钱，预计在什么时间上市，围绕这个车的卖点和成本的要求构建研发的过程，这是以一个产品为研发的流程，但是重复劳动比较多，相对而言会延长整体研发的时间和周期，所以现在在车企里，在数字化生产和数字化领域里，希望做得叫做基于产品工程的管理PLM，基于产品工程的管理的核心思想是，我作为一个整车企业，要构建我这个整车企业的功能组合清单，这里包含了整车相关的功能池，比如说自动导航功能，车道预警功能，包括硬件的功能，比如说这个企业目前的发动机组引用了哪些，电池、电动机的规格，会形成一个产品的portfolio组合。
下面是我们目前的产品化的实践，因为文思海辉也提炼出了相关的支撑车企数字化的产品，下面是数字管控的实践，基于文档化的协同，对外输出一些相关的PDF或一些文档，还有一个是测试服务化，测试这个事情在整车企业确实是非常重要的事情，一旦产品质量出现问题，按照法律法规，对车企的损害是非常大的，所以车企也非常重视测试这一块，我们也是在项目管控平台中，把测试代码级的，形成了一个测试化的服务平台。这个图是我们给某一家国内的整车企业搭建了项目管控平台的整体流程图，把相关的研发、测试、验证的系统进行串联，通过portfolio进行管理，进入生产系统里，直接向终端用户投送，达到端到端软件的投放。
由于这款产品是面向整车企业的，可以进行深度化的定制，包括插件化的集成，比如说整车企业买研发工具花费了上千万的费用，不可能因为整体化的应用，把既有的资产动抛弃了，所以会通过插件化集成。
现在可以选择内饰的颜色，外面的颜色，整体进行定制化之后，如果进行柔性化的生产，这个批次里可能什么样的车型都有，怎么支撑可定制化的生产，最后交付的时候，不但要考虑整车的一次性交付，考虑每周每月的软件的OTA，或者怎么样提供增值服务。
另一方面刚才提到了业务价值，从我们在整车企业的研发角度来说，这是传统的敏捷的模式，业务人员到需求，项目人员去开发，最后验收，实际目前也有一个业务人员、开发人员和运维人员统和，包含了业务部门、信息部门，数字化建设部门的小型团队，不断的实现业务的快速迭代。（转自 吴畏）
页:
[1]