От программных продуктов — к отраслевым решениям
В процессе эксплуатации PLM-решений заказчик часто сталкивается с проблемой недостаточно эффективного использования приобретенного программного продукта. Рассмотрим одну из причин ее возникновения и возможные пути преодоления.
Опыт применения систем САПР в 90-х годах показал, что с внедрением новых информационных технологий на предприятиях возникали проблемы. Приобретение программного продукта не являлось 100-процентной гарантией успеха, по крайней мере в долгосрочной перспективе. Попытки прямого переложения традиционных (бумажных) методик проектирования и производства на новый инструментарий превращали мощные пакеты 3D-моделирования и производства в аналоги пространственных кульманов. В лучшем случае выигрыш получался только за счет более точной геометрической привязки и компоновки изделия, а также за счет сокращения используемой в проектировании бумаги в обмен на неконтролируемо большое количество файлов. Увы, никто особенно не заботился о сохранении знаний, опыта предприятия и его повторного использования, никто не инвестировал свое время в разработку шаблонов процессов проектирования и производства. Работа шла по такому принципу: быстро и точно воспроизвести объект, потом еще раз воспроизвести, потом еще раз и еще… Типично «бумажный» подход.
Однако вина за возникновение такого рода проблем лежит не только на заказчике, но и на поставщике программного обеспечения. Декларируя универсальный инструмент, разработчик ПО идет на намеренную универсализацию базовых функций, не только делая продукт применимым во всех отраслях промышленности, но и превращая его в набор «сделай сам», а точнее — «настрой специфику сам», в том числе и по части методик сохранения шаблонов процессов проектирования и производства.
Правда, некоторые разработчики ПО предлагают специальный сервис по настройке и адаптации ПО под специфику процессов того или иного сегмента промышленности. Увы, именно этот пункт до недавнего времени настойчиво игнорировался российскими заказчиками, полагающими, что им будет достаточно универсальных решений. Либо заказчики надеялись на свои собственные силы и инвестировали в свои группы внедрения и разработки, что вполне осуществимо в случае создания эффективной группы поддержки.
Возникающие противоречия
Никто, кроме самого заказчика, разумеется, если у него достаточно продолжительный опыт работы с продуктом, не знает, как лучше проектировать и изготавливать продукт, но с использованием старой методологии и инструментария! Значительная часть знаний об изделии — это драгоценный опыт предприятия и сотрудников. Как должен выглядеть продукт, работать, изготавливаться — эти знания универсальны, они не зависят от инструмента, который их описывает.
Однако другая часть знаний зависит от применяемого инструментария: как лучше построить, отобразить, заложить возможность быстрой модификации и редактирования. Именно в этом пункте и заключается одно из главнейших противоречий, тормозящих успешное внедрение систем PLM на предприятиях. Ситуация выглядит так. Заказчик заявляет: «Я знаю, как сделать продукт». С одной стороны, он прав, если говорит об опыте, с другой — нет, если говорит об инструменте. Обычно заказчик формулирует свои требования так: «Дайте мне программный продукт как инструмент, а уж как проектировать с его помощью, я сам разберусь». Это одно из стандартных заблуждений, так как базовые курсы дают знания о работе с универсальными функциями. Однако для эффективной работы этого недостаточно. Специалисты САПР знают, что одну и ту же 3D-модель можно построить приблизительно n! (n-факториал) способами, где n — число геометрических операций (фичерсов). В связи с этим для одного предприятия оптимальным может быть один сценарий, а для другого — совсем другой. Вот почему так важна работа по адаптации программного продукта. Кто должен ее выполнить? Заказчик? Но он не обладает всеми знаниями о программных продуктах, методиках работы с ними, особенностях применения той или иной функции. Производитель ПО? Однако он, как правило, недостаточно знает о специфике изделия, о методах его проектирования и производства.
 |
