В управлении ИТ-активами легко принять внедренный инструмент за признак порядка: единая платформа учета, автоматическое обнаружение оборудования, интеграции с закупками и сервис-деском, дашборды и отчеты для руководства. Но само наличие системы не создает управляемость. Если не определены правила учета ИТ-актива, владельцы данных и порядок действий на каждом этапе жизненного цикла актива, сложный ITAM-инструмент лишь фиксирует существующий хаос — теперь в цифровом виде.
Практика показывает обратную последовательность: сначала компании нужен воспроизводимый бизнес-процесс, и только потом — инструмент для его автоматизации. Технология усиливает дисциплину, прозрачность и скорость принятия решений, но не создает их с нуля.
Когда ITAM не дает результата
Представим, компания внедрила полнофункциональное ITAM-решение, интегрированное с системой обнаружения ИТ-активов. Система дискаверинга выявляет устройства в сети и собирает сведения об установленном программном обеспечении, а ITAM-система использует эти данные для ведения учета, формирования карточек активов, сопоставления с договорами и лицензиями, контроля жизненного цикла и подготовки отчетности для финансовой службы.- Проект формально завершен: интеграции настроены, данные поступают. Однако через год руководство по-прежнему не может уверенно ответить на базовые вопросы: сколько конечных устройств действительно используется сотрудниками, какие лицензии куплены и доступны, кому принадлежат серверы, виртуальные машины и облачные подписки, какие активы уже выведены из эксплуатации, но продолжают числиться в учете.
Проблема как правило не в инструменте управления ИТ-активом. Она в том, что в компании так и не договорились, какие данные считать достоверными, кто отвечает за их качество и что делать при каждом изменении статуса актива.
Такая логика закреплена и в стандарте: ГОСТ Р ИСО/МЭК
Почему подход «включили и забыли» не работает
Сложная система часто внедряется как проект с понятной датой завершения. Но управление активами — не разовая задача. Меняются сотрудники, поставщики, договоры, подразделения, конфигурации инфраструктуры, модели лицензирования и облачные сервисы. Значит, должны регулярно обновляться и данные, и правила работы с ними. Наиболее типичные ошибки выглядят так.
Инвентаризация без управления изменениями. Компания настроила обнаружение оборудования и ПО, но не связала его с процессами выдачи, перемещения, ремонта, списания и изменения конфигураций. Карточки активов быстро теряют актуальность, а команда начинает вести параллельные таблицы «для надежности».
Отчеты без управленческого решения. Платформа выявляет неиспользуемые лицензии, устройства без владельца или серверы с устаревшими договорами поддержки. Но если не определено, кто рассматривает отчет, в какие сроки принимает решение и как фиксирует результат, аналитика остается лишь красивой визуализацией.
Зависимость от одного специалиста. Логика учета существует только в голове администратора или менеджера по активам: он знает, какие поля обязательны, как сверять данные и кому писать при расхождениях. Пока этот человек на месте, система работает. После его ухода компания получает заполненную базу, но теряет способность поддерживать ее качество.
Автоматизация исключений вместо правил. Инструмент настраивают под каждую частную ситуацию: отдельные маршруты для разных типов техники, договоров и подразделений. Если базовые статусы и правила не унифицированы, система становится сложной в сопровождении и непонятной пользователям.
Зрелая модель отличается не максимальным количеством полей в карточке актива, а тем, что ее можно объяснить, передать новому сотруднику и стабильно воспроизвести.
Процесс определяет требования к ITAM
Главный вопрос при выборе ITAM-платформы — не «какая у нее функциональность», а «какой конкретный процесс она должна поддерживать».
Компания, которая только начинает выстраивать учет активов, нередко покупает решение «на вырост», чтобы избежать повторной закупки через несколько лет.
Но широкая функциональность не превращается в ценность автоматически. Если организация пока не умеет надежно фиксировать факт поступления, назначения и возврата оборудования, сложная модель расчета совокупной стоимости владения не даст полезного результата. Если нет согласованных правил работы с программными лицензиями, система не сможет сама определить, какие лицензии можно перераспределить, а какие необходимо продлить.
Поэтому требования к инструменту должны формироваться от сценариев использования, а не от списка функций в презентации поставщика. Например:
- если задача контролировать использование лицензий и избегать штрафов при аудитах поставщиков, инструменту нужны точный учет установленного ПО, сверка с договорами и сигнал о превышении лимитов;
- если задача сократить расходы на оборудование, важнее функция повторного использования: статус «свободен», сроки гарантии и история обслуживания;
- если задача — безопасный вывод из эксплуатации, ключевым становится не факт обнаружения устройства в сети, а обязательный порядок действий: отключение доступа, удаление данных, обновление статуса, решение об утилизации;
- если задача — прозрачность для финансовой службы, нужна интеграция с бухгалтерским учетом и расчетом амортизации, а не только техническая инвентаризация.
В такой логике инструмент становится частью операционной модели. Его можно менять или развивать без нарушения самого процесса, поскольку правила учета, роли и контрольные точки уже определены.
Роли и ответственность не менее важны, чем интеграции
Управление ИТ-активами всегда находится на пересечении нескольких функций. ИТ-служба видит техническое состояние и фактическое использование, закупки — договоры и поставки, финансы — стоимость и амортизацию, информационная безопасность — требования к контролю и безопасному выводу из эксплуатации, HR — кадровые события, а бизнес-подразделения — потребность в ресурсах. Именно на границах этих зон чаще всего возникают разрывы.
Например, ИТ-команда может считать виртуальную машину действующим активом, потому что она технически существует в инфраструктуре. Финансовая служба может не видеть ее как отдельную единицу учета. Владелец бизнес-сервиса может не знать, что на этой машине работает устаревшее приложение, а служба ИБ — не иметь информации о ее критичности. В результате решение о выводе из эксплуатации откладывается: никто не готов подтвердить, что актив больше не нужен.
Ни одна платформа не устранит эту проблему сама. Для этого необходимо заранее определить:
- кто является владельцем данных по каждому классу активов;
- кто отвечает за актуальность технических, финансовых и договорных сведений;
- какие события меняют статус актива;
- кто утверждает передачу, списание, повторное использование и закупку;
- как разрешаются расхождения между данными из разных систем;
- кто контролирует соблюдение правил и эскалирует нарушения.
Полезный рабочий принцип: один актив — один ответственный владелец процесса и один согласованный источник правды для каждого типа данных. Это не означает, что вся информация должна физически храниться в одной системе. Но компания должна понимать, откуда берет серийный номер, стоимость, договорный статус, пользователя, техническую конфигурацию и статус жизненного цикла.
Первую сверку данных стоит проводить не ради того, чтобы немедленно исправить каждую ошибку, а чтобы выявить системные причины расхождений: где отсутствует интеграция, где не определен обязательный атрибут, где в компании нет единой терминологии и правил классификации активов, а где сотрудники обходят согласованный маршрут.
Какие метрики показывают зрелость ITAM
- Наличие регламента или заполненной базы активов еще не означает, что процесс работает. Реальную зрелость лучше оценивать по операционным показателям — тем, что отражают качество данных и способность компании принимать решения.
- Полнота учета. Доля активов, по которым есть обязательный набор данных: уникальный идентификатор, статус, владелец, местонахождение или сервис, дата приобретения либо начала использования.
- Точность данных. Доля активов, сведения о которых подтверждаются при сверке с фактическим наличием, системами обнаружения, закупочными документами или кадровыми данными.
- Доля активов без владельца. Если сервер, лицензия, мобильное устройство или облачная подписка не имеют ответственного лица или подразделения, ими трудно управлять: нельзя обоснованно продлевать расходы, оценивать риски и принимать решение о выводе из эксплуатации.
- Скорость обработки изменений. Время между событием и обновлением сведений в реестре: поставкой оборудования, выдачей сотруднику, увольнением, переносом, заменой компонента, деинсталляцией ПО или списанием.
- Доля повторного использования. Сколько возвращенных устройств и лицензий компания смогла перераспределить вместо новой закупки. Этот показатель напрямую связывает ITAM с экономическим эффектом.
- Количество расхождений при аудитах. Важна не только абсолютная цифра, но и динамика: уменьшаются ли повторяющиеся ошибки и устраняются ли их причины.
- Доля корректного вывода из эксплуатации. Для оборудования это закрытие доступа, удаление данных согласно политике компании, обновление учета и решение о дальнейшем использовании или утилизации. Для ПО — прекращение использования, освобождение лицензии и актуализация договорных данных.
Метрики не должны превращаться в самоцель для бизнеса. Их задача — подсветить слабые места процесса. Если доля активов без владельца растет, проблема может быть не в реестре, а в отсутствии связи ITAM с кадровыми и сервисными процессами. Если данные обновляются с большой задержкой, возможно, сотрудники не понимают своей роли или маршрут согласования слишком сложен.
Ошибки масштабирования
Одна из самых частых управленческих ошибок — решать проблему качества данных новой технологией. Компания видит неполный реестр и приобретает дополнительный инструмент дискаверинга. Затем оказывается, что устройств найдено больше, но часть из них дублируется, не привязана к владельцам или относится к тестовым и временным средам. Количество данных растет, а определенности не прибавляется.
Другая ошибка — пытаться внедрить единую модель без учета специфики подразделений. Компании необходимы общие для всех принципы учета, терминология, правила жизненного цикла активов и требования к качеству данных. При этом модель должна учитывать особенности филиалов, производственных площадок, дочерних обществ и проектных команд.
Важно не создавать отдельные, несопоставимые правила для каждого подразделения: это быстро приводит к «зоопарку» процессов и систем. Если единый ITAM-контур по объективным причинам невозможен, целесообразно использовать отдельные решения, но заранее определить порядок консолидации и сопоставления данных на корпоративном уровне.
Не менее рискованна автоматизация до согласования терминов. Когда одно подразделение понимает «выведен из эксплуатации» как «устройство отключено», другое — как «списано в бухгалтерском учете», а третье — как «передано на утилизацию», интеграции начинают передавать формально корректные, но управленчески противоречивые статусы.
Если компания не может ответить, какие решения она принимает на основе данных об активах и кто отвечает за каждое изменение статуса, новый инструмент добавит еще один источник данных, а не управляемости.
Простота как признак зрелости
Зрелый ITAM-процесс позволяет без лишних согласований понять, что это за актив, кому он нужен, в каком он статусе, сколько стоит компании и какое следующее действие требуется. Именно такую прозрачность должны поддерживать ИТ-инструменты.
В итоге многофункциональное решение оправдывает себя там, где уже есть дисциплина учета, распределенная ответственность и понятный жизненный цикл активов. В незрелой среде она способна лишь сделать непрозрачность более технологичной. Стандарты ITAM ориентируют организации на управление активами по всему жизненному циклу, а не на разовую инвентаризацию — поэтому основой результата становится не количество модулей в системе, а способность компании стабильно исполнять согласованные правила.
1 ГОСТ Р ИСО/МЭК
Источник: Евгений Мошняцкий, коммерческий директор НТЦ АРГУС
