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

Problem Management: эскалация инцидента на вторую линию

В редакцию портала поступил вопрос:

Коллеги, добрый день!

Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти".

Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти — заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам — так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие же инциденты. Сейчас это решается созданием инцидента на вторую линию. Но хотелось бы разграничить и статистику строить по инцидентам и проблемам отдельно.

Как это проще всего сделать? В окне работы с инцидентом добавляем новую кнопку "Создать проблему". Создается новый тикет, с типом "Проблема". В первом приближении, в ITSM системе проблема будет отличаться от инцидента только типом тикета. То есть мне, по сути, надо лишь добавить тип тикета "Проблема", которая скрыта пользователям, но открыта агентам. Проблемы точно также решаются специалистами второй линии. Единственное явное отличие — их не надо как инциденты закрывать пользователям.

В чем сложности и ущербности такого PM?

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Макс

    Добрый день! Такой вариант возможен, хотя отсутствуют некоторые элементы автоматизации проблем, например:

    1. Оповещение всех авторов заявок\специалистов о решении проблемы (в случае если у вас массовый инцидент более чем на 100 заявок автоматизированная отправка решений сильно снижает затраты времени на закрытие тиектов в системе.) В нашей корпоративной ITSM системе это делается заполнением полей "Решение" или "Обходное решение", после чего решения добавляются к каждому привязанному инциденту.

    2. Закрытие заявок по которым было отправлено оповещение.

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

    Насколько я знаю общепринято вымещение PM в отдельный фрейм, для проблем. Это значительно упрощает их администрирование.

  • Даниил

    Добрый день.

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

  • Ольга

    Добрый день.

    Нет никаких сложностей с созданием сущности "проблема" в системе автоматизации – все современные ITSM-системы имеют нужную функциональность. Если вам важно время от времени проводить анализ повторяющихся инцидентов на предмет возможных проблем, для этого даже не обязательно отдельную сущность "проблема" регистрировать. Достаточно добавить признак "кандидат в проблему" (в HP SM, например, это вообще встроенный чек-бокс на форме инцидента), а потом строить по нему отчетность.

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

    У нас, например, Problem Mngt до сих пор не взлетел. Причин много. С одной стороны, есть сложности, связанные с пониманием сути процесса (например, большинство участников вообще не видит разницы между инцидентом и проблемой). С другой стороны, то, что у нас называют Problem Mngt, используют для снятия с себя ответственности. Например, если не могут в срок решить инцидент, переклассифицируют его в проблему, тем самым останавливая SLA по инциденту. В общем, процесс действительно непростой 🙂

     

     

    • Dimitriy

      Добрый день, Ольга

      Это известная "болячка"...

      Пока Вы не начнете внедрять процесс и контролировать его — всё так и будет.

      Обучение инженеров поможет поменять взгляд на Проблем Мереджмент.

      Будет процесс и контроль за процессом — будет и ответственный и SLA по проблемам.

      • Ольга

        Дмитрий, мне все-таки кажется, что в обратном порядке: сначала ответственный, а потом уже контроль процесса этим ответственным 😉

        А обучение, само собой, проводили и проводим.

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

  • Dimitriy

    Добрый день.

    Про “Управление Проблемами”…

    1. Да, проблемы нужно выводить в отдельную "ветвь" и управлением проблемами должны заниматься "другие люди", которые не относятся непосредственно к "Управленью Инсидентами".

    Об этом, кстати,  говорит и ITIL, и я с ним 100% согласен.

    Если у вас Инцидент Менеджмент и Проблем Менеджмент управляются одними и теми же людьми — со временем получите хаос и много конфликтов интересов.

    2. Почитайте ITIL OSA. Очень советую, найдёте много ответов на вопросы.

    О самой сущности «Проблем тикет»…

    Если Вы сделаете "Problem Ticket" из сущности, подобной "ченджу"/ "изменению" – то будет видно какие "таски" для решения проблемы существуют (план решения проблемы), какие из них сделаны, а какие ещё открыты.

    Если возможно – внедрите статусы проблем на основе ITIL, чтобы четко понимать на какой стадии проблемы находятся (нахождение первопричин, поиск решения и т.д.) — это позволит Вам упростить контроль над процессом, ставить точки контроля и т.д, вплоть до разработки метрик и некоторых KPI.

    Если это не возможно внедрить/сделать — используйте "проблем таски" так обходное решение.

    Dimitriy.

  • Андрей другой

    Для успешного внедрения процесса Problem Management он прежде всего у вас должен быть — т.е. у вас должны быть конкретные люди, для которых работа с проблемами будет основной/обязательной работой. Если вы планируете организовать процесс в виде факультативных занятий в свободное от других задач время, то ничего путного не получится. Это вовсе не значит, что специалист должен заниматься ТОЛЬКО проблеммами, возможно их у вас и не так много. Это значит, что у него должны быть как минимум обязательные часы по работе с проблемами и должен быть механизм оценки его работы с проблемами. А вот когда все это у вас будет, хотябы на бумаге, можно перейти к тому как будет у вас настроен инструмент для поддержки ВАШЕГО процесса, как и из чего вы будете регистрировать проблемы, кто и как их будет закрывать... Лично мое мнение — иметь все объекты одного класса — тикет и различать их по одному аттрибуту — тип есть не очень хорошая идея. Обращение, Инцидент, проблема и заявка слишком сильно отличаются друг от друга. Но это лично мое мнение.

    • Dimitriy

      Добрый день,

      Андрей, по всем пунктам могу ответить только "ДА"!!! 🙂

      Потому что действительно:

      ДА: Нужен "кто-то" кто "нарисует процесс" для вас... или адаптирует уже существующие шаблоны (в общем доступе есть примеры). без этого непонятно что собирается быть сделано.

      Добавлю: Готовте как процесс, так и инструкцию и матрицу ответственности по процессу *сразу же*, не давайте возможность "додумывать" как оно "должно бы" работать с точки зрения отдельных индивидов!

      ДА: Нужен отдельный человек ответственный за работу процесса (контроль процесса решения проблем)

      ДА: "Факультатив" не работает, как ни старайся, селяви.

      ДА: Инженеры должны планировать время на как на работу с текужими проблемами, так и на поиск новых проблем в окружении.

      ДА: Тикет не должен быть "похож" на инцидент или реквест — это не "по феншую". Думаю это взгляд большинства из тех, кто работает с проблемами...

      И лучше, если проблем тикет имеет:

      * другой класс в ITSM

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

      * отдельные таски для разных команд и/или инженеров

  • ДМБ

    Автоматизация процесса и его функционирование — есть две разные вещи.

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

    Как вы их будете регистрировать — как просто инцидент или вообще в экселе — это на этапе становления процесса абсолютно не важно.

    Поставьте цель — снижение количества инцидентов. Если вы ее достигните — неважно если вы нарушите каноны ИТИЛ. Они для того и сделаны чтобы выходить за их рамки.


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

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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как 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 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT