Когда речь заходит об автоматизации проектирования, то обсуждаются чаще всего трехмерное моделирование и жизненный цикл изделий. Однако к российской производственной реальности гораздо большее отношение имеют не такие модные, но необходимые процессы технологической подготовки. О практике, сложившейся по этому направлению во ФГУП «ВНИИА им.Духова», рассказывает Евгений Абакумов, начальник отделения информационных технологий.
Intelligent Enterprise: Какова предыстория ваших проектов по автоматизации проектирования?
Евгений Абакумов: Институт был организован в 1954 году как филиал КБ1, первого ядерного центра в Сарове. С тех пор мы прошли большой путь, в том числе в области автоматизации. У нас до сих пор работают люди, которые по праву считаются основоположниками цифрового проектирования в стране. Девяностые были для нашей отрасли годами безвременья, а в двухтысячные началась новая волна автоматизации, которая и продолжается до сих пор.
Основной деятельностью института всегда было проведение научно-исследовательских и опытно-конструкторских работ, изготовление опытных образцов и макетов, передача разработок на заводы. С двухтысячных годов появилось и серийное производство. Из НИИ, проводящего ОКР и НИР, институт превратился в научно-производственное объединение. Одновременно произошла трансформация от полностью оборонной тематики к широкому спектру задач. Мы участвуем в работах по АСУТП атомных и тепловых станций, ведем гражданские разработки, в том числе выпускаем датчики давления для нефтегазовой отрасли. Принципиально, что номенклатура изделий в результате диверсификации изменилась кардинально. Всё это, включая переход к серийному производству, поставило перед нами новые задачи автоматизации.
Очень важный бизнес-процесс — технологическая подготовка производства. Так как мы сами разрабатываем документацию и сами же затем делаем по ней и опытную, и серийную продукцию, он является для нас принципиальным. И один из его элементов — создание маршрутно-операционных технологий средствами автоматизированного проектирования.
Каким образом этот процесс был автоматизирован раньше?
С конца девяностых с этой целью мы применяли систему собственной разработки на базе Access, очень напоминающую текстовый редактор. В ней накапливалась структурированная информация, которая использовалась потом для формирования плана производства, для нормирования операций, определения трудоемкости. Мы всегда старались связывать технологическую подготовку с учетом. Технолог работает не только «на себя», продукт его труда — технологическая документация, основа всех плановых расчетов. В той системе мы этого достигли. Были классификаторы, которые затем использовались для расчета производственного плана и себестоимости изделий, а по данным из «маршруток» рассчитывались экономические показатели.
Но каждый продукт имеет свои ограничения. Со временем объем базы Access стал слишком велик, сами базы были многочисленны и сложно связаны между собой. Потребности в такой автоматизации постоянно росли, в процесс вовлекалось все больше людей. Не только технологам, но и сотрудникам планово-экономических служб стало очевидно, что нам нужен другой, более универсальный и масштабируемый инструмент, а считать себестоимость изделий вручную невозможно. Первоначально использование автоматизированной системы было делом добровольным. Однако с ростом объемов возник устойчивый дефицит маршрутных карт, созданных автоматически.
Чтобы этот дефицит устранить, нужно было технологам, нормировщикам и всем, кто участвует в процессе технологической подготовки, дать единую систему ввода и обработки информации. Во-первых, технологам нужны были средства проектирования технологической работы, прежде всего детализация переходов обработки. Требовался справочник таких переходов, более детальное, чем раньше, описание технологических процессов. Пока речь идет о разработке и опытных образцах, достаточно и укрупненных описаний. Но при серийном производстве уровень их детализации существенно возрастает. Скажем, если раньше можно было просто написать «точить по чертежу», то теперь вся последовательность обработки должна быть описана подробно. Средства технологической САПР дают возможность эти детальные описания брать из базы и компоновать из них нужные последовательности.
Во-вторых, необходима привязка эскизов, вначале двумерных, к маршрутной технологии, а согласование маршрутных карт должно быть не просто автоматизированным, но электронным. Маршрутная карта, как и любой документ, проходит свой жизненный цикл со всей последовательностью согласований и утверждений. Следующий шаг — трехмерные модели изделий, мы пока только переходим к ним, да и нужны они не везде, а главным образом для сборочных операций.
Три года назад сошлись требования всех трех сторон: технологов, нормировщиков, планово-экономического отдела. Было решено перейти на новый продукт, который решал бы все поставленные задачи, причем на продукт внешней разработки.
Как был выбран инструмент и как шло внедрение?
На рынке есть много импортных пакетов для трехмерного проектирования. Для технологической подготовки их тоже хватает, но среди них мало тех, которые удовлетворяли бы требованиям Единой системы технической документации (ЕСТД). Ситуация усугубляется тем, что у нас есть отраслевые стандарты, конкретизирующие требования ГОСТа. В госкорпорации «Росатом» реализуются масштабные программы автоматизации, затрагивающие и единые стандарты. В своих локальных справочниках мы обязаны требования отраслевых документов выполнять.
Ни в одной западной САПР отечественный технолог не узнает интерфейс: это другая идеология. Западные разработчики почему-то всегда занимались CAD-системами, в том числе адаптацией их к российским условиям. Но в области технологической подготовки такого нет. Есть продукты отечественных разработчиков, мы долго и обстоятельно их исследовали и остановились на пакете Techcard белорусской фирмы «Интермех». Другие ее продукты были нам известны и раньше, некоторые даже применяются у нас. Генеральной задачей было извлечь свою старую систему из ИТ-ландшафта, поставить на ее место Techcard и восстановить все интеграционные связи. Сейчас мы эту работу уже практически закончили. Когда мы выбирали продукт, мы имели в виду и опыт наших программистов, которые смогут самостоятельно выполнить его интеграцию с другими действующими системами.
Каковы ключевые элементы вашего ИТ-ландшафта?
Он весьма разнообразен. Есть системы собственной разработки, есть тиражные переписанные нами приложения, и есть тиражные продукты, внедренные без изменений. Мы идем по пути стандартизации и унификации, но не хотим терять накопленных преимуществ.
Конечно, удобно, когда вендор рядом, но с «Интермехом» у нас уникальная модель взаимодействия. На нашей территории их представителей никогда не было, ведь они — граждане хоть и союзной, но другой державы. Мы всегда покупали у них ПО и потом сами его внедряли, консультируясь у разработчиков, которые находятся в Минске. Если нужно, наши сотрудники выезжали к ним, так было и при внедрении Techcard, но в основном мы общаемся по почте и через видеоконференцсвязь. Причем у нас с ними только сублицензионный договор. Никаких соглашений о внедрении и связанных с ним услугах нет и никогда не было. Такие у нас сложились партнерские отношения, и мы это очень ценим. Это вендор, который не только старается получить прибыль, но и действительно обеспечивает ценность для заказчика через свои продукты. У «Интермеха» есть в России партнеры, хотя и немногочисленные, однако мы предположили, что задачи интеграции они нам все равно не решат, а уж установку и обучение мы тем более выполним своими силами. Так оно и оказалось.
В системе развернуто несколько десятков рабочих мест технологов и нормировщиков. Были те, кто двигал изменения, и те, кто им сопротивлялся. Были агенты изменений, проводились оргмеры, издавались приказы, в общем, весь диапазон «кнута и пряника» был применен. Причем пряник превалировал на первых этапах, пока шло разъяснение и агитация, а кнут — на более поздних. С упорными пессимистами приходится бороться организационными мерами, но в целом мы старались идти эволюционным путем.
Принципиально измененять переносимые данные не потребовалось. Изменили структуру справочника операций, но вопросов, связанных с неполнотой данных, не возникло. Это заслуга тех, кто занимался системой до меня и нашей команды. Проработка была серьезная.
А что касается экономического эффекта внедрения — вы пытаетесь его считать?
Сроки создания технологических процессов сократились на 10%, ошибки при проектировании и нормировании — на 15%. Так мы оцениваем результаты, но все же это скорее качественные метрики. У нас есть и более точные инструменты измерения.
Например, корректность загрузки данных для экономических расчетов — число ошибок на загрузку, вполне счетная величина. После внедрения Techcard этот показатель заметно упал. Другая метрика — число технологий, не описанных и не пригодных к автоматическому учету в плане производства. Их тоже легко посчитать, и их число также резко снизилось.
Пограничный вопрос — как оценить продолжительность выполнения отдельных техпроцессов. Этим мы только начинаем заниматься. Анализ данных САПР и MES-системы позволяет организовать корректную обратную связь: измерить реальную длительность выполнения производственного цикла и вернуть ее плановику, который указал плановое время выполнения.
Учесть время на проектирование, на разработку — казалось бы, более простая задача: одну карту закончил, другой занялся. Все требуют сокращения сроков проектирования, забывая при этом или умалчивая о сложности изделий. Более разумно было бы требовать повышения качества проектирования, чем снижения его сроков как таковых. А качество разработки, включая использование численного моделирования, позволит сократить время и ресурсы на многих других операциях, в том числе на изготовлении макетов. Операционная эффективность — одно из серьезнейших требований, которые к нам сейчас предъявляются.