Зайцев: О заводах, ИТ и людях

Результаты пилотов, которые запускали в августе Как и обещал, делюсь результатами пилотов, которые мы запускали в августе. Начало можно почитать здесь. За этот месяц нам удалось внедрить мониторинг на 2-х предприятиях из трех, т.к. с последним согласование подключения затянулось, и мы установили оборудование только на прошлой неделе. Какие результаты показали 2 тестовые недели на первых двух производствах делюсь ниже: 🚩Пилот №1 Напомню, необходимо было зафиксировать работу ночных смен на станках, а также показать реальную загрузку оборудования и точное время на обработку детали по заданию. Мониторили 2 типа станков: фрезерные и токарные (по 5 каждого типа). Каждое утро, в 8:00, отчет о состояниях в виде файла excel уходил на почту генеральному директору и ит.специалисту, а также был настроен доступ к мониторингу в реальном времени, долговременной аналитике, отчету по причине простоя и итоговому отчету. Тестовые 2 недели показали, что на фрезерном участке загрузка оборудования составляла от 39 до 81%, при этом ночные смены справлялись с работой значительно лучше, но присутствовала проблема с дисциплиной регистрации в системе. На токарном же участке загрузка оборудования была ниже и составляла от 12 до 51% , при этом в начале пилота она была высокой, а потом резко спала у обеих смен из-за простоев по технической неисправности станка, затянувшегося технического обслуживания и длительной смены заготовок. При этом в первую неделю показатели ночной смены были выше дневной на 6-12%, но потом упали в 4 раза и не поднимались выше 30%. Т.е. мониторинг показал, что работа ночной смены, в которой изначально были сомнения, в действительности гораздо лучше справляется с работой, чем дневная и больше внимания нужно уделить тем, кто работает днём, а не ночью. Итоги пилота: приняли решение продолжить мониторинг оборудования с дальнейшим развитием в виде привязки к номенклатуре и интеграцией с 1С. 🚩Пилот № 2 Задачей на пилот было зафиксировать реальное время работы прессов в рамках часовой нормы. Для этого мы подключили оборудование к клапану смыкания и размыкания пресс-формы и в режиме реального времени предоставляли данные по загрузке оборудования и причинах простоев. По каждому станку можно было «провалиться» в детализированный отчет и посмотреть во сколько работа была начата, как долго длиться перезарядка, сколько перезарядок делается и во сколько работа заканчивается. Все эти данные фиксировали операторы, которые должны были регистрироваться в системе. Каждое утро директор по производству и мастер участка получали ежедневный отчет о состоянии оборудования, в котором фиксировалось количество произведенной продукции за сутки и время, затраченное на переналадку. За 2 недели мониторинг показал, что оборудование загружено в среднем на 50% и действительно есть операторы, которые справляются с переналадкой быстрее, выпуская больше продукции, а есть те, кто сокращает цикл работы, увеличивая таким образом брак. Итог пилота: приняли решение продолжить мониторинг, но доработать дашборды: предоставить возможность операторам выбирать пресс-форму и дополнить список простоев для экструзии.

Улучшения, которые внедряем сейчас В продолжение темы про улучшения, которые мы внедряем (начало здесь) (https:/...27) буду рассказывать, какие изменения происходят внутри компании и чем они обусловлены. Так как для нас важно, чтобы качество услуг, которые мы предоставляем было высоким, мы постоянно работаем над улучшаем системы, опираясь на пожелания клиентов и проблемы, которые замечаем сами. Одна из доработок, над которой мы работали последнее время и которую уже начали внедрять – это новый сетевой модуль «Оса». Это не первый её вариант, уже есть «Оса», которой мы измеряем выпуск количества изделий на производствах с помощью оптических датчиков. Поэтому у нас появилась её доработанная версия, о деталях которой расскажу ниже. Изначально, первым сетевым модулем, с которым наша компания вышла на рынок был «Паук». Он передавал данные, полученные с токовых клещей на сервер, и по нему мы предоставляли производству информацию о причинах простоев и работе оборудования. Это была полная информация по загрузке станков, но в ней не содержалось информации по количеству выпущенной продукции. Со временем, получая точные данные о загрузке машин, с помощью которых удавалось оптимизировать работу производства, нашим клиентам захотелось получать такие же данные и по выпуску продукции. Именно для этих целей и была разработана первая «Оса», позволяющая устанавливать оптические датчики на начало и конец ленты и таким образом считывать число произведенной партии и сверяться с планом. Оба модуля отлично работают в связке, но всплыла проблема, никак не связанная с нами, но которая затрудняла передачу данные с модулей на сервер и которую мы довольно быстро заметили. Эта проблема – пропажа связи. Дело в том, что и «Паук» и «Оса» подключены к сети с помощью сим-карт и передают данные на сервер через оператора связи. На некоторых территориях заводов эта связь может глушиться или производство находится в принципе в месте, где связь сложнодоступна. И получалось, что станки работали, токовые клещи и оптические датчики информацию передавали, а мы не получали достоверные данные потому, что они до нас просто не доходили. Следовательно, мониторинг становился лишь частично верным, что абсолютно не устраивало ни одну из сторон. Поэтому мы решили модифицировать предыдущую версию «Осы», в которой закрыли сразу 2 проблемы: 1. Мы объединили «Паука» и первую «Осу» в один модуль и теперь новая версия включает в себя все возможности предшественников 2. Теперь все данные передаются на сервер через Wi-Fi, к которому мы подключаемся на заводе. Если же он «отваливается», то данные продолжают передаваться по старой схеме, с помощью сим-карт. А также «осы» сами могут раздать связь между собой при достаточной плотности расстановки оборудования в цеху. Т.е. потеря связи перестаёт быть проблемой, пока хотя бы одна «оса» видит интернет. Новинку сейчас только начинаем внедрять в эксплуатацию, поэтому буду делиться подробностями, если тема интересна.

Выстраивание бизнес процессов. Как изменилось моё восприятие Как только наша компания стала быстро расти и я системного начал погружаться в процессы и их выстраивание, органично получилось, что любую коммуникацию внешнего бизнес мира я стал рассматривать с точки зрения бизнеса. Это достаточно интересно оценивать: кто, как, зачем и что  делает? Раньше эти моменты просто проходили мимо меня. Сегодня расскажу две истории: одна связанна с продажами, а другая с маркетингом. Примерно в феврале 24 года мы занимались выстраиванием процесса продаж. Собственно, и сейчас занимаемся и непонятно, когда все это закончится..)) Так вот… я искал сервис, который мог бы анализировать разговоры менеджеров по продажам и выявлять какие-то ключевые вещи или контролировать их. Это бы экономило нам время на прослушивании и позволило бы переключиться на другие бизнес-задачи. Я наткнулся на рекламу сервиса, посмотрел его и отложил. Потом мне на глаза попалась статья или отзыв о них, и я решил уже оставить заявку. Попробовать. Казалось, что нам сможет помочь их сервис. Т.е у ребят хорошо отработал маркетинг. В несколько касаний они дотянулись до меня с выгодным предложением. Я заполнил форму на сайте, выбрал дату и время, удобные для созвона, и с утра пришел на онлайн-встречу. Прихожу, а там никого. Ну, может опоздал человек? Жду… ничего не меняется. Захожу в почту, чтобы написать и спросить что случилось и вижу, что прошлым вечером созвон был отменен. Я, конечно, частично сам виноват, что пропустил отбивку, но, учитывая, что сообщение пришло после 17, а созвон был назначен на 10 утра, то ситуация с пропуском письма вероятна. Тем более в аутлуке часто отмены созвонов приходят вообще в какую-то свою папку и это легко можно не отследить. Я немного офигел от такого подхода и пошел в канал, где видел рекламу. Я знаком с тем, кто его ведёт и спросил не знает ли он лично человека и что за странная тема? Выяснилось, что этот сервис стартап (ок, понимаю, сами были или все еще) и основатель (оказывается с кем должен быть созвон) видит своей целевой аудиторией компании с 4+ продавцами, а я в тот момент указал что у нас 2. Пообщавшись, мы пришли к выводу, что звонок отменили по этой причине. Но еще тогда мне показался сомнительным такой подход. Зачем предлагать время, если гипотетическая компания не подходит вам по численности при заполнении анкеты? Почему не ввести какой-то минимальный тариф? Я на тот момент посчитал, что заплатить за 5 продавцов, а использовать для 2 для меня было бы нормальным, если бы сервис был полезен. Зачем отменять звонок в последний момент и никак не сообщить об этом? Ведь есть номер телефона, адрес телеграма. И халатность нельзя спихнуть на неопытность человека из продаж. Как я узнал, опытом продаж там хороший. Почему вдруг вспомнил об этом случае сейчас? На прошлой неделе они мне позвонили. Видимо, решили актуализировать старую базе. И с таким первым подходом были посланы сразу. Желания с ними работать нет никакого. Если бы первоначально человек так не поступал и нормально объяснил, что сейчас ему не интересно работать, то и сейчас разговор был бы другой. Вторая история связана с маркетингом. Если вы смотрите сериалы или кино на сайтах «еще не заблокированных роскомнадзором», (и я не про взрослый контент), то зачастую видите рекламу казино, букмейкеров и так далее. Много там откровенного скама, но суть в том, что этим ребятам приходится сильно выкручиваться с креативами, чтобы зацепить внимание. И бывают очень интересные истории с точки зрения маркетинга. Например, последнее что я увидел, смотреть со звуком: htvk.com/...5b8Видео с точки зрения маркетинга близко к гениальности для той аудитории, на которую оно рассчитано. Во-первых, оно тихое. Нет громкой музыки для привлечения внимания, как на всех аналогичных видео, есть шепот. С первого раза лично я не понял почему тихо и что шуршит? И посмотрел в ноут, чтобы понять. Во-вторых, внимание привлечено. Очевидно, что целевая аудитория  - это мужчины. На видео девушка, которая, я бы сказал, специфически одета, но скорее специфич

Опубликовали кейс на VC В нём рассказали, как с помощью мониторинга оборудования выявили на металлообрабатывающем предприятии 35% резервного времени для повышения загрузки станков и сохранили 2,5 миллиона рублей , не купив новый. В статье поделились, как решали задачи по: 1) предоставлению реальной загрузку станков и повышению производительности узких мест производства 2) созданию системы контроля операторов для повышения полезного времени работы 3) созданию системы контроля ремонтных работ для оперативного реагирования на проблемы узнать подробнее, оставить комментарии, поделиться обратной связью можно по ссылке (https:/...yi) ⤵️

Написали статью, в которой рассказали, как с помощью мониторинга оборудования повысили загрузку на мясокомбинате на 29% и сэкономили 8 миллионов рублей. С каким запросом к нам пришли, какие задачи поставили и как мы их решали. Подробности кейса по ссылке ⤵️ hvc.ru/...lei

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

