4 - 2020

Appius-PLM — со скоростью света к оперативному планированию в 1С:ERP

Виталий Богданов,
вице-президент по стратегии и развитию МГК «Световые технологии»
Виталий Богданов,
вице-президент по стратегии и развитию МГК «Световые технологии»

Причина успеха нашего предприятия — комплексная автоматизация в единой среде «1С:Предприятие»: от конструктора и технолога до планирования производства и расчета фактической себестоимости.

Для производства более 9 тыс. модификаций продукции нужна четкость действий на всех стадиях подготовки производства, а такие этапы, как проектирование и актуализация данных под заказчика и рынок в целом, диктуют высокие требования к системам автоматизации. Основой всех наших современных подходов по организации бережливого производства, внедрению эко­эффективных технологий является изделие. Начиная от дизайнерской идеи и заканчивая ее реализацией на производстве, в работу вовлечено огромное число специалистов из различных подразделений. Всем участникам этого процесса необходим современный инструмент для ввода информации в едином стиле, соответствующий их роли, доступ к данным в режиме реального времени. И сделать это можно только при условии использования современных систем управления жизненным циклом изделия (PLM). Исходя из нашего опыта использования системы подобного уровня, четко сформировалось представление об уникальности PLM и при этом глубокой интегрированности с производственной (учетной) системой предприятия. О внедрении на предприятии системы Appius­PLM в рамках корпоративной информационной системы пойдет речь в настоящей статье. Желающим более подробно и интерактивно ознакомиться с нашей компанией предлагаем воспользоваться QR­кодом, который перенаправит вас на сайт МГК «Световые технологии».

Группа внедрения

МГК «Световые технологии»:

  • Иван Лагов — директор Департамента разработки новых продуктов;
  • Ольга Баданина — системный аналитик Группы развития;
  • Евгений Муравьев — заместитель руководителя отдела инженерной поддержки производства;
  • Ирина Суворинова — инженер­технолог отдела инженерной поддержки производства;
  • Денис Романенко — заместитель руководителя конструкторского бюро Товарно­отраслевого департамента «Коммерческое освещение»;
  • Андрей Бородько — инженер­технолог конструкторского бюро Товарно­отраслевого департамента «Промышленное освещение»;
  • Сергей Скрипкин — руководитель направления Департамента ИТ.

ГК «АППИУС»:

  • Владислав Игонин — к.т.н., руководитель отдела внедрения;
  • Андрей Касаточкин — руководитель отдела разработки;
  • Михаил Дубин — менеджер проектов.


Сайт МГК «Световые технологии»

Предпосылки внедрения

С ГК АППИУС и ее программными продуктами конструкторско­технологическая группа и производство компании «Световые технологии» знакомы уже более десяти лет. В то время в качестве инструмента по управлению инженерными данными и подготовке информации для системы учета использовалась система «1С:PDM Управление инженерными данными». В системе конструкторы­проектировщики хранили свою информацию в рамках электронных структур изделия (ЭСИ), которая была доступна для просмотра производственными подразделениями, а именно, мастерами и рабочими, непосредственно в цехах на специализированных информационных терминалах. Технологический блок использовался в качестве основного и единственного инструмента описания маршрутов изготовления деталей и сборочных единиц и расчета материально­трудовых нормативов. Подготовленная информация для учетной системы (на тот момент на предприятии вовсю использовалась система 1С:УПП) в виде спецификаций номенклатуры и технологических карт передавалась в учетную систему. Более подробно о реализации проекта по созданию корпоративной информационной системы можно прочитать в статье «Управление светом» («САПР и графика» № 10’2012).


Статья «Управление светом»

Первый вариант корпоративной системы полноценно использовался нами около семи лет — до тех пор, пока не была выпущена новая система управления предприятием 1С:ERP. Нужно отметить, что от прежнего варианта «Системы первого уровня» мы еще полностью не отказались и ряд подразделений в настоящее время продолжает использовать Аppius­PLM и 1С:УПП. Заявленные возможности 1С:ERP со стороны управления производством, такие как диспетчеризация на межцеховом и внутрицеховом уровне, интервальное планирование, планирование пооперационное и по узким местам и т.д., оказали основное влияние на пересмотр существующего варианта автоматизации производства.

В 2018 году было принято решение о внедрении 1С:ERP и создании новой корпоративной системы, в связи с чем возник вопрос «что делать с PDM?». После переговоров с разработчиком остановились на варианте, предусматривающем возможность конвертации данных до формата, необходимого новой системе. Одновременно с этим были предъявлены дополнительные требования к системе, а именно — использование управляемых форм и веб­интерфейса в соответствии с новыми возможностями платформы «1С:Предприятие».

На тот момент компания АППИУС уже выпустила новое решение «Appius­PLM Управление жизненным циклом изделия», синхронизированное с 1С:ERP. Это была отдельная конфигурация, без возможности прямого обновления с 1С:PDM. На основании технического задания данные из существующей базы были перенесены в новую конфигурацию Appius­PLM под 1C:ERP. И это оказалось самым простым и менее трудоемким процессом, а впереди нас ждала серьезная, кропотливая работа, так как требования к корпоративной системе в рамках единого информационного пространства предприятия за несколько лет оформились в довольно большой и, по некоторым аспектам, на первый взгляд «фантастический» список. Сам перенос информации послужил отправной точкой для внедрения и, по сути, создания системы, подходящей для нашей действительности.

