Большинство ITAM-систем отлично справляются со сбором данных: подключают источники, собирают данные, строят карточки активов и генерируют отчеты. Но между сбором и доверием к этим данным при принятии решений лежит критически важный пласт работы — верификация. В типичных внедрениях он отсутствует.
Без контура верификации ITAM постепенно превращается в «справочник с ошибками». Эксплуатация перестает верить карточкам, ИБ сверяется со своими сканерами, а финансы живут по данным из 1С.
Разбираем 7 причин, почему инфраструктурная модель теряет достоверность, и показываем, как SkyV ITAM закрывает каждую из них.
1. Ошибки на входе: мусор в номенклатуре (НСИ)
Ошибка в номенклатурной позиции (НП) не остается в справочнике. Она каскадом бьет по закупкам, карточкам актива и финучету. Пользователь ошибся в шаблоне, пропустил атрибут — НСИ-специалист вручную разбирает завалы, закупки тормозят, дубли копятся.
Как решает SkyV ITAM:
В системе реализован гибридный сервис нормализации. Свободное описание на входе проходит несколько уровней:
Жесткие правила: регистр, единицы измерения, аббревиатуры.
Справочники: производитель, модель, тип актива из эталонного каталога.
LLM-классификация: подключается для нестандартных описаний.
Контроль уверенности: если LLM не уверена, система не заполняет поля «наугад», а формирует задачу НСИ-специалисту.
Типичный пример: Системный архитектор создает НП «Лицензия Microsoft SQL Server 2019 Standard», но забывает указать метрику лицензирования — Core или Server+CAL. Закупки, ориентируясь на типовую практику, заказывают лицензию Server+CAL. ИТ разворачивает SQL Server на виртуальном хосте с 32 ядрами, но лицензия Server+CAL не покрывает использование на виртуальных машинах — для легальной работы ИТ экстренно докупает лицензии Core, которых не было в бюджете. Деньги потрачены дважды: актив числится на балансе, но не закрывает бизнес-потребность, а финансовый директор видит нецелевое использование бюджета и риски при аудите. В итоге ИТ создает новую НП «Microsoft SQL Server 2019 Standard Core», закупки проводят повторную закупку, а НСИ-специалист разбирает дубли и объясняет финансам, почему по одному проекту числятся две разные лицензии на одно и то же ПО.
2. Инвентаризация не равна достоверному учету
Инструменты инвентаризации и discovery фиксируют факт: устройство присутствует в сети и получают, его технические характеристики: IP-адрес, MAC-адрес и другие, но не знают кому принадлежит сервер, какой договор связан, сходится ли найденный серийник с данными учета. Без сверки с системой учета инвентаризация создает лишь иллюзию полноты данных.
Как решает SkyV ITAM:
SkyV ITAM выполняет роль управленческого слоя, который сверяет данные из различных источников инвентаризации с учетными карточками:
Настраиваются политики идентификации по типам активов. Например: для серверов приоритет у серийного номера через IPMI/iDRAC, для ноутбуков — через BIOS, для ПО — по лицензионному ключу.
На основании найденных расхождений автоматически формируются задачи: актив в учете, но не в сети; или наоборот.
Важно отметить, что SkyV Discovery и SkyV ITAM являются двумя самостоятельными продуктами в линейке SkyV. SkyV Discovery отвечает за обнаружение и инвентаризацию: определяет, что фактически присутствует в инфраструктуре. SkyV ITAM преобразует эти факты в управляемую модель ИТ-активов. При этом ITAM работает не только с данными SkyV Discovery, но и с любыми другими источниками: SCCM, Kaspersky, vCenter, SNMP-сканерами.
3. Конфликт источников и отсутствие приоритетов
Данные об активе приходят из ERP, агентов инвентаризации, HR и закупок. Например, Ноутбук сотрудника в 1С (ERP) он числится с привязкой к ЦФО «Бухгалтерия» и остаточной стоимостью 50 000 руб. Агент видит, что MAC-адрес регистрируется на Wi-Fi точке «Офис Санкт-Петербург». А в Jira инженер создает тикет: «Перемещен в серверную СПб».
Без правил приоритета система либо хаотично перезаписывает атрибуты, либо сохраняет конфликт. Итог: противоречивые данные.
Как решает SkyV ITAM:
Администратор настраивает приоритеты источников в разрезе типа актива и атрибута.
Финансовые атрибуты (стоимость, ЦФО) берутся только из ERP и меняются через согласованный процесс.
Технические данные из агентов и сканеров обновляются автоматически, а все остальные расхождения уходят на ручной разбор.
Система фиксирует каждый конфликт и не допускает авторедактирования. Каждое решение журналируется (автор, дата, обоснование).
Закупается партия из 50 мониторов. В ITAM создается карточка «Монитор 27 дюймов». В ней не заполнены: производитель, точная модель, серийный номер, инвентарный номер. Мониторы развешаны по переговорным. Через год нужно провести физическую инвентаризацию. Сотрудник, проводящий инвентаризацию, приходит с карточкой «Монитор 27 дюймов» и не может понять, какой из 50 мониторов в комнате считать этим активом. В итоге 30 мониторов не проходят инвентаризацию, потому что их не с чем сверить. Финансы не могут корректно начислять амортизацию по группам, потому что неясно, это дорогие 4K-мониторы или дешевые офисные.
Не полными данными невозможно пользоваться в ходе аудита, в рамках процесса управления мощностями или финансовой отчетности.
Для каждого типа актива настроены шаблоны с указанием обязательных атрибутов:
Для Серверов: производитель, модель, серийный номер, CPU, RAM, HDD, артикул, hoatname или IP-адрес.
ПО: вендор, название продукта, параметры лицензирования.
Таким образом, создать карточку актива без заполнения обязательных полей невозможно. При нехватке данных система сама определит пробелы и предложит варианты для выбора.
Закупка лицензий на Microsoft Office. Московский филиал создает НП «Microsoft Office 2021 Professional Plus», а региональный — «MS Office 2021 Prof Plus RU». По факту это одно и то же ПО, но система видит их как две разные позиции. Без механизма поиска дублей по нормализованным атрибутам справочник разрастается, данные утрачивают целостность, Справочник разрастается, аналитика искажается.
Поиск дублей идет по нормализованным атрибутам с расчетом процента совпадения:
≥ 90%: система блокирует создание и требует явного подтверждения пользователем.
70–89%: выводится список кандидатов для ручного решения.
< 70%: информационное уведомление без блокировки.
Пороги совпадения администратор настраивает индивидуально под каждый тип актива.
Ошибки находят случайно, правят в рабочих чатах, без журналов и повторных проверок. Качество данных зависит от личной инициативы сотрудников.
Управление качеством данных реализовано как формализованный бизнес-процесс с полным жизненным циклом задачи:
Обнаружение проблемы (автоматически или вручную).
Создание задачи и назначение ответственного по ролевой модели (дубли ➔ НСИ, расхождения со сканерами ➔ ИТ, конфликты ➔ владелец данных).
Внесение исправлений и повторная верификация.
Закрытие задачи с сохранением полной истории изменений.
В бухгалтерии 10 серверов, по факту в сети 8. Причины расхождений неясны, ЦФО не проставлены. Отчетам по затратам не могут верить ни ИТ-директор, ни CFO.
Система замыкает финансовый контур на жизненный цикл актива.
Каждый актив жестко связывается с ЦФО, договором и балансовой стоимостью (от потребности до списания).
Автоверификация: если нет ЦФО или стоимости — система сама ставит задачу владельцу.
Сопоставление плановой и фактической стоимости: при превышении лимитов срабатывает блокировка и эскалация.
Верификация данных представляет собой самостоятельный управленческий контур, без которого ITAM-система не может обеспечить достоверность инфраструктурной модели.
Неважно, сколько источников вы подключили и какой сканер используете. Если между сбором данных и принятием решений нет слоя, который нормализует, сверяет и инициирует исправления, ваша модель инфраструктуры будет деградировать.
SkyV ITAM выстраивает этот контур «под ключ»: от нормализации на входе до финансовой верификации и управляемых задач. А SkyV Discovery обеспечивает этот контур фактами из инфраструктуры. Вместе они формируют единую достоверную модель ИТ-активов организации.
Хотите увидеть контур верификации в действии?
Запросите демонстрацию сценария: «Источник → Нормализация → Расхождение → Управляемое действие».