Портал №1 по управлению цифровыми
и информационными технологиями

Трудности SMART

Наверное, все знакомы с набором критериев SMART, которым должна соответствовать правильно поставленная цель, задача.
По моим наблюдениям самая большая проблема на практике у людей возникает с «R». Следует уточнить, что несмотря на то, что нередко под «R» понимают, как и было предложено в первой публикации, где этот акроним использовался, «realistic» (реалистичный), я имею в виду наиболее часто используемый ныне смысл «relevant» (релевантный). Соотнесение цели с контекстом. В широком смысле это означает в том числе соотнесение измерения с целями измерения. «Зачем измерять?» – первый вопрос, на который необходимо ответить при формировании любого отчёта и любой системы измерения и оценки. Например, так часто встречаемая в жизни «отчётность ради отчётности» как раз не удовлетворяет критериям SMART в части R, понимаемой вышеописанным образом. Мы просто производим какую-то работу по измерению. Но никаких управленческих решений на основе полученных данных не принимаем. M (measurable) есть, R (relevant) нет. И это не самый плохой сценарий.

Хуже, когда в систему измерения и оценки, например сотрудника/команды/процесса, особенно если на эту систему завязана система мотивации, включают показатели, которые мотивируют на то, что противоположно исходным целям и задачам. Проблема знаменитой «палочной системы» ровно в этом. Происходит так нередко потому, что система измерения и оценки собирается из того, что мы умеем измерять, из того, что легко измерять, из того, что мы привыкли измерять. А не из того, что нужно измерять.

Как убедиться в том, что в нашей системе измерения и оценки находится только то, что нужно? В умных книгах говорится о каскаде – последовательности шагов, которые мы совершаем на пути от цели к конкретным показателям и тому, как мы оперируем их значениями (см. например раздел «Формирование системы измерения и оценки» в книге «Управление услугами на основе измерений» или раздел 2.4.1 в описании практики «Measurement and Reporting Management ITIL®4 Practice Guide», об этом же говорим на курсе ITIL® 4 Strategist: Direct, Plan and Improve).

Разумеется, «R» – не единственная сложность. Иногда мы вынуждены разбираться с комбинацией проблем. Например, недавно Олег Скрынник, размышляя о метрике эффективности потока в одноимённой заметке, отмечал, что время фактической работы на задачей в потоке (Touch Time) довольно сложно измерить. Оценить – да, измерить – вряд ли. То есть в данном случае, мы имеем проблему с измеримостью («M» из SMART). Эта проблема проявляется в том, что, так называемый коэффициент эффективности потока (рассчитывается как отношение Touch Time / Lead Time) сложно использовать для сравнения эффективности работы разных команд (или других производственных систем). Иными словами, метрика эффективности потока перестаёт быть релевантной задаче сравнения потоков (например, сравнение продуктовых команд между собой). Точно также вряд ли удастся повысить эффективность работы, увязывая мотивацию членов команды со значением этого показателя (почти любое целевое значение может быть достигнуто за счёт того, что команда «правильно посчитает»). Получается, что метрика эффективности потока нерелевантна многим (всем?) задачам внешнего управления потоком. Означает ли это, что метрика плоха. Именно этот вопрос и ставится в упомянутой заметке. На мой взгляд, с учётом всего вышесказанного, вопрос можно переформулировать следующим образом: «Существуют ли какие-либо цели и задачи, которым данная метрика релевантна?» (мой ответ – да).

Как видим, вопрос релевантности конкретной метрики или системы измерения и оценки комплексный. То, насколько показатели M (measurable) может повлиять на то, насколько они R (relevant). Но важно уметь простраивать каскады/цепочки от верхнеуровневых целей до конкретных показателей, чтобы исключить ненужные измерения и метрики, и не потерять нужные. То есть, набор показателей, которые хороши с точки зрения M (measurable) не решит управленческой задачи, если это показатели не R (relevant).


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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM