Реестр критичности активов: методика для ТОиР и запасов

Зачем нужен реестр критичности активов

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

Реестр критичности активов нужен, чтобы решения перестали зависеть от громкости проблемы. Без него часто побеждает тот, кто «срочно просит», а не тот, у кого риск выше. Итог - пожарные работы, постоянные переносы планов ТОиР, неожиданные простои и закупки «на всякий случай».

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

На критичность обычно опираются решения: какие работы ставить в план ТОиР первыми, где нужны регламентные проверки и более частый мониторинг, какие MRO-запасы держать на складе, как защищать бюджет (что нельзя «срезать» без роста риска), какие сроки реакции и восстановления задавать по заявкам.

Простой пример: два насоса стоят одинаково, но один питает пожаротушение, а второй - вспомогательный контур. Если это не отражено в реестре, команда может тратить время на «видимые» поломки и упускать тихие, но опасные риски.

Что считать активом и на каком уровне оценивать

Актив в реестре критичности - это все, что при отказе может остановить работу, создать риск для людей или привести к заметным затратам. Важно не ограничиваться станками и линиями. На практике часто «падает» не сама машина, а питание, сеть, охлаждение или ключевой ИТ-узел.

Обычно в реестр включают производственное оборудование и ключевые узлы (насосы, редукторы, частотники), ИТ и связь (серверы, СХД, коммутаторы, рабочие станции, критичное ПО как сервис), инженерную инфраструктуру (электроснабжение, ИБП, компрессоры, вентиляция, пожарка), а также элементы безопасности (ограждения, датчики, аварийная остановка).

Уровень детализации выбирают так, чтобы по нему можно было принимать решения по ТОиР и запасам. Если вы планируете работы «по машине», оценка на уровне каждого компонента даст много шума. Если запасы и ремонты завязаны на узлы, оценка только на уровне линии будет слишком грубой.

Практическое правило: начните с уровня «линия или машина», а компоненты добавляйте только там, где они реально отличаются по последствиям и по стратегии запасов. Например, для серверной или дата-центра иногда полезнее оценивать не «сервер в целом», а связку «стойка + питание/ИБП + коммутатор», потому что именно она определяет простой. Если у вас есть локальная инфраструктура (серверы и рабочие места), фиксируйте активы так, чтобы было ясно, где стоит устройство и кто отвечает за его доступность.

Минимальный набор полей в реестре должен отвечать на четыре вопроса: «что это», «где это», «зачем это» и «кто владелец». Обычно достаточно:

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

Отдельно разберите «серые зоны». Арендованное, подрядное и общее инженерное часто выпадает из учета, хотя влияет сильнее всего. В реестре отмечайте, кто реально устраняет аварии, какие есть SLA/договоренности и есть ли доступ к запасам и документации. Тогда в момент простоя не придется спорить - останется действовать по заранее понятным правилам.

Три оси оценки: безопасность, выпуск, финансы

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

Безопасность (S) - последствия, которые нельзя «отработать позже»: травмы и риск для жизни, пожар и взрыв, утечки и экология, соответствие обязательным требованиям и проверкам. Даже редкий отказ может быть высоким по этой оси, если цена ошибки неприемлема.

Выпуск/производство (P) - как отказ бьет по работе: простой линии или участка, падение мощности, рост брака, нарушение сроков поставок. Смотрите не только на остановку, но и на скрытые потери, когда оборудование «как бы работает», но качество плавает, скорость падает, а переналадка занимает часы.

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

Почему важно заранее договориться о смысле критериев

Чтобы оценки были сравнимы, закрепите короткие определения до первого обсуждения конкретных активов:

• что считать инцидентом по безопасности (только травмы или также near-miss, экология)
• как мерить влияние на выпуск (минуты простоя, процент брака, влияние на сроки)
• какие деньги включать в финансы (только ремонт или также штрафы и недополученную выручку)
• за какой период смотреть эффект (смена, неделя, месяц)

Пример: отказ датчика на печи может быть «средним» по выпуску (линия остановится на 30 минут), но «высоким» по безопасности, если без него растет риск перегрева и пожара. Такой актив должен подниматься в приоритете даже при небольших финансовых потерях.

Шкалы 1-3: как договориться о понятных уровнях

Шкала 1-3 работает, когда уровни описаны простыми словами и опираются на факты: что именно считаем инцидентом, какой простой действительно срывает план, какие потери считаем значимыми. Обычно достаточно одной рабочей встречи (ТОиР, производство, HSE, финансы), чтобы утвердить формулировки как общий «словарь».

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

Ниже пример уровней 1-3 по трем осям. Пороговые значения подставьте свои, но оставьте логику и измеримость.

Чтобы команда действительно «сверила калибр», добавьте по одному реальному примеру актива на каждый уровень (S1, S2, S3 и так далее) и зафиксируйте в реестре. Если по активу постоянно спорят, обычно проблема не в активе, а в размытых порогах или в том, что в потери не включили важную статью (например, штрафы, брак, срочные закупки).

Пошаговая методика присвоения критичности

Реестр работает лучше всего, когда оценка идет коротким повторяемым циклом, а не попыткой «оценить все разом».

1. Соберите список активов и минимальные данные по каждому: назначение, режим работы (24/7, сменный, сезонный), наличие резерва или обходного пути, и что вы считаете «остановкой» (полная, частичная, падение качества). На этом шаге часто всплывают дубли и разные названия одного и того же узла.

2. Опишите реальные сценарии отказа - не «может сломаться все», а 2-4 события, которые действительно случались или логично ожидаемы: перегрев, утечка, отказ датчика, сбой питания, заклинивание. Если сценарий нельзя объяснить одним предложением и привязать к признаку (вибрация, температура, тревога), он слишком размытый.

3. Оцените последствия по трем осям S/P/F по согласованным шкалам 1-3. Лучше оценивать по каждому сценарию и брать наихудший разумный вариант. Пример: отказ насоса охлаждения может быть P=3 (останов линии), S=2 (риск ожога при ручном обходе), F=2 (ремонт и простой).

4. Назначьте итоговый класс критичности по простому правилу (например, максимум из S/P/F или суммарный балл) и обязательно запишите обоснование: что именно остановится, на сколько, какие барьеры есть (резерв, защита, обход).

5. Согласуйте оценки межфункционально (производство, ОТиПБ, финансы, ТОиР). Сразу определите владельца записи и порядок изменения класса, чтобы через месяц методика не превратилась в «каждый ставит как хочет».

Как считать итоговую критичность: простые правила

Итоговая критичность нужна не для красоты в таблице, а чтобы быстро решать, что делать первым и что нельзя откладывать. В реестре лучше иметь одно понятное правило расчета, одинаково понятное производству, ТОиР и ОТиПБ.

Два рабочих способа

Вариант 1: максимум из трех оценок (S, P, F). Логика прозрачна: если хотя бы по одной оси последствия высокие, актив не может считаться «средним».

Вариант 2: взвешенная сумма. Подходит, когда у разных площадок действительно разные приоритеты, и это влияет на решения.

Чтобы правило не «ломалось» в жизни, обычно хватает таких договоренностей:

• Стоп-фактор: если S=3, итоговая критичность всегда 3, независимо от P и F.
• По умолчанию: если стоп-фактор не сработал, итог = max(P, F).
• Веса используйте только при необходимости и фиксируйте их официально.
• Если итог по формуле 2,4 и выше, округляйте до 3, чтобы не спорить из-за десятых.

Пример. Насос: S=2, P=3, F=1. По правилу max итог = 3. Другой узел: S=1, P=2, F=3. Итог тоже 3, потому что финансовый эффект высокий.

Когда и как вводить веса

Если веса все же нужны, закрепите их приказом или регламентом, а не «по договоренности в чате». Например: S 50%, P 30%, F 20%. Расчет должен считаться в Excel без формул на полстраницы и объясняться одной фразой на планерке.

Пример матрицы критичности 3x3 (вероятность и последствия)

Матрица 3x3 помогает быстро договориться о приоритете: по одной оси вероятность отказа, по другой - последствия. Важно заранее записать, что именно вы называете «вероятностью» и откуда берете данные: частота отказов за 12-24 месяца, наработка до отказа, результаты осмотров, условия эксплуатации. Если данных мало - используйте экспертную оценку, но с пометкой «допущение».

Последствия можно считать двумя способами:

• проще: взять максимум из S/P/F
• точнее: вести три матрицы (S, P, F) и объединять по правилу «красный, если хотя бы по одной оси красный»

Пример матрицы (вероятность x последствия):

Зоны обычно читаются так:

• Зеленая: плановые работы по регламенту, без «пожаров».
• Желтая: усиленный контроль, уточнение периодичности, точечные доработки.
• Красная: приоритет в ТОиР, диагностике и устранении причин, повышенное внимание к запасам.

Небольшой пример: у насоса вероятность «средняя» (2-3 отказа в год), последствия «высокие» из-за риска травмы и остановки линии. Он попадает в красную зону, даже если финансовый ущерб сам по себе умеренный. Если позже поставили защиту и обучили персонал, последствия по безопасности могут снизиться, и зона изменится, но только после фиксации причин и даты пересмотра.

Как использовать критичность в планах ТОиР

Критичность нужна, чтобы по-разному обслуживать разное оборудование. Для высококритичных активов вы делаете больше профилактики и проверок, для низкокритичных - больше допускаете работу по факту и объединяете задачи в пакеты.

Частота ППР и глубина осмотров

Логика простая: чем выше последствия отказа, тем раньше вы хотите заметить деградацию.

• Класс A (высокая критичность): чаще ППР, обязательные функциональные тесты, контрольные замеры, разбор причин повторных отказов.
• Класс B (средняя): базовые регламенты, выборочные проверки, акцент на типовые слабые места.
• Класс C (низкая): минимально достаточные осмотры, больше работы по состоянию, допускается объединение с другими остановами.

Например, один и тот же тип насоса на линии охлаждения может быть классом A, если без него останавливается выпуск, и классом C, если рядом есть резерв и простой не влияет на безопасность.

Очередь работ и SLA: реактивные и плановые

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

• A: аварийные заявки всегда выше плановых, но плановые задачи по A не переносятся без решения ответственного.
• B: аварийные выше, плановые переносятся ограниченно (с понятным сроком и причиной).
• C: допускается перенос и укрупнение работ, если риск не растет.

Для SLA удобно задавать два времени: реакция (когда специалист начал) и восстановление (когда актив вернули в работу). Для класса A они самые жесткие, для C - мягче.

Что делать с отложенными работами

Перенос допустим только если вы можете объяснить, почему риск не стал выше. Нельзя откладывать работы при признаках прогрессирующей неисправности, повторяющихся отказах, замечаниях по безопасности или когда задача закрывает критический барьер (защита, блокировка, аварийная сигнализация). Для класса A перенос чаще всего возможен только с компенсирующими мерами: временный контроль, снижение нагрузки, резервирование или ускоренная поставка запчастей.

Как связать критичность с запасами и MRO-закупками

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

Практичный подход - разделить номенклатуру по зонам (красная, желтая, зеленая) и привязать к правилам пополнения. Учитывайте не только цену детали, но и срок поставки, сложность замены и последствия простоя.

• Красная зона: страховой запас обязателен (min-max), точка заказа должна перекрывать срок поставки с запасом.
• Желтая зона: ограниченный запас, уровни пересматриваются чаще.
• Зеленая зона: заказ под потребность, на складе только расходники с быстрым оборотом.

Дальше настройте параметры запаса одной логикой: min (минимум на срок поставки), reorder point (точка заказа), max (верхняя граница, чтобы не замораживать деньги). Если поставка долгая или нестабильная, повышайте min даже для недорогих позиций.

Отдельно договоритесь о взаимозаменяемости и «каннибализации» (снятии детали с другого оборудования). Это работает только при утвержденном списке совместимых позиций и понятном правиле возврата: что и когда обязаны восстановить на доноре. В ИТ-инфраструктуре, например, иногда допустима временная перестановка блока питания с менее критичной стойки, но с обязательным заказом замены и ограничением по сроку.

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

Короткий пример: как реестр меняет приоритеты работ

Представьте линию, где есть одно узкое место и нет резерва. Если участок встал, выпуск останавливается полностью. До реестра заявки часто идут по принципу «кто громче», а план ТОиР строится вокруг привычных работ, а не риска.

Возьмем три актива на участке: насос (перекачка/охлаждение), шкаф управления (ПЛК, питание, автоматика) и промышленный ПК оператора (HMI/SCADA). Оценим по трем осям: безопасность (S), выпуск (P) и финансы (F) по шкале 1-3.

