Дмитрий спрашивает:
Интересно было бы обсудить рациональность выполнения одним человеком разных ITSM ролей, особенно при наличии открытого или скрытого конфликта интересов. Скажем, совмещение одним человеком роли сервис менеджера и менеджера по безопасности — насколько возможно и насколько жизнеспособно?
По нашему мнению, это нерационально, ведь такому совместителю придется платить несколько зарплат. Так ведь?
OK, давайте разберем конкретный пример: сервис-менеджер и он же менеджер по безопасности.
Конфликт интересов ЕСТЬ.
В какой ситуации такое совмещение возможно, и не будет катастрофическим для результата? Как выстроить эффективную работу?
Дмитрий. На мой взгляд конфликт интересов отсутствует. Менеджер по безопасности помогает сервис-менеджеру определить требования к ИТ сервисам/системам, которые помимо прочих должны быть учтены при их проектировании, создании, эксплуатации, осуществляет контроль их выполнения и другие функции, направленные на обеспечение так называемой гарантии сервиса (опять же поддержка сервис-менеджера). Совместить точно не удастся, если обеспечение информационной безопасности выделено из ИТ, что нередко встречается.
На мой взгляд возможность зависит от объема задач, которые должен выполнять/отвечать за выполнение назначенный на эти роли специалист, количеством предоставляемых сервисов, сложностью инфраструктуры, масштабами организации.
Предлагаю сперва определиться с терминами – менеджер по ИБ не может быть менеджером по ИБ если он внутри ИТ, ведь тогда scope его обязанностей не включает в себя защиту информации в “неИТ” форме.
Далее, давайте посмотрим на клиентов ролей, чьи интересы необходимо защитить:
СМ – функциональные заказчики, определяющие требования к сервисам
ИТбез – совет директоров, определяющий политику ИБ
Посмотрим на их предназначение:
СМ – реализация требований заказчиков к сервисам
ИТбез – реализация политики ИБ
Таким образом возможны следующие ситуации:
1) ИБ в организации не определена совдиром\топами – конфликтов не будет;
2) ИБ в организации определена – конфликты с заказчиками по причине необходимости реализации требований ИБ за счет заказчиков без повышения utility
Но при первом случае вряд ли наймут менеджера по ИБ;)
Политику ИБ определяет (в конкретном случае) штаб-квартира, спускающая в подразделения конкретные жесткие требования по ИТ безопасности (в широком смысле слова, включая безопасность и процессов, континьюити/availability и т.д.) в виде политик и поцедур, обязательных к исполнению. Но они (политики) скорее говорят “что” делать, но не “как”.
Очень интересно совмещаются три ИТ-роли: Сервис-менеджер; Руководитель проекта; и Менеджер по изменениям.
Процессы разные. Но по факту – все крутиться во круг того, что нам нужно управлять жизненным циклом Информационного решения (как частный случай создать новое ) и нам нужен некий ответственный за эту “штуку”, причем, не функциональщик, не архитектор, а такой, вот знаете ли, – МЕНЕДЖЕР.
Т.е. предлагается подойти к рассматриваемому вопросу не с позиции чистой методологии, а с позиции эквивалента полной занятости – т.е. нагрузить человека деятельностью , схожей не по букве, но по духу.
Не стоит совмещать роли Менеджера Инцидентов и Менеджера Проблем.
Вы шутите? Всю жизнь успешно совмещали.
Соболезную)
А где-же аргументы?
почему именно соболезнуете?
“… совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: «не успеваю, и так работаю по ночам». Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.”
Подробнее см. здесь: http://www.realitsm.ru/2012/03/sovmeshhenie-rolej/#comment-8444
Впрочем, соболезнования здесь неуместны. В конкретной организации ни один из перечисленных рисков мог и не случиться – очень зависит от человека. Вот если он сменится, тогда вероятность того, что соболезнования пригодятся, резко возрастает. В частности, для того чтобы эту зависимость снизить, роли inc- и prb-менеджеров рекомендуется разделять.
По ссылке дискуссия с мультиками, надо и сюда добавить.
Есть прелестный мульт “Первые встречи” (например тут можно просмотреть http://mult-online.ru/detstvo/2332-pervye-vstrechi.html)
Вот мне лично всегда, когда заходит речь о менеджерах инцидентов и проблем приходят на ум эти два цыпленка с их вечной темой “-Тут надо подумать… -А чего тут думать” 😀
Разные цели у менеджеров. Менеджер INC заинтересован в регистрации максимально возможного количества инцидентов, а деятельность Менеджера PRB наоборот, направлена на сокращение инцидентов. Первый готов решать инцидент любым способом, который быстрее всего ликвидирует признаки инцидента, неважно что “завтра” опять сломается. Второму не так важно время простоя, важнее найти причину и устранить раз и навсегда.
теперь Вы расскажите коллегам пожалуйста о Вашем успешном опыте совмещения
Поделитесь с коллегами о своем опыте?
А зачем ?
я уже посмеялся, пока Вы сначала общеизвестные вещи излагали,
а потом общеизвестными аргументами обосновывали.
Я честно говоря рассчитывал на то, что на этом форуме будут отсутствовать тролли. Видимо зря.
Если есть возможность оставлять комментарии без регистрации – тролли рано или поздно появляются. Лучшее лекарство – игнорирование.
На мой взгляд лучше совместить Менеджера Проблем с Менеджером Изменений.
При прочих равных условиях (не имея информации о персональной специфике) я бы лучше делал так: INC, CFG+CHG, PRB+SLM.
Гм, а можно ли как то аргументировать PRB+SLM? Как я понимаю, SLM чаще всего это директор ИТ отдела..
“а можно ли как то аргументировать PRB+SLM? “
Андрей, выпишите в столбик, что требуется от каждого из этих менеджеров и сами все поймете. И уж точно лучше, чем кто-то объяснит.
“SLM чаще всего это директор ИТ отдела…”
Во-первых, не обязательно. Во-вторых, почему это говорит о странности совмещения ролей менеджеров процессов PRB и SLM?
«SLM чаще всего это директор ИТ отдела….»
«Во-первых, не обязательно. Во-вторых, почему это говорит о странности совмещения ролей менеджеров процессов PRB и SLM?.»
Дмитрий, меня несколько смутило, что первый процесс находится на операционном, а другой на тактическом или даже стратегическом уровне. Если SLM – достаточно высокопоставленный и как правило занятой менеджер, ему некогда будет заниматься проблемами. Не поделитесь (исходя из своего богатого опыта внедрений) какие еще сотрудники ИТ подразделения могут занимать роль SLM и это может считаться хорошей практикой?
Только сегодня обсуждали сложности с совмещением менеджера процессов SLM и CFG.
Насчет совмещения ролей: так получилось, что до последнего времени совмещала(и сейчас формально совмещаю) роли руководителя Help Desk, инцидент-менеджера и проблем-менеджера. При этом была ответственной за общее внедрение ITSM-процессов. Получалось 🙂 Никакого конфликта интересов. Кто сказал, что менеджер инцидентов заинтересован в регистрации максимального количества инцидентов? Неправда ваша, господа. У нас в компании как раз упор был на процент инцидентов, разрешенных вовремя или с опережением. И вот тут процесс управления проблемами помогал, поскольку снижал общее количество инцидентов, люди успевали их качественно решать, да и мне проще было контроллировать процесс.
Niza, а все ли выявленные сбои, деградации, недоступности, нештатные ситуации и т.п., что подпадает под определение инцидента были зарегистрированы как Инциденты? Задача менеджера инцидентов в первую очередь обеспечить 100% охват всех таких случаев, а уже далее могут появляться необходимые метрики, например как Вы приводите “процент инцидентов, разрешенных вовремя или с опережением”.
Андрей, не совсем понятно, почему вас интересует процесс регистрации инцидентов у нас, но отвечу. Регистрация входящих заявок является одной из основных функций Help Desk, так что да, регистрировалось все. Учитывая специфику компании, инциденты разделялись на те, что касаются абонентов и абонентское обслуживание и те, что касаются пользователей. Соответственно, и уровни сервисов были разные для этих двух категорий.
Мое же возражение касалось утверждения о том, что совмещение ролей менеджера инцидентов и менеджера проблем нежелательно из-за конфликта интересов, и как аргумент приводили именно метрику количества зарегистрированных инцидентов. С чем я и не согласна. Потому как мне неясно, зачем вообще внедрять сервисный подход, если менеджер инцидентов будет за увеличение количества инцидентов. Задачи у него другие должны быть.
Niza,
“Регистрация входящих заявок является одной из основных функций Help Desk, так что да, регистрировалось все.”
А учет инфраструктурных инцидентов (сбоев в ИТ инфраструктуре, которые обнаруживает система мониторинга или сам ИТ персонал) не входил в Вашу специфику?
“зачем вообще внедрять сервисный подход, если менеджер инцидентов будет за увеличение количества инцидентов.”
подразумевалось в виду, что это необходимое условие, но никак не достаточное в качестве ключевого фактора эффективности процесса Управление Инцидентами.
Дмитрий Исайченко выше уже озвучивал:
“совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: «не успеваю, и так работаю по ночам». Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.”
Андрей,
По пунктам:
1. “А учет инфраструктурных инцидентов (сбоев в ИТ инфраструктуре, которые обнаруживает система мониторинга или сам ИТ персонал) не входил в Вашу специфику? ”
Инфраструктурные инциденты регистрировались безусловно. Система мониторинга в крупной телекоммункационной компании для этого и существует.
2.”«зачем вообще внедрять сервисный подход, если менеджер инцидентов будет за увеличение количества инцидентов.»
подразумевалось в виду, что это необходимое условие, но никак не достаточное в качестве ключевого фактора эффективности процесса Управление Инцидентами. ”
Еще раз повторю вопрос, объясните аргументировано, почему одной из метрик INC должно быть большое количество инцидентов?
3.”Дмитрий Исайченко выше уже озвучивал:
«совмещение менеджеров INC и PRB опасно перекосом в сторону одного из процессов, в большинстве случаев конечно в сторону INC (потому что это очень оперативный процесс, и он требует вовлечения менеджера в оперативное управление в большей степени, чем PRB). Ответ INC-PRB-менеджера про PRB в этом случае будет один и тот же: «не успеваю, и так работаю по ночам». Тем хуже, если такой менеджер будет ещё и начальником SD. Тем хуже, если оба процесса находятся на этапе становления.»”
Аргументируйте, почему будет перекос? Почему в большинстве случаев перекос будет в сторону INC? Почему совмещение INC+PRB+SD представляется таким нежелательным? Сама могу судить о подобном совмещении ролей только с положительной стороны. Мне, как PRB помогала оперативная информация по INC, потому как находилась в курсе текущей ситцуации по всем инцидентам. С другой стороны, как INC, мне PRB помогал в предоставлении решений(как временных, так и постоянных), чтобы ответственные спецы разгружались от авральных ситуаций (когда абонентская база приближается к цифре в 10 миллионов, такие ситуации случаются время от времени). Единственная особенность, PRB был на откупе у 3-й линии-внешнего поставщика. Ну и то, что являюсь руководителем SD, помогало координировать работу на управленческом уровне.
Роль – это НЕ должность. Один человек за одну зарплату может совмещать хоть 20 разных процессных ролей.
В действительности редко встречается один человек на одну роль.
Пример нерацинального совмещения ролей (не ITIL) – менеджер разработчиков + менеджер тестеровщиокв = ПО никогда не будет разработано.
Рациональность определяется функциями ролей (чтобы не было конфликта интересов) и временем, которым располагает сотрудник, совмещающий роли. И, конечно, компетенцией и знаниями сотрудника.
Странный вопрос, ИМХО.