Распределенное проектирование: аккумулируя лучшее

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

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

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

Одним из немногих исключений является проект разработки базового двигателя ПД-14, осуществляемый в рамках федеральной программы создания семейства двигателей на базе унифицированного газогенератора. За его реализацию отвечает Объединенная двигателестроительная корпорация, которая определила круг исполнителей. Ведущим предприятием стал пермский «Авиадвигатель», компанию ему составили еще несколько крупных разработчиков. Политика ОДК очевидна: аккумулировать лучшие силы, так как проект весьма серьезен, а сроки по нему определены предельно сжатые. Предприятиям, обладающим значительной компетенцией в конструировании, дано задание на разработку одного или нескольких узлов двигателя. Перед руководством «Авиадвигателя» встала проблема организовать взаимодействие разнородных предприятий. Эту задачу призвана решить технология управления жизненным циклом изделий (Product Lifecycle Management, PLM), постепенно реализуемая в рамках сотрудничества.

Игра по правилам

«К реализации подобных решений приводит сама жизнь. Мы ощущаем потребность в PLM и реализуем ее», — говорит Сергей Бормалев, директор по ИТ предприятия «Авиадвигатель». Были сформированы технические требования к осуществлению ИТ-поддержки проекта ПД-14. Эти требования постоянно наращиваются и на данный момент соответствуют классической концепции PLM.

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

«Авиадвигатель» как головной разработчик активно помогает коллегам. Для проектирования на всех предприятиях используются CAD/CAM-система NX и PLM-система Teamcenter фирмы Siemens. Для того чтобы организовать взаимодействие всех этих предприятий, используется модуль Teamcenter Multi-Site Collaboration. Разумеется, этот обмен защищен — сертифицированные ФСБ программные и технические средства шифруют все виды трафика.

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

В технических требованиях по ИТ-поддержке проекта определены несколько основных пунктов: помимо централизованной работы через единую PDM-систему, наличия ВКС и защищенных каналов, они включают использование системы управления проектами Microsoft Project и системы объединенных коммуникаций Microsoft Lync. Эти требования постоянно развиваются в соответствии с возникающими потребностями. Впоследствии они согласуются с предприятиями-соисполнителями и включаются в планы работ.

«Обычно мы внедряем решения у себя, доказывая их работоспособность, и делимся опытом с партнерами», — говорит Бормалев.

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

Кроме того, компания подобралась разношерстная, предприятия находились на разных уровнях развития ИТ. Например, PDM-системы использовались не на всех предприятиях. CAD/CAM-системы использовались, но далеко не в тех масштабах, которые требовались. Отстающим пришлось помогать, оперативно подтягивая их до уровня, необходимого для реализации проекта. Более того, пришлось стандартизировать используемые системы. Под эти работы со стороны ОДК были выделены деньги. В результате построенная система взаимодействия охватила всех соисполнителей, а также заказчика — корпорацию «Иркут».

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

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

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

С переработкой стандартов

«Актуальность внедрения технологий PLM определяется тем фактом, что в настоящее время мировой рынок отторгает продукцию, не снабженную электронной документацией и не обладающую средствами интегрированной поддержки постпроизводственных стадий жизненного цикла», — отмечает Александр Минин, заместитель директора по ИТ НПК газотурбостроения «Зоря–Машпроект» (Украина). Более того, очень скоро это произойдет и на внутреннем рынке.

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

Создание нового газотурбинного двигателя — длительный и дорогостоящий процесс. На различных этапах в этот процесс вовлекается от 200 до 3000 человек. Традиционно проект­ными материалами являлась бумажная документация, поскольку она наглядна, привычна и не требует никакого дополнительного оборудования. За всю историю завода созданы четыре поколения двигателей. На создание и доводку каждого нового базового образца с помощью традиционных технологий проектирования требовалось около 15 лет. Очень важно было максимально сократить эти сроки, в том числе и посредством использования системы инженерного электронного документооборота.

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

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

Ни одно из решений, существовавших на рынке в середине первого десятилетия XXI века, не покрывало потребностей предприятия. По сути, и сегодня на рынке нет единой PLM-системы — в лучшем случае речь идет о комплекте из нескольких продуктов. Было решено реализовать необходимый функционал с помощью доработки PLM-модуля уже давно использовавшейся ERP-системы IT-Enterprise компании «Информационные технологии». С помощью единого решения удалось связать все процессы инженерной подготовки с процессами управления производством и производственными ресурсами. Кроме того, очень большое внимание было направлено на бизнес-процесс управления конструкторскими и технологическими изменениями.

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

Эффект одной комнаты

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

«К первой группе относятся организационно-коммуникационные проблемы», — считает Николай Нырков, руководитель проектов разработки информационных систем компании «Аскон». Техническая возможность для общения удаленных команд есть (например, средства Skype), но она слабо используется в промышленности. Причины могут быть разными — от требований информационной безопасности до уровня ИТ-грамотности инженеров.

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

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

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

Вторую группу составляют организационно-технические проблемы. Главная из них — управление изменениями (как архивной информации, так и актуальной, находящейся в разработке). Например, во многих решениях давно существуют системы контроля версий, которые включают в числе прочего возможности слияния контента. Но с конструкторами сложнее: большинство CAD-систем не позволяют выполнять такое слияние. Кроме того, при оперативной коллективной работе с изменениями опять-таки важен «эффект одной комнаты» — нужно оперативно координировать эту деятельность, что практически невозможно в удаленном режиме.

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