Если судить, с одной стороны, по статье одного из лидеров Autodesk СНГ – Павла Брука в недавнем номере CAD/CAM/CAE Observer, а, с другой стороны, по некоторым публикациям относительно эволюции направлений развития Dassault Systemes, можно придти к симпатичному прогнозу: Autodesk одной ногой вступил в PLM, а DS одной ногой оттуда уже вышел:).
Вообще-то, для вразумительного обсуждения такого рода тем следовало бы пользоваться каким-то определением PLM. Однако я сознаю безнадежность такого совета: у нас любят вести дискуссии, пользуясь своим собственными и разными определениями обсуждаемых понятий, что делает дискуссии особенно яркими и увлекательными.
Хочу пересказать точку зрения на PLM известного аналитика и блоггера Джима Брауна. PLM в глазах читателя может быть чем-то совсем своим, но объективную ценность технологических и методологических компонентов и процессов, которые перечисляет Джим отрицать нельзя – как бы они вместе или по отдельности не назывались.
Джим пишет, что хотя термин PLM задуман как средство характеристики группы решений, которые служат стержнем обработки информации о продукте и процессах в течение жизненного цикла продукта, случилось так, что часть этой характеристики, относящаяся к информации о продукте и процессах, куда-то исчезла. Это привело к мифу о том, что ядром PLM как решения является именно жизненный цикл. Но суть решения концентрируется вокруг
продуктов, создаваемых предприятиями: ведь именно продукт является центром бизнеса.
С продуктами, напоминает Джим, даже с теми, которые выглядят самыми простыми, связана сложная информация. Поддержание всей этой информации в адекватном и синхронизированном состоянии является чрезвычайно сложной задачей. Эта задача еще более усложняется, когда информация содержит огромные САПР-файлы, отражающие сложные отношения между данными. Даже просто хранение, обновление, совместное использование и защита таких файлов является трудной работой. Но PLM – это гораздо больше, чем данные о продукте. Помимо информации о продукте, PLM имеет дело с процессами. Создание новых версий продуктов, их разработка и конструирование – все это состоит из массы разнообразных взаимосвязанных процессов, распределенных по разным отделам, компаниям и нередко географически удалены друг от друга. Вот это пересечение продукта с ассоциированными с ним процессами и составляет сущность PLM.
Итак, подчеркивает Д.Браун, речь идет о контроле над данными о продукте и о процессах, сопровождающими жизненный цикл продукта, что позволяет разделить весь набор PLM-решений на две главные части, на решения для
-
Цифрового Проектирования (или - Прототипирования) – программных инструментов, с помощью которых инженеры в процессе разработки продукта, выполняют свои конструкторские функции, направленные на создание конкурентоспособных изделий,
-
Цифровой Разработки Продукта – решений, которые помогают управлять и координировать процессы вывода коммерческого продукта на рынок и осуществлять контроль над таким выводом.
Рисунок, приведенный в статье Д.Брауна (см. выше), подчеркивает еще один ключевой аспект PLM –
«проектный». За рамками индивидуальной работы и индивидуальных процессов возникают группы, разрабатывающие продукты, и проекты над которыми работают такие группы. Поддержание связей между проектами по разработке продукта и командами, осуществляющими такую разработку, -- серьезная задача. В последнее время эта задача усложнилась, поскольку создание продукта приобрело глобальный характер и нередко связано с аутсорсингом, что сделало редкой ситуацию, когда все члены команды работают в одном и том же месте. Поскольку успешность создания нового продукта и его запуск на рынок (СНПЗ) чрезвычайно важны для прибыльности компании, способность PLM поддержать проектную компоненту в дополнение к разработке продукта, является крайне ценным качеством. Для такой поддержки PLM предоставляет средства управления проектами и средства совместной разработки. Такие средства играют ключевую роль в повышении эффективности работы команд разработчиков.
В последнее время сами по себе
средства совместной работы привлекли большое внимание. Значительный акцент был сделан на возможности как можно более полного цифрового представления продукта с тем, чтобы разделение работы над ним могло осуществляться электронным образом. Такая возможность позволяет, уже на ранних стадиях разработки, большему числу людей вносить вклад в создание продукта и в его оценку, что способствует избежать многочисленных ошибок. Кроме того, подобное сотрудничество многих людей формирует ценную информацию, способствующую продажам и сопровождению продукта после его вывода на рынок. Возможности доступа многих людей к разнообразной содержательной информации о продукте, включая 3D-модели, повышают эффективность всех процессов – от начальных стадий конструирования до документирования продукта и его обслуживания.
Джим не обходит стороной и явно ставший модным аспект внедрения в разработку продукта
методы социальных вычислений. К этому относится использование средства обмена мгновенными сообщениями, социальные сети, профили, блоги, базы данных, основанные на вики-движках и др.: все это помогает группам разработчиков весьма эффективно работать в рамках расширенных команд. Многие компании реально начинают включать средства Web 2.0 в набор своих PLM-решений. Дж. Браун полагает, что такие средства являются естественным расширением PLM, поэтому, скорее всего, в следующие 5 лет они станут обыденными для передовых PLM-систем – по мере того, как все большее число предприятий научится извлекать пользу из социальных подходов.
Наконец, обсуждая
соотношение PLM и ERP, Дж. Браун высказывает точку зрения о том, что плодотворный вариант проведения границы между PLM и ERP – это трактовка PLM как оси всех данных и процессов, связанных с продуктом, а ERP – как исполнительного устройства, которое управляет продажами, поиском клиентов и поставками, а также непосредственно – процессами производства. В таком случае ERP имеет дело с процессами, от заказов до их исполнения, включая и все финансовые операции. Большинство компаний сочетают ERP и PLM, прежде всего, интегрируя Релиз для Тиражирования (RTM) и Управление Инженерными Изменениями (ECM). И все же, заключает Джим, разграничение ролей между PLM и ERP в будущем не будет легким, особенно с учетом того, что поставщики ERP решений наращивают свои собственные решения в области PLM.
Джим Браун (Jim Brown) – видный американский аналитик в области САПР с двадцатилетним стажем. Первая его консалтинговая компания была поглощена известным агентством Aberdeen Group, в котором несколько лет проработал и сам Джим. Затем он основал аналогичную компанию «второго поколения» под названием tech-clarity, миссия которой хорошо перекликающаяся с названием, состоит в как можно более ясном представлении современных технологий. Для отражения одного из главных направлений своих интересов, Джим ведет блог о PLM.
Оригинал статьи Джима Брауна был опубликован в июльско-августовском номере журнала DEVELOP3D. DEVELOP3D – это, вероятно, единственный из оставшихся бумажных достаточно распространенных журналов в области САПР/PLM на английском языке.
.
