Защищенное облако для учреждения: тарифы и требования

16рекомендаций↓12комментариев~12мин чтения

Задать вопрос

Что выбрать учреждению под запрос защищенное облако?

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

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

Ситуация учреждения	Что выбирать первым	Что проверить до заявки	Когда переходить к КП
Нужны кадровые личные дела, приказы и отчеты	Ведомственную кадровую систему	Штатное расписание, роли, структуру организаций	После проверки демо на реальных кадровых документах
Нужен внутренний портал для сотрудников	Портал с ролями и хранилищем	Пользователей, группы, файлы, уведомления	После оценки нагрузки и прав доступа
Нужны электронные кадровые документы	КЭДО внутри ведомственной системы	ЭП, статусы, архив, выгрузку подписанных файлов	После теста маршрута подписания
Нужен только сервер или место под сайт	Инфраструктурное облако	ОС, резервные копии, сеть, администрирование	После расчета ресурсов и SLA

Когда подходит Контур.Гособлако?

Контур.Гособлако подходит, когда учреждению нужна не отдельная программа для одной операции, а связанная система управления данными: кадровый учет, портал, отчеты, проверки, согласования и электронные кадровые документы. По официальному описанию решение размещается на серверах заказчика, работает через веб-интерфейс, использует Linux-среду и PostgreSQL или Postgres Pro, а также допускает интеграции с государственными и ведомственными системами.

Сильная сторона такого класса решений в том, что оно закрывает не один файл или одну таблицу, а порядок работы учреждения: кто видит данные, кто утверждает документ, где лежит архив, как строится отчет и как данные проходят между локальными системами. Если нужна обычная коммерческая HRM для малого бизнеса, такой контур будет избыточным; если есть ведомственная структура и подведомственные организации, обычная HRM часто не выдерживает требований.

Признак	Почему это важно	Что спросить у поставщика	Риск без проверки
Размещение на серверах заказчика	Учреждение контролирует инфраструктуру и доступ	Какая ОС, СУБД, схема резервного копирования	КП не совпадет с реальной инфраструктурой
Веб-интерфейс	Не нужно ставить клиент на каждое рабочее место	Какие браузеры и разрешение поддерживаются	Пользователи не смогут работать на старых местах
Кадровое ядро	Личные дела и приказы становятся основой данных	Какие документы и отчеты есть из коробки	Доработки появятся уже на старте
Интеграции	Данные не должны вручную переноситься между системами	API, СМЭВ, ЕСИА, форматы обмена	Будут дубли, ошибки и ручная сверка

Когда нужен не Гособлако, а инфраструктурное облако?

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

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

Что хочет заказчик	Класс решения	Как считать цену	Что будет ошибкой
Разместить сайт учреждения	Защищенный хостинг или IaaS	Виртуальные ресурсы, канал, администрирование	Покупать кадровую платформу вместо хостинга
Хранить резервные копии	Облачное хранилище или резервный контур	Объем, срок хранения, восстановление	Считать только лицензию без восстановления
Вести кадры и портал	Ведомственная прикладная система	Модули, пользователи, внедрение, сопровождение	Сравнивать с ценой обычного VPS
Связать несколько учреждений	Платформа с ролями и интеграциями	Организации, справочники, обмены, SLA	Покупать локальную программу без архитектуры

Какие тарифы считать перед заявкой?

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

Минимальный запрос к поставщику: базовый модуль, расширенный модуль, пользователи, серверные требования, обучение, перенос данных, доработки, сопровождение и срок запуска. Если поставщик дает только общую сумму без состава работ, учреждение не сможет сравнить варианты и принять работу по факту.

Строка сметы	Что в нее входит	Как проверить	Когда брать выше
Лицензии или доступ	Модуль и число пользователей	Сверить роли и активных пользователей	При росте организаций или портала
Внедрение	Настройка структуры, ролей, шаблонов	Попросить план работ и приемку	При сложной структуре ведомства
Миграция данных	Справочники, сотрудники, документы	Проверить тестовую загрузку	При старой базе и дублях
Интеграции	API, учетные системы, госсистемы	Запросить схему обмена	При обязательном обмене без ручного ввода

Матрица требований

Соберите профиль защищенного облака

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

Тип заказчика

АдминистрацияОрган власти УчреждениеШкола, МБУ, МАУ МедицинаКадры и ресурсы РегионМного организаций

Первый модуль

КадрыЛичные дела, приказы ПорталСотрудники, новости КЭДОПодписание документов КонтрольКоррупция, закупки

Пользователи

