Ошибки бимодального управления

26

 

Ошибки бимодального управления или что первичней: процесс или  проект.

Управление проектами в компании – это основа и движущая сила компании к её успеху и верный путь постановки и оптимизации текущих и новых процессов управления. Процесс – это завершенный проект, который одобрен управляющим советом компании и её президентом.

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

Создание в компаниях проектных офисов позволит решить  следующие задачи:

1. Анализ текущего состояния реестра проблем в организации.

2. Рассмотрение предложений по новым предложенным решениям.

3. Постановка целей и их согласование со всеми участниками, читай, подразделениями компании и внешними контрагентами.

4. Согласование. определение и синхронизация плана работ, для достижения поставленных целей.

5. Определение ресурсов для решения задач по достижению обозначенных целей.

6. Подготовка и согласование команд ­ выделение ресурсов текущих структур управления для участия в утвержденных проектах.

Далее проектную деятельность необходимо проводить в соответствии с развернутой в компании системой/процессами управления по целям, которая позволяет избежать противоречий матричной системы управления проектами.

Управление по целям (Management by Objectives, МВО) - ­ метод управления, призванный приблизить организацию к достижению поставленных перед ней целей, сделать ее максимально ориентированной на достижение конкретных результатов. МВО объединяет в себе такие важные аспекты менеджмента как стратегическое планирование, постановка целей (по принципу SMART), контроль, оценка и мотивация персонала.

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

Каково ваше мнение о создании и/или использовании проектных офисов и их привлечении к реорганизации современных компаний?


