Ремонты на предприятии чаще всего организованы так: оборудование обслуживается по техническому паспорту, заявки закрываются по графику, данные о сбоях оседают в Excel. Подобная модель выглядит довольно простой для реализации и в целом надёжной — если всё работает с запасом прочности, а технологический парк можно регулярно обновлять.
Но мы в другой ситуации. Техника эксплуатируется с высокой загрузкой, обновить её — дорого или почти невозможно, специалистов на рынке не хватает, каждый час простоя обходится дороже. Даже привычные процессы могут сбоить: то, что раньше закрывалось «по плану», перестаёт давать ожидаемый результат.
Проблема не в том, что механики плохо работают или регламенты неправильно написаны. Проблема в самой логике, на которой строится управление ремонтами.
Эта логика отвечает на вопрос «как обслуживать оборудование», но не помогает определить, какое оборудование действительно критично для производства, какие работы влияют на выполнение плана, где возникают реальные потери.
При таком подходе ТОиР (техническое обслуживание и ремонт) работает как техническая служба со своими внутренними показателями, а производство — со своими. Механики отчитываются количеством закрытых заявок, производственники — объёмами выпуска. Руководство видит затраты на ремонты в бюджете, но не понимает связи с производственными результатами.
Эта разобщённость создаёт конкретные риски. Непонятно, куда направить ограниченные ресурсы, какие работы действительно критичны, где нужно усилить контроль.
Системный подход к ТОиР позволяет встроить ремонты в операционное управление. То есть не просто следить за исправностью техники, а управлять производственными рисками через состояние оборудования.
Подробнее об этом поговорим 28-30 октября на бесплатном практическом онлайн-интенсиве «1С:ТОИР против Excel в управлении ремонтами». Зарегистрироваться можно здесь.
А пока разберём 3 бизнес-задачи, которые позволяет решить системный подход к ТОиР.
Представьте цех, где стоят три насоса одной модели. Первый обеспечивает работу всей производственной линии, второй служит резервом на случай аварии, третий подкачивает воду для вспомогательных нужд. По действующему регламенту все три получают одинаковое обслуживание: например, замена масла раз в полгода, диагностика через 5000 часов работы.
С точки зрения механика это удобно — не нужно запоминать разные схемы для одинакового оборудования. Но с точки зрения бизнеса получается абсурд: критически важный и вспомогательный насосы получают равное внимание, хотя их роль в производственном процессе кардинально различается.
Почему так происходит?
Регламенты обслуживания составляются по принципу «одна модель — одна схема». Это упрощает планирование, но игнорирует реальные условия эксплуатации каждого конкретного агрегата.
Регламенты обслуживания составляются по принципу «одна модель — одна схема». Это упрощает планирование, но игнорирует реальные условия эксплуатации каждого конкретного агрегата. Источник: пресс-служба компании «Деснол»Основной насос может работать круглосуточно с максимальной нагрузкой, резервный — включаться раз в месяц, а вспомогательный — работать по несколько часов в день. При одинаковом обслуживании первый рискует выйти из строя раньше срока, а третий получит избыточную профилактику.
Проблема усугубляется тем, что даже при наличии данных о реальном состоянии техники эта информация редко меняет планы. Результаты осмотров показывают степень износа, датчики фиксируют параметры работы, ведётся история отказов — но план ремонтов формируется заранее на основе календаря, а не актуальных данных.
Получается парадокс: информация есть, но используется для отчётности. Такая логика создаёт скрытые риски. Когда бюджет на ремонты ограничен — а он ограничен практически всегда — компания не может отличить действительно приоритетные работы от рутинных. Ресурсы распределяются равномерно, а не там, где они нужнее всего.
Когда у вас внедрена единая система ТОиР, планирование становится риск-ориентированным. То есть мы ориентируемся не на календарь, а на значимые для бесперебойной работы факторы: техническое состояние каждой единицы оборудования, интенсивность её использования и критичность для производственного процесса.
Система анализирует данные осмотров, показания датчиков, дефектовку и определяет, где ресурс действительно на исходе, а где его ещё достаточно.
Мы работали с крупным нефтеперерабатывающим предприятием, которое обслуживало десятки резервуаров строго по календарю, не учитывая различия в степени коррозии и условиях эксплуатации.
Отказы случались регулярно — некоторые резервуары вырабатывали ресурс значительно раньше планового срока. Цена таких отказов может достигать сотен миллионов рублей в день — в зависимости от того, что именно и как надолго выходит из строя.
После внедрения системы каждому резервуару присвоили коэффициент риска на основе данных диагностики. Этот коэффициент учитывал не только износ металла, но и роль конкретного резервуара в технологической цепочке. Самые уязвимые объекты получили приоритет в планах обслуживания.
В результате за год компания перераспределяет треть бюджета в пользу критически важных активов. При том же уровне общих затрат количество внеплановых простоев сократилось на четверть — достаточно весомый аргумент в пользу автоматизации.
Руководитель производства видит в месячном отчёте строку «Затраты на ремонты: 2,5 млн рублей». Рядом другая строка «Выполнение плана производства: 94%». Есть ли связь между этими цифрами? Скорее всего, никто не знает.
Ремонтная служба отчитывается количеством закрытых заявок и соблюдением графиков профилактики. Производственная служба — объёмами выпуска и соблюдением сроков. Руководство видит затраты на обслуживание оборудования, но не понимает, что конкретно эти деньги обеспечивают: какие простои предотвращают, как влияют на себестоимость продукции, сколько поставок клиентам спасают от срыва.
Такая разобщённость делает ремонты «чёрной дырой» в бюджете. Невозможно оценить эффективность вложений: стоит ли тратить дополнительные средства на диагностику, если неясно, как это повлияет на производственные показатели. Нельзя обосновать увеличение бюджета на профилактику, потому что нет данных о том, сколько стоят предотвращённые аварии.
Ремонты перестают быть «чёрной дырой», когда их стоимость можно измерить в невыпущенной продукции. Фото из открытых источниковКорень проблемы в том, что ремонты воспринимаются как техническая функция, которая работает по своим внутренним правилам и показателям. Механики думают категориями «исправно-неисправно», а бизнес — категориями прибыли, сроков поставки, качества продукции.
Чтобы эти два мира начали работать вместе, нужны количественные связи: сколько часов простоя оборудования влияет на выполнение плана, как профилактика одного узла влияет на надёжность всей линии, какова реальная стоимость каждого часа аварийного простоя.
Здесь помогают специальные показатели:
Но собрать эти данные вручную практически невозможно. Информация хранится в разных местах и не связана между собой: инженер анализирует причины отказов в своей таблице, но не передаёт выводы в отдел снабжения — просто потому, что такого регламента нет, да и в таблице снабженцев эта информация не предусмотрена.
Снабженец заказывает запчасти по заявкам или нормативам потребления, не зная, что частота поломок конкретного узла выросла, потому что до него эта информация не доходит. Руководство получает технические отчёты от механиков и производственные сводки от мастеров, но связать эти данные с ключевыми показателями бизнеса может только вручную, а на это нет ни времени, ни инструментов.
Системный подход решает эту проблему через единую информационную среду.
Каждая заявка на ремонт становится источником данных: когда она закрывается, система автоматически обновляет статистику надёжности, корректирует прогнозы отказов, пересчитывает влияние на производственные показатели. Руководство понимает, какие узлы чаще всего влияют на сбои в поставках, где растёт риск невыполнения планов, какие зоны требуют перераспределения ресурсов.
Хороший пример — проект с горно-металлургическим комбинатом, который располагается на Крайнем Севере.
Там внедрены показатели надёжности оборудования с логистическими затратами: система стала отслеживать коэффициент технической готовности и время между отказами каждого узла, что помогло точнее планировать поставки запчастей и сокращать дорогостоящие авиаперевозки при срочных ремонтах. Техническое обслуживание стало частью системы управления производственными рисками.
Даже если в компании есть регламент ТОиР, устойчивость процессов на практике часто держится не на системе, а на отдельных людях.
Инженер знает, где лежит нужная запчасть, как устранить отказ на этом типе оборудования, кому позвонить в снабжении, если нужная позиция вне каталога. Он ведёт свой Excel с маршрутами, помнит, какие дефекты критичны, а какие можно отложить.
Но всё это — у него в голове. Если сотрудник увольняется или уходит в отпуск, логика обрывается. Новый человек может открыть тот же Excel, но не поймёт, почему из трёх одинаковых насосов обслуживается только один. Ответа нет — просто «так было всегда».
Когда ключевой специалист недоступен, компания тратит время на восстановление логики: где шаблоны, кто теперь отвечает, как пересчитать графики.
Вот примерно так всё выглядело на одном из наших проектов до автоматизации. Данные хранились разрозненно: в Excel-файлах, Word-документах, бумажных журналах. Информация по отказам, ТМЦ (товарно-материальным ценностям) и проведённым работам пересылалась по мессенджерам и почте. При смене сотрудников часть информации просто терялась — она нигде не фиксировалась в формализованном виде.
Автоматизация ТОиР позволяет объединить технические данные, паспорта, плановые работы и факты обслуживания в единую среду. Источник: пресс-служба компании «Деснол»Автоматизация в этом случае позволила объединить технические данные, паспорта, плановые работы и факты обслуживания в единую среду — по сути, получилась библиотека знаний.
То есть новые специалисты могли увидеть всю историю объекта: отработанное время, дефекты, заменённые узлы. Если насос выходит из строя — не нужно «добираться» до предыдущего исполнителя. Достаточно открыть карточку, чтобы понять, что с ним было, кто и что делал, когда истекает ресурс.
Автоматизация не отменяет роль людей, но делает процессы независимыми от их сменяемости. Это особенно важно в условиях дефицита квалифицированного персонала: предприятие сохраняет устойчивость даже при высоком уровне текучести — потому что опирается на данные, а не на память.
Системный ТОиР не сводится к автоматизации ремонтных заявок. Это инфраструктура, которая формализует знания об оборудовании, снижает зависимость от отдельных специалистов и позволяет управлять активами как частью производственной системы. Она встраивается в цифровой контур предприятия, связывается с ERP, MES, складскими и снабженческими системами и становится частью общей логики управления.
В условиях дефицита кадров и высокой загрузки оборудования такая система становится опорой. Она удерживает технологическую преемственность при смене персонала, синхронизирует ремонты с производственным графиком, даёт управляемость затратам и помогает принимать решения на основе данных, а не интуиции.
А когда обновление парка становится всё менее доступным, системный ТОиР позволяет выжимать максимум из уже работающего оборудования. Он помогает продлевать ресурс, устранять риски до сбоев и удерживать устойчивость там, где нет запаса прочности.
Переход к системному ТОиР — это не вопрос внедрения программы, а вопрос управляемости. Где начать, как перевести данные из Excel в работающую модель и увидеть эффект в цифрах — обсудим на бесплатной практической онлайн-конференции «1С:ТОИР VS Excel в управлении ремонтами».
Зарегистрироваться можно здесь.