ТОиР без бумаги: как не терять заявки на ремонт

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

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

Что именно теряется

Прежде чем что-то автоматизировать, полезно назвать потери своими именами. Их четыре, и все они об одном: событие произошло, а следа не осталось.

01ЗаявкиСказали мастеру в коридоре — он забыл. Написали в общий чат — сообщение утонуло за час.

02Время реакцииСколько прошло от поломки до прихода ремонтника, не знает никто: момент обращения нигде не зафиксирован.

03История по единице оборудованияЧто делали с этим станком за три года, помнит слесарь, который на нем работал. Приблизительно.

04ЗапчастиДеталь либо лежала на складе, но о ней не знали, либо не лежала — и заказывать начали в день поломки.

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

Шаг 1. Реестр оборудования

Основа всего — список единиц оборудования с идентификатором, местом установки, паспортными данными и ответственным. Без него заявки не к чему привязать, и вся история рассыпается.

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

Шаг 2. Маршрут заявки

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

1ПоданаОператор сканирует метку, описывает проблему, отмечает, встало ли производство

2ПринятаДиспетчер видит заявку в очереди, уточняет детали, если нужно

3Назначен исполнительВручную или по правилу: тип оборудования, участок, смена

4В работеС этого момента считается время ремонта, а не ожидания

5ВыполненаИсполнитель фиксирует, что сделал и какие запчасти израсходовал

6Принята заказчикомПодтверждает тот, кто подавал, — не тот, кто чинил

На этом шаге принимаются решения, которые потом дорого менять:

• кто может подавать заявку — только мастер участка или любой оператор;
• что обязательно указать при подаче: оборудование, описание, признак остановки производства;
• кто распределяет — диспетчер, руководитель службы или система по правилу;
• какие сроки реакции для аварийной заявки и для плановой;
• кто подтверждает выполнение — важно, чтобы это был не тот же человек, что чинил.

Приоритеты стоит сделать простыми: два-три уровня, у каждого свой срок.Шкала из семи градаций выглядит солидно, а на практике все ставят высший приоритет.

Шаг 3. Заявки подаются с телефона

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

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

Шаг 4. Регламентные работы по графику

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

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

Шаг 5. Запчасти и связь со снабжением

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

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

Что считать после запуска

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

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

Честно про сложности

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

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

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

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