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

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

Почему компания не может посчитать, во что обходится ремонт

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

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

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

Карточка врёт о конфигурации сервера — и это стоит времени именно в момент инцидента

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

Инженер меняет жёсткий диск на такой же по объёму, но другого производителя — на складе был только такой. Закрывает наряд с пометкой «диск заменён», сервер работает. И на этом всё: закрыть тикет и обновить карточку в CMDB — разные шаги, а второй инженер часто просто не делает.

В карточке по-прежнему стоит старый диск. Через полгода на этом сервере — другой инцидент, специалист открывает карточку для диагностики и видит характеристики, которых в железе давно нет.

С памятью так же: заменили одну планку на 16 ГБ, а в карточке до сих пор четыре модуля по 8 ГБ. И когда дело дойдёт до амортизации или продажи, компания оценит сервер по данным, которые устарели ещё в момент ремонта.

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

Как считать: ремонтировать или списывать?

Сравните сумму ремонтов с нормой амортизации актива. По Классификации основных средств сервер относится ко 2-й амортизационной группе со сроком полезного использования от 2 до 3 лет — при трёхлетнем сроке актив теряет 33% стоимости в год, при двухлетнем — 50%.

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

1. Посчитать сумму ремонтов

• Блок питания — 8 000 рублей

• Та же деталь повторно — 8 000 рублей

• Контроллер RAID — 15 000 рублей

• Работа инженера на четыре вызова — 4 000 рублей

• Итого за год — 35 000 рублей

2. Посчитать амортизацию

• Если сервер стоит 100 000 рублей, норма амортизации в деньгах — 33 000 рублей в год

• Сумма ремонтов за последние 12 месяцев — 35 000 рублей (два блока питания, контроллер RAID, работа инженера)

• Сравнение — ремонты обогнали норму амортизации на 2 000 рублей

Сигнал к списанию: сумма ремонтов за год > годовая амортизация 35 000 ₽ ремонтов > 33 000 ₽ износа → чинить дальше уже невыгодно.

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

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

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

Если система управления активами имеет Low-code функциональность, эти настройки компания вообще может сделать сама, без ожидания доработок от вендора.

***

Если прямо сейчас поднять карточку любого сервера в вашей компании — вы увидите там реальную историю его ремонтов или просто дату последней инвентаризации?