Здравствуйте! Я Владимир Зайцев, основатель и генеральный директор компании Encost (Энкост). С 2013 г. мы помогаем клиентам-производственникам экономить на электроэнергии, но это отдельная история: мы пытались заработать, создав онлайн-калькулятор цен на электричество, а по факту стали сами корпеть над расчётами и переводить клиентов на более выгодные тарифы. В 2021 г. мы опять хотели заработать, помогая клиентам экономить электроэнергию, но сокрушительно промахнулись с запросом и чуть было не остались с любовно созданным и никому не нужным девайсом на руках. Но в итоге, после сбора обратной связи и допилов, мы превратили этот ненужный девайс в систему мониторинга для промышленных производств – Энкост Мониторинг. Вот эту историю с неожиданным поворотом я и хочу сегодня рассказать.

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

«Заработаем на онлайн-калькуляторе расчета электроэнергии! Что может пойти не так?»

 В начале этого пути мы толком ничего о производствах не знали и узнавать не планировали – просто с 2013 г. помогали юрлицам снижать затраты на электроэнергию. Сначала сделали онлайн-сервис – калькулятор, который показывал, из чего складывается ценообразование (для юрлиц это довольно замороченный процесс, у многих компаний был запрос плана: «Хотим убедиться, что не переплачиваем за электричество»). Собственник брал информацию со счетчика электроэнергии (это массив значений о почасовом потреблении за месяц), загружал эти данные на сайт, указывал параметры: регион, поставщик электроэнергии и прочее. Система на выходе выдавала все возможные варианты тарифа, доступные потребителю, и собственник мог понять: использует он сейчас самый выгодный для себя тариф или переплачивает.

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

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

«Заработаем на устройстве сбора данных об энергопотреблении! Что может… А, ну да»

 Мы разработали под свою идею устройство удаленного сбора данных о потреблении электроэнергии. Выглядело оно так: токовые клещи цепляются на провода, по которым запитан потребитель – станок или целый цех, или здание, что угодно. С токовых клещей на серверный модуль идёт аналоговый сигнал, мы его обрабатываем, по LoRa-каналу передаём на свою базовую станцию, а оттуда на свой сервер. На сервере сигнал преобразуем в киловатт-часы. Да, тут не было суперточности, поскольку мы не отслеживали напряжение каждой фазы и коэффициент мощности. Но у нас и не было задачи делать скрупулёзные измерения, была задача отслеживать явную неэффективность использования электроэнергии – типа «У вас в выходные дни по всему зданию продолжает работать вентиляция».

Модуль с токовыми клещами мы назвали «Паук». Название показалось нам страшно удачным, и мы так считаем до сих пор, хотя и приходится уточнять: на провода мы цепляем токовые клЕщи, а не клещЕй. Возникает временами такая избыточно членистоногая ассоциация.

Хабр, это «Паук». «Паук», это Хабр.
Хабр, это «Паук». «Паук», это Хабр.

После первых тестов мы обнаружили пару досадных недочётов в своём подходе:

  • LoRa как технология связи не соответствовала нашим задачам: чем дальше базовая станция от «Паука», тем реже уходят пакеты данных. Если станция находится хотя бы в 300 метрах от «Паука», то сигнал отправляется лишь один раз в 10-15 секунд, если на пути есть преграды – раз в 20 секунд, ну и так далее по угасающей.

  • Если сам «Паук» отключится от питания (например, когда пропал свет на объекте или устройство отключили принудительно), – сервер никак этого не поймёт.

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

 Мы примерно полностью промахнулись с запросом!

 Когда мы предварительно обсуждали систему мониторинга с клиентами, то не вполне точно «сверили часы». Мы-то говорили про «Паука» как про способ отслеживать избыточные затраты на электричество, и нам это казалось очень важным. Клиенты живо реагировали: да, это важно! Но когда «Паук» пошёл в жизнь, стало понятно, что желание снизить плату за электричество на условные 5%, – это одно. А желание что-то делать в связи с этим – совсем другое. Потому что когда мы для своих клиентов решаем задачи по изменению тарифов (сами!), – клиенты довольны весьма. Но они оказались совершенно не готовы, имея данные с «Паука», самостоятельно регулировать энергопотребление на своих производствах. Учитывая, что в структуре производственных затрат электроэнергия занимает ну ~4%, а с учётом данных «Паука» энергопотребление можно было бы снизить на 2-5%... никто никуда не включился и не побежал, как вы понимаете. То есть вся затея с нашим «Пауком», по сути, оказалась выстрелом в «молоко»!

Не успели мы удивиться и расстроиться, как оказалось, что производственников крайне заинтересовали другие данные с «Пауков»: на графиках потребления энергии клиенты узрели дневники рабочего дня каждого конкретного станка. И это оказалось очень-очень любопытно! Ведь станок стоит сотни тысяч, а то и миллионы рублей. За работу на нём и за его обслуживание получают зарплаты операторы, мастера, техники. Плюс ежемесячные затраты на электроэнергию, плюс коммуналка… И с удивлением спрашивает себя производственник: а почему же этот жутко дорогостоящий станок простаивает суммарно 20-30-40% рабочего времени?!

 И тут мы наконец расслышали реальный запрос мелких-средних производств.

«Паук» не давал ответ на вопрос «Почему наши станки простаивают?», а значит – нужно было переделать девайс в соответствии с запросом. И мы сосредоточились на системах, которые будут мониторить только станки и ничего кроме. Бог с ним, с избыточным расходом электроэнергии, с условной тепловой завесой, работающей 24/7…

Мы стали смотреть, какие системы мониторинга производств уже есть на рынке. Расспросили своих клиентов, почему они не устанавливают эти системы, чего им там не хватает. Оказалось, в России есть мощные, продуманные программные решения, которые отслеживают причины остановки и недозагрузки производственных линий дотошно, вплоть до контроля параметров работы отдельных узлов каждого станка. Но… Все сложно.

Во-первых и в главных: это очень дорогие решения. Установка системы на один станок обойдётся в 150 000 - 300 000 руб., что является заградительным тарифом для небольших предприятий. И даже крупных производственников может останавливать необходимость солидных капитальных затрат на старте: покупка лицензий на ПО и оборудование. Плюс предварительно нельзя оценить эффективность мониторинговой системы, даже если предприятие может себе позволить её приобрести. Это риск. Может, система не окупится. Может, окажется бессмысленной.

Забегая вперёд: мы решили эту проблему, поставляя свой Энкост Мониторинг как подписку. Наши клиенты не платят за сервер, датчики, связь и так далее – никаких первичных капиталовложений не нужно. Мы решили брать с клиентов «абонентку» в 4 500 – 7 000 руб./мес. за каждый станок, на котором висит система мониторинга. Клиент платит, пока пользуется. Решит отказаться – перестанет платить. В среднем сейчас наши клиенты отдают суммарно около 80 000 руб. в месяц с предприятия за использование Энкост Мониторинга. Оборудование даём бесплатно, первые две недели тестирования системы тоже бесплатно. Нужно только оплатить командировочные расходы сотрудников Энкост, которые приедут и внедрят систему на предприятии. Запуск обходится в среднем в 50-60 тысяч рублей однократно.

Вторая проблема, о которой нам говорили производственники, – это время. Внедрение сложной системы на производство – до двух месяцев. Причём при установке дорогостоящих систем информация берется напрямую с ЧПУ станка, а там куча различных протоколов обмена данными, так как на производстве всегда «зоопарк» из станков разных брендов. Все это удлиняет и усложняет процесс внедрения.

Мы придумали систему, которая внедряется за 1-3 дня. В сочетании с отсутствием капитальных затрат на внедрение получается продукт, который относительно легко «продать» руководству предприятия («Давайте протестируем Энкост Мониторинг? Чем предприятие рискует – 50 000 рублей?»).

В-третьих, надо было придумать, как фиксировать причины простоев. На КПД работы станка влияет множество факторов: как очевидных (находится ли сотрудник на рабочем месте, есть ли у него материалы-заготовки для работы, налажена ли их бесперебойная доставка), так и неочевидных. Контролировать датчиками все причины, по которым тормозит производство, невозможно.

