Юрий Ершов
Возраст: 47 лет
Образование: Московское высшее техническое училище им. Баумана, специальность «автоматизированные металлургические машины и агрегаты»
Послужной список:
2008 — настоящее время
Электростальский завод тяжелого машиностроения (ЭЗТМ), директор по конструкторской и исследовательской работе, главный конструктор
2005 — 2008
ЭЗТМ, начальник конструкторского бюро
1993 — 2005
ЭЗТМ, главный инженер проекта
1991—1993
ЭЗТМ, ведущий конструктор
1985 — 1991
ЭЗТМ, инженер-конструктор
Было бы неверно утверждать, что эволюция автоматизированных решений сулит избавление от различного рода издержек — просто на смену одним издержкам приходят другие. И не всегда предприятия к ним готовы.
«При внедрении систем автоматизированного проектирования на бизнес-процесс разработки новых изделий накладываются дополнительные процессы. Они-то и влекут за собой новые издержки, в частности лицензионные затраты на программное обеспечение, которое в среднем раз в два года приходится обновлять, на обслуживание компьютерной техники и пр. В результате оказывается, что применение компьютеров ускоряет работу конструкторов далеко не сразу. Через это разочарование надо было пройти, им нужно было переболеть», — вспоминает Юрий Ершов, директор по конструкторской и исследовательской работе, главный конструктор Электростальского завода тяжелого машиностроения. Завод производит оборудование для металлургических, сортопрокатных и трубных цехов, горнодобывающей, цементной промышленности, а также выпускает специальные станы. Расположен в подмосковной Электростали.
В советское время в конструкторском бюро завода работало более 500 специалистов, два года назад их было двести. Экономический кризис привел к сокращению числа сотрудников до 120—130.
На момент внедрения первых CAD-систем на заводе практически не было никакой ИТ-инфраструктуры. «Так как коллективная и групповая работа при проектировании изделий у нас преобладает, нам требовалась некая система, объединяющая отдельных конструкторов между собой. Специфика нашего производства в том, что мы создаем штучные объекты, причем довольно крупные. Один такой объект может состоять из примерно 11 тыс. изделий», — поясняет Ершов.
От решения на платформе AutoCAD, работавшего в то время на базе DOS, специалисты конструкторского бюро отказались в пользу решений на платформе «Компас» компании «Аскон», поскольку, по словам Ершова, AutoCAD не была адаптирована для управления конструкторской документацией. «В системе “Компас” была хорошо проработана подготовка спецификаций различных уровней. В других оболочках мы не увидели генератора спецификаций», — вспоминает Ершов.
Внедрение САПР спровоцировало быстрый рост объемов конструкторской информации, в которой стало непросто разбираться. «В определенный момент конструкторских файлов стало много, их нужно было структурировать, организовывать поиск в них. Кроме того, спецификацию проектируемого изделия в дальнейшем надо транспонировать в другие документы, в частности в производственную спецификацию (для этого у нас разработаны определенные алгоритмы). Или вот еще пример: на основе конструкторского документа нужно сформировать ведомость, например покупных изделий, причем не по какому-то отдельному узлу, а по заказу в целом. Когда мы описали круг задач, которые хотим решить, специалисты “Аскон“ порекомендовали нам обратить внимание на возможности PLM-систем, в частности, на “Лоцман: PLM”», — рассказывает Ершов.
Первые сомнения
При внедрении CAD-систем руководители и участники проекта понимали, что быстрого эффекта ожидать не стоит. Эффект появится позже, по мере накопления данных, когда удастся повысить качество обработки конструкторской документации и уменьшить число ошибок (поскольку трехмерное моделирование позволяет быстрее распознать композиционные ошибки). Кроме того, переход на электронное конструирование повысит эффективность и качество производства, а также улучшит работу маркетинговой службы (в частности, упростит создание рекламных материалов с описанием продукции).
«Начав развертывание PLM-решения, мы столкнулись с очень серьезными издержками, поскольку появились дополнительные бизнес-процессы, связанные с проверкой, контролем и поддержанием базы данных конструкторской документации в актуальном состоянии», — отмечает Ершов.
По его мнению, ИТ-компании отличает особый подход к PLM-системам. У всех разработчиков PLM-решений, с которыми специалистам завода приходилось общаться, первичной была информация из систем CAD/CAM, а интеграция с PLM-системой была вторичной — во главу угла ставилась структура изделия (причем именно в графическом исполнении); затем она экспортировалась в PLM-систему. Конструктор должен выдать чертеж, подготовить спецификацию, а потом все это экспортировать в PLM. Но, во-первых, для конструктора это дополнительная работа. Во-вторых, если в конструкторской документации обнаружится ошибка, то нужно внести исправления не только в эти, но и во все другие документы и системы, которые так или иначе опираются на данные из документов, содержащих ошибку. Встает вопрос: кто должен отвечать за актуальность информации в базе данных?
«Традиционная модель для нас не подошла, — вспоминает Ершов. — Возможно, для японских или немецких коллег с их культурой производства подобное решение было бы вполне приемлемо, но отечественная специфика производства, в том числе НИОКР, предъявляет свои требования».
Задача осложнялась тем, что вопрос об эффективности PLM-системы повис в воздухе. Было непонятно, как в деньгах оценить пользу, получаемую, например, от сортировки данных, выдачи каких-то оценок, рекомендаций; как обосновать необходимость трат на поддержание информации в актуальном состоянии и пр.
В какой-то момент в КБ завода были готовы к тому, чтобы закрыть проект внедрения PLM-системы. «Примерно в 2005 году начался внутренний кризис из-за того, что издержки оказались просто немыслимыми. Между тем руководство ставило задачу в течение года автоматизировать процесс подготовки конструкторской документации. Определенные результаты были достигнуты, но они потянули за собой новые сумасшедшие расходы. Референтные визиты к коллегам не помогли — выяснилось, что они столкнулись с такими же проблемами, внедрив сначала CAD, потом PLM. Все соглашались с тем, что поддержание данных в актуальном состоянии представляет собой большую проблему, и у всех были сомнения в том, что база данных верна. В результате мы зашли в тупик. Мы вынуждены были запросить у разработчиков подробное описание PLM-системы. После его внимательного изучения решили попробовать поставить во главу угла PLM-систему, а не CAD», — вспоминает Ершов.
Идея основывалась на том, что если конструктор работает со спецификацией, то она должна стать PLM-объектом. На основе описания системы «Лоцман» было создано клиентское приложение, реализующее редактор спецификаций непосредственно в PLM-системе. Вскоре появилась первая версия заводской конструкторской спецификации, введенная непосредственно в PLM-систему, минуя CAD. Конструкторы восприняли нововведение позитивно. Таким образом, процесс подготовки и формирования спецификации в «Компасе» был заменен на аналогичный процесс в PLM-системе. CAD-систему стали использовать как средство получения отчетов о текущем состоянии конструкторской документации.
«Отчет формируется по определенным правилам, конструктор не имеет права изменять эти правила и этот отчет. Его нужно создать в системе, распечатать, расписаться и сдать в архив. Своей росписью конструктор подтверждает, что информация в документе верна. Эта информация уже присутствует и в PLM-системе. С одной стороны, бумажная версия пригодится на случай разбирательств, с другой — имеется привычный для конструктора верификационный процесс. Таким образом, все устоявшиеся процессы и с точки зрения конструктора, и с точки зрения ИТ-службы сохранились, хотя и в несколько измененном виде», — поясняет Ершов.
Новые возможности
К настоящему времени в редакторе спецификаций, вводимых конструкторами в PLM-систему, реализованы дополнительные функции, такие как автопоиск, автозаполнение, справочник стандартных изделий и пр. «Раньше, находясь в информационной среде CAD/CAM, конструктор не видел, что происходит за пределами его индивидуального проектного пространства. Теперь все сопрягаемые разработки собраны в одной базе данных. Нам было важно добиться, чтобы конструктор мог работать в PLM-пространстве, не тратя времени на интеграционные процессы и на проверки соответствия данных. Решение было с одобрением воспринято конструкторами, поэтому его внедрение по отделу в целом прошло достаточно безболезненно», — считает Ершов.
Сейчас специалисты решают проблемы, связанные с технологической подготовкой производства. Ситуация в цехах пошла по другому пути: вместо того, чтобы разработать свою структуру документооборота в PLM-системе и создать редакторы документов, необходимых для технологической подготовки производства и собственно изготовления изделия, систему «Лоцман» решили интегрировать с другой PLM-системой, то есть реализовали тот самый подход, от которого конструкторы постарались уйти, когда убедились в его неэффективности. Коллеги предпочли выгружать данные из CAD-системы в PLM, а потом обратно в CAD. Как и следовало ожидать, заметных положительных результатов такое решение не принесло.
Как бы там ни было, конструкторы продолжают совершенствовать свою информационную модель. Схему конструкторского документооборота, которая была разработана специалистами заводского КБ, пришлось самостоятельно поддерживать и развивать, заодно исправляя собственные ошибки и перепрограммируя приложение при выявлении несоответствий. Например, не сразу удалось учесть и отразить в PLM-системе отдельные сценарии событий, некоторые редкие случаи, встречающиеся при производстве изделия и не описанные в структурной модели, и пр.
Постепенно конструкторы пришли к идее использовать базу данных PLM-системы не только для хранения информационной модели изделия или предприятия, но и как модель интерфейса пользователя при работе с PLM- системой: клиентское приложение, которое является надстройкой над PLM-системой, «читает» модель и отображает ее на экране в виде необходимых пользовательских интерфейсов и сервисов. Таким образом, интерфейс пользователя адаптируется под ту или иную задачу. Пользователь, подключаясь к базе данных, получает всю нужную информацию, которая визуализируется в зависимости от решаемой задачи.
Затем возникла еще одна, совсем неожиданная идея. «Система моделирования, названная нами “Visual Лоцман”, превратилась в самостоятельную оболочку. Она управляет документами, загружая только те приложения, которые нужны для редактирования и работы с этими документами, и контролируется из единого центра. У нас появилась идея заменить Windows Explorer на рабочих местах производственных пользователей на нашу оболочку, способную предоставлять производственнику именно ту задачу, которую он должен выполнять, не давая ему ни на шаг отклониться от нее. Но пока это только идея», — поделился планами Ершов.