Какая версия PUR применяется к моим лицензиям? Часть третья

Это третья часть статьи. Перейти ко второй или к первой части.

Итак, мы уже знаем, что нужно искать. Давайте теперь разберёмся, какие практические действия требуется произвести.

Первым делом, необходимо найти все записи об имеющихся лицензиях и всех их исторических закупках. Особенно это касается хотя бы раз продлевавшихся соглашений. Это ваше обычное действие в ходе аудита, и подробно мы его рассматривать сейчас не будем. Очень хорошим инструментом для изучения истории закупок является Microsoft Licensing Statement (MLS), который клиент должен запросить самостоятельно у своего менеджера в Microsoft или через своего реселлера. Это файл в формате Microsoft Excel, который содержит как сырую информацию обо всех транзакциях клиента, так и несколько сводных таблиц pivot table, показывающих с разных углов карту доступных лицензий.

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

В идеальном случае, когда все закупки видны в MLS и не вызывают у вас никаких вопросов и сомнений, вам не потребуется самостоятельно выстраивать и выверять цепочки лицензий. В реальной ситуации такая выверка может потребоваться для 10-30% закупок. Трудности могут вызвать изменения в наименовании продукта, передача лицензий между офисами в разных странах, закупки отдельных SA для купленных ранее коробок и OEM. Коробки FPP и OEM-лицензии в MLS не отражаются, в его записях содержатся только именные приобретения (корпоративные лицензии с указанием лицензиата).

Посмотрите ещё раз на рисунок. Красным цветом обозначены лицензии в составе соглашения Enterprise Agreement. Слева вы видите связь самого соглашения и его двух продлений. Однако, как вам известно, клиент может докупать отдельные продукты в течение срока действия соглашения в любой момент, а не только в даты его заключения и продления. И, что вам может быть менее очевидно, в даты продления клиент может отказаться продлевать SA как на отдельные позиции целиком, так и на часть количества лицензий. Например, при продлении соглашения в 2014 году клиент, у которого имеется 200 лицензий Windows Server 2012 по истёкшему EA, может принять решение обновить Software Assurance только на 180 из них. Поэтому цепочки закупок и продлений нужно выстраивать не для EA целиком, а для отдельных позиций, лицензированных в контексте этого EA, что отражено на правой половине рисунка.

Синим цветом на рисунке отмечена закупка отдельной лицензии Open License L&SA и последующее продление SA на два года. Оранжевым — SA, для которого при первичном анализе не нашлось основной лицензии, т.е. невозможно установить, зачем приобреталась отдельная лицензия на Software Assurance без самого продукта. Такие «сироты» могут означать, что SA покупали для ранее приобретённой коробки FPP или лицензии OEM. В других случаях «сироты» могут указывать как на неверную передачу лицензий, например, при слиянии и поглощении компаний, так и на ошибки в самом MLS. Ваша задача на этом этапе — расследовать все несвязности в цепочках и по максимуму восстановить утерянную информацию. При необходимости можно обратиться в Microsoft, но только для коррекции MLS. Microsoft не обладает информацией о конечных покупателях FPP и OEM.

В процессе выстраивания «цепочек» вы уже будете видеть даты закупок и продлений. Схематично соответствующий график показан на рисунке выше. Обратите внимание, что промежуток между точкой покупки OEM и докупки к этой лицензии Software Assurance — это не ошибка на рисунке, а напоминание о том, что от покупки FPP или OEM до приобретения соответствуюшего SA может пройти до 90 дней. Это разрешается. Имейте это в виду, когда расследуете судьбу «SA-сироток».

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

  1. Дата покупки продукта или дата продления соглашения, на которую устанавливается наиболее старая применимая версия PUR.
  2. Дата, когда продукт «стал доступен» (см. вторую часть статьи), по которой определяются как доступные клиенту обновления, так и следующие применимые версии PUR.

На следующем рисунке это продемонстрировано на отдельных продуктах в составе одного соглашения Enterprise Agreement.

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

Продукт Текущая версия К-во Дата покупки или последнего продления Срок SA истекает или истёк Название и версия изначально лицензированного продукта, дополнительные заметки
SQL Server Enterprise 2012 20 21 окт 2011 Активно 2008 R2
SQL Server Enterprise 2008 R2 12 21 окт 2008 21 окт 2011 2008
Windows Server Standard 2012 R2 60 21 окт 2001 Активно 2008 R2 Enterprise, 30 лицензий
Visual Studio Ultimate w/MSDN 2013 9 21 окт 2011 Активно 2010
Office SharePoint Server 2010 1 01 янв 2009 21 окт 2011 Office Forms Server 2007

Информацию для первых двух колонок можно почерпнуть из закладки MLS под названием «License summary», а для последней — разыскать в закладке «Transaction details».

Обратите внимание на две строчки, в которых последняя ячейка выделена жирным шрифтом. В третьей строке вы можете увидеть, что в 2011 году были куплены 30 лицензий Windows Server Enterprise, которые в 2012 году превратились, во-первых, в редакцию Standard, а во-вторых, их количество увеличилось в два раза согласно формуле обновления. Именно так подобные лицензии будут отражены в MLS. Вспомните, пожалуйста, предыдущие части статьи. Клиент может в этом случае:

  • Продолжить использовать Windows Server 2008 R2 Enterprise в конфигурации, которая требует 30 соответствующих лицензий изначально купленной версии.
  • Обновить физически экземпляры Windows Server до версии 2012 R2 и использовать его в конфигурации, которая требует уже 60 или менее новых лицензий.
  • Не обновлять физически экземпляры Windows Server, но перейти на правила использования версии 2012 R2 в конфигурации, которая требует 60 или менее новых лицензий, а экземпляры 2008 R2 трактовать как понижение версии с 2012 R2, при этом понижение позволяет использовать 2008 R2 Enteprise вместо 2012 R2 Standard.
  • Использовать любой смешанный вариант из вышеперечисленных, не нарушающий лицензионных правил.

Office Forms Server — это типичный образец так называемого «Licence grant», когда лицензиатам позволялось использовать другой, часто более продвинутый (читай — более дорогой) продукт вместо старого, выпуск которого был прекращён. Это также будет отражено в MLS.

Итак, для всех лицензий вы определили применимые PUR, тем самым ответив на заглавный вопрос этой трёхчастной статьи: «Какая версия PUR применяется к моим лицензиям?» Однако, это только первый этап работы по «тонкому аудиту лицензий». Оставайтесь с нами, и вы узнаете:

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

Всего вам доброго!

Это третья часть статьи. Перейти ко второй или к первой части.
© Alexander Golev & Partners Software Asset Management Experts Ltd. Сайт использует Nesta Ruby CMS.
Яндекс.Метрика