Положим, руководство предприятия хочет разобраться, загружена ли определенная линия полностью или почему она недозагружена. Можно повесить в цехах камеры и посадить отдельных людей наблюдать за производственным процессом. Но ведь даже десяток видеокамер – это 240 часов видео ежесуточно! Кто в силах отсматривать и анализировать их? Мы ведь не роботы, никакой наблюдатель физически не может сохранять бдительность восемь часов в сутки, если просто сидит и смотрит на монотонный производственный процесс. К тому же такое наблюдение не всегда информативно. Вот, допустим, наблюдатель видит, что оператор станка остановил линию и ушел из цеха. Что это даёт для понимания ситуации? Почему оператор ушел: его срочно вызвало руководство? Живот прихватило? Станок сломался, и оператор отправился на поиски техника? Оператор вдруг переосмыслил свою жизнь и ушёл получать профессию лингвиста? Вопрос без ответа, если просто наблюдать за работой через монитор.

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

С учётом всего собранного массива информации мы стали дорабатывать свою систему и создавать тот Энкост Мониторинг, который сегодня отслеживает работу 700+ станков в 28 регионах России.

Что мы переосмыслили под запрос пользователей

Взяли смартфон на Android’е и перепрошили его под «киоск» – со смартфоном ничего нельзя сделать, кроме того, что ему велено делать создателями, то есть нами. А создатели велели постоянно держать открытым телеграм-канал и не гасить экран самостоятельно. Если станок останавливается, бот телеграм-канала выбрасывает на экран сообщение, предлагая выбрать причину простоя.

И рабочий обязательно сразу указывает одну из причин остановки: «Отсутствие заготовок», «Окончание смены» и т.д. Или собственный вариант, если причина нестандартная. Для коротких остановок оборудования до пяти минут причину можно не запрашивать (ну отходит человек по нужде или ещё чего), но статистика по таким остановкам всё равно собирается. Это просто настройка – клиент может не отслеживать причины коротких остановок, а может собирать причины даже минутных простоев.

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

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

Вообще, после установки телеграм-бота у нас появилось много новых возможностей, и мы их реализовали:

  1. Стали регистрировать операторов на смену.

  2. Настроили систему эскалации уведомлений: если станок уходит в простой, то через 10 минут получает начальник смены уведомление об этом. Ещё спустя 20 минут простоя уведомление идёт начальнику производства, ну и так далее.

  3. Через телеграм-бота сделали вызов на станок ремонтного персонала (+ регистрируется скорость реакции). В обычном случае сервисные службы, как правило, выполняют заявки в порядке их регистрации. Вполне возможно, техник будет заниматься второстепенным ремонтом, пока простаивает критически важное оборудование. Мы дали возможность распределять приоритеты сервисных заявок.

  4. Разработали чек-листы: например, что должен сделать оператор в конце смены.

  5. Внедрили блокирующие состояния: например, «Переналадка». Когда это состояние активно, показания «Паука» игнорируются: в процессе переналадки станок могут постоянно запускать и останавливать, но это не производственный процесс.

  6. Сделали системы отчётов, которые я уже упоминал выше: фиксируются причины и длительность простоев, собирается информация по отдельным линиям или станкам. Мы настроили доступ к отчётности через личный кабинет из любой точки мира: куда бы ни занесло руководство предприятия, его рука остаётся на пульсе происходящего. Отчёты о работе станков формируются в графиках или Excel.

 Отдельный блок сделали для описания работы сервисных служб.

Система у нас достаточно простая: например, мы отказались от идеи разрабатывать визуализацию, контролировать работу всех агрегатов и узлов. Это сложно и удорожает систему, а ведь супердетализированная статистика в обычном производственном процессе обычно не нужна. Для решения конкретных прикладных задач достаточно более скромного, но точечно направленного функционала. При этом во многих случаях при использовании Энкост Мониторинга можно отследить соблюдение техпроцесса, если производство привязано ко времени обработки деталей. Например, деталь должна обрабатываться час, но в отдельном случае станок её обрабатывал полтора часа – можно начинать разбираться, почему так получилось. Также Энкост Мониторинг не показывает сбоя в работе конкретного узла, но создает график работы каждого станка, собирает данные о времени и причинах остановки линий, детализирует причины простоев, собирает данные по сменам/операторам и рассылает уведомления о сбоях в работе и длительном простое оборудования. Можно мгновенно формировать отчетность за нужный период, отслеживать состояние станков в реалтайме.

Какие задачи мы научились решать

