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

Выделенные менеджеры процессов

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

В большинстве организаций, с которыми мне доводилось работать, менеджеры процессов ITSM совмещали свои процессные обязанности с должностными, то есть были предметниками. Даже менеджеры процесса управления инцидентами довольно часто «на самом деле» были начальниками группы первой линии поддержки. Компаний, где роль менеджера того или иного процесса исполнялась выделенным сотрудником, меньшинство.

А жаль. Есть вполне логичные сочетания ролей, которые в крупной компании тянут на 100%-ную загрузку. Например, SLM+PRB, CHG+CFG, INC (даже без совмещения). Выделенный менеджер обладает не только бОльшими ресурсами, но и может более правильно позиционироваться в организации, поскольку он при этом не будет являться начальником одного из отделов, который не должен иметь прямого организационного влияния на смежников. Больше шансов сократить и количество ролевых конфликтов (segregation of duties).

Напротив, в большинстве крупных компаний, с которыми я работал, менеджеры проектов были выделены, и по оргструктуре, и по ресурсам. Интересно, почему? Зрелость предприятий пока во многом такова, что идёт процесс «набора технологической массы», потребность в автоматизации пока обгоняет потребность в управлении? Может ли факт выделения менеджеров процессов управления ИТ являться своеобразным показателем уровня зрелости организации с точки зрения ИТ и практик управления? Или мне «не везло», в Вашей жизни всё как раз наоборот – выделенные менеджеры процессов встречаются на каждом шагу?

Менеджеры процессов, что скажете?

P.S. Зарубежные коллеги, кстати, довольно часто рассказывали о том, что сотрудники работают менеджерами процессов.

