"Чтобы" (или "для чего")- этим предикатом описывается цель проведения ТОиР. Ремонт ради ремонта не нужен. В самом простом варианте "чтобы выпустить нужный объем продукции/услуг и при этом не было аварий и связанных с ними проблем". То есть надо описать цель. Или точнее, параметры целевой ситуации (если это можно сделать). Тут для менеджмента часто кроется серьезная засада. Потому, что нужны внятные и измеряемые критерии. В мире есть разные целевые критерии: MTBF, SAIFI, SAIDI, CAIDI и многие другие (общие или специфические - это будет отдельной темой). В основном, это оценки стоимости перерывов/простоев и, дополнительно, - возникающего экологического вреда... Формулировки при этом могут быть разными: "чтобы перерыв в функционировании не превышал 15 минут". Или "чтобы между авариями было не меньше 500 часов исправного функционирования". Или "чтобы суммарный ущерб был не больше 1 тысячи рублей". Или "чтобы выдержало ураган". Или как-то еще... Но формулировать задачу в стиле "чтобы все было хорошо" - это неправильно и безграмотно.

"Куда" - чтобы иметь возможность ответить на этот вопрос, надо предварительно иметь хорошо структурированное оборудование/активы. Cледовательно, надо провести их структуризацию и паспортизацию. И уложить полученную при структурировании разнообразную (технически и экономически значимую) информацию в БДО (Базу данных оборудования - так обычно называется). Обычно в результате получается структура типа дерева (от крупного - к отдельным компонентам). Лишь после этого можно приступать к реализации каких-либо идей в сфере ТОиР. Ибо для инвестиций появляется конкретный адресат. Понятно, в этом дереве появятся надежные и проблемные узлы. Но об этом - следующий пункт.

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

А вот тут ситуация посложнее. Ответ на этот вопрос - это, в определенной степени, ответ на вопрос "что делать". Можно делать по максимуму можно делать по минимуму. Сколько - это зависит от того, что мы хотим достичь своими инвестициями, куда перевести проблемный актив (в смысле его способности приносить отдачу и не приносить проблем). А хотеть можно разного... Можно капитально обновить актив (провести капремонт или даже модернизацию), а можно провести минимальное техобслуживание (сменить масло, условно говоря). Плюс к тому, тут надо учитывать ограничения на бюджет. Часто бывает, что именно здесь находится "зона компромиссов". Но проблема тут есть серьезная. Ибо никто не знает, что лучше: сейчас вложить Х, или позже вложить 10Х. Недовложение vs избыточной надежности. Тут возникает тема анализа технологических и имиджевых рисков.

Итак, мы пристыковали друг другу понятия "куда, когда и сколько" и "зачем". Конечно, это все очень упрощенное изложение. Но иногда надо отстраниться от деталей и посмотреть на ситуацию в её рафинированном виде, слегка сверху. В принципе, тут есть место для довольно серьезной математики, но этому будет посвящен отдельный материал (математические модели есть и будут изложены при необходимости). Мы пока не анализировали массу практических локальных вопросов (например, доступность необходимых материальных/транспортных/трудовых ресурсов или скачкообразное изменение Индекса Технического Состояния). Все это решаемо довольно легко - при наличии соответствующего поддерживающего ПО, разумеется. И, следовательно возникает предпосылка уйти от "кошмара владельца/инвестора", который заключается в неприятной неопределенности - что лучше: инвестировать немного, но часто или же много, но редко... Это похоже на известный анекдот от Жванецкого про раков... :-)

Можно ли иметь хорошую методологию ТОиР и не иметь ПО ? Да, можно. Ответственно заявляю, можно всё сделать в Excel. Но все же лучше это делать с помощью тематической ТОиР-платформы, которая содержит определенное количество функциональных заготовок. Например, которая может опрашивать активы и фиксировать возникающие дефекты. И ставить им в соответствие необходимые технологические карты... Еще очень полезна функциональность прогнозирования ИТС. Плюс к тому, никто не отменяет учетные задачи и отчетность, поэтому интеграция с бухгалтерской системой (а лучше - не с одной) - это тоже базовое свойство ТОиР-платформы. Впрочем, это уже отдельная тема...

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

Не все можно предугадать, заранее промоделировать и просчитать. Это одна причина возникновения аварий - не смогли подготовиться. Другая причина - не захотели готовиться. Ведь неблагоприятные условия могут сложиться, а могут и не сложиться. А деньги будут потрачены. Обычная логика хозяйственника - не предугадывать, а ликвидировать. И денег может быть потрачено меньше (иногда больше, но за это не спросят - это идет от ситуации). И часто сталкиваются разные тактики: Планово-Предупредительные Ремонты (ППР) и Ремонты по Фактическому Состоянию (РФС), для простоты можно считать так. Обычно затраты на ППР существенно больше, чем на РФС. Поэтому переход от ППР к РФС зачастую экономически оправдан. Но методологически сложен. Ибо часто неясно, где граница надежности, которую нельзя пересекать. Иногда бывают парадоксы - правильный расчет актуального технического состояния сложного агрегата дороже, чем возникающая экономия от перехода на РФС. Этот расчет (если аккуратный) - должен учитывать много параметров, которые могут оказаться неизмеряемыми. Отсюда и дороговизна. Но, пожалуй, это уже ближе к Data Science...

АСУТП/SCADA - не идеальный инструмент для сбора информации о техническом состоянии оборудования. И датчиками тоже нельзя все обвесить. Про модные ныне т.н. IoT-устройства практикующим хозяйствнникам и говорить не стоит. Но пока никто не отменял обходы/осмотры. И это хорошо. Даже там, где есть АСУТП/SCADA. Это правильно, но обходчиками надо теперь давать не блокнот и карандаш для записей, а защищённый смартфон и делать для него голосового ассистента. Который может распознать эмоциональное восклицание обходчика типа "О, крану-то, кажись, пришел капец, промайновывается,...". То есть в ТОиР-системе надо уметь распознавать голосовое сообщение, снабженное профессиональными аббревиатурами и терминами. И таким образом будет организована доставка технологической информации об актуальном состоянии оборудования в корпоративную ТОиР-систему. В принципе, тут расположена точка роста, в этом заключается способ повышения эффективности от использования ТОиР-систем, как ни странно это звучит.