Звонок от бизнес-заказчика с вопросом «Почему мой инцидент висит уже третий день?» — это, пожалуй, худший вид обратной связи для ИТ-директора. Если руководитель узнает о проблемах от пользователей, а не со своего дашборда, значит, управление услугами дает сбой.
Сегодня поговорим о дашбордах. В словаре слово dashboard переводится как «приборный щиток», «панель управления», но в области управления ИТ-услугами это слово вошло в обиход без перевода и вряд ли это удастся когда-то изменить. У любого ИТ-специалиста при упоминании слова «дашборд» перед глазами встает экран с цифрами и разноцветными графиками. Но это не просто красивые графики для презентаций, а основной инструмент, позволяющий перейти от реактивного «тушения пожаров» к проактивному управлению качеством ИТ-услуг.
Что такое ITSM-дашборд на самом деле?
Технически дашборд — это панель индикаторов, которая в реальном времени агрегирует данные из разных систем и показывает всё ли в порядке или где-то есть отклонения от нормы. Но суть глубже: назначение дашборда давать ответы на конкретные управленческие вопросы, а не показать «всё, что мы насобирали».
Зачем они нужны, если есть отчеты?
Классический отчет (например, ежемесячный Excel на 10 листов) — это кладбище фактов, в то время как дашборд — это командный центр. Есть три фундаментальных отличия:
- Проактивность вместо ретроспективы. В отчете мы видим, что SLA в прошлом месяце просело на 5% из-за аварии 15-го числа. Поезд ушел и уже ни как не повлиять на эту метрику. Дашборд покажет, что очередь необработанных заявок растет прямо сейчас, и дежурный менеджер может перераспределить нагрузку до того, как упадут показатели.
- Единый источник достоверной информации. На оперативках часто одни заявляют, что «Нам звонят и жалуются, что всё плохо», другие отвечают, что «Система показывает, что 90% заявок решаются вовремя». Дашборд поможет прекратить споры об ощущениях, переводя дискуссию в плоскость данных.
- Вовлечение команды. Публичный дашборд, транслируемый на мониторе в офисе поддержки, работает как табло на стадионе. Команда видит, как «счет» меняется в реальном времени и это мотивирует лучше любого приказа.
Компоновка метрик: от потока создания ценности к здоровью системы
Критическая ошибка новичков — помещать на дашборд все подряд: тут и процент решения при первом обращении (FCR), и загрузка CPU серверов, и любимые пирожки директора. Но это только создает шум.
Метрики нужно собирать в смысловые блоки, имитируя взгляд оператора. Один из подходов к компоновке — по логике движения потока создания ценности:
Блок 1: «Вход» (Спрос)
Здесь мы смотрим, что падает в воронку.
Метрики: Количество открытых обращений (топ-5 сервисов), доля заявок по каналам (портал, почта, телефон), процент инцидентов vs запросов на обслуживание.
Цель: Увидеть аномалии спроса (например, лавина звонков из-за сбоя сети).
Блок 2: «Процесс» (Пропускная способность)
Это «сердце» дашборда. Как быстро и качественно мы обрабатываем поток.
Метрики: Текущий % просрочки по SLA (светофор), среднее время в статусе «В ожидании пользователя», возраст старейшего открытого тикета, распределение нагрузки по группам/сотрудникам.
Цель: Поиск «узких мест» в реальном времени.
Блок 3: «Выход» (Качество)
Результат нашей работы с точки зрения пользователя.
Метрики: Уровень удовлетворенности (CSAT) за сегодня, процент решенных при первом обращения (FCR), процент переоткрытых заявок (Reopen Rate).
Три уровня управления — три разных дизайна
Также необходимо понимать кому предназначена информация, размещаемая на дашборде. Не стоит пытаться использовать один и тот же дашборд для всех ролей. Информация должна компоноваться и менять фокус в зависимости от горизонта планирования и зоны ответственности адресата информации.
1. CIO (Директор по ИТ): Стратегический уровень
Задача: понять «болит» ли сервис у бизнеса и эффективна ли команда в долгую.
Горизонт: Тренды (неделя, месяц, квартал).
Состав дашборда:
Сводный показатель здоровья сервисов (ИТ-светофор).
Динамика удовлетворенности бизнеса (CSAT, NPS тренд, а не цифра за день).
Объем использования ценных ресурсов (соотношение инцидентов к развитию).
Финансовый срез (стоимость инцидента, трудозатраты на некачественно выполненные запросы — «цена переоткрытия»).
Ключевой принцип: Исключения, а не детали. CIO должен видеть только красные кружки и аномалии трендов. Если всё зелено, дашборд не должен отвлекать его внимание.
2. Менеджер поддержки: Тактический уровень
Задача: Балансировка нагрузки и контроль операционной дисциплины.
Горизонт: Сегодня / Текущая смена.
Состав дашборда:
«Пульс» смены: входящий поток vs решенные.
Нарушения SLA в реальном времени (звуковое оповещение или мигание при критичности).
Текущая загрузка сотрудников.
Прогноз: успеваем ли мы разобрать очередь до конца дня.
Ключевой принцип: Управляемость. Менеджер видит, что инженер Петров взял 5-й инцидент подряд и «тонет», в то время как у Иванова простой. Значит, нужна координация.
3. Инженер / Технический специалист: Операционный уровень
Задача: Быстро видеть «свой фронт работ».
Горизонт: Прямо сейчас.
Состав дашборда:
Моя личная очередь: список назначенных тикетов с обратным отсчетом SLA.
Мои показатели за смену (игрофикация: «Ты закрыл 15, норма — 12, ты в топе»).
Подсказки: висяки (заявки без движения более суток, залипшие на коллегах).
Уведомления о критических событиях (Значительные инциденты), находящиеся в зоне ответственности сотрудника.
Ключевой принцип: ничего лишнего. Инженеру не нужно знать, сколько денег теряет компания из-за простоя или какова статистика по HR-отделу. Ему нужен четкий список дел на ближайший час.
Примерное содержание дашбордов в зависимости от ролей адресатов информации можно свести в такую таблицу:
|
Роль |
Зона ответственности | Содержание дашборда |
|
Директор по информационным технологиям |
Стратегия и бюджет ИТ Риски и непрерывность бизнеса Эффективность инвестиций |
ROI ИТ-проектов Статус ключевых бизнес-сервисов Количество критических инцидентов за месяц Тренды затрат |
|
Руководитель ИТ-подразделения |
Стабильность и работоспособность ИТ-инфраструктуры Управление инцидентами и изменениями Соблюдение SLA |
Инциденты: число открытых, среднее время устранения (MTTR/MTTA) Статистика затронутых инцидентами объектов инфраструктуры Изменения: соотношение успешных и неуспешных изменений Трудозатраты специалистов техподдержки и эксплуатации, нагрузка на персонал |
|
Дежурный оператор |
Физическая и виртуальная инфраструктура Сетевая связность и каналы Базы данных и СУБД |
Метрики оборудования: загрузка CPU, очередь процессов, объем занятой оперативной памяти, заполненность дисков, нагрев процессора, скорость вращения кулеров и др. Сеть: пропускная способность каналов, потеря пакетных данных, статус портов коммутаторов СУБД: число активных сессий, медленные запросы, статус репликации Схемы топологии сети, архитектурные карты дата-центров, таблицы текущих алертов |
Типичные ошибки при построении дашбордов
Напоследок три совета как избежать типичные ошибки, которые убивают пользу любого дашборда:
Не собирайте «космос». Если вы вывели на экран загрузку серверов, количество комаров в серверной и количество строк кода, это уже ситуационный центр, а не ITSM-дашборд. Используйте советы из этой статьи для компановки информации. Источник данных должен быть единым (ваша ITSM-система), либо интеграция должна быть бесшовной и логичной.
Не стремитесь к «монохромности». Если весь дашборд всегда зеленый, то либо у вас идеальный ИТ, либо вы неправильно настроили пороговые значения метрик. Дашборд, на котором никогда не загорается красный/желтый, бесполезен, так как не показывает точек для улучшения.
Соблюдайте правило «3 секунд». Взглянув на дашборд, руководитель должен за 3 секунды понять, есть ли проблема. Если ему нужно всматриваться и анализировать, то это плохой дизайн.
Дашборд — это не финальная точка цифровизации, а начало культуры управления на основе данных. Начните с малого: определите самую болевую точку (например, просрочку SLA на первой линии) и постройте один простой тактический дашборд для менеджера смены. Эффект от прозрачности не заставит себя ждать.
Какие метрики на ваших дашбордах вызывают больше всего споров у бизнеса? Делитесь в комментариях.
