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

Вопрос из зала: где должен быть Problem management?

Читатель нашего портала Дмитрий интересуется управлением проблемами:

PuzzleДобрый день,

 Внутри команды Service Managers  возникло бурное обсуждение, откуда должен предоставляться Problem Management, так как в ITIL нет четкого описания ( или мы его не нашли), кто за это отвечает ( понятно, тут не обойтисть без Problem Manager)  и откуда  (ServiceDesk?) , есть лишь описание , что проблемы поднимаються со 2-й линни в Problem Management процесс. Cреди вариантов есть такие мнение:

1) Не должен предоставляться Service Desk, так как возникает конфликт интересов, и всегда должен предоставляться на уровнях  2 или 3 линий поддержки, которая обязательно находится не в ServiceDesk

2) Предоствляется из Service Desk, так как процесс позволят планомерно уменьшать количество инцидентов и т д и т п

Вопросы:

 1) Что говорит ITIL по этому поводу? и говорит ли вообще?

2)  А  где у Вас на проектах находится Problem management? И какие вы видите сложности в этом?

Спасибо

Поможем найти место данному процессу?

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

  • Konstantin

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

    • Дмитрий

      спасибо за быстрый ответ. Посмотрел MOF и вот что нашел:

      "Problem Management: The service desk, with its responsibility for coordinating the incident management process, is ideally placed to identify recurrent or multiple incidents that point toward an underlying problem. As such, the service desk is an important source of information for problem management. In return, problem management works to identify and document workarounds and solutions that the service desk can use while performing initial support on new incidents. When resolutions or workarounds are identified by problem management, the information is then passed to users by means of the service desk. Problem management also aims to identify information that the service desk can use to proactively advise users. In the long run, effective problem management should reduce the number of incidents being reported to the service desk." 

      и кажется опять никакой конкретики...или я не там ищу?

  • Konstantin

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

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

    • Дмитрий

      Константин, спасибо за развернутый ответ и возможность получить ваш опыт и мнение по данному вопросу.

      .....................

      А что скажут гуру Сleverics?

  • Андрей

    Хоть и не гуру, но скажу:)

    Problem mangement — процесс из группы процессов Service Operations. Если коротко, то суть его в первичном анализе инцидентов на предмет выявления проблем, регистрации выявленной проблемы и поиск решения. По аналогии с медициной — инциденты есть симптомы болезни(проблемы). Анализ симптомов позволяет поставить диагноз (описание проблемы) и назначить лечение. Для реализации процесса problem management вполне логично использовать человекомашиный комплекс ServiceDesk, поскольку анализ и первичная обработка инцидентов подразумевает уверенное владение инструментарием, используемым для реализации функций ServiceDesk. По идее, это должен быть кто-то из группы ServiceDesk в обязанности которого входит либо регулярный (раз в день/неделю/месяц ...) анализ инцидентов, либо анализ на основе неких событий, на пример резкий рост числа инцидентов, либо оба варианта. А вот поиском решения проблемы разумнее заняться профильным специалистам и они как правило вне ServiceDesk. При этом за Problem Manager-ом остается общий контроль за исполнением процесса.

  • Евгений

    Дмитрий,

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

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

    Лично мое мнение, PM менеджер должен быть "отстранённым" то SD и HD так как Вы ранее и уточнили -конфликт интересов, так же PM должен быть мотивирован на поиск новых проблем -в этом Вам помогут показатили KPI PM

  • Nargiza Suleymanova

    Как-то я пропустила тему про любимый процесс 🙂

    Из практики: problem management обычно не живет конкретно в какой-либо функции (как, например, incident management большей частью живет в service desk), а размазан по 2-й и выше линиям поддержки. Аналитиками проблем чаще всего становятся либо лидеры команд, либо эксперты 3-й линии, и в этом у них "шкурный" интерес: им либо хочется немного снизить нагрузку из-за часто повторяющихся инцидентов, отнимающих много их драгоценного времени, либо они видят тенденцию, что не все ладно в их зоне ответственности (в случае редких, но регулярно появляющихся инцидентов). Ну и обязательный триггер для регистрации проблем — это major инциденты или аварии. 

    С ролью problem manager чуть сложнее, тут все зависит от конкретной компании. Я вообще в свое время совмещала роли incident и problem manager, будучи руководителем service desk ("о, ужас!"- скажут авторы ITIL), но это работало успешно только потому, что решение проблем было на стороне исполнителя, внешнего поставщика.


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

Ваш адрес 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