— У меня ничего не открывается. Вообще ничего.
— Понял. Скажите, какой у вас ноутбук?
— Чёрный, прямоугольный такой.
— А примерно сколько ему лет?
— Ну... его выдали когда-то... давно…

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

Всем привет, это команда продукта SimpleOne ITAM. Наш продукт живет на стыке управления активами и сервис-деска, поэтому мы давно наблюдаем одну и ту же картину: данные об активах есть, а до оператора они не доходят.

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

Отдельную благодарность за помощь в написании статьи выражаем автору SimpleOne Яне Панфиловой и эксперту по цифровой трансформации ИТ-процессов Евгению Котухову.

CMDB, ITAM и discovery: где заканчивается одно и начинается другое

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

Многие компании уже используют инструменты, которые частично закрывают задачу: Intune и SCCM знают, какие устройства существуют и какой на них софт. CMDB описывает, как устроена инфраструктура и что от чего зависит.

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

Считаем на конкретном примере

Для расчёта возьмём условную производственную компанию с типичными для отрасли параметрами: 900 сотрудников, сервис-деск из трёх операторов первой линии. В среднем они обрабатывают от 40 до 45 тикетов в день — возьмём 43. Бывают всплески, бывают тихие пятницы, но примерно так выглядит типичная неделя.

По данным hh.ru, средняя зарплата специалиста технической поддержки в 2025 году составила около 67 000 ₽. В московских компаниях вилка, как правило, выше — 60 000–80 000 ₽ на руки.

С учётом НДФЛ и страховых взносов полная стоимость сотрудника для компании — примерно 90 000–108 000 ₽/мес.

При 167 рабочих часах стоимость часа — ≈ 540–647 ₽. В расчёте возьмём 580 ₽/ч — середина диапазона.

Считаем

Тикетов в месяц на одного оператора:

43 × 22 рабочих дня = 946 тикетов

Тикетов, где оператору потребовались данные об активе — около 65%. Эта доля типична для производственных компаний: в нашей практике внедрений она варьируется от 55% в простых очередях до 75% в технически насыщенных:

946 × 65% = ≈ 615 тикетов

Время на поиск в месяц:

615 × 5 мин = 3 074 мин = ≈ 51 час

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

В год:

51 × 12 = ≈ 615 часов

В деньгах (1 оператор, 580 ₽/ч):

615 × 580 = ≈ 357 000 ₽/год

Это потери на одного оператора. В нашем примере три оператора первой линии:

357 000 × 3 = ~1 071 000 ₽/год — столько компания тратит только на ручной поиск данных об активах.

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

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

Формула для ваших цифр

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

Подставьте свои значения вместо 0,65 и 5 минут

Где:

• T_days — тикетов в день

• P_asset — доля тикетов с поиском данных об активе (0,6–0,7)

• T_search — время поиска в минутах (3–7)

• Rate — стоимость часа оператора в рублях

Если лень считать — возьмите среднее: 5 минут и 65%. Это даст достаточно точную картину.

Например, если у вас 30 тикетов в день, 60% из них требуют данных об активе, а поиск занимает 4 минуты — это уже около 200 000 ₽ в год только на переключения и поиск. 

Когда компания в 20 раз больше

Евгений Котухов, эксперт в области ITAM и ITSM-проектов, приводит данные из практики крупной компании.

Компания — около 20 000 сотрудников с распределённой инфраструктурой. За пять месяцев текущего года зафиксировано 29 000 обращений в Service Desk, из которых 20 000 — инциденты, требующие оперативного реагирования.

Около 4 500 обращений (15%) напрямую связаны с оборудованием: пользовательские рабочие места, специализированная периферия на точках обслуживания и корпоративная инфраструктура. Это 53 обращения в день только по прямым случаям с оборудованием. При этом в оставшихся 85% обращений оборудование фигурирует косвенно — реальная доля выше.

Учитывая, что большинство обращений — инциденты, задержка даже в 5 минут на идентификацию актива критична. При таком объёме суммарные потери только на поиск оборудования — свыше 4 часов операторского времени ежедневно.

Минута против десяти: что меняет карточка актива в тикете

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

Без связки: спросил → не нашёл → эскалация

Тикет открылся. Оператор видит имя пользователя и тему — и всё. Что за устройство, когда куплено, есть ли гарантия, что уже ломалось — ничего этого нет. Он заходит в CMDB, а там данные устарели или отсутствуют. Пишет в чат коллеге, ждёт. Параллельно у него открыто 5–7 тикетов, и каждый такой возврат приводит к  потере контекста и времени на повторное вхождение в задачу. Если ответ пришёл с опозданием или оказался неточным оператор закрывает тикет «как умеет», а такие тикеты, как правило, возвращаются.

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

Со связкой: актив уже здесь

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

Было / Стало*

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

«Но у нас же уже есть учёт»

Самые частые возражения — и почему они не снимают проблему.

«У нас всё в AD / Intune»

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

«У нас есть CMDB»

Она описывает инфраструктуру, но не отвечает за стоимость, контракты и амортизацию. CMDB — это «как это работает». ITAM — «сколько это стоит». Разные вопросы, разные данные.

«У нас Excel»

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

Скрытые потери: что не попадает в отчёт

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

Повторные тикеты

Когда оператор решает симптом без понимания актива — пользователь возвращается. В нашем примере: если 15% тикетов возвращаются повторно, это ещё ~140 тикетов в месяц. Каждый требует повторного вхождения в контекст — ещё 12 минут операторского времени. В деньгах — около 195 000 ₽/год сверху к уже посчитанным потерям. В отчётах это выглядит как «много обращений», а не как «системная проблема в конкретном активе» — и никто не принимает решение о замене.

Слепые изменения

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

Дублирующиеся расходы

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

От «посчитать ноутбуки» до «принимать решения на миллионы»

Мы посчитали прямые потери сервис-деска. Но это только одна сторона проблемы. Отсутствие связки ITAM и сервис-деска означает не просто медленные тикеты, но и потолок, выше которого компания не поднимается в управлении IT-инфраструктурой.

Компании приходят к ITAM через три стадии зрелости.

• Первая — инвентаризация: просто знать, сколько оборудования и где оно находится.

• Вторая — контроль расходов: видеть стоимость активов, даты окончания контрактов, факты переиспользования лицензий.

• Третья — управленческие решения.

Именно здесь начинается настоящая ценность: оператор видит, что сервер за полгода стал источником 12 инцидентов, а ITAM показывает, что его замена обойдётся в 400 000 ₽, но он уже самортизирован и стоимость простоев давно превысила эту сумму. Решение принимается на основе данных, а не интуиции.

Большинство компаний застревают между первой и второй стадией. Те самые ~1 071 000 ₽ ежегодных потерь — это цена первой стадии. Чем дольше компания на ней остаётся, тем дороже обходится каждый следующий год.

Резюме

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

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

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

***

А у вас оператор видит данные об активе сразу — или начинается квест?