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

Management by objectives

Одной из центральных тем библиотеки ITIL v3 и может быть главным ее достижением является Continual Service Improvement (CSI) – постоянное совершенствование услуг (а точнее – непрекращающееся совершенствование услуг, хотя это и не очень привычно русскому уху). Причем если сложности с организацией и исполнением тех или иных процессов ITIL (управления уровнем ИТ-услуг или инцидентами – неважно) могут быть оправданы отсутствием опыта применения сервисного или процессного подходов (это действительно требует некоторой привычки), то недостаточное внимание к совершенствованию – скорее показатель зрелости практики менеджмента, как такового. Обобщая опыт ITSM-проектов последних восьми с лишним лет, я могу сказать, что организации систематического совершенствования определенно уделяется меньше внимания, чем это необходимо. И совсем не из-за недостатка хороших материалов на эту тему.

Книга ITIL Continual Service Improvement описывает нескольких важных техник, используемых для организации совершенствования. Например, там есть очень хорошее (тем более что весьма краткое) описание техники SWOT-анализа и такого инструмента стратегического планирования, как Balanced Scorecard (хотя здесь изложение с моей точки зрения оставляет желать лучшего). Но есть как минимум одна незаслуженно забытая в этой книге методика, очень важная для CSI, – Management By Objectives (MBO). Чем же она так важна?

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

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

Отсюда и вытекает ответ на вопрос «Чем же она так важна?»: тем, что позволяет более полно использовать творческий потенциал руководителей, включая их в процесс развития, а также повысить степень их ответственности за получаемые результаты.

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

  • качества постановки целей верхнего уровня (что является ответственностью топ-менеджмента организации), которые потом подлежат декомпозиции на цели следующих уровней для планирования конкретных мероприятий по совершенствованию;
  • качества анализа текущей ситуации – контекста, находясь в котором организации необходимо достигать поставленные цели. Именно для анализа контекста чаще всего применяется SWOT. В качестве иллюстрации могу сказать, что за последние 2 года я выполнял SWOT-анализ в 80% проектов (иногда совместно с заказчиком, иногда – самостоятельно) и использовал полученные результаты при планировании дальнейших действий;
  • наличия информации об операциях, которая позволяет достоверно измерить текущее состояние (baseline) и прогресс в совершенствовании. На мой взгляд, именно ограничения в измерении делают MBO мало применимой к планированию первых шагов по организации процессного управления ИТ. Но если какие-то процессы уже организованы, и собранная статистика позволяет делать выводы, «опираясь на цифры», применение MBO может дать существенно более обоснованный и значимый для бизнеса план совершенствования, чем план, основанный на измерении уровня зрелости процессов.

Собственно, написать эту заметку меня побудил один недавно завершенный проект, в котором мы активно использовали MBO для разработки программы совершенствования. Я очень рассчитываю, что сделанная нами работа принесет заказчику значимую пользу. Надеюсь на коллег, от которых это зависит. Жду ваших примеров применения MBO и достигнутых результатов. Кто готов поделиться?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 5

  • Pavel Solopov

    Как правило, основная проблема совершенствования: дать ответ на вопрос "Зачем?".

    • Павел, это Вы к чему?

      • Andrey Kapustin

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

        Чтобы дать контекст: говорить буду о своем текущем проекте, и о постановке целей для проекта (не для портфеля и компании в целом). Данный проект объявлен "не стратегическим" ( на смену ему идет "стратегический" ). Ситуация такова, что данный ярлык на проекте, (видимо) вынуждает менеджеров как на стороне Заказчика , так и на стороне аутсорсера (от уровня PMO и выше), впадать в ступор при прямом вопросе: Каковы цели-перспективы "не стратегического" проекта? Есть ли стратегия?

        Вами замечательно отмечено:

        Польза от применения MBO в существенной степени зависит от трех факторов:

        качества постановки целей верхнего уровня (что является ответственностью топ-менеджмента организации), которые потом подлежат декомпозиции на цели следующих уровней для планирования конкретных мероприятий по совершенствованию;

        В моей, логично 🙂 сложившейся ситуации, описанного Вами фактора 1 (осозноваемого желания сверху) не наблюдаю. (Я конечно утрирую: желание получать деньги от Заказчика как можно дольше, никто не оменял…)

        (далее гонг и надменно-вызывающий голос Ворошилова)
        А теперь, дорогие знатоки, внимание, вопрос: Зачем что-либо улучшать в данной ситуации? 🙂

        • Андрей, вопрос, который Вы ставите, очень важен, хотя и не имеет оношения к MBO. Не имеет отношения потому, что MBO помогает выстроить систему "проводимости" целевых установок и соответствующего контроля от топ-менеджмента к линейному менеджменту, но не помогает сделать так, чтобы топ-менеджмент захотел поставить нужные (и тем, наверно, более непростые) цели. Это вопрос лидерства и в выборе целей, и в воле к их достижению. Это определяется не применяемыми методиками, а только личностью руководителя и культурой организации, которая принимает сильных лидеров и отвергает неспособных к прорыву.

          Я думаю, здесь важно ответить себе на два вопроса:

          1. Сверху "нет желания" (как Вы пишете) или не хватает видения? Если второе, можно попытаться помочь обрести видение и превратить его в желания. К примеру, в проекте, по мотивам которого появилась эта заметка, целевое состояние сверху тоже не родилось естественно, без лишних усилий в ходе приятной беседы. Разговор все время скатывался от того, что нужно достичь, к тому, как это работает сейчас. Однако я имел заготовки, которые в итоге помогли мне получить нужную установку и затем превратить её в набор взаимосвязанных измеряемых целей. И сейчас я понимаю даже больше – что я не использовал всех возможностей, что были и другие способы.

          2. Вы лично в этой ситуации видите для себя возможность самореализации (например в виде внутреннего драйвера, помогающего "найти" нужное направление и начать движение) или Вы зависите от того, начнется ли нужная Вам инициатива сверху?

          Ответы на эти вопросы приведут Вас к выбору одной из трех стратегий: а) ждать перемен и пока терпеть сложившуюся ситуацию, б) всеми силами бороться и инициировать перемены или в) перестать попытки "оживить дохлую лошадь" и искать другое место работы, где Ваши возможности по самореализации расширятся. Фишка в том, что личный выбор всегда кажется нам труднее выбора, который стоит перед другими людьми (например, нашими руководителями). Но время бежит. И решение принять придется.

          Павел же, насколько я его понял, писал немного о другом – о наличии критериев необходимости совершенствования. Развитие возможно всегда, но требует ресурсов. Оправдана ли их растрата (особенно когда получение нужных ресурсов требует серьезной мобилизации)? И здесь моя позиция такова: на этот вопрос надо иметь предметный ответ в каждом конкретном проекте, но дать этот ответ в общем виде нельзя. Т.е. можно, но он не будет информативным, не поможет принять решение. В упомянутом проекте у меня это ответ был, в цифрах.

          • Andrey Kapustin

            Дмитрий, спасибо за развернутый ответ.

            Не смотря на казалось бы притянутость моего кейса к Вашему посту, хотел бы показать,что вектор моего вопроса совпадает (в том числе и с Вашей) интерпретацией вопроса Павла:

            Павел же, насколько я его понял, писал немного о другом — о наличии критериев необходимости совершенствования. Развитие возможно всегда, но требует ресурсов. Оправдана ли их растрата … ?

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

             Развитие возможно всегда, но требует ресурсов. Оправдана ли их растрата (особенно когда получение нужных ресурсов требует серьезной мобилизации)? И здесь моя позиция такова: на этот вопрос надо иметь предметный ответ в каждом конкретном проекте, но дать этот ответ в общем виде нельзя.

            Согласен. Все KPI не внедрить, да и по всем измерять не надо. Формирование "списка проблематизаций" для проекта – дело индивидуальное.
            Однако мое убеждение раскрыто в начале комментария: чтобы ответ был предметным вплоть до цифр, должно быть все разъяснено с целями. Исходя из целей (чьих ? 🙂 ) вопрос "Зачем?" не появится.


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM