Лицензии Microsoft в ТЗ: формулировки для нужных прав

Зачем в ТЗ подробно прописывать лицензии

Если в ТЗ написать просто «Windows» или «Office», поставщик может привезти продукт, который совпадает по названию, но дает другие права. Итог часто неприятный: нельзя обновиться до нужной версии, нельзя легально поставить более раннюю версию для совместимости, нельзя перенести лицензию при замене ПК.

Риски есть у обеих сторон. Заказчик рискует приемкой (комиссия просит подтверждения, а предъявить нечего или документы не подходят), аудитом по лицензированию и затратами на докупку. Поставщик рискует спором по контракту: товар поставлен, но ожидания заказчика были «про другое», потому что в ТЗ не закрепили права и тип лицензии.

Обычно расходятся в понимании четырех вещей: версия и редакция (например, Home/Pro/Enterprise), канал поставки (OEM, коробка, корпоративные программы), способ активации и подтверждающие документы. Даже при одинаковом названии условия использования и набор бумаг могут отличаться.

Перед публикацией ТЗ стоит закрыть несколько вопросов: где будет использоваться ПО (новые ПК, существующие, виртуальные машины), нужны ли права апгрейда/даунгрейда и до каких версий, требуется ли перенос лицензий между устройствами, и какие документы вы хотите видеть при поставке и приемке.

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

Базовые термины: что именно вы покупаете

В закупках Microsoft важно разделять три вещи: сам продукт (Windows, Office и т.д.), право использования (что именно вам разрешено) и подтверждение (какими документами это право доказывается на приемке и при проверках).

Лицензия в бытовом смысле - это не коробка и не ключ. Это договорное право использовать ПО при заданных условиях: на каком устройстве, для какого пользователя, можно ли переносить, можно ли ставить другую версию. Подтверждение обычно складывается из поставочных документов (договор, счет-фактура, накладная, акт) и материалов лицензирования (сертификат/письмо, сведения о лицензиях в корпоративном кабинете, карточка лицензии, ключи/активация - если применимо).

Чаще всего путают тип поставки, а именно от него зависят установка и перенос. OEM обычно привязана к конкретному устройству и поставляется вместе с ПК, перенос на другое устройство, как правило, не допускается. Retail (коробочная/электронная розница) чаще допускает перенос, но с ограничениями (например, одновременно только на одном устройстве). Volume (корпоративные программы) обычно дает более гибкие права, но они зависят от выбранной программы и условий договора, а подтверждающие документы отличаются от Retail.

Отдельная зона ошибок - метрика лицензирования. Если не указать ее явно, поставщик может предложить не то, что вы ожидали. При per device лицензия считается по устройствам (типичная ошибка - купить «на отдел», не посчитав конкретные ПК). При per user лицензия считается по пользователям (типичная ошибка - купить «на компьютеры», хотя доступ имеют десятки сотрудников с личных учеток).

Наконец, Software Assurance (SA) - это не «дополнительный ключ», а набор прав и сервисов на срок действия. Именно SA часто дает право на апгрейд до новых версий и влияет на легальность даунгрейда. Если, например, госорган закупает ПК с OEM Windows, а потом планирует централизованно перейти на более новую редакцию, лучше заранее указать в ТЗ, нужно ли SA или иная программа, которая дает требуемые права.

Что должно быть в любой формулировке ТЗ

Чтобы «лицензии Microsoft в ТЗ» не превратились в спор на приемке, описание должно быть конкретным. Не «Windows/Office», а что именно, в какой редакции и на каких условиях вы получаете право использования.

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

Обязательные параметры, без которых ТЗ становится двусмысленным

Минимальный набор, который стоит зафиксировать в тексте:

• Продукт и редакция: точное название (например, Windows 11 Pro, Windows Server Standard, Microsoft Office Standard), а также разрядность и версия, если это важно.
• Канал лицензирования: OEM, коробочная (FPP), корпоративная (Volume), подписка (например, через CSP). У разных каналов разные права на перенос и разные подтверждающие документы.
• Язык: язык интерфейса и право на многоязычную установку, если это нужно (например, RU и EN).
• Количество и метрика: «на устройство», «на пользователя» или «на сервер/ядра» (для серверов) с точным числом.
• Срок действия: бессрочно или подписка на N месяцев, плюс правило, с какого момента срок считается (с момента активации или поставки).

Дальше полезно добавить 1-2 фразы про ваш реальный сценарий: где это будет устанавливаться, как активироваться, и какие права критичны (апгрейд, даунгрейд, перенос).

Совместимость с текущей инфраструктурой

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

Пример: «Требуется поставка 200 лицензий Office в редакции Standard, на пользователя, с поддержкой установки на рабочие станции Windows 10/11 и совместимостью с доменной инфраструктурой организации; язык интерфейса - RU с возможностью добавления EN. Тип лицензии указать в предложении поставщика и подтвердить документами поставки/права использования».

Как запросить нужные права апгрейда: примеры

Апгрейд нужен, когда вы хотите законно перейти на более старшую редакцию (например, с Standard на Datacenter) или иметь право получать новые версии в течение срока действия соответствующего права.

Здесь важно не смешивать два разных запроса: (1) покупка более старшей редакции сразу и (2) право обновления на будущие версии. Обновление не всегда включено по умолчанию, поэтому в ТЗ лучше прямо спросить, входит ли оно в поставку или приобретается отдельно (например, через Software Assurance или подписку).

Пример формулировки требования (апгрейд)

Ниже пример, который обычно одинаково понятно читается и заказчиком, и поставщиком:

Требование: предоставить лицензии Microsoft с правом обновления (Upgrade Rights) на новые версии продукта в течение срока действия права обновления.

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

Перед публикацией ТЗ уточните, что именно вы хотите обновлять: редакцию, версию или оба варианта. И попросите участника указать тип лицензирования (OEM, корпоративное, подписка), потому что от этого зависит наличие и условия апгрейда.

Как привязать к приемке: какие доказательства запросить

Чтобы право обновления не осталось «на словах», привяжите его к подтверждениям для приемки. Например, можно потребовать: комплект документов, подтверждающих право обновления (наименование, количество, срок, идентификатор или номер соглашения), первичные документы поставки с теми же позициями, подтверждение назначения лицензий организации (письмо от поставщика или выгрузка/скриншот из портала администрирования лицензий), а также описание процедуры, как заказчик получает доступ к обновлению (кто и где скачивает дистрибутив, как фиксируется версия).

Как корректно прописать даунгрейд: примеры

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

Главная ошибка в ТЗ - путать «право даунгрейда» и «поставку старой версии». Обычно вы покупаете актуальную лицензию, но получаете право легально использовать более раннюю версию. Поэтому лучше явно запросить именно право, а не писать «поставить Windows 10 вместо Windows 11» без пояснений.

Пример формулировки (универсальная):

«Требуется поставка лицензий Microsoft [наименование продукта/редакция] в количестве [N] с предоставлением права даунгрейда (использования более ранних версий) в соответствии с правилами производителя. Заказчик должен иметь право использовать любую из следующих версий: [перечень допустимых версий, например: Windows 11 Pro с правом использования Windows 10 Pro]. Поставка должна обеспечивать законность использования выбранной Заказчиком версии на дату приемки и в течение срока действия лицензии».

Чтобы убрать двусмысленность, добавьте фразу про итог:

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

По подтверждающим документам тоже лучше просить конкретику, чтобы на приемке не спорить «это просто слова». Например:

• документы, подтверждающие тип лицензии и права (сертификат/договор/лицензионное соглашение/подтверждение в личном кабинете, если применимо)
• комплект поставки и идентификаторы (ключи, номер лицензии, сведения о редакции)
• письмо/справку от поставщика о наличии права даунгрейда для указанных продуктов и версий
• инструкцию, как заказчику документально подтвердить право даунгрейда при проверках

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

Перенос лицензий между устройствами: как написать в ТЗ

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

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

Хорошая формулировка фиксирует событие (почему перенос), порядок (что делаем со старым ПК) и документы (чем подтверждаем).

Пример формулировки для ТЗ (можно адаптировать под ваш продукт и программу лицензирования):

«Поставляемые лицензии должны предоставлять право переноса права использования на другое устройство в случае: (а) плановой замены рабочего места, (б) выхода из строя оборудования и замены ключевых компонентов, (в) обновления парка ПК. Перенос допускается при условии прекращения использования ПО на исходном устройстве и отражения операции в учете ИТ-активов Заказчика. Поставщик обязан указать ограничения (если применимо): минимальный срок между переносами, требования к деактивации/удалению, случаи, когда перенос запрещен».

Чтобы перенос не стал спором на приемке, привяжите его к учету активов. В ТЗ можно добавить, что при передаче прав заказчик фиксирует старый и новый инвентарные номера, серийные номера устройств, дату переноса и основание (замена/ремонт).

Отдельно запросите, что именно передает поставщик для подтверждения: документы, подтверждающие легальность поставки и тип лицензии; данные для регистрации и учета (номера, сведения по пользователям/устройствам); описание правил переноса и ограничений в письменном виде; инструкции по действиям при замене ПК или ремонте.

Пошагово: как подготовить раздел ТЗ про Microsoft

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

1. Соберите исходные данные: какие устройства будут покрыты лицензией, сколько их, где используются (офис, удаленные рабочие места, серверная), какие версии и редакции уже стоят. Зафиксируйте, что именно нужно легализовать или заменить.

2. Определите модель лицензирования под сценарий. Для офисных ПК чаще всего критичны редакция (например, Pro vs Enterprise) и тип поставки. Для серверов и виртуализации заранее уточняйте, будет ли доступ через VDI/терминальные сессии и нужны ли клиентские лицензии.

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

4. Пропишите, какие подтверждения вы принимаете: наименование продукта и SKU, канал поставки, количество, лицензионное соглашение, первичные документы (счет, накладная, счет-фактура), а также сведения, по которым можно сопоставить лицензию с поставкой.

5. Продумайте приемку и хранение: кто проверяет соответствие редакции и прав, где хранятся ключи и документы, что считается расхождением. Если вы закупаете партию офисных ПК у системного интегратора вместе с Windows, заранее укажите, допускается ли установка Windows 10 вместо Windows 11 (при наличии права даунгрейда), и какие документы поставщик должен передать.

Типовые ошибки и ловушки в формулировках

Самая частая проблема - общие слова вроде «лицензия на Windows» или «Office». Без редакции, версии, языка, типа лицензии и канала поставки поставщик может привезти не то, а формально требование окажется «выполненным». Для лицензии важно точно назвать продукт (Windows Pro, Windows Enterprise, Office Standard и т.д.) и уточнить, это новая лицензия или апгрейд.

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

Еще одна путаница - «поставить ПО» против «передать права». Можно получить установленную систему, но остаться без подтверждения права использования. Это особенно болезненно при проверках и при постановке на баланс.

Быстрый самоконтроль формулировок:

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

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

Короткий чеклист перед публикацией ТЗ

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

В документе должны быть пять вещей:

• Точный состав поставки: продукт, редакция, версия (или правило «не ниже»), язык, количество и метрика (на устройство, на пользователя, по ядрам и т.д.).
• Права отдельными фразами: апгрейд, даунгрейд, перенос (если допускается) и ограничения переноса.
• Подтверждающие документы: что именно вы ждете и в каком виде (условия/соглашения, подтверждение права использования, ключи/учетные данные, сведения о канале поставки, идентификаторы).
• Порядок приемки: что проверяем (состав, метрику, права, документы), кто подписывает, где и как хранится комплект подтверждений для аудита.
• Совместимость и минимальные требования: разрядность, память, диск, роль устройства (рабочая станция/сервер), ограничения по виртуализации, если она планируется.

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

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

Пример реальной ситуации и как бы звучали формулировки

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

Ниже - пример фрагмента, который закрывает вопросы апгрейда, даунгрейда и переноса.

Фрагмент ТЗ (пример формулировок):

1. Поставить права использования ОС/офисных приложений с бессрочной лицензией (perpetual), с указанием редакции, языка, типа лицензии (OEM/FPP/Volume) и количества.
2. Для 80 рабочих мест требуется право использования актуальной версии продукта на дату поставки (обновление в рамках приобретенной редакции, если предусмотрено правилами лицензирования).
3. Для 40 рабочих мест требуется право даунгрейда до версии: (указать версию), с сохранением прав на базовую приобретенную редакцию.
4. При замене неисправного ПК в гарантийный период допускается перенос права использования на устройство-замену в пределах одной организации при условии соблюдения правил конкретного типа лицензии.

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

Документы для поставки и приемки (пример):

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

После поставки заведите учет: кто и на каком ПК использует какую редакцию, где хранится подтверждение, кто отвечает за перенос при замене. Если ПК поставляет системный интегратор или производитель, например GSE.kz (gse.kz), удобнее заранее согласовать формат реестра и актов, чтобы документы совпали с тем, что фактически установлено.

Следующие шаги: как подготовиться к закупке и приемке

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

Соберите входные данные кратко: где работают пользователи (офис, удаленно, смешанный режим), есть ли серверные роли и доступ по RDP/VDI, планируется ли замена ПК в течение срока использования, нужны ли апгрейд/даунгрейд под конкретные версии, важен ли перенос между устройствами и при каких условиях.

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

Заранее договоритесь о приемке: кто проверяет лицензирование и где хранится подтверждение. На практике удобно разделять роли: в день поставки ИТ-специалист сверяет наименования и тип лицензии со спецификацией, а закупщик проверяет комплект документов.

Если перенос прав для вас критичен (например, вы планируете через год заменить часть парка), лучше заложить это в ТЗ сразу. Иначе есть риск «привязать» лицензии к старому оборудованию и купить повторно.