По сравнению с традиционным подходом процессы обладают и другим преимуществом. Действительно, трудно или невозможно измерить достоинства иерархической структуры или улучшить ее, в то время как при ориентации на процессы специалисты имеют дело с такими четко оцениваемыми характеристиками, как стоимость, длительность, выход, качество и степень удовлетворения клиента.
Оценка процесса опирается прежде всего на первичный результат, ради которого этот процесс создан и функционирует.
Метрика – это стандартная мера для оценки деятельности в специфической области. Метрики разрабатываются в фокусе клиентов и стандартов деятельности, сформированных для удовлетворения клиентов и достижения деловых целей.
«Бизнес преуспевающий и делающий деньги постоянно оценивает и улучшает себя во всех направления; метрики – это краеугольный камень этой оценки и основание для любого совершенствования»
Вы не можете улучшить то, что вы не можете измерить. Поэтому метрики должны быть разработаны, основываясь на приоритетах стратегического плана, который обеспечивает ключевые драйверы для бизнеса и критерии метрик, которые руководители хотят использовать. Затем разрабатываются процессы и формы сбора, хранения и анализа этих данных. Лица, принимающие решение, видят измеряемые результаты различных процессов и стратегий и имеют основания ля руководства компанией.
1.4 Ключевые маркетинговые метрики для бизнеса! | Должен знать каждый предприниматель
Таким образом, метрики нужны, чтобы определять:
Ø Связь со стратегий, состояние ее реализации;
Ø Основу для улучшения процессов;
Ø Основу для прогнозов.
Секрет 1 Измеряйте правильные вещи
- Выполнение требований клиентов
- Удовлетворение клиентов
Выполнение внутренних процессов
2 Качество продукта и сервиса
3 Затратная операционная часть (производительность и т.д.)
4 Затратная капитальная часть
Удовлетворение требований предприятия
2. Рост доли на рынке и др.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Метрика
Пять гибких метрик, которые вы не будете ненавидеть
Статистика и графики являются мощными инструментами. Используйте их во благо, дорогие агилисты . используйте их во благо.
Метрики — деликатный предмет.
С одной стороны, мы все работали над проектом, в котором не отслеживались никакие данные, и было трудно сказать, находимся ли мы в процессе выпуска релиза или становимся более эффективными по мере продвижения вперед. С другой стороны, многие из нас имели несчастье участвовать в проектах, где статистика использовалась в качестве оружия, противопоставлять одну команду другой или оправдывать обязательную работу на выходных. Поэтому неудивительно, что большинство команд имеют отношения любовь / ненависть с метриками.
Но так не должно быть. Отслеживание и обмен значимыми метриками может уменьшить путаницу и пролить свет на прогресс команды (и неудачи) на протяжении всего цикла разработки. Вот как.
30 метрик и показателей бизнес-процессов / Вебинар
Знай свое дело
«Готово» рассказывает только половину истории. Речь идет о создании правильного продукта, в нужное время, для правильного рынка. Быть на ходу на протяжении всей программы означает собирать и анализировать некоторые данные по пути. В любой гибкой программе важно отслеживать как бизнес-метрики, так и agile метрики. Бизнес-метрики ориентированы на то, соответствует ли решение требованиям рынка, а agile метрики измеряют аспекты процесса разработки.
Бизнес-метрики программы должны быть основаны на ее дорожной карте.
Для каждой инициативы в дорожной карте включите несколько ключевых показателей эффективности (KPI-key performance indicators), которые соответствуют целям программы. Кроме того, включите критерии успеха для каждого требования к продукту, такие как степень принятия конечными пользователями или процент кода, покрытого автоматизированными тестами. Эти критерии успеха используются в agile метриках программы. И чем больше команд учатся, тем лучше они могут адаптироваться и развиваться.
Как использовать agile метрики для оптимизации предоставления
Agile метрики, которые будут обсуждены ниже, фокусируются на поставке (предоставлении) программного обеспечения. Независимо от того, являетесь ли вы командой Scrum или Kanban, каждая из этих agile метрик поможет команде лучше понять процесс разработки, упрощая выпуск релиза программного обеспечения.
Сгорание спринта
Команды Scrum организуют разработку в спринтах с временными рамками. В начале спринта команда прогнозирует, какую работу они могут выполнить во время спринта. Отчет об сгорании спринта отслеживает завершение работы на протяжении всего спринта.
Ось X представляет время, а ось Y относится к объему работы, оставшейся для завершения, измеренному в сюжетных точках или часах. Цель состоит в том, чтобы все прогнозируемые работы были завершены к концу спринта.
Команда, которая постоянно выполняет свои прогнозы, является убедительной рекламой для agile в своей организации. Но не позволяйте этому поддразнивать вас, чтобы обмануть числа, объявив элемент завершенным, прежде чем он действительно таким будет. Это может выглядеть хорошо в краткосрочной перспективе, но в долгосрочной перспективе только мешает обучению и улучшению.
АНТИ-ОБРАЗЦЫ, ЧТОБЫ СМОТРЕТЬ ЗА НИМИ
- Команда заканчивает ранний спринт после спринта, потому что они не уделяют достаточного внимания работе.
- Команда пропускает свой прогноз спринта после спринта, потому что они совершают слишком много работы.
- Линия сгорания делает крутые падения, а не более постепенное сгорание, потому что работа не была разбита на гранулированные части.
- Владелец продукта добавляет или изменяет область среднего спринта.
Эпики и сгорание релиза
Эпики и диаграммы сгорания релиза (или версии) отслеживают ход разработки в более широком объеме работы, чем сгорание спринта, и направляют разработку для команд scrum и kanban. Поскольку спринт (для команд Scrum) может содержать работу из нескольких эпиков и версий, важно отслеживать как ход отдельных спринтов, так же как и эпики и версии.
«Сфера ползучести» — это внедрение большего количества требований в ранее определенный проект. Например, если команда предоставляет новый веб-сайт для компании, сфера ползучести будет просить новые функции после того, как начальные требования были набросаны. Хотя допускать ползучесть во время спринта — плохая практика, изменение объема в эпиках и версиях является естественным следствием agile разработки. Когда команда продвигается по проекту, владелец продукта может решить взять на себя или удалить работу на основе того, чему они обучаются. Графики сгорания эпика и релиза держат всех в курсе приливов и отливов внутри эпика и версии.
АНТИ-ОБРАЗЦЫ, ЧТОБЫ СМОТРЕТЬ ЗА НИМИ
- Прогнозы эпиков или релизов не обновляются по мере того, как команда отрабатывает работу.
- В течение нескольких итераций прогресс не достигнут.
- Хроническая «сфера ползучести», которая может быть признаком того, что владелец продукта не полностью понимает проблему, которую пытается решить основная часть работы.
- Сфера растет быстрее, чем команда может ее поглотить.
- Команда не выпускает инкрементные выпуски релизов на протяжении всей разработки эпика.
Скорость
Скорость — это средний объем работы, выполняемой командой Scrum во время спринта, измеряемый либо в сюжетных точках, либо в часах, и очень полезен для прогнозирования. Владелец продукта может использовать скорость, чтобы предсказать, насколько быстро команда сможет работать с списком необходимых требований (backlog), поскольку отчет отслеживает прогнозируемую и завершенную работу за несколько итераций — чем больше итераций, тем точнее прогноз.
Допустим, владелец продукта хочет набрать 500 сюжетных точек в списке необходимых требований (backlog). Мы знаем, что команда разработчиков обычно завершает 50 сюжетных точек за одну итерацию. Владелец продукта может разумно предположить, что команде понадобится 10 итераций (дать или взять), чтобы выполнить требуемую работу.
Важно следить за тем, как скорость развивается со временем. Новые команды могут ожидать увеличения скорости, так как команда оптимизирует отношения и рабочий процесс. Существующие команды могут отслеживать свою скорость, чтобы гарантировать постоянную производительность во времени, и могут подтвердить, что изменение определенного процесса улучшилось или нет. Снижение средней скорости обычно является признаком того, что некоторая часть процесса развития команды стала неэффективной и должна быть рассмотрена на следующей ретроспективе.
АНТИ-ОБРАЗЦЫ ЧТОБЫ СМОТРЕТЬ ЗА НИМИ
Когда скорость меняется в течение длительного периода времени, всегда пересматривайте методы оценки команды. Во время ретроспективы команды задайте следующие вопросы:
- Существуют ли непредвиденные вызовы разработки, которые мы не учли при оценке этой работы? Как мы можем лучше раздробить на части работу, чтобы раскрыть некоторые из этих проблем?
- Есть ли внешнее деловое давление, толкающее команду за ее пределы? В результате страдает ли приверженность лучшим методам развития?
- Как команда, мы слишком усердны в прогнозировании спринта?
Скорость каждой команды уникальна. Если команда A имеет скорость 50, а команда B имеет скорость 75, это не означает, что команда B имеет более высокую пропускную способность. Так как культура оценки каждой команды уникальна, их скорость также будет различной. Не поддавайтесь искушению сравнивать скорость в разных командах. Измерьте уровень усилий и результатов работы на основе уникальной интерпретации сюжетных точек каждой команды.
Контрольная диаграмма
Контрольные диаграммы сосредоточены на времени цикла отдельных задач — общее время от «в процессе» до «выполнено». Команды с более коротким временем цикла, вероятно, будут иметь более высокую пропускную способность, а команды с одинаковым временем цикла по многим вопросам более предсказуемы в выполнении работы. В то время как время цикла является основной метрикой для команд kanban, scrum-команды также могут извлечь выгоду из оптимизированного времени цикла.
Измерение времени цикла — это эффективный и гибкий способ улучшить процессы команды, потому что результаты изменений видны почти сразу, что позволяет им сразу же вносить любые дополнительные изменения. Конечная цель состоит в том, чтобы иметь последовательное и короткое время цикла, независимо от типа работы (новая функция, техническая задолженность и т. д.).
АНТИ-ОБРАЗЦЫ, ЧТОБЫ ЗА НИМИ СМОТРЕТЬ
Контрольные диаграммы могут сначала показаться непостоянными. Не будьте так обеспокоены каждым выбросом. Ищите тренды. Вот две области, на которые стоит обратить внимание:
- Увеличение продолжительности цикла — увеличение продолжительности цикла лишает команду трудно вырабатываемой гибкости. В ретроспективе команды нужно время, чтобы понять рост. Единственное исключение: если в команде расширилось определение сделанного, вероятно, увеличится и время цикла.
- Неустойчивое время цикла — цель состоит в том, чтобы иметь согласованное время цикла для рабочих элементов, которые имеют сходные значения сюжетных точек. Отфильтруйте контрольную диаграмму для каждого значения сюжетных точек, чтобы проверить согласованность.
Накопительная диаграмма потока
Накопительная диаграмма потока является ключевым ресурсом для kanban-команд, помогая им обеспечить согласованность потока рабочих процессов в команде. Имея количество задач по оси Y, время по оси X и цвета для обозначения различных статусов рабочего процесса, она визуально указывает на недостатки и узкие места и работает в сочетании с лимитами WIP.
Кумулятивная диаграмма потока должна выглядеть гладкой (ish) слева направо. Пузыри или пробелы в любом одном цвете указывают на недостатки и узкие места, поэтому, когда вы видите их, ищите способы сгладить цветные полосы по всей диаграмме.
АНТИ-ОБРАЗЦЫ, ЧТОБЫ ЗА НИМИ СМОТРЕТЬ
- Блокирующие задачи создают большие резервные копии в одних частях процесса и неопределённое блокирование в других.
- Непроверенный рост списка необходимых требований (backlog), со временем. Это происходит из-за того, что владельцы продуктов не закрывают задачи, которые устарели или просто имеют слишком низкий приоритет, чтобы когда-либо возвращаться к ним.
Еще больше метрик
Хорошие метрики не ограничиваются обсуждениями, рассмотренными выше. Например, качество является важной метрикой для agile команд, и существует ряд традиционных метрик, которые можно применять для agile разработки:
- Сколько дефектов найдено .
- во время разработки?
- после релиза для клиентов?
- людьми вне команды?
- Сколько дефектов отложено до будущего релиза?
- Сколько запросов в службу поддержки клиентов приходит?
- Каков процент покрытия автоматическими тестами?
Agile команды также должны смотреть на частоту релизов и скорость предоставления. В конце каждого спринта команда должна выпустить программное обеспечение для производства. Как часто это происходит на самом деле? Поставляются ли большинство релизных сборок? В том же духе, сколько времени понадобится команде, чтобы выпустить аварийное исправление для производства?
Легок ли выпуск релиза для команды или это требует героизма?
Метрики — это только одна часть в построении культуры команды. Они дают количественное представление о работе команды и обеспечивают измеримые цели для команды. Хотя они важны, не зацикливайтесь. Прислушиваться к отзывам команды во время ретроспективы в равной степени важно для повышения доверия всей команды, качества продукта и скорости разработки в процессе релиза. Используйте как количественную, так и качественную обратную связь, чтобы стимулировать изменения.
По материалам Agile Coach «Metrics»
Источник: jiraved.ru
Измерение процессов управления ИТ
Измерение является частью управления любыми объектами: людьми, механизмами, денежными потоками и т.д.; но если методы измерения состояния неодушевленных предметов существуют уже давно, то подходы к измерению процессов пока находятся в стадии зарождения.
07.09.2011 Дмитрий Исайченко
- Ключевые слова / keywords:
- Менеджмент ИТ
Измерение – выраженное в количественных величинах сокращение неопределенности в оценке состояния объекта управления – является частью управления любыми объектами: людьми, механизмами, денежными потоками и т. д.; но если методы измерения состояния неодушевленных предметов существуют уже не одну сотню лет, то подходы к измерению процессов пока находятся в стадии зарождения.
Управление – широкое понятие, и, покопавшись в различных энциклопедиях, можно без труда найти пять-шесть его различных определений. В данной статье под управлением мы будем понимать «особый вид профессионально осуществляемой деятельности, направленной на достижение определенных целей путем рационального использования материальных и трудовых ресурсов…» [ 1 ]. В этом определении два важных момента. Первый – объектом управления являются не только материальные, но и трудовые ресурсы (люди), поэтому в русскоязычной литературе данный вид управления иногда называют словом «менеджмент» для того, чтобы отличать его от управления, скажем, автомобилем. В конечном счете, люди являются самым сложным элементом объекта управления, и именно от них в наибольшей степени зависит конечный результат. Видимо, поэтому Ли Якокка, один из признанных специалистов в области управления, отметил: «…управление представляет собой не что иное, как настраивание других людей на труд» [ 2 ]. Второй важный момент – управление представляет собой деятельность, работу (в отличие от власти, полномочий), которая включает в себя различные аспекты и один из которых – необходимость принятия управленческих решений.
Как следует из приведенного определения, управленческие решения касаются постановки целей и использования ресурсов. Например, увеличение количества клиентов при сохранении существующих ресурсов. Или перераспределение ресурсов с целью снижения рисков нехватки персонала или компетенции. Для того чтобы принимать подобные решения, необходимо понимать текущее и плановое состояние объекта управления, в нашем случае – деятельности, связанной с применением и развитием информационных технологий. Проблема в том, что в крупных организациях не только плановое, но и текущее состояние объекта управления не всегда известно — существует некоторая мера неопределенности.
Проиллюстрирую это на примере. В 2008-2009 годах я выполнял проект по реорганизации департамента ИТ одного среднего по размеру банка, этот департамент представлял собой второе по величине структурное подразделение банка после дирекции розничного бизнеса (190 человек). От деятельности сотрудников департамента в значительной степени зависела возможность банка осуществлять основные бизнес-процессы (зарабатывать деньги). Для управления своим департаментом ИТ-директору информации о текущем состоянии объекта управления было недостаточно, что истало одной из причин реорганизации.
Для понимания текущего и планового состояния объекта управления необходимы измерения. Измерение процессов управления ИТ представляет собой «выраженное в количественных величинах сокращение неопределенности на основании одного или нескольких наблюдений» [3]. Таким образом, измерение является одним из аспектов управления, и его важность возрастает с ростом сложности объекта управления.
Далее в статье мы будем говорить об измерении процессов управления ИТ-услугами, однако излагаемый метод измерения не ограничен данным подмножеством процессов.
Суть метода
Суть метода в том, чтобы связать с процессом набор метрик – технически или процедурно измеряемых величин, характеризующих объект управления. Метрика не обязательно измеряется технически (рассчитывается средствами автоматизации процесса). Существуют весьма важные метрики, значения которых можно получить только путем опроса участников процессов или потребителей услуг.
Да, они могут восприниматься как более субъективные (что может вызывать у ИТ-специалистов сомнение в их ценности). Но, возможно, именно этот субъективизм и ценен. Например, точка зрения потребителя является важным аспектом управления качеством. Борьба за повышение качества в целом, а тем более качества услуг, без учета точки зрения потребителя просто невозможна, поскольку противоречит определению качества.
В одном из номеров журнала Harvard Business Review за 1998 год [4] приводилась любопытная метрика — рентабельность управления (Return on Management, ROM). Ее суть – оценка того, насколько хорошо удается руководителям фокусироваться на реализации стратегии компании. Авторы определенно указывают на то, что эта метрика не является математической формулой, дающей объективное числовое значение. И несмотря на это, авторы относят данную метрику к столь же важным экономическим показателем, как, скажем, Return on Assets (ROA) или Return on Capital Employed (ROCE). Ведь ROM позволяет судить об отдаче самого дефицитного ресурса компании – времени и сил ее руководителей.
Следующий важный момент в определении метрики – метрика характеризует объект управления. Этот на первый взгляд банальный факт пригодится нам позже, при рассмотрении разработки процессных метрик.
Итак, предположим, мы разработали набор метрик, характеризующий наш объект управления достаточно полно для обоснованного принятия сформулированных нами управленческих решений. Разумеется, работа управленца на этом не заканчивается. Фактически метрики (а в более общем смысле – измерение в целом) помогают принимать управленческие решения на различных уровнях управления.
На оперативном – в рамках оперативного контроля. Например, решения, направленные на повышение результативности процесса посредством стимулирования ключевых исполнителей (обоснованных наказаний и поощрений по результатам отчетного периода). На тактическом уровне – в рамках планирования деятельности в среднесрочной перспективе. Например, решения о перераспределении полномочий по управлению процессом или о «настройке» интерфейсов между несколькими процессами.
Это значит, что измерение процессов – просто один из этапов в регулярном контроле, оценке и совершенствовании процессов. Организация цикла контроля, оценки и совершенствования – важнейший аспект внедрения или повышения зрелости процессов, поскольку позволяет не только осуществлять действенный контроль исполнения процесса непосредственно после его изменения, но и своевременно изменять процесс в будущем, если на то появится необходимость. Без этого цикла даже самые замечательные метрики окажутся бесполезным теоретическим грузом.
К сожалению, именно контролю, оценке и совершенствованию процессов меньше всего уделяют внимание в типовом «консалтинговом проекте», где основные усилия внедренца тратятся на настройку системы автоматизации процессов и разработку регламентирующих процессных документов без должного внимания работе с персоналом компании. Вместе с тем именно действующий цикл контроля, оценки и совершенствования позволяет организации получить уверенность в пользе внедряемых процессов управления.
Например, при внедрении процесса управления инцидентами заказчику имеет смысл больше времени и усилий тратить не на то, чтобы процесс определял последовательность действий по устранению инцидентов, а на порядок контроля, оценки и совершенствования деятельности по устранению инцидентов. Именно такой подход позволит реализовать назначение данного процесса – снижение негативного влияния на бизнес, оказываемого нарушениями в предоставлении ИТ-услуг. Именно поэтому данный процесс называется процессом управления инцидентами, а не процессом устранения инцидентов.
Итак, суть метода измерения процессов состоит в двух пунктах.
- Разработка системы метрик для измерения процессов.
- Применение системы метрик в рамках цикла контроля, оценки и совершенствования процессов для принятия более обоснованных управленческих решений.
Разработка системы метрик
Разработка системы метрик начинается с определения значимых с точки зрения измерения характеристик процесса, и в этой связи можно выделить несколько типов метрик.
Метрики результативности. Формулируются исходя из назначения, целей и задач процесса. Концепция назначения, целей и задач процессов (purpose, goals and objectives) используется авторами ITIL во всех книгах, и тем не менее должного системного объяснения эта концепция в книгах ITIL не нашла (www.realitsm.ru/2011/07/purpose-goals-and-objectives). Примеры метрик результативности для процесса управления инцидентами представлены в таблице.
| Назначение: обеспечение качества ИТ-услуг за счет скорейшего устранения инцидентов и своевременного выполнения запросов на обслуживание. | Среднее время устранения инцидентов в разбивке по уровню влияния (особый интерес представляет измерение в динамике). Единица измерения – минуты. |
| Цель: в I квартале 2011 года сократить превышение норматива времени на прием в работу до 5%. | Доля инцидентов, принятых в работу с соблюдением норматива на время приема в работу. Единица измерения – проценты. |
| Задача: организация накопления и повторного использования знаний по устранению инцидентов. | Доля инцидентов, решенных с помощью обходных решений из базы знаний. Единица измерения – проценты. |
Если цель процесса сформулирована с соблюдением принципов SMART (Specific, Measurable, Attainable, Relevant, Time-bound), то метрика для контроля достижения данной цели «извлекается» непосредственно из формулировки цели.
Метрики рациональности. Характеризуют количество ошибок, возникающих при исполнении процесса, использования тех или иных механизмов, предусмотренных для сокращения трудозатрат и т. д. Например, для процесса управления изменениями это может быть метрика «доля (в %) изменений, возвращенных на повторное оформление в результате проверки менеджером процесса». Для процесса управления инцидентами это может быть «доля (в %) обращений пользователей, закрытых после получения подтверждения по e-mail». Формулировка данных метрик выполняется исходя из описания процедур процесса.
Метрики соответствия. «Доля изменений, прошедших выборочную проверку у менеджера процесса при закрытии» (если соответствующий норматив определен в регламенте процесса), «доля фактически проведенных аудитов CMDB от общего количества аудитов, предусмотренных годовой программой аудита CMDB», причем формулировка метрик выполняется исходя из описания процедур процесса.
Метрики объема работ по исполнению процесса. «Количество изменений, обработанных за месяц (штуки)» или метрика потока обработки проблем :
где C – количество проблем, закрытых за период, O – количество проблем, открытых по итогам периода, N – количество проблем, зарегистрированных за период, но не закрытых к его окончанию (http://www.realitsm.ru/2010/12/measuring-problem-management). Данные метрики также формулируются на основании описания процедур процесса.
Опыт выполнения различных проектов по организации процессов управления ИТ позволяет сформулировать следующие рекомендации по разработке метрик.
Метрик не должно быть слишком много. Про каждую метрику разработчик должен быть в состоянии объяснить, кому и когда значение этой метрики помогает принять то или иное решение. Обилие метрик в регламенте процесса обычно говорит о том, что автор документа списал их из различных источников. Вместе с тем все метрики все равно не придумать – важнее научить менеджера процесса принципам формулирования метрик и их использования в практике управления процессом.
Метрики обязательны для всех целей и всех задач процесса. Такие метрики позволяют судить о результативности процесса, а это очень важно для стимулирования исполнителей, оценки экономического эффекта и выполнения иных управленческих функций.
Помимо метрик, позволяющих в общем оценить процесс, но не позволяющих сделать вывод «хорошо или плохо», например «количество изменений, зарегистрированных за период», обязательны также метрики-индикаторы (KPI), по значениям которых можно делать вывод о текущем состоянии процесса. Такие метрики, как правило, выражаются в процентах, изменяются в фиксированном диапазоне от 0 до 1, с ними относительно легко связать целевое значение (например, «светофоры» для наглядного отображения степени соответствия). При этом желательно, чтобы все подобные метрики имели общую «направленность». Например, чтобы все метрики интерпретировались как «чем ближе к 1, тем лучше».
Помимо метрик, характеризующих процесс в целом, обязательно должны присутствовать метрики, характеризующие работу ключевых ролей в процессе. Эти метрики используются при формировании системы мотивации, стимулирующей качественное исполнение процесса. Например, «доля инцидентов, принятых в работу своевременно (в соответствии с установленным нормативом)» – отличная метрика для оценки работы руководителя функциональной группы, обрабатывающей инциденты. Очевидно, метрики связываются с ролями процесса на основании таблицы RASCI, которая представляет собой расширенный вариант известной матрицы RACI (Responsible, Accountable, Consulted, Informed), описывающей участие при выполнении задач в виде определенных ролей: ответственный, подотчетный, консультирующий, информируемый.
При наличии нескольких метрик, характеризующих ту или иную роль, необходим понятный механизм их агрегирования — комбинирования значений для получения интегральной оценки успешности работы исполнителей данной роли.
Необходимо внимательно проверять метрики, чтобы исключить возможность манипулирования значениями со стороны оцениваемых ролей. Например, в одном из проектов, в котором мы осуществляли контроль качества, внешний консультант предложил заказчику метрику «доля проблем, решенных в установленный срок» для оценки работы аналитиков проблем. При том что срок решения проблемы устанавливался непосредственно аналитиком, польза от такой метрики сомнительна.
Подводя итоги, можно сказать, что самое главное при разработке метрик – стремиться не к их количеству, чтобы произвести впечатление на заказчика, а к ясному пониманию, кому, когда и зачем (для принятия каких решений) эти метрики понадобятся. Грамотно составленная система метрик позволяет сформировать взгляд на то, как соответствующий процесс может быть использован для решения управленческих задач.
Ограничения метрик
При оценке процесса полагаться лишь на значения метрик можно только в том случае, если действительно есть уверенность, что существующие метрики дают полную картину, но на практике так бывает не всегда. И причина этого – дороговизна измерения, делающая более-менее точную оценку некоторых метрик экономически нецелесообразной.
Например, попытаемся измерить пользу от исполнения процесса управления проблемами. Исходя из назначения процесса, его польза – в сокращении количества и степени тяжести инцидентов.
Однако на практике измерить это оперативно (например, по итогам квартала), не так-то просто — для этого нам потребовалось бы обеспечить относительно точный учет связей между проблемами и вызываемыми ими инцидентами. Любой, кто пробовал решить эту задачу, знает, что учет таких связей хотя бы с точностью 90% требует жесткого контроля исполнителей. На практике же ресурс менеджеров, как правило, ограничен в большей степени, чем ресурс исполнителей, поэтому оценку пользы от процесса управления проблемами часто выполняют не только на основании метрик, но и на основании письменного отчета менеджера процесса за период, в котором он фиксирует наиболее значимые решенные проблемы. Это вполне рабочий механизм.
Идея конечной ценности результатов измерений, ограничивающая применение некоторых метрик (или, по крайней мере, способов их расчета), раскрывается в литературе по прикладной информационной экономике, иинформацию об этом методе можно почерпнуть в [ 3 ].
Копировать метрики процессов из каких-либо источников бессмысленно — состав метрик и их применение зависят и от модели процесса, и от среды, накладывающей ограничения на их измерение. Поэтому выбор оптимальной системы метрик остается не только важной, но и интересной задачей. Разве достойно настоящего управленца избегать таких задач?
Литература
- Социология: Энциклопедия/Сост. А. А. Грицанов, В. Л. Абушенко, Г. М. Евелькин, Г. Н. Соколова, О. В. Терещенко. – Минск: Книжный Дом, 2003.
- Якокка Л. Карьера менеджера. – Минск: Попурри, 2005.
- Habbard D. How to Measure Anything. Finding the Value of «Intangibles» in Business – John Wiley and Sons, Inc., 2010.
- Simons R., Davila A. How High is Your Return on Management? – Harvard Business Review, January-February 1998.
Источник: www.osp.ru