Портал №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 РГ?

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

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

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

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

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

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

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

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

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

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

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

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


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM