Неплохая ссылка (просто, понятно) по lean, в стиле "делай раз, делай два", на примере. Пример очень тривиальный, и для интернет-разработчика, но сути дела не меняет.
воскресенье, 24 апреля 2011 г.
Сложности организации систем метрик
Написал о сложностях построения многоуровневых систем метрик. Необходимость в такой системе возникает обычно у крупных заказчиков: например, нужно сравнить эффективность вклада различных подразделений, направлений деятельности ИТ - в процесс.
(мой комментарий на исходные размышления Дмитрия Исайченко)
Навскидку вижу три сложности в такой системе.
Первое — она системно непрозрачна в силу расставления коэффициентов-весов (по опыту любая аналогичная система тяжело объясняется, тяжело запускается и легко оспаривается недовольными вовлеченными сторонами, что подменяет задачу на цифру и провоцирует большое количество ненужных споров вместо совместных усилий).
Второе — не определена цель функции. Помню на эту тему текст Романа Журавлева о функциях и процессах. Ок. Предположим, целью является предоставление качественных ресурсов для процессов. Но ведь это далеко не равнозначно качественному выполнению обязанностей функциональных ресурсов в процессах (что и меряют процессные метрики, разделенные по подразделениям).
И третье — а зачем, собственно, мерять вклад подразделения (функции, или любой другой непроцессной единицы в процесс)? К примеру, это противоречит тезисам Деминга. Я без робости вообще ко всем авторитетам, но здесь скорее придерживаюсь его мнения. Это система метрик в стиле «разделяй, оценивай и властвуй». И, особенно в наших условиях, будет поощрять политическую борьбу подразделений.
А вот полное обсуждение.
(мой комментарий на исходные размышления Дмитрия Исайченко)
Навскидку вижу три сложности в такой системе.
Первое — она системно непрозрачна в силу расставления коэффициентов-весов (по опыту любая аналогичная система тяжело объясняется, тяжело запускается и легко оспаривается недовольными вовлеченными сторонами, что подменяет задачу на цифру и провоцирует большое количество ненужных споров вместо совместных усилий).
Второе — не определена цель функции. Помню на эту тему текст Романа Журавлева о функциях и процессах. Ок. Предположим, целью является предоставление качественных ресурсов для процессов. Но ведь это далеко не равнозначно качественному выполнению обязанностей функциональных ресурсов в процессах (что и меряют процессные метрики, разделенные по подразделениям).
И третье — а зачем, собственно, мерять вклад подразделения (функции, или любой другой непроцессной единицы в процесс)? К примеру, это противоречит тезисам Деминга. Я без робости вообще ко всем авторитетам, но здесь скорее придерживаюсь его мнения. Это система метрик в стиле «разделяй, оценивай и властвуй». И, особенно в наших условиях, будет поощрять политическую борьбу подразделений.
А вот полное обсуждение.
Несколько интересных обсуждений
Так получилось, что за пару месяцев труднодоступности сервиса \blogspot.com "немного писал и немного читал" у коллег на realitsm, вот подборка интересных обсуждений:
- Дима очень четко и абсолютно правильно про обоснование проектов ITSM
я полностью согласен, могу только дополнить немного:
Чем дальше любые процессы (не только ИТ) от бизнеса (финансов), тем менее связаны любые действия по реорганизации с прибылью. И чем ближе процессы, тем проще связать их с прибылью, и соответственно, вменяемо финансово обосновать.
- коробочные решения в консалтинге (в обсуждении Дима Исайченко категоричен, Роман Журавлев системен, как обычно)
- процедура PIR в управлении изменениями (у меня достаточно отличный от itil'овских рекомендаций подход к PIR, в комментариях привел пару примеров)
- тема души сервисного подхода очень старая и заезженная (однако в комментариях таки появились интересные критерии сервисного подхода)
- Дима очень четко и абсолютно правильно про обоснование проектов ITSM
я полностью согласен, могу только дополнить немного:
Чем дальше любые процессы (не только ИТ) от бизнеса (финансов), тем менее связаны любые действия по реорганизации с прибылью. И чем ближе процессы, тем проще связать их с прибылью, и соответственно, вменяемо финансово обосновать.
- коробочные решения в консалтинге (в обсуждении Дима Исайченко категоричен, Роман Журавлев системен, как обычно)
- процедура PIR в управлении изменениями (у меня достаточно отличный от itil'овских рекомендаций подход к PIR, в комментариях привел пару примеров)
- тема души сервисного подхода очень старая и заезженная (однако в комментариях таки появились интересные критерии сервисного подхода)
Подписаться на:
Сообщения (Atom)
