Портал №1 по управлению цифровыми
и информационными технологиями

Измерение процессов. Incident rate

Возможно ли, зная количество пользователей информационных технологий в той или иной компании, оценить среднее количество инцидентов в единицу времени?

У этого вопроса есть вполне прикладное значение:

  • либо прогноз потока, чтобы, например, оценить количество инцидентов при организации процесса управления инцидентами;
  • либо анализ потока, чтобы, например, определить ориентиры по повышению доступности за счёт сокращения текущего (известного) количества инцидентов.

Конечно, количество инцидентов существенно зависит от размера компании, а также от используемых информационных технологий. Диапазон широк – в моей практике были цифры от двух-трех десятков до тысяч инцидентов в день. Где же взять ориентир?

На этот счет есть некоторые цифры в виде метрики, которая традиционно называется Incident Rate. Она измеряет количество инцидентов, поступивших от пользователей, в месяц в расчете на одного пользователя. Опыт показывает (и наш, и международный), что значения этой метрики колеблются в гораздо более узком диапазоне, чем в примере выше (10-1000). Согласно доступным мне аналитическим отчетам эта величина находится в диапазоне 0.3-2.0 (специально недавно обновлял свои знания на этот счет). Причем данный диапазон зависит от отрасли (например, в банках значения выше, чем в энергетике) – это следствие влияния сложности применяемых информационных технологий и частоты их изменений.

Чтобы перейти к основному вопросу, ради которого я об том пишу, уточним алгоритм расчета метрики. В числитель ставим количество обращений пользователей категории инцидент, поступивших за месяц (инфраструктурные инциденты не учитываем). Лучше брать выборку за год в разбивке по месяцам, чтобы исключить сезонность. В знаменатель – количество пользователей ИТ (лучше исключить уволенных сотрудников и различные технические учетные записи, если справочник сотрудников в Вашей ITSM-системе реплицируется из Active Directory).

Используя данный расчет, я для разных компаний получал величину 0.4-2.3. Причем и 0.4, и 2.3 – это крайние случаи. Более типичный, усредненный, диапазон – от 0.8 до 1.2 (а всего по обращениям пользователей, включая и инциденты, и сервисные запросы – от 1 до 2). Но это по нашим заказчикам. Выборку интересно увеличить. Посчитайте, сколько получается у Вас? Поделитесь, пожалуйста.

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 13

  • Наталья

    Дмитрий, я так понимаю, описанный вами алгоритм больше для внутреннего ИТ подходит. Если мы говорим про поддержку конечных пользователей (продуктовая компания), то тяжелее посчитать этот параметр, т.к. с одной стороны можно взять количество активированных лицензий за период, но туда не входят пользователи, использующие версию продукта trial, а их (не просто скачавших, а установивших и использующих) посчитать почти невозможно... Хотя метрика достаточно интересная...

  • Vladimir Lyaleko

    В ТС для внутренних пользователей:

    1.59 инциденты

    2.99 запросы

    Для внешних:

    1.08 инциденты

    0.8 запросы

    В свое время указанная метрика учитывалась при обсуждении вопроса выделения управления запросами в отдельный процесс. Но это уже другая история 🙂

  • Юрий Алдунин

    У нас инциденты+запросы от пользователей лежат в диапазоне от 1 до 2 в месяц на человека (больше тяготеет к верхней границе) в зависимости от сезонных обострений и региона. Компания очень ИТ-зависимая:-)

    На предыдущем месте работы порядок цифр был 1,5-1,7 на человека в месяц. Компания не очень ИТ-зависимая, но на протяжении нескольких лет шёл процесс миграции на новую версию одного из основных бизнес-приложений.

    И в том и в другом случае речь о компаниях 1000+ сотрудников.

  • Коллеги, всем спасибо за ответы. Ждем еще!

  • Сергей Посыльный

    работаю в энергетике

    на 6000 пользователей (включая технических) среднее колличество заявок в месяц 9000

    • Сергей Посыльный

      9000 обращений не считая Регламентных работ.

      Из 9000 обращений 40% Инциденты типа Сбой

  • Михаил Кузнецов

    Дима, в знаменателе количество пользователей или рабочих мест?

    Сразу хочется исключить сменщиков, которые значительно исказят картину. Вспоминаю времена РОЛЬФа — на каждое рабочее место в зоне механиков по 6 сотрудников, работающих в смены. Как их правильно считать?

    • Для поиска ответов на вопросы, представленные в тексте поста, я бы считал количество пользователей. Для сменных работников это даст 3 человека на одно рабочее место. Действительно, на складах, в цехах на один компьютер может приходиться большее количество работников. Но:

      1. Надо еще посмотреть, как они будут отражены в расчете. Обычно большинство групповых рабочих мест работают под одним логином (кроме, пожалуй, кассы). Поэтому расчет в лоб для описанного тобой случая может дать не шесть пользователей, а именно одного.

      2. В любом случае вряд ли это сильно исказит средний расчет по компании.

  • Анастасия Кировская

    У нас, на 800 рабочих мест, получается также в пределах типичных диапазонов:

    инциденты = 0,42

    запросы = 1,68.

  • Алексей

    Дмитрий, добрый день. Ради интереса посчитал у себя ~650 пользователей инциденты = 1,44 обращения = 2,76 О чем могут говорить большие цифры данной метрики?

    • О том, что вероятно есть возможность оптимизировать ресурсы, сократив поток обращений / инцидентов 🙂


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT