Как крупной компании выбрать SaaS-платформу и не ошибиться с поставщиком

SaaS-платформа стабильно работает у крупной компании лишь при трех условиях: процесс поддается стандартизации, данные и интеграции остаются под контролем, а поставщик гарантирует отказоустойчивость, предоставляет зрелый договорной SLA и прозрачную статистику аптайма. SaaS — модель поставки программного обеспечения, при которой инфраструктуру и приложение эксплуатирует поставщик, а заказчик получает доступ по подписке. Перед выбором решения стоит проверить семь параметров: полную стоимость владения (TCO), модель размещения, требования к данным, API, соглашение об уровне обслуживания (SLA), сценарий выхода из сервиса и функциональность.

С помощью SaaS закрывают стандартизируемые функции: совместную работу, CRM, HR-процессы, управление проектами, аналитику, сервисное обслуживание. Полной заменой ИТ-ландшафта компании SaaS не становится. Для процессов с высокой регуляторной или операционной спецификой обычно нужна выделенная модель размещения или внутренняя разработка.

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

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

Композируемую архитектуру выбирают, если компании нужно сочетать совместимые компоненты, а не искать единую платформу под все сценарии сразу. Модульный подход сравнивают с единой платформой по требованиям к интеграциям, данным и управлению изменениями. Gartner называет модульную архитектуру одним из вероятных векторов развития корпоративных ИТ-систем. Это не универсальная норма закупки, но ориентир при проектировании: компоненты собирают из совместимых частей, а не подбирают один сервис «под все».

Многопользовательская модель, multi-tenant, — это размещение, при котором несколько заказчиков используют общую инфраструктуру SaaS при логическом разделении данных и доступа. Выделенная модель, single-tenant, закрепляет ресурсы приложения или инфраструктуры за одним заказчиком.

Multi-tenant закрывает задачи, где важнее стандартизация и единый цикл обновлений. Single-tenant рассматривают, когда требования к изоляции и размещению данных не позволяют использовать общую инфраструктуру.

Поставщик в модели multi-tenant развивает единый продукт сразу для многих клиентов. В single-tenant заказчик получает больше изоляции, но берет на себя больше эксплуатационных обязательств. Итоговый TCO зависит именно от модели инфраструктуры и объема сопровождения.

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

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

В тех же оценках приведены доли поставщиков инфраструктуры: Cloud.ru (32,5%), РТК-ЦОД (13,7%), Yandex Cloud (11%), Selectel (7,1%), MWS (5%). Эти цифры относятся только к рынку инфраструктуры, качество конкретной SaaS-платформы они не определяют.

TCO, полная стоимость владения, включает подписку и затраты на внедрение. Отдельно считают интеграции, сопровождение, обучение, управление данными и выход из сервиса. Для проектов от 5 млн ₽ расчет TCO на три года обычно делают до подписания договора; конкретную глубину расчета определяют интеграции, миграция и срок использования платформы.

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

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

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

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

Пилот показывает, справится ли SaaS с реальным циклом проекта: продажа, планирование, исполнение, учет трудозатрат, документы, финансовый результат. Тестовый сценарий должен воспроизводить рабочий процесс на тестовых или обезличенных данных.

Порядок действий такой. Сначала описывают 5—7 обязательных сценариев: отдельно фиксируют планирование и исполнение проекта — план, загрузку команды, задачи, а также работу с документами, согласованиями, учетом часов и маржинальностью и интеграции с CRM, документооборотом, финансовой системой, SSO и системой управления задачами. Затем сравнивают 3—5 SaaS-платформ по единой матрице и проводят пилот с измеримыми критериями: полнотой данных, временем создания проекта, экспортом отчета. Расчет TCO делают минимум на три года, а условия выхода из SaaS согласуют до подписания договора.

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

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

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

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

Перед подписанием договора стоит закрыть три блока вопросов.

1. Договорные условия: юридическое лицо, подписывающее договор, SLA и исключения из него, ответственность субподрядчиков поставщика.

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

3. Эксплуатационные процедуры: порядок реагирования на инциденты, результаты теста восстановления.

Формулировка «безопасность обеспечивается» критерием не считается: она не содержит ни одного проверяемого обязательства поставщика. Документально подтвержденные процедуры контроля нужны независимо от уровня доверия к поставщику.

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

При запуске отдельно определяют владельца бизнес-процесса, ИТ-владельца и ответственного за данные: это три разные роли. Далее данные для миграции очищают и классифицируют, а роли, SSO и журналы действий настраивают до старта пилота.

Пилот проводят на ограниченной группе пользователей. После подтверждения результатов фиксируют решение о дальнейшем использовании SaaS и постепенно расширяют его применение.

Результатом пилота вполне может стать решение не внедрять SaaS вовсе. Это позволяет избежать расходов и потерь времени до того, как компания попадет в зависимость от поставщика.

Кто должен принимать окончательное решение о выборе SaaS-платформы?

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

Подходит ли SaaS для процессов с высокими регуляторными требованиями?

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

Что подтверждает готовность поставщика к работе с чувствительными данными в multi-tenant?

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

Как рассчитать TCO для проекта с бюджетом до 5 млн ₽?

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

Сколько SaaS-платформ стоит сравнивать перед выбором?

Для большинства корпоративных сценариев достаточно 3—5 платформ, сравненных по единой матрице критериев. Меньшее число ограничивает выбор, большее увеличивает нагрузку на пилотирование без ощутимого прироста качества решения.