Наши пилоты В рамках рассказа о компании я буду делиться не только кейсами, которые собираем и планируем публиковать отдельно, но и пилотами, которые запускаем прямо сейчас. Сначала о терминологии: пилот — это тестовый период, во время которого предприятие в течение демо-периода (14 дней) тестирует мониторинговую систему на своём предприятии. Так как причины простоев даже в одинаковых нишах бывают совершенно разные, то, на мой взгляд, интересно узнавать и то, с каким запросом клиенты приходят, и то, как мы технически решаем поставленные задачи. Подробнее о работе самой системы и её установке писал в статье. В посте коснусь части пилотов, которые запущены прямо сейчас. 1. Пилот: Чем занимается предприятие: Производством различных видов редукторов и муфт промышленного назначения Оборудование: 30 станков ЧПУ и универсалы Количество смен: 2 (дневная и ночная) Проблемы производства: Увидеть реальные цифры загрузки оборудования и точное время на обработку детали по заданию, так как сроки по заказам стали срываться. По расчетам руководства, выручка должна быть в 2 раза больше, а сотрудники столько не делают, объясняя это тем, что срывают сроки из-за неверного планирования и позднего поступления сырья. Заготовки приходят, например, в конце мая, а сдать нужно уже в июне. Как фиксировали простои раньше: вручную. Директору для повышения контроля приходилось приезжать ночью на производство самому и отсматривать видео с камер Какие задачи поставили: а) контроль ночных смен b) увидеть реальные цифры по загрузке оборудования и точное время на обработку детали по заданию, чтобы привязать мотивацию сотрудников к количеству выполненных заказов Какие станки подключили к мониторингу: 5 фрезерных и 5 токарных 2. Пилот: Чем занимается предприятие: Производством силикона на заказ (силиконовые трубки, пластины, кольца, шары, полотна и т.д.) Оборудование: более 20 гидравлических прессов Количество смен: 1 дневная Проблемы производства: Отследить причину простоев, а также посмотреть сколько запрессовок производят в час. Сейчас подозревают, что операторы 3 часа курят, а потом за оставшееся время добивают план. Бригадир может договориться с рабочим, норму выполняют неправильно и отдел технического контроля это пропускает, потому что снаружи брака нет, а качество изделий страдает. Как фиксировали простои раньше: вручную Какие задачи поставили: а) зафиксировать реальное время работы прессов в рамках часовой нормы, чтобы повысить качество выпускаемой продукции. Какие станки подключили к мониторингу: 10 вулканизационных гидравлических пресса 3. Пилот: Чем занимается предприятие: Производство холодного и теплообменного оборудования для отраслевых задач любого масштаба (рефрежераторы на автомобиль, кондиционеры для микроавтобусов, воздухоохладители, драйкулеры, антикоррозийное покрытие и т.д.). Оборудование: более 100 шт. Количество смен: 3 смены 24/7 Проблемы производства: Интересует работа ночной смены, так как загрузка от дневной сильно отличается. Из-за отсутствия контроля ночью одному Богу известно что там происходит. Заказы растут, требуется понимать насколько реально загружены станки и нужно ли как минимум докупать новое? По камерам отслеживать проблематично, не насмотришься. Человеческий фактор есть, но все понимают, что это не объективная информация. Есть проблемный участок с обрабатывающими центрами: постоянно как не посмотрит - оборудование стоит по различным причинам, тормозит всё производство. Как фиксировали простои раньше: вручную заносили в google файл все остановки и заявки на ремонт Какие задачи поставили: а) контроль ночных смен b) зафиксировать насколько реально загружены станки для планирования производства. Все 3 пилота позволят увидеть реальную картину того, что происходит на производстве и начать внедрять изменения уже в тестовый период. Я же поделюсь итоговыми результатами 14-дневного мониторинга и теми данными, которое получит каждое из них по завершению проекта. 

Это четвертая часть про то, как работает наш сервис и как мы начинали его разработку. Начав с измерения экономии электроэнергии в кВт*ч, мы в итоге пришли к тому, что стали мониторить полезную загрузку станков и предоставлять инструмент для ее увеличения. Получив информацию о том, что станок простаивает, мы через специально написанного чат-бота в «Телеграмме» спрашиваем у оператора причину простоя. Причины простоя настраиваются заранее, чтобы информация была релевантная и сопоставимая, иначе ее нельзя будет собирать в единую систему и анализировать. Для понимания того, сколько информации или различных бизнес-сценариев можно получить благодаря данным о потребляемом объеме электроэнергии и ответу оператора, укажу лишь часть этих сценариев. 1. Оператор указывает причину простоя как «Отсутствие заготовок», после чего запускается сценарий уведомления начальника заготовительного цеха о том, что на станке N нет деталей для работы и станок простаивает. Начальник заготовительного цеха дает поручение сотруднику Х доставить на этот станок заготовки, сотрудник Х собирает тележку и везет заготовки на станок. Так как взаимодействие происходит через чат-бот, все действия, от приема заявки до назначения ответственного сотрудника, фиксируются в базе данных. С одной стороны, кажется, что ничего сложного в том, чтобы привезти заготовки на станок, нет. С другой стороны, между собой взаимодействуют минимум три человека и два подразделения, и если на любом этапе что-то пойдет не так, то ключевое оборудование может простаивать, а простой узких мест, по сути, равен простою всего завода. 2. Оператор указывает причину простоя как «Поломку станка», после чего запускается сценарий уведомления начальника ремонтного отдела о том, что станок N сломался. В зависимости от того, к какому классу оборудования относится этот станок, может быть несколько дальнейших сценариев. Если это ключевое оборудование, то в случае, когда к ремонту не приступают в течение 30 минут, идет эскалация уведомлений вплоть до уведомления директора завода. Если оборудование НЕ ключевое, то эскалации может и не быть, но у начальника ремонтного отдела будет информация о том, что сломалось на станке по мнению того, кто на нем работает, и начальник сможет выбрать специалиста, которому предстоит ремонтировать данный станок, а не гонять туда-обратно персонал с информацией о том, что и как сломалось. При этом вся информация о поломках собирается в базе данных, и по прошествии времени она позволяет принимать различные организационные или бизнес-решения о дальнейшей эксплуатации станков. 3. Зафиксирован простой, и оператор указывает причину простоя как «Переналадку». Облачное ПО «Энкост» запрашивает в «1С ERP» клиента номера заказов, которые ещё не были взяты в работу, получает их и предлагает оператору выбрать, на какой именно заказ он переключает оборудование. Далее, зная, какой номер заказа на каком станке находится, клиент может прогнозировать время готовности заказа и вносить корректировки, ставя важные заказы в приоритет (например, отдавая в ПО «Энкост» сначала только важные заказы, а уже когда они сделаны — все остальные). Также в рамках одного заказа фиксируется фактическое станочное время, что помогает правильно нормировать сменные задания. Часто бывает, что при 100%-м выполнении сменного задания фактическое станочное время работы не доходит и до половины. Иногда это нормально, а иногда становится откровением для руководства предприятия.

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

Продолжаю рассказ о том, как работает наш сервис и как мы начинали его разработку. Поняв, что мы можем собирать информацию о работе и простоях станков, мы решили проверить, как можно работать с этой информацией и какую пользу из нее может получать наш клиент. Для этого мы обратились к нашему постоянному клиенту, которому оказывали другие услуги, с предложением установить приборы на его производстве и начать собирать информацию. Клиент занимается металлообработкой. Наш первый вариант был установлен на лазере, координатно-пробивном и гибочных станках. Главная проблема заключалась в том, чтобы найти решение, которое дало бы нам возможность понимать, работает станок или простаивает с точки зрения программы. Когда за станком смотрит оператор, он может посмотреть на графики и их соответствие реальной работе, но на каждый станок не посадишь по человеку, поэтому требовалось как-то автоматизировать этот процесс. Если не вдаваться в детали, то спустя неделю размышлений и тестирования различных вариантов мы пришли к тому, что анализировать данные каждую секунду нет смысла и нужно агрегировать их в большие периоды времени, для того чтобы эти значения могли сглаживать секундные колебания тока. Это убрало часть проблем, связанных с резкими падениями потребления в период работы, например, когда головка лазера двигается по листу в новую точку, но не режет его. Но после этого появилась другая проблема: из-за сглаживания графика прекращение работы становилось заметным не сразу. Возникал вопрос: каким образом мы будем решать, когда случился тот момент, что станок не работает?