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

Совмещение ролей

Опубликовано 23 марта 2012
Рубрики: ITSM, Всё это - ЛЮДИ, Процессы, Управление инцидентами, Управление проблемами
Комментарии

 

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

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

Менеджер двух процессов (а это весьма энергичный человек) убедил меня, что сможет «переключать» голову в нужный момент времени. Посмотрим, к чему это приведет….

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Дмитрий Исайченко

    Миша, это системная ошибка. Да, возможно конкретный талантливый человек сможет совмещать эти две роли. Но для конкретных талантливых людей процессы вообще могут быть не очень нужны – они справятся на энтузиазме. Процессы нужны для того, чтобы снизить зависимость от талантов отдельных людей, поэтому правила назначения на роли в регламентах процессов INC и PRB должны прямо запрещать такое совмещение. И разумно, чтобы менеджер не нарушал нормативных документов по своим процессам.
    А менеджеров всегда негде взять (если не решать задачу). У нас и президента негде взять. Кроме г-на Путина решительно некому быть президентом. И министра внутренних дел негде взять. Поэтому чтобы ни творилось в милиции/полиции г-н Нургалиев сохраняет свой пост, поскольку иначе президент “останется ни с кем”. Ну нет у нас в стране менеджеров, негде взять! Вся надежда – на незаменимые таланты.

    • Вадим

      Ну нет у нас в стране менеджеров!

      есть только эффективные менеджеры! ура, товарищи!

  • Михаил Тобурдановский

    Дима, скажи пожалуйста, а почему мы думаем, что этого нельзя делать? На основании собственной практики и практики коллег консультантов? Потому что так написано в умных книжках? Ты можешь привести конкретный пример, когда из-за такого совмещения ролей все было плохо? Может, коллеги с этим сталкивались? Есть здравый смысл, есть хорошие практики – а есть жесткая реальность 🙂

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

    Про системную ошибку – я тоже так думал, но сейчас не знаю… Возьми небольшую организацию, с маленьким ИТ – так там скорее всего менеджером многих процессов будет один и тот же человек. Тоже системная ошибка? 🙂

    • Дмитрий Исайченко

      “Я могу привести два примера, когда как раз выделенный менеджер процесса управления проблемами не справлялся, и процесс тихо умирал. Поэтому в данной ситуации из двух зол мы выбрали меньшее.”

      Железная логика 🙂 Замечено, что все люди, которые ели огурцы, в конце концов умирали. Поэтому огурцы мы есть не будем. Есть медицина и диетология, а есть “жесткая реальность”.

      “Возьми небольшую организацию, с маленьким ИТ — так там скорее всего менеджером многих процессов будет один и тот же человек. “

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

      • Михаил Тобурдановский

        Про огурцы улыбнуло:-) Однако на вопрос ты не ответил – тебе известны примеры, когда из-за подобного совмещения ролей было плохо? Конкретные примеры, из жизни?

        • Дмитрий Исайченко

          Нет. Будем пробовать на заказчике? Это идея.

          Меня, кстати, никогда не било 380В. Логика подсказывает, что это неприятно, но есть электрофизика и анатомия, а есть “жесткая реальность”. Давай попробуем на заказчике, а? Интересно ведь, как это бывает.

          • Михаил Тобурдановский

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

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

            И никакой тренировки на заказчике здесь нет.

        • Михаил Тобурдановский

          “Многих — не значит именно этих двух. При прочих равных лучше совместить PRB с CHG”
          Очень сильно сомневаюсь, что в маленькой организации будет выделенный PRB менеджер. Скорее всего, это будет один человек, который будет совмещать и INC, и PRB…

          • Дмитрий Исайченко

            А почему не с CHG, как я писал? Обоснуй, пжл, интересно.

            • Михаил Тобурдановский

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

              Понятно, что логичнее совместить PRB и CHG, но здесь он до кучи еще будет и INC менеджером, и менеджером еще много чего….

    • Роман Журавлёв

      За ДИ не отвечу, но я думаю, что этого не стоит делать потому, что у процессов конфликтующее назначение, за реализацию которого этот человек должен будет отвечать. И в рамках этого назначения могут устанавливаться конфликтующие цели. Например,
      “Сократить время решения инцидентов до N минут” и
      “Сократить долю повторяющихся инцидентов схожей симптоматики до X %”.

      Есть же классический почти уже пример: у тебя под окнами на улице Свободы на трамвайных путях лоб в лоб встречаются два чудака, решившие, что они спешат и что они – как трамваи, только круче. В результате Свобода стоит от МКАД до Волоколамки и обратно, а трамваи – аж до Сокола.
      Теперь, значит, приезжает на место инспектор ДПС и спрашивает себя: что сделать – растащить уже эту красоту по обочинам, чтобы северо-запад Москвы поехал наконец, или сначала тщательно зарисовать, сфотографировать и описать этот пейзаж, чтобы можно было потом разобраться, кто из чудаков был более неправ.
      (наши инспекторы будут действовать по второму сценарию, ибо у них в голове действует примат расследования над восстановлением… и вообще – там действует примат, но сейчас не об этом)

      Пока просто представим, что инспектор будет действовать, как ему велят, а велит, конечно, менеджер. А ему как раз поручили сократить время разбора ДТП и заодно повысить качество расследования оных. И что ему теперь велить своему инспектору?

      ***
      Если мы зачем-то сделали из процесса поддержки два разных контролируемых потока работ, они должны управляться независимо. Если мы не можем или не хотим управлять ими независимо – зачем мы сделали два потока работ?

      • Михаил Тобурдановский

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

        Играют же шахматисты сами с собой. 🙂 Вот и посмотрим, насколько у человека получится “переключать” голову. 🙂

      • Pavel Solopov

        Честно говоря, класическая тема с совмещением INC и PRB, мне не совсем понятна. Для того чтобы найти причину, тем более корневую, которая скорее всего не первая причина инцидента, вовсе не обязательно не устранять инцидент.
        Надо учиться собирать диагностическую информацию об инциденте при его регистрации, надо учиться повторять ситуацию и т.д.
        Другое дело, что нельзя совмещать исполнителей этих работ это да, а руководить этой деятельнсотью вполне сможет и один человек (если объём задач позволяет).

        • Роман Журавлёв

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

          Тезис про “вовсе не обязательно не устранять инцидент” не понял.
          Никто ведь вроде и не говорил,что это обязательно?
          В общем же, для того, чтобы найти в инфраструктуре ошибки – а именно этим занимается PRB – инциденты могут вообще не использоваться, верно ведь?

          • Pavel Solopov

            Про “не устранять” это я к тому, что в качестве основного аргумента в пользу разделения менеджера инцидентов и менеджера проблем приводится разница в приоритетах процессов:
            инциденты должны как можно скорее восстанавливать работоспособность, а проблемы должны искать корневые причины.
            Из чего я для себя сделал вывод, что противоречие (по мнению лучших практик) возникает на почве того, что менеджер инцидентов заинтересован решать их как можно быстрее, в то время, как менеджер проблем заинтересован чтобы инциденты висели подольше, дабы разобраться в их природе.
            Если этого противоречия нет, то в чём противоречие, которое никак не позволяет совместить эти две роли?

          • Pavel Solopov

            возможно, все наоборот

            Роман, при всём моём к Вам уважении, это уж совсем полная ерунда выходит.
            Во-первых, выходит, что работников у нас мало, зато руководителей полно?
            Во-вторых, проблема совмещения исполнителей намного серьёзней, нежели совмещение руководителей. Исполнителю, реально, придёться разрываться между “посидеть подумать” и “бежать тушить”. Вот хорошая илюстрация к этой ситуации, кстати, попалась: http://youtu.be/PbRWWRQYU9Y.
            В то время, как совместить, в одном человеке обязаности по координации различной деятельности это более реально.

            • Дмитрий Исайченко

              Вот это дискуссия, даже с мультиками 🙂
              Ресурсный конфликт действительно возникает из-за совмещения исполнителей, а не менеджеров, тут я с Павлом согласен. Чтобы им управлять, надо: 1) вводить деление на 2-ю и 3-ю линию поддержки, 2) выделять координаторов проблем с гарантированным резервом % времени под их обработку, 3) мотивировать линейных менеджеров сбалансированным набором метрик по обоим процессам (INC+PRB). Ничего из перечисленного не требует совмещения менеджеров двух процессов, тут уже я с Павлом разошёлся. Или … мы с Павлом разошлись 🙂
              Напротив, совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: “не успеваю, и так работаю по ночам”. Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.
              Два разных менеджера более вероятно (конечно, не гарантированно) обеспечат баланс интересов. А чтобы они не подрались, _владение_ INC и PRB рекомендуется совместить. Это довольно “классическая” конструкция, которая отвечает на вопрос ресурсного конфликта.
              Разумеется, если мы говорим об организации с 10 ИТ-специалистами, эта конструкция не жизненна. От 50 – вполне. И конечно – исключения возможны. Как существуют, наверно, люди, которые до обеда – тираны, а после – демократические правители. Но системно это не работает. Процессы эту особенность игнорировать не могут, поэтому системно совмещение управления INC и PRB и не рекомендовано.
              P.S. Предвидя вопросы: я глубоко убеждён, что главная сложность PRB не в ресурсном конфликте (как в мультике), а в том, что PRB, в отличие от INC, запускается внутренним триггером, и он требует от ИТ-подразделения большего уровня зрелости, чем умение реагировать на поступающие инциденты. Но это уже совсем другая история.

              • Pavel Solopov

                не требует совмещения менеджеров двух процессов, тут уже я с Павлом разошёлся

                Я не говорил, что требуется сомещение этих ролей. Я говорил, что оно вполне себе допустимо и вовсе не так нежелательно, как заявляется в Торе ITIL.

                P.S. Я тут ещё одну интересную мульт-илюстрацию, на выходных подсмотрел, так что ожидайте “скоро на экранах”. Правда там не про роли. 🙂 Там про лучшие -практики вообще. 🙂

                • Дмитрий Исайченко

                  “Я говорил, что оно вполне себе допустимо и вовсе не так нежелательно”

                  Именно в этом мы и разошлись. Я подробно написал, почему я с Вами не согласен. Тем более на период становления процессов.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.