На демонстрации почти любая ITAM-система выглядит убедительно. В карточке оборудования заполнены десятки атрибутов, на дашборде подсчитаны серверы и рабочие станции, поиск мгновенно находит нужный серийный номер. Но все это еще не доказывает, что решение умеет управлять ИТ-активами. Разница становится заметна, когда поставщика просят показать не карточку и не отчет, а сквозной процесс: как система проверяет резерв перед закупкой, фиксирует передачу оборудования сотруднику или подрядчику, связывает лицензию с договором и фактическим использованием, обрабатывает расхождение между складским и техническим учетом.

Поэтому выбирать ITAM стоит не по набору функций в презентации, а по тому, как система работает в конкретных процессах компании. Чтобы это проверить до подписания договора и запуска пилота, мы собрали десять вопросов поставщику. Они помогут ИТ-директору, CTO, руководителю ИТ-инфраструктуры и группы системного администрирования понять, перед ними полноценная система управления активами или еще один цифровой реестр оборудования.

Такой подход соответствует ISO/IEC 19770-1 и его российскому аналогу ГОСТ Р ИСО/МЭК 19770-1-2021. Стандарты рассматривают ITAM не как отдельную базу оборудования, а как систему управления ИТ-активами, связанную с другими корпоративными процессами и информационными системами. Поэтому оценивать нужно не количество экранов и атрибутов, а то, какие действия система поддерживает на протяжении жизненного цикла актива.

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

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

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

Журнал редактирования карточки не заменяет управление жизненным циклом. Он может показать, кто изменил поле «Местоположение», но не объяснит, почему оборудование переместили, кто согласовал действие и какой процесс должен начаться дальше.

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

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

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

В зрелой архитектуре одна система не обязательно является источником всех сведений об ИТ-активе. Финансовые атрибуты могут поступать из систем на базе 1С или ERP, технические - из NRI или CMDB, данные о движении - из складской системы. Поэтому поставщик должен объяснить, какая система является источником для конкретного атрибута и как разрешаются конфликты между данными.

Фраза «системный администратор при необходимости все поправит вручную» должна насторожить. При таком подходе ITAM быстро превращается в таблицу с расширенными правами редактирования.

Один из наиболее понятных экономических эффектов ITAM - возможность не покупать то, что уже есть в компании.

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

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

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

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

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

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

Попросите поставщика показать, как система различает эти роли и что происходит при изменении роли пользователя или прекращении его связи с активом. Например, как запускается возврат оборудования при увольнении сотрудника, завершении договора с подрядчиком или прекращении оказания услуг клиенту.

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

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

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

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

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

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

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

ITAM не должен заменять финансово-бухгалтерские решения, корпоративную ERP, NRI, CMDB, сервис-деск или складскую систему. Его задача - связать данные между функциональными контурами, определить источники для разных атрибутов и поддержать процессы вокруг актива.

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

Отдельно запросите оценку интеграций с системами на базе 1С, ERP, CMDB, ITSM-системой и инструментами автоматического обнаружения оборудования. Оценка должна включать не только разработку, но и тестирование, поддержку и последующие изменения.

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

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

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

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

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

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

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

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

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

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

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

В зависимости от задач это может быть сверка финансового, складского и технического учета; проверка резерва перед закупкой; инвентаризация распределенного парка; контроль оборудования у сотрудников, подрядчиков и клиентов; управление лицензиями и подписками; интеграция с 1С, ERP или ITSM; обработка выявленных расхождений.

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

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

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

• карта пилота с бизнес-сценариями, участниками, источниками данных и критериями успеха;

• матрица интеграций с системами-источниками, направлениями обмена, готовыми коннекторами, необходимыми доработками и зонами ответственности;

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

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

Полноценная ITAM-система ценна не количеством карточек в единой базе. Она формирует согласованную картину оборудования, программного обеспечения, лицензий и связанных с ними затрат, объединяя атрибуты из разных систем-источников.

Такой контур позволяет контролировать стоимость владения активами, учитывать расходы на техническое обслуживание и модернизацию, планировать обслуживание до возникновения отказов и сокращать объем ручной работы при инвентаризации. Для программных активов ITAM помогает сопоставлять фактическое использование ПО с количеством приобретенных лицензий, выявлять избыточные или недостающие лицензии и готовить данные для внутренних проверок и внешнего лицензионного аудита со стороны правообладателя или его представителя. В результате данные об активах становятся основой для управленческих решений, а ITAM выходит за пределы автоматизированного учета.

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