Простой оборудования сократился в 2 раза: как мы оцифровали парк из 165 единиц и выстроили учёт ремонта в реальном времени

Коротко о проекте

• Исходная ситуация: поломку станка до сервисной службы несли «вручную» – от рабочего до бригадира, от бригадира до сервисной службы в другое здание, до 50 минут на одно уведомление; реальных данных по простою у руководства не было.
• Что сделано: разработали сервис учёта оборудования, простоев и ремонта (плановый и аварийный) на платформе Битрикс24 – веб-версия для руководителей и мобильное приложение для рабочих и сервисной службы.
• Результат: срок простоя оборудования сократился в 2 раза, уведомление о поломке доходит до сервисной службы за секунды (сканирование QR-кода на станке), весь парк – 165 единиц оборудования – виден в одном рабочем окне.
• Побочный, но важный эффект: у руководства цеха и производства появилась онлайн-картина загрузки и простоев, точнее стал прогноз выполнения плана.

Контекст и задача

Проект для производственной компании в сфере деревообработки – сильный игрок рынка с присутствием в 35 регионах России (название не раскрывается по соглашению о неразглашении). В цехах – парк из 165 единиц оборудования: форматно-раскройные и сверлильные центры, рельефно-шлифовальные и упаковочные автоматы, осушители, стреппинг-машины и другая техника.

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

Задача

Бизнес-цель клиента формулировалась просто: быстрее выполнять ремонт оборудования и понимать реальную загрузку сервисной службы. Отсюда функциональные требования:

1. Оцифровать весь парк оборудования – единый справочник с характеристиками и ответственными.
2. Фиксировать простои и ремонты: аварийный и плановый, с датами начала, плана и окончания.
3. Сделать моментальное информирование сервисной службы о поломке – без походов к бригадиру.
4. Дать руководству аналитику: реальное время простоя по каждому станку, динамика, план-факт по срокам ремонта.

Ограничения проекта: работающее производство останавливать нельзя, решение должно быть понятно рабочим без длительного обучения, а доступ к данным – разграничен по ролям (рабочий, сервисная служба, руководитель). Исполнитель – команда Smart Бизнес.

Почему старый процесс не работал

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

Этап 1. Оцифровка парка и модель данных

1. Завели карточку на каждую единицу оборудования (наименование, фото, дата ввода в эксплуатацию, инвентарный номер, место – цех и участок, последнее ТО, наработка в часах, тип оборудования из настраиваемого справочника, ответственный). Пример карточки: «Осушитель рефрижераторный CRD-5.1 (5100 л/мин), инв. № 25, Цех 1».
2. Определили статусы жизненного цикла: «Работает», «Плановый ремонт», «Не работает», «Ожидание подтверждения ремонта» – и правила переходов между ними.
3. Разграничили типы простоев: аварийный и плановый, чтобы статистика по ним не смешивалась.

Этап 2. Мобильный сценарий вызова сервисной службы

1. Сформировали QR-код на каждую единицу оборудования и наклеили на станки. Рабочий сканирует код со своего смартфона – и сразу попадает в карточку станка.
2. По сканированию создаётся запись о поломке: рабочий указывает причину поломки из справочника и комментарий свободным текстом (например, «Разорвало вакуумный шланг»), либо помечает плановый ремонт. Сервисная служба получает данные сразу: какой станок, какой участок, кто инициатор.
3. В мобильном приложении появились разделы «Оборудование» (полный список с фильтрами «Все / Работает / Плановый ремонт / Ожидание подтверждения»), «Активные работы» (текущие задачи) и «История» (события и статусы). Когда ремонт закончен, сотрудник нажимает «Ремонт завершён» – станок возвращается в статус «В работе».

Этап 3. Журнал инцидентов и аналитика

1. Собрали журнал инцидентов: станок, цех, тип (аварийный или плановый), даты начала, плана и окончания, длительность простоя, причина, инициатор и ответственный за ремонт. План-факт по датам виден сразу, а срыв планового срока помечается меткой «Просрочен».
2. Сделали дашборд с ключевыми показателями за любой период: аварийный простой, плановый простой, число поломок, средний срок ремонта, срывы сроков. Ниже – графики «Динамика простоев по месяцам» и «Аварийный / плановый» с разбивкой по периодам.
3. Добавили фильтры: период (месяц, год, всё время), тип простоя, тип станка, цех или участок, поиск по конкретному станку. На каждый показатель – подсказка, что он означает.

Этап 4. Права, доступ и обучение

1. Настроили управление доступом: администратор раздаёт права на приложение прямо из мобильного – рабочие видят только нужный функционал, руководители – аналитику и историю.
2. На каждой странице разместили инструкции и подсказки: что означают кнопки, как пользоваться поиском и фильтрами, как сканировать QR-код. Это сняло вопрос «а что нажимать?» у рабочих на старте.

Как это работает сейчас

Сценарий поломки. Рабочий подходит к станку и сканирует QR-код со смартфона → создаётся запись о поломке с причиной и комментарием → сервисная служба видит инцидент в «Активных работах» с указанием станка, участка и инициатора → ремонт выполняется, сроки фиксируются в журнале → сотрудник нажимает «Ремонт завершён», станок получает статус «Работает», а событие навсегда остаётся в истории станка.

Сценарий планового ремонта. Ремонт ставится планово, с датой окончания; если срок срывается, запись получает метку «Просрочен» – руководитель видит это в тот же день, а не в конце месяца.

Что получил каждый участник:

• Рабочий: не нужно идти к бригадиру и ждать – одно сканирование, и вопрос запущен.
• Сервисная служба: понятный список текущих задач и самоконтроль – срок каждого ремонта на виду.
• Начальник цеха и руководитель производства: онлайн-картина по каждому станку и возможность пересчитать простой в рублях по реальным часам.
• Руководитель компании: история поломок по всему парку – по ней видно и качество оборудования (какие станки ломаются чаще), и скорость работы сервисной службы.

Результаты внедрения

Какие внешние факторы влияли на цифры: сезонность загрузки производства меняет объём поломок (в дашборде видно, как аварийный простой вырос с примерно 500 часов в июне до примерно 1670 часов в августе), поэтому сравнивать месяцы между собой напрямую нельзя – сокращение срока простоя оценивалось по длительности инцидентов, а не по суммарным часам. Цифра «в 2 раза» – оценка клиента по периоду эксплуатации, а не сплошной замер по всем станкам.

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

Что сработало и где есть ограничения

• Сработало: QR-код на самом станке как единственная точка входа. Порог входа для рабочего – одно действие, а время простоя фиксируется автоматически, без «помню – не помню».
• Сработало: план-факт по срокам ремонта с меткой «Просрочен». Прозрачность подтянула и самоконтроль сервисной службы – это заметная часть эффекта сокращения простоя.
• Не сработает без порядка в данных: если у оборудования нет ответственного, не заполнены тип и место, карточка превращается в пустышку. Оцифровка парка – обязательный первый шаг, а не формальность.
• Не сработает там, где часть поломок фиксируют устно или закрывают ремонт «задним числом»: в журнале наших клиентов такие записи видны сразу («Станок починили ещё вчера, забыл сделать запись»), и они искажают статистику.
• Ограничение применимости: сервис закрывает контур «оборудование – простой – ремонт». Учёт запчастей, склада и планирование ТО по наработке – отдельные контуры, они в этот проект не входили.

Типичные ошибки

• Не закрывают ремонт в системе вовремя – искажаются сроки простоев, и дашборд начинает врать. Нужен простой регламент: отремонтировал – нажал «Ремонт завершён».
• Не заполняют причину поломки – теряется возможность анализировать повторяемость и качество оборудования.
• Не разделяют аварийный и плановый ремонт – статистика смешивается, и выводы о загрузке сервиса становятся бесполезными.
• Раздают доступ к приложению без разбора – возрастает риск случайных правок в журнале.
• Ставят QR-коды «на глаз», без привязки к инвентарному номеру – через полгода никто не понимает, какой код к какому станку относится.

Частые вопросы