Вопрос из зала: KPI для параллельных работ

После выхода нашей книги "ITSM. Руководство по измерению", читатель Сергей, внимательно её изучающий, задаёт вопрос:

dragraceРеализуем метрики согласно вашей замечательной книги

Сейчас застопрорились на метрике TPI в рамках РГ (стр.39-42 книги формулы 8-10)

Рассмотрим ситуацию в рамках выполнения обращения привлечены в рабочие группы. Они работают параллельно. 

Пусть обращение хочу хорошую погоду (не придирайтесь — это пример)

SLA (T) по обращению 8 часов

1 рабочая группа задача убрать снег

2 Рабочая  группа разогнать облака

1 Рабочая группа справилась в срок и все сделала за 2 часа

2 Рабочая группа справилась за 12 часов и нарушила срок

Для РГ2 TPI = 0

А для РГ 1?

0,75 — согласно формуле?

Или же 1 ?

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

А как правильно поступать при параллельных работах? 

Обращение в целом нарушено, но есть вина в данном нарушении 1 РГ?

CleverKPI Сбалансированная система управления информационными технологиями по KPI

Измерение и оценка эффективности ИТ-процессов, проектов и услуг.
 

Узнайте больше!

Комментарии и мнения

  1. Дмитрий Исайченко

    Сергей, огромное Вам спасибо – Вы прислали отличный вопрос. Ответ:

    1. значение KPI для РГ1 = 0,75 (Вы посчитали правильно);

    2. исходя из представленного примера, вины РГ1 в просрочке данного конкретного запроса нет.

    И всё это действительно можно считать изъяном данной формулы – она таких тонкостей не учитывает. НО какова цена исправления? Решение-то очевидно – надо снижать оценку только тех групп, задачи которых лежали на критическом пути общей работы. Но для управления инцидентами это, пожалуй, слишком сложно.

    Кроме того, в отличие от проектов, инциденты обрабатываются не единицами, а десятками и сотнями, а на больших выборках Ваш пример сгладится другими. Если же РГ1 только и делает, что разгребает снег, и к пришитым ею пуговицам (то есть расчищенному снегу) претензий нет, а за большее она не отвечает и к хорошей погоде в целом отношения не имеет, вводите для неё OLA и назначайте отдельные обращения / задания, а не исходный запрос про погоду.

    1. Алексей Юсов

      Дмитрий, пример автора — типичный RFC. А метрики инцидентов и запрос — разные вещи, и универсальные формулы здесь не годятся, тут Вы правы.

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮЛ
3
Учебный курс:
Основы ITIL (очно)