Три ноутбука в реестре компании числятся как «Lenovo ThinkPad». Просто три строки в Excel, без модели, без конфигурации, без цены. Когда финансовый директор спрашивает «а это какие именно модели?» — в ответ звучит только «ThinkPad», и на этом все.

Хотя разница между ThinkPad T14 и ThinkPad P16 — это 80 тысяч рублей против 250 на балансе одной строки.

Списание, амортизация, планирование бюджета на замену техники упираются в один и тот же вопрос, на который никто не может ответить с ходу. Сотрудник склада запишет «леново», бухгалтер — «Lenovo Inc.», айтишник в тикете — «ThinkPad (Lenovo)», и в отчете по итогам квартала эти три записи превратятся в три разные строки вместо одной.

Таким образом в компании с парком в 15–50 тысяч устройств, распределенных по нескольким юрлицам и странам, та же проблема умножается на масштаб и превращается в системную неспособность закрыть финансовый и SOX-аудит вовремя.

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

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

Как обычно, дисклеймер: да, мы разрабатываем ITAM-систему. Но все, что ниже про справочники, — не про конкретный продукт, а про модель данных; работает в любой системе, где справочник хранится ссылкой, а не текстом.

Что такое справочники в контексте ITAM

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

Разрыв между отделами проявляется на конкретных операциях. Бухгалтерия амортизирует технику по группам основных средств и категориям, ИТ-отдел выдает и принимает оборудование по моделям и серийным номерам, склад считает штуки по локациям и статусам. Без единых справочников каждый отдел ведет свой список, и перед аудитом их сводят руками.

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

Справочники — не отдельная табличка сбоку, а часть CMDB. Через справочник модели и категории карточка актива Configuration Item, или КЕ встаёт в общую схему связей: видно, какой сервер держит какое приложение и какой актив относится к какому бизнес-сервису. Без этой связки справочник остаётся просто красивым списком — по нему не понять, что сломается, если упадёт конкретная железка.

Это же требует и стандарт ISO/IEC 19770-1:2017: у системы учёта активов должны быть внятные процессы, роли и правила ведения данных. Справочники с уникальными записями, на которые всё ссылается, — как раз способ это выполнить.

Какие справочники нужны — минимальный набор

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

Модели оборудования

Производитель + линейка + конфигурация — без этого справочника невозможно посчитать балансовую стоимость: «три ThinkPad» превращаются в диапазон от 240 тысяч (три T14 по 80 тыс.) до 750 тысяч рублей (три P16 по 250 тыс.) на балансе, и никто не скажет, какая сумма верная.

Величину этой неопределённости можно прикинуть напрямую:

Где:

• N — число единиц под одним неуточнённым названием,

• C (max) и C (min) — цена самой дорогой и самой дешёвой конфигурации, которые за этим названием скрываются.

Для трёх «ThinkPad» это 3 × (250 000 − 80 000) = 510 000 ₽ разброса на балансе одной строки. В парке из тысяч единиц с десятком неуточнённых моделей неопределённость складывается в миллионы, которые нельзя ни списать точно, ни заложить в бюджет на замену. В крупных компаниях этот справочник дополнительно ведёт каталог артикулов (SKU) для планирования закупок и типовых конфигураций при массовых заявках на подбор техники.

Локации

Здания, этажи, склады, стойки — без справочника локаций техника «есть в системе», но никто не знает, в каком городе и на каком складе она физически стоит, пока кто-то не поедет и не проверит руками. Для серверного оборудования локация — это еще и rack unit, power zone и cooling zone в ЦОДе, а не просто «этаж и кабинет».

Статусы жизненного цикла

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

Категории активов

Рабочие станции / серверы / сетевое / периферия / виртуальные машины / облачные ресурсы — без категорий отчет по типам техники превращается в один общий список, в котором сервер и мышь стоят в одной строке. В зрелой модели категория актива определяет, какой набор связей между конфигурационными единицами для него допустим и обязателен (например, "сервер обязан иметь связь Hosts с приложением").

Контрагенты

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

Типы контрактов

Гарантия / сервисный контракт / лизинг / подписка — без типов контрактов истечение гарантии узнают постфактум, когда сломанная техника уже не подлежит бесплатному ремонту. Этот же справочник должен покрывать лицензионные соглашения на ПО (perpetual, subscription, OEM) — без этого невозможно вести лицензионный учёт (SAM) и готовиться к аудитам производителей ПО (Microsoft, Oracle, SAP), которые требуют не менее детальной модели данных, чем учет железа.

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

Три антипаттерна

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

Свободный текст вместо справочника

Самая частая ошибка на старте: поле заполняется руками, без выбора из фиксированного списка — и каждый пишет как привык. Монитор Dell в одной карточке «Dell», в другой «Dell Inc.», в третьей модель вписана прямо в название актива. В отчете по производителям вместо одной строки появляется несколько, и система считает их разными сущностями.

Справочник, который никто не обновляет

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

Справочник без иерархии

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

Как внедрять — практический подход

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

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

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

Этап 1 — модели и категории

Без них ни одна карточка актива не создается, потому что модель и категория — это первые обязательные поля, которые определяют, что за объект вообще заводится в систему. На этом шаге достаточно закрыть технику, которая реально стоит на балансе прямо сейчас: выгрузить список из бухгалтерии или Excel, сгруппировать по производителю и линейке, убрать дубли вроде «Lenovo» и «леново». Категории на этом этапе можно ограничить крупными группами — рабочие станции, серверы, сетевое оборудование, периферия — детализацию и связку с классами КЕ для CMDB добавить позже.

Этап 2 — локации и статусы

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

Этап 3 — контрагенты и типы контрактов

Без них невозможно посчитать, сколько компания платит за обслуживание и когда истекает гарантия или лицензия на ПО. Справочник контрагентов собирают из накладных и договоров за последний год — обычно выясняется, что один и тот же поставщик записан под тремя разными юрлицами или названиями, и для крупной компании эта дедупликация может занять больше времени, чем остальная работа этапа (закладывайте на нее 2–3 недели отдельно, не блокируя запуск остальных справочников). Типы контрактов — гарантия, сервисный контракт, лизинг, подписка — привязывают к каждому активу с датой окончания, и это единственный способ получить список техники с истекающей гарантией одним запросом, а не ручным поиском по бумажным договорам.

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

Как это устроено в SimpleOne ITAM

Как работает ссылочная модель на практике, проще показать.

На гифке — карточка актива в SimpleOne ITAM: конкретный ноутбук ASUS Vivobook 15 со своей стоимостью, статусом гарантии и жизненным этапом.

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

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

Резюме

Разница между «у нас 1420 единиц техники» и «у нас 312 ThinkPad T14 Gen 3, из них 40 на складе в Петербурге, 12 с истекающей гарантией» — это разница между отчётом для галочки и отчётом, по которому реально принимают решения. Первую цифру даёт простой подсчёт строк в Excel. Вторую — только справочники, где зафиксированы модели, локации, статусы и контракты, а не свободный текст в карточках и комментарии к заявкам.

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

Компания, которая это сделала, отвечает аудитору за секунды. Компания, которая отложила на потом, ищет нужный ThinkPad среди трёх строк в Excel.

***

Какой справочник вы внедрили первым — и какой до сих пор откладываете или забыли обновить?