Software metering для оптимизации закупок: измеряем использование

Зачем измерять фактическое использование ПО

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

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

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

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

• ИТ отвечает за инвентаризацию, доступ к данным и технические ограничения.
• Безопасность - за правила сбора данных и приватность.
• Закупки - за условия лицензий, сроки продлений и варианты оптимизации.
• Владельцы процессов - за то, что считать «использованием» в реальной работе и какие риски у сокращений.

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

Ключевые термины и что именно измерять

Metering часто путают с инвентаризацией и лицензированием, хотя это разные задачи. Инвентаризация отвечает на вопрос «что установлено и где». Лицензирование - «на что у нас есть право использования и на каких условиях». Metering - «как этим реально пользуются».

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

Важно учитывать тип приложения. Для офисных программ запуск и активное время часто отражают реальную работу. Для фоновых сервисов (VPN-клиенты, антивирусы, драйверы, агентское ПО) запуск почти ничего не говорит: они могут быть критичны, но «не видны» как активная работа. Для web-приложений и SaaS metering по установкам не подойдет - нужны логи входов, активность в системе или отчеты из админ-консоли.

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

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

Откуда брать данные: основные источники metering

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

Чаще всего используют четыре источника:

• агент на ПК/сервере (запуски, активность, время работы, иногда версии);
• данные ОС (журналы и события, проще внедрять, но меньше деталей);
• лицензионный сервер (FlexLM и аналоги: выдача/возврат, пики, конкуренция за пул);
• облачные отчеты вендора (Microsoft, Autodesk и др., особенно полезно для SaaS).

У каждого источника свои ограничения. Агент дает точность по рабочим станциям, но требует развертывания и контроля. Лицензионный сервер хорошо отвечает на вопрос «почему не хватает лицензий», но не всегда показывает, что приложение открыто «для галочки». Облачные отчеты иногда считают только вход, а не полезную работу.

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

Для CAD, ERP и специализированного ПО часто нужны дополнительные метрики: одновременные пользователи и пики по времени, токены/кредиты/модули вместо «просто лицензии», использование ключевых функций и признаки реальной активности (а не просто открытое окно).

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

Как подготовиться: границы проекта и правила принятия решений

Software metering работает, когда заранее понятно, зачем вы измеряете. Цель обычно одна из трех: сократить новые закупки, перераспределить лицензии или проверить соответствие условиям лицензирования. Если смешать все сразу, данные начнут тянуть в разные стороны, а решения станут спорными.

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

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

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

Перед стартом согласуйте правила решений:

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

Так вы снижаете «мертвые» лицензии, не лишая людей инструмента в самый неподходящий момент.

Пошагово: как запустить software metering и получить первые выводы

Начинайте не с сокращений, а с чистых данных и понятных правил. Первые выводы реально получить за 2-4 недели, если заранее договориться, что считать «использованием».

1) Соберите базу: кто и что у вас есть

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

Дальше включайте сбор факта запуска и проверяйте качество данных: убедитесь, что события реально приходят, сравните отчеты с работой контрольной группы из 10-20 пользователей и зафиксируйте окно наблюдения (например, 30-60 дней), чтобы не попасть в «тихий» сезон.

2) Приведите данные к виду, пригодному для решений

Часто половину проблем решает нормализация названий и версий. «Adobe Reader», «Acrobat Reader DC» и «AcroRd32.exe» должны стать одним продуктом, иначе список «редко используемых» раздуется искусственно.

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

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

Как правильно интерпретировать данные и контекст

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

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

Сезонность и проектные пики легко маскируют реальную потребность. Поэтому ориентируйтесь не на «последние 7 дней», а на интервал, который покрывает типичный цикл работы (часто 90-180 дней).

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

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

Сравнивая подразделения, не делайте выводы «у отдела А меньше запусков - значит лишнее». Сопоставляйте задачи, регламенты и риски. Лучше подтвердить выводы короткими интервью с владельцами процессов и пилотным перераспределением, чем резать сразу и останавливать работу.