Мониторинг показал, что одна из самых распространённых причин простоев станков на предприятиях – «Отсутствие сырья». Когда это становится видно в отчётах, производственник понимает, что слабое место в цепочке – планирование материалов и складских запасов.

Или оказывается, что вашего оператора станка отвлекают от работы посторонними задачами: сходить на совещание, которое не касается его работы, помочь коллегам нести круглое и катить квадратное… Перестали отвлекать оператора – КПД станка вырос с 60% до 90%.

Ещё пример: на фанерном комбинате станки «прохлаждались» до 25% рабочего времени в ожидании ремонта/ сервисного обслуживания. В отчёте стало видно, что проблема – в коммуникации сервисной службы и цехов. Проблему устранили – и время реакции на заявку теперь составляет 5-7 минут вместо 60-75, как прежде.

Тот самый фанерный комбинат
Тот самый фанерный комбинат

Производственник сэкономил 3,5 млн руб. на покупке нового станка, когда увидел в отчётах, что уже существующие станки простаивают до 20% времени, потому что операторов привлекают к сторонним задачам. Проблему устранили, сейчас станки загружены 90% рабочего времени.

Как ни странно, объективный контроль сокращает конфликты на предприятиях со сложными технологическими цепочками. Вместо споров между отделами, что и где споткнулось/застряло/поломалось – сухие строчки в отчётах. И вопрос из сферы «Кто виноват?» закономерно переходит в сферу «Как мы можем быстро это исправить?».

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

Сейчас мы потихоньку развиваем систему. Поскольку она строилась поэтапно, под ней как-то сама собой выросла сервисная архитектура для мониторинга предприятий разных типов: от производства полуфабрикатов до деревообработки (у нас сейчас 70+ клиентов из разных отраслей).

В ответ на запрос клиентов-производственников мы сделали новое устройство, назвали его «Оса» – принцип такой же, как у «Паука», но расширен спектр используемых датчиков. Уже установили первых «Ос» с оптическими датчиками на подсчёт выпущенной продукции.

Про «Осу» и мониторинг, возможно, расскажу подробнее в другой раз, если будет интересно.

Что хочу сказать о коммуникациях и связках «Запрос – решение»

Энкост Мониторинг появился как альтернатива слишком дорогим для мелкого-среднего бизнеса системам просто потому, что мы сотрудничали с производственниками с 2013 года, имели с ними связь и в какой-то момент услышали запрос. А сколько перспективных, полезных, удачных, недорогих IT- и технических решений ещё только ждут своих героев, потому что сейчас нет внятной коммуникации между заинтересованными сторонами? Где-то сидят айтишники и технари, которые могли бы эффективно и недорого решить другие задачи других производственников, но не знают, что у производственников есть запрос. А производственники не думают о том, что могут поискать решения за пределами своих привычных способов действий и уже существующих на рынке чрезмерно дорогих продуктов.

И ещё. Я понимаю, что слово «санкции» можно предлагать как рвотное, но тем не менее: из-за санкций сейчас у отечественных производственников вообще сильно ограничен выбор IT-решений. Сложных систем остерегаются просто потому, что где-нибудь в их «начинке», возможно, болтаются подсанкционные ныне «потрошки», которые, в случае чего, невозможно будет заменить. И автоматически оказывается в выигрыше отечественная система, простая, как тапок, и не зависящая от поставки материалов из, скажем обтекаемо, проблемных стран. Нас это радует не только потому, что растёт популярность конкретно Энкост Мониторинга, в котором 100% комплектующих из НЕподсанкционных стран. А потому, что даёт отечественным технарям и айтишникам много возможностей для генерации совершенно новых интересных решений для отечественных же потребителей. Уверен, у айтишников и производственников огромный потенциал сотрудничества, который ещё только предстоит раскрыть. И наша синергия может вывести некоторые направления на качественно новый уровень.

Готов обсудить любые тезисы из вышеописанных в комментариях или подробнее рассказать про отдельные этапы разработки наших продуктов.

Комментарии (3)


  1. Simpre_falta_algo
    08.07.2023 11:22

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


  1. vbifkol
    08.07.2023 11:22

    Я правильно понимаю что мониторится только потребление энергии? А интерфейс - только таблицы и оповещения бота?


  1. mkrentovskiy
    08.07.2023 11:22

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