Программа SPLA позволяет провайдеру предоставлять клиентам программное обеспечение Microsoft вместе со своей услугой: например, размещать приложения на сервере и давать заказчику доступ к ним по подписке. В статье разберём, кому подходит такая модель, какие данные подготовить для расчёта лицензий, чем SPLA отличается от обычной закупки и где чаще всего возникают ошибки. Это поможет собрать рабочую схему до обсуждения условий с поставщиком.
Что такое SPLA и кому нужна эта модель?
SPLA расшифровывается как Services Provider License Agreement. Это программа лицензирования Microsoft для поставщиков услуг. Провайдер получает право использовать определённые продукты Microsoft в собственной инфраструктуре и предоставлять их конечным клиентам как часть сервиса.
Такой подход подходит компаниям, которые управляют серверами, виртуальными машинами или облачной средой для других организаций. Например, провайдер размещает бизнес-приложение клиента на Windows Server, предоставляет удалённый доступ к рабочему столу или включает серверные компоненты Microsoft в ежемесячную услугу.
Ключевой признак SPLA — клиент пользуется программой через услугу провайдера. Провайдер отвечает за инфраструктуру, доступ и расчёт лицензий в рамках выбранной модели. Клиент при этом не получает универсальное право установить купленную копию продукта на любой собственный компьютер.
Актуальные варианты лицензирования и материалы программы Microsoft публикует в разделе для поставщиков услуг. При подготовке договора нужно сверять именно действующие условия, потому что перечень продуктов, правила отчётности и доступные варианты могут меняться.
Чем SPLA отличается от покупки лицензий клиентом?
При обычной закупке организация приобретает лицензии для собственной инфраструктуры. При SPLA провайдер лицензирует сервис, который он предоставляет клиентам. Поэтому сначала нужно описать услугу, а уже затем подбирать состав лицензий.
| Вопрос | Покупка лицензий для своей компании | SPLA для поставщика услуг |
|---|---|---|
| Кто использует ПО? | Организация, которая купила лицензии | Клиенты провайдера через его сервис |
| Где работает ПО? | В инфраструктуре владельца лицензий или в согласованной среде | В инфраструктуре поставщика услуги |
| Как планируется потребность? | По числу пользователей, устройств или серверов компании | По объёму услуги и клиентскому использованию |
| Как меняется объём? | Через отдельную закупку или изменение лицензирования | Через регулярный пересмотр фактического объёма сервиса |
| Кому вести учёт? | Владельцу лицензий | Провайдеру, который рассчитывает и подтверждает использование |
Сравнивать эти модели только по цене одной лицензии бессмысленно. В SPLA в расчёт попадают также администрирование, резервное копирование, поддержка, виртуализация, безопасность и подготовка регулярной отчётности. Если компания сама использует Microsoft внутри офиса, ей может быть ближе обычная корпоративная закупка или облачная модель. Для такого сравнения полезно изучить Microsoft Cloud Solution Provider в 2026 году.
Какие лицензии нужно посчитать до запуска сервиса?
Начните с инвентаризации. Запишите, какие продукты реально работают в услуге, где они размещены и кто получает доступ. Название сервера само по себе не даёт ответа: для расчёта важны роль продукта, способ доступа и условия конкретной программы.
- Составьте список продуктов Microsoft, которые входят в сервис.
- Отдельно укажите физические серверы, виртуальные машины и тестовые среды.
- Посчитайте клиентов, пользователей и устройства по каждому сервису.
- Зафиксируйте, какой доступ получает клиент: к приложению, серверу, рабочему столу или отдельной функции.
- Разделите постоянных пользователей, временный доступ и внутренние учётные записи сотрудников.
- Опишите, какие компоненты провайдер предоставляет сам, а какие принадлежат клиенту.
Полезно вести таблицу с четырьмя колонками: клиент, услуга, используемый продукт и основание для расчёта. В отдельном поле укажите период, к которому относится количество пользователей или устройств. Тогда изменение тарифа или состава сервиса не потеряется в переписке.
Если провайдер предлагает удалённый рабочий стол, нужно отдельно проверить серверную часть, права доступа и фактическое число пользователей. Если он размещает приложение клиента, следует разделить лицензирование платформы и самого приложения. Такой разбор лучше делать до публикации коммерческого предложения.
Как организовать учёт и ежемесячную отчётность?
SPLA требует дисциплины в учёте. Провайдеру нужно понимать, сколько лицензируемых ресурсов он использовал за отчётный период и какие клиенты получали доступ. Для этого недостаточно один раз посмотреть список виртуальных машин.
Назначьте владельца реестра лицензий. Это может быть сотрудник закупок, системный администратор или руководитель направления, но зона ответственности должна быть закреплена внутри компании. Технические данные и коммерческие договоры должны совпадать: если клиент отключил услугу, запись о его доступе должна измениться в том же периоде.
- Зафиксируйте исходную конфигурацию сервиса и перечень продуктов.
- Свяжите каждую услугу с конкретным клиентом и договором.
- Ежемесячно сверяйте активные учётные записи, виртуальные машины и доступы.
- Сохраняйте историю изменений: подключение, приостановка, расширение и отключение услуги.
- Перед отчётностью проверяйте расхождения между технической системой и реестром продаж.
Для небольшой компании достаточно начать с контролируемой таблицы и понятных правил обновления. Когда клиентов становится больше, данные обычно переносят в систему управления инфраструктурой или внутренний учётный инструмент. Главное, чтобы из записи было видно, почему выбран именно такой объём лицензирования.
Как подготовиться к оформлению SPLA в 2026 году?
Подготовка начинается с описания бизнес-модели, а не с выбора случайного набора продуктов. Провайдеру нужно объяснить, какую услугу он продаёт, где она работает, кто получает доступ и как меняется число пользователей. Чем точнее описание, тем меньше риск получить неподходящую схему.
Подготовьте краткий профиль компании: инфраструктура, типы клиентов, география предоставления услуги, используемые продукты и планируемый объём. Отдельно укажите, нужны ли клиентам выделенные серверы, общая среда или виртуальные рабочие места. Эти сведения пригодятся при обсуждении доступных вариантов с партнёром по лицензированию.
До подписания документов проверьте несколько пунктов:
- входит ли нужный продукт в программу для поставщиков услуг;
- как определяется лицензируемая единица: пользователь, устройство, сервер или другой параметр;
- какие правила действуют для тестовых и резервных сред;
- как провайдер сообщает об изменении объёма использования;
- какие документы подтверждают право предоставлять продукт в составе услуги;
- кто отвечает за проверку данных перед отчётностью.
Не стоит копировать в договор с клиентом формулировки из чужого шаблона. В документе нужно описать именно вашу услугу: что получает заказчик, кто поддерживает инфраструктуру, как меняется количество доступов и какие действия выполняются при завершении обслуживания.
Типичные ошибки при работе с SPLA
- Провайдер считает только серверы и забывает проверить пользовательский или клиентский доступ.
- В реестре лицензий остаются отключённые учётные записи и старые виртуальные машины.
- Тестовая среда используется постоянно, но её не включают в проверку условий программы.
- Коммерческий отдел продаёт услугу, состав которой техническая команда ещё не проверила.
- Компания смешивает собственные лицензии клиента и права, которые провайдер предоставляет в рамках своей услуги.
- Объём использования фиксируют в конце периода вручную, без истории изменений.
Для каждой ошибки помогает простой контрольный вопрос: кто, где, когда и на каком основании получил доступ к продукту. Если на него нельзя ответить по реестру и договору, схему лицензирования рано считать готовой.
3 шага, которые можно сделать на этой неделе:
- Составить перечень сервисов, в которых используется ПО Microsoft, и привязать их к клиентам.
- Сверить технические доступы с договорами и убрать записи об отключённых услугах.
- Передать партнёру по лицензированию описание инфраструктуры и получить подтверждение подходящей модели SPLA для каждого сервиса.
