СПОСОБЫ ИЗМЕРЕНИЯ БИЗНЕС-ПРОЦЕССОВ И ИХ ЗНАЧЕНИЕ ДЛЯ БИЗНЕСА.
Последние несколько лет мы наблюдаем сдвиг в культуре управления во множестве крупных и средних компаний. Руководители начинают рассматривать бизнес-процессы как уникальные активы предприятия. Действительно, можно вкладывать в уникальное оборудование или торговые точки или транспорт— это крупные проекты развития, реализация которых не отменяет развития бизнес-процессов.
Работа над бизнес-процессами способна привести компанию к лидерству на рынке. При этом, проекты развития процессов не являются инвестиционно-емкими или продолжительными. Развитие процессов может происходить постоянно, небольшими шагами.
Как следствие, на первый план выходя вопросы: с чего начать? какие процессы работают хорошо, а какие плохо? Чтобы ответить на них, необходимо грамотно измерять бизнес-процессы, видеть их сильные и слабые стороны.
Границы процессов
Здесь и далее мы исходим из следующего определения сквозного процесса. Сквозной процесс — это последовательная совокупность взаимосвязанных действий различных функций для получения единого результата, ценного для Компании или Клиента, объединение которых позволяет получить синергетический эффект.
Выясняется, что границы процесса напрямую влияют на его измерения. Что мы считаем успешным экземпляром процесса закупки? Проведенный тендер и заключенный договор или факт получения качественного сырья на склад точно в срок?
Границы сквозного процесса определяются исходя из здравого смысла и следующих предпосылок:
- Грамотно определенные границы сквозных процессов позволяют компаниям сконцентрировать усилия и добиться синергетического эффекта в рамках одного процесса;
- Грамотно определенные границы сквозных процессов делают прозрачными результаты работы. Таким образом, формируется модель ориентиров или показателей, актуальных для ТОП-менеджмента;
- Грамотно определенные границы сквозных процессов позволяют компаниям меняться осознано в соответствие с выбранной стратегией. Компания выбирает приоритетное направление стратегии, формулирует сквозной процесс и «вытягивает» его.
План/Факт или Метрики/Показатели
Для целей этой статьи дадим следующие определения.
Показатель процесса — измеряет объем результатов, созданных бизнес-процессом. Показатель имеет плановое и фактическое значение за период. Например, сумма выставленных счетов за день — это показатель бизнес-процесса “Формирование счета для клента”.
Метрика процесса — отражает способ организации деятельности внутри бизнес-процесса. Метрика связана со стартовым и конечным событием процесса и измеряет “расстояние” между двумя этими точками. Метрика имеет нормативное значение и степень отклонения от этого значения. Например, среднее время выставления счета — это метрика бизнес-процесса “Формирование счета для клиента”.
Классификация метрик и показателей процессов
Мы определили 6 групп метрик и показателей бизнес-процессов, которые имеют значение для бизнеса.
Группа 1. Результативность (англ. Effectiveness)
Мы намеренно не используем термин “эффективность”, чтобы избежать путаницы относительно англ. efficiency (см.далее).
Показатели результативности сконцентрированы на соотношении ожидаемого и фактического результата работы бизнес-процесса за период (далее будем рассматривать период 1 мес.).
Как правило, большинство вопросов возникают вокруг измерения ценности, сформированной бизнес-процессом (EFFE04, EFFE05).
Мы считаем заблуждением попытку расчета прибыли, сформированной процессом. Другими словами, не правильно привязывать к конкретному процессу прибыль от реализации заказа или от выдачи кредита. В формировании прибыли участвуют активы компании, сотрудники и способ работы организации в целом (все процессы как единая система). Именно поэтому мы проводим оценку ценности процесса через денежные или материальные потоки, проходящие через процесс.
Мы считаем неправильной попытку введения денежных производных для определения ценности обеспечивающих процессов. Например, оценка успешно оформленной командировки или успешно нанятого сотрудника в деньгах — это не лучшая идея, способная разбалансировать систему.
Группа 2. Эффективность (англ. Efficiency)
На этой группе метрик сконцентрирован распространенный метод исследования процесса “Функционально-стоимостной анализ”.
Метрики эффективности сконцентрированы на расходах ресурсов, формируемых бизнес-процессом.
Результаты ФСА могут быть обогащены за счет введения дополнительных метрик, связанных с запасами бизнес-процесса (подробнее см. в следующей части).
Интересно отметить, что единичное усовершенствование процесса приводит к двум типам эффекта:
- Разовый всплеск прибыли компании, если мы говорим о процессе, который является частью цепочки создания ценности. Этот всплеск обусловлен снижением запасов процесса. После запуска в продуктив обновленный процесс за период времени отработал больше транзакций / заявок / экземпляров, т.е. выдал больше результата за единицу времени;
- Снижение операционных расходов бизнес-процесса, которое сохраняется постоянно в будущих периодах.
СМ. ПРОДОЛЖЕНИЕ В СЛЕДУЮЩЕЙ ЧАСТИ
Источник: medium.com
Про бизнес и метрики
Приборная панель современного авиалайнера отображает несколько десятков различных показателей. Вся эта информация требуется пилотам для принятия тех или иных решений во время полета.
1547 просмотров
Управленческие решения в бизнесе также принимаются на основании объективных показателей – метрик. Но чем больше компания, тем сложнее организовать контроль всех необходимых показателей. Многообразие всевозможных метрик, с одной стороны, дают простор для выбора, с другой – сбивают своей избыточностью.
Мониторинг даётся компаниям не бесплатно, и чтобы лучше отделить зёрна от плевел (даже после изучения понятий ванильных, NorthStar, и прочих метрик), предлагаю посмотреть на метрики ни как на данные в рамках одной команды (продукта), а как систему взаимосвязанных потоков информации.
Анатомия метрик
Метрика бывает двух типов:
- бизнесовая, то есть отражающая показатели успешности бизнеса;
- процессная – отражающая показатели процесса создания продуктов.
В свою очередь, бизнесовые метрики могут подразделяться на основные и сопутствующие.
Основные – те, которые в явном виде отражают успешность бизнес-части (например, количество продаж и доход), сопутствующие – те, изменение которых влияет на изменение основных (например, посещаемость сайта).
Возможно, самым простым способом определения Основных бизнес-метрик будет взятие их из квартального отчета для генерального директора организации 🙂
Помимо этого, метрики обладают следующим списком атрибутов:
Стадия — может быть двух видов:
- ожидание метрики – планируемая величина, которую хочется достичь в результате каких–либо действий;
- результат метрики – фактически достигнутый результат (полученный показатель) в результате совершенных действий;
Длина (обратной связи) – временной интервал между совершенным действием и проверкой полученного результата метрики (другими словами – через какой промежуток времени считается целесообразным измерение полученного результата)
Стадия метрики и её длина находят своё отражение в цикле Деминга–Шухарта (PDCA):
Бизнесовые метрики
В больших организациях с иерархической структурой подразделений, каждая бизнес–метрика (как основная, так и сопутствующая) должна быть декомпозирована от уровня появления метрики (например, подразделения), до конечных исполнителей (команд).
Сопутствующие метрики, в отличие от основных (которые спускаются «сверху» путём декомпозиции) могут быть выбраны и установлены на любом из уровней иерархии компании (и также декомпозированы до команд).
Посредством этого происходит вовлечение и повышение мотивации руководителей разных уровней, а также членов самих команд за счёт самостоятельного решения способа реализации поставленной цели (основной метрики).
Другими словам: например, перед компанией стоит задача получить доход в размере 1 млрд. рублей. Эта цель декомпозирутся по двум подразделениям – каждому заработать по 500 млн. Ввиду разного направления бизнеса подразделений, один ставит себе (самостоятельно) одну сопутствующую метрику (например, MAU), второй – другую (например, количество товаров в одном чеке при продаже). Команды, в свою очередь, также свободны в выборе тех дополнительных (сопутствующих) метрик, мониторинг которых поможет им в продвижении к достижению значения основной метрики.
Также, сопутствующие метрики становятся крайне востребованы при работе с «длинными» основными метриками, когда полученный результат таковых становится доступен через месяц, квартал или даже год. В таких случаях полезно иметь на вооружении ряд сопутствующих метрик, которые хоть и косвенно относятся к результатам основной метрики, но «короче» по длине обратной связи, и позволяют повысить управляемость процессом.
Процессные метрики
Мониторинг процессных метрик позволяет объективно отслеживать процесс создания продукта.
Совместно с релизным расписанием, такие метрики, как velocity помогают команде (и выше) понять количество попыток повлиять на бизнесовые метрики (через выпуск новых фич) за определенный промежуток времени.
Чтобы обеспечить эту прозрачность, запланированные фичи (задачи) должны быть оценены и приоритизированы. Помимо этого, при совместном выводе несколькими командами одного (либо связанного) функционала – через процессные метрики обеспечивается общее понимание отсутствия или наличия проблем в процессе разработки.
Другими словами, например, две команды работают над функционалом, который планируют вывести в релиз через полтора месяца. Используя метрики сгорания релиза (т.е. отношение суммы оценок оставшихся задач к velocity) – команды способны на ранних стадиях увидеть потенциальное непопадание к назначенной дате, либо несинхронное завершение работ (при работе над разными бэклогами)
Влияние метрик друг на друга
В отличие от бизнесовых метрик, ожидание от которых спускается сверху–вниз (в иерархической структуре организации), данные о процессных метриках (результаты) «поднимаются» снизу–вверх (например, Lead Time).
В случае крупных организаций с иерархической структурой, процессным метрикам больше внимания уделяется на уровне команд, которое плавно сменяется фокусом на бизнесовые по мере «поднятия» вверх по иерархическому дереву компании.
Другими словами, очевидно, что участники команды на своём уровне больше внимания будут уделять процессным метрикам, тогда как на уровне правления основные обсуждения будут посвящены бизнесовой составляющей.
Agile–подход предполагает получение максимального результата через работу с данными от обоюдо–направленных метрик.
Особо хотелось бы отметить важность направления движения информации: данные о бизнесовых метриках «спускаются» (декомпозируются) сверху–вниз (в нашем случае – от уровня руководства компании к Командам), в свою очередь, данные о процессных метриках «поднимаются» снизу–вверх.
Именно такой формат отличает проектный подход (где «сверху» спускаются ожидания и по бизнесовым и по процессным показателям) от Agile–подхода.
Выявление зон роста
Для диагностики состояния культуры использования метрик в работе организации предлагается следующий чек–лист:
- Определён список основных бизнес метрик (ЧКД, P
- Бизнес–метрики декомпозированы от уровня руководства компании до Команд;
- Определены сопутствующие метрики, позволяющие производить мониторинг достижения основных метрик (количество продаж в определенном канале и пр.);
- Определён список процессных метрик (ТТМ, Velocity и пр);
- Для каждой метрики определён период обратной связи;
- Определены и автоматизированы источники информации по метрикам;
- Определены события, на которых обсуждаются ожидания и полученные показатели метрик;
- Планирование любой работы осуществляется на основании всех доступных на данный момент метрик;
- Для каждой заводимой (например, в Jira) задачи есть понимание (например, пометка), на какую метрику она будет влиять.
Дополнительно, для оценки доступности каждой из метрик:
- источник автоматизирован, доступ (у заинтересованных лиц) есть;
- источник автоматизирован, доступа нет;
- информация собирается вручную;
- источник информации отсутствует.
После заполнения чек–листа становятся очевидны пути улучшений.
Важно не только выбрать правильные метрики для конкретной команды, но и выстроить стабильные потоки информации через все слои иерархии.
Отчет о продажах на столе генерального директора и BurnDown Chart на стене у разработчиков – это не цифры из разных миров, это взаимозависимая информация, позволяющая держать ситуацию под контролем.
Поэтому не существует главной или идеальной метрики, наблюдение за которой решало бы все проблемы в компании. Метрики в принципе не решают проблем – их решают люди, основываясь на полученных показателях.
Источник: vc.ru
Как оценивать эффективность продуктовых команд. Часть 1: процессные метрики
Начнем с экспозиции. В нашей компании продуктовая структура представляет из себя 9 продуктовых end-to-end команд общей численностью ~130 человек, работающих над развитием одного продукта.
Каждая из команд укомплектована всеми необходимыми компетенциями. Все они живут в одном релизном процессе, делают задачи из одного бэклога (и проекта в Jira) и следят за одним набором метрик в Amplitude.
В условиях такого тесного взаимодействия естественным образом возникает вопрос: а как оценивать их эффективность? Об этом мы и поговорим.
Перед тем, как определить критерии оценки, давайте разберемся с тем, что же такое эффективная продуктовая команда. Все просто:
Эффективная продуктовая команда — та, которая выпускает классные (коммерчески успешные) продукты. Чтобы сделать классный продукт, нужно быстро поставлять качественные решения пользователям. То есть эффективность продуктовой структуры или команды можно оценить по двум факторам:
- Как быстро бежит команда? (Time to market)
- А туда ли она бежит? (Value)
Скорость команды
Для начала нужно понять, а что, собственно, мы хотим измерить в скорости работы команды. Время от идеи до релиза? Время от «взяли в работу» до «выпустили»? Давайте разложим основные этапы разработки любой крупной задачи на временную шкалу:
- Генерация идеи — кто-то придумал что нужно сделать классную фичу.
- Создана задача — об этой классной фиче впервые появился цифровой след, ее завели в Jira, Kaiten или Trello.
- Взята в работу — та самая точка взятия обязательств командой. До этого момента работа над классной фичей по сути не велась.
- Разработка закончена (Ready for Release) — все работы сделаны, фича готова к выпуску.
- Релиз — релиз.
- Аналитика а что она нам дала?». Может, вы ее зря делали 🙂
Теперь пойдем от обратного и поговорим о метриках на основе этой шкалы:
- Dev Time — самая базовая единица измерения в нашей шкале. Показывает, сколько времени уходит на разработку/тестирование и подготовку фичи к релизу. Это самая честная и понятная метрика для команды, т.к. она на 100% находится в зоне ее влияния.
- Release Time — сколько времени занимает выпуск готового функционала. Метрика больше для корпораций и крупных компаний. В истории, когда у тебя десятки или сотни команд, время выпуска релизов может достигать недель, и за этим показателем есть смысл следить и как-то его улучшать. В небольших командах или компаниях с низкой бюрократией и/или низким техническим легаси этой метрики может вообще не быть, т.к. время на релиз несущественно.
- Cycle Time — от «взяли в работу» до «выпустили в прод». Первая из перечисленных метрик, которую можно ставить в KPI команды и мониторить ее на дашбордах. По ней видно, как быстро работает каждая из ваших команд.
Начинаем усложнять. Допустим с метрикой Cycle Time вы разобрались и даже улучшили до нужных значений.
- Lead Time — следующий уровень. Сколько времени проходит от того, как мы завели задачу в бэклог до ее фактического выпуска? По опыту, Lead Time обычно кратно больше Cycle Time. И причина этому — долгое время ожидания очереди в бэклоге.
- Time to Market — та самая фраза, которую вы слышите на митапах и конференциях. Научиться ее измерять — дело уже высшего пилотажа и мало кому действительно удается. Вся сложность кроется в измерении самого первого этапа — генерации идеи. Как оцифровать тот самый момент, когда вы на совещании или по пути на работу придумали классную фичу и решили ее делать? Сколько дней или недель прошло до того момента, как эта фича появилась в бэклоге в Jira?
- Time to Learn — сколько времени проходит от момента, когда классную фичу кто-то придумал до момента, когда по ней появились цифры в Amplitude. Показатель в большей степени характеризует с какой скоростью работает ваш бизнес/продукт в целом. Как быстро вы выпускаете новые продукты или проводите эксперименты?. Как быстро вы обрабатываете результаты этих запусков и делаете из них выводы? Как быстро вы потом можете обновить свои приоритеты и поменять свой курс? Этот показатель комплексно отвечает на вопрос «как быстро работает ваша компания». И разумеется, тот, кто работает быстрее — тот обычно и побеждает.
Справедливости ради отмечу, когда мы начинаем внедрять оценку эффективности команд в организации, то первым делом определяем приоритетные метрики. В нашем случае это — Lead Time, Cycle Time и Release Frequency. Мы сразу и честно себе признаем, что все что больше этого (Time to Market, Time To Learn), мы нормально посчитать сейчас не сможем, да и вряд ли сможем на них в ближайшей перспективе повлиять. Поэтому сразу убираем их из фокуса.
Далее, как технически измерить эти показатели? Очень просто — timestamp в Jira. Для того, чтобы собрать статистику по всем нашим командам, нам достаточно настроить автоматическую выгрузку из Jira нескольких временных кодов:
- Дата создания задачи. Автоматически создается Jira в любой задаче.
- Дата перевода задачи в статус In Progress. Также автоматически создается самой Jira.
- Дата выпуска задачи в релиз. Сильно зависит от вашего релизного процесса. В нашем случае — в каждую задачу проставляется fix version. По нему определяем дату релиза и проставляем ее в выгрузке.
- Тип задачи. Важно не забывать разделять метрики по типам задач и следить за ними отдельно. Ведь Cycle Time по багу нельзя сравнивать с Cycle Time новой фичи.
Итого, если настроить автоматическую выгрузку по всем этим параметрам и положить в простенький дашборд в том же Power BI, то получаем простой, но результативный инструмент по отслеживанию эффективности ваших команд:
Скорость сжигания бэклога
Если возиться с Jira и считать метрики не хочется или не можется — есть альтернативный вариант. Считаем скорость сжигания бэклога продуктовыми командами. Метод до жути простой, но рабочий. Как говорится — «keep it simple, stupid» (принцип дизайн проектирования, принятый ВМС США).
- Вводим в командах любую систему оценки задач. В сторипоинтах, в часах, в штуках — как вам нравится.
- В конце каждого спринта/итерации/месяца собираем два показателя: сколько планировали единиц в работу, сколько по факту выполнили. Строим из этих данных несложную таблицу или дашборд.
- Наглядно видим слабые места в системе, получаем массу фактуры для работы над улучшениями.
В нашем примере мы собираем статистику по закрытым сторипоинтам в спринт каждой команды. «Сжигаются» сторипоинты в момент, когда задача доезжает до статуса Ready for Release, то есть она оттестирована и готова, осталось только выложить в прод.
Здесь важно сказать, что любую систему можно довольно таки легко обмануть. И история с оценкой метрик не является исключением. Рано или поздно ваши команды найдут способ читерить с оценками, это неизбежно. Но.
Как правило, первыми способами обойти систему будут положительные под предлогами — «а давайте нарезать таски на более мелкие», «а давайте меньше брать в спринт», «а давайте оставлять временной резерв на непредвиденные задачи и вбросы». Это приводит к положительному эффекту процесса разработки. Ведь действительно, нужно лучше декомпозировать задачи, не брать в работу то, что «не лезет», и оставлять время на исправление багов.
Вывод
В первой части мы разобрались с вопросом «как быстро мы бежим?». А это — только вершина айсберга. Можно бежать очень быстро, но бежать не туда или вообще бежать в стену.
Во второй части расскажу как оценивать качество того, что создают продуктовые команды (и ответить на вопрос «а куда мы бежим?»), как правильно мотивировать их на достижение коммерчески успешных результатов в продукте.
- agile
- time to market
- ttm
- метрики процесса
- метрики производительности
- метрики продукта
- продуктовая команда
- Блог компании Лига Ставок
- Управление разработкой
- Управление проектами
- Agile
- Управление продуктом
Источник: habr.com