Метрика бизнес процесса это

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

Подразделение ИТ – то же производство, сравнимое по сложности со средним заводом, и для управления им нужны соответствующие инструменты. Метрики процессов — инструменты управления. От того, как будет выстроена система метрик, зависит, насколько эффективно руководитель сможет управлять организацией.

Разница между метриками и показателями

Прежде, чем двигаться дальше, договоримся о терминах. Метрика — измеримый параметр.

Показатель – измеримый параметр достижения определенной цели. Для показателя должно быть определено целевое значение и желательная тенденция.

Классификация метрик

Деятельность любой ИТ организации можно разделить на три сегмента

• Сервисы
• Процессы
• Инфраструктура

Каждым из этих сегментов следует управлять и, следовательно, измерять.

Сервисные метрики

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

Примеры таких метрик: время формирования отчета, количество клиентов, обслуженных в единицу времени и т.д.

Именно за значения сервисных метрик ИТ организация отвечает перед заказчиком.

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

Технологические метрики

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

Процессные метрики и их классификация

Процессные метрики показывают эффективность работы внутренних процессов ИТ организации.

У любого процесса есть вход и выход, кроме того, процесс использует ресурсы и подвергается управляющим воздействиям.

Выстраивая систему метрик необходимо помнить об этих четырех составляющих и измерять каждую из них.

Метрики входа – измеряют нагрузку на процесс. Например, для процесса управления инцидентами количество инцидентов – метрика входа. Важно, что для менеджера процесса метрики входа – показатель исключительно информационный, на них нельзя влиять, а можно только реагировать.

Метрики выхода, или метрики результативности – показывают, насколько процесс достигает своей цели.

Метрики ресурсов показывают загрузку и достаточность ресурсов, используемых процессом.

Метрики управления показывают, насколько процесс управляем, эффективны управляющие воздействия.

В CobiT предложена своя классификация метрик: показатели результативности, показатели управляемости. Кроме того, для каждого процесса предложена модель зрелости.

Разложение метрик по четырем составляющим сопоставимо с классификацией метрик, предложенной в CobiT. Показатели результативности – метрики выхода, показатели рациональности – метрики ресурсов, зрелость процесса – метрика управляемости.

Очевидно, что, планируя целевые значения для различных метрик, следует балансировать их между собой. Потому что процесс может быть очень результативен и совсем нерационален и наоборот. Например, мы можем устранять все инциденты за полчаса, силами тысячи человек, или же справляться десятком человек, но устранять инциденты за месяц.

Отчетность корректирующие меры

Показатели не интересны сами по себе, они нужны для осуществления управленческих воздействий на процесс. Следовательно, ответственность за достижение целевых показателей должна быть возложена на руководство процесса и на сотрудников, назначенных на роли в процесс.

Должна быть выстроена система отчетности по показателям. Важно, чтобы на каждом уровне управления были представлены соответствующие показатели. Вряд ли директору по ИТ будет интересно анализировать статистику сбоев одного из дисковых массивов. Система отчетности должна быть выстроена таким образом, чтобы на каждом уровне, каждый менеджер контролировал и отвечал за 3-9 показателей. Большее количество трудно удерживать под постоянным контролем.

Вопросы мотивации

Зачастую показатели эффективности процесса используют для постановки личных целей и мотивации сотрудников. На первый взгляд, это логичное и правильное решение. Однако у человека, зарплата которого зависит от выполнения целевых значений, будет слишком велико искушение «подправить» показатели в свою пользу. Такая «правка» приводит к нарушению главного принципа использования показателей – объективности и достоверности, как если бы врач ставил диагноз и назначал лечение на основании неправильной информации о температуре пациента.

Выстраивание системы показателей ИТ

Процессы работают не в вакууме. Каждый процесс направлен на достижение определенной цели, связан с другими процессами и вносит свой вклад в предоставление сервисов. Цель каждому процессу должна ставиться исходя из того, какой аспект сервиса им поддерживается.

Таким образом, первичны цели сервисов, параметры, зафиксированные в SLA. Цели процессов и показатели, их измеряющие, должны определяться путем декомпозиции этих параметров. Например, в SLA может быть зафиксирована целевая доступность сервиса.

Очевидно, что на доступность сервиса влияют такие показатели как время устранения инцидентов, количество инцидентов, успешность проведения изменений и пр. Целевые значения этих показателей должны определяться из целевого значения доступности сервиса. Также понятно, что значимость каждого из этих показателей неодинакова и может меняться в зависимости от условий.

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

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

На основании чего строить систему показателей?

Чем же руководствоваться при построении системы измерений для ИТ процессов?

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

При использовании рекомендаций CobiT способы измерения целевые значения и алгоритмы расчета показателей придется продумывать самостоятельно.

Что касается ITIL®, то он более конкретен. В нем можно найти достаточно подробный перечень показателей для каждого процесса со способами их измерения и желательными тенденциями. Однако, в ITIL®, как известно, описаны не все возможные процессы ИТ. Например, за показателями процесса Разработки ПО придется обращаться к другим источникам.

В теме про измерения процессов невозможно не затронуть Карту Сбалансированных Показателей (BSC). Этот инструмент, изначально разработанный для управления предприятием, с успехом может быть применен для системы управления ИТ. Основной постулат BSC в том, что, выстраивая систему целей организации, опасно допустить перекос в ту или другую сторону. Например, уделять все внимание финансовой эффективности, не обращая внимания на лояльность клиентов или организацию внутренних процессов.

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

• Сервисы
• Внутренние процессы
• Инфраструктура
• Финансы
• Персонал.

В каждом конкретном случае вес целей по этим перспективам может меняться. Можно также использовать другую систему перспектив.

Источник: www.itexpert.ru

Метрики как способ эффективного управления проектами

За время жизни продукта, безусловно, приходится собирать большое количество данных, анализировать и принимать на их основе решения.

В своей работе мы собираем множество метрик — мониторим качество продакшена, поведение пользователей и процесс автоматизации. И, конечно, отслеживаем внутренние процессы — например, успеваемости сотрудников, приближения дедлайнов, сгорания задач и тому подобные.

Но как сделать так, чтобы всеми метриками было удобно пользоваться? Чтобы не приходилось собирать всё вручную, а была бы единая точка входа к данным, и сама полученная информация помогала контролировать состояние дел и проводить верную оценку.

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

Какие метрики собираем?

Ниже приведу основные метрики, которые собираются на проекте. Для удобства для себя мы делим их на четыре категории — QA, технической поддержки, метрики безопасности и процессные показатели. Важно понимать, что этих метрик на самом деле намного больше, и все они пригождаются на разных этапах проекта и в разных непредвиденных ситуациях.

1. Техподдержка

• дашборд качества
• поступающие задачи

2. QA

• покрытие
• тестовая документация
• покрытия автотестами
• результаты прогонов
• нагрузочное тестирование
• скорость написания автотестов

3. Безопасность

• загруженность отдела
• покрытие тестами безопасности

4. Процессные метрики

• загруженность производства
• сгорание задач
• срывы сроков задач
• сложность релизов
• приближение дедлайна

Вместо дисклеймера

Существует заблуждение, что сбор метрик — это целиком и полностью ответственность менеджера, а значит он сам в состоянии собрать то, что ему необходимо для отчетов. Но по факту, менеджеры в большинстве своем не обладают такими техническими компетенциями. Мы учитываем это у нас в компании, и поэтому менеджер работает в связке с QA-специалистом. И уже QA работает с инструментами, про которые мы расскажем ниже, и воплощает в жизнь те метрики, которые необходимы менеджеру.

Как это реализовано?

Data Studio — инструмент для анализа данных, отслеживания KPI и генерации отчетов. Он может собирать «под одной крышей» информацию из множества сервисов, и это очень удобно. К большому сожалению среди этих сервисов нет Jira Cloud, поэтому нам пришлось придумать костыль хитрое решение.

У Bob Swift Atlassian Apps есть плагин Database Exporter for Jira Cloud, который может выгружать все задачи в базу данных Postgres, а Google Data Studio может работать с Postgres.

Таким образом у нас получилась следующая связка:

• Задачи заводятся в таск-трекере Jira:

• В Jira установлен плагин, который раз в 15 минут подключается к нашей базе и выгружает все изменения в задачах.
• В Postgres хранятся все изменения задач (комментарии, статусы, сроки и т. д.) в актуальном состоянии. Эти данные мы можем использовать в разных целях, в том числе и для построения процессных метрик.
• В Google Data Studio, используя PostgreSQL connector, подключаемся в нашу базу с задачами с помощью SQL запросов получаем данные и строим метрики. Для удобства, чтобы каждый раз не писать большие запросы, на стороне СУБД написали виртуальную таблицу (VIEW) со всеми необходимыми столбцами:

CREATE OR REPLACE VIEW all_issues AS SELECT DISTINCT «ISSUEKEY» AS «issue_key», COALESCE(t1.»СОЗДАНО», t1.»CREATED») AS «create_date», COALESCE(t1.»ОПИСАНИЕ», t1.»DESCRIPTION») AS «description», COALESCE(t1.»СРОК_ИСПОЛНЕНИЯ», t1.»DUE_DATE») AS «deadline», COALESCE(t1.»РЕШЕНО», t1.»RESOLVED») AS «ready», COALESCE(t1.»P_», t1.»SUMMARY») AS «resume», t2.»NAME» AS «project», t3.»NAME» AS «status», t4.»NAME» AS «priority», t5.»NAME» AS «issue_type», t6.»VALUE» AS «severity», CASE WHEN t7.»TO_STRING» IS NULL THEN ‘false’::boolean ELSE ‘true’::boolean END AS «reopen», t8.»CREATED» as «closed_date», case when t10.»NAME» is null then Null else concat(t2.»NAME», ‘ | ‘, t10.»NAME»)::CHARACTER VARYING end AS release_name, CASE WHEN t11.»ID» IS NULL THEN ‘false’::BOOLEAN ELSE ‘true’::BOOLEAN END AS «bug_in_prod», t8.»CREATED» ::date-COALESCE(t1.»СРОК_ИСПОЛНЕНИЯ»::date, t1.»DUE_DATE»::date) AS deadline_breakdown, t13.»DISPLAY_NAME» as responsible, «EPIC_LINK» AS epic_link, «СЛОЖНОСТЬ_ЗАДАЧИ» AS «story_points», t1.»ISSUE_ID»::text AS issue_id, trunc(coalesce(«СУММАРНОЕ_ЗАТРАЧЕНОЕ_ВРЕМЯ», «AGGREGATE_TIME_SPENT»)/3600, 2) AS time_tracked, t14.»DISPLAY_NAME» AS assignee, trunc(coalesce(«СУММАРНАЯ_ПЕРВОНАЧАЛЬНАЯ_ОЦЕНКА», «AGGREGATE_ORIGINAL_ESTIMATE»)/3600, 2) AS original_estimate, t1.»START_DATE» AS start_date, t16.»CREATED» AS «last_modification», CASE WHEN t17.»ID» IS NULL THEN ‘false’::boolean ELSE ‘true’::boolean END AS «automation_task», CASE WHEN t10.»RELEASED»=’false’::BOOLEAN THEN NULL ELSE t10.»RELEASE_DATE» END AS release_date FROM «ISSUE_FIELD_VALUES» t1 LEFT JOIN «PROJECTS» t2 ON coalesce(t1.»ПРОЕКТ_PROJECT_ID», t1.»ПРОЕКТ_ID», t1.»PROJECT_ID») = t2.»ID» LEFT JOIN «STATUSES» t3 ON coalesce(t1.»СТАТУС_STATUS_ID», t1.»СТАТУС_ID», t1.»STATUS_ID») = t3.»ID» LEFT JOIN «PRIORITIES» t4 ON coalesce(t1.»ПРИОРИТЕТ_PRIORITY_ID», t1.»ПРИОРИТЕТ_ID», t1.»PRIORITY_ID»)= t4.»ID» LEFT JOIN «ISSUE_TYPES» t5 ON coalesce(t1.»ТИП_ЗАДАЧИ_ISSUE_TYPE_ID», t1.»ТИП_ЗАДАЧИ_ID», t1.»ISSUE_TYPE_ID») = t5.»ID» LEFT JOIN «FIELD_OPTIONS» t6 ON t1.»СЕРЬЕЗНОСТЬ_FIELD_OPTION_ID» = t6.»ID» LEFT JOIN (SELECT * FROM «ISSUE_HISTORY» WHERE «TO_STRING» = ‘Reopen’) t7 ON t1.»ISSUE_ID» = t7.»ISSUE_ID» LEFT JOIN done_issues t8 ON t1.»ISSUE_ID» = t8.»ISSUE_ID» LEFT JOIN «ISSUE_FIX_VERSIONS» t9 ON t1.»ISSUE_ID» = t9.»ISSUE_ID» LEFT JOIN «PROJECT_RELEASES» t10 ON t9.»PROJECT_RELEASE_ID» = t10.»ID» LEFT JOIN «ISSUE_БАГ_НА_ПРОДЕ» t11 ON t11.»ISSUE_ID»=t1.»ISSUE_ID» LEFT JOIN (SELECT DISTINCT ON («ISSUE_ID») * FROM «ISSUE_HISTORY» WHERE «FROM_STRING» IN (‘Open’,’To Do’,’To do’) AND «TO_STRING» IN (‘InProgress’, ‘In Progress’, ‘В работе’) ) t12 ON t1.»ISSUE_ID» = t12.»ISSUE_ID» LEFT JOIN «USERS» t13 ON t13.»ID»=t12.»AUTHOR_USER_ID» LEFT JOIN «USERS» t14 ON t14.»ID»=t1.»ASSIGNEE_USER_ID» LEFT JOIN (SELECT DISTINCT ON («ISSUE_ID») t15.»ISSUE_ID», «CREATED» FROM (SELECT * FROM «ISSUE_HISTORY» WHERE «FIELD» !=’Workflow’ ORDER BY «CREATED» ASC) t15) t16 ON t16.»ISSUE_ID»=t1.»ISSUE_ID» LEFT JOIN «ISSUE_ЗАДАЧА_АВТОМАТИЗАЦИИ» AS t17 ON t17.»ISSUE_ID» = t1.»ISSUE_ID»

Теперь мы можем использовать эту виртуальную таблицу в Google Data Studio для получения нужных данных. Например, тренд по багам за период:

SELECT to_char(create_date, ‘MM.YYYY’) AS month, project, severity, count(severity) FROM all_issues WHERE issue_type IN (‘Bug’,’Ошибка’) AND severity IS NOT NULL GROUP BY 1, 2, 3

Как внедрить свои первые метрики? Пошаговая инструкция

После того как мы собрали все инструменты вместе, самое время создать свою первую метрику. Собрали пошаговую инструкцию, чтобы построить отчет в Google Data Studio для количества задач в разрезе статусов и типов в процентах. Ниже мы используем стандартные поля в Jira. В вашем конкретном случае настройки в таблицах могут отличаться.

1. Установить плагин Database Exporter for Jira Cloud в Jira. Необходимо иметь права администратора Jira

1. Настроить подключение к базе PostgreSQL:

1. После настройки подключения начнется синхронизация. Когда пройдет полная синхронизация задач в базе появятся следующие таблицы (основная информация по задачам находится в таблице ISSUE_FIELD_VALUES ):
2. Перейти в Google Data Studio и создать отчет:

1. Выбрать источник данных:

1. Настроить подключение до базы с задачами и написать запрос для получения данных:

SELECT t1.»ISSUEKEY» AS «issue_key», t2.»NAME» AS «status», t3.»NAME» AS «project», t4.»NAME» AS «issue_type» FROM «ISSUE_FIELD_VALUES» t1 LEFT JOIN «STATUSES» t2 ON coalesce(t1.»СТАТУС_STATUS_ID», t1.»СТАТУС_ID», t1.»STATUS_ID») = t2.»ID» LEFT JOIN «PROJECTS» t3 ON coalesce(t1.»ПРОЕКТ_PROJECT_ID», t1.»ПРОЕКТ_ID», t1.»PROJECT_ID») = t3.»ID» LEFT JOIN «ISSUE_TYPES» t4 ON coalesce(t1.»ТИП_ЗАДАЧИ_ISSUE_TYPE_ID», t1.»ТИП_ЗАДАЧИ_ID», t1.»ISSUE_TYPE_ID») = t4.»ID»

