Привет, Хабр! Меня зовут Роман Путилов, я руководитель направления позиционирования продукта в Cloud.ru. Среди наших заказчиков довольно много промышленных предприятий, например «Стройдормаш» и племзавод «Октябрьский».

Исторически сложилось, что автоматизация ТОиР на заводах — это долго и дорого. Чтобы оцифровать ремонтные процессы, компании закладывают крупный CAPEX, проходят затяжные тендеры и месяцами ждут инфраструктуру. Итог: оборудование простаивает, бизнес теряет деньги.

В статье разберем, как сократить этот цикл: отказаться от закупки серверов, перенести систему в облако и запустить пилот на реальном участке за считаные недели с первыми результатами уже через несколько месяцев.

Содержание: 

1. Заводские реалии

2. Почему цифровизация буксует на старте

3. Облако вместо серверов

4. Как продать облако финдиректору

5. Роадмап пилота: как запуститься за 14 дней

6. Ошибки и ограничения

Заводские реалии

Сразу оговорюсь: сам я у станка не стою и наряды-допуски не подписываю, но регулярно общаюсь с теми, кто этим занимается, — с главными инженерами, ИТ-директорами и руководителями ремонтных служб. Дальше я опишу ситуацию так, как ее видят наши заказчики и партнеры из АНТ-ЦС, у которых за плечами 25 лет работы с производственными предприятиями.

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

По внутренним оценкам АНТ-ЦС, до 30% потерь эффективности оборудования (OEE) — это не сложность самих ремонтных работ, а задержки в коммуникации и бумажная бюрократия. Откуда берется такая цифра? 

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

Из такой расстановки вытекает несколько типичных следствий:

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

• Аналитика затруднена. Свести историю отказов, посчитать MTTR или найти первопричину повторяющейся поломки по бумажным журналам можно, но это отдельный проект, а не рутина. В итоге решения о замене оборудования и закупках принимаются по ощущениям, а не по данным.

• Склад работает с запасом. Раз спрогнозировать поломки сложно, то запчасти закупаются на всякий случай. 

Когда эти эффекты складываются, бизнес рано или поздно обращает внимание на ТОиР — обычно после крупного инцидента, сорванного контракта или аудита склада. Возникает запрос о необходимости уйти от бумаги, поставить нормальную EAM-систему, начать управлять активами по данным. 

И вот здесь начинается история внедрения.

Трагедия ИТ-отдела: почему цифровизация буксует на старте

Запрос «Нам нужна нормальная EAM-система» обычно прилетает на стол ИТ-директору, тот садится собирать смету, а дальше начинаются первые сложности.

В классическом сценарии внедрение системы ТОиР идет по on-premise-модели — на собственных серверах предприятия. Это почти всегда означает крупные капитальные затраты (CAPEX). Чтобы дойти до момента, когда бригада получит планшеты, а главный инженер — дашборды, заводу нужно пройти несколько шагов:

• обосновать бюджет, провести тендеры, закупить серверы и СХД;

• оплатить лицензии на ПО, обычно сразу на несколько лет вперед;

• усилить ИТ-команду — добавить администраторов, отвечающих за инфраструктуру, бэкапы и безопасность новой системы.

Проблема в том, что эти шаги идут последовательно и упираются в физическую логистику. По опыту коллег из АНТ-ЦС, путь от подписания контракта до боевого запуска по on-premise модели обычно занимает от 6 до 12 месяцев, и это спокойный сценарий, без задержек. 

В реалиях 2026 года к этому добавляется еще один момент — необходимость подобрать, привезти и развернуть серверное оборудование под крупный проект. А это задача, которую не всегда можно ускорить деньгами. Сроки поставок, конфигурации, совместимость с тем, что уже стоит в ЦОД — все это растягивает старт.

В итоге к моменту, когда смета попадает на стол к финансовому директору, картина обычно такая: большой CAPEX, а горизонт результата — следующий финансовый год. И, как следствие, ожидаемый вопрос: «А можно ли это сделать дешевле и быстрее?» Часто на этом этапе проект и глохнет: его не отменяют, но и не запускают, так как ждут более подходящего момента. Производство тем временем продолжает работать в прежнем режиме.

Здесь стоит честно оговориться: классический on-premise — неплохой вариант сам по себе. Для части предприятий это единственный возможный путь, и дальше мы еще скажем об этом отдельно.

Вопрос в том, что для большинства заводов CAPEX-история — это не единственная опция. Есть альтернатива, которая позволяет сначала проверить идею, а уже потом решаться на большой проект.

А что, если?.. Облако вместо серверов

Если идти классическим путем, то завод так и будет терять деньги на каждом сломанном насосе. Но этот цикл можно разорвать. 

Раз главная проблема любого ИТ-проекта на производстве — это железо и гигантские стартовые инвестиции, то давайте просто вычеркнем их из уравнения и уйдем в облака.

На примере нашей модели проект устроен так: система ТОиР от АНТ-ЦС развернута на инфраструктуре Cloud.ru, завод получает к ней доступ по подписке, бригады — мобильное приложение на планшеты, и пилот запускается прямо на проблемном участке цеха. И это всё не за год, а за недели.

Дальше я возьму этот сценарий и разберу пошагово:

• как посчитать ROI и защитить пилот перед финансовым директором;

• как выглядит роадмап запуска за 14 дней — от выделения контура до выхода бригад «в поля»;

• как мобильное приложение работает в цехах, где половина помещений — мертвые зоны без сети.

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

Как продать облако финдиректору

Разговор про новую систему на производстве рано или поздно сводится к двум вопросам: сколько это стоит и когда даст результат? Чтобы защитить идею, надо правильно сформулировать контраргументы под каждый стоппер.

Деньги

Тезис № 1. Мы отказываемся от капитальных затрат (CAPEX) и переходим на операционные (OPEX).

В on-premise модели завод платит за систему ТОиР как за актив: закупает серверы и СХД, оплачивает лицензии, расширяет ИТ-команду под обслуживание новой инфраструктуры. Это крупная разовая трата — CAPEX.

В облачной модели завод не покупает железо и не получает лицензии в собственность. Вместо этого подключается к готовой инфраструктуре провайдера, на которой уже работает система ТОиР, и оплачивает ее использование. Стоимость подписки — от 15 000 рублей за пользователя + около 300 000 рублей единоразово за настройку, консультацию и обучение + облачные сервисы. Это операционные расходы — OPEX.

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

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

Сроки

Тезис № 2. Меняется скорость выхода на результат. 

В on-premise сценарии большая часть времени уходит на подготовительные шаги: подобрать и закупить железо, привезти, развернуть в ЦОД, настроить сеть и базы, потом уже разворачивать ПО. По опыту АНТ-ЦС, путь от подписания контракта до боевого запуска занимает 6–12 месяцев, но при условии, что серверное оборудование приедет точно в срок.

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

• импорт справочников — оборудование, технологические карты, нормативы, запчасти;

• настройка графиков ППР, маршрутов обходов, ролевой модели пользователей;

• интеграция с учетной системой завода («1С», SAP или другой ERP) через готовые API-коннекторы;

• тестовый прогон сценариев — создание заявки, планирование, закрытие работ;

• установка мобильного приложения на устройства бригад и обучение пользователей.

В сумме это от одного месяца (пилот в одном цехе) до трех, если проект сложный.

Ответственность и безопасность

Тезис № 3. Меняется зона ответственности за инфраструктуру.

В on-premise модели техническая поддержка системы лежит на ИТ-отделе завода. Администрирование серверов, обновления ПО, бэкапы, мониторинг доступности, защита от сбоев — все это нужно делать своими силами.

В облачной модели часть этих задач уходит к провайдеру и разработчику системы.

• Cloud.ru, как облачный провайдер, отвечает за инфраструктурный слой: доступность виртуальных машин и СХД, физическую безопасность дата-центров, базовое резервное копирование, сетевую связность.

• АНТ-ЦС, как разработчик системы, отвечает за прикладной слой: обновления АНТ ТОиР, поддержку работоспособности продукта, исправление ошибок, развитие функциональности.

• Завод-заказчик отвечает за свои данные, бизнес-процессы и управление учетными записями пользователей.

Тезис № 4. Регуляторные требования закрываются на стороне провайдера.

Одни из главных стопперов облачных проектов на промышленных предприятиях — безопасность и соответствие регуляторике. Производство часто относится к критической информационной инфраструктуре. Логичный вопрос службы информационной безопасности: «А точно ли наши данные будут защищены?»

Отвечаю: у хорошего провайдера инфраструктура аттестована для работы с персональными данными по требованиям 152-ФЗ, дата-центры физически расположены в России, есть сертификаты ФСТЭК. Поэтому при оценке соответствия завод подтверждает только свою часть (приложения, данные, процессы), а по облачной инфраструктуре запрашивает сертификаты у провайдера.

Чтобы наглядно показать, кто за что отвечает в этой конструкции, сделал схему архитектуры.

Роадмап пилота: как запуститься за 14 дней

С деньгами, скоростью и ответственностью разобрались. Остается понять, как именно выглядят эти 14 дней.

Главная ошибка заводов при цифровизации — попытка оцифровать все сразу и побыстрее. Но именно из-за этого внедрение превращается в долгострой на три года, выматывающий всю команду. Облака помогают пересобрать этот процесс и запустить боевой пилот всего за две недели.

14-дневный спринт может выглядеть так:

• Дни 1–3 — облачный фундамент. Провайдер выделяет готовую виртуальную инфраструктуру. ИТ-отделу не нужно настраивать сеть с нуля и поднимать базы — завод просто получает ключи от изолированного защищенного контура.

• Дни 4–10 — интеграция и настройка. Система АНТ ТОиР стыкуется с заводской учетной системой («1С», SAP или «Галактикой»). За счет готовых API-коннекторов базовый обмен справочниками настраивается за считаные дни, но итоговый срок зависит от степени кастомизации вашей ERP.

• Дни 11–14 — полевые испытания. Бригадам выдают защищенные планшеты с приложением «мТОиР» и проводят экспресс-онбординг. Далее их отправляют на реальный обход.

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

Вопрос 1: «А как интегрировать все это с нашей ERP?»

Любая интеграция в энтерпрайзе — это отдельный проект. У завода уже работают свои системы: «1С» с накопленной за годы кастомизацией, SAP, «Галактика» и т. д. Естественное опасение: новая система ТОиР встанет рядом, не подключится к складу и ERP и в итоге будет жить своей жизнью.

Решение. У АНТ-ЦС уже есть готовые адаптеры к типовым системам: к семейству «1С» — полностью готовые; к SAP, «Галактике» и другим ERP — типовые шаблоны, которые адаптируются под конкретный контур заказчика. Базовые сценарии обмена — справочники, заявки, складские остатки — настраиваются быстро. В крайнем случае, если делать с нуля, — до месяца.

Вопрос 2: «Что делать, если данных нет в электронном виде?»

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

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

Логика такая: для двухнедельного пилота не нужно оцифровывать весь завод. Берется 3–5 единиц критичного оборудования — такого, у которого чаще всего возникают простои. По ним собирается минимальный набор информации:

• Паспорта оборудования и инструкции по эксплуатации. Там обычно прописаны регламенты ТО.

• Наряды и журналы ремонтов. Там видно, какие операции реально выполняются.

• Знания бригады — то, что нигде не записано, но используется ежедневно. Это вытаскивается через короткие интервью со слесарями и мастерами.

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

• у каждого объекта есть понятное название и идентификатор;

• зафиксирован состав узлов — что именно может ломаться;

• есть базовые типы дефектов и работ;

• заполнены простые справочники, чтобы пользователи выбирали значения из списка, а не вводили текстом каждый раз.

Эти данные собираются в простые шаблоны, чаще всего в Excel, которые АНТ-ЦС предоставляет в начале проекта. Есть три варианта работы с шаблонами, и завод выбирает тот, что удобнее:

1. Полностью на стороне завода. Подходит, если на предприятии есть ресурс и желание контролировать процесс самостоятельно.

2. Совместно с АНТ-ЦС. АНТ дает шаблоны, проверяет корректность заполнения, помогает с импортом данных в систему.

3. Полностью силами АНТ-ЦС (как консалтинговая услуга). Обследование на площадке, наполнение справочников, настройка.

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

Оцифровка даже такого небольшого куска сразу же дает результат. Развертывание занимает дни, но уже в течение 3–6 месяцев завод начинает системно видеть причины отказов, реальный расход запчастей в конкретном цеху и, главное, получает прозрачные метрики эффективности для масштабирования на все предприятие.

Вопрос 3: «А что, если мы никогда раньше не считали простои?»

Любой пилот ТОиР в итоге упирается в одну просьбу: «Покажите экономику». Потому что без этого проект масштабировать не будут.

Обычно формула для расчетов такая:

Но как посчитать возврат инвестиций, если до пилота завод вообще не вел учет времени простоя? Ведь тогда считать просто нечего.

На практике это не так. Даже если нет телеметрии и датчиков, следы простоев всегда остаются в операционных данных. Их можно собрать и превратить в деньги.

1. Для начала определяем затраты на проект.

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

2. Дальше переходим к самому важному — выгодам. 

Основной эффект в ТОиР — это снижение простоев. Чтобы его посчитать, достаточно определить стоимость часа простоя оборудования и умножить ее на время, которое удалось сократить.

И даже если на заводе нет точного учета простоев, данные все равно можно восстановить. Они будут размазаны по операционке: в актах на брак видно, сколько продукции потеряли после аварий; в складских журналах — сколько времени оборудование ждало запчасти; в планфакте — где недовыполнение связано именно с поломками. В итоге получаем рабочую оценку простоев.

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

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

Когда есть затраты на пилот и понятная оценка годового эффекта, их остается подставить в формулу ROI. По стандартам отрасли, если целевой ROI превышает 100%, а срок окупаемости составляет менее 6 месяцев, то обсуждение сразу переходит из плоскости «нужно ли это» в «как бы нам быстренько это дело развернуть».

Но вам не обязательно высчитывать все это самим. У АНТ-ЦС есть готовый калькулятор в Excel, в который вшиты все четыре компонента расчета: снижение простоев, риски аварийных остановок, оптимизация склада и рост производительности бригад. Вы просто вбиваете туда базовые показатели своего предприятия (стоимость часа простоя, ФОТ ремонтников) — и файл за пять минут генерирует готовое финансовое обоснование для защиты пилотного проекта перед вашим директором.

Ошибки и ограничения

Цифровизация производства — это не легкая прогулка. Поэтому дальше рассмотрим несколько ситуаций, где проекты могут пойти не по плану.

Ошибка 1: внедрять всё и сразу

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

Решение: изолируйте внедрение. Берем строго один цех и 3–5 самых проблемных активов с высоким риском простоя. Обкатываем механику на них, получаем первые метрики эффективности и только потом масштабируем систему на соседние участки.

Ошибка 2: верить в идеальный заводской вайфай

Цеха — это металл, железобетон, высоковольтное оборудование и помехи. Вайфай там не везде, LTE местами не ловит, в подвалах и технических помещениях связь может пропадать вовсе. Веб-приложение, которое требует постоянного соединения с сервером, в такой среде работать не будет.

Решение: мобильный клиент с архитектурой offline-first. Слесарь уходит в подвал, делает фото дефекта, заполняет чек-лист без единой палочки связи. А как только он выходит в курилку или диспетчерскую и ловит сеть, приложение делает отложенную фоновую синхронизацию с облаком.

Ошибка 3: игнорировать сопротивление сотрудников

У бригад уже есть отлаженный способ делать работу — со своими привычками, обходными путями, договоренностями между сменами. Любая новая система меняет этот сложившийся уклад, и реакция на нее будет настороженная. И это нормально.

Решение: показать практическую пользу. Когда сотрудник видит, что ему не нужно бегать за подписью и вручную передавать информацию, то отношение меняется.

Конкретные приемы, которые помогают:

• внедрять постепенно, а не директивно;

• начинать с тех функций, которые реально снимают рутину. Например, мобильное приложение убирает бумажные наряды и беготню за подписями;

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

• учитывать, что переход у разных сотрудников идет с разной скоростью, не давить и не форсировать.

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

Ошибка 4: проигнорировать ограничения по периметру

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

Решение: принять боль. На таких объектах придется идти по проторенному, но не всегда простому пути on-premise: закупать собственные серверы, разворачивать железо в изолированном контуре и мириться со всеми капитальными затратами.

Заключение: что делать дальше

На Хабре не принято верить вендорам на слово, и это правильно. Любые цифры и кейсы из статьи — это только ориентир. В реальности же все зависит от конкретного производства. Поэтому перед масштабированием предлагаю проверить систему на практике:

1. Съездить на референс-визит и пощупать руками. Коллеги из АНТ-ЦС могут организовать для вас онлайн-сессию или живую экскурсию на завод из вашей отрасли, где АНТ ТОиР уже внедрен.

2. Протестировать решение на своих данных. Запросите демодоступ к защищенной инфраструктуре на мощностях Cloud.ru. Пришлите нам 1–2 ваши реальные техкарты — хоть кривой Excel, хоть фото помятого листа. Мы сами их оцифруем, загрузим в систему и сделаем готовый расчет экономики с учетом стоимости часа именно ваших простоев.

3. Послушать наш вебинар. Вот запись вебинара, на котором мы вместе с АНТ-ЦС полтора часа разбирали тему цифровизации завода. Из того, что в статью не вошло или вошло сокращенно: подробнее про кейс «Газпрома», детали по ROI-калькулятору и нюансы интеграций с разными ERP.