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

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

Опубликовано 18 июля 2017
Рубрики: Service Desk, Вопрос из зала, Обо всём на свете, Управление проблемами
Комментарии

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

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

Прочитал много материалов, касающихся 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 не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.