Запросы на сравнение SCADA и систем диспетчеризации от разных вендоров (производителей) — обычное дело при выборе поставщика. Это необходимый шаг, но крайне субъективный: результат зависит от множества факторов. В этой статье я не буду сравнивать производителей по техническим и функциональным критериям — оставим эту «грязную работу» соответствующим специалистам . Вместо этого поделюсь практическим опытом выбора вендора через призму других, не менее важных критериев: зрелость компании, наличие экосистемы, доступность обучения и поддержки, совокупная стоимость владения системой (TCO).
Типичный сценарий: импортозамещение
На предприятии установлено иностранное ПО — Siemens, Schneider Electric, Honeywell, GE, Yokogawa и т. п. Оно работает стабильно по принципу «работает — не трогай», однако регулятор требует замены на значимых объектах КИИ (ЗО КИИ) согласно ПП № 1912.
Руководитель отдела АСУ ТП, инженер, «домашний» интегратор или консалтинговая компания провели техническое сравнение трёх — пяти–семи российских производителей по балльной системе и получили таблицу с двумя-тремя лидерами и остальными претендентами. Дальше начинается самое сложное — выбор между ними.
Здесь важно понимать: в нынешних условиях в процессе выбора вы столкнётесь как с компаниями, давно присутствующими на рынке, так и с теми, кто появился всего 3–4 года назад. Подчёркиваю: критерии, изложенные ниже, крайне важны — вне зависимости от публичных деклараций о технических и функциональных возможностях.
Что делать дальше?
SCADA или платформа?
SCADA подходит для локальных задач: котельные, АРМ оператора производственной линии или цеха. Платформа — для крупных и распределённых проектов. На практике часто сравнивают SCADA одного производителя с платформой другого — и по технике, и по цене. Это некорректно. Различия в архитектуре, масштабируемости и возможностях интеграции делают такое сравнение бессмысленным.
Ключевые отличия SCADA от платформенного решения: функциональные возможности, масштабируемость (в том числе изменение стоимости и производительности при росте системы), архитектура, глубина интеграции с ИТ-ландшафтом предприятия. Эта тема заслуживает отдельной статьи.
Ценовой анализ
Анализ цен по типовым архитектурам проекта — обязательный шаг. Лицензионная политика у вендоров существенно различается: теги ввода/вывода, клиентские подключения, дополнительные драйверы, не включённые в базовый пакет, — всё это считается по-разному. Если разница в цене между вендорами одного класса превышает 30%, рекомендую уточнять детали у производителя или его дистрибьютора: зачастую правильно подобранная архитектура позволяет привести стоимость к сопоставимым значениям.
Ключевые критерии выбора вендора
Ниже — критерии в порядке значимости. Оговорюсь сразу: везде нужен баланс, все критерии важны, и здесь большое поле для дискуссии.
- Экосистема системных интеграторов
На мой взгляд, это самый важный фактор. Все инжиниринговые компании, как правило, мультивендорные, и наличие в их портфеле действующего сертификата от конкретного вендора — косвенный индикатор его рыночной конкурентоспособности.
Важный элемент зрелой экосистемы — многоуровневая сертификация системных интеграторов, учитывающая опыт и актуальное владение продуктом. Эти требования полезно включать в тендерную документацию на реализацию проекта: это повышает вероятность выбора качественного подрядчика.
При выборе системного интегратора обращайте внимание на реализованные проекты, состав команды и релевантный опыт в функциональной области вашего проекта. Хороший, проверенный интегратор — при наличии вовлечённых специалистов со стороны заказчика — способен нивелировать технические и функциональные слабости ПО.
Тем более важно учитывать, что в рамках тренда на открытую АСУ ТП роль и ответственность системного интегратора кратно возрастают (роль СИ при построении АСУ ТП по стандартам O-PAS — это отдельная интересная тема). И, конечно, наличие выбора среди сертифицированных инжиниринговых компаний в вашем регионе частично снимает риски дальнейшего сопровождения системы.
- Техническая поддержка
Если проект крупный, распределённый, объекты удалённые, а квалификация собственного персонала вызывает вопросы — обязательно запрашивайте стоимость и условия платной технической поддержки на 1, 3 и 5 лет. В таких случаях настоятельно рекомендую включать техническую поддержку как на этапе внедрения, так и на этапе эксплуатации в совокупную стоимость владения системой (TCO).
- Обучение
Для многих производителей критичен порог входа в разработку. Какой базовый уровень специалиста необходим? Потребуются ли скрипты на C++/Java или привлечение DevOps-инженеров?
Low-code системы снижают порог входа, но часто ограничены по функционалу. Это нужно учитывать при выборе.
Оцените:
- Сроки, стоимость и формат обучения (очно/дистанционно)
- Географию учебных центров — обучение не должно быть привязано к одному городу раз в квартал
- Наличие полноценной программы и доступных материалов после обучения
Если актуальные версии документации и учебных материалов не предоставляются сразу — это тревожный сигнал.
- Истории успешных внедрений
Идеально — в вашей отрасли. Часто встречаемся с требованиями потенциального заказчика о наличии реализованных проектов по уникальным предприятиям мирового уровня, аналогов которым нет, например, «Алросы», «Норникеля», «КАМАЗа» или «Новатэк-а». Моё мнение – это требование второстепенно: все проекты уникальны, а сильная экосистема и опытный интегратор легко компенсируют отсутствие ранее успешных внедрений в сопоставимых по масштабу предприятиях.
Важная оговорка: на этапе внедрения в проекте обязательно должен участвовать специалист — со стороны интегратора или конечного заказчика, — глубоко понимающий технологии и бизнес-процессы вашего предприятия.
- Дорожная карта продукта
Наличие и последовательная реализация планов развития продукта, его функционала или отдельных модулей — признак устойчивости компании и сигнал к долгосрочному партнёрству, если эти планы соответствуют вашим ожиданиям от системы в перспективе. Крупные мировые вендоры направляют на R&D (Research & Development) до 50% и более от прибыли.
- Технологические партнёрства
Коллаборации вендора с другими производителями ПО - важный критерий с точки зрения встраивания вашего проекта в общий ИТ-ландшафт предприятия: взаимодействие со смежными корпоративными системами, оборудованием других производителей, а также выполнение требований внутренних и внешних регуляторов — например, в части резервного копирования данных и информационной безопасности.
Модели работы вендора: на что обращать внимание
Следование перечисленным критериям, как правило, приводит к производителям с историей на рынке и проверенной экосистемой — а значит, снижает риски при реализации вашего проекта. Тем не менее на практике встречаются и другие модели работы с вендором.
Вендор как главный интегратор
Этот этап проходит любой «начинающий» вендор, и некоторые задерживаются в нём надолго — причин может быть много. Да, в такой модели ПО будет дорабатываться «на ходу» специально под вас. Но заказчику стоит заранее задать себе вопрос: что произойдёт, если у этой компании что-то пойдёт не так? Или она получит более платёжеспособного клиента, а ресурсы — как всегда — ограничены? На середине внедрения проекта конкуренция за внимание вендора уже может не работать в вашу пользу.
Вендор как заказчик ПО для собственных нужд
Сегодня как в России, так и за рубежом встречаются заказчики, разрабатывающие ПО «под себя» — нередко на базе платформы какого-либо вендора. Иногда в результате таких проектов рождается новый отраслевой продукт. Однако, на мой взгляд, коллаборация вида «заказчик (отраслевая экспертиза) + поддержка и разработка от вендора» крайне сложна при тиражировании решения на аналогичные отраслевые предприятия — зачастую конкурентов первоначального заказчика. У зарубежных производителей это работает, но требует серьёзной команды delivery со стороны вендора. В России такие решения пока остаются «привязанными» к одному клиенту и с трудом поддаются масштабированию.
Роль дистрибьютора ПО
Нам часто задают вопрос: а зачем вообще нужен дистрибьютор? Профессиональный дистрибьютор — это прежде всего партнёр по продвижению ПО производителя на рынке промышленной автоматизации.
Для производителей: продвижение продукта и информирование потенциальных заказчиков о его преимуществах; включение ПО в проектную документацию на ранней стадии; проведение пилотов и тестирование продукта; поставка и логистика; профессиональная техническая поддержка уровней L1/L2 для системных интеграторов и конечных заказчиков.
Для системных интеграторов: генерация лидов и привлечение к проектам; регистрация проектов согласно коммерческой политике вендора; финансовое «плечо»; обучение и техническая поддержка специалистов.
Для конечных заказчиков: помощь в выборе оптимальных архитектур по ТЗ; поддержка в миграции с иностранного ПО; консультирование по продлению жизненного цикла существующих решений; обучение и техническая поддержка уровней L1/L2.
Надеюсь, материал оказался полезным. Пишите в комментариях, если хотите продолжения: в следующих статьях можем разобрать перечисленные критерии применительно к конкретным вендорам — лидерам российского рынка АСУ ТП и диспетчеризации.
Об авторе: Алексей Амиров — эксперт с многолетним опытом в продажах и развитии партнёрских экосистем SCADA-систем. Ранее отвечал за развитие партнёрской сети одного из мировых лидеров SCADA в РФ. В настоящее время — дистрибьютор ведущих российских производителей систем диспетчеризации и SCADA.