Урок 4: Как выбрать PdM-SaaS — Augury vs Uptake vs Senseye vs C3.ai

Чему вы научитесь

• Отличать зрелую PdM-платформу от переоценённого «AI для всего оборудования»
• Быстро сравнивать Augury, Uptake (приобретён Bosch в марте 2026), Senseye, C3.ai, Aspen Mtell и другие платформы по сенсорике, TCO и fit для вашего типа активов
• Рано понимать, когда PdM вообще не нужен и задача лучше решается классической аналитикой, CMMS или собственным time-series стеком
• Читать западный рынок PdM как reference, но не путать его с доступным закупочным контуром в РФ
• Формулировать реалистичные ожидания от пилота и не обещать руководству ROI там, где его нельзя честно защитить

Predictive maintenance — одна из самых продаваемых категорий industrial AI. И одновременно одна из самых переоценённых. Причина простая: PdM хорошо выглядит на слайде, но плохо переносит грязную телеметрию, разреженные отказы, дешёвые активы и отсутствие ремонтной дисциплины. Поэтому закупка PdM-платформы — это не вопрос «какой SaaS моднее», а вопрос «есть ли у нас вообще объект для такой экономики».

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

Когда PdM вообще имеет смысл

Если у вас закрыто меньше большинства этих признаков, не идите сразу в PdM-SaaS. Сначала вернитесь к уроку p.2/07 и посмотрите, не решается ли задача baseline-прогнозированием, anomaly detection или простой rule-based аналитикой.

Международный reference-рынок PdM

Для российского предприятия эта таблица нужна как reference-понимание класса, а не как прямой список для закупки. По белому enterprise-контуру РФ все эти SaaS или официально недоступны, или экономически/юридически держатся на слишком хрупкой схеме — см. урок p.3/05.

Как читать типы PdM-вендоров

Augury

Augury полезен как reference для sensor-first machine health. Это сильный сценарий, когда проблема действительно похожа на «много вращающихся машин с повторяемыми поломками». Если ваш актив похож на это описание, логика Augury оправдана. Если нет — просто покупать «Augury-подобный» продукт бессмысленно.

Senseye

Senseye показывает другой подход: plant-wide SaaS, который хорошо ложится в Siemens-экосистему. Это полезно как образец того, как PdM масштабируют на уровне завода. Но если у вас нет Siemens-контра, а объект живёт в российском regulated-периметре, практическая ценность здесь скорее методическая.

C3.ai Reliability

C3.ai интересен там, где PdM — часть более широкого enterprise reliability/process optimization слоя. На их странице звучат очень сильные цифры вроде до -50% downtime, +5% OEE, -99% alert noise (C3 AI Reliability). Для procurement это не повод поверить цифрам «как есть», а повод правильно задать вопрос: какой baseline, на каком активе, в каком горизонте, с каким набором действий после алерта.

Aspen Mtell

Aspen Mtell остаётся важным reference для process industries — нефтехимии, переработки, тяжёлых технологических контуров. Но в российском контуре он важен уже не как опция закупки, а как причина появления программ импортозамещения и собственных платформенных разработок.

Таблица выбора: когда западный SaaS вообще был бы уместен и чем его заменять в РФ

Что реально брать в российском контуре

Здесь обычно есть три рабочих варианта.

1. Свой time-series стек

Самый недооценённый путь — собрать не «платформу предиктивки», а компактную аналитическую систему на основе forecasting и anomaly detection. Как правило, это комбинация:

• Prophet — если нужен простой и объяснимый baseline;
• Nixtla / NeuralForecast — если рядов много и нужна более сильная forecasting-линейка;
• PyOD — если надо ловить аномалии, а не строить сложный прогнозный пайплайн.

Это не теория, а практичный путь для предприятий, где нет права на западный SaaS и нет смысла покупать тяжёлую платформу до подтверждения economics. Инструменты разобраны в уроке p.2/07.

2. Платформенный промышленный слой в РФ

Если нужен data layer, интеграция с оборудованием, производственными системами и собственными приложениями, то логика чаще уходит в сторону Zyfra ZIIoT, in-house платформ крупных компаний или интеграторской сборки на российских облаках.

3. Custom-реализация через интегратора

Для большинства предприятий это наиболее реалистичный путь. Jet Infosystems, КРОК, IBS, ITPS и другие игроки могут собрать PdM-решение под конкретный класс активов, а не тащить коробочный SaaS, который потом упрётся в санкции, ИБ и отсутствие локального сервиса.

Реалистичные ожидания vs маркетинг

Чек-лист перед short list PdM-поставщиков

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

2. Посчитайте цену простоя. Без этого PdM защищать нельзя — см. урок p.4/02.

3. Проверьте телеметрию и историю ремонтов. Если они рваные, пилот будет строить данные, а не экономить деньги.

4. Решите, нужен ли вам вообще SaaS. Для российского regulated-контура часто ответ будет «нет» ещё до технической оценки.

5. Сверьте вариант с санкционным фильтром. Это обязательный шаг из урока p.3/05.

6. Спросите про action path. Кто реагирует на алерт, как меняется график ремонта, где это фиксируется в CMMS/EAM.

7. Только после этого делайте RFP.