Ситуация: у сотрудника сломался ноутбук. Не включается, диагностировать на месте бессмысленно. Инженер первой линии нашел на складе подменное устройство, выдал его за двадцать минут и закрыл заявку. Получилось, что время реакции в норме, время решения тоже, пользователь оценил поддержку на пять звезд. В отчете по SLA все показатели зеленые. Казалось бы – все идет отлично.

Но вдруг через месяц обнаруживается то, чего в отчете видно не было: такие заявки идут одна за другой. Да, поломки случаются без графика, но в этом квартале их оказалось особенно много, а на складе уже не осталось ни одного свободного устройства. Заявки копятся, сроки по SLA срываются один за другим, и закрыть их физически нечем. Инженер, вроде бы, делает ровно то же самое, что исправно работало месяц назад, но проблема в том, что выдавать больше нечего. Никто не посчитал, сколько подменных устройств еще есть на складе, и тем более нигде не было правила «пополнять склад, когда остаток падает ниже минимума». Из-за этого устройства закончились разом — склад не просигналил о нехватке заранее, когда это еще можно было поправить. «А мне когда нормальный ноутбук дадут, а не это убитое железо?», — спрашивает уже третий пользователь за неделю. И он прав, а ответить ему особо нечего.

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

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

Привет, это команда SimpleOne. Дальше разберем, зачем вообще связывать ITSM (систему управления ИТ-сервисами) и ITAM (систему управления активами) и что это дает сервис деску на практике. 

Виноват ли сервис деск?

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

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

Зачем сервис деску данные об активах

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

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

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

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

Как это работает

Разберем на примере связки SimpleOne ITSM — ESM-платформы для автоматизации ИТ-процессов, — и SimpleOne ITAM, которая ведет полный жизненный цикл актива: от регистрации до утилизации.

В основе лежат общая платформа и общие справочники: ITSM и ITAM работают на одних и тех же данных. У ITSM есть CMDB — централизованное хранилище данных об ИТ-инфраструктуре, а у ITAM — AMDB, логическая база управления активами, где по каждому устройству фиксируется вся история: регистрация, перемещения, бронирования, списание. AMDB связана с CMDB на уровне платформы: не нужна ночная выгрузка файлов между двумя разными системами, которые время от времени сверяют данные друг с другом вручную. Отдельную интеграцию между системами заводить не нужно — связь уже есть на уровне платформы. От этого сама работа по вводу и сверке данных об активах не исчезает: платформа убирает техническую стыковку систем; первичную инвентаризацию данных все равно делает кто-то вручную.

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

В чем еще польза для сервис деска

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

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

Резюме

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

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

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