Как PLM на самом деле помогает инженерным командам работать быстрее

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

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

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

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

Но как именно это помогает инженерным командам работать быстрее в повседневной деятельности?

Где на самом деле теряется инженерное время

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

Инженерным командам регулярно нужны ответы в реальном времени на следующие вопросы:

• Какая BOM является актуальной?
• Была ли эта деталь утверждена?
• Кто утвердил это изменение?
• Почему был выбран именно этот компонент?
• Какую ревизию получило производство?

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

Современные PLM-инструменты дают инженерам удобный доступ к нужной информации, чтобы они могли тратить больше времени на проектирование и меньше — на поиски.

Инженерным командам нужна единая достоверная запись о продукте

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

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

Имея одну достоверную запись о продукте, инженерные команды могут уверенно выпускать проекты, закупки — проверять утвержденные детали и альтернативы, производство — собирать по правильной ревизии, а руководство — отслеживать прогресс без опоры на статусные совещания.

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

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

Современное управление изменениями должно быть гораздо более «вдохновленным GitHub», с возможностью отслеживать ревизии деталей, чертежей и BOM; видеть, кто что изменил и почему; направлять ECO по маршрутам согласования; уведомлять проверяющих; и сокращать количество отклоненных запросов на изменение из-за отсутствующих данных.

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

PLM раньше включает решения по снабжению в инженерный процесс

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

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

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

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

PLM улучшает межфункциональное взаимодействие

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

PLM позволяет кросс-функциональным командам проверять проекты и вносить вклад раньше в процессе разработки. 

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

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

PLM сохраняет «почему» за инженерными решениями

Аппаратные продукты, существующие годами, требуют сохранения продуктовой памяти, особенно когда инженеры уходят, поставщики меняются, а компоненты устаревают. 

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

PLM помогает сохранять «почему» рядом с «что». Хорошая запись о продукте должна отвечать на вопросы:

• Почему был выбран этот компонент?
• Почему эта альтернатива была отклонена?
• Почему был изменен этот допуск?
• Какой поставщик утвердил эту ревизию?
• Какой ECO ввел это требование?
• Какие сборки затрагиваются, если эта деталь изменится?

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