|
Каков выход?
Вариантов три:
- создание группы компетенции на предприятии;
- привлечение сторонних компаний-консультантов (по сути — внешний центр компетенции);
- направление, в котором уже давно и плодотворно работает компания Dassault Systemes.
В последнем случае речь идет о центрах отраслевых решений (заметьте — не продуктов, а решений) внутри самой компании Dassault Systemes. Создание таких центров имеет достаточно долгую историю. Дело в том, что изначально компания Dassault Systemes работала с очень большими компаниями-заказчиками. Одним из требований корпоративных заказчиков было прямое участие в процессе внедрения и адаптации программных продуктов под требования заказчика, а также разработка специальных методологий по использованию ПО для решения конкретных задач компаний. Корпоративный заказчик напрямую выдвигал требования по адаптации к производителю ПО, запросы направлялись сразу в подразделения R&D (подразделение разработки ПО), где проходила их обработка. Со своей стороны Dassault Systemes получала прямой доступ к корпоративным бизнес-процессам, методологиям и правилам, все больше погружаясь в специфику той или иной отрасли и особенности создания конкретного изделия.
В итоге в выигрыше оказывались все стороны. Заказчик формулировал технические требования к продуктам напрямую и для реализации их работал с R&D. В свою очередь, специалисты Dassault Systemes набирались бесценного опыта непосредственно на предприятии-заказчике в той или иной индустрии и лучше понимали, как и для каких целей используются эти продукты. Так, многие продукты Dassault Systemes рождались под влиянием прямого запроса корпоративных заказчиков, как, например, это произошло с продуктом Aerospace Sheetmetal Design (ASL) для проектирования штампованных деталей из листа для авиационной и космической промышленности. Ценность таких продуктов заключается в том, что в них уже заложены определенные методики проектирования и производства изделий, типичных для различных отраслей промышленности.
Безусловно, имеются и сложности. Перед тем как выдать задание на разработку нового продукта, адаптацию существующего или даже на разработку методики работы с тем или иным стандартным продуктом, Dassault Systemes и заказчик проводят серию стандартных и хорошо отлаженных процедур по выработке технических требований к разработке. Подробно рассматриваются бизнес-процессы. Решается вопрос о копировании существующего бизнес-процесса и воспроизведении его с применением нового инструмента или о создании совершенно новых бизнес-процессов, использующих новый функционал, предоставляемый ПО. Лишь после этого начинается проработка решения.
Под решением следует понимать продукт, состоящий из совокупности стандартных программных модулей, дополнительных программных модулей (кода программ), разработанных специально для данного заказчика, специальных настроек системы, предустановленных процессов, шаблонов деталей и сборок и методологии работы либо в виде шаблонов процессов, либо в виде документа, подробно описывающего последовательность операций.
Укрупненно схему работы Dassault Systemes по поддержке решений для заказчиков можно представить в виде диаграммы (рис. 1).
Рис. 1. Схема организации поддержки отраслевых решений
Задачей центра является разработка решений для оптимизации работы с продуктами Dassault Systemes в отдельных отраслях промышленности. Разработка методологий ведется совместными рабочими группами специалистов, привлеченных и со стороны заказчика, и со стороны Dassault Systemes. В работе группы принимают участие ведущие специалисты компании-заказчика, в том числе разработчики корпоративных методологий. От Dassault Systemes в нее входят эксперты ПО, архитекторы PLM-решений и программисты R&D.
Три сектора и центр диаграммы отображают четыре основных подразделения, вовлеченных в процесс разработки решений для заказчиков.
PLM Program Center — Центр программ. Задачей этой группы является планирование и организация работ по разработке решений для той или иной отрасли промышленности.
Решаемые задачи:
- общее управление проектом;
- управление PLM-программами разработки решений;
- проведение аудита процессов заказчика;
- формирование стратегии разработки PLM-решений отрасли.
Industry Solution Center — Центр решений. Их в настоящее время существует несколько — для каждого крупного сегмента промышленности: авиация и космос, автомобилестроение, судостроение, нефтегазовая и нефтеперерабатывающая промышленность, электрика и электроника, общее машиностроение (Fabrication & Assembly), товары народного потребления и упаковка.
Решаемые задачи:
- управление процессом формирования требований к решению и взаимоотношений с заказчиком;
- адаптация существующих обобщенных приемов работы и продуктов под специфику заказчика и разработка специальной методологии работы с комплексными PLM-решениями.
Deployment Center — Центр детальной проработки решения и индустриализации.
Решаемые задачи:
- разработка специализированных решений в зависимости от групп используемых продуктов (CATIA, DELMIA, ENOVIA, SIMULIA, 3D VIA);
- обеспечение качества разработанного продукта;
- обеспечение всех необходимых интеграций, отработка процессов миграций версий, индустриализация кода.
Knowledge Center — Центр разработки (компетенции).
Решаемые задачи:
- внедрение решения на площадке заказчика;
- обучение персонала заказчика;
- техническая поддержка;
- оказание сервисных услуг, связанных с решением.
Упрощенная схема разработки решения показана на рис. 2.
Рис. 2. Схема разработки решения в подразделениях отраслевых решений
Процесс разработки и внедрения решения ведется объединенной группой представителей заказчика и Dassault Systemes. Каждую неделю проводятся совещания, где рассматривается статус запланированных работ, разрешаются конфликты и вырабатываются тактические планы, что контролируется руководством предприятия и компании Dassault Systemes.
|
|
Что в итоге получают стороны
Заказчик — методологию работы на новом инструменте, оптимизированную, с одной стороны, под бизнес-процессы заказчика, а с другой — под рациональное использование инструмента. Иногда модификацию текущих бизнес-процессов, иногда новые бизнес-процессы, ориентированные на новые инструменты, о которых заказчик даже не имел четкого представления. В результате выполнения специальных тестовых сценариев (так называемых use-case) на примере собственных изделий и документов заказчик получает документальное подтверждение, что тот или иной процесс выполним. Причем заказчику предоставляется целый набор метрик, отображающих полноту реализации тех или иных процессов, и план разработки функциональности, если он на тот момент реализован не до конца. Более того, заказчику предоставляются четко и подробно описанные методики пользования продуктами при выполнении тех или иных процессов, а также рекомендации по настройке и модификации типовых процессов, если требуется модификация описанного сценария. Эти методики схожи с РДК (руководством для конструктора), но с акцентом на правильное использование ПО.
Компания — поставщик решений получает неоценимый опыт работы в реальном окружении, опыт «боевой» эксплуатации ПО, четко расписанные методологии основных бизнес-процессов для той или иной отрасли промышленности, отладку универсальных программных средств по итогам эксплуатации, разработку новых, ориентированных на отдельные отрасли программных продуктов и модулей.
Однако есть еще один, пожалуй, самый важный аспект, которому компания Dassault Systemes уделяет особое внимание в процессе разработки решений для конкретных заказчиков. В продолжение своей политики, направленной на развитие функционала программных продуктов по капитализации знаний предприятия (шаблоны деталей, сборок и процессов), Dassault Systemes также капитализирует знания, полученные при прямой работе с заказчиками, превращая свой опыт в универсальные методологии. Безусловно, разработка универсальных методологий ведется с соблюдением правил конфиденциальности и сохранением прав на интеллектуальную собственность всех заинтересованных сторон. В методиках отсутствует информация, которая могла бы нанести ущерб предприятиям, в сотрудничестве с которыми Dassault Systemes разрабатывает свои решения. На основе анализа процессов нескольких предприятий берутся только базовые принципы, характерные для данной отрасли промышленности. Разрабатываются и документируются подходы к настройкам универсальных методик под возможную специфику заказчика. В итоге получается новый продукт, который может быть предложен другим заказчикам из данной отрасли промышленности, нуждающихся в подобных методологиях.
Такой подход очень эффективен. Компания Dassault Systemes предоставляет высококвалифицированный консалтинг не только по своим продуктам, но и в методологиях их использования в специфических условиях. Предлагаемые методологии надежны и опробованы на многих предприятиях (зачастую являющихся мировыми лидерами отдельных отраслей промышленности), что способствует унификации процессов проектирования, производства и эксплуатации изделий. Это особенно важно в условиях глобализации производства сложных высокотехнологичных изделий. Представьте, что ваша компания начинает новый проект в условиях кооперации с другими партнерами. Предположим, что до настоящего момента вы с данным партнером никогда не работали. Каково же будет ваше удивление, если вдруг окажется, что ваши коллеги работают с использованием процессов и методик, очень похожих на ваши собственные! Сколько времени ваша компания сможет сэкономить на решении вопросов интеграции и интерфейсов, проверки форматов деталей, согласования моделей исполнителей, работающих у разных партнеров!
Если говорить об авиационной промышленности, то спектр предлагаемых методик весьма широк. Например, это рекомендации по формированию структуры продукта в системе PDM и структуры проектных подразделений, по управлению конфигурациями и изменениями, по созданию и управлению мастер-геометрией, проектированию деталей из композиционных материалов и многое другое.
Рис. 3. Пример оформления методики проектирования
На рис. 3 представлен пример оформления таких методик, доступных заказчикам. Помимо специального руководства, в набор решения могут входить и коды программ дополнительных модулей, и специальные файлы настроек систем, и модели, и шаблоны моделей и процессов.
Для того чтобы оценить полноту реализации основных бизнес-процессов определенной отрасли, взгляните на набор решений компании Dassault Systemes для авиационной промышленности, представленный на рис. 4.
Рис. 4. Решения Dassault Systemes для типовых бизнес-процессов авиационной промышленности
По вертикали размещены основные этапы жизненного цикла самолета — от концептуального дизайна до эксплуатации на авиалиниях. Горизонтальные ряды — группы бизнес-процессов, начиная от процессов в отделах продаж и маркетинга и заканчивая производством самолета. Из схемы видно, что практически все процессы создания, производства и эксплуатации самолета могут быть реализованы на базе PLM-решений компании Dassault Systemes.
|
|
Подводя итоги
В настоящее время компании — разработчики ПО создали превосходные инструменты по сохранению опыта предприятий при проектировании и производстве изделий, что способствует капитализации знаний предприятия. В связи с этим необходимы специалисты, которые могли бы разрабатывать и поддерживать базу знаний предприятия. Причем основа такой базы может быть построена разными способами: с использованием собственных разработок центров компетенции предприятия, при помощи компании-партнера или консультанта или посредством специальных отраслевых решений компаний — разработчиков ПО, о которых было подробно рассказано в этой статье на примере Центра отраслевых решений Dassault Systemes.
Руководитель технической службы Dassault Systemes Russia.
|
|
