База данных лицензионного ПО v.1, по ней специалист делал select count(*) from licenses where vendor = '1C'

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

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

Чтобы понять масштаб страданий, знайте, что в состав ОМК входит семь металлургических и машиностроительных предприятий, сервисная и торговая сети, более 10 000 пользователей. Мы работаем с 250 вендорами, у нас 800 наименований используемых видов ПО и сильно больше 100 000 лицензий в штуках.

Эта история началась в 2018 году, когда ушла в отпуск Мария, наш специалист по работе с лицензиями на ПО.

Что важно, на тот момент — единственный специалист.

Когда мы попытались разобраться, сколько лицензий в наличии, что кому выдано, то пришли в тихий ужас. Вместо единой базы было множество разрозненных источников, часть из них на компьютере, часть в общих сетевых папках. И всё это гнездо заботливо свито несколькими разными поколениями специалистов. А Мария была в этом хаосе как рыба в воде.

Мы решили навести в этом порядок, потому что разбираться руками с XLS-файлами, письмами с ключами и тетрадками в разных подразделениях нам казалось не очень современным. Напоминаю, на производстве так: объём задач бесконечный и можно брать и делать то, что сейчас нужнее. Вот мы решили запилить систему управления лицензиями.

Мы — это четыре человека, включая меня.

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

Как мы работали с лицензиями раньше?

Мы каждый год составляем бюджет на закупку лицензий. Соответственно, каждому предприятию, входящему в наш холдинг, отправляем запрос, что им необходимо. Ну или они сами присылают нам запросы на нужное ПО. Затем мы эти потребности обрабатываем, оцениваем и согласовываем вместе с ИТ-директором и основными заказчиками, которые участвуют в формировании бюджета.

Где-то на этом этапе у нас формируются план и график закупок.

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

Происходит это, к примеру, так:

• Через встроенный функционал на сервере лицензирования, который помогает отслеживать и снимать статистику.
• С помощью системы SCCM, через которую мы проводим массовые установки и обновления.

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

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

С использованием ПО есть некоторые риски.

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

Проверку может провести не только вендор, но и правоохранительные органы.

В целом, если выявляются нарушения, то это может привести к штрафам или требованиям компенсации. Например, 2 апреля 2024 года Арбитражный суд Республики Татарстан (дело № А65-13671/2023) постановил взыскать с одной компании компенсацию (в пользу правообладателя) за превышение количества разрешённых лицензий и обязал прекратить незаконное использование ПО.

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

Работа с этими рисками тоже ведётся по-разному.

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

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

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

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

Проблема в том, что не все вендоры и поставщики ПО позволяют так делать.
В общем, вариантов самих лицензий, как и работы с ними, на самом деле много. Так вот, до внедрения системы управления лицензиями (далее по тексту СУЛ) всеми вопросами, связанными с лицензиями, у нас управляла специалист по имени Мария, причём в ручном режиме.

В круг её обязанностей входило:

• Согласование лицензий. Например, приходил от пользователя запрос на выдачу лицензии и Мария решала, есть ли возможность её выдать этому человеку или нет. Иначе говоря, есть у нас такой программный продукт или его придётся закупить.
• Контроль лицензионной чистоты. Это анализ количества имеющихся у нас в наличии и используемых лицензий.
• Коммуникации с вендорами / производителями ПО. Мария вела переговоры по условиям предоставления лицензий. Тип лицензирования, стоимость, порядок продления и вот это вот всё.

Кроме этого, она брала на себя иногда и другие задачи — например, помогала разрабатывать автоматизированные отчёты и т. д. В общем, работы у неё было много, в какой-то момент это стало накапливаться как снежный ком, ей в помощь взяли ещё одного человека, но это уже совсем другая история.

Проблемы до внедрения СУЛ

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

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

Допустим, есть пользователь Иванов Иван Иванович с таким-то компьютером, на который установлено такое-то количество лицензий. И вот Иван Иванович уволился, на его месте сидит Пётр Петрович. А компьютер (мы называем его «каешка» от КЕ — конфигурационная единица) вообще ушёл Сидору Сидоровичу. И вот все эти перетасовки в блокноте или Экселе зачастую просто не отображаются, отследить их невозможно. Но в каждом из этих случаев нужен пересмотр подписки.

А теперь представьте, сколько в нашей компании предприятий, сколько в них работает человек и какое их количество поступает на работу или увольняется — ручным способом это всё фиксировать и отслеживать просто нереально.

Кроме того, ключи можно потерять, но на моей памяти такого не случалось.

Так как для Марии это была основная деятельность, то она в ней разбиралась, плюс наверняка создала какую-то «ментальную карту», которая позволяла ей запоминать и находить нужную информацию по лицензиям.

Нельзя сказать, что до этого мы не предпринимали никаких попыток автоматизации. Например, ещё в 2014 году мы создали базу для хранения актуальных дистрибутивов. Но работа с лицензиями велась в режиме «тушения огня» — то есть несистематично, путём ситуативного улучшения то там, то сям.

Ключевые задачи, поиск решений

Так вот, когда Мария ушла в отпуск, я с моим (на тот момент) руководителем осталась заниматься её задачами.

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

К некоторым из них у нас не было доступа.

У нас не было иного выбора, кроме как шерстить сам Service Desk, чтобы смотреть от кого и какие были обращения. Естественно, все её записи были в виде блокнота, по ним нельзя какой-то анализ провести.

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

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

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

Вот что мы хотели:

• Полную или хотя бы частичную автоматизацию управления лицензиями, запросами пользователей, контрактами с вендорами и т. д.
• Упорядоченное хранение информации о лицензиях и пользователях с нужными атрибутами и параметрами.
• Интеграцию с другими модулями — например, базой кадрового отдела, где хранится информация об увольнениях, переводах, приёме на работу других пользователей и т. д.
• Автоматизированное обновление данных при внесении изменений в базы данных.
• Быстрый доступ к СУЛ и хранящейся в ней информации.

Соответственно, нужна какая-то программа, которая бы удовлетворяла этим требованиям. И здесь было два варианта. Первый — поиск существующего решения на рынке. Вариант вполне себе, но у него были проблемы:

• Слишком высокая цена.

Точнее так — на рынке были недорогие решения, но они не покрывали бы потребности нашей компании, в составе которой множество предприятий. А те, что покрывали, стоили дорого. Напомню, что задачей специалиста по лицензированию была в том числе экономия на закупках. Поэтому было бы странно, если бы мы пришли такие к руководству: «Нам бы купить вот это с конской ценой». То есть денег-то нам бы наверняка дали, только не факт, что сразу и в том объёме, который нужен был для полной реализации задач.

• Отсутствие кастомизации.

У предлагаемых на рынке решений, как правило, стандартный функционал. Понятно, что бизнес-процессы во всех компаниях похожи, но и своя специфика тоже имеется. Хотелось, чтобы система эти особенности учитывала. Напомню, это был 2018 год, тогда модульные приложения, в которых можно ненужные блоки отключить, а нужные — добавить, только зарождались, они были сырыми. А готовые, отлаженные системы, представленные на рынке, предлагали много лишнего, что было уже реализовано в Service Desk. Например, у нас была служба управления ИТ-услугами и базами данных (CMDB). Но этого было недостаточно. Нам требовалась узкоспециализированная система для работы с лицензиями и подписками.

Поэтому практически сразу мы выбрали второй вариант — разработку собственной системы управления лицензиями.

Это позволило бы сразу настроить её именно под наши процессы, к тому же обошлось бы гораздо дешевле.

Забегая вперёд, скажу, что этот выбор полностью оправдался после реализации задуманного. Для сравнения, на тот момент использование готового облачного сервиса составляло: подключение — около 3 млн рублей, ежегодная оплата доступа — 2,4 млн.

Наша доработка существующей системы обошлась примерно в 300 тыс. рублей + 1 специалист на администрирование.

Разработка СУЛ, интеграция

Проектированием системы управления лицензиями мы занимались небольшой командой: я, Маша, наш коллега Дима, который взял на себя техническую часть работы, и Татьяна — она отвечала за методологическую сторону в части взаимодействия с Service Desk.

Собственно, мы с Машей отвечали за постановку задач — к тому моменту мы уже понимали, что конкретно хотим от продукта, какие проблемы он должен решить. На основе этого быстро сформулировали пользовательские требования к системе и функционал.

Сразу же мы столкнулись с главной проблемой — дефицитом ресурсов. Потому что у каждого из нас были, помимо лицензий, и другие задачи. А Дима вообще работал в другом отделе, а помогал нам понемногу в свободное время. Тем не менее прототип он выкатил быстро. К тому же он делал его не с нуля, а как модуль Service Desk. Плюс, возможно, сыграл тот факт, что все мы работаем в одной компании, понимаем её специфику, бизнес-процессы.

Дальше, уже когда прототип дорабатывался до рабочей версии, дело пошло со скрипом. Всё же на то, чтобы отточить функционал, учесть все нюансы, нужно было время — которое, естественно, наш технический специалист выделял по остаточному принципу.

А хотелки-то у нас масштабные.

Кстати, в системе остались потешные артефакты, например, в названии одного из блоков «оличие» вместо «отличие».

Другая проблема, возникшая сразу после создания рабочей версии СУЛ, — её наполнение. Она же изначально была пустая, и нужно было как-то перенести всю эту разрозненную информацию по контрактам и лицензиям в базу данных. Делали это, естественно, ручками — да, трудоёмко, пришлось попотеть и потратить время. Но это был необходимый шаг. Сейчас, уже как появляется новый запрос на лицензию, мы сразу вносим его в базу данных. Плюс какая-то информация автоматически поступает из систем, например HR.

Даже на данный момент не все проблемы до конца решены. Например, мы хотим сделать единый справочник ПО, интегрированный в систему. Который агрегировал бы все данные по конкретному продукту. Сейчас наша SCCM выдаёт разные списки, это не очень удобно. Проблема не критичная, жить особо не мешает, но иногда из-за этого приходится собирать данные вручную. Я думаю, что на рынке есть хорошие решения с таким функционалом, но они стоят денег.

Как работает система?

Для примера рассмотрим основное окно. Здесь есть несколько подразделов: наименование ПО, лицензии, подписки на лицензии и производители.

В основном окне отображаются:

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

Соответственно, мы видим, к примеру, когда эти лицензии нужно будет пересмотреть либо увеличить их объём (закупить дополнительные). Более того, если по каким-то причинам ПО перестало распространяться на территории РФ, то мы понимаем, какие области эти ограничения могут задеть, и начинаем искать альтернативы.

Что изменилось после внедрения СУЛ

Если бы мы не внедрили СУЛ, то было бы так.

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

Возможно, вы спросите: «В смысле Кирилл? А где Маша?» Она со спокойной душой ушла наводить порядок в другой компании, когда мы запустили и обкатали систему. Кстати, Маша, если ты читаешь этот пост, — шлём пламенный привет от всей команды!

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

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

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

На первых порах благодаря эффективному перераспределению мы сэкономили около 10 млн рублей. Если раньше мы мыслили контрактами («Нужно?» — «Нужно!» Предлагают — купили), то сейчас — масштабами всей компании. С помощью СУЛ лицензии можно консолидировать, что значительно упрощает их контроль. Соответственно, всё это позволило существенно снизить риск перерасхода бюджета на ненужные закупки.

Упорядочилось хранение данных. Раньше, чтобы нам проанализировать информацию по тому или иному контракту, нужно было поднять все договоры, и уже среди них найти конкретное соглашение. А теперь масштабируйте проблему: с одного договора до всех, которые у нас есть. Напомню, в нашу компанию входит семь металлургических и машиностроительных предприятий, сервисная и торговая сети. Это свыше сотни тысяч позиций лицензий. Теперь же в СУЛ в карточке лицензии указывается номер конкретного договора, по которому его можно найти и посмотреть всю иерархию в системе учёта договоров. Там же мы размещаем ключи, оставляем примечания, вложения и т. п. И мы всегда имеем быстрый доступ к полной информации по конкретной лицензии.

Своевременно обновляются сведения. Раньше, когда с лицензиями, пользователями, техникой происходили какие-то изменения, все они вносились в базу данных вручную. Естественно, что-то при этом терялось или фиксировалось неправильно. Сейчас либо изменения сразу автоматически заносятся в базу СУЛ из других БД нашей компании (отдела кадров, закупок, техподдержки и т. д.), либо нам приходит уведомление о необходимости пересмотра. Например, сотрудник перешёл в другой отдел или уволился — всё, лицензия помечается красным цветом, статус меняется на «Требует пересмотра». И мы её пересматриваем, решая, оставить ли её за этим пользователем или открепить. То есть у нас появился инструмент, позволяющий контролировать движение объектов лицензирования в реальном времени.

Мы работаем с СУЛ с 2019 года, и она полностью оправдывает вложенные в неё время и силы. Да, есть некоторые проблемы, требующие доработки. Но даже в таком виде она сделала работу с лицензиями гораздо легче, чем было до. Даже сейчас, несмотря на всю автоматизацию, это непростой процесс — в первую очередь из-за расширения нашей компании.

Но если с СУЛ это лишь сложно, то без неё было бы просто невозможно.