麦肯锡：软件驱动的新价值链上把握住关键的控制点

菏泽炫佑科技

麦肯锡：软件驱动的新价值链上把握住关键的控制点

报告发布者/作者：麦肯锡公司等

由于软件正在推动汽车行业的创新，车企研发部门必须快速掌握软件开发的复杂能力。

软件正在迅速重塑汽车行业。 近年来，行业的四次颠覆浪潮——自动驾驶、互联、电气化和共享（ACES）——都严重依赖先进的软件。 这些领域未来将迎来更具颠覆性的发展。 整个行业的原始设备制造商、供应商和新公司都希望能够抓住这个由软件驱动的新价值链中的关键控制点。 软件：一个关键的行业转折点

随着行业格局的变化，缺乏软件能力的车企将面临重大风险，包括量产（SOP）延迟和预算超支等。 如果他们能够更快地将更新的产品推向市场，他们甚至可能落后于竞争对手和新进入者。 更糟糕的是，软件问题可能会导致大规模召回，或者让汽车公司无法防范黑客造成的客户安全风险。

我们的研究表明，软件能力强的公司和软件能力弱的公司之间的差距很大，能力*强的公司报告的产出和质量比能力*低的公司高出三到六倍。 这种开发效率差距比不同能力的硬件制造商之间可能出现的差距要大得多。 许多车企已经意识到强大的软件开发能力所带来的各种优势，并正在采取大刀阔斧的措施来提高自己的业绩。 一些车企计划在未来几年提升软件能力，招聘数千名软件工程师； 其他人将重新定义治理模式，建立伙伴关系，并在全球范围内推动软件开发卓越中心。

然而，我们认为这些措施还不够，因为只有当车企更新软件开发的基本运营模式时，真正的改变才会到来。 根据我们的研究，只有 40% 的汽车研发领导者将软件视为主要颠覆者，认为他们已经为必要的运营变革做好了准备。 尽管一些领先的汽车公司在软件工程实践方面取得了长足进步，但大多数仍远远落后于领先者。 目前车企的问题集中在几个方面：敏捷实践、持续集成、自动化测试。

软件开发转型的风险如此之大，车企必须重新思考一整套软件开发方法，包括基本的运营模式。 本文分享了我们通过与汽车制造商、供应商和生态系统中的其他合作伙伴密切合作获得的关键概念和见解。 这些见解基于对技术专家的广泛采访以及使用麦肯锡专有数据库进行的大规模基准测试。

让数字说明一切：软件的重要性如何后来居上

几个趋势凸显了汽车软件日益增长的重要性。 **个趋势与软件和电气/电子市场的快速扩张有关，预计2020年至2030年将实现12%的复合年增长率——是普通汽车销量预期增长率的三倍以上。 多个领域正在经历*强劲的增长，包括软件功能（复合年增长率 11%）和集成测试（复合年增长率 12%）。

复杂度持续上升，但开发效率进步缓慢

无论是功能层面还是架构层面，汽车软件的复杂度都在增加，但开发工作的效率却没有跟上同样的速度。 我们的研究表明，过去十年软件复杂度增加了四倍，而软件开发效率仅增加了1到1.5倍。 这个问题在信息娱乐系统和高级驾驶辅助系统 (ADAS) 等变得越来越复杂的大型模块中*为严重。 与传统的深度嵌入式软件相比，开发这些模块的效率大约低25%至35%。

这种不断扩大的差距可能会影响汽车公司未来的成功。 车企需要在软件生命周期内投入更多的资源来开发软件和维护软件，这可能会削弱其创新和应对竞争对手的能力。 一位企业负责人在采访中注意到，如果复杂性不断增加而效率不变，仅靠软件维护就会很快耗尽所有软件开发资源，没有创新的空间。 。 *终，复杂性和效率之间的差距将削弱成本竞争力，导致严重的财务和声誉问题。

可以看出，软件开发能力排名前25%的企业，其效率比垫底的企业高3倍，生产力高3.5倍，质量高6倍。 因此，他们的产品上市时间更短自动化软件开发，各个软件功能级别的开发成本也更低。

在硬件方面，强弱企业之间的业绩差距相对不太明显，因此在该领域追求差异化的机会较少。

降低复杂性，同时提高效率

为了在这个快速变化的环境中取得成功，公司应该通过减少开发和维护软件所需的工作来尽量减少复杂性。 该策略涉及限制每个平台和生命周期阶段的功能和特性的版本数量。 同时，企业必须增加组件的重复利用。 至于开发效率，企业应尽量将软件开发速度与数字原生企业相匹配，以提高开发效率。 由于软件创新的整体水平不会下降，因此公司还必须增加软件开发和维护的产出，以便提供在市场上取得成功所需的产品和服务。

降低复杂性、提高效率需要新的软件运营模式，主要关注四个维度：开发什么软件，包括架构、设计、需求； 软件是在哪里开发的，以及企业内哪个部门开发的，包括位置、人才和合作伙伴关系； 使用什么方法来开发软件。 该维度考虑开发工作方法，例如大规模敏捷开发，或者开发和测试流程的变化； 使用什么方法来促进软件开发，包括性能管理和工具链基础设施。

**个维度——开发什么软件——重点是通过模块化和解耦的硬件/软件架构、以用户为中心的设计和需求管理来降低开发复杂性。 其他三个维度侧重于通过提供适当的结构、流程和基础设施来提高软件开发的效率。 我们从四个维度出发，确定了 11 个*佳实践，可以帮助车企成功解决所面临的软件挑战。 理想情况下，公司将同时解决所有方面的问题。

开发什么软件：架构、设计和需求

在新的运营模式下，企业必须将软件相关的发展目标和商业机会转化为产品、功能和模块层面上可行的架构、产品和组合需求。 通过这个过程，企业可以更多地了解可以为他们创造价值的软件类型。 这一过程还将帮助企业降低架构的复杂性，应用以用户为中心的设计流程，并改进软件需求的管理。

降低架构复杂度

根据我们的研究，如果汽车软件模块化程度不够，就会增加设计的复杂性，增加项目的整体难度。 此外，汽车软件的架构组件边界通常不太理想，这有可能导致更多的相互依赖性，并成倍增加开发人员在添加新功能时必须修改的组件数量。 这些依赖性还可能产生这样的后果：当检测到缺陷时，需要更长的时间和更高水平的专业知识才能将错误追踪到特定的软件模块和开发团队。

为了解决此类问题，OEM厂商必须显着提高标准化和模块化程度，使软件能够跨平台扩展，并将软件复杂性维持在可管理的水平。 车企还必须重视两项工作，一是推动软硬件解耦，二是应用面向服务的设计。

解耦架构。 汽车制造商可以引入强大的中间件层，用它提取硬件能力，并通过上层使用的标准化应用程序编程接口（API）将这些能力开放给软件功能。 这种软件架构可以利用平台之间的共性来降低设计复杂性并消除多次开发相同软件的需要。

除了解耦之外，车企还应该创建一系列标准化操作系统，并用它们来支持各个组件之间的协调，以确保互操作性。 许多公司已经宣布了开发此类操作系统的计划，但目前还没有统一的方法。

而且，企业还没有明确这些系统的具体研发重点和功能。

通过遵循清晰的架构原则和指南，企业可以有效地应对更高的系统和软件复杂性。 硬件/软件解耦允许多个实体参与模块化开发。 反过来，模块化软件构建技术增加了代码重用，并由于代码通用性的增加而减少了所需的代码总量。 许多公司已经开始引入软件产品线工程（PLE）方法，以在处理产品变更的同时提高重用性。 这种方法使一个软件能够服务于多种产品、产品变体和产品系列，并且与不同的硬件版本兼容。 软件PLE显着降低了开发和测试的难度，这两项工作只需完成一次。

换句话说，将硬件与软件解耦可以实现硬件的进一步“自治”，其中硬件提供标准计算、存储、输入/输出和电源功能，而软件定义*终用户功能。 对于需要标准性能的应用程序，可以使用虚拟化和容器化技术在同一硬件上运行不同的软件功能，并在必要时动态分布到其他硬件（例如，在发生硬件故障时）。 对于具有实时性能要求的应用（例如 ADAS），特定于硬件的软件开发对于实现*佳效率仍然至关重要。

面向服务的架构。 该架构应遵循各个服务的定义，而各个服务又应将业务或用户需求编码化。 面向服务的架构设计不仅可以让企业标准化各个核心元素，还可以标准化部门、业务单元之间的接口。 企业还应该将标准化设计应用于各个硬件和软件元素麦肯锡：软件驱动的新价值链上把握住关键的控制点，以便可以在不影响性能的情况下为其他支持设备和功能大规模配置计算和存储资源等资源。 面向服务的架构对于 OEM 来说尤为重要。 实现车辆到云端的快速连接，不仅能提升车企各类车型的长期价值，还能促进车企能力快速更新升级。

2.应用以用户为中心的设计技术

在各个行业中，专注于开发强大的以用户为中心的设计并创造*佳用户体验（UX）的公司将获得更高的财务回报。 随着 ACES 概念不断受到关注以及软件定义汽车成为常态，这些功能对于 OEM 的整体竞争力将变得越来越重要。 即使是顶级公司也需要改进，因为汽车行业在设计良好的软件用户体验和提供*佳客户价值方面仍然落后于其他行业。

遵循*佳实践中体现的设计原则，原始设备制造商应与*终用户合作，在交付之前和之后迭代新软件。 汽车制造商还应该采用新的交付模式，以便每周或每月进行软件更新或添加，以实现持续优化。 这些工作比传统的软件开发工作要短得多，后者通常需要几年的时间。 新的交付模式的另一个好处是，它允许 OEM 实现与客户的持续直接联系，使 OEM 收到持续的反馈，这有助于他们优化软件需求并提供积极的用户体验改进。 当 OEM 依靠硬件来实施升级时，这种类型的交互是不可能的，因为仅在通过经销商网络进行一次性销售或市场调查期间才会发生一次接触。 为了达到这一目标状态，原始设备制造商需要具备必要的先决条件，例如支持软件和电子架构，以及支持云更新的工具链。

想要成为用户体验领导者的 OEM 必须充分利用他们的数据。 随着车载软件和传感器数量的不断增加，原始设备制造商现在可以访问大量数据来了解客户如何使用他们的汽车。 OEM 可以挖掘这些数据来识别对客户*重要的功能，以及过度指定或根本未使用的功能。 这些见解将为配置和未来模型需求提供信息。

*终，新的交付模式将对开发效率产生积极影响。 鉴于汽车制造商会对其软件进行频繁的更改、调整和修改，因此他们不需要从项目一开始就确定极其详细的需求。 由于定义需求的时间缩短了，产品上市时间也将缩短。

3.调整软件需求管理

从历史上看，汽车行业一直是管理集成价值链需求的领导者。 然而，原始设备制造商主要关注硬件要求，其现有流程并未针对软件进行优化。 随着车载软件成为重要的差异化因素，原始设备制造商必须采用新的实践来管理需求。 管理需求变化尤为重要，因为我们的研究表明，汽车软件的需求变得如此细化，以至于减缓了开发速度。

根据*佳实践，原始设备制造商应根据客户价值对需求进行聚类。 **级应主要包含面向客户的需求（通常表示为用例）。 另一个级别主要由技术或实现要求（通常表示为启用因素）组成，例如功能所需的内存。 这种方法可确保 OEM 专注于价值创造并在软件开发过程中设置适当的优先级。 随着汽车制造商将需求分为多个层次，以下内容可以提供帮助。

将需求与战略和客户价值联系起来。 成功的软件开发需要根据客户反馈不断调整和修改需求。 虽然公司应该根据业务战略和目标尽早定义软件需求，但也应该根据客户反馈和开发进度定期进行调整。

确保端到端的可追溯性。 通过密切跟踪整个价值链的需求，汽车公司可以避免浪费精力并加快开发进程。 然而，车企只有其开发流程和工具链能够在从定义到验收的整个过程中实现需求的严格可追溯性，才能实现这一目标。 这种清晰度有助于汽车公司了解需求（客户角度）、所需功能（开发人员角度）和可交付成果（测试人员角度）。

车企必须分四步实现端到端的追踪，要么需要使用几个高度集成的工具，要么需要四种专业工具搭配相应的接口。 这些步骤是：跟踪需求，细化和指定从功能到组件的这些需求； 管理待办事项列表，这有助于每个团队在软件开发冲刺期间管理每个需求的覆盖范围（与下一步密切相关）； 跟踪代码更改，包括待办事项的更新； 通过运行测试用例来验证需求并检查测试用例的通过/失败状态。

使用工具关联需求，用户可以在项目的每个阶段有效地实施变更，以满足端到端可追溯性的监管要求（例如，或 UNECE [5]）。 使用这种方法，我们可以快速找出哪些变更影响哪些工作产品。 当按照敏捷流程开发软件时，这种需求变化是正常且可取的（例如基于客户反馈的变化），公司应该使用各种流程和工具来支持它们。 在软件开发工作的传统瀑布过程中，这种变化很少见，而且往往是不可预见的。

避免过度细化并创建明确的需求类别。 企业可以建立一些*佳实践来指定和分类软件需求并开发简化的测试方法。 良好的需求声明是清晰的，并且允许独立于其他需求进行测试。 与投资组合管理一样，公司应该区分不同类型的需求。 常见的需求类别包括法律监管、安全、策略，以及必要的改进、客户价值、成本赋权等因素。 此外，公司必须确保需求之间的所有依赖关系都是透明的。 许多公司已将这些规则集成到自己的软件开发流程和培训课程中，以优化需求的处理和审查。

确定优先顺序并不断调整。 应根据特定的业务案例和战略目标以及客户反馈和整个开发过程（例如，在测试期间）获得的经验来评估软件需求并确定优先级。 组织应定期重新评估需求并以透明的积压状态维护它们。

许多公司任命产品负责人，他们知识渊博，可以对产品功能进行权衡，建立跨职能团队，并确保职能部门就需求达成一致。 根据*佳实践，产品负责人还负责遵循*佳实践并维护需求和用例的积压。

详情请参阅报告原文。

（本文仅供参考，不代表本行任何投资建议，如需使用相关信息，请以报告原文为准。）

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等