Показатели ТОиР: что считать главному инженеру
MTTR, наработка на отказ, доля плановых работ и соблюдение графика: что показывает каждый показатель, как его считать и чем он способен ввести в заблуждение.
Зачем вообще считать
Главного инженера оценивают по тому, стоит оборудование или работает. Но «работает» — это не показатель, а ощущение, и в разговоре с руководством оно проигрывает любой цифре. Показатели нужны ровно для двух вещей: обосновать ремонтный бюджет и увидеть, где парк отказывает систематически, а где разово.
Считать всё подряд не нужно. Пяти показателей достаточно для любого предприятия, и лучше честно вести три, чем формально заполнять десять.
Пять показателей
| Показатель | Что показывает | Как считается |
|---|---|---|
| Доля плановых работ | Управляете вы обслуживанием или тушите пожары | Плановые работы ÷ все выполненные работы за период |
| Среднее время восстановления (MTTR) | Как быстро служба возвращает оборудование в строй | Суммарное время ремонтов ÷ количество ремонтов |
| Наработка на отказ | Насколько надёжна конкретная единица | Время работы ÷ количество отказов за период |
| Соблюдение графика | Выполняется ли регламент или он существует на бумаге | Работы, сделанные в срок ÷ запланированные на период |
| Коэффициент готовности | Какую долю времени парк реально доступен | Время работоспособного состояния ÷ общее время |
Первые два считаются почти автоматически, если заявки заводятся и закрываются в системе. Наработка на отказ требует учёта времени работы — по счётчику моточасов или хотя бы по сменам. Коэффициент готовности сложнее всех и на старте не обязателен.
Главный из них — доля плановых работ
Если брать один показатель, берите этот. Он отвечает на вопрос, которым и отличается управляемая служба от аварийной: работы происходят потому, что вы их запланировали, или потому что что-то сломалось.
Ориентир зависит от отрасли и возраста парка, но направление важнее абсолютной цифры. Служба, у которой доля плановых работ растёт от квартала к кварталу, снижает и простои, и стоимость ремонтов — просто потому, что плановая замена подшипника дешевле аварийной замены вала. Служба, у которой она падает, скоро придёт за внеплановым бюджетом.
Побочный эффект: этот показатель невозможно улучшить, не наведя порядок в графиках. Поэтому он же хорошо работает как аргумент для внедрения — его динамику видно уже через два-три месяца.
Чем эти цифры врут
Любой показатель можно улучшить, не улучшая ничего по существу. Знать эти способы полезно — и чтобы не обманывать себя, и чтобы понимать чужие отчёты.
MTTR улучшается, если не регистрировать мелкие работы. Подкрутили за десять минут и не завели заявку — среднее время растёт только за счёт крупных ремонтов. Обратная сторона: чем полнее регистрация, тем «хуже» выглядит показатель на старте. Это нормально, и падение MTTR в первые месяцы внедрения обычно означает не ускорение, а неполный учёт.
Доля плановых растёт, если аварийные работы задним числом оформлять плановыми. Лечится тем, что тип работы фиксируется в момент создания заявки и потом не редактируется.
Коэффициент готовности поднимается исключением «неучтённого» оборудования. Если в расчёт попадает не весь парк, цифра красивая, а решения по ней ошибочные.
Соблюдение графика достигается разреженным графиком. Поставьте осмотр раз в год вместо раза в месяц — и выполнение будет стопроцентным. Поэтому показатель имеет смысл только рядом с количеством отказов.
С чего начать, если не считается ничего
Не с показателей. Сначала должен появиться сам факт регистрации: каждая работа заводится заявкой, у неё есть тип, объект, исполнитель и дата закрытия. Пока это не привычка, любые расчёты будут описывать не парк, а дисциплину заполнения.
Практический порядок такой. Первый месяц — просто регистрируем всё, ничего не считая. Второй — смотрим на соотношение плановых и внеплановых, оно почти всегда оказывается хуже ожидаемого. Третий — добавляем MTTR и разбираем повторяющиеся отказы. Наработку на отказ и коэффициент готовности подключаем позже, когда данные накопились и им можно верить.
Что для этого нужно в учёте
Требования к системе минимальны, и это хорошая новость: почти всё считается из данных, которые и так появляются при нормальной работе.
- Заявка с типом работы, объектом, исполнителем и датами открытия и закрытия.
- Каждая единица оборудования как отдельный объект, а не строка в перечне: без этого нельзя посчитать наработку на отказ по конкретной машине.
- Планы обслуживания с периодичностью, чтобы система сама показывала просроченное.
- История работ по каждой единице — она же журнал технического обслуживания.
Как это выглядит на практике — заявки, планы ТО, пройденные чек-листы и сводка по работам — показано на странице автоматизации ТОиР, а сами экраны системы — в разделе как выглядит EAMForge. Про построение самих графиков есть отдельный разбор — планово-предупредительный ремонт.