До 200Пилот или одно учреждение До 3 тыс.Ведомственный портал До 10 тыс.Крупная сеть Свыше 10 тыс.Региональная модель

Размещение

У заказчикаСерверы учреждения Защищенный контурОтдельная площадка ГибридЧасть систем локально

Интеграции

Без интеграцийРучной старт Учетная система1С или ведомственная ГоссистемыСМЭВ, ЕСИА, реестры

Первый пакет кадровое ядро

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

Тариф считать по модулям и пользователям

Инфраструктура Linux, PostgreSQL, резервное копирование

ИБ-требование роли, журнал, регламент доступа

Интеграция импорт справочников

Проверка перед оплатой

Попросите демо на реальных ролях: кадровик, руководитель, администратор, сотрудник.

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

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

Какие требования к серверам проверить?

Технические требования нельзя оставлять на конец. По справочным материалам Гособлака для разных подсистем проверяются сервер баз данных, сервер приложений, дисковое пространство, память, процессоры, Linux-окружение, PostgreSQL и сетевое подключение. Для портала на тысячи пользователей требования выше, чем для одиночного кадрового контура.

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

Компонент	Что спросить	Почему это влияет на цену	Что указать в КП
Сервер баз данных	CPU, RAM, диск, СУБД, резервирование	Хранит основные данные и отчеты	Версию PostgreSQL или Postgres Pro, объем и рост
Сервер приложений	CPU, RAM, ОС, обновления	Обслуживает пользователей и модули	Число пользователей и модулей
Сеть	Канал, сегменты, доступ администраторов	Влияет на скорость и безопасность	Схему доступа и ограничения
Рабочие места	Браузеры, разрешение, офисный пакет	Ошибки видны уже у пользователей	Минимальные требования к ПК

Как оценить число пользователей и нагрузку?

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

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

Группа пользователей	Как работает	Что влияет на нагрузку	Как считать
Кадровики	Создают документы и ведут личные дела	Отчеты, приказы, выборки	По фактическим рабочим местам
Руководители	Согласуют и смотрят отчеты	Маршруты согласования	По подразделениям и полномочиям
Сотрудники	Заходят в портал или КЭДО	Массовые уведомления и файлы	По активным личным кабинетам
Администраторы	Настраивают роли и справочники	Права, журналы, обновления	По зонам ответственности

Какие модули включать в первый пакет?

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

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

Модуль	Когда нужен сразу	Что проверить на демо	Что не покупать вслепую
Кадровый учет	Есть личные дела, приказы, отчеты	Приказ, личное дело, выборка	Индивидуальные доработки без пилота
Портал	Нужны новости, файлы, обращения	Поиск сотрудника, уведомления, права	Большое хранилище без оценки файлов
КЭДО	Нужно подписывать кадровые документы	Подпись, статус, архив, выгрузка	Массовый запуск без регламента
Контроль и проверки	Есть коррупционные и закупочные сценарии	Загрузка данных, отчет, журнал	Блок без владельца процесса

Какие требования по безопасности включить в КП?

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

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

Требование	Как сформулировать	Как принять	Риск
Роли и права	Доступ по должности и функции	Проверить на тестовых пользователях	Лишний доступ к кадровым данным
Журнал действий	Фиксация входов и операций	Показать отчет по действиям	Нельзя расследовать ошибку
Резервное копирование	Периодичность и срок хранения	Выполнить тест восстановления	Данные есть только на бумаге в договоре
Обновления	Порядок установки и окно работ	Получить регламент	Срыв работы в отчетный период

Как проверить интеграции с госсистемами?

Интеграции надо проверять не словами, а маршрутом данных. Для ведомственной системы важно понять, откуда берутся справочники, куда выгружается отчет, какая система считается источником истины, кто исправляет ошибки и где виден протокол обмена. Если интеграция заявлена через СМЭВ, ЕСИА, API или ведомственный формат, попросите схему, тестовый сценарий и ограничения.

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

Интеграция	Что проверить	Документ для КП	Приемка
Учетная система	Справочники, сотрудники, должности	Формат обмена и владелец данных	Тестовая загрузка без дублей
ЕСИА	Авторизация и роли	Схема подключения	Вход тестового пользователя
СМЭВ	Маршрут, статусы, протоколы	Описание сервиса обмена	Успешный тестовый обмен
Ведомственный реестр	Поля, периодичность, ошибки	Таблица соответствия данных	Протокол сверки

Какие документы запросить у поставщика?

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

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

Документ	Что должно быть внутри	Зачем нужен	Когда запросить
Функциональное описание	Модули, роли, процессы, ограничения	Понять, закрывает ли задачу	До выбора поставщика
Технические требования	Серверы, ОС, СУБД, браузеры	Оценить готовность инфраструктуры	До расчета сметы
План внедрения	Этапы, сроки, ответственные	Не сорвать запуск	До договора
Критерии приемки	Что считается готовой работой	Не спорить после внедрения	До оплаты этапа

Матрица выбора решения

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

Если в таблице получается больше половины пунктов про модули, роли и документы, вам нужна прикладная ведомственная система. Если большинство пунктов про CPU, RAM, диски и сеть, сначала выбирайте инфраструктурную площадку.

Задача	Решение	Обязательный тест	Коммерческий вывод
Кадры органа власти	Гособлако или аналогичная ведомственная система	Личное дело, приказ, отчет	Запрашивать модуль кадров и внедрение
Портал сотрудников	Портальный модуль	Пользователь, группа, файл, уведомление	Считать активных пользователей
КЭДО	Кадровый ЭДО внутри системы	Подписание и архив	Считать ЭП, маршруты и хранение
Серверы и сайт	IaaS или защищенный хостинг	Развертывание и восстановление	Считать ресурсы и администрирование

Тарифная модель без рекламных цифр

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

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

Параметр	Низкая сложность	Средняя сложность	Высокая сложность
Организации	Одно учреждение	Несколько подведомственных	Региональная сеть
Пользователи	До 200	До 3 тыс.	10 тыс. и больше
Модули	Кадровое ядро	Кадры плюс портал	Кадры, КЭДО, контроль, интеграции
Интеграции	Импорт Excel	Учетная система	СМЭВ, ЕСИА, ведомственные реестры

Техническое задание для закупки

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

Не пишите в ТЗ только “защищенное облако для учреждения”. Эта формулировка слишком широкая. Напишите, какие процессы будут автоматизированы: кадровый учет, портал, КЭДО, отчеты, проверки, обмен с системами, хранение документов и администрирование.

Раздел ТЗ	Что описать	Проверка	Ошибка
Функции	Модули и сценарии работы	Демо по каждому сценарию	Общее описание без процессов
Пользователи	Роли и число активных пользователей	Тестовые учетные записи	Считать всех одной ролью
Инфраструктура	Серверы, ОС, СУБД, сеть	Сверка с ИТ-службой	Оставить требования поставщику после договора
Приемка	Критерии готовности и протоколы	Акт по этапам	Принимать по факту установки

Пилот и приемка

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

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

Этап пилота	Что сделать	Критерий готовности	Кто принимает
Подготовка данных	Загрузить структуру и сотрудников	Нет дублей и пустых обязательных полей	Кадры и ИТ
Роли	Создать пользователей разных уровней	Каждый видит только свое	Ответственный за ИБ
Документ	Провести приказ или заявление	Есть статус, файл и архив	Кадровик
Отчет	Построить выборку	Данные совпали с контрольной выгрузкой	Руководитель процесса

Ошибки выбора

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

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

Ошибка	Как выглядит	Последствие	Как исправить
Сравнили разные решения	VPS против ведомственной системы	Цена кажется завышенной или заниженной	Разделить инфраструктуру и приложение
Не посчитали пользователей	В смете только учреждение	Не хватает лицензий или ресурсов	Считать роли и активность
Не проверили миграцию	Старые данные оставили потом	Ручной перенос и дубли	Сделать тестовую загрузку
Не описали приемку	Система установлена, но процессы не работают	Спор по договору	Фиксировать критерии до оплаты

Решение для учреждения

Если учреждению нужно защищенное облако как прикладная ведомственная система, первый рабочий выбор — запросить демонстрацию и расчет по кадровому ядру, порталу, КЭДО или контрольному модулю с учетом числа пользователей, организаций, размещения и интеграций. В таком запросе Контур.Гособлако имеет смысл рассматривать как профильное решение для государственного и муниципального сектора.

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

Вывод	Что делать сейчас	Что запросить	Когда покупать
Нужна ведомственная система	Собрать процессы и пользователей	Демо, КП, техтребования, план внедрения	После пилота и критериев приемки
Нужен портал	Описать пользователей и контент	Расчет портала и хранилища	После теста ролей и уведомлений
Нужен КЭДО	Описать документы и подписантов	Маршрут подписи и архив	После проверки ЭП и выгрузки
Нужен только сервер	Считать IaaS и администрирование	Ресурсы, резерв, SLA	После теста восстановления