Облачная LMS или система на сервере компании

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

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

Как устроена облачная LMS

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

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

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

Как устроена коробочная LMS

Коробочная, или on-premise LMS, разворачивается на сервере клиента либо в выделенной для него инфраструктуре. Компания контролирует серверный доступ и может связать приложение с внутренними системами по согласованной схеме.

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

Модель размещения и модель лицензии — разные вещи. Коробочная LMS может требовать ежегодных платежей, а условия разовой лицензии всегда нужно читать в договоре.

Сравните контроль над данными

До выбора зафиксируйте требования компании:

• где физически размещается приложение;
• кто имеет административный доступ;
• где хранятся резервные копии;
• как регистрируются действия администраторов;
• как удаляются и выгружаются данные;
• какие внутренние политики нужно выполнить.

Сервер клиента даёт больше организационного контроля над размещением, но безопасность зависит от качества всей инфраструктуры и регламентов. Сам факт установки «у себя» не заменяет обновления, резервирование и управление доступами.

Разделите ответственность за эксплуатацию

Составьте простую матрицу ответственности между компанией и поставщиком. В неё полезно включить:

• доступность сервера и операционной системы;
• продление домена и TLS-сертификата;
• резервное копирование и проверку восстановления;
• мониторинг свободного места и ресурсов;
• установку обновлений приложения;
• диагностику интеграций;
• обработку обращений пользователей.

Формулировки «техническая поддержка включена» недостаточно. Нужны каналы обращения, границы работ, сроки реакции и порядок оценки доработок.

Сравните модель расходов

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

Нельзя заранее утверждать, какая модель дешевле. Итог зависит от срока расчёта, количества пользователей, имеющейся инфраструктуры и объёма дополнительных работ. Сравнивайте варианты по одинаковому периоду и составу результата — методика есть в статье о TCO корпоративной LMS.

Проверьте ограничения пользователей

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

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

Учтите интеграции

Серверное размещение может упростить доступ к внутренним источникам, но не создаёт интеграцию автоматически. Для каждого обмена нужно определить:

• источник сотрудников и подразделений;
• способ входа;
• направление и периодичность синхронизации;
• сетевые доступы;
• владельца данных;
• обработку ошибок.

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

Когда чаще выбирают облако

Облачную модель обычно рассматривают, если:

• важен быстрый стандартный запуск;
• нет требования размещать приложение внутри инфраструктуры компании;
• команда не планирует администрировать сервер;
• устраивают тариф и правила эксплуатации поставщика;
• глубокие внутренние интеграции не нужны на первом этапе.

Когда рассматривают сервер клиента

On-premise LMS подходит для рассмотрения, когда:

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

Последний пункт не является свойством всех серверных систем — его проверяют отдельно.

Вопросы поставщику до договора

1. Где будет работать приложение и храниться резервная копия?
2. Кто устанавливает и проверяет обновления?
3. Какие требования предъявляются к серверу?
4. Как выгрузить пользователей, материалы и результаты?
5. Как считаются пользователи и дополнительные модули?
6. Что входит в поддержку, а что считается новой работой?
7. Как выглядит восстановление после сбоя?
8. Какие интеграции уже готовы, а какие требуют разработки?

«Фаза данных» разворачивается на сервере клиента. Разовая лицензия стоит 790 000 ₽, не требует обязательного ежегодного продления и не ограничивает число пользователей. Требования, возможности и отдельно оцениваемые работы опубликованы на странице обучающей платформы.