БИЗНЕС-СИМУЛЯЦИИ
Профессиональные деловые игры
для ИТ-департаментов и ИТ-компаний

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

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

  • Анатолий Павлюченко

    Работал дублёром менеджера процесса по управлению изменениями в ИТ в крупной транснациональной компании (с зоной ответственности “весь мир”). Надо отметить, что это было ~50% от всех обязанностей.
    Во время становления самого процесса, естественно, это занимало больше времени. После того, как уровень зрелости перешагнул отметку “стандартизован”, нагрузка значительно упала.
    Могу и ошибаться в формальной стороне вопроса, но менеджер глобального процесса по устранению инцидента одновременно являлся и директором (глобальной) службы поддержки. Процесс управления выпусками был тесно интегрированы в процесс по управлению изменениями. Процесс по решению проблем не был формально централизован, но это, скорее, было обусловлено достаточно сильной централизацией инфраструктуры и приложений. Т.е. лежал в рамках ответственности соответствующих подразделений.

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

      “Надо отметить, что это было ~50% от всех обязанностей.”

      Анатолий, уточните, пжл, какие конкретно функции менеджера изменений выполняли?

      • Анатолий Павлюченко

        1. Еженедельное (удалённое или на месте) модерирование совещаний консультативного комитета по изменениям.
        2. Ежедневный мониторинг состояния и диспетчеризация запросов на изменение в автоматизированной системе (HP OV Service Desk).
        3. Регулярные ответы на вопросы и консультации для заполняющих формы для регистрации запросов на изменение (эл. почта, телефон).
        4. Регулярное обновление конфигурации рабочих процессов (wokflow) на предмет изменения маршрутов и ответственных.
        5. Достаточно регулярный пересмотр и обновление набора документов (IT Change Management Policy, IT Change Management Procedure).

        Всё это было приблизительно поровну распределено между двумя людьми, которые дублировали друг-друга при необходимости. Всё остальное время уходило на проектные работы.
        Компания – табачная. [… the world’s third largest industry player, with a global market share of 11% and market capitalization of approximately USD 50 billion. ]

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

          Анатолий, спасибо. 3 уточнения, если позволите:

          1. “Всё это было приблизительно поровну распределено между двумя людьми”
          Значит имеем 2 х 50% = 100%? То есть, если бы был один исполнитель, загрузка была бы полная (или около того), так?
          2. “мониторинг состояния и диспетчеризация запросов на изменение”
          Помогите, пжл, оценить поток изменений. Скажем, крупный ритейл и банки – это поток порядка 50 RFC в неделю. Причём, часть из них касается ответственности разных ИТ-менеджеров (кросс-функциональные изменения). Как было у Вас?
          3. Какие области инфраструктуры находились под управлением процесса? И инфраструктура, и бизнес-приложения? Десктопы (организация для новичков, перемещение) – тоже были в рамках процесса?

          • Анатолий Павлюченко

            1. Выходит, что да. Но схема с дублёром более надёжна!
            3. Централизованные приложения и инфраструктура – полностью. Частично – региональные приложения. Все рутинные запросы (installation, move, add and change) – автоматизированы и не попадают к менеджеру процесса.
            2. Исходя из п.3, на еженедельный CAB попадало между 10-тью и 20-тью запросами. Приблизительно ещё столько же проходило процедуру согласования, минуя CAB. (порядок сохранён, хотя это было более четырёх лет назад. Мог и подзабыть 🙂
            4. Существовал ещё отдельный процесс по работе с партнёрами (vendor management).

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

              1,3,4 – полностью согласен, хорошая практика.
              2 – да, это серьёзный поток.

              Итого, по объёму операций имеем 1 FTE только на CHG.

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

              Ещё вопрос: а должность у Вас как называлась? Вы были прежде всего менеджер процесса + довески или наоборот – ИТ-специалист (технарь, предметник) + менеджер процесса?

              P.S. Я, почему-то, почти уверен в первом варианте 😉

              • Анатолий Павлюченко

                Неа :-). Реальный ITSM!
                Вариант №3/1 IT Compliance Coordinator
                Вариант №3/2 Global IT Policies and Procedures Manager

                http://ua.linkedin.com/pub/anatoliy-pavlyuchenko/3/533/287

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

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

        • Pavel Solopov

          А у меня вот какой вопрос возник:
          нужно ли как-то регестрировать задачи которые решает менеджер процесса? Если нужно так как и где?
          С одной стороны на основании этого можно понимать трудозатраты менеджера, но это не главное.
          А с другой стороны чтобы сам менеджер не забыл чего, и чтобы быть уверенным, что он не забыл – это пожалуй важнее.

          Или считаем, что менеджер существо самомотивированное и самоорганизованное, а все его недочёты выползут в показателях процесса?

          • Анатолий Павлюченко

            Регулярные еженедельные совещания высшего звена руководства ИТ “волшебным” образом мотивируют и наглядно демонстрируют эффективность процесса 🙂 Рекомендую!

            Формальные метрики выполнения процесса: количество поступивших запросов на изменения в календарном периоде (месяц/ квартал/полугодие и т.д) с разбивкой на приоритеты; среднее время выполнения запроса на изменение в зависимости от категории (новая функциональность, новый отчёт, инфраструктура и т.д.).

            Т.е., собственно, эффективность “решения задач самим менеджером процесса” не оценивалась. Его задачи – диспетчеризация и контроль правильности процедуры (маршрута) выполнения. Сроки и финансы – в зоне ответственности инициатора запроса и исполнителя.

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

            Павел, помимо “волшебной мотивации”, упомянутой Анатолием (с чем я полностью согласен), хорошая практика – чеклист для менеджера. После стабилизации процесса он отпадает, но при смене менеджера помогает серьёзно.

            • Анатолий Павлюченко

              Если под чеклистом (на одну страницу) подразумевать вырожденную процедуру (страниц 60-70), то да.

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

                Не совсем. Чеклист менеджера не должен подробно описывать, как выполнять работу. Скорее, что необходимо сделать менеджеру – каждый день, раз в неделю и так далее. Просто чтобы начинающий менеджер надёжно осознал, в чём заключаются его функции. А вот если возникнет вопрос “как?” – велкам в процессный регламент.

              • Вадим

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

  • Вадим

    Не менеджер, но скажу :о))

    Совмещение роли процессного менеджера и линейного, по-моему, связано с неготовностью “разрезать” всю деятельность на “кусочки” (процессы), т.к. не очевиден результат. Все понимают (или думают, что понимают), что будет непонятно “кто шил ITSM-костюм” и то что “к пуговицам (например, обработке инцидентов) претензий нет”. А как связать одно с другим им неочевидно.
    Более того, линейные менеджеры реально являются менеджерами ресурсов, а процессные, видимо, еще нет.

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

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

    Не взыщите, если путано объяснил.

    • Pavel Solopov

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

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

      • Вадим

        А проекты они как бы не находятся пока в области чьих-то интересов.

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

        В этом смысле процессы от проектов IMHO мало отличаются.

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

          +1.

          Но я также скажу “как бы не так” про Вашу идею о более высокой зрелости управления проектами по сравнению с процессами. Раньше начали – да, научились лучше управлять – “как бы не так” 🙂

          • Вадим

            я соглашусь, что все очччень индивидуально. кто-то научился, а кто-то нет, несмотря на написанные процедуры, формы документов и прочее…

        • Pavel Solopov

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

          • Вадим

            такой интерес только один – сколько в день зарплаты появляется в кошельке (или на карточке)?

            • Pavel Solopov

              Такой же интерес, как у руководителя отдела обслуживания пользователей в процессе управления инцидентами.
              Или как у начальника отдела сетей и связи в процессе управления конфигурациями и т.д.
              Если бы не было процессов, эти люди всё равно занимались бы этой деятельностью и отвечали бы за неё (хотя, возможно в несколько ином виде).
              А проект, как правило, связан с внедрением новой деятельности или её изменением. Особо подчёпкиваю КАК ПРАВИЛО, т.е. не всегда и не обязательно так.

              • Вадим

                Если бы не было процессов, эти люди всё равно занимались бы этой деятельностью и отвечали бы за неё (хотя, возможно в несколько ином виде).

                вполне определенно в другом виде – достаточно посмотреть на организации, в которых ITIL в явном виде не применяется.

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

                P.S. на самом деле аналогичная картина и со зрелостью в области управления проектами

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

                “Если бы не было процессов, эти люди всё равно занимались бы этой деятельностью и отвечали бы за неё”

                Всё так, только понятие менеджера процесса такому состоянию абсолютно не свойственно – каждый отвечает за свой участок, а не за результат. Чтобы убедиться в этом, достаточно вспомнить, какие трудности возникают у вновь назначенного менеджера процесса в организации, только начавшей применять процессный подход к управлению ИТ.
                А мой-то вопрос как раз не про процессы в целом (в сравнении с проектами), а про выделение исполнителя роли менеджера процесса. Это такая же (ОК, аналогичная) матрица, как и в управлении проектами.

                • Pavel Solopov

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

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

                    “руководитель какого-нибудь отдела поддержки пользователей процентов на 80 покрывает функционал менеджера процесса”

                    Ой как сомневаюсь. Например, его должностные обязанности включают в себя организацию обработки обращений на всех линиях поддержки? Пресечение футбола между группами L2-L3? Организацию базы знаний (за пределами L1)? Обеспечение оперативного реагирования на инциденты в группах L2-L3? Формирование сквозной отчётности по процессу? Формирование и расчёт KPI для стимулирования старших групп линий L2-L3? Анализ причин нарушения сроков обработки (всеми линиями), формирование и реализацию предложений по совершенствованию процесса (в о хвате всех групп поддержки)? Разработку и актуализацию нормативной документации по управлению инцидентами, охватывающую все линии поддержки?
                    Если “да” – это не должностные обязанности начальника группы поддержки пользователей, даже если это так почему-то называется 🙂
                    И Вы правы в том, что это в лучшем случае – управление инцидентами. Шагаем дальше – PRB, CFG, CHG, SLM и последние тени иллюзии совпадения функциональных и процессных обязанностей исчезают.

                    • Pavel Solopov

                      Дмитрий, то что вы написали есть и не во всяком процессе управления инцидентами. Вы рисуете идеальную картину мира.
                      А если посмотреть на более простые реализации процесса, то большая доля задач ложится на его подразделение, просто потому, что большая доля вопросов у пользователей не замысловата и решается его отделом. Ну и конечно ему немного приходится заниматься пинанием второй линии и может третьей, составлять какую-то отчётность и т.д.
                      Статистики не имею, но умозрительно 80% задач “не идеального” управления инцидентами он решает.

                      С PRB сложнее, возможно его и реализуют реже, поскольку не понимают, что это за деятельнсоть. Тут скорее сетевики или ребята работающие с серверной инфраструктурой основной объём работы выполняют, может ещё поддержка основной информационной системы.
                      Конфиг – поскольку у нас чаще в виде конфига некий складской учёт делают, тот тут основной претендент тот, под чьей ответственностью больше оборудования. Им может оказаться наш любимый начальник отдела поддержки пользователей, а может и вообще ИТ-завхоз.
                      Ну и так далее.
                      Просто я не говорю о идеальном, полном реализации процессов. Я говорю о ситуации, когда с уровня зрелости 1 или 1+, продвигаются на уровень 2-3.
                      дальше ситуация может конечно и измениться. Ну и много значит размер компании.

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

                      Павел, ну если мы приходим к состоянию, в котором 80% процесса сосредоточено в одной функции Ваше предположение может быть верным 🙂 Но это вырожденный случай, он не покрывает большинство реализаций в компаниях от 50-ти ИТ-специалистов.
                      Согласен с Вами в том, что важный фактор – размер компании. Я как-то упустил это из виду, изначально подразумевая “весовую категорию 50+”. Но и это уточнение не вносит особой ясности – ответа на вопрос в комментариях к этому посту я пока не вижу.

                    • Pavel Solopov

                      ответа на вопрос в комментариях к этому посту я пока не вижу
                      Это не значит, что их здесь нет. 🙂

                  • Вадим

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

                    “конфликт интересов” называется. поэтому-то и надо разносить процессное управление и линейное. особенно в управлении конфигурациями.

                    наверное можно составить потенциальные приоритеты процессов, управление которых нужно “оторвать” от иерархической структуры. хотя организация взаимодействия иерархической структуры и процессного управления – тот еще вопрос.

                • Вадим

                  про выделение исполнителя роли менеджера процесса. Это такая же (ОК, аналогичная) матрица, как и в управлении проектами

                  на эту тему некоторое время назад было много обсуждений в рамках ITSM-форума, даже секция специальная была “процессное и линейное управления” (кажется так). Вел Баринов. Местами было интересно. Параллели между процессным и проектным тоже проводились, разница между процессным и линейным – тоже. В деталях уже не очень помню, но какие-то материалы на эту тему должны где-то быть (найти не обещаю).

  • Юрий Ерин

    Поздновато, но тем не менее, хотел бы сказать свое мненние по сути поставленных вопросов.

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

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

      Юрий Юрич, это всё, конечно, так. Видимо также надо ввести уточнение по поводу слова “выделенный”. Я имел ввиду не выделенный на 1 проект, а выделенный в оргструктуре, т.е. так, что менеджер проекта – это должность, а не “почётная обязанность”. Аналогично и выделенный менеджер процессов может совмещать управление несколькими процессами, как в примере с Анатолием (с чего и начались комментарии к топику).
      Так вот с этим уточнением при всех соображениях о факторах, которые ты привёл (масштаб, уровень коммуникаций, …) выделенные менеджеры проектов встречаются гораздо чаще, чем выделенные менеджеры процессов. По крайней мере такова моя статистика.

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

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

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