• Насос: S=2 (есть риск перегрева/утечки, но есть защиты), P=3 (остановка узкого места), F=2 (ремонт средний, потери есть)
• Шкаф управления: S=3 (риск опасного отказа, блокировки, неправильных команд), P=3 (остановка 100%), F=3 (дорогой ремонт и простой)
• Промышленный ПК: S=1 (на безопасность влияет косвенно), P=2 (можно перейти на ручной режим/резервный терминал, но медленнее), F=1 (замена относительно недорогая)

Теперь добавим матрицу критичности 3x3 «вероятность x последствия». Последствия можно брать как максимум из S/P/F (или отдельным правилом: если S=3, то последствия минимум 3).

Пример матрицы 3x3

По горизонтали последствия (1-3), по вертикали вероятность (1-3).

• Зеленая: (1,1), (1,2), (2,1)
• Желтая: (1,3), (2,2), (3,1)
• Красная: (2,3), (3,2), (3,3)

Допустим, по истории отказов и состоянию:

• Насос: вероятность 2, последствия 3 -> красная зона
• Шкаф управления: вероятность 2, последствия 3 -> красная зона
• Промышленный ПК: вероятность 3, последствия 2 -> желтая зона

Что меняется на практике. Для шкафа управления и насоса план ТОиР становится жестче: диагностика по состоянию, тесты защит, регламент на критичные узлы, контроль поставщиков и сроков ремонта. По запасам появляются обязательные позиции (например, частотник/блок питания/модули ввода-вывода, комплект уплотнений/подшипники) с целевым временем восстановления.

В заявках приоритет меняется сразу: даже «мелкие» симптомы по красным активам (скачки температуры, просадки питания, ошибки модулей) поднимаются выше косметики и удобства на HMI. ПК тоже важен, но чаще решается стандартом: образ диска, горячая замена, минимум уникальных моделей.

Типовые ошибки и ловушки при внедрении

Самая частая путаница: критичность считают как «насколько сейчас плохо». Если насос шумит или станок часто останавливается, это про состояние и срочность ремонта. Критичность отвечает на другое: что будет, если актив откажет в самый неудобный момент. Бывает, что «сломано», но последствия ограничены. И наоборот: «работает», но отказ приведет к травме или остановке линии.

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

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

Что чаще всего ломает методику

• Один отдел ставит оценки в одиночку, без производства, ОТиПБ, качества и снабжения.
• Решения принимают «по памяти», без фактов: длительность простоев, частота отказов, наличие обходных схем.
• Редкие, но тяжелые сценарии по безопасности занижают, потому что «у нас такого не было».
• Реестр делают один раз и убирают в папку, без обновления после изменений в технологии.

И еще одна проблема - реестр не связан с действиями. Если критичность не влияет на приоритизацию ТОиР, регламенты, уровни MRO-запасов и сроки поставки, люди быстро перестают тратить время на аккуратные оценки.

Чеклист и правила пересмотра реестра

Реестр критичности активов нужно поддерживать как живой документ.

Проверьте базовые вещи:

• Назначен владелец реестра (роль, а не фамилия) и понятен порядок внесения изменений.
• Шкалы и правила оценки зафиксированы и одинаковы для всех участков.
• У каждой позиции есть дата последнего пересмотра и источник данных (инциденты, простои, затраты).
• Красная зона не остается «красной без действий»: есть план работ и срок реакции.
• Желтая зона не забыта: есть мониторинг и понятные триггеры, когда актив должен стать красным.

Дальше посмотрите на действия по зонам. Для красных активов должно быть ясно, что именно будет сделано в ТОиР, какой минимум MRO-запаса держим, кто отвечает и как быстро реагируем при отказе. Для желтых важно не перегружать план, но держать контроль состояния (обходы, вибрация, температура, наработка) и заранее описать, при каких симптомах включается эскалация.

Правила пересмотра лучше привязать к событиям:

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

Практичный следующий шаг - пилот на одном участке (50-150 активов): согласовать шкалы, провести оценку и привязать результат к плану ТОиР и нормам запасов, а затем перенести реестр в систему учета активов. Если для этого нужна ИТ-инфраструктура (серверы, рабочие места) и интеграция систем, это можно закрывать вместе с системным интегратором. Например, GSE.kz как производитель и интегратор в Казахстане поставляет рабочие станции и серверы, а также помогает с внедрением и поддержкой инфраструктуры для таких задач.