Представьте обычный понедельник: ИТ-менеджер открывает новую ITAM-систему (IT Asset Management), а вокруг уже десятки источников данных — выгрузка из 1С, Excel от закупок, список из Active Directory, таблица склада и файл «ноутбуки_финал_точно_последний.xlsx». 

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

Всем привет! Меня зовут Евгений Котухов. В этой статье я расскажу, как пройти первые 90 дней после старта ITAM, не утонуть в таблицах и быстро показать руководству результат.

Коротко: что нужно сделать за 90 дней

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

1. Недели 1–3 — договориться о цели, ролях, источниках и минимальной модели данных, результат: понятный пилотный периметр и правила работы с данными.

2. Недели 4–7 — загрузить первый класс активов, провести сверку и разобрать расхождения, результат: массив данных, которому можно доверять в выбранном периметре.

3. Недели 8–12 — запустить базовые процессы: выдачу, возврат, перемещение и инвентаризацию, результат: данные обновляются через процесс, а не вручную «по памяти».

4. После 90 дней — расширять периметр, подключать интеграции, аналитику, SAM и связку с ITSM/CMDB.

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

Для кого этот маршрут

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

Почему старт ломается

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

Ловушка 1. Ждать идеальных данных

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

Для старта нужна не идеальная, а честная база. Актив можно загрузить со статусом «требует проверки», а не держать его вне системы до полной сверки. Это лучше, чем откладывать запуск до состояния, которое почти никогда не наступает.

Ловушка 2. Загрузить все сразу

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

Начинать лучше с пилота: например, «понять, сколько ноутбуков реально на руках у сотрудников и сколько доступно на складах». Такой периметр можно проверить, обсудить с бизнесом и превратить в решение по закупкам.

Ловушка 3. Внедрять ITAM только силами ИТ

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

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

Ловушка 4. Запустить без владельца процесса

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

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

Фаза 0. Подготовка: недели 1–3

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

1. Определите цель и периметр

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

1. Снизить теневые закупки.

2. Понять, где находятся ноутбуки сотрудников.

3. Навести порядок на складах.

4. Подготовиться к аудиту.

5. Связать активы с заявками в ITSM.

6. Контролировать возврат оборудования при увольнении.

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

2. Назначьте роли

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

A — accountable, R — responsible, C — consulted, I — informed. 

Таблица не обязана быть большой, но она должна убрать фразу «за это отвечает ИТ в целом».

3. Проведите аудит источников

Соберите все источники, из которых потенциально можно загрузить данные: выгрузки Excel от ИТ и склада, 1С/ERP, AD или HR-систему, MDM (Mobile Device Management), discovery, EDR (Endpoint Detection and Response), закупки, CMDB и прошлые инвентаризации. Не ищите один «главный файл» — его почти никогда нет.

4. Согласуйте минимальную модель данных

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

• тип актива;

• модель или номенклатура;

• серийный номер;

• инвентарный номер;

• статус;

• склад или расположение;

• пользователь;

• материально ответственное лицо;

• подразделение;

• источник данных;

• дата последней проверки;

• комментарий по расхождению.

Чек-лист №1. Готовность к старту: 10 вопросов перед загрузкой

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

Фаза 1. Миграция: недели 4–7

После подготовки можно переходить к первой загрузке. Цель этой фазы — не перенести в ITAM все, что накопилось за годы, а проверить выбранный периметр на практике и получить первую достоверную картину.

1. Выберите пилотный периметр

Хороший пилот отвечает трем условиям: у бизнеса есть боль, есть хотя бы один источник данных, результат можно измерить через 3–4 недели.

Примеры:

Боль: не понимаем, сколько техники у сотрудников

Пилот: ноутбуки и мониторы, источники: выгрузки Excel от ИТ, 1С, AD/HR и склад, первый результат: список выданных и свободных устройств.

Боль: нет прозрачности по складам

Пилот: складские остатки ИТ-оборудования, источники: складская таблица, закупки, 1С, первый результат: актуальные остатки и расхождения.

Боль: готовимся к аудиту

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

Боль: растут расходы на закупки

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

2. Примените правило 80/20

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

3. Введите рабочие статусы

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

• заказан;

• получен;

• на складе;

• выдан;

• в ремонте;

• на возврате;

• требует проверки;

• нет физического подтверждения;

• кандидат на списание;

• списан;

• утилизирован;

• утерян или украден.

4. Проведите сверку и заведите реестр расхождений

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

Не обязательно проверять каждый актив вручную. Для пилота достаточно склада, одного подразделения или 10–15% записей. Но типы расхождений нужно фиксировать отдельно: нет серийного номера, спорный пользователь, не совпадает склад, актив есть в бухгалтерии, но не найден физически, устройство видно в MDM, но отсутствует в ITAM.

Фаза 2. Запуск процессов: недели 8–12

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

Для старта достаточно 2–3 процессов:

• выдача актива сотруднику;

• возврат при увольнении;

• перемещение между складами или подразделениями;

• плановая или выборочная инвентаризация.

Правила работы с нестандартными ситуациями

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

1. Если актив числится за уволенным сотрудником, создается задача на Service Desk и склад, статус меняется на «на возврате», владелец процесса контролирует срок закрытия;

2. Если актив есть в 1С, но физически не найден, запись не удаляется, ей присваивается статус «нет физического подтверждения» и запускается проверка с финансами;

3. Если устройство видно в MDM, но его нет в ITAM, создается кандидат на постановку на учет, до подтверждения оно не должно автоматически становиться финансовым активом;

4. Если два источника спорят о пользователе, приоритет должен быть определен заранее, например HR подтверждает сотрудника, Service Desk подтверждает выдачу, склад подтверждает физическое движение.

Интеграции: что подключать сразу, а что позже

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

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

SAM: что проверить на старте

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

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

Для первого SAM-периметра достаточно проверить:

•  какие лицензии куплены и по каким договорам;

• где продукт установлен;

• кто реально использует продукт;

• есть ли превышение купленных прав;

• есть ли неиспользуемые лицензии;

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

После 90 дней: куда расти

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

Дальше лучше двигаться итерациями

1. Расширить периметр на следующий класс активов;

2. Подключить дашборды по статусам, складам, расхождениям и списанию;

3. Связать активы с ITSM, чтобы поддержка видела историю устройства;

4. Углубить CMDB-связи для критичной инфраструктуры;

5. Запустить отдельный SAM-контур для дорогих вендоров;

6. Ввести регулярный контроль качества данных.

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

Чек-лист №2. Контрольные точки по неделям 

Резюме

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

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

***

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