Гарантия кончилась вчера, а сервер сгорел сегодня

Сервер выходит из строя вечером в пятницу. ИТ-служба звонит вендору — и слышит: «Гарантия закончилась два месяца назад». Ремонт обойдется в 180 000 ₽, продление поддержки стоило бы 45 000 ₽ в год, но срок никто не отследил.

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

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

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

Платим за то, что могли получить бесплатно

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

Точный размер потерь по рынку назвать нельзя — стоимость ремонта сильно зависит от модели сервера, характера поломки и региона. Формула переплаты за ремонт (оборудование еще на гарантии):

$\text{Переплата за ремонт} = \text{Ремонтов/год} \times \text{Доля на гарантии} \times \text{Цена ремонта}$

Где:

R — число ремонтов серверного оборудования за год;
Dг — доля ремонтов, пришедшихся на технику ещё на гарантии;
Cр — средняя стоимость одного такого ремонта в вашей организации.

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

Возьмем для примера цифру из истории в начале статьи: ремонт на 180 000 ₽.

Если в компании происходит 20 таких ремонтов в год, а возьмём осторожные 5% из них на оборудование, еще числящееся на гарантии (подставьте свою долю), — это один лишний ремонт в год, оплаченный из бюджета, хотя по факту он должен был быть бесплатным.

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

Сервер без поддержки — самый дорогой актив в компании

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

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

Вернемся к примеру из начала статьи: ремонт на 180 000 ₽ плюс несколько часов простоя дают инцидент, который по итоговой цене превышает несколько лет продленной поддержки за 45 000 ₽ в год.

Здесь речь не просто об экономии — «продлить заранее» обходится в разы дешевле, чем «чинить по факту».

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

В связке с 152-ФЗ это уже не только технический, но и юридический риск: с 30 мая 2025 года действуют поправки в КоАП РФ (ФЗ-420 от 30.11.2024), многократно ужесточившие ответственность за утечку.

При первом нарушении — фиксированные штрафы 3–15 млн ₽ в зависимости от объема утечки;
При повторном — оборотные 1–3% годовой выручки, но не менее 20 и не более 500 млн ₽ (ст. 13.11 КоАП РФ).

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

Откройте свою таблицу гарантий прямо сейчас

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

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

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

Антипаттерны: как компании теряют деньги на ровном месте

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

История 1. Пакетное продление вслепую

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

История 2. Серийники не те

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

История 3. Контракт есть, а вызвать некого

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

История 4. Напоминание уволилось вместе с сотрудником

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

О том, что делать, если сисадмин ушел, а учёт ИТ-активов был в его голове, мы уже рассказывали в другой статье.

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

Что же со всем этим делать?

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

Формула потерь и три способа перестать их нести

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

Формула ожидаемых потерь от пропущенного продления:

$\text{Ожидаемые потери} = \underbrace{N}_{\text{парк}} \times \underbrace{D_к}_{\text{доля критичных}} \times \underbrace{P_с}_{\text{вероятность события/год}} \times \underbrace{C_с}_{\text{цена события}}$

Где:

N — размер парка оборудования;
Dₖ — доля активов, от которых зависит работа бизнеса;
Pс — вероятность события за год;
Cₛ — стоимость одного события, если поддержка вовремя не продлена.

Чем крупнее парк, тем дороже обходится каждый пропущенный срок.

Уровень 1. Excel и ручные напоминания

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

Уровень 2. Реестр контрактов с уведомлениями

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

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

Уровень 3. ITAM — гарантия привязана к активу

На третьем уровне гарантия и сервисный контракт хранятся не сами по себе, а привязаны напрямую к конкретному активу в системе управления ИТ-активами. Это соответствует переходу от reactive к managed-уровню в типичных моделях зрелости учёта активов (напр.Gartner ITAM Maturity), где ключевой критерий — не наличие софта, а связность данных об активе, контракте и владельце в единой записи. Система заранее предупреждает ответственных о приближающемся сроке, а любой сотрудник может открыть карточку сервера и сразу увидеть дату окончания гарантии, дату окончания техподдержки и, если речь о лицензии, — срок ее действия.

Так выглядит карточка актива с датами покрытия и уведомлениями в SimpleOne ITAM — все ключевые сроки видны в одном месте, без необходимости поднимать переписку или звонить в закупки.

Наглядно логику уровня 3 можно представить как таймлайн:

90 дней до истечения контракта → 60 → 30 → 0 → событие.

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

Резюме

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

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

***

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

ссылка на оригинал статьи https://habr.com/ru/articles/1055942/