Подготовка к внедрению

По классике проектного подхода была создана группа внедрения и назначены ответственные по каждому из подразделений. Группа внедрения состояла из двух основных направлений. В первое вошли ведущие специалисты конструкторско­технологических подразделений, во второе — специалисты компании АППИУС из Департамента разработки, отделов внедрения, обучения и технической поддержки. За координацию всех действий в рамках проекта внедрения отвечали ведущие аналитики нашей компании.

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

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

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

Согласно проекту внедрения, его длительность составляла шесть месяцев при условии своевременного выполнения всех этапов. Но всё предусмотреть невозможно, и в результате срок выполнения проекта увеличился фактически на четыре месяца. Но не будем забегать вперед, расскажем обо всем по порядку.

Внедрение

Работа закипела! Руководитель отдела внедрения компании АППИУС лично провел ряд встреч с проектной группой, на которых были подробно разобраны все особенности новой системы, обсуждены ключевые моменты, касающиеся сравнения базовой функциональности системы с потребностями, определенными на начальном этапе. В результате появилось первое техническое задание для разработчика. В рамках службы технической поддержки компании АППИУС были определены сотрудники, которые в online­режиме проводили консультации для пользователей. По договоренности большая часть вопросов решалась посредством удаленного подключения; в качестве инструмента для связи использовался Skype для бизнеса.

Первым делом было решено наладить обмен в рамках всей корпоративной информационной системы, и на это ушло довольно много времени и сил. За разработку отвечала отдельная сторонняя компания. Основными требованиями к обмену были: сокращение времени обмена до нескольких секунд против прежних десятков минут; систематизация и прозрачность правил обмена для простоты их поддержки и доработки; автоматизированный контроль обмена с предоставлением отчета по ошибкам, самотестирование новых правил; обновление без переподключения пользователей и т.д. Было решено максимально использовать действующие правила, так как они учитывали множество нюансов всех используемых конфигураций. По ссылке из QR­кода можно ознакомиться с отдельной публикацией, посвященной обмену, организованному в рамках корпоративной информационной системы, — в ней очень подробно и профессионально описана созданная модель. Со стороны пользователей нужно отметить, что этот обмен позволяет в режиме online обеспечивать единство данных во всех системах.


Организация обмена в рамках корпоративной информационной системы

Номенклатура — это один из основных справочников предприятия, а выверенный единый справочник номенклатуры — залог успешной работы всей информационной системы. Организация этого вопроса потребовала много дополнительного времени, вследствие чего запланированные сроки по этапу проекта были нарушены, но потраченные усилия дали свой результат. В итоге для нас оптимальным вариантом оказалось создание отдельной базы НСИ, где рождается и хранится нормативно­справочная информация. Единственное, для чего было сделано исключение, — это номенклатура полуфабрикатов: она автоматически появляется в Appius­PLM на определенных этапах производственных маршрутов. С точки зрения уникальности за основу был выбран Артикул номенклатуры, а его значение решено было приравнять к уникальному конструкторскому обозначению.

Большое внимание было уделено интерфейсу. Проектная группа столкнулась с многочисленными претензиями со стороны пользователей на неудобства в работе и просьбами сделать систему более дружественной, то есть создать более удобный и интуитивно понятный интерфейс. Основным препятствием для разработчиков в этом вопросе оказалась платформа «1С:Предприятие», которая в ряде случаев не позволяла сделать так, как хотелось. Специалистам технической поддержки пришлось рассмотреть огромное количество пожеланий, чтобы прийти к общему консенсусу с пользователями. В результате остановились на интерфейсе режима «Такси» тонкого клиента, так как он предполагал более гибкие настройки, в большей степени доступные самим пользователям.

Со стороны данных серьезно встал вопрос, касающийся внесения конструкторско­технологических изменений. От классического извещения об изменениях пришлось отказаться в пользу единственной актуальной ресурсной спецификации на каждую единицу продукции. Была разработана специализированная обработка «Групповая замена элементов», которая позволяет выбранный в автоматическом режиме заменяемый элемент заменить по всей применяемости (рис. 1). Замена производится в рамках конструкторского состава и технологии, при этом система отслеживает количество замен и выводит уведомление о результате замены. Замена применима как к производимым и покупным элементам, так и к оборудованию и профессии. Эта же обработка отвечает за актуализацию производственной информации, а именно, переформировывает технологическую схему и подготавливает новые ресурсные спецификации, утверждает их и делает основными со статусом «Действующая», а прежним версиям автоматически назначается статус «Закрыта». В результате осуществления групповой замены ответственным, а эта функция есть не у всех пользователей, в системе сразу появляется вся необходимая для ведения производственного учета информация. Эта обработка, по своей сути, частично заменяя функциональность извещения об изменении, автоматизирует процесс внесения изменений и минимизирует число ошибок, связанных с человеческим фактором.

Рис. 1. Групповая замена и удаление по применяемости

Рис. 1. Групповая замена и удаление по применяемости

Серьезная работа была проделана с допустимыми заменами и способом их указания в составе изделия. Для этого было принято решение использовать пакеты и варианты замен, которые создают конструкторы, а технологи комплектуют этими пакетами технологические операции, при этом в комплектовании участвуют только активные замены. На основании информации по пакетам замен при создании ресурсных спецификаций автоматически заполняется специализированный документ «Разрешение на замену материалов» (рис. 2). В рамках документа прописываются все возможные варианты замены активного элемента, будь то материал, деталь, прочее изделие и т.д., на указанную в пакете допустимую замену. В дельнейшем этой информацией руководствуются на производстве при планировании потребностей.

Рис. 2. Оформление допустимых замен

Рис. 2. Оформление допустимых замен

Дополнительно в системе были введены такие понятия, как аналоги оборудования и вспомогательное оборудование. Это позволило технологам создавать специализированные шаблоны, с помощью которых значительно ускорилась их работа, а для учетной системы данные были подготовлены в соответствии со всеми требованиями. Также был автоматизирован процесс назначения вспомогательного оборудования при выборе основного. В итоге профессия тоже была преобразована в элемент, доступный для указания в рамках технологической операции, что, в свою очередь, сняло ограничение прежней системы, связанное с возможностью указания только одной профессии. Для элемента профессии в системе была организована связь со справочником «Виды рабочих центров», что позволило перейти на указание бригад и групп рабочих. На стороне трудового нормирования было решено разрешить указание норм времени в разных единицах измерения, что сняло ограничения в точности параметров, используемыx в учетной системе.

В Appius­PLM технологи впервые стали полноценно применять типовые/групповые технологические процессы для описания самых распространенных этапов производства, таких как окрашивание и сборка. Основной причиной отказа от подобного описания в прежней версии было отсутствие удобного интерфейса. Существующий в рамках новой системы «Редактор ТТП/ГТП» полностью решил вопрос удобного отображения информации и сделал работу по описанию ТТП/ГТП более простой и информативной.

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

  • контроль выбора оборудования в соответствии с подразделением изготовления;
  • возможность существования только одной действующей ресурсной спецификации в системе;
  • утверждение всего комплекта объектов «Ресурсной спецификации», «Маршрутной карты», «Этапа производства», разрешения на замену и т.д.;
  • автоматический расчет норм времени. Для ряда технологических операций назначен буфер времени, который добавляется автоматически в зависимости от вида операции. В качестве примера можно привести операцию «Сушка», для которой автоматически к норме, указанной технологом, прибавляется два дополнительных часа;
  • автоматизация расчета материальных норм лакокрасочной продукции;
  • различные проверки при утверждении ресурсных спецификаций.

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

В качестве дополнительного средства контроля был разработан ряд отдельных обработок. Одной из них является «Документы и файлы», предназначенная для проверки комплектности документов соответствующими файлами (рис. 3). Необходимость в такой проверке возникла в связи со сложностью ручного контроля и всё нарастающим объемом информации в базе. Обработка сравнения двух ресурсных спецификаций решила многочисленные споры между пользователями и техподдержкой, предоставив инструмент визуализации различий, без которого было сложно доказать правильность работы алгоритмов системы по созданию новых версий спецификаций. Потребность в сравнении конструкторского состава с технологическим, касающемся соответствия комплектности, продиктовала создание необходимой обработки. И в этом списке, на наш взгляд, еще рано ставить точку, так как новые задачи постоянно требуют соответствующих решений.

Рис. 3. Контроль конструкторско-технологической документации

Рис. 3. Контроль конструкторско-технологической документации

Итоги внедрения

В результате проект внедрения завершился спустя десять месяцев, то есть срок его выполнения увеличился на четыре месяца. Но так как внедрение проводилось в режиме рабочего процесса, то, в целом, это оказало минимальную дополнительную нагрузку. В настоящее время в корпоративной информационной системе работают несколько подразделений, находящихся в разных городах России и Украины. Общее число пользователей превышает 250 человек. Организована система мониторинга и сбора информации по возникающим вопросам от пользователей. Для этой цели используется система управления бизнес­процессами и проектами «Первая Форма». Все пользователи и служба технической поддержки компании АППИУС объединены в рамках системы и имеют возможность живого общения. Подобный подход минимизировал время решения возникающих проблем и позволил отслеживать ход выполнения поставленной задачи на исправление ошибок или доработку функционала.

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

Насколько нам известно, большая часть доработок была добавлена разработчиком в базовую конфигурацию «Appius­PLM 2020».

Новые цели

Дальнейшее развитие предполагает внедрение подсистемы обработки параметрических заказов Appius­Конфигуратор, которая позволит автоматизировать процесс принятия заказа, одновременно сформировав производственный состав из множества доступных вариантов изготовления.