Тематическое исследование: успешная реализация Pdm в автомобильном производстве

Исполнительное резюме

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

Справочная информация о компании

Предметом этого тематического исследования является всемирно признанный автомобильный производитель со штаб-квартирой в Германии, с производственными мощностями на трех континентах и портфелем, который включает в себя высокопроизводительные седаны, электрические внедорожники и гибридные силовые агрегаты. В компании работает более 40 000 человек по всей инженерии, производству, логистике и обеспечению качества. До инициативы PDM компания полагалась на лоскутное одеяло устаревших систем: смесь электронных таблиц, локальных файловых серверов и устаревшей платформы PLM, которая не была обновлена за десятилетие. Каждая инженерная дисциплина - корпус, шасси, трансмиссия и электричество - поддерживала свои собственные хранилища данных, что приводило к непоследовательным номерам деталей, дубликатам записей BOM и ручным усилиям по синхронизации, которые потребляли сотни инженерных часов в месяц.

Недавно компания приступила к реализации стратегии цифровой трансформации, направленной на зрелость Индустрии 4.0. Руководство признало, что без единой основы PDM такие инициативы, как цифровые двойники, разработка на основе моделирования и видимость цепочки поставок в режиме реального времени, останутся недостижимыми. Совет утвердил выделенный бюджет для системы PDM следующего поколения с мандатом на выбор решения, которое могло бы интегрироваться с существующими инструментами ERP (SAP) и MES, поддерживать сотрудничество на нескольких площадках и предоставлять ролевой доступ для внешних партнеров, таких как поставщики Tier 1.

Проблемы, с которыми приходится сталкиваться

Фрагментированный менеджмент данных по всем департаментам

Инженерные команды хранили файлы САПР, спецификации и результаты тестов в разделах ведомственной сети. Команда использовала локальный файловый сервер в Штутгарте, инженеры силовых агрегатов полагались на SharePoint, а группа проверки хранила результаты моделирования на облачном диске без версии. Эта фрагментация сделала практически невозможным получение одного источника правды для любой конкретной сборки. Обзоры дизайна часто начинались с недели ручного сбора данных только для подтверждения того, какая ревизия чертежей была актуальной. Отсутствие централизованного сводирования также создавало риски безопасности — чувствительная интеллектуальная собственность существовала в неуправляемых местах, доступных десяткам пользователей с неясными разрешениями.

Проблемы контроля версий

Без автоматизированного управления версиями инженеры прибегли к ручным соглашениям об именах, таким как «brake caliper v3 final rev2 final.sldprt». Когда несколько дизайнеров работали одновременно над одной и той же сборкой, противоречивые изменения переписывали друг друга, и единственный способ восстановить потерянную работу состоял в том, чтобы восстановить из местных резервных копий. Это привело к дорогостоящей переделке во время сборок прототипов. В одном случае конструкция кронштейна шасси, которая уже была изготовлена в предсерийной оснастке, была обнаружена устаревшей редакцией, требующей двухнедельной аварийной редизайн и 250 000 евро в утилизированной оснастке.

Расширенное время выхода на рынок для новых моделей

Средний цикл разработки от первоначальной концепции до начала производства (SOP) растянулся до 48 месяцев, что значительно превышает отраслевой ориентир в 36 месяцев для аналогичных сегментов транспортных средств. Задержки были вызваны итеративными ручными передачами данных между проектированием, моделированием и производственным проектированием. Без общей цифровой нити каждый отдел должен был повторно вводить или переинтерпретировать данные, вводя ошибки и зависимости, которые каскадировались на поздних этапах программы.

Непоследовательная коммуникация между командами

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

Процесс выбора PDM

Определение требований

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

Оценка поставщиков и пилот

Компания оценила четырех основных поставщиков PDM: Siemens Teamcenter, PTC Windchill, Dassault ENOVIA и новую облачную платформу, построенную на безголовой архитектуре. Каждый поставщик завершил структурированное доказательство концепции с использованием эталонной сборки из электрической трансмиссии компании. Критерии оценки включали гибкость развертывания, усилия по интеграции, пользовательский опыт и общую стоимость владения в течение пяти лет. Пилотный этап длился три месяца и включал 15 инженеров из трех разных отделов.

В то время как унаследованные поставщики PLM предлагали обширные сквозные возможности, компания была привлечена к более модульному подходу, основанному на API, который можно было настраивать постепенно. Выбранная платформа — Directus , платформа безголовых данных с открытым исходным кодом — позволила внутренней команде быстро моделировать конкретные схемы данных компании, не заставляя жесткие шаблоны процессов. Способность Directus обрабатывать любую базу данных SQL в качестве хранилища данных для поддержки означала, что существующие данные из устаревшего PLM могут быть постепенно перенесены, а пользовательская бизнес-логика может быть введена через веб-хуки и потоки. Архитектура безголового также согласуется с долгосрочной целью компании по созданию композитного технологического стека, где системы PDM, ERP, MES и IoT могут быть подключены через общий уровень API.

Дорожная карта реализации

Фаза 1: Открытие и картирование рабочих процессов (1-2 месяца)

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

Фаза 2: Настройка и интеграция системы (месяцы 3-5)

Используя панель администратора Directus, внутренняя команда разработчиков настроила пользовательские коллекции для деталей, сборок, документов, запросов на изменение и инженерных выпусков. Разрешения на основе ролей были определены для зрителей, участников, рецензентов и менеджеров выпуска. Разъемы интеграции были построены для синхронизации данных о магистре деталей с SAP каждые 15 минут и для извлечения статуса заказа производства из MES. Пользовательский веб-хук также был создан для автоматического уведомления членов команды через Slack всякий раз, когда статус запроса изменения менялся.

Фаза 3: Миграция и валидация данных (5-7 месяцев)

Миграция данных осуществлялась тремя волнами: во-первых, эталонные данные (материалы, стандарты и шаблоны); во-вторых, активные проекты (части разработки и БОМы); и в-третьих, архивные данные, которые читались только в течение более пяти лет. Команда использовала комбинацию пользовательских скриптов ETL и модуля импорта Directus. Каждый мигрированный элемент был проверен на ручные точечные проверки и автоматизированные правила согласованности. Примерно 12% архивных элементов были обнаружены осиротевшие ссылки или отсутствующие метаданные; они были помечены и исправлены перед загрузкой в новую систему.

Фаза 4: Обучение и пилотная выкатка (7-8 месяцев)

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

Фаза 5: Полное развертывание и постоянное совершенствование (9-12 месяцев)

После того, как пилот продемонстрировал 40%-ное сокращение времени поиска данных и нулевые инциденты потери данных, система была развернута в оставшиеся инженерные отделы - корпус, электротехнику и проверку - а также в производственную инженерную команду на заводе в Китае. Развертывание было завершено через 13 недель. После внедрения была создана доска непрерывного улучшения, чтобы удовлетворить двухнедельные и приоритетные улучшения функций. Примеры ранних улучшений включали панель мониторинга для отслеживания старения запросов на изменение и пользовательское мобильное приложение для инженеров цеха-пола, чтобы просматривать обновленные БОМы без входа в полный рабочий стол клиент.

Результаты и выгоды

Повышение точности и доступности данных

Через шесть месяцев после полного развертывания показатель единственного источника истины достиг 99,3%, измеряемый процентом обзоров дизайна, где последний пересмотр может быть получен в течение 30 секунд. Число расхождений в части, о которых сообщалось в полевых отчетах, сократилось на 55%, и инженерная команда устранила практику отправки электронных таблиц с изменениями BOM по электронной почте.

Быстрые изменения дизайна и утверждения

Среднее время цикла запроса на изменение - от подачи до реализации - сократилось с 18 дней до 6 дней. Автоматизированные рабочие процессы уведомления и утверждения гарантировали, что ни один запрос не оставался бездействующим более 24 часов. Система управления изменениями также отслеживала анализ воздействия, чтобы инженеры могли видеть, какие структуры БОМ, сборки и центры затрат будут затронуты, прежде чем утвердить пересмотр.

Сокращение времени выхода на рынок на 20%

Общий график разработки автомобиля, измеряемый от заморозки концепции до SOP, был сокращен с 48 месяцев до 38,4 месяцев - улучшение на 20%. Это было достигнуто путем сжатия поздних этапов проектирования: с точными БОМ, доступными в режиме реального времени, заказы на оснастку могут быть размещены раньше, а производственная инженерия может начать проектирование крепления за несколько недель до окончательного замораживания конструкции.

Улучшенное сотрудничество между командами

Значительно улучшились показатели кросс-функционального сотрудничества. Процент запросов на изменение, которые требовали эскалации, среди высшего руководства снизился с 30% до 8%, поскольку проблемы были решены ранее в рабочем процессе командами, которые владели данными. Инженерные и производственные команды начали проводить еженедельные совещания «цифровой непрерывности», где они рассматривали последние БОМ и отмечали потенциальные проблемы сборки. Внешним поставщикам был предоставлен ограниченный доступ к партнерскому порталу, что позволило им загружать утвержденные файлы САПР и спецификации без прямого контакта с инженерами - сокращение среднего времени ответа на запрос поставщика с двух дней до двух часов.

Уроки, извлеченные

Инвестиции в управление изменениями не подлежат обсуждению

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

Поэтапное развертывание минимизирует риск

Решение начать с одного пилотного отдела оказалось критическим. Когда первоначальная конфигурация вызывала проблемы с производительностью во время интенсивного одновременного использования (более 30 одновременных пользователей проверяли большие файлы САПР), команда определила и решила узкое место — объединение соединений с базой данных — до того, как система была развернута на более широкой базе пользователей. Развертывание большого взрыва вызвало бы широко распространенное разочарование и могло бы подорвать доверие к решению.

Настройка должна быть сбалансирована со стандартизацией

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

Будущий прогноз

С созданием PDM-основы компания теперь расширяет систему для поддержки цифрового моделирования двойников. Подключив PDM BOM к данным датчиков в реальном времени от тестовых автомобилей, инженеры могут проверить, что конфигурация в реальном времени соответствует разработанной спецификации. Компания также планирует интегрировать Directus с платформой совместной робототехники для автоматизации инструкций по сборке на основе последнего инженерного выпуска. Промышленные тенденции согласуются с этой траекторией: отчет от McKinsey указывает, что разработка продуктов, поддерживаемых данными, может снизить общие инженерные затраты на 15-25%, а Siemens PLM глоссарий отмечает, что эффективный PDM остается предпосылкой для передовых возможностей PLM, таких как системная инженерия и генеративный дизайн.

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

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