5552
Коментарии: 26

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Виктор Федько
    Рейтинг: 367
    Независимый эксперт
    Эксперт
    19.01.2016 08:28

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

    Проектный офис - это здорово, только каждой ли компании он нужен и что мы тут под ним понимаем? Каков д.б объем проектов, чтобы офис был окупаем и востребован? В любой ли отрасли это необходимо?

    • Владимир Когут Виктор
      Рейтинг: 10
      РеутДент, ДентБлан, Медсофт
      Руководитель службы ИТ
      21.01.2016 10:03

      Согласен. Выглядит замечательно. И даже не только теоретически, но кое-где и практически, как например в "сбере". Только масштабчик там ого-го.
      Даже для Вашего МПО - это было бы накладно, хотя сняло бы много головных болей.

      • Виктор Федько Владимир
        Рейтинг: 367
        Независимый эксперт
        Эксперт
        21.01.2016 11:58


        Накладно - не то слово). И насчет снятия головной боли - тоже не факт. Одну боль снимешь - другая появится.
        Мы сейчас это направление начали постепенно развивать, вводим зачатки проектного управления. сначала по Ит-проектам. Готовим почву, проводим ликбез и т.п. Посмотрим, что получится. И как приживется. вообще.
        Проектное управление - инструмент тонкий, и отнюдь не всеобъемлющий. Это всего лишь один из способов управления. Не всем и не везде годный.

        • Владимир Когут Виктор
          Рейтинг: 10
          РеутДент, ДентБлан, Медсофт
          Руководитель службы ИТ
          21.01.2016 17:04

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

          • Виктор Федько Владимир
            Рейтинг: 367
            Независимый эксперт
            Эксперт
            21.01.2016 18:18

            Все зависит от конкретной обстановки. Иной раз ходить нужно еще больше и чаще))). Повторюсь - головную боль может и излечить, но при том заработать геморрой :)
            Парадокс, однако.

  • 19.01.2016 17:40

    Про проектные офисы имею набор впечатлений. С одной стороны, многие крупные компании, особенно банки, их точно организовывали годы назад. И тогда ИТ-проекты рассматриваются как часть "проектов вообще", и управляются так же. То есть НЕ айтишниками. И понятно, что в банке, например, это разумно: для них проект - это запуск нового банковского продукта чаще всего, и там ИТ-компонента - одна из многих необходимых, и важно единое управление.
    Для девелоперов проект - это само строительство, с проектирование и разрешающих документов начиная, там ИТ компонента - вообще то О-малое от всего остального. Поэтому и управлять ИТ проектом можно независимо.
    Для торгово-производственных компаний тоже чаще есть смысл ИТ-проектами управлять отдельно. Насколько это оправданно, не могу судить, но такое наблюдаю. Возможно, скоро это будет меняться. Мы перед праздниками проводили опрос членов сообщества о том, чего они ждут от 16 года и что намерены делать. Так было неожиданно много ответов, что самое интересное, что они будут делать - это организовывать проектный офис. Только для ИТ или для всей компании - мы не уточняли.
    И есть еще одна сторона дела. Довольно часто были у меня случаи, когда сегодня люди говорят - о, мы всех обучаем проектному управлению, у нас PMBook прям настольная книга, все только по науке теперь. В любых проектах, особенно в ИТ. А придешь к ним года через три, про другое уже писать, спросишь - ну как, проектные менеджеры теперь у вас кругом, да?....они так мнутся, говорят: ну, вы знаете, мы проектное управление оптимизировали под свои условия. А что же это значит? А значит это, что они перестали вести всю документацию и оставили только отдельные элементы проектного управления. Скажем. по прежнему для вида пишут устав проекта. И все! Потому как дорого все это и долго. И не надо никому. Читай - не окупается. Поэтому было бы очень интересно узнать о реальной практике создания проектных офисов, особенно потому, что это в планах многих на новый год.

    • Владимир Когут
      Рейтинг: 10
      РеутДент, ДентБлан, Медсофт
      Руководитель службы ИТ
      21.01.2016 10:06

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

    • 21.01.2016 14:47

      Ольга,
      я встречал 2 причины этого:
      1) самая распространенная - попытка "в лоб" применить практики, описанные в PMBOK в расчете, что "они сами сработают". Это естественно не происходит, отсюда отторжение "это не работает".
      2) более редкая, но более современная :) Думающие люди понимают, что в современном мире для не огромных проектов, которых большинство, практика PMBOK не эффективна, agile подходы дают лучший результат.
      По моим наблюдениям Проектные офисы стараются поддерживать более формализованные методологии, т.к. они ближе к стандартным привычным бюрократическим механизмам, а также потому что видят в agile угрозу своему существованию.

      • Виктор Федько
        Рейтинг: 367
        Независимый эксперт
        Эксперт
        21.01.2016 18:21

        а также потому что видят в agile угрозу своему существованию.

        А так и есть на самом деле. Конкуренция в чистом виде. И приверженцы того или другого правы по-своему.

  • 19.01.2016 17:43

    Нашла недавно очень любопытный конкурс проектного управления: для госкомпаний. Называется "Проектный Олимп". 100 организаций приняли участие в 2015 году. В числе финалистов Сбер, Росатом, Северсталь, но и Белгородская область тоже.

  • 20.01.2016 11:10

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

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    21.01.2016 19:40

    ИТ, как мне кажется, имеют явное сходство с традиционной медициной. И тут и там много непонятных непосвященным терминов. И тут и там принцип "Не навреди". Общая база и узкая специализация. Но, на мой взгляд самое важное, "Всё яд и всё лекарство". Уместность, дозировка и своевременность использование какого-то определённого инструмента из всего их многообразия в нужный момент - вот то, что отличает хорошего ИТ-специалиста от обычного.

    • Виктор Федько Марк
      Рейтинг: 367
      Независимый эксперт
      Эксперт
      21.01.2016 20:26

      "Умри ,Денис. Лучше не скажешь" (с)

    • Марк
      22.01.2016 12:55

      Да! Но тут мало констатации факта. Можно ли очертить точные границы применения лекарства "Проектный офис" именно для ИТ-подразделения? У медиков же как: диагноз такой-то, показатели по анализам такие-то, лет пациенту столько то, вес такой то. Отлично, по 350 г, в вену, за полтора часа, через день 2 недели. В процессе наблюдать, что получается: поплохеет - отменить немедленно. Может ли мы так же подходить к проектному управлению? :))

      • Марк Шварцблат
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        22.01.2016 13:06

        Можем. Если у пациента есть медкарта со всеми анализами. :)

        Ну вот руководил я проектным офисом. Вынес из этого мысль, что он нужен только там, где есть регулярные разноплановые проекты. Но поможет ли это конкретному пациенту? Для начала хорошо бы узреть anamnesis morbi и anamnesis vitae. :)

        • Марк
          22.01.2016 13:21

          В медицине я ничего не смыслю. Меня учили делать численные модели, изображать реальный физический процесс уравнениями. И когда такие модели строят, всегда очень аккуратно надо следить, находимся ли мы все еще в зоне разумного их применения. О классических моделях известно прекрасно, каковы должны быть параметры физических процессов, чтобы можно было применять такую модель. Ограничения всегда надо держать в уме, иначе можно очень смешное насчитать...Что и бывает, на самом деле: увлекаются люди, забывают, где у них физика. И по этому по всему мне всегда хочется очертить однозначно области применимости и управленческих инструментов, и ИТ-средств, в том числе приложений разных. Чтобы точно сказать: если так - то вот сюда, а если вот такое - то вовсе в другую вам область, коллеги. Но совершенно мой высоко детерменированый подход не находит сторонников! нет точного знания, вот что меня огорчает. Вот вопрос: а вообще точное знание возможно здесь? Если да, то надо до него докапываться. Если нет - не надо морочить людям голову.

          • Марк Шварцблат
            Рейтинг: 30
            КТ "Акведук"
            ИТ-директор
            11.02.2016 15:39

            Как только в проекте появляются люди - сразу можно забыть про точность в несколько 9-к после запятой. :) Поэтому и рекомендации из серии "скорее да, чем нет" и на основе экстраполированной статистики. Как-то так.

  • Дмитрий Кудрявцев
    Рейтинг: 30
    CIO-on-demand.ru
    партнёр
    22.01.2016 14:38

    Очень простая аналогия приходит из института вооружённых сил. У них же в случае "горячей" фазы сплошное управление проектами: тактические планы, ресурсное обеспечение, дедлайны - вот это вот всё.

    А когда войны нет - штат в 100-500 раз сдут, зато возможность его развернуть обеспечивается организационно (как в том огнемёте - всегда запален фитиль). Все понимают, что базовые навыки управления проектами передаются буквально за недели, а потому что их держать, раз работы нет.

    Мой опыт говорит о том, что изменения в организации нужно организовывать и ставить на руководство серийного ПМа. А вот команду держать в штате практически никогда не требуется, это никому не удобно ни финансово, ни организационно.

  • 22.01.2016 16:08

    Общее направление развитие систем управления идет по линии увеличения степени идеальности, которое осуществляется увеличением степени динамичности, переходом системы в надсистему и согласованием смежных систем управления.

    Согласование структур управления внутри компании осуществляется при любых изменениях в системе её управления с учетом внешней окружающей среды. Развитие системы управления осуществляется, как правило, не по одному из рассмотренных выше законов, а комплексно.

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

    Это всё классика. И я совершенно согласен с Дмитрием о возросшей роли ПМ в современной компании...

  • 22.01.2016 16:12

    Анализ показывает наличие трёх типов требований к системе управления:

    • 1.Очевидные требования.

    • 2.Требования «базового» качества.

    • 3.«Восхитительное» качество. Именно к третьей группе относится повышение эффективности самой системы и процессов внутри неё. Это облегчает построение стратегии по развитию системы и отношений внутри и вне её.


    • Рассматривая аналогию с пирамидой Маслоу, мы заметим, что если не удовлетворены требования низшего уровня, то компания не должна думать о требованиях последующих уровней, в соответствии с законом возрастания потребностей.

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


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


  • 22.01.2016 16:26

    Анализ показывает наличие трёх типов требований к системе управления:
    1.Очевидные требования.
    2.Требования «базового» качества.
    3.«Восхитительное» качество. Именно к третьей группе относится повышение эффективности самой системы и процессов внутри неё. Это облегчает построение стратегии по развитию системы и отношений внутри и вне её.

    Рассматривая аналогию с пирамидой Маслоу, мы заметим, что если не удовлетворены требования низшего уровня, то компания не должна думать о требованиях последующих уровней, в соответствии с законом возрастания потребностей.

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

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

  • Александр Громцев
    Рейтинг: 63
    ССЗ " Вымпел", ОАО
    Начальник управления по ИТ
    05.02.2016 09:22

    ИТ служба скорее многопоточна, чем бимодальна , наверное так!

  • Владимир Тырнов
    Рейтинг: 60
    REDMOND-IG
    Зам. ген. директора по техническим вопросам
    16.06.2016 12:46

    "Процесс – это завершенный проект, который одобрен управляющим советом компании и её президентом."

    Данная информация, на мой взгляд, скорректирует ожидания от результатов работы проектного офиса. «В лоб» данный вопрос не прошибаем и скорее всего потребуется искать пути гибкого компромисса между проектами и процессами.
    В ITIL данный компромисс найден за счет определения результата работы проектной группы – разработанный сервис (услуга). Но проекты в компании это не только ИТ направления. Возникает вопрос, что будет результатом проекта для коммерческих структур? В случае разработанных бизнес процессов напрашивается ответ – сервис (услуга). Получатели данной услуги - подразделения компании, которые в своей бизнес деятельности вынуждены иметь на входе своих бизнес процессов ожидаемый ими ресурс (продукт, материал, информацию…) А это уже другая, сервисная архитектура компании, где проект - процесс создания услуги.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.