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

Вопрос из зала: Совмещение ролей в ITSM

Дмитрий спрашивает:


Интересно было бы обсудить рациональность выполнения одним человеком разных ITSM ролей, особенно при наличии открытого или скрытого конфликта интересов. Скажем, совмещение одним человеком роли сервис менеджера и менеджера по безопасности — насколько возможно и насколько жизнеспособно?


По нашему мнению, это нерационально, ведь такому совместителю придется платить несколько зарплат. Так ведь?

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • NAT

    Роль — это НЕ должность. Один человек за одну зарплату может совмещать хоть 20 разных процессных ролей.

    В действительности редко встречается один человек на одну роль.

    Пример нерацинального совмещения ролей (не ITIL) — менеджер разработчиков + менеджер тестеровщиокв = ПО никогда не будет разработано.

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

    Странный вопрос, ИМХО.

  • Dmitriy

    OK, давайте разберем конкретный пример: сервис-менеджер и он же менеджер по безопасности.

    Конфликт интересов ЕСТЬ.

    В какой ситуации такое совмещение возможно, и не будет катастрофическим для результата? Как выстроить эффективную работу?

    • Юрий

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

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

      • Oleksandr Bodryk

        Предлагаю сперва определиться с терминами — менеджер по ИБ не может быть менеджером по ИБ если он внутри ИТ, ведь тогда scope его обязанностей не включает в себя защиту информации в «неИТ» форме.

        Далее, давайте посмотрим на клиентов ролей, чьи интересы необходимо защитить:

        СМ — функциональные заказчики, определяющие требования к сервисам

        ИТбез — совет директоров, определяющий политику ИБ

        Посмотрим на их предназначение:

        СМ — реализация требований заказчиков к сервисам

        ИТбез — реализация политики ИБ

        Таким образом возможны следующие ситуации:

        1) ИБ в организации не определена совдиром\топами — конфликтов не будет;

        2) ИБ в организации определена — конфликты с заказчиками по причине необходимости реализации требований ИБ за счет заказчиков без повышения utility

        Но при первом случае вряд ли наймут менеджера по ИБ;)

        • Dmitriy

          Политику ИБ определяет (в конкретном случае) штаб-квартира, спускающая в подразделения конкретные жесткие требования по ИТ безопасности (в широком смысле слова, включая безопасность и процессов, континьюити/availability и т.д.) в виде политик и поцедур, обязательных к исполнению. Но они (политики) скорее говорят «что» делать, но не «как».

  • Очень интересно совмещаются три ИТ-роли: Сервис-менеджер; Руководитель проекта; и Менеджер по изменениям.

    Процессы разные. Но по факту — все крутиться во круг того, что нам нужно управлять жизненным циклом Информационного решения (как частный случай создать новое ) и нам нужен некий ответственный за эту «штуку», причем, не функциональщик, не архитектор, а такой, вот знаете ли, — МЕНЕДЖЕР.

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

  • Андрей В.

    Не стоит совмещать роли Менеджера Инцидентов и Менеджера Проблем.

    • Штора

      Вы шутите? Всю жизнь успешно совмещали.

      • Андрей В.

        Соболезную)

        • Штора

          А где-же аргументы?

          почему именно соболезнуете?

          • «... совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: «не успеваю, и так работаю по ночам». Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.»

            Подробнее см. здесь: www.realitsm.ru/2012/03/s...ej/#comment-8444

            Впрочем, соболезнования здесь неуместны. В конкретной организации ни один из перечисленных рисков мог и не случиться — очень зависит от человека. Вот если он сменится, тогда вероятность того, что соболезнования пригодятся, резко возрастает. В частности, для того чтобы эту зависимость снизить, роли inc- и prb-менеджеров рекомендуется разделять.

            • Георгий

              По ссылке дискуссия с мультиками, надо и сюда добавить.

              Есть прелестный мульт «Первые встречи» (например тут можно просмотреть mult-online.ru/detstvo/23...ye-vstrechi.html)

              Вот мне лично всегда, когда заходит речь о менеджерах инцидентов и проблем приходят на ум эти два цыпленка с их вечной темой «-Тут надо подумать... -А чего тут думать» 😀

          • Андрей В.

            Разные цели у менеджеров. Менеджер INC заинтересован в регистрации максимально возможного количества инцидентов, а деятельность Менеджера PRB наоборот, направлена на сокращение инцидентов. Первый готов решать инцидент любым способом, который быстрее всего ликвидирует признаки инцидента, неважно что «завтра» опять сломается. Второму не так важно время простоя, важнее найти причину и устранить раз и навсегда.

      • Андрей В.

        теперь Вы расскажите коллегам пожалуйста о Вашем успешном опыте совмещения

      • Андрей В.

        Поделитесь с коллегами о своем опыте?

        • Шпора

          А зачем ?

          я уже посмеялся, пока Вы сначала общеизвестные вещи излагали,

          а потом общеизвестными аргументами обосновывали.

          • Андрей В.

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

            • Если есть возможность оставлять комментарии без регистрации — тролли рано или поздно появляются. Лучшее лекарство — игнорирование.

  • Андрей В.

    На мой взгляд лучше совместить Менеджера Проблем с Менеджером Изменений.

    • При прочих равных условиях (не имея информации о персональной специфике) я бы лучше делал так: INC, CFG+CHG, PRB+SLM.

      • Андрей В.

        Гм, а можно ли как то аргументировать PRB+SLM? Как я понимаю, SLM чаще всего это директор ИТ отдела...

        • "а можно ли как то аргументировать PRB+SLM? "

          Андрей, выпишите в столбик, что требуется от каждого из этих менеджеров и сами все поймете. И уж точно лучше, чем кто-то объяснит.

          «SLM чаще всего это директор ИТ отдела...»

          Во-первых, не обязательно. Во-вторых, почему это говорит о странности совмещения ролей менеджеров процессов PRB и SLM?

          • Андрей В.

            «SLM чаще всего это директор ИТ отдела...»

            «Во-первых, не обязательно. Во-вторых, почему это говорит о странности совмещения ролей менеджеров процессов PRB и SLM?.»

            Дмитрий, меня несколько смутило, что первый процесс находится на операционном, а другой на тактическом или даже стратегическом уровне. Если SLM — достаточно высокопоставленный и как правило занятой менеджер, ему некогда будет заниматься проблемами. Не поделитесь (исходя из своего богатого опыта внедрений) какие еще сотрудники ИТ подразделения могут занимать роль SLM и это может считаться хорошей практикой?

  • Только сегодня обсуждали сложности с совмещением менеджера процессов SLM и CFG.

  • Niza

    Насчет совмещения ролей: так получилось, что до последнего времени совмещала(и сейчас формально совмещаю) роли руководителя Help Desk, инцидент-менеджера и проблем-менеджера. При этом была ответственной за общее внедрение ITSM-процессов. Получалось 🙂 Никакого конфликта интересов. Кто сказал, что менеджер инцидентов заинтересован в регистрации максимального количества инцидентов? Неправда ваша, господа. У нас в компании как раз упор был на процент инцидентов, разрешенных вовремя или с опережением. И вот тут процесс управления проблемами помогал, поскольку снижал общее количество инцидентов, люди успевали их качественно решать, да и мне проще было контроллировать процесс.

    • Андрей В.

      Niza, а все ли выявленные сбои, деградации, недоступности, нештатные ситуации и т.п., что подпадает под определение инцидента были зарегистрированы как Инциденты? Задача менеджера инцидентов в первую очередь обеспечить 100% охват всех таких случаев, а уже далее могут появляться необходимые метрики, например как Вы приводите «процент инцидентов, разрешенных вовремя или с опережением».

      • Niza

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

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

        • Андрей В.

          Niza,

          «Регистрация входящих заявок является одной из основных функций Help Desk, так что да, регистрировалось все.»

          А учет инфраструктурных инцидентов (сбоев в ИТ инфраструктуре, которые обнаруживает система мониторинга или сам ИТ персонал) не входил в Вашу специфику?

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

          подразумевалось в виду, что это необходимое условие, но никак не достаточное в качестве ключевого фактора эффективности процесса Управление Инцидентами.

          Дмитрий Исайченко выше уже озвучивал:

          «совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: «не успеваю, и так работаю по ночам». Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.»

          • Niza

            Андрей,

            По пунктам:

            1. «А учет инфраструктурных инцидентов (сбоев в ИТ инфраструктуре, которые обнаруживает система мониторинга или сам ИТ персонал) не входил в Вашу специфику? „

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

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

            подразумевалось в виду, что это необходимое условие, но никак не достаточное в качестве ключевого фактора эффективности процесса Управление Инцидентами. „

            Еще раз повторю вопрос, объясните аргументировано, почему одной из метрик INC должно быть большое количество инцидентов?

            3.“Дмитрий Исайченко выше уже озвучивал:

            «совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: «не успеваю, и так работаю по ночам». Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.»»

            Аргументируйте, почему будет перекос? Почему в большинстве случаев перекос будет в сторону INC? Почему совмещение INC+PRB+SD представляется таким нежелательным? Сама могу судить о подобном совмещении ролей только с положительной стороны. Мне, как PRB помогала оперативная информация по INC, потому как находилась в курсе текущей ситцуации по всем инцидентам. С другой стороны, как INC, мне PRB помогал в предоставлении решений(как временных, так и постоянных), чтобы ответственные спецы разгружались от авральных ситуаций (когда абонентская база приближается к цифре в 10 миллионов, такие ситуации случаются время от времени). Единственная особенность, PRB был на откупе у 3-й линии-внешнего поставщика. Ну и то, что являюсь руководителем SD, помогало координировать работу на управленческом уровне.


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT