Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
05 декабря 2019 Из жизни РМа
0

Что такое субоптимизация, и почему это плохо

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM
-->




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

Кусочек из книжки У.Детмера “Производство с невероятной скоростью”, чтобы велосипед не изобретать:

Субоптимизация – это не что иное, как улучшение одной части системы за счет других или за счет системы в целом. Кто из нас не слышал высказываний вроде: «Наша задача – выплыть самим, а как они будут выплывать – не наше дело»? В этом и заключается суть субоптимизации – люди (руководители) обычно волнуются за успех в своей области деятельности, не задумываясь особо об успехе остальных элементов системы.

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

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

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

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

Когда говорят, что система – это нечто большее, чем просто сумма частей (определение синергии), подразумевается, что присущая системам внутренняя связность позволяет им достигать более значительных результатов, чем те, на которые способна любая отдельно взятая часть. Но синергию нельзя получить, максимизировав отдачу от каждого компонента системы, – нужно координировать и синхронизировать работу всех ее частей. Это означает, что для максимальной выгоды системы в целом некоторые ее элементы, возможно, должны работать не на полную мощность.

Хотя проекты – это и не совсем про производство, точнее и не скажешь. Что получается в жизни – если проектный офис работает не как управляющий орган, а как поддерживающий или контролирующий (= не выполняет проекты сам, РМы находятся в других подразделениях), то руководители проектов, ответственные за свои бизнес-направления и выполняющие поставленные им KPI, начинают бороться за свой кусочек солнца, а именно за дефицитные ресурсы (та же архитектура или информационная безопасность) или просто аккуратно обходить централизованные требования, обеспечивая быструю реализацию проектов именно по своему направлению. А что там будет в целом с компанией, когда данные из этой системы окажутся нужны где-то еще, а технически это будет невозможно, или когда аудит выявит несоответствие тому же GDPR – их не слишком волнует, учитывая, что KPI – удовлетворенность бизнес-заказчика по направлению (формально, конечно, KPI на соблюдение корпоративных стандартов тоже есть, но какой-то необязательный).

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





комментарии

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

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: