🪐 Московский Планетарий

На выходных немного непрофессионального контента. На днях впервые был в Московском Планетарии. Ходили на спектакль ‘Коперник’. Скорее это даже не спектакль, а мультимедийное шоу.

Шоу очень необычное. Комбинация сценического действия, акробатических этюдов и, самое главное, видео-проекции на куполе планетария. Как все это выглядит можно посмотреть на приложенных фото и видео.

Меня заинтересовало, как все это реализуется и что это за шарообразная конструкция в центре зала, которую видно на последнем фото и одном из видео.

Оказалось, что это специальная разработка для планетариев, предназначенная для проекции звездного неба, солнца и планет на купол. Если интересно, почитать и посмотреть подробности можно по ссылкам ниже:
🔘Описание Universarium
🔘Как это работает (видео)

Перед шоу ещё была небольшая обзорная экскурсия по залам Планетария. В общем, и само место интересное, и мероприятие необычное.

#досуг

Недавно в канале Антона Субчева была хорошая тема про ошибку PMO, когда всё построено вокруг метрик самого PMO, но бизнес-результат никто не видит.
Я оставил комментарий:

Метрика сама по себе бесполезна, если на её основе не принимается управленческое решение.

И добавил, что видел похожую ситуацию:

По крупным межфункциональным проектам, которые ведутся в единой ИСУП, на ежемесячной основе собираются статус-отчеты. Но в какой-то момент оказалось, что у этой информации нет реального потребителя.

Антон предложил раскрыть эту мысль подробнее. Поэтому раскрываю 👇

На бумаге всё выглядит правильно.
Есть проекты.
Есть ИСУП.
Есть ежемесячный статус-отчёт.
Есть поля по срокам, бюджету, рискам, проблемам, статусам.
Есть обязанность руководителей проектов обновлять информацию.

То есть с точки зрения методологии процесс был.
Но обещать не значит жениться наличие процесса ещё не означает наличие управления.
Регламент фиксирует обязанность отчитаться.
Но сам по себе не создаёт обязанности принять решение.
Поэтому ключевой вопрос оказался в другом:

Кто на основе этих данных принимает управленческие решения?

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

И в этой конструкции оказалось, что у статус-отчётов по крупным межфункциональным проектам нет очевидного владельца управленческого решения.
Первому лицу компании неинтересно смотреть на проекты в такой гранулярности.
У финансового директора уже есть свой настроенный регулярный процесс, который охватывает 100% финансовой деятельности компании: фактическое освоение, инвестиционный контроль, постинвестиционный мониторинг.
А руководители бизнес-направлений не всегда заинтересованы в таком формате отчётности по нескольким причинам:
▫️Во-первых, в единой ИСУП находятся не все проекты сегмента, а только крупные. Значит, для руководителя сегмента это не полная картина управления.
▫️Во-вторых, в блоках и сегментах годами выстроены свои системы коммуникации. Они быстрее, привычнее и понятнее главному заказчику, чем статус-отчёт в ещё одной корпоративной системе.
▫️В-третьих, никто особенно не любит, когда внешний по отношению к бизнес-направлению контур приходит не с управленческой пользой, а с дополнительным сбором данных.

И вот получается типичная ловушка PMO.
Механизм есть, Данные есть, Регламент есть, Система есть, Шаблон отчёта есть, Дисциплина заполнения есть.
Но управленческого контура вокруг этой информации может не быть.

PMO часто думает, если мы настроили процесс, внедрили систему, сделали шаблон отчёта и обязали людей его заполнять значит, управление появилось.
Но управление появляется не в момент заполнения отчёта.
Управление появляется тогда, когда на основе данных кто-то принимает решение с последствиями для проекта, бюджета, ресурсов или бизнес-результата.
Например:
▫️остановить проект;
▫️пересмотреть сроки;
▫️перепроверить бизнес-кейс;
▫️изменить состав портфеля и т.д.

Перед тем как вводить любую метрику или статус-отчёт, PMO должно ответить на четыре вопроса:
1️⃣Кто владелец решения? Кто имеет полномочия что-то изменить на основе этой информации?
2️⃣Где принимается решение? На комитете, статус-встрече, инвестконтуре, операционном штабе или другом управленческом ритуале?
3️⃣Какие решения реально возможны? Остановить, ускорить, перераспределить ресурсы, изменить приоритет, пересобрать бизнес-кейс?
4️⃣Что изменится после решения? Бюджет, сроки, команда, ответственность, приоритет, ожидаемый эффект?
Если ответов на эти вопросы нет, метрика почти неизбежно превращается в ритуал.

При этом оговорюсь, описанный механизм у нас всё равно продолжает жить, несмотря на все ограничения. Но в деталях я уже не могу открыто рассказывать, как именно это устроено.
Буду рад вашим комментариям 👇

📲 MAX | 📱 LinkedIn | 📱ASchepin.ru