Будущее развитие автомобильной промышленности невозможно без IT-трансформации

Исторически автомобиль, как продукт, всегда воспринимался результатом инженерной мысли и совокупностью механических агрегатов и механизмов. Но уже сейчас программное обеспечение стало неотъемлемой частью автомобиля и занимает все большую часть от автомобильной платформы следующих поколений машин. С каждым поколением доля программного обеспечения растет стремительными темпами.

Разработка программного обеспечения стала одной из ключевых звеньев цепочки создания ценности автомобиля и производители, которые не перестраиваются под новые стандарты производства могут потерять значительную часть рынка в ближайшем будущем.

Помимо становления программного обеспечения как неотъемлемой части автомобиля, цифровизация активно охватывает и само производство, позволяя собирать информацию о процессах производства, в режиме реального времени видеть в каких ключевых точках производства имеет низкую эффективность или эффект “бутылочного горлышка” и оперативно реагировать, принимая управленческие решения.

У цифровых систем на производстве есть две ключевые задачи: 

–  прозрачность сбора и консолидации данных – вы должны знать, что происходит на производстве; 

–  автоматизация процессов производства – для улучшения эффективности производства и организации работы большого числа сотрудников и подразделений.

Программное обеспечение – неотъемлемая часть автомобиля

Исследование аналитиков McKinsey показывают, что разрыв между скоростью и качеством производства у механических агрегатов автомобилей между лучшими и худшими автомобильными компаниями составляет всего 1,5-2 раза. В то время как разрыв в производстве программного обеспечения для новых моделей между топами и замыкающими списка автопроизводителей уже в 3-6 раз. 

Те автопроизводители, которые упускают модернизацию и наращивание производства программного обеспечения для машин потеряют значительную долю рынка уже в ближайшие 5-8 лет.

Поскольку на карту поставлено так много, автомобильным игрокам следует переосмыслить весь свой подход к разработке программного обеспечения, включая базовую операционную модель. В этой статье мы делимся нашими ключевыми убеждениями и идеями, полученными за последние 2 года в результате тесной работы с топовыми автопроизводителями, такими как VW и Audi, поставщиками и другими партнерами по экосистеме.

Проникновение программного обеспечения на рынок автопромышленности в цифрах

Несколько тенденций подчеркивают растущую важность автомобильного программного обеспечения. Первый связан с быстрым расширением рынка программного обеспечения и электротехники/электроники, среднегодовой темп роста которого, как ожидается, составит 12% в период с 2020 по 2030 год, что более чем в три раза превышает ожидаемый рост продаж автомобилей в целом. Области самого сильного роста  включают функции программного обеспечения (CAGR 11%), а также интеграционное тестирование (12%).

Растущая сложность программного обеспечения, но медленный рост производительности

Сложность автомобильного программного обеспечения возрастает как на функциональном, так и на архитектурном уровнях, но производительность разработки не растет такими же темпами. Исследование рынка показывает, что за последние десять лет сложность программного обеспечения выросла в 4,0 раза, тогда как производительность разработки программного обеспечения увеличилась только в 1,5 раза. 

Проблема наиболее серьезна с большими модулями, которые становятся все более сложными, такими как информационно-развлекательные и передовые системы помощи водителю (ADAS). Производительность этих модулей примерно на 25–35% ниже, чем у традиционного глубоко встроенного программного обеспечения.

Этот увеличивающийся разрыв может поставить под угрозу будущий успех автомобильных игроков. Увеличение усилий по разработке и сопровождению программного обеспечения в течение жизненного цикла может уменьшить их способность к инновациям и реагированию на конкурентов. 

Во время интервью, руководитель одной компании отметил, что только обслуживание программного обеспечения быстро израсходует все ресурсы НИОКР, если сложность будет продолжать расти, а производительность останется неизменной. Это в свою очередь оставит мало места для инноваций. В конечном итоге разрыв между сложностью и производительностью снизит конкурентоспособность по стоимости и может привести к серьезным финансовым и репутационным проблемам.

Путь снижения сложности при одновременном повышении эффективности

Чтобы преуспеть в этой быстро меняющейся среде, компании должны свести к минимуму сложность, уменьшив усилия, необходимые для разработки и обслуживания программного обеспечения. Эта стратегия будет включать ограничение количества версий функций, доступных на разных платформах и этапах жизненного цикла. 

В то же время компании должны увеличить повторное использование компонентов. Для повышения производительности организации должны попытаться повысить эффективность, сравнив скорость разработки программного обеспечения с цифровыми компаниями. Поскольку общий уровень инноваций в области программного обеспечения не снизится, компании также должны увеличить объемы разработки и сопровождения программного обеспечения, чтобы предоставлять предложения, необходимые в настоящее время для достижения успеха на рынке.

Для снижения сложности и повышения эффективности потребуется новая операционная модель программного обеспечения, которая фокусируется на четырех важнейших параметрах:

–  Какое программное обеспечение разрабатывается, включая архитектуру, дизайн и требования;

–  Где программное обеспечение разрабатывается внутри организации, включая местоположение, разработчиков и партнеров;

–  Как разрабатывается программное обеспечение с учетом методологий разработки, таких как agile-at-scale, или изменений в процессах разработки и тестирования.

–  Как обеспечивается разработка программного обеспечения, включая управление производительностью и инфраструктуру цепочки инструментов.

Разберем каждый из аспектов по отдельности.

Аспект 1 – Какое программное обеспечение разрабатывается: архитектура, дизайн и требования

В соответствии с новой операционной моделью компании должны преобразовывать свои стремления и бизнес-возможности, связанные с программным обеспечением, в действенные требования к архитектуре, продуктам и портфелям на уровне продуктов, функций и модулей. Благодаря этому процессу компании получают подробное представление о видах программного обеспечения, которые могут создавать для них ценность. Это также позволяет им упростить архитектуру, применять методы проектирования, ориентированные на пользователя, и улучшать управление требованиями к программному обеспечению.

Упрощение архитектуры программного обеспечения автомобиля

Согласно исследованиям в 2021 году, отсутствие модульности в автомобильном программном обеспечении приводит к усложнению конструкции. Это, в свою очередь, увеличивает общую трудоемкость проекта. Более того, автомобильное программное обеспечение часто имеет неоптимальные границы архитектурных компонентов, что может привести к усилению взаимозависимостей, что увеличивает количество компонентов, которые разработчики должны модифицировать при добавлении новых функций. 

Эти взаимозависимости также увеличивают время и опыт, необходимые для отслеживания ошибок до конкретных программных модулей и групп разработчиков при обнаружении дефекта.

Чтобы решить эти проблемы, компаниям следует сфокусироваться на стандартизации и модульности, которые могут распространяться на разные платформы, чтобы поддерживать управляемость уровнем сложности программного обеспечения. 

OEM-производители также должны сосредоточиться на отделении программного обеспечения от аппаратного обеспечения и применении сервисно-ориентированного дизайна.

Раздельная архитектура. Компании могут внедрить мощный уровень промежуточного программного обеспечения, который абстрагирует аппаратные возможности и делает их доступными для программных функций и служб через стандартизированные API, используемые на верхних уровнях. 

Эта программная архитектура может обеспечить унификацию для разных платформ и снизить сложность проектирования, тем самым устраняя необходимость многократно переделывать одно и то же программное обеспечение.

Помимо разделения, компаниям также следует стремиться к созданию набора стандартизированных операционных систем, поддерживающих гармонизацию компонентов и обеспечивающих совместимость. Многие международные игроки уже объявили о разработке таких операционных систем, но на данный момент универсального подхода не существует. И компаниям еще предстоит определить точную направленность и функциональность этих систем.

Методы проектирования, ориентированные на пользователя

В разных отраслях компании, которые концентрируются на разработке сильного пользовательского дизайна и создании оптимального пользовательского опыта (UX), добиваются большей финансовой выгоды, чем другие. 

По мере того, как ACES продолжает набирать обороты, а автомобили с программным управлением становятся нормой, эти функции будут становиться все более важными для общей конкурентоспособности OEM-производителей. Даже лучшим игрокам нужно будет улучшить качество своей разработки, поскольку автомобильная промышленность все еще отстает от других секторов, когда дело доходит до разработки хорошего UX программного обеспечения и обеспечения оптимальной ценности для клиентов.

OEM-производители автомобилей, которые хотят стать лидерами UX, должны управлять своими данными. С увеличением количества автомобильного программного обеспечения и датчиков производители автомобилей теперь имеют доступ к огромному количеству информации о том, как клиенты используют свои автомобили. OEM-производители могут анализировать эти данные, чтобы определить функции, которые наиболее важны для клиентов, а также те, которые указаны слишком широко или не используются вообще. Такие идеи будут способствовать спецификации и определению приоритетов будущих требований к модели.

Где разрабатывается программное обеспечение: организация, места, разработчики и партнеры

Большинству автопроизводителей не хватает организационной основы, необходимой для крупномасштабной разработки программного обеспечения. Проблемы варьируются от небольшой ответственности за программное обеспечение на исполнительном уровне до нехватки инженеров и дизайнеров программного обеспечения. Новая операционная модель решит эти проблемы, определив необходимую организационную структуру, местоположение и кадровую стратегию для разработки программного обеспечения, а также стратегии «сделай или купи» и необходимую партнерскую экосистему.

На организационном уровне большинство игроков автомобильной отрасли не готовы реагировать на тенденции, которые повышают важность программного обеспечения. Например, OEM-производители, как правило, медлительны при принятии решений по вопросам программного обеспечения, и многие из них еще не прояснили всеобъемлющее право собственности на программное обеспечение, стратегию в отношении электроники и соответствующие бюджеты. 

Чтобы оставаться конкурентоспособными в новых условиях, компании должны переосмыслить свои организационные структуры. Одной из основных целей является сокращение количества интерфейсов при определении архитектуры, определении требований и разработке в процессе сквозной разработки. Повышая согласованность и сотрудничество между группами на всех этапах, компании могут избежать лишних потерь ресурсов и бюджетов и оптимизировать как существующий функционал продуктов и производств, так и внедряемый новый. 

Многие компании начали полагаться на централизованную функцию, которая берет на себя ответственность за архитектуру и обмен институционализированными передовыми практиками. Например, один OEM-производитель недавно создал центральную функцию, объединяющую более 5000 разработчиков программного обеспечения. Однако в большинстве случаев OEM-производители по-прежнему придерживаются более децентрализованного подхода к разработке программного обеспечения.

Получите доступ к лучшим разработчикам и привлекайте их, а также растите потенциал внутри

В то время как автомобильные организации должны преуспеть на многих уровнях, чтобы выиграть гонку программного обеспечения, привлечение и удержание лучших специалистов, вероятно, является наиболее важным аспектом.

Большинство OEM-производителей в значительной степени передали свою деятельность по разработке программного обеспечения на аутсорсинг и часто полагаются на стратегическое партнерство. Поскольку тенденции ACES значительно повышают важность программного обеспечения и, несмотря на потенциальное повышение производительности программного обеспечения, к 2030 году спрос на инженеров-программистов, вероятно, возрастет в три-четыре раза. 

​​Определите четкие стратегии «производи или покупай» и разработайте партнерскую экосистему

Чтобы сохранить с трудом завоеванные конкурентные преимущества и не превратиться в однообразных разработчиков аппаратных платформ, автопроизводители должны разработать четкие клиентские стратегии, определить отличительные особенности и ценностные предложения, а также создать модульную архитектуру, которая может логически разбивать модули разработки. Когда эти задачи выполнены, они могут разработать четкую стратегию «производить или покупать», сосредоточив внимание на трех различных аспектах:

–  этап процесса разработки, такой как системная интеграция или приемочное тестирование;

–  стек программных технологий;

–  программный домен или модуль, который может охватывать такие области, как информационно-развлекательная система или трансмиссия.

По этим параметрам компании должны определить и определить контрольные точки, чтобы привести стратегию «производи или покупай» в соответствие со своей общей стратегией (например, в отношении критически важной интеллектуальной собственности, стандартов качества и отличительных инноваций).

Конечно, компании также должны учитывать легкость поиска на рынке при принятии решений о покупке. Другие факторы, такие как стоимость, также важны, но обычно не являются решающими. Чтобы улучшить процесс принятия решений, OEM-производители могут взвешивать каждый фактор с учетом своих приоритетов и рыночного контекста.

Когда компания принимает решение о разработке программного обеспечения собственными силами, она должна оценить влияние на внутренние инженерные возможности, определить, обладают ли текущие сотрудники всеми необходимыми способностями, а также изучить организационные структуры и процессы. Если компании не хватает необходимых возможностей или недостаточно мощностей, ей следует изучить возможности приобретения или создания совместных предприятий, которые позволят ей сохранить контроль над критическими точками.

Если компания решает купить программное обеспечение, она должна определить детальную модель сорсинга во время расширенной оценки, которая включает в себя выбор и заключение контрактов с партнерами по разработке. При рассмотрении стратегии частичной покупки сложной программной системы компаниям следует заключать контракты не более чем с двумя-тремя поставщиками. Наше исследование показывает, что все, что выходит за этот предел, может снизить производительность более чем на 65%.

В любой всеобъемлющей стратегии «производи или покупай» компаниям следует использовать стандартные строительные блоки и блоки с открытым исходным кодом, поскольку они могут обеспечить огромное преимущество при разработке программного обеспечения. Однако компаниям необходимо будет установить четкие правила и процессы для использования блоков с открытым исходным кодом и уделять пристальное внимание вопросам лицензирования, ответственности и обслуживания. Часто OEM-производителям и поставщикам требуется официальное юридическое соглашение для включения компонентов с открытым исходным кодом в продукт.

Наконец, автопроизводителям следует развивать стратегическое партнерство и находить партнеров по экосистеме, поскольку эти связи позволяют компаниям учиться друг у друга, ускоряя разработку и сохраняя низкие затраты. Совместная разработка также снижает риски, связанные с поздним выходом на рынок.

Как разрабатывается программное обеспечение: Agile-практики, разделение, тестирование

Автопроизводители традиционно рассматривали программное обеспечение как вторичное по отношению к аппаратному обеспечению. Теперь они должны пересмотреть эту перспективу, а также свои подходы к разработке, поскольку программное обеспечение в настоящее время является основным драйвером стоимости в портфеле разработки продуктов.

Этот сдвиг потребует от автопроизводителей внедрения гибкости в масштабе, разделения процессов разработки аппаратного и программного обеспечения, а также увеличения автоматизации тестирования и непрерывной интеграции.

Внедрение agile

Гибкие подходы, применяемые в масштабе как аппаратного, так и программного обеспечения, позволяют компаниям повышать производительность и быстро реагировать на изменения в современной быстро меняющейся среде. Благодаря гибким преобразованиям в разных отраслях компании добились повышения производительности и скорости внедрения на 30 процентов, одновременно сократив остаточные дефекты на момент выпуска более чем на 70 процентов. 

Снижая проектные риски, связанные с бюджетом, сроками и качеством, Agile играет решающую роль в решении сложных задач.

На сегодняшний день лишь немногие автомобильные компании последовательно внедряют методы гибкой разработки программного обеспечения. В то время как многие игроки запускают пилотные проекты, особенно в области продвинутой разработки, лишь немногие внедряют гибкие подходы в масштабе. Скорость внедрения может быть низкой, поскольку автомобильные приложения имеют очень специфические требования, которые затрудняют внедрение стандартного гибкого подхода в масштабах всей организации. Кроме того, набор автомобильных гибких инструментов должен быть способен справляться со сложностью системы, часто сложными взаимозависимостями при разработке оборудования и строгими нормативными требованиями, касающимися кибербезопасности, безопасности транспортных средств и качества.

Взаимозависимости с разработкой оборудования

Чтобы управлять взаимозависимостями, OEM-производители могут использовать подход гибкости в масштабе, сочетая системную инженерию с методами управления требованиями. Вместе эти методы обеспечивают плавную интеграцию аппаратного и программного обеспечения, а также синхронизированный график разработки.

Классические методы системной инженерии для общей архитектуры, интеграции и тестирования обеспечат интегрированный подход к управлению жизненным циклом продукта и помогут компаниям соблюдать нормативные требования. Компании могут использовать методы системной инженерии для определения общей архитектуры транспортного средства и предметной области (см. схему ниже). Это, в свою очередь, позволит им предоставлять agile-командам высокоуровневые входные данные и граничные условия. На основе этих входных данных agile-команды могут детализировать требования к программному обеспечению перед разработкой и тестированием компонентов. В конце цикла разработки команда замыкает цикл системного проектирования, когда домен, интеграция транспортных средств и действия по тестированию объединят всю систему воедино.

С точки зрения управления проектом цель состоит в том, чтобы добиться функционального согласования приоритетов и необходимых точек синхронизации для выделенных элементов блока управления и архитектуры домена. Например, компаниям следует расставлять приоритеты и отслеживать предоставление функций, необходимых для запуска срочных событий, таких как зимние тесты. Между тем, они будут отслеживать только менее важные функции, глядя на общие показатели выполнения требований.

При переходе на гибкие методы организации должны сделать критический выбор в отношении операций на макроуровне, включая управление портфелем, ресурсами и проектами. Как правило, только передовые подразделения разработки, такие как «фабрики программного обеспечения» в OEM-производителях, следуют подходу гибкости в масштабе, при котором все функции полностью перенимают новые способы работы. 

Однако есть исключения. Например, некоторые пионеры автомобилестроения внедрили методологии Agile, такие как масштабируемая гибкая структура (SAFe), для управления своими всеобъемлющими операциями по исследованиям и разработкам.

Напротив, отдельные команды всегда должны следовать установленным гибким методам работы. Как и в других отраслях, преимущества гибкости могут быть наиболее очевидными, когда они применяются к командам, отвечающим за отдельные функции.

Поскольку OEM-производители переходят на agile-процессы, они также должны:

• Интегрируйте поставщиков разработки в свои agile-процессы, чтобы обеспечить полную реализацию
• Адаптировать процессы закупок по мере их перехода от четко определенных и предварительно согласованных контрактов на основе спецификаций к партнерству в области разработки на основе спринта.
• Решайте юридические проблемы, которые мешают стратегиям совместного размещения или гибкому сотрудничеству между поставщиками и OEM-производителями.

Разделите аппаратное и программное обеспечение, чтобы обеспечить двухскоростные процессы разработки

Что касается процессов, автопроизводители могут придерживаться более динамичного плана программного цикла, который поддерживает частые выпуски, не привязанные к жестким, отдаленным датам SOP для транспортных средств. Отделение управления продуктом и жизненным циклом от аппаратного обеспечения является ключом к отходу от ориентации SOP на одно транспортное средство. Для этого они должны поддерживать отдельные невыполненные работы и дорожные карты, определяя при этом четкие и синхронизированные вехи между разработкой аппаратного и программного обеспечения. При работе с поставщиками OEM-производителям может потребоваться реструктуризация соглашений. Наконец, они должны активизировать использование автоматизированного программного обеспечения, а также интеграционное тестирование и развертывание.

Как и в случае гибкого подхода, группа разработки систем может управлять и определять интерфейсы между группами аппаратного и программного обеспечения для разделения невыполненных работ по аппаратному/программному обеспечению и обеспечения синхронизации между уровнями. Очевидно, что если аппаратное и программное обеспечение являются независимыми, компании могут разделить точки замораживания архитектуры и, таким образом, не будут нуждаться в синхронизации.

Как и гибкие методы, разделение требует нескольких предварительных условий, включая стандартизированную и модульную архитектуру и надежный подход к тестированию. Как отмечалось ранее, компании могут отделить программное обеспечение от аппаратного обеспечения, используя мощный промежуточный уровень программного обеспечения, который абстрагирует аппаратные возможности и делает их доступными для функций и служб через стандартизированные API. Тем не менее, наиболее важным фактором для процессов разделения является надежный подход к тестовым автомобилям. Следовательно, компании должны определить методы предоставления и обслуживания испытательных транспортных средств: либо аппаратные, либо программные системы, либо более широкая инфраструктура моделирования.

Как гибкие методы, так и раздельная разработка аппаратного/программного обеспечения имеют значительные последствия в цепочке создания стоимости, особенно для закупочной организации. Например, при закупках потребуется перейти от традиционного каскадного процесса поиска поставщиков к более гибким и несвязанным подходам к разработке. На практике это требует от OEM-производителей следовать определенным передовым методам, таким как постоянная оценка стратегической важности элементов программного обеспечения, понимание того, как будут развиваться требования, и определение наиболее подходящих моделей сорсинга в каждом конкретном случае. Эти изменения потребуют оценки совокупной стоимости владения программным обеспечением, а также новых моделей сотрудничества, ориентированных на стратегическое партнерство.

Повышайте автоматизацию тестирования и совершенствуйте непрерывную интеграцию, чтобы обеспечить скорейшее обнаружение ошибок

В связи с увеличением объемов программного обеспечения и повышением спроса на непрерывные обновления функций OEM-производители должны как можно скорее находить и устранять ошибки и ошибки интерфейса. Если им не удастся устранить ошибку напрямую, они могут создать огромное количество ошибок, которые могут полностью поглотить их ресурсы и усложнить отслеживание ошибок, что приведет к задержкам в разработке и увеличению усилий по проверке.

Как и в случае с agile-методами, лишь немногие игроки автомобильной отрасли внедрили методы непрерывной интеграции или автоматизированного тестирования в масштабе. Если они обратят эту тенденцию вспять, они смогут одновременно снизить риск запуска и резко повысить производительность. По нашему опыту, компании увеличили производительность более чем на 40%, сократив плотность остаточных дефектов более чем на 60%.

Чтобы последовать их примеру, автомобильные компании должны принять два взаимосвязанных передовых метода разработки программного обеспечения. 

Во-первых, они должны интегрировать код в общий репозиторий несколько раз в день и проверять его с помощью автоматической сборки. Интегрируя код на ранней стадии, разработчики могут «быстро ошибаться» и легко изолировать ошибки с помощью методов непрерывной интеграции, инструментов и использования автоматизации. Поставщики могут достаточно независимо реализовывать эти преимущества на системном уровне. На уровне полного транспортного средства OEM-производителям необходимо преодолеть ограничения IP и либо кодировать самостоятельно, либо использовать подход «белого ящика» для совместного использования полного кода с поставщиком. 

Второй элемент решения — разработка и автоматизация на основе тестирования, процесс, в котором тесты определяются до начала написания кода, а затем автоматически запускаются после интеграции кода. Дизайнеры и разработчики программного обеспечения — а не отдельный отдел тестирования — уточняют и повторяют тесты в процессе разработки вместе с клиентами. Этот подход вынуждает разработчиков думать, как использовать систему и как ее реализовать перед написанием кода. Со временем комплексный автоматизированный набор тестов позволит проводить устойчивые высококачественные спринты.

Как обеспечивается разработка программного обеспечения: производительность и наборы инструментов

Чтобы оптимизировать эффективность операционной модели, основанной на программном обеспечении, компаниям следует внедрить лучший в своем классе подход к управлению производительностью и настроить современную программную инфраструктуру, создав цепочку инструментов для разработки программного обеспечения.

Внедрите управление производительностью, которое учитывает производительность на основе данных, зрелость проекта и измерение качества.

По мере увеличения сложности программного обеспечения игроки автомобильной отрасли должны модернизировать свои системы управления производительностью, используя стандартизированные, основанные на данных показатели производительности, зрелости проекта и качества. Только автоматизированная аналитика на основе данных может обеспечить основанный на фактах подход к управлению производительностью в режиме реального времени и заблаговременно выявлять надвигающиеся проблемы с программным обеспечением, касающиеся времени, стоимости и качества.

Лучшая в своем классе система управления производительностью программного обеспечения будет превосходна по трем ключевым направлениям:

–  Создание всеобъемлющей системы, включающей каскадные ключевые показатели эффективности (KPI), такие как показатели стоимости, времени и качества, и гарантирующей, что каждый из них связан с общей бизнес-целью и операционными задачами.

–  Разработка эффективной системы эскалации вопросов, включающей стандартные встречи, ориентированные на простую и быструю отчетность, принятие решений и эскалацию.

–  Использование инструментов, технологии автоматизированного измерения производительности и показателей качества кода для обеспечения объективной оценки производительности и качества при разработке программного обеспечения.

Обновление наборов инструментов разработки

Участники автомобильной отрасли могут повысить эффективность, внедрив стандартизированную и эффективную цепочку инструментов для разработки программного обеспечения, которая поддерживает непрерывную интеграцию и использование стандартных API. Типичные компоненты этой цепочки включают процессы управления исходным кодом и инструменты, ориентированные на сборку, непрерывную интеграцию и автоматизацию тестирования (выполнение теста, генерация тестового вердикта и генерация тестового отчета). Как отмечалось выше, эта цепочка инструментов также легко интегрирует все инструменты для управления требованиями.

Создание интегрированной и высокоавтоматизированной цепочки инструментов может открыть значительные преимущества в процессе разработки. Например, он повышает внутреннюю эффективность за счет снижения сложности и позволяет использовать устоявшиеся технологии из внешних строительных блоков. 

Основываясь на исследованиях и нашем опыте, современная цепочка инструментов может:

–  Обеспечить более быструю и гибкую разработку, сократив усилия, необходимые для выпуска кода или сборки, на 90 %.

–  Уменьшить плотность дефектов, разрешив использовать строгие критерии качества, что потенциально снижает частоту отказов на 50 процентов.

–  Позвольть компаниям компилировать тысячи сборок кода в день без каких-либо ручных усилий.

В целом внедрение стандартизированной, современной цепочки инструментов разработки является ключевым фактором, позволяющим раскрыть от 30 до 40 процентов потенциала производительности за счет автоматизированного тестирования и гибких методов. Этот уровень производительности отличает лучших исполнителей от остальных. Игроки в автомобилестроении должны рассматривать этот тип цепочки инструментов для разработки программного обеспечения как основу для высокопроизводительной организации, которая поддерживает непрерывную интеграцию и использование стандартных API. 

Такие цепочки инструментов также обеспечивают эффективные и автоматизированные интерфейсы между инструментами разработки программного и аппаратного обеспечения на протяжении всего процесса разработки. Они также дают возможность автоматизировать несколько этапов процесса для таких действий, как выполнение тестов. В целом, цель состоит в том, чтобы ускорить скорость разработки и обеспечить раннее тестирование.

Внедрение стандартизированной, современной цепочки инструментов разработки является ключевым фактором, позволяющим раскрыть от 30% до 40% потенциала производительности за счет автоматизированного тестирования и гибких методов.

Часто количество используемых инструментальных цепочек и инструментов увеличивается до неуправляемого уровня, что снижает прозрачность. Чтобы избежать этой проблемы, опытные менеджеры цепочек инструментов должны регулярно просматривать набор инструментов и при необходимости предпринимать корректирующие действия.

Итог:

Чтобы преодолеть текущую сложность разработки программного обеспечения и поднять эффективность производительности в автомобильной промышленности, требуется комплексная трансформация исследований и разработок автомобильного программного обеспечения. Технический директор и исполнительный директор должны принять эту задачу в качестве главного приоритета в своей повестке дня и решить ее сейчас, чтобы оставаться конкурентоспособными и успешными в текущей отраслевой среде, и им следует подготовиться к длительному путешествию. Их преобразование займет несколько лет, чтобы решить все проблемы, связанные с организацией программного обеспечения и лежащей в его основе операционной моделью.

Дополнительной стратегией победы в конкурентной борьбе будет привлечение опытных команд и IT-компаний, имеющих опыт цифровой трансформации в автомобильной отрасли и понимающие верхнеуровневую структуру трансформации и шаги, необходимые для ее достижения. А также имеющие собственные готовые наработки и решения в данной отрасли.