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

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

Опубликовано 26 ноября 2015
Рубрики: ITIL, Вопрос из зала, Управление проблемами
Комментарии

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

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? И какие вы видите сложности в этом?

Спасибо

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

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

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

Комментариев: 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
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.