Как обосновать ИТ-бюджет через FMEA и RCM — методологию надёжности, которой на предприятии уже доверяют
Вопрос из комментариев: а как считать?
После прошлой статьи о том, как защищать ИТ-бюджет через язык бизнес-рисков, в комментариях и в личке повторился один и тот же вопрос — в разных формулировках, но по сути один: «Согласен. А как посчитать?»
С тезисом «говорите с бизнесом на языке рисков и денег» почти никто не спорил. Спотыкаются на следующем шаге: откуда взять цифру потерь, чем доказать, что отказ вообще вероятен, и в каком виде принести это на комитет, чтобы не выглядело придуманным накануне вечером. Ответить в комментариях одним абзацем не вышло — ответ оказался размером со статью. Вот он.
Короткий вариант: считать заново ничего не нужно. Методика уже лежит на вашем предприятии, ей каждый день пользуется технологический блок, и комитет ей доверяет. Это FMEA и RCM — анализ видов и последствий отказов и обслуживание, ориентированное на надёжность. Их просто никто не наводил на ИТ-активы.
Почему у механика цифра есть, а у вас нет
Разница видна на одном совещании. Главный механик говорит: «Износ насоса — 70%, остановка возможна через три месяца». Дальше разворачивает последствия: встанет линия, выпуск продукции упадёт на 30%, это убытки на снижении производительности плюс повышенный износ смежного оборудования. Ему согласуют деньги — за три минуты.
ИТ в ответ оперирует другим: устарела СХД, отказоустойчивость на пределе, нужна вторая площадка и резервирование. Мы показываем графики нагрузки и предупреждения мониторинга — и слышим: «Работает же. Вернёмся к этому в следующем квартале».
Дело не в том, что механик красноречивее. У него за спиной документ. Ни 70%, ни 30% он не придумал на совещании — он взял их из анализа отказов, который на предприятии ведётся регламентно, по стандарту, с прошлого года. Цифра пришла на комитет из документа, а не из головы выступающего. У ИТ такого документа обычно нет — поэтому любая наша цифра звучит как оценка на глаз, даже когда она верная.
Раньше на это можно было махнуть рукой: отказ насоса останавливает выработку, отказ ИТ останавливает администрацию — расчёт зарплаты, отчётность, бухгалтерию. Весомость разная, и ИТ закономерно проигрывало. Но это перестало быть правдой в тот момент, когда на предприятиях появились озёра данных и лейкхаусы, агрегирующие телеметрию и показания оборудования, а на них — витрины для производства и предиктивная аналитика ремонтов. Этот контур живёт целиком в ИТ. Его отказ — уже не «встала бухгалтерия», а остановка того, что питает производственные решения данными. Считать его последствия можно ровно так же, как последствия отказа насоса.
Дальше в статье — как это делается по шагам: как описать ИТ-систему как актив, как разложить её отказы по FMEA, как классифицировать последствия, чтобы они превратились в рубли, и в какие документы всё это положить, чтобы комитету было тяжело отклонить.
Сдвиг рамки: ИТ — это актив
Первый шаг — перестать защищать железо и начать защищать актив.
Разница тут не косметическая. Железо описывается голыми характеристиками: терабайты, год выпуска, окончание срока поддержки производителя. Актив описывается функцией, которую оборудование выполняет для предприятия, и тем, что случится, если эта функция пропадёт или начнёт сбоить. Механик защищает насос не как набор деталей, а как функцию: перекачивать столько-то кубов в час; без неё встаёт производство и копятся простои с финансовыми потерями.
Ровно так же нужно смотреть и на СХД, кластер виртуализации, канал связи или озеро данных. Что это за оборудование, какую функцию оно сопровождает и что происходит с предприятием, когда функция теряется? Здесь работает не только логика — здесь уже появляется ряд стандартов. Управление активами описано серией ISO 55000, в России это ГОСТ Р 55.0.01. И этот стандарт прямо относит к управляемым активам не только физическое оборудование, но и информационные активы — наравне с насосами и трансформаторами. То есть на уровне методологии сервер и насос уже лежат в одном реестре активов. Требования к самой системе управления активами задаёт ISO 55001, в России это ГОСТ Р 55.0.02.
А согласование нефинансовой ценности актива с деньгами происходит в ISO 55010, в России это ГОСТ Р 55.0.06. Последнее особенно важно: именно там методология разрешает переводить надёжность и доступность в рубли, которые понимают финансисты, — и вы уже говорите с ними на языке денег.
Что это меняет на практике? Как только ИТ-система заходит на обсуждение не как «ИТ-заявка», а как актив в общей системе управления, она проходит через ту же логику принятия решений, что и производственное оборудование: критичность, вероятность отказа, последствия, стоимость мероприятия против стоимости аварии. Вы перестаёте быть отдельным просителем со своим непонятным языком — вы встаёте в один ряд с технологическим блоком. К этому ряду у комитета доверие уже выстроено, особенно если у вас сильный руководитель, который разбирается в технологии: он понимает язык, на котором вы начинаете говорить.
Но есть одна большая проблема. Если вы хотите защитить актив именно так, его нужно правильно описать: задать функцию, определить, что считается отказом этой функции, и разложить, из-за чего этот отказ наступает. Это и есть вход в FMEA и RCM.
Ядро методики: FMEA и RCM для ИТ
RCM (обслуживание, ориентированное на надёжность) — это не про «чаще обслуживать». Это способ ответить на семь вопросов про каждый актив. В международном контуре они закреплены в SAE JA1011, в российском — в ГОСТ Р 27.606. По сути это анкета:
1. Какие функции у актива и с какими показателями он должен работать?
2. Как он может перестать выполнять функцию (функциональные отказы)?
3. Из‑за чего наступает каждый отказ (виды отказов)?
4. Что происходит, когда отказ случается (последствия)?
5. Чем эти последствия грозят (значимость)?
6. Что можно сделать заранее, чтобы отказ предупредить?
7. Что делать, если подходящей задачи нет?
Первые четыре вопроса — это и есть FMEA, анализ видов и последствий отказов (ГОСТ Р 27.303, международный аналог IEC 60812), а с пятым, оценкой значимости, он превращается в FMECA — то же самое плюс критичность. Это инструмент, которым технологический блок пользуется каждый день. Мы просто наводим его на ИТ-актив.
Возьмём конкретный пример — то самое озеро данных, которое питает предиктивную аналитику ремонтов.
Функция. Собирать телеметрию с оборудования и отдавать производству витрины данных с заданной свежестью и доступностью — скажем, обновление раз в 15 минут при доступности 99,5%. Это не «хранить данные», это «вовремя давать производству картину состояния оборудования».
Функциональный отказ. Витрина не обновляется дольше 30 минут (двух циклов обновления) или недоступна. Модель предиктивной аналитики перестаёт видеть текущее состояние.
Виды отказов: отказ узла хранения; переполнение хранилища; обрыв канала приёма телеметрии; сбой ETL-конвейера; просроченный сертификат на интеграции. Каждый — отдельная строка, как отдельный вид износа у насоса.
Последствия. Предиктивная модель слепнет. Ремонты возвращаются к календарному графику, растёт доля внеплановых остановок оборудования в цеху, повышается аварийность. То есть отказ ИТ-актива напрямую бьёт по выработке — ровно так же, как остановка насоса.
И вот здесь ключевой ход всей методики — классификация последствий. RCM делит их на четыре категории: скрытые; влияющие на безопасность и экологию; эксплуатационные; неэксплуатационные. И это деление решает всё. Неэксплуатационные последствия сводятся к стоимости ремонта самого актива. Эксплуатационные — это потерянная выработка, сорванные сроки, штрафы. Именно к эксплуатационным относится простой ИТ-контура, который питает производство данными. И считается он не в «часах недоступности», а в рублях недовыпущенной продукции.
Вот этот перевод и меняет разговор на комитете. Вы больше не говорите «СХД устарела, доступность на пределе». Вы говорите: «Вид отказа — переполнение хранилища телеметрии. Последствие — эксплуатационное: предиктивная аналитика встаёт, ремонты уходят в аварийные, оценка потерь — порядка 1,5 млн ₽ за сутки простоя. Мероприятие, которое это снимает, стоит около 3 млн ₽ единовременно — то есть окупается за два дня предотвращённого простоя». Это тот же лист, что лежал перед механиком, — только про ИТ-актив.
Осталось показать два приёма RCM, которые для ИТ работают особенно точно, и то, как всё это привязать к документам.
Два приёма RCM, которые бьют по ИТ точно
В методологии RCM есть два понятия, которые как будто придуманы под ИТ, хотя родились в мире насосов и подшипников. Если их освоить, половина ваших бюджетных аргументов перестраивается сама собой.
Приём первый: P-F интервал — это ваш мониторинг.
В RCM отказ редко случается мгновенно. Сначала появляется потенциальный отказ — момент, когда неисправность уже можно обнаружить, но функция ещё выполняется. Потом наступает функциональный отказ — когда актив реально встал. Отрезок между этими двумя точками называется P-F интервалом. Вся идея обслуживания по состоянию в том, чтобы проверять актив чаще, чем длится этот интервал: тогда вы ловите проблему в окне и успеваете вмешаться до аварии.
В ИТ этот интервал буквально виден в мониторинге. Предупреждение SMART о деградации диска, рост заполнения хранилища к пределу, приближение срока действия сертификата, деградация батарей ИБП — это всё точки P, потенциальные отказы. И у каждого есть своё окно до точки F. Срок сертификата — вообще идеальный пример: дата функционального отказа известна заранее, а окно на реакцию — это дни и недели до неё.
Что это даёт на комитете. Ваш мониторинг перестаёт быть «графиками, которые айтишники любят показывать». Он становится системой обслуживания по состоянию — ровно тем, за что технологический блок платит на вибродиагностику и тепловизоры. А запрос на резервный узел или запас по времени замены превращается из «хотим на всякий случай» в «P-F интервал по этому виду отказа — около 7 дней от первого предупреждения до отказа, а поставка нового контроллера занимает 6 недель; за это окно мы физически не успеваем без резерва».
Приём второй: скрытый отказ — это ваш непроверенный бэкап.
Скрытый отказ — это отказ, который никто не замечает в обычной работе, потому что отказала защита, а не то, что она защищает. Резервный насос, который включается раз в год, может быть давно неисправен — и вы узнаете об этом ровно в тот момент, когда встанет основной. RCM для таких случаев предписывает отдельный тип задачи — поиск скрытых отказов: регулярную проверку того, что защита реально работает.
В ИТ скрытых отказов полно, и самый дорогой — бэкап, который никто ни разу не восстанавливал. Резервная копия, которую не проверяли восстановлением, — это не защита, это предположение о защите. Туда же: резервный узел кластера, который ни разу не принимал нагрузку; ИБП, который не тестировали под реальной просадкой; вторая площадка, на которую ни разу не переключались. Всё это — защита в состоянии скрытого отказа, пока не доказано обратное.
Что из этого вытекает для комитета. Регламент тест-восстановлений и учебных переключений — это не «перестраховка ИТ», а обязательная в методологии задача поиска скрытых отказов. И бюджет на стенд для таких проверок, на людей и на время обосновывается тем же языком, что и проверка резервного насоса: без неё вы не знаете, есть ли у вас защита вообще.
У обоих приёмов есть ещё один эффект: они превращают ваши мероприятия в задачи обслуживания с интервалами — а значит, их можно вписать в те же документы, что и обслуживание производственного оборудования.
Как привязать всё это к документам
Главная ошибка на этом шаге — завести отдельную «ИТ-документацию» и носить её на комитет как что-то своё. Тогда вы снова в позиции отдельного просителя. Правильный ход обратный: встроить ИТ в те документы, которые на предприятии уже ведутся по производственному оборудованию. Комитет должен увидеть ИТ-актив в привычном формате, а не в новом.
На практике это четыре документа.
Реестр активов (паспорт актива). ИТ-системы заводятся в тот же реестр, что насосы и трансформаторы, с той же структурой паспорта: критичность, функция, показатели работы, история отказов. Требование вести такой реестр идёт из ISO 55001 (ГОСТ Р 55.0.02), а как кодировать и классифицировать данные об отказах — из ISO 14224 (ГОСТ Р 70841). Это фундамент: пока ИТ-актива нет в реестре, для системы управления активами его как будто не существует.
FMEA-лист на ИТ-актив. Тот самый анализ видов и последствий отказов, оформленный по ГОСТ Р 27.303: функция, функциональные отказы, виды отказов, последствия с классификацией, оценка значимости. Это и есть ваш главный документ на комитете — прямой аналог FMEA-листа механика.
Регламент (карта) обслуживания с интервалами. Сюда ложатся задачи по состоянию и поиску скрытых отказов: проверки с интервалом короче P-F, тест-восстановления, учебные переключения, тесты ИБП. Термины и виды работ берутся из ГОСТ 18322, а логика самого процесса обслуживания — из EN 17007. Документ отвечает на вопрос «что, как часто и зачем мы делаем с активом», в одном формате с производственным ТО.
KPI обслуживания. Показатели, по которым видно, что система работает: доступность, наработка на отказ, доля планового обслуживания против аварийного. Набор таких метрик описан в EN 15341. Это то, что вы приносите на следующий комитет как доказательство, что прошлые деньги отработали.
Отдельно про пробел, о который многие спотыкаются. Часть нужных методик прямого российского аналога не имеет: например, процесс обслуживания (EN 17007), KPI (EN 15341) и сама «сборка» RCM под ИТ. Это не повод от них отказываться. Такие вещи закрываются через стандарт организации — СТО, который делает международную методику обязательным внутренним документом компании. По сути вы один раз описываете правила игры для ИТ-активов и утверждаете их — дальше на них можно ссылаться так же, как на ГОСТ.
Результат этого блока — не «презентация для руководства», а комплект документов, живущий в той же системе, что и обслуживание цехового оборудования. Именно поэтому его тяжело отклонить: отклонить ИТ-заявку легко, а отклонить строку в реестре активов с посчитанными эксплуатационными последствиями — уже совсем другой разговор.
Что с этим делать
Если сжать всю статью в одну мысль, она такая: перестаньте просить деньги на ИТ на языке ИТ. Опишите ИТ-систему как актив, посчитайте её риск через виды и последствия отказов и принесите это в тех документах, которым комитет уже доверяет. Вы не меняете суть своих запросов — вы меняете язык, на котором их слышат. Механик и айтишник в начале статьи просили про одно и то же: не дать критичному оборудованию встать. Разницу сделал только язык.
Начать можно в понедельник и без большого проекта. Возьмите один самый критичный ИТ-актив. Напишите для него одну строку FMEA: функция, один функциональный отказ, один вид отказа, последствие — и попробуйте отнести последствие к эксплуатационному, то есть перевести его в потерянную выработку или деньги. Одна строка. Этого уже достаточно, чтобы увидеть, как меняется разговор.
Дальше — сложнее не в методике, а в подаче. Защита ИТ-инициативы перед руководством — это отдельный навык: как за три минуты развернуть последствия, как ответить на «работает же», как не свалиться обратно в SLA и терабайты под давлением зала. Этому можно научиться и это можно отрепетировать заранее — до того, как вы окажетесь на реальном комитете.
Про это я и пишу в канале «Директор по IT. Как есть» (@it_kak_est): без глянца, на языке тех, кто реально защищает бюджеты на промышленных предприятиях. Если тема с переводом ИТ на язык надёжности откликнулась — заходите, там я разбираю такие приёмы предметно, на конкретных ситуациях.
P.S. Если у вас уже был случай, когда ИТ-бюджет зарубили со словами «работает же» — расскажите в комментариях, на каком активе и с какой формулировкой. Разберём, как это выглядело бы на языке FMEA.