Реестр лицензий без CMDB: шаблон полей и правила обновления

Задача реестра: порядок в лицензиях без CMDB

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

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

Заранее договоритесь, что именно вы считаете лицензией и заносите в реестр. Обычно туда попадают подписки (помесячные или годовые), бессрочные лицензии (perpetual), OEM-лицензии, привязанные к железу, CAL и серверные права доступа, а также пакеты и «пулы» лицензий, которые распределяются по мере нужды.

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

Какой реестр считать рабочим: 4 простых принципа

Рабочий реестр не обязан быть красивым или «идеальным». Он должен отвечать на два вопроса в любой день: сколько прав у нас есть и на что они сейчас потрачены. Если вы строите реестр лицензий без CMDB, важнее дисциплина и одинаковые правила, чем сложные таблицы.

1) Принцип 80/20: начните с критичного

Сначала внесите то, что дает самый большой риск и расходы: офисные пакеты, ОС, серверные продукты, VDI, САПР, антивирус, дорогие подписки. На практике 10-20 позиций часто закрывают 80% бюджета и почти все «проверочные» вопросы.

2) Один источник правды

Реестр должен жить в одном месте: один файл или один список в выбранной системе. Не допускайте параллельных копий «для ИБ», «для закупок» и «для админов». Если нужно - делайте представления и выгрузки, но правки идут только в первоисточник.

3) Единые определения

Одинаковые слова - одинаковые цифры. Зафиксируйте простые определения и используйте их в каждом споре: что считается «правом», что считается «установкой», кто такой «пользователь», что такое «хост», как вы учитываете пул и виртуальные машины. Иначе один человек считает по устройствам, другой по людям, а на встрече цифры «не сходятся».

4) Версионность и ответственность

Назначьте владельца реестра (обычно ИТ-активы или ИТ-операции) и того, кто утверждает изменения (например, руководитель ИТ или закупок). Любая правка должна оставлять след: дата, кто изменил, что изменил и на основании какого события.

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

Шаблон полей: блок «Право» (что купили и на каких условиях)

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

Начните с формулировки «уровня права». Записывайте не просто название, а связку: продукт + редакция/пакет + тип лицензии + метрика. Иначе через полгода «Office» превратится в спор: Pro это или Standard, подписка или бессрочная, на пользователя или на устройство.

Чтобы записи можно было быстро сверять с закупками и письмами от вендора, добавьте идентификаторы: вендор и SKU/Part Number (если он есть в счете или заказе), номер договора, заказа или заявки. Это экономит часы при аудитах и внутренних проверках.

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

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

Минимальный набор полей, которого обычно хватает:

• Продукт, редакция/пакет, тип лицензии, метрика
• Вендор, SKU/Part Number, номер договора/заказа
• Подразделение (центр затрат), валюта (и сумма при необходимости)
• Тип документа и место хранения подтверждения права

Пример записи: «Windows Server, Standard, бессрочная, per core; Vendor: Microsoft; Part Number из счета; договор №...; ЦЗ: ИТ; подтверждение: акт + письмо, хранится в папке закупок».

Метрика и правила подсчета: чтобы все считали одинаково

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

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

Сделайте обязательное поле «Метрика лицензирования» со строго заданными значениями (выбор из списка). Рядом добавьте «Единицу учета» (пользователь, устройство, ядро, VM, сервер) и «Количество по договору». Тогда модель становится прозрачной: «сколько купили» плюс «сколько заняли».

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

Если метрика сложная и зависит от железа, кластера или сочетания «сервер + ядра», не пытайтесь упаковать это в одно название. Добавьте поле «Правило подсчета (простыми словами)» (например: «считаем по ядрам на каждом физическом сервере, виртуалки не считаем отдельно») и поле «Источник правила» (документ или пункт договора), чтобы не спорить при проверке.

Привязка лицензии: к пользователю, к хосту или в пул

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

Как выбрать тип привязки

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

Практичное правило такое:

• Пользователь - «лицензия для человека»: устройства могут меняться, владелец один.
• Хост - «лицензия для железа»: важны инвентарный номер и место установки.
• Пул - «лицензия на склад»: выдаем и возвращаем по заявке.

Минимальные поля, чтобы не спорить на проверке

Для привязки к пользователю достаточно идентифицировать человека и его актуальность. Обычно хватает ФИО как отображаемого поля, уникального идентификатора (табельный номер или стабильный ID из HR-системы), подразделения и статуса (активен или уволен). Статус важен: он сразу показывает, что лицензию можно вернуть в пул или переоформить.

Для привязки к хосту фиксируйте данные, которые не «плавают» при переименовании в сети: имя ПК/сервера (как видит ИТ), инвентарный номер, серийный номер и местоположение (офис, кабинет, стойка). Это помогает, когда устройство уехало в другой филиал или было заменено по гарантии.

Если лицензия в пуле, не оставляйте строку пустой. Укажите статус «Свободна» и добавьте поле «Ожидаемый владелец» (например, «новый бухгалтер, выход 15.02» или «проектная команда, март»). Так пул не превращается в свалку «непонятно чьих» прав.

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

Сроки и документы: как не пропускать продления и проверки

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

Поля по срокам, которые реально работают

Минимальный набор полей про время лучше сделать одинаковым для любых типов лицензий: дата начала, дата окончания, период продления и «уведомить за N дней». Если лицензия бессрочная, «дата окончания» остается пустой или помечается как «бессрочно», но срок поддержки (если он есть) ведите отдельно - отдельным полем или отдельной строкой.

Чтобы не гадать, когда поднимать вопрос, закрепите одно правило: N дней зависит от сложности закупки. Например, для типовых подписок - 30 дней, для закупок через тендер или длинные согласования - 60-90 дней.

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

Документы: как быстро доказать право

В поле «Документ» указывайте тип и реквизиты: счет/инвойс, договор, акт, сертификат, письмо-подтверждение, номер заказа в личном кабинете вендора. Важно, чтобы по одной строке в реестре можно было быстро найти первоисточник: «Договор №..., от ..., контрагент ...».

Файлы храните отдельно (в защищенной папке или хранилище с правами доступа), а в реестре оставляйте только идентификаторы и место хранения. Туда же складывайте сканы, письма, сертификаты. Ключи и токены в реестр не пишите: отмечайте факт наличия и где они лежат, иначе реестр станет источником утечки.

Пример: подписка на 100 мест заканчивается 30 июня. В реестре стоит «уведомить за 60 дней», статус «активно», и указаны реквизиты инвойса и письма от вендора. В начале мая у вас уже есть задача на продление, а при проверке вы показываете реквизиты без поиска по старым чатам.

Пошагово: как собрать реестр за 1-2 недели

Реестр лицензий без CMDB реально собрать быстро, если не пытаться сразу описать весь мир. Начните с понятного объема: ПО, которое покупали или продлевали за последние 12-24 месяца, плюс то, что уже стоит на рабочих местах и чаще всего всплывает на проверках.

План на 1-2 недели

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

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

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

3. Внесите права: что купили, в каком количестве, на каких условиях и к каким документам это относится. Это ваша «точка правды».

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

5. Настройте базовую рутину: кто обновляет реестр, как часто сверяет и какие отчеты смотрите каждую неделю.

Как не утонуть в деталях

Держите порядок ввода: одна строка права - на одну покупку или пакет, а назначения ведите отдельно (вторая вкладка или отдельная таблица). Если купили 50 подписок «на пользователя», право одно, а назначений будет до 50. Так проще видеть остаток и перераспределять.

На финише добавьте три контрольных отчета (даже если это просто фильтры):

• что истекает в ближайшие 60-90 дней;
• где назначено больше, чем куплено;
• где есть установки без назначения (или наоборот).

Польза появится сразу, без ожидания идеальной точности.

Правила обновления: события-триггеры и частота сверок

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

События-триггеры: что должно попадать в реестр сразу

Самый надежный подход - фиксировать изменения в день появления, а не «когда будет время». Обычно хватает четырех групп триггеров.

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

Кадровые изменения: увольнение, перевод, длительный отпуск. Это повод снять привязку лицензии, переназначить ее или отметить возврат в пул.

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

Внешние проверки: запрос от закупок, службы безопасности или аудитора. Полезно фиксировать сам факт проверки и результат (кто смотрел и что подтвердил).

Частота сверок: чтобы ошибки не копились

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

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

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

Частые ошибки и как их избежать

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

Частая проблема - смешивание метрик в одной строке без пояснений. Например, в одной записи пишут «10 users / 10 devices» или рядом ставят «16 cores» и «1 server». Через месяц никто не помнит, как считать потребление. Исправление простое: одна строка - одна метрика и одно правило подсчета. Если очень нужно оставить детали, вынесите их в отдельные поля.

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

Третья ошибка - привязка к именам пользователей («Иванов И.И.») без уникального идентификатора. Люди увольняются, меняют фамилии, появляются однофамильцы. Лучше хранить табельный номер или стабильный ID из кадровой системы, а имя оставить как отображаемое поле. Для хоста аналогично: не только «PC-OLGA», а инвентарный номер или серийный номер.

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

Быстрый способ найти эти проблемы:

• убедиться, что в каждой строке ровно одна метрика и понятное правило подсчета;
• проверить, что у каждой закупки есть документ-основание или явный статус «нет подтверждения»;
• посмотреть 10 случайных назначений: есть ли у пользователя уникальный ID, а у устройства - инвентарный признак;
• проверить статусы и даты: «закупка» и «назначение» не должны считаться как два разных права;
• найти дубликаты по ключевым полям (продукт, версия, метрика, договор, период) и определить, какая запись главная.

Если исправить это сразу, реестр перестает быть «списком ключей» и начинает работать как источник правды для продлений и проверок.

Быстрая проверка реестра: чек-лист на 10 минут

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

10 минут: что проверить

Ответьте «да/нет» по пунктам. Если где-то «нет», отметьте строку и вернитесь к ней позже.

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

Небольшой пример: у вас куплено 120 прав на продукт X. Назначено 95 (по пользователям), в пуле свободно 25. Если в реестре выходит 120 - 95 - 20 = 5, значит 5 лицензий «потерялись»: не учтено назначение, неверно указан пул или ошиблись в количестве по документу.

Если нашли пробел, не пытайтесь исправить все сразу. Сначала сделайте минимальные правки, чтобы реестр снова «сходился»: приведите названия и метрику к одному варианту, восстановите связь «документ -> количество -> назначения», добавьте статус «требует проверки» для спорных строк и назначьте ответственного.

Пример из практики: реестр для организации на 200 рабочих мест

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

Для старта удобно разделить учет на три категории:

• Офисный пакет - учет по пользователю (учетная запись/ID), потому что люди могут менять рабочие места.
• Антивирус - учет по хосту (инвентарный номер ПК/серийник), потому что защита ставится на конкретный компьютер.
• Серверные лицензии - учет по серверу и роли (например, лицензия на ОС, СУБД, доступы), с отдельной строкой на каждый сервер.

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

Чтобы это выглядело одинаково у всех, закрепите в реестре несколько ключевых полей: «Право/редакция», «Метрика», «Привязка (пользователь/хост/пул)», «Срок действия», «Документ».

Ежемесячная сверка занимает 20-30 минут, если есть ответственные: HR дает список кадровых изменений, ИТ отмечают выдачу/списание ПК и изменения по серверам, закупки подтверждают ближайшие продления и место хранения документов, владелец реестра фиксирует изменения и помечает спорные строки.

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

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

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

Если позже появится CMDB или SAM-инструмент, вы не захотите переписывать данные. Поэтому уже сейчас используйте стабильные идентификаторы: табельный номер сотрудника, инвентарный номер ПК/сервера, единый справочник подразделений, а для лицензий - один формат названий и версий.

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

Цель простая: реестр должен переживать рост компании и изменения в ИТ без ручного «героизма» раз в год.