1. Готово. Если предыдущие шаги выполнены правильно, то должна появиться таблица с задачами на пустой странице:

1. Нажать на эту таблицу и в правой стороне страницы добавить дополнительные параметры для отображения, удалить показатель и передвинуть немного вниз. Названия столбцов можно менять нажав на «ABC» правее от названия параметра:

1. Добавить круговую диаграмму которая показывает процент задач в разрезе статусов:

1. Добавить еще одну такую же диаграмму для отображения процента задач в разрезе типов:

1. Добавить управляющий элемент для выбора проекта (фильтр по проекту для построения метрик в отчете):

1. Добавить текст в шапке отчета и настроить стиль:

1. Выбрать цвет фона заголовка таблицы и цвет шрифта:

1. Изменить название отчета и нажать открыть для просмотра результата:

1. Готово:

Почему именно эта связка инструментов?

Конечно, существует много разных инструментов с уже готовыми решениями. Это такие системы как YouTrack с собственным конструктором дашбордов или Jira со встроенной статистикой. Мы пробовали использовать эти стандартные инструменты, но поняли, что нам их не хватает. Есть еще множество дорогостоящих решений, которые тоже нам не подошли.

По сути, мы используем полностью бесплатное решение. Его несложно доработать и адаптировать под собственные цели и особенности проекта.

Какие результаты приносят метрики?

Использование метрик приносит определенные плоды. С точки зрения менеджмента видим следующие плюсы:

• У менеджеров складывается актуальное представление о том, чем занимается отдельно взятый сотрудник, команда или отдел. Если задачи выполняются медленно, это повод поговорить и понять, что не так — может сотрудник начинает перегорать или испытывает трудности
• Позволяет грамотно планировать релиз и не срывать сроки
• Получается оперативно реагировать на ошибки и сбои
• Единая точка входа — ничего не разбросано по чатам и трекерам, а собрано в одном месте
• Если сотрудник уходит из офиса на удаленку, его прогресс хорошо виден

Плюсы для ребят в команде тоже имеются:

• Растет удовлетворенность слаженной работой команды и процессами
• Дает возможность как контролировать себя, так и помочь другому сотруднику
• Мотивирует на достижение результата

Что дальше?

У этого инструмента большой потенциал развития внутри компании.

Во-первых, мы рассчитываем, что подобный инструмент будет внедряться не только в отделы, где ведется разработка, но и в другие — например, в отделы безопасности, маркетинга или обеспечения. Это позволит эффективнее выстраивать процессы во всей компании и улучшать коммуникации друг с другом.

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Какие инструменты используете Вы для сбора метрик? Напишите в комментарий, если здесь нет вашего варианта

33.33% Готовыми решениями: Google Data Studio, статистика от Jira/Youtrack, etc., Tableau или Grafana 3

Источник: habr.com