После выхода нашей книги "ITSM. Руководство по измерению", читатель Сергей, внимательно её изучающий, задаёт вопрос:
Реализуем метрики согласно вашей замечательной книги
Сейчас застопрорились на метрике TPI в рамках РГ (стр.39-42 книги формулы 8-10)
Рассмотрим ситуацию в рамках выполнения обращения привлечены в рабочие группы. Они работают параллельно.
Пусть обращение хочу хорошую погоду (не придирайтесь — это пример)
SLA (T) по обращению 8 часов
1 рабочая группа задача убрать снег
2 Рабочая группа разогнать облака
1 Рабочая группа справилась в срок и все сделала за 2 часа
2 Рабочая группа справилась за 12 часов и нарушила срок
Для РГ2 TPI = 0
А для РГ 1?
0,75 — согласно формуле?
Или же 1 ?
В чем суть вопроса. Приведенные формулы хороши для ситуации приведенной на рисунке 8, т.е работ проходящих последовательно.
А как правильно поступать при параллельных работах?
Обращение в целом нарушено, но есть вина в данном нарушении 1 РГ?
Сергей, огромное Вам спасибо – Вы прислали отличный вопрос. Ответ:
1. значение KPI для РГ1 = 0,75 (Вы посчитали правильно);
2. исходя из представленного примера, вины РГ1 в просрочке данного конкретного запроса нет.
И всё это действительно можно считать изъяном данной формулы – она таких тонкостей не учитывает. НО какова цена исправления? Решение-то очевидно – надо снижать оценку только тех групп, задачи которых лежали на критическом пути общей работы. Но для управления инцидентами это, пожалуй, слишком сложно.
Кроме того, в отличие от проектов, инциденты обрабатываются не единицами, а десятками и сотнями, а на больших выборках Ваш пример сгладится другими. Если же РГ1 только и делает, что разгребает снег, и к пришитым ею пуговицам (то есть расчищенному снегу) претензий нет, а за большее она не отвечает и к хорошей погоде в целом отношения не имеет, вводите для неё OLA и назначайте отдельные обращения / задания, а не исходный запрос про погоду.