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

Различают два основных типа отчётов и важно понимать, когда и для чего каждый из них применяется.

Оперативная отчётность: пульс вашей ИТ-инфраструктуры

Оперативные отчёты — это инструмент ситуационного управления. Они обновляются в реальном времени или с минимальной задержкой и отвечают на вопрос: «Что происходит прямо сейчас?»

Основное назначение оперативного отчета — это обеспечить контроль над текущей деятельностью, оперативно выявлять риски и отклонения от нормативов. Представьте себе некий дашборд «Монитор руководителя эксплуатации ИТ» — информационную панель, на которой видны все заявки в работе: какая уже просрочена, по какой нарушается соглашение об уровне услуг (SLA), кто из сотрудников перегружен. Это позволяет мгновенно перераспределять задачи и предотвращать сбои.

Показателями оперативной отчётности для сервис-деска могут быть:

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

Аналитическая отчётность: взгляд в прошлое для управления будущим

Если оперативная отчётность показывает состояние системы в моменте, то аналитическая позволяет увидеть тенденции и причины. Она формируется за различные календарные периоды (неделя, месяц, квартал) и отвечает на вопросы: «Почему это произошло?», «Как мы работали и что можно улучшить?»

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

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

Сравнение оперативного и аналитического отчетов

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

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

Больше информации на расширенном учебном курсе “ITSM. Основы управления ИТ-услугами (модуль расширения)” и на авторских курсах Cleverics

Отчеты как инструмент для поиска решений

Представьте, что в оперативном отчёте вы замечаете резкий рост заявок с пометкой «Нет доступа к CRM» в течение последнего часа. Оперативная панель показывает, что одна из команд поддержки перегружена и время реакции на её заявки превысило допустимое. Вы оперативно подключаете дополнительного специалиста, чтобы снять пик нагрузки.

Через неделю аналитический отчёт за прошедший период показывает, что инциденты с системой CRM составляют 40% от общего числа всех обращений, а их количество выросло на 25% по сравнению с прошлым месяцем. Сопоставив эти данные с графиком релизов, вы обнаруживаете, что рост начался сразу после обновления CRM-системы. Этот аналитический вывод запускает более глубокое расследование уже в рамках процесса управления проблемами. При этом аналитическая отчётность позволяет не только констатировать факт, но и оценить реальную стоимость простоев для бизнеса, чтобы обосновать инвестиции в развитие ИТ.

Практика построения отчётов на примере управления инцидентами

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

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

Блок 1. Сводка по SLA и объёмам. Здесь мы фиксируем общее количество инцидентов за месяц, долю решённых в срок и среднее время восстановления сервиса. Например, в отчёте за май видим: 412 инцидентов, 89% соблюдения SLA (целевой порог — 95%), среднее время восстановления — 4,2 часа против 2,8 часа в апреле. Данный набор показателей будет точкой отсчёта для совершенствования процессов. Цифры берутся из системы управления ИТ-услугами и не требуют дополнительных допущений.

Блок 2. Декомпозиция по категориям и причинам. Следующий шаг — разложить общую картину на составляющие. Группируем инциденты по категориям услуг и смотрим динамику относительно прошлого периода. В нашем примере категория «Доступ к корпоративным приложениям» даёт прирост на 37% (с 68 до 93 заявок), а категория «Рабочие станции» остаётся стабильной. Здесь же добавляем столбец с медианным временем решения по каждой категории — это помогает отделить «шумные» заявки от действительно проблемных. Оказывается, что в категории «Доступ к корпоративным приложениям» каждая четвёртая заявка требует эскалации на уровень L3, тогда как раньше эскалаций почти не было.

Блок 3. Причинно-следственный срез. Чтобы ответить на вопрос «почему», мы связываем рост инцидентов с изменениями в инфраструктуре. Сопоставляем данные отчёта с календарем релизов и видим, что за две недели до скачка было обновление политик аутентификации. Дополнительно выводим диаграмму «инциденты по часам суток», которая показывает, что пик обращений приходится на утренние часы, когда сотрудники массово входят в систему. Это может говорить о проблеме не в самих приложениях, а в процессе аутентификации при пиковых нагрузках.

Блок 4. Финансовый и ресурсный срез. Завершаем отчёт оценкой влияния. Рассчитываем трудозатраты команды на обработку этой категории инцидентов: 93 заявки × в среднем 45 минут на первую диагностику + ещё 2 часа на эскалацию для 25% случаев. Получаем около 120 человеко-часов за месяц, а это эквивалент почти трёх недель работы одного инженера. Сравниваем с бюджетом, заложенным на поддержку данной услуги, и видим перерасход на 40%.

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

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

Больше информации на расширенном учебном курсе “VAP: Построение эффективной системы KPI для ИТ (интенсив с тренером)” и на авторских курсах Cleverics

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую