SAM на 90 дней: план запуска инвентаризации и контроля трат

Зачем запускать SAM и какие задачи он закрывает

SAM (Software Asset Management) нужен, когда в компании никто не может быстро и уверенно ответить на простые вопросы: какие программы у нас есть, кому они нужны и за что мы реально платим. Без этого обычно начинается хаос: лицензии покупают "на всякий случай", отделы дублируют закупки друг друга, а устаревшее ПО продолжает числиться как обязательное.

SAM закрывает три практические задачи.

Первая - деньги. Вы находите лишние подписки, неиспользуемые лицензии и перекосы, когда в одном месте не хватает, а в другом простаивает.

Вторая - риски. При аудите трудно доказать право использования, если нет связки "устройство - пользователь - версия - лицензия - документ".

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

Простой список установок сам по себе мало помогает. Он не показывает, что именно установлено (названия одного и того же продукта могут отличаться), кто реально пользуется программой и является ли установка лицензируемой. Например, "Microsoft Office", "Office 365", "M365 Apps" и "Office ProPlus" часто оказываются одним продуктом в разных написаниях. Без нормализации вы получите неверные итоги.

За 90 дней реально выстроить базовую систему: инвентаризацию, единый справочник названий, первичную картину перерасхода и простой процесс согласования закупок. А глубокую оптимизацию контрактов, пересмотр условий с вендорами и полную автоматизацию лучше планировать вторым этапом.

Обычно вовлечены четыре роли: ИТ дает данные и отвечает за техническую часть, закупки - за правила покупки и документы, финансы - за бюджет и эффект, безопасность - за требования к допустимому ПО и риски (например, запрет теневых установок). Когда эти роли договорились о правилах, SAM начинает работать как система, а не как разовая "перепись".

Цели и границы SAM: чтобы не утонуть в объеме

Чтобы SAM за 90 дней дал результат, сначала нужно ответить на два вопроса: что именно вы берете под контроль и как поймете, что стало лучше. Без границ команда быстро увязнет в сотнях приложений, разных площадках и спорах о том, что считать лицензией.

Охват: где начинаем и что пока не трогаем

Выберите стартовый периметр, который легко объяснить. Например: 1-2 подразделения с самыми большими тратами на ПО, одна площадка (или один домен) и только коммерческое ПО с платными лицензиями. Отдельно решите, включаете ли вы удаленные рабочие места, виртуальные машины, серверы, терминальные фермы и облачные подписки.

Сразу зафиксируйте, какие категории точно входят в первый цикл (например, офисные пакеты, САПР, антивирусы, серверные продукты), а что откладывается (узкоспециализированные утилиты, бесплатные приложения, плагины).

Цели лучше формулировать в цифрах и сроках. Для первых 90 дней обычно достаточно 3-5 метрик, например:

• снизить перерасход по 3-5 ключевым издателям на сумму X тенге (или на X%)
• выявить 100% установок выбранных продуктов в заданном периметре
• убрать закупки без согласования
• выпускать ежемесячный отчет: установки, лицензии, риски, экономия

Роли и правила учета: один словарь для всех

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

Заранее согласуйте определения, чтобы не спорить в середине проекта:

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

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

Дорожная карта на 90 дней: результат на каждом этапе

90 дней - хороший срок, чтобы получить видимый контроль и не превратить SAM в бесконечный проект. Логика простая: каждый месяц вы фиксируете измеримый результат и добавляете один новый элемент процесса.

Что должно быть готово к 30, 60 и 90 дню

Думайте не "что делать", а "что показать" руководству и пользователям.

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

Минимальный набор артефактов, который стоит вести с первого дня: реестр ПО, каталог нормализации, отчет по перерасходу и короткий регламент закупок (1-2 страницы). Этого достаточно, чтобы SAM стал управляемым.

Как не утонуть в коммуникациях и согласованиях

Держите коммуникации легкими: 15-20 минут еженедельного статуса и один общий канал для вопросов, где договоренности фиксируются сразу. Бизнес должен видеть прогресс, а ИТ - не тратить время на бесконечные встречи.

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

Дни 1-30: инвентаризация ПО и сбор исходных данных

Первые 30 дней решают одну задачу: получить картину, которой можно доверять. Без этого SAM превращается в спор мнений, где у ИТ одни цифры, у закупок другие, а у безопасности третьи.

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

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

