Основные KPI для ИТ. Часть 4. Уровень доверия бизнеса к ИТ (запросы на изменение)

Завершая блок по уровню доверия бизнеса к ИТ хочется рассмотреть еще два показателя: стабильность внедренной функциональности и количество переносов плановой даты выполнения задачи.

Начнем со стабильности работы ИТ сервисов при запуске новой функциональности. Первый отчет – стабильность релизов. Здесь можно использовать следующие определения для построения отчета:

  • Релизом считается обновление рабочей среды, если было внедрено более 10 задач.
  • Анализируем количество созданных инцидентов к закрытым задачам в рамках переноса релиза на рабочую среду.
  • Инциденты относятся к конкретному релизу, если были заведены в день релиза или на следующий день, если нет четкой связи между релизом и инцидентом.

Имея указанные выше цифры, отчет построить достаточно просто как по месяцам, так и по релизам:

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

Несколько возможных примеров:

  • Время жизни инцидента в разрезе по бизнес подразделениям:
  • Причины возникновения инцидентов

Так же можно смотреть какой конкретно сотрудник находит нам максимальный объем работы, по исправлению его ошибок, какое направление бизнеса слабо тестирует функциональность на применяемость в своей работе и т.д. Соответственно ИТ руководитель видит не только объем ошибок, но может понять причины возникновения и точечно устранять их, тем самым снижая объем инцидентов и как следствие повышая уровень доверия к ИТ.

Второй вид отчета, о котором я хотел рассказать – это кол-во переносов плановой даты решения задачи. Формула расчета очень простая:

  • Берется массив задач, запланированных на каждого сотрудника (в отчете колонка Pl).
  • При каждом переносе плановой даты решения в будущее – счетчик пронесенных задач увеличивается на 1 (в отчете колонка Ov.)
  • Итоговый % для всего ИТ подразделения считается по аналогичной формуле с учетом общих значений по всем сотрудникам.

Внешний вид может быть представлен следующим образом:

Понятно, что в отчет попадает вся команда и у каждого сотрудника разных объем работ и разный массив задач. Тем не менее, не выполнение установленных дат, всегда является негативным фактором, который в большинстве случаев приводит к обесцениванию обещаний, которые ИТ дает бизнесу.

Это все, что я хотел рассказать о том, как можно измерять уровень доверия бизнеса к ИТ и об основных флагах, которые говорят нам на какие моменты следует обратить внимание. Уверен, что можно придумать еще отчеты и параметры для опосредованного измерения данного показателя, но главное, что сотрудники ИТ должны всегда помнить: “Доверие потерять легко и быстро, а восстанавливается оно долго и путем огромных усилий”.

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

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