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

Вопрос из зала: 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 РГ?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

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

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

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

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

    • Алексей Юсов

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

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

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

        В книге мы эти процессы не разделяем, поэтому вопрос Сергея абсолютно справедлив.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM