— У меня ничего не открывается. Вообще ничего.
— Понял. Скажите, какой у вас ноутбук?
— Чёрный, прямоугольный такой.
— А примерно сколько ему лет?
— Ну... его выдали когда-то... давно…
Этот диалог происходит в сотнях компаний каждый день. Сотрудник поддержки не виноват — он делает всё правильно, пытается понять контекст. Просто у него нет другого способа его получить.
Всем привет, это команда продукта 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 минут способна обернуться потерями в миллионы рублей.
Формула для ваших цифр
Логика расчета прямая: из всего потока тикетов выделяем те, где оператору нужны данные об активе, считаем суммарное время поиска за год и переводим в деньги. Подставьте свои значения вместо наших — и получите свою цифру.
Потери в год = тикетов в день × 22 × 0,65 × 5 мин ÷ 60 × ставка оператора × 12
Подставьте свои значения вместо 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 году, гарантия истекла, а за последние три месяца по нему уже четыре обращения с той же проблемой. Решение очевидно: не чинить снова, а поставить вопрос о замене. Время на диагностику сокращается с десяти минут до меньше одной. По нашему опыту внедрений интеграция данных об активах с сервис-деском позволяет заметно сократить время обработки части обращений — особенно тех, где критичен контекст оборудования и история эксплуатации.
Было / Стало*
Без связки ITAM → SD | Со связкой | |
Время поиска данных об активе | 3–7 мин на тикет | < 1 мин |
Источник информации | Excel, чат, устный запрос | Карточка актива в тикете |
Точность диагностики | Частичная — нет истории | Полная — история + статус + финансы |
Повторные тикеты | 15–20% от общего объёма | 7–10% |
Эскалации на вторую линию | Каждый 3-й тикет с активом | Реже — контекст есть сразу |
Среднее время обработки тикета | ~12 минут | ~7 минут |
Управленческие решения по активам | На интуиции или вручную | На данных, в интерфейсе |
*Цифры по повторным тикетам, эскалациям и времени обработки — на основе собственных расчётов и практики внедрений. Ваши показатели могут отличаться в зависимости от специфики команды.
«Но у нас же уже есть учёт»
Самые частые возражения — и почему они не снимают проблему.
«У нас всё в AD / Intune»
Там есть устройства, но нет финансовой информации и истории владения. Intune знает, что ноутбук существует. Он не знает, что гарантия истекла три месяца назад и что за этот год по нему уже было пять инцидентов.
«У нас есть CMDB»
Она описывает инфраструктуру, но не отвечает за стоимость, контракты и амортизацию. CMDB — это «как это работает». ITAM — «сколько это стоит». Разные вопросы, разные данные.
«У нас Excel»
Данные есть, но они не встроены в процесс — оператор всё равно ищет их вручную, переключаясь между окнами. Плюс Excel не обновляется автоматически: ноутбук ушёл на склад, а в файле он всё ещё числится за сотрудником. Это и есть тот самый разрыв. Проблема в том, что все данные в таком случае живут отдельно от рабочего процесса.
Скрытые потери: что не попадает в отчёт
Прямые потери времени — только верхушка, под ней скрывается еще три категории издержек.
Повторные тикеты
Когда оператор решает симптом без понимания актива — пользователь возвращается. В нашем примере: если 15% тикетов возвращаются повторно, это ещё ~140 тикетов в месяц. Каждый требует повторного вхождения в контекст — ещё 12 минут операторского времени. В деньгах — около 195 000 ₽/год сверху к уже посчитанным потерям. В отчётах это выглядит как «много обращений», а не как «системная проблема в конкретном активе» — и никто не принимает решение о замене.
Слепые изменения
Без данных об активе изменения в инфраструктуре делаются вслепую: непонятно, что на чём стоит, кто зависит от этого сервера, есть ли действующий контракт на поддержку. Одно непродуманное изменение может превратить плановую работу в незапланированный инцидент.
Дублирующиеся расходы
Классика: одно оборудование попадает в два контракта с разными подрядчиками — компания платит дважды. Или 50% дорогих лицензий не используются. И происходит это потому, что данные разрозненны и никто не видит полной картины.
От «посчитать ноутбуки» до «принимать решения на миллионы»
Мы посчитали прямые потери сервис-деска. Но это только одна сторона проблемы. Отсутствие связки ITAM и сервис-деска означает не просто медленные тикеты, но и потолок, выше которого компания не поднимается в управлении IT-инфраструктурой.
Компании приходят к ITAM через три стадии зрелости.
Первая — инвентаризация: просто знать, сколько оборудования и где оно находится.
Вторая — контроль расходов: видеть стоимость активов, даты окончания контрактов, факты переиспользования лицензий.
Третья — управленческие решения.
Именно здесь начинается настоящая ценность: оператор видит, что сервер за полгода стал источником 12 инцидентов, а ITAM показывает, что его замена обойдётся в 400 000 ₽, но он уже самортизирован и стоимость простоев давно превысила эту сумму. Решение принимается на основе данных, а не интуиции.
Большинство компаний застревают между первой и второй стадией. Те самые ~1 071 000 ₽ ежегодных потерь — это цена первой стадии. Чем дольше компания на ней остаётся, тем дороже обходится каждый следующий год.
Резюме
Больше миллиона рублей в год — только прямые потери от ручного поиска на трёх операторах. Без повторных тикетов, неточных диагнозов, дублирующихся контрактов и просроченных лицензий.
Эти деньги — не «потери из-за неэффективности». Это стоимость архитектурного решения, которое не было принято.
Пока данные об активах живут отдельно от сервис-деска, компания платит за это каждый день, просто не видит счёт. Проблема не в операторах: они работают в тех условиях, которые им созданы. Решается она не регламентами и не мотивационными беседами, а изменением архитектуры процесса. Когда оператор открывает тикет, актив должен быть уже там.
***
А у вас оператор видит данные об активе сразу — или начинается квест?