Частые ошибки и ловушки, из-за которых страдает бизнес

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

Частая ошибка - урезать лицензии до окончания согласованного периода наблюдения. Если вы смотрели только 2-4 недели, легко пропустить квартальные пики, отпуска, командировки и смены проектов.

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

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

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

Небольшой контрольный набор, который помогает не навредить:

• Дождитесь согласованного окна наблюдения (часто 8-12 недель).
• Проверьте редкие сценарии: закрытие периода, аудиты, аварийные задачи.
• Разведите редакции, версии и права в отчетах и в договорах.
• Сначала перераспределяйте, а сокращение закупок делайте после подтверждения эффекта.
• Фиксируйте решения и владельцев, иначе через 3-6 месяцев все «разъедется».

Пример: в банке 20 лицензий графического ПО «не использовались» 30 дней. После разговора выяснилось, что 4 сотрудника запускают его раз в квартал для отчетов и бренд-материалов. Решение было простым: 16 лицензий перераспределили в активные команды, а 4 оставили как резерв с понятным правилом выдачи.

Короткий чек-лист перед тем, как сокращать лицензии

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

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

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

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

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

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

Пример из практики: как найти «мертвые» лицензии без сокращений наугад

В одной компании закупали 200 лицензий офисного пакета и 80 лицензий специализированного ПО для проектных команд. Формально все было «нужно», но закупки росли каждый год, а бюджет - нет. Решили включить software metering и посмотреть фактическую картину.

За 90 дней собрали данные по запускам и активному использованию. По офисному пакету все было ожидаемо: большинство работали почти ежедневно. А вот по спецПО обнаружился нюанс: 35 пользователей запускали его всего 1-2 раза за весь период. По одним цифрам хотелось сразу снять лицензии, но владельцы процессов объяснили контекст: это проектные роли, где доступ нужен «на всякий случай» в период приемки, аудита или закрытия этапа.

Вместо резких сокращений:

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

Итог был простым: закупки снизили без остановки процессов и без конфликта с владельцами. Главный вывод - не «35 человек не используют», а то, что у использования есть сезонность и пики. Metering помогает, если читать его вместе с календарем проектов, ролями и требованиями к доступу.

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

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

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

Что измерять, чтобы не было ощущения «слежки»

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

Короткое правило: если показатель не влияет на решение о лицензии, его не надо собирать.

Доступ к данным и анонимизация

Ограничьте доступ по ролям. Обычно достаточно, чтобы отчеты видели SAM/ITAM, владелец продукта и ИБ, а руководителям давать агрегированные данные.

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

Если у вас есть ИБ и юридический блок, согласуйте методику до старта: основание обработки, сроки, уведомление сотрудников, требования к хранению.

Как превратить metering в регулярный процесс, а не разовую акцию

Разовый замер часто дает заметную экономию, но через 3-6 месяцев все возвращается: люди меняют роли, появляются новые проекты, версии приложений обновляются, а закупки идут по привычке. Чтобы metering работал постоянно, нужен простой повторяемый цикл и понятные правила.

Ежемесячный цикл: от данных к действиям

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

Маленькая, но важная деталь: сначала перераспределяйте, а сокращение покупок делайте только после подтверждения эффекта.

Чем мерить результат и как сохранять актуальность

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

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

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

Следующие шаги: пилот, масштабирование и поддержка

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

Пилот на 1-2 подразделениях

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

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

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

Когда стоит подключить интегратора

Интегратор обычно нужен, если источники данных разрознены (AD, VPN, VDI, SaaS, терминальные фермы) и нет единой картины, если требуется надежная инфраструктура для metering и отчетности без лишней нагрузки на пользователей, если есть строгие требования ИБ и приватности, а также если вы хотите связать metering с закупками и SAM-процессами.

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