23 Ноября 2021
Ломоносовский опытный завод — основной российский производитель и поставщик комплектующих для железнодорожного транспорта и поездов метро. Продукция предприятия востребована не только в России, но и за ее пределами — во многих странах Европы и в Прибалтике. Заместитель руководителя департамента разработки, внедрения и сопровождения информационных систем управляющей компании «Ключевые системы и компоненты» Евгений Савельев рассказывает о том, как проходит развитие информационных технологий завода с целью повышения эффективности производственных и сервисных процессов.
Вы можете посмотреть видео или прочитать статью — как вам будет угодно.
В ноябре 2019 года на Ломоносовском опытном заводе внедрена автоматизированная система для управления ремонтами 1С:ТОИР 2 КОРП. Мы совместно с разработчиком «Деснол Софт» автоматизировали 50 рабочих мест. Сперва интегрировали 1С:ТОИР с 1С:УПП, а в 2020 году перешли на 1С:ERP. Внедрили производственный учет и объединили систему для управления ремонтами с 1С:ERP. После этого добавили интеграцию с системой мониторинга оборудования — АИС «Диспетчер».
В АИС «Диспетчер» хранится архив управляющих программ, что очень удобно для контроля производства. Из 1С:ERP в АИС выгружается номенклатура и техпроцесс на новые изделия. В АИС формируются сменно-суточные задания: данные по их выполнению можно отслеживать по каждому станку — каждое состояние (ремонт, простой, ожидание) фиксируется через систему мониторинга. В зависимости от параметров контроля производства ведется либо контроль времени, либо контроль подсчета деталей, либо процесс выполнения управляющей программы.
Таким образом, АИС «Диспетчер» мы используем как:
Почему бы не анализировать данные прямо в АИС «Диспетчер»? Функционалу программы не хватает гибкости в формировании отчетности. В системе мониторинга данных много, однако требуемые нам отчеты здесь не сформируешь.
АИС «Диспетчер» — система мониторинга в первую очередь и мало подходит для учета. Поэтому необходимые данные мониторинга для изучения и аналитической обработки мы — за счет механизма интеграции — переносим в 1С:ТОИР.
Как мы используем 1С:ТОИР для анализа данных?
В базе 1С:ТОИР у нас более тысячи объектов ремонта, в их числе 42 станка с программным управлением, а также основное технологическое и вспомогательное оборудование.
Благодаря 1С:ТОИР мы получаем всю эту информацию оперативно, в необходимых объемах для анализа. Можем проводить на основе данных анализ результативности и таким образом влиять на эффективность.
Сегодня мы поговорим об одной конкретной прикладной задаче — как сократить простои. И как нам в этом может помочь интеграция 1С: ТОИР с системой мониторинга оборудования.
Работа над тем, чтобы потерь было как можно меньше, — это постоянная работа, это регулярные улучшения, которые доступны при использовании автоматизированной системы управления активами.
Сокращать потери мы можем традиционно двумя способами.
Мы идем обоими путями.
Задача, которую мы решаем, — увеличение отдачи от активов за счет снижения простоев и роста доступности оборудования.
Итак, дано. У нас есть две системы:
Первая система работает в режиме реального времени. Поставляет достоверную информацию о простоях, загрузке, наработках на отказ и технологиях каждой единицы оборудования в каждый момент времени.
Вторая система — 1С:ТОИР — ведет, так сказать, синтетический учет — по заявкам, учитывает время диагностики, поступления запчастей и так далее по цепочке выполнения ремонта.
И, что крайне важно, мы можем сопоставить данные одной системы и другой и… найти отклонения в рабочих процессах. То есть обнаружить те самые точки оптимизации.
Приведу пример.
У каждой из наших служб есть свои KPI — ключевые показатели эффективности. Есть они у служб ремонта, есть у производственных служб.
На деле выходит так, что на ключевые показатели эффективности производства сильно влияет то, что связано с ремонтами. Служба ремонта работает не круглосуточно. Станок может сломаться в любое время. Представим себе такую ситуацию: станок сломался вечером и всю ночь простоял без ремонта. Кто при этом теряет? Теряет производство. Станок не функционирует, продукция не выпускается, компания теряет прибыль.
А на ключевой показатель эффективности эксплуатационной службы этот простой не повлияет! Ведь дефект официально зафиксирован с утра. И только с утра началось его устранение.
Но давайте скажем честно: если бы ремонтная служба зафиксировала дефект еще вечером и приступила бы к его устранению в ночную смену, производство, возможно, даже не заметило бы простоя. И спокойно продолжило выполнять свою первоочередную задачу: производить ценный конечный продукт.
Как мы можем подтвердить, что подобные потери существуют? Для этого нам надо сопоставить данные, которые дает нам система мониторинга и проанализировать их в 1С:ТОИР.
Итак, что мы имеем сегодня?
В системе мониторинга мы фиксируем реальное время отказа. В 1С:ТОИР падает задача и формируется заявка на ремонт, которую видно на корпоративном портале. Специалист службы эксплуатации тут же получает уведомление по SMS.
Зафиксировав точное времени происшествия и сопоставив его со временем реагирования, мы видим, как улучшить процесс. Например, если есть проблема с «ночными простоями», о которых мы говорили выше, можно сделать службу ремонта трехсменной или круглосуточной. Или принять другое организационное решение.
Главное, что у нас есть инструменты, чтобы получить достоверные данные и на их основании сделать выводы.
Подобные ситуации мы обнаруживаем, сопоставляя самые разные временные промежутки жизненного цикла простоя.
Вспомните жизненный цикл отказа. Есть целый ряд причин, которые могут привести к простою. Это и промедление на этапе регистрации дефекта, и задержка при поступлении запчастей и материалов.
Например, станок вышел из строя, диагностика заняла полтора часа. Обнаружилось: пришел в негодность привод. Что дальше? Если служба снабжения не подготовилась, новый привод придется ждать месяц. Месяц станок будет выведен из строя. А ремонт потом проведут за 2 часа!
Повышая достоверность учета, мы снижаем время реагирования, повышаем оперативность взаимодействия разных служб. Решение подобных ситуаций помогает снизить напряженность и периодически возникающий конфликт интересов между службами производства, ремонта и снабжения.
Сейчас к системе мониторинга у нас подключено 40 станков из трехсот. Конечно, в первую очередь мы подключили лимитирующее, дорогостоящее, технологичное оборудование, которое для нас наиболее ценно. Это станки с ЧПУ (числовым программным управлением). Если оборудование выходит из строя, устанавливается состояние «Ожидание ремонта», фиксируется точное время происшествия, технический специалист отрабатывает заявку.
Задействован участок механической обработки деталей — очень часто это узкое место на производстве. Часть деталей этого направления часто отдают на аутсорсинг, чтобы снизить риски, ведь именно здесь постоянно могут возникать сложности с персоналом и с качеством. Особенность Ломоносовского опытного завода — в том, что для нас такой участок необходим, это наше конкурентное преимущество. Именно здесь, на этом участке отрабатываются и опытные, и серийные изделия. Поэтому, как вы сами понимаете, каждая минута промедления или простоя на таком участке очень дорого обходится компании.
Это первый проект такого рода. АИС Диспетчер впервые был интегрирован с 1С:ТОИР. Для этого была продела большая работа со стороны разработчиков, чтобы добиться качественных механизмов интеграции. Планируем тиражировать решение на другие предприятия управляющей компании.
На что бы мы посоветовали обратить внимание и разработчикам, и заказчикам при интеграции системы мониторинга с системой учета управления активами?
Первое: необходимо сопоставить нормативно-справочную информацию двух систем. Иерархия станков обязательно должна соответствовать друг другу. Уровень сопоставления — до инвентарных номеров изделий.
Второй сложный момент. Надо определить степень полноты данных, которые мы хотим передавать из одно системы в другую. Не надо забирать всё и сразу. Забирать данные — это не самоцель. Надо понять, как их интерпретировать, с чем сопоставлять, как и для чего анализировать, как потом использовать.
Мы начали с загрузки состояний объектов ремонта, потом добавили пункт загрузки выявленных дефектов. Контролируемые показатели пока не загружаем, но, скорее всего, будем в ближайшем будущем. Данные по сотрудникам (по операторам, которые закреплены за конкретными станками) тоже пока не передаем. Это нам еще предстоит настроить, но интеграция это позволяет.
Третий момент, на который надо обратить внимание. Интеграция, конечно, достаточно гибкая. Вместе с тем данных в АИС Диспетчер собирается действительно много, поэтому надо четко продумать и выставить параметры загрузки. Такие, как детализация загрузки и ее периодичность. Нам, например, удобнее загружать данные для анализа не ежедневно, а каждую неделю.
Четвертый вопрос, с которым вы столкнетесь, — это необходимость сопоставления видов эксплуатации. Видов эксплуатации в АИС «Диспетчер» гораздо больше, чем есть в 1С:ТОИР. И не все они нужны для анализа. Поэтому мы что-то убрали в одной системе, что-то добавили в другой. Понимая логику того, какой отчет хотим получить на выходе, мы можем принимать решения о необходимой степени детализации состояний оборудования.
Например, мы хотим не просто видеть «простой», а простой в разрезе причин: «простой по причине отсутствия оператора», «простой по причине отсутствия заготовки для изделия», «простой по причине поломки» и так далее.
Не учитывается время приемки оборудования. После того, как станок был отремонтирован, производством он может быть принят в эксплуатацию неизвестно когда. Эти показатели мы тоже хотим визуализировать, сопоставляя данные двух систем.
Кроме того, мы хотим разработать функционал, который позволит заблаговременно предупреждать производство о плановых ремонтах. Чтобы можно было корректировать загрузку оборудования и управлять технической готовностью станков.
Итак, чтобы подытожить, перечислю преимущества, которые дает интеграция с системами мониторинга оборудования.
Поделиться:
