Составные активы: что это такое и как ими управлять

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

Если не сразу — эта статья для вас.

Что такое составной актив и зачем его придумали

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

Типичные примеры:

• Серверы — дисковые массивы, модули памяти, блоки питания, контроллеры

• СХД (система хранения данных) — дисковые полки, контроллеры, дисковые массивы, блоки питания 

• АРМ (автоматизированное рабочее место) — системный блок, монитор, периферия, установленный софт

• Кассовые узлы и торговое оборудование со сменными компонентами

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

Почему плоского учета недостаточно

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

Сценарий первый: инцидент

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

Сценарий второй: бюджетное планирование

Финансовый директор просит обосновать закупку на следующий год. Сколько компонентов выйдет из строя? Когда именно? Какова стоимость замены? Если учет плоский, ответить на эти вопросы с цифрами невозможно — остается только экспертная оценка на основе опыта конкретного инженера, который, возможно, тоже уже не работает в компании.

При плоском учете системно теряется целый пласт операционно значимой информации:

1. Гарантийные обязательства на уровне компонентов. Когда актив — одна запись, непонятно, по какому контракту и у какого поставщика обслуживается конкретный модуль памяти или диск.

2. История замен и ремонтов. Кто, когда и что менял в этом сервере — хранится в головах людей или в переписке. При смене команды эти данные теряются безвозвратно.

3. Своевременное планирование замен и закупок. Чтобы обосновать бюджет на замену компонентов, нужно знать дату закупки, остаточный срок службы и стоимость замены. Без структурированного учета это прогноз на основе ощущений.

4. Аудит и инвентаризация. При проверке обнаруживается диск, которого нет ни в одной таблице. Как и когда он появился в сервере — неизвестно.

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

Учет составных активов и их компонентов

Рабочая модель строится на нескольких  уровнях: родительский актив и вложенные компоненты. Сервер — родительский. Диски, модули памяти, блоки питания, контроллеры — дочерние активы, каждый со своей карточкой.

На уровне каждого компонента необходимо хранить:

• Технические параметры: модель, серийный номер, производитель;

• Дату установки и срок полезного использования;

• Привязанный контракт на гарантийное обслуживание и данные поставщика;

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

Визуально структура выглядит как граф связей:

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

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

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

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

Что нужно от системы учета составных активов

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

1. Иерархическое представление — вложить актив в актив и видеть всю цепочку в наглядном виде.

2. Связи с контрактами и поставщиками на уровне каждого компонента, а не только родительского актива.

3. Контроль дат — срок гарантии, плановое ТО, срок полезного использования — с автоматическими оповещениями ответственным.

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

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

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

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

Как это работает: опыт ITGLOBAL.COM

ITGLOBAL.COM — международный системный интегратор и облачный провайдер с 17-летней историей, работающий в 12 странах. На каждой площадке — дата-центры и склады оборудования. Компания предоставляет расширенную поддержку серверного оборудования: хранит запасные компоненты и выдает оборудование как внутренним подразделениям, так и внешним заказчикам.

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

В конце 2024 года ITGLOBAL.COM внедрила SimpleOne ITAM за 6 месяцев силами собственной команды. Компания стала одним из первых заказчиков SimpleOne, кто начал вести составные активы в полном объеме: серверное оборудование в ЦОДах с полной иерархией компонентов.

Что изменилось:

1. Граф связей и списки по каждому составному активу. Видно, что во что входит. Из списка компонентов можно сразу создать задачу на ремонт или модернизацию для складских сотрудников или инженеров — без переключения между системами.

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

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

4. Охват всех 12 стран — движение актива прозрачно от склада хранения до конечного заказчика на всех международных площадках.

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

С чего начать, если учет сейчас в таблицах

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

1. Выберите 5–10 серверов или СХД, от которых зависят ключевые бизнес-процессы.

2. Для каждого составьте список компонентов с датами закупки, поставщиками и контрактами на обслуживание.

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

4. Занесите структуру в ITAM-систему с поддержкой иерархии.

5. Настройте оповещения по критичным датам: окончание гарантии, плановое ТО, срок полезного использования.

Типичные ошибки первого пилота повторяются из проекта в проект: берут слишком много активов сразу и теряют контроль над качеством данных на старте; не договариваются об обязательных полях до начала заполнения — и получают записи, где у одного актива есть серийный номер, у другого нет, у третьего поставщик указан как «Dell» в одной записи и «Dell EMC» в другой; не назначают владельца данных, и через три месяца непонятно, кто отвечает за актуальность. Пилот на 5–10 активах позволяет выявить эти проблемы до того, как они масштабируются на весь парк.

В следующий раз, когда в три часа ночи упадет блок питания, ответ на вопрос «кому звонить» займет десять секунд.

***

А у вас в компании бывало, что при поломке компонента приходилось искать, кому звонить по гарантии — и как долго это занимало?