SaaS-платформа подходит крупной компании при трех условиях: типовой процесс поддается стандартизации, данные и интеграции остаются под контролем, а поставщик подтверждает надежность договором и эксплуатационными фактами, а не обещаниями. Корпорацией в этой статье называется компания с несколькими подразделениями, сложными интеграциями и отдельными требованиями к данным. SaaS — модель поставки программного обеспечения. Поставщик эксплуатирует приложение и инфраструктуру, заказчик получает доступ по подписке. При оценке решения важны семь параметров: полная стоимость владения (TCO), модель размещения, требования к данным, API, соглашение об уровне обслуживания (SLA), сценарий выхода из сервиса и функциональность, подтвержденная на демонстрации.
SaaS в корпоративной ИТ-архитектуре
С помощью SaaS реализуют стандартизируемые функции: совместную работу, CRM, HR-процессы, управление проектами, аналитику, сервисное обслуживание. Полной заменой ИТ-ландшафта компании SaaS не становится. Для уникальных процессов с высокой регуляторной или операционной спецификой чаще нужна выделенная модель или внутренняя разработка.
SaaS-платформой называют готовую облачную программу, которой пользователи управляют через браузер: она поддерживает несколько связанных бизнес-сценариев, роли пользователей, интеграции и управление данными. Это не любой облачный продукт и не синоним конкретной CRM или ЭДО-системы.
При использовании SaaS архитектурные решения оценивают по трем направлениям.
- Готовность типового функционала и качество интеграций определяют скорость запуска.
- Размещение данных, разграничение доступа и правила резервного копирования формируют уровень контроля.
- Стоимость эксплуатации складывается из подписки, доработок и объема внутренней поддержки.
Композируемую архитектуру рассматривают, когда компании требуется сочетать совместимые компоненты вместо единой платформы. Модульную архитектуру стоит сравнивать с единой платформой по требованиям к интеграциям, данным и управлению изменениями. В прогнозах Gartner модульная архитектура рассматривается как один из вероятных векторов развития корпоративных ИТ-систем. Это не универсальная норма закупки, однако при модульном проектировании архитектуру собирают из совместимых компонентов, а не пытаются найти один сервис «на все».
В российской практике крупные компании часто сочетают внешние SaaS-сервисы с собственной ИТ-инфраструктурой. Так проще сохранить контроль над критическими данными и соответствовать регуляторным требованиям. Это значит, что корпорация не обязана выбирать что-то одно: внешний SaaS и собственная платформа могут работать вместе.
Как SaaS влияет на корпоративные бизнес-процессы
При использовании SaaS бизнес-процессы меняются благодаря стандартизации операций. Отдельно на процесс влияют единые данные и сокращение цикла изменений. Эффект появляется после пересмотра ролей, маршрутов согласования и метрик процесса; включения лицензий для этого недостаточно.
При ограничении произвольных доработок срок выполнения процесса при использовании SaaS сокращается. Это полезно, если компания готова принять стандартный маршрут. Иначе срок внедрения увеличивается из-за очереди на доработку.
Возможна обратная ситуация: после покупки сервиса для управления заявками команда сохраняет пять параллельных таблиц, и Excel продолжает использоваться как система учета.
Как выбрать SaaS для автоматизации проектной работы
Для автоматизации проектной работы SaaS выбирают по реальному циклу проекта: продажа, планирование, исполнение, учет трудозатрат, документы, финансовый результат. Пилот должен воспроизводить рабочий сценарий на тестовых или обезличенных данных.
Мини-алгоритм выбора:
Сначала следует описать 5—7 обязательных сценариев. Отдельно фиксируют сценарии планирования и исполнения проекта: план проекта, загрузку команды и задачи. Затем требуется зафиксировать работу с документами, согласованиями, учетом часов и маржинальностью, а также интеграции с CRM, документооборотом, финансовой системой, SSO и системой управления задачами.
После этого сравнивают 3—5 SaaS-платформ по единой матрице. Для кандидатов проводят пилот с измеримыми критериями: например, полнотой данных, временем создания проекта и экспортом отчета.
Расчет TCO выполняют минимум на три года. Условия выхода из SaaS согласуют до подписания договора.
Во время демонстрации затруднения могут не возникнуть, но результаты следует подтверждать на рабочем сценарии с фактическими ролями и обезличенными либо тестовыми данными. Критерием пилота должна быть успешная обработка сценария в заданное время и корректный экспорт отчета.
Как оценивать SaaS-платформы для корпорации без рейтингов
Корпоративную SaaS-платформу следует оценивать по соответствию конкретному классу задач, требованиям к данным и способности встроиться в ИТ-ландшафт. Востребованность категории не равна применимости отдельного SaaS-решения.
Широкий функционал может сократить число используемых систем. Но это работает только, если владелец процесса готов отказаться от локальных исключений. Иначе универсальная платформа становится дорогим конструктором.
Критерии выбора поставщика SaaS для корпорации
Поставщик SaaS оценивается по способности выполнять договорные и технологические обязательства на всем сроке использования SaaS. По критериям платформы оценивают соответствие функциональности, а по критериям поставщика — возможность доверить ему эксплуатацию.
Отдельно следует уточнить, кто отвечает за инцидент, кто уведомляет заказчика и в какой срок. Формулировка «безопасность обеспечивается» — не критерий. Такая формулировка не содержит проверяемых обязательств поставщика.
Многопользовательская и выделенная модели SaaS для корпораций
Многопользовательская модель (multi-tenant) — это модель, в которой несколько заказчиков используют общую инфраструктуру SaaS при логическом разделении данных и доступа. Выделенная модель (single-tenant) — это модель размещения, при которой ресурсы приложения или инфраструктуры выделены одному заказчику.
Multi-tenant подходит при приоритете стандартизации и единого цикла обновлений. Single-tenant рассматривают, если требования к изоляции и размещению данных ограничивают применение общей инфраструктуры.
В модели Multi-tenant поставщик развивает единый продукт для многих клиентов. В модели single-tenant заказчик получает больше изоляции, но и больше эксплуатационных обязательств. От модели инфраструктуры и объема сопровождения зависит TCO.
Как сравнить стоимость владения SaaS
TCO — это полная стоимость владения SaaS. TCO включает подписку и затраты на внедрение. Отдельно учитывают интеграции, сопровождение, обучение, управление данными и выход из сервиса. Для проектов с бюджетом от 5 млн ₽ расчет TCO обычно выполняют до подписания договора; потребность в нем уточняют с учетом интеграций, миграции и срока использования.
Прямые расходы бюджета складываются из стоимости подписки. Из-за трудозатрат внутренней команды и подрядчиков TCO интеграций растет. Расходы на выход из сервиса следует включать в стоимость проекта на всем жизненном цикле.
Требования к корпоративным данным и размещению SaaS в России
Требования к корпоративным данным определяют допустимый состав сведений для передачи в SaaS и правила их размещения. Отдельно фиксируют доступ к данным и порядок их возврата после прекращения договора. Требования к данным относятся к обработке информации, а требования к интеграциям — к техническому обмену между системами.
Для России отдельно проверяют применимость требований к персональным данным, договорную роль сторон и фактическую географию размещения. По имеющимся оценкам, мультиоблачность используют 41% компаний. При такой модели повышается гибкость, но усложняется единый контроль прав и журналов.
В тех же оценках указаны доли поставщиков инфраструктуры: Cloud.ru (32,5%), РТК-ЦОД (13,7%), Yandex Cloud (11%), Selectel (7,1%), MWS (5%). Эти данные относятся только к рынку инфраструктуры. Качество конкретной SaaS-платформы требуется оценивать отдельно.
Чек-лист проверки надежности SaaS-поставщика
Надежность поставщика подтверждается документами, эксплуатационными процедурами и проверяемыми обязательствами. Одного публичного описания сервиса недостаточно.
Чек-лист перед договором:
1. Договорные условия: проверить юридическое лицо, подписывающее договор, SLA и исключения из него, а также ответственность субподрядчиков поставщика.
2. Данные: проверить права заказчика на экспорт данных и возможность тестовой выгрузки в согласованном формате.
3. Эксплуатационные процедуры: проверить процедуру реагирования на инциденты и результаты теста восстановления.
Документально подтвержденные процедуры контроля необходимы независимо от уровня доверия к поставщику.
План внедрения SaaS в крупной компании
Внедрение SaaS начинается с владельца процесса и измеримого пилота. Сначала определяют границы первого релиза, затем подключают интеграции и масштабируют решение после подтверждения результата.
При запуске требуется определить владельца бизнес-процесса и ИТ-владельца. Ответственность за данные закрепляют отдельно. Затем следует очистить и классифицировать данные для миграции, а также настроить роли, SSO и журналы действий.
Пилот проводят на ограниченной группе пользователей. После подтверждения результатов фиксируют решение о дальнейшем использовании SaaS и расширяют его применение.
Результатом пилота может стать решение не внедрять SaaS. Такое решение позволяет избежать расходов и потерь времени до возникновения зависимости от поставщика.
FAQ о SaaS-платформах в корпорациях
Почему SaaS становится стандартом в корпоративной среде?
SaaS становится распространенным форматом, поскольку при его использовании сокращается время запуска типовых процессов, а часть инфраструктурной эксплуатации выполняет поставщик. Он становится рабочим стандартом при контроле TCO и данных. Также необходимо проверить интеграции и условия выхода из сервиса.
Что делать, если поставщик SaaS не может подтвердить логическую изоляцию данных при multi-tenant?
Безопаснее не начинать интеграцию, пока поставщик не предоставит описание модели разделения данных, ролей доступа и порядка реагирования на инциденты. При отсутствии такого подтверждения стоит рассмотреть single-tenant или отложить запуск до получения документов.
Можно ли сменить SaaS-поставщика без потери данных при переходе?
Это возможно, если условия выхода зафиксированы в договоре заранее: формат выгрузки, сроки предоставления данных и порядок удаления копий у поставщика. Без таких условий смена поставщика превращается в отдельный проект с непредсказуемыми сроками и затратами.
Обязательно ли считать TCO, если бюджет проекта небольшой?
Для небольших и простых внедрений полный расчет TCO на три года не всегда оправдан. Но интеграции, миграцию данных и затраты на выход из сервиса стоит оценить в любом случае: именно эти статьи чаще всего недооценивают при выборе SaaS.
Есть ли альтернатива выбору между multi-tenant и single-tenant?
Да, часть компаний сочетает внешние SaaS-решения с собственными платформенными компонентами или развивает внутренний SaaS для нестандартных процессов. Выбор конкретной комбинации зависит от того, какие процессы поддаются стандартизации, а какие требуют выделенной модели или внутренней разработки.