Чтобы потом сравнивать данные, нужен единый формат выгрузок. Поля могут называться по-разному, но смысл должен совпадать. Утвердите минимальный "паспорт записи":

• уникальный идентификатор устройства (серийный номер или asset ID)
• имя устройства и тип (ПК, ноутбук, сервер, VDI)
• пользователь или владелец (учетка, табельный номер)
• название ПО как в источнике и издатель
• версия и дата обнаружения

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

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

Нормализация названий: как привести ПО к единому справочнику

Нормализация нужна по простой причине: одно и то же приложение в инвентаризации легко превращается в 3-5 разных строк. Где-то оно записано как "Microsoft Office", где-то как "MS Office Pro", где-то как "Office 2019 en-us". Если оставить так, вы не сможете честно посчитать установки, сопоставить их с лицензиями и увидеть перерасход.

Практичный подход - отделить "как называется продукт" от "какая у него комплектация и вариант поставки". Обычно хватает таких полей:

• Издатель (Publisher): единое написание без "LLC", "Inc." и лишних приставок
• Продукт (Product): короткое базовое имя без года и языка
• Редакция (Edition): Standard/Pro/Enterprise, Client/Server и другие отличия, влияющие на лицензирование
• Версия (Version): один формат (например, major.minor или год)
• Язык (Language): отдельное поле, а не часть названия

Конфликты будут всегда. Один установщик оставляет разные Display Name на разных ПК, или агент читает разные источники (реестр, MSI, ярлыки). Тут помогает правило приоритета источников и ручная верификация 10-20 самых "шумных" записей. Например, в больнице с сотнями рабочих мест вы увидите "Adobe Reader", "Adobe Acrobat Reader DC" и "AcroRdrDC" - это один продукт, и его нужно свести к одной карточке.

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

Дни 31-60: выявление перерасхода и рисков по лицензиям

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

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

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

• лишние покупки (купили "про запас")
• лишние установки (ПО стоит шире, чем покрывают права)
• неиспользуемые лицензии (право есть, но программа не запускается месяцами)
• неправильные редакции (стоит версия дороже или с иными условиями)
• теневые установки (ПО появилось без заявки и без закупки)

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

Чтобы ИТ и финансы не спорили о цифрах, заранее согласуйте формат двух отчетов: один для действий, другой для денег.

Для ИТ достаточно указать продукт, где стоит, владельца, тип нарушения и что сделать (удалить, заменить, докупить). Для финансов - продукт, количество прав, подтвержденная потребность, разница, оценка стоимости и период.

Пример: в филиальной сети на рабочих станциях нашли платную графическую программу, которая нужна только маркетингу. После проверки оказалось, что на 40 ПК есть установки, лицензий 10, и еще 15 лицензий не используются. Решение раскладывается на три шага: убрать лишние установки, перераспределить лицензии и только потом докупить недостающее.

Процесс согласования закупок ПО: как остановить хаотичные покупки

Хаотичные закупки часто начинаются с "нужно срочно для проекта". Без понятного процесса вы быстро получаете дубли, разные версии одного продукта и расходы, которые трудно объяснить. В плане на 90 дней важно не только найти перерасход, но и перекрыть канал, через который он появляется снова.

Триггеры: купить, перераспределить или удалить

Зафиксируйте простые триггеры, чтобы каждый запрос шел по одному маршруту:

• покупаем, если лицензий не хватает и нет подходящей альтернативы
• перераспределяем, если лицензии есть, но не используются
• удаляем и закрываем доступ, если ПО не нужно по роли, не используется или создает риск
• продлеваем, если заканчивается подписка и есть подтвержденная потребность
• откладываем, если запрос не связан с задачами ближайших 1-2 месяцев

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

Минимальный пакет заявки и стоп-правила

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

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

Простой сценарий: отдел просит 10 лицензий графического редактора. Проверка показывает, что 6 активных пользователей уже есть в другой команде, а еще 2 сотрудника не открывали программу 60 дней. Итог - перераспределение 8 лицензий, покупка только 2 и фиксация стандартной версии на будущее.

Дни 61-90: закрепляем процесс и делаем его повторяемым

На этом этапе важно перестать жить "проектом" и перейти к регулярной работе. Если реестр обновляют раз в полгода, SAM быстро превращается в архив. Цель дней 61-90 - закрепить роли, частоту обновлений и простые проверки, которые выполняются всегда.

Регламент и ответственность

Короткий регламент обычно работает лучше толстого документа. Достаточно договориться, кто и что делает, и где это фиксируется.

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

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

Регулярные циклы и метрики

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

Метрики выбирайте простые:

• доля нормализованных записей (например, 90% и выше)
• сумма предотвращенных трат и найденной экономии
• среднее время согласования заявки на ПО
• доля теневого ПО и скорость его устранения

Хорошая практика - держать метрики на одной странице, чтобы их читали не только ИТ.

Встраивание в онбординг и выдачу рабочих мест

Частый источник хаоса - новые сотрудники и "срочные" выдачи ноутбуков. Встройте SAM в стандартный сценарий: при онбординге сотрудник выбирает ПО из каталога, а нестандартное ПО идет через согласование.

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

Частые ошибки при запуске SAM и как их избежать

Самая частая причина провала SAM - попытка сделать все идеально с первого дня. Лучше получить точные цифры по ключевым продуктам и площадкам, чем утонуть в объеме и не дойти до решений.

Ошибка 1: пытаться охватить все сразу

Когда в инвентаризацию одновременно попадают все филиалы, VDI, тестовые контуры и каждый мелкий инструмент, команда быстро застревает в спорных данных. Начните с 10-20 самых дорогих или рискованных вендоров (часто это офисные пакеты, ОС, виртуализация, СУБД). Расширяйте охват волнами, раз в 2-4 недели.

Ошибка 2: свалить установки и закупки в одну таблицу

Данные установок показывают факт использования, а закупки - право на использование. Их нельзя смешивать без правил сопоставления: какие метрики лицензирования у продукта, что считать "устройством", как учитывать виртуальные машины, что делать с подписками и пакетами.

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

Ошибка 3: отложить нормализацию на конец

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

Ошибка 4: запустить согласование закупок без понятных правил

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

Пример: отдел просит 50 лицензий "на всякий случай". По данным использования реально активны 32. Согласование разрешает докупить 10 сейчас, а остаток вернуть на повторную проверку через месяц. Так процесс помогает, а не тормозит работу.

Пример сценария на 90 дней: от хаоса к контролю

Компания: 500 ПК, 3 офиса (головной и два региональных). ПО покупали по запросу, учет вели в Excel, часть программ ставили "временно", но они оставались годами. Запуск SAM начали с простой цели: понять, что реально установлено и за что уже заплачено.

В приоритете были офисный пакет, PDF-редактор, средства удаленного доступа, графические редакторы для небольшой группы, антивирус и несколько инженерных утилит.

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

Перерасход нашли сопоставлением фактов: установок, активных пользователей и купленных лицензий. В одном офисе было больше установок PDF-редактора, чем реальных задач, потому что его ставили "про запас".

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

Результаты фиксировали "до и после", без обещаний в процентах:

• сократили число уникальных наименований ПО в учете примерно в 3 раза
• нашли и убрали 1-2 дублирующих продукта в массовом использовании
• снизили число установок без владельца и цели
• ускорили согласование за счет более полных заявок

Покупки начали опираться на инвентаризацию и правила, а не на срочность. Это и есть главный признак, что SAM перестал быть разовой кампанией.

Чеклист и следующие шаги после первых 90 дней

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

Чеклист перед стартом (или перезапуском)

• Назначен владелец процесса SAM (кто принимает решения и снимает блокировки).
• Понятны источники данных: инвентаризация на ПК и серверах, закупки, договоры, учет пользователей.
• Утвержден формат реестра: какие поля обязательны, как хранится версия, издатель, метрика лицензии, владелец.
• Согласован список приоритетного ПО (обычно 10-20 позиций с максимальными тратами или рисками).

К 30 дню должны появиться цифры, а не ощущения: покрытие инвентаризации (например, 85% устройств в контуре), доля нормализованных записей (например, 60%) и основные провалы данных (нет владельца, неполные версии, не совпадают названия в закупках).

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

Следующие шаги после первых 90 дней

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

Если SAM нужно глубже встроить в ИТ-контур и поддерживать в режиме 24/7, имеет смысл привлекать опыт системной интеграции и сопровождения. В Казахстане такие задачи часто решают вместе с GSE.kz, когда важно увязать данные SAM с инфраструктурой, процессами выдачи рабочих мест и закупками.