Связующее звено подготовки производства

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

Не PLM единым
Опыт проектов в машиностроении показывает, что, опираясь только на возможности PLM-платформ (даже таких комплексных, как Teamcenter от Siemens PLM Software, Windchill от PTC и Enovia от Dassault Systemes), как правило, не удается полноценно реализовать поддержку технологической подготовки производства, правильно и точно описать технологические процессы и управлять ими. На деле это означает, что формирование документации по технологической подготовке производства, ее передача в электронном виде между конструкторскими и производственными подразделениями, а также поддержание документации в актуальном состоянии как минимум затруднены или вовсе неосуществимы.
Из-за этого возникает целый ряд ограничений — например, когда на этапе проектирования нет возможности учитывать особенности технологии изготовления или ограничения производственной базы предприятия. Из контура автоматизации может выпасть важнейшая информация о составе изделия, техпроцессах, необходимых ресурсах: оборудовании, материалах, оснастке и кадровом обеспечении. Конечно, многие из этих показателей могут быть введены вручную на основе имеющегося опыта и оценок технологов и производственников, но будут ли они точными — это большой вопрос, особенно для новой продукции. Следовательно, руководство предприятия вряд ли получит реалистичные оценки себестоимости изделия, сроков его выхода на рынок, необходимых ресурсов, а значит, не сможет принимать правильные решения.

САПР ТП — не только технологам
Системы автоматизированного проектирования технологических процессов (САПР ТП) как раз призваны устранить эту проблему, с одной стороны, предоставив необходимые инструменты для создания техпроцессов технологам, а с другой — став источником необходимой информации по технологической подготовке производства для других информационных систем. В идеальной архитектуре решения для автоматизации предприятия САПР ТП являются частью (самостоятельным модулем) PLM-системы, обеспечивая двустороннюю передачу информации. Сегодня существует множество локальных САПР ТП, которые успешно решают задачи в своей области. Наиболее известные: «Вертикаль» от АСКОН, Timeline от SDI Solutions, TECHCARD от Intermech.
Интеграция САПР ТП с системами управления данными об изделии (Product Data Management, PDM) во многих случаях может быть осущест­влена штатными средствами, особенно если обе системы от одного производителя. Однако с точки зрения интеграции и совместной работы с PLM-системами верхнего уровня дело обстоит не столь однозначно. Увы, сегодня ни один из производителей САПР ТП не предлагает промышленных решений для интеграции их продуктов со сторонними PLM. Поэтому при выборе любой САПР ТП нужно быть готовым к тому, что в проекте будет значительная доля работ по созданию интеграционных решений, связывающих все элементы в единую информационную систему.
Выбирая САПР ТП, необходимо руководствоваться двумя равнозначными критериями. Во-первых, нужно ориентироваться на потребности служб предприятия, занятых в планировании производства. Разработка техпроцессов должна быть удобной и понятной, иначе велик риск, что процессы будут проектироваться традиционно, то есть на бумаге, а в системе будут отражены только «для галочки», с низкой степенью достоверности.
Второй критерий — возможность выпуска технологической документации в соответствии со стандартами предприятия и гибкость настройки форматов исходящих документов. Все перечисленные выше системы изначально ориентированы на соблюдение стандартов оформления конструкторско-технологической документации как базового требования. Однако многие предприятия в дополнение к ним используют свои формы документов, следовательно, и особые требования могут быть реализованы в этих системах по-разному. Кроме того, даже в рамках одного предприятия могут использоваться разные форматы для разных групп клиентов — для «обыч­ных» внешних заказчиков и, например, для военной приемки. Тогда система должна настраиваться на реализацию различающихся типов сопровождения техпроцессов.

Интеграция: третий — не лишний
Интеграция САПР ТП в общую архитектуру является обязательным условием для соблюдения концепции PLM. Однако во многом из-за сложностей сопряжения этих решений в российской практике проекты по обеспечению полноценного взаимодействия и совместной их работы единичны. И каждый из них уникален.
С архитектурной точки зрения для их объединения может быть применена трехсторонняя интеграция: САПР ТП — PLM, PLM — ERP, ERP — САПР ТП. Однако чем проще архитектура и чем меньше интеграционных связей, тем система более устойчива и жизнеспособна. Поэтому лучшим вариантом архитектуры является интеграция САПР ТП только с PLM как с центральным связующим звеном между всеми инженерными приложениями и источником необходимой информации для ERP.
Общий подход в таких проектах предусматривает, что серьезные изменения (программные доработки) не производятся ни в PLM, ни в САПР ТП. Роль обработчика и интерпретатора данных для двух систем должна лежать на интеграционном решении. В зависимости от сложности поставленных задач технологически этот инструмент может быть разным — как простая программная надстройка, конвертирующая данные, так и, например, целый программный комплекс, обеспечивающий выгрузку данных, их обработку, транспортировку и загрузку в целевую систему.
Промежуточное решение осуществляет преобразование данных, чтобы они были понятны и PLM, и САПР ТП. Одним из наиболее удобных форматов для этих целей является формат структурированного списка (XML). В ходе проекта создаются алгоритмы трансформации данных (таблицы мапирования). Основная сложность заключается в том, чтобы корректно определить требования к объемам, потокам и форматам данных для передачи между системами, а затем формализовать методологию и разработать программную реализацию этих требований. Именно в этих двух вопросах решающую роль может сыграть опыт и профессионализм проектной команды, и именно здесь чаще всего требуется привлечение консультантов, знакомых с обеими системами.

Где хранить НСИ?
Как только возникает вопрос о работе в двух и более системах, на первый план выходит проблема качества нормативно-справочной информации (НСИ) и вопросы управления ею. Вариантов реализации множество: тут и САПР со встроенным НСИ, и PLM-система со своим классификатором, и ERP со своим. Возможен вариант с отдельной системой для управления мастер-данными (Master Data Management, MDM).
Выбор системы для хранения и управления НСИ определяется уровнем задач. Если требуется управлять технологическими данными в PLM без их передачи в ERP, то реализацию НСИ логичнее осуществить в САПР ТП, так как большинство разработчиков этих систем уже предусмотрело инструменты, адаптированные под требования машиностроителей. Естественно, что в этом варианте изменится и общий подход, когда для интеграции САПР ТП и PLM могут быть применены более простые логика и средства. Если же предприятие создает комплексную систему PLM для проектирования техпроцессов, обеспечения сквозной поддержки проектирования и производства, к тому же хочет использовать возможности ERP для планирования и управления производством, то очевидно, что НСИ удобнее хранить в PLM.
Необходимо отметить, что в обоих случаях требуется централизованное управление НСИ через соответствующие процедуры и регламенты. Именно во втором варианте реализации можно построить цепочку, в которой совокупность операций сложится в техпроцессы в САПР ТП, а те — в программу выпуска изделия в PLM, которая будет передана затем в систему ERP для планирования и ресурсного обеспечения производства.
Помимо уже отмеченных преимуществ в виде более точной управленческой информации, такая конфигурация обладает еще одним неоспоримым плюсом: в САПР ТП переносятся вопросы по обеспечению соответствия документации отечественным стандартам. Есть целый ряд особенностей, которые достаточно сложно и дорого реализовать средствами PLM, и даже лидирующие PLM-платформы не могут похвастаться полной поддержкой требований российских стандартов. В этом случае САПР ТП фактически выполняет функции подключаемого локализованного модуля, который решает, во-первых, вопрос расширения функционала там, где у PLM в наших условиях его недостаточно, и, во-вторых, обеспечивает соответствие всем обязательным стандартам документации.