Интеграция 1С:ТОИР с системами мониторинга оборудования на Ломоносовском опытном заводе

Ломоносовский опытный завод — основной российский производитель и поставщик комплектующих для железнодорожного транспорта и поездов метро. Продукция предприятия востребована не только в России, но и за ее пределами — во многих странах Европы и в Прибалтике. На заводе идет активное внедрение инновационных технологий, а с 2019 года предприятие работает в новой автоматизированной системе для управления ремонтами и обслуживанием оборудования.


Автоматизация управления производственными активами

В ноябре 2019 года на Ломоносовском опытном заводе внедрена автоматизированная система для управления ремонтами 1С:ТОИР 2 КОРП. Внедрение выполняла компания — разработчик системы — «Деснол Софт». В результате проекта было автоматизировано 50 рабочих мест, около 1500 объектов ремонта внесено в систему — это оборудование дивизиона интерьера и экстерьера для пассажирского железнодорожного транспорта и метрополитена.

В результате проекта внедрения 1С:ТОИР на заводе на 12% снизились затраты на содержание и на 4% — на ремонт оборудования, на 3% сократились производственные издержки, на 50% ускорилось получение управленческой отчетности.

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

Следующим шагом автоматизации производственных процессов стала интеграция 1С:ТОИР с системой мониторинга оборудования АИС «Диспетчер».

— В АИС «Диспетчер» хранится архив управляющих программ, что очень удобно для контроля производства. Из 1С:ERP в АИС «Диспетчер» выгружаются номенклатура и информация для формирования техпроцесса на новые изделия. В АИС формируются сменно-суточные задания: данные по их выполнению можно отслеживать по каждому станку — каждое состояние (ремонт, простой, ожидание) фиксируется через систему мониторинга оборудования. В зависимости от параметров контроля производства ведется либо контроль времени, либо контроль подсчета деталей, либо процесс выполнения управляющей программы.

Таким образом, мы используем АИС «Диспетчер» и как архив управляющих программ, и в качестве инструмента для контроля производства. Почему бы еще и не анализировать данные прямо в АИС «Диспетчер»? Дело в том, что функционалу программы не хватает гибкости в формировании отчетности. В системе мониторинга данных много, однако требуемые нам отчеты здесь не сформируешь.

АИС «Диспетчер» — система мониторинга и мало подходит для учета. Поэтому необходимые данные для изучения и аналитической обработки мы — за счет механизма интеграции — переносим в 1С:ТОИР.

Евгений Савельев,
заместитель руководителя департамента разработки, внедрения и сопровождения информационных
систем управляющей компании «Ключевые
системы и компоненты», обслуживающей
ПФ «КМТ «Ломоносовский опытный завод»

Как 1С:ТОИР используется для анализа данных?

Как уже было сказано выше, в базе 1С:ТОИР — более 1500 объектов ремонта, в их числе — 42 станка с программным управлением (ЧПУ), а также основное технологическое и вспомогательное оборудование.

Какой именно анализ данных проводится сейчас с помощью 1С:ТОИР на Ломоносовском опытном заводе?

  • Специалисты отслеживают, какие затраты (материалы, трудовые ресурсы) на каждую единицу оборудования произведены, какие материалы израсходованы, какова стоимость материалов, какова трудоемкость. Есть возможность проанализировать, какие модели станков наиболее затратны в обслуживании.
  • Определяют долю затрат на ремонты от общей реализации предприятия и сравнивают этот показатель с плановым.
  • Анализируют отказы по ЧПУ — собирают информацию по основным показателям оборудования с числовым программным управлением — наиболее дорогостоящего и технологичного.
  • Определяют виды поломок и потерь по каждой единице оборудования за отчетный период. С помощью инструментов бережливого производства — «Пять почему», диаграммы Ишикавы, диаграммы Парето — выполняется анализ причин отказов и разрабатываются планы мероприятий, приводящих к снижению нежелательных показателей. Затем специалисты по надежности контролируют выполнение этих планов.
  • При работе с ППР проводится анализ процента выполнения плана. Процент выполнения — один из ключевых показателей эффективности службы эксплуатации.
  • Анализируются и внеплановые ремонты. Ведется журнал учета проведения аварийных ремонтов, который помогает видеть все зарегистрированные дефекты: виды, время устранения, частоту возникновения.
  • Специалисты рассчитывают основные показатели надежности. Анализируются основные показатели работы оборудования, время ремонта, время между поломками (MTTR, MTBF).
  • В числе важных отслеживаемых показателей — среднее время ремонта по всему оборудованию.
  • Анализируется и динамика изменения уровня поломок оборудования за каждый отчетный период.
  • Контролируется средний уровень поломок, т.е. процентное соотношение общего времени работы оборудования к времени простоя в период ремонта.
  • И, наконец, в фокусе внимания всегда находится «Топ наихудших» — 20 единиц оборудования, которые имеют самый высокий показатель уровня поломок.
Благодаря 1С:ТОИР сотрудники завода получают всю эту информацию оперативно, в необходимых объемах и разрезах для анализа. На основе поступивших точных данных специалисты проводят анализ результативности, принимают решение о том, как совершенствовать процессы и таким образом влияют на общую эффективность.

Как снизить простои и увеличить отдачу от активов?

Сегодня мы поговорим об одной конкретной прикладной задаче — как сократить простои. И о том, как Ломоносовскому опытному заводу в этом помогает интеграция 1С:ТОИР с системой мониторинга оборудования.

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

Сокращать потери традиционно можно двумя способами.

  • Первый путь — улучшение процессов производства и обслуживания с целью минимизации количества простоев. Например, борьба с авариями и переналадками, улучшение планирования, совершенствование технологии ремонта и т.д.
  • Второй путь — оптимизация жизненного цикла простоя. При оптимизации жизненного цикла простоя главная задача — свести к минимуму временные интервалы, не связанные напрямую с выполнением ремонтных работ: время обнаружения поломки, время регистрации и реагирования, время диагностики, время ожидания материалов, время сдачи-приемки объекта в эксплуатацию и возобновления работы.
На Ломоносовском опытном заводе идут обоими путями, чтобы решить главную задачу и увеличить отдачу от активов за счет снижения простоев и роста доступности оборудования.

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

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

— Приведу пример. У каждой из наших служб есть свои KPI — ключевые показатели эффективности. Есть они и у служб ремонта, и у производственных служб. На деле выходит так, что на ключевые показатели эффективности производства сильно влияет то, что связано с ремонтами. Служба ремонта работает не круглосуточно. Станок может сломаться в любое время. Представим себе такую ситуацию: станок сломался вечером и всю ночь простоял без ремонта. Кто при этом теряет? Теряет производство. Станок не функционирует, продукция не выпускается, компания в убытке — теряет прибыль.

А на ключевой показатель эффективности эксплуатационной службы этот простой не повлияет! Ведь дефект официально зафиксирован с утра. И только с утра началось его устранение.

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

Евгений Савельев,
заместитель руководителя департамента разработки, внедрения и сопровождения информационных
систем управляющей компании «Ключевые
системы и компоненты», обслуживающей
ПФ «КМТ «Ломоносовский опытный завод»

Что дает сопоставление данных? Можно ли на деле подтвердить, что подобные потери существуют? Чтобы это выяснить, нам надо сопоставить данные, которые дает система мониторинга оборудования АИС «Диспетчер» и проанализировать их в 1С:ТОИР.

В системе мониторинга фиксируется реальное время отказа. В 1С:ТОИР падает задача и формируется заявка на ремонт, которую видно на корпоративном портале. Специалист службы эксплуатации тут же получает уведомление по SMS.

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

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

Например, станок вышел из строя, диагностика заняла полтора часа. Обнаружилось: пришел в негодность привод. Что дальше? Если служба снабжения не подготовилась, новый привод придется ждать месяц. Месяц станок будет выведен из строя. А ремонт потом проведут за 2 часа!

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


— Сейчас к системе мониторинга подключено 40 станков из трехсот — это станки с ЧПУ, лимитирующее дорогостоящее технологичное оборудование, которое для компании наиболее ценно.

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

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

Евгений Савельев,
заместитель руководителя департамента разработки, внедрения и сопровождения информационных
систем управляющей компании «Ключевые
системы и компоненты», обслуживающей
ПФ «КМТ «Ломоносовский опытный завод»

На что обратить внимание на проекте интеграции?

Интеграция 1С:ТОИР с АИС «Диспетчер» на проекте на Ломоносовском опытном заводе была выполнена впервые в истории существования двух продуктов. Для того, чтобы добиться качественных механизмов обмена данными, была проделана большая работа со стороны каждого из разработчиков — компании «Деснол Софт», разработавшей 1С:ТОИР, и компании «Цифра», которая является автором АИС «Диспетчер».

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

Мы поинтересовались у Евгения, на что бы он посоветовал обратить внимание и разработчикам, и заказчикам при интеграции системы мониторинга с системой учета управления активами. И вот что он рассказал.

1. Необходимо сопоставить НСИ двух систем

Первое: необходимо сопоставить нормативно-справочную информацию двух систем. Иерархия станков обязательно должна соответствовать друг другу. Уровень сопоставления — до инвентарных номеров изделий.

2. Необходим поэтапный подход к запуску интеграции

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

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

3. Необходимо продумать параметры загрузки

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

4. Необходимо сопоставить виды эксплуатации

Четвертый вопрос, с которым вы столкнетесь, — это необходимость сопоставления видов эксплуатации. Видов эксплуатации в АИС «Диспетчер» гораздо больше, чем есть в 1С:ТОИР. И не все они нужны для анализа. Поэтому мы что-то убрали в одной системе, что-то добавили в другой. Понимая логику того, какой отчет хотим получить на выходе, мы можем принимать решения о необходимой степени детализации состояний оборудования. Например, мы хотим не просто видеть «простой», а простой в разрезе причин: «простой по причине отсутствия оператора», «простой по причине отсутствия заготовки для изделия», «простой по причине поломки» и так далее.


— Преимущества, которые дает интеграция решения для управления ремонтами с системами мониторинга оборудования, очевидны.

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

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

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

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

Евгений Савельев,
заместитель руководителя департамента разработки, внедрения и сопровождения информационных
систем управляющей компании «Ключевые
системы и компоненты», обслуживающей
ПФ «КМТ «Ломоносовский опытный завод»

Поделиться: