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

Управление инцидентами и запросами пользователей

Уже давно бродит эта тема. А последней каплей стало то, что за последние 2-3 недели я обсуждал её 3 (!) раза с разными людьми. И так, вопрос: «Насколько осмысленно (или в каких случаях) выделять обработку сервисных запросов и управление инцидентами в отдельные процессы»?

За:

  • Соответствие ITIL v3. Строго говоря, тут надо учесть, что понятие «процесс» в ITIL v3 используется довольно неоднозначно. Но средства автоматизации ITSM-процессов «меряются» количеством процессов, а значит для вендоров – это плюс.
  • И раз уж заговорили про вендоров ITSM-продуктов, надо упомянуть, что такое деление (на инциденты и сервисные запросы) стимулируется рядом программных продуктов, в которых сервисные запросы и инциденты – это не просто разные категории одного объекта, а просто-таки разные объекты (с весьма различными возможностями по обработке).

Видимо, отсюда песня и пошла в народ. Но рассмотрим также и …

Против:

  • Рациональность организации управления. О чём, кстати, говорится в ITIL v2: «A request for new or additional service (i.e. software or hardware) is often not regarded as an Incident but as a Request for change (RFC). However, practice shows that handling of both failures in the infrastructure and of service requests are similar, and both are therefore included in the definition and scope of the process of Incident Management.». И в самом деле, зачем выделять отдельный процесс, который будет заниматься практически тем же, чем уже занимается управление инцидентами?
  • Устранение вероятных конфликтов. На практике (в проектах) граница между инцидентом и сервисным запросом вызывает массу вопросов. Обычно они выливаются в дискуссии типа «А замена картриджа принтера? А сброс забытого пароля?» и так далее. Логично предположить, что путаются не только «идеологи», но и специалисты при исполнении процесса. А значит должна быть возможность переклассификации. Но если сервисный запрос и инцидент теперь принадлежат к разным процессам управления (и не дай Бог, эти процессы управляются разными менеджерами), вопрос «что это – инцидент или сервисный запрос» превращается в вопрос «кто за это отвечает». И это не на пользу.
  • Рациональность автоматизации. В моей практике разница в обработке инцидента, поданного пользователем, и запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя (тут и разная классификация, и разные процедуры выявления / регистрации, и разные процедуры закрытия). То есть деление, выполненное в HP OpenView Service Desk, мне кажется гораздо более разумным, чем деление, например, в HP SM или в BMC Remedy ITSM Suite. Это конечно тема смежная, поскольку декомпозиция объектов в модели данных ITSM-продукта может не иметь никакого отношения к декомпозиции процессов управления. … но всё же 🙂

Выводы делаем сами. Ну и спорим, естественно.

P.S. Хотя меня конечно так и подмывает закончить известным «Никто не сказал ни слова, выводы были ясны». (с) БГ.

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

  • Прошлой осенью на эту тему отлично высказался Неугомонный Наш Ян ван Бон в своей колонке c оригинальным названием What the %$#$& is a Service Request?(http://www.itsmportal.com/columns/what-service-request). Я тогда тоже постарался сформулировать свое отношение к вопросу, тем более что три раза за три недели – это как раз средняя частота, с которой ITSM-тренеру приходится обсуждать эту тему.

    Я уверен, что главный вопрос – не в количестве потоков работ (“процессов”). Основная проблема объединения запросов и инцидентов в v2 была в том, что это делало процесс внутренне противоречивым: деятельность не соответствовала цели (обработка запросов не ведет к скорейшему восстановлению нормальной работы, ибо эта работа не нарушена). “Коня налево повернул, а сам направо поскакал”.
    Отсюда главный вывод: либо это один процесс, цель которого включает в себя и устранение инцидентов, и своевременную качественную обработку запросов на обслуживание, либо процессов несколько, но у каждого цель, виды деятельности, метрики и проч. – целостны и друг другу не противоречат.

    Приведенные Димой “плюсы” кажутся мне неубедительными. Тем не менее, я считаю, что разделение процессов может быть оправдано и полезно. У кого-нибудь есть более практические аргументы “за”?

  • Если у Заказчика цели инцидентов и запросов кардинально не расходятся (например, и там, и там: “своевременное качественное разрешение”), то вообще не вижу смысла обсуждать – это один процесс.

    • Один процесс какой? Если один процесс обработки обращений пользователей, то да, я тоже соглашусь. Но тогда процесс устранения сбоев в инфраструктуре, весьма вероятно, будет другим.

      Или туда же его?

  • Ром, если цели глобально не расходятся – это будет процесс управления инцидентами и запросами. Если же расходятся суперкардинально – то тогда это разные процессы. Кардинально расходящихся процессов я за все время не видел ни разу (правда, большинство цели плохо ставить умеет, ну не суть).
    Твой аргумент о внутренней противоречивости цели и деятельности не очень убедителен пока: слишком абстрактен. Приводи примеры )

    • Предположим, что в процессе занято некоторое количество людей. Нагрузка на них распределяется так: 30% времени они заняты тушением инцидентов, 70% – обработкой запросов.

      Теперь предположим, что мы при проектировании процесса формировали метрики “от целей”. То есть от одной цели – скорейшего восстановления нормальной работы. Деятельность по обработке запросов на цель не влияет, оттого не измеряется.

      70% деятельности участников процесса не учтены при сборе метрик и формировании отчетности. Те, кто хорошо работали, не повлияли на конечный результат и оттого не получили премий. А при очередной оптимизации – сокращены как бесполезные.

      ***
      Конечно, в реальной жизни почти никто не проектирует метрики от целей, их копируют из книг. Все равно потом не пригодятся.
      А если в книге работы по поддержке (INC) и работы по эксплуатации (RFF) свалили в один котел, то и метрик там, наверное, накидают для обоих составляющих…

      ***
      Вот у меня, кажется, еще аргумент появился…
      Давайте чуть расширим границы. Обработка жалоб и благодарностей – в каком процессе выполняется?

      • Давай сначала про инциденты и запросы. Цель в большинстве случаев ставится как скорейшее (SLA) и качественное (отзыв инициатора) устранение инцидентов и выполнение запросов. Для инцидента оценка deadline есть? Есть. Оценка пользователя есть? Есть. Для запроса? Если есть и то, и то – запрос это все-таки суслик, хоть он и описан как медведь.

        Ты заранее допускаешь, что не-major инциденты важнее запроса. А для меня у большинства заказчиков это далеко не тривиально. На типовом учебном примере – зажевало бумагу в принтере\закончился картридж. И то, и другое – просто суслик.

        Для универсального процесса (который open source IncM (c) itsmf.kz) сомнений ровно ноль, хотя обсуждения еще идут – это процесс управления инцидентами и запросами.

  • На памяти вспоминается всего один пример, когда инциденты от пользователей и запросы пользователей сбросили в один котел и назвали это “Управление обращениями”. При этом существовал ещё один процесс управление инфраструктурными инцидентами. И по факту всё равно было ДВА процесса….

    В остальном всегда были разные процессы, разные цели и т.д и т.п.

    Объедение этих процессов, это возврат к временам, когда кроме служб HelpDesk и ТраблТикетов ничего не было ИМХО.

    • >Объедение этих процессов, это возврат к временам, когда кроме служб HelpDesk и ТраблТикетов ничего не было ИМХО.

      Владимир, аргументируйте, плз )

      • Например:

        Цель процесса управления запросами:
        обеспечение сотрудников информационными и материальными ресурсами, необходимыми для организации и поддержания бизнес-деятельности.

        Цель процесса управления инцидентами:
        скорейшее восстановление нормального функционирования компонентов ИТ-инфраструктуры, задействованных в предоставлении услуг пользователям.

        Системы трабл тикетов автоматизируют данные процессы в рамках одной и тойже среды, одних и техже правил обработки, одних и техже метрик…

        Вот и получается, что два процесса превращаются в один универсальный в котором смешано всё сразу…

        Для определенных заказчиков это возможно удобней, но неизбежно встаёт вопрос выделения управления инцидентов в отдельный процесс… когда появляются инфраструктурные инциденты:)

        • Эээ, ну на это я только что выше Роману ответил. Тут нет различий в целях: нужно быстро и качественно обработать инциденты\запросы. Кстати, инцидент от пользователя и инфраструктурный инцидент с этой точки зрения не особо различаются.

          • Саша, абсолютный +1.

            • тогда уж +3:
              нужно быстро и качественно обработать инциденты\запросы\RFC\жалобы\благодарности.

              Любые обращения надо обрабатывать быстро и качественно. Но разве это значит, что любые обращения надо обрабатывать в одном процессе управления?

              • Декомпозиция (дробление) процессов в принципе ведёт к сложности, а значит не должна выполняться, если только на это нет чёткого основания (речь не идёт о глубине детализации – только о выделении разных процессов).

                Далее, вот фрагмент нашего курса молодого бойца: у процесса есть 10 основных реквизитов:

                1. Цели и задачи
                2. Входы
                3. Выходы
                4. Триггеры
                5. Распределение ответственности (роли)
                6. Порядок исполнения
                7. Порядок взаимодействия (6+7 = процедуры)
                8. Порядок и механизмы контроля
                9. Порядок и механизмы оценки
                10. Порядок и механизмы совершенствования.

                Основанием для деления является разница в этих реквизитах. Т.е. можно ввести и отдельный процесс управления жалобами, и отдельный процесс управления благодарностями, если это обоснованно. Только в большинстве случаев это делается довольно бездумно, потому что так написано в книжке. И реальной необходимости в этом нет.

                Но конечно бывают и исключения. Рома, Саша, предложите примеры. Тогда фраза “всё зависит от заказчика” приобретёт больше смысла 🙂

              • При прочих равных условиях – чем проще, тем лучше. “Лучше” в том смысле, что больше шансов на соблюдение правил, а если эти правила разумны – то больше польза для организации. Несколько разных процессов обработки обращений пользователей – сложно. Много разных типов обращений – сложно.

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

                Разумный процесс должен “закрывать” 80-90% типовых ситуаций. В этом его основная польза. Дизайн процесса, который претендует на 100% – избыточно сложен. И всё равно жизнь окажется богаче – найдётся то, что не предусмотрели. Проверить себя просто – сколько процентов от общего числа обращений занимают жалобы? А благодарности? Моё мнение – в данных ситуациях лучше те же силы консультанта тратить на развитие навыков менеджера и ключевых исполнителей процесса, чем на детальное описание исключений в регламенте процесса.

                • Я не агитирую за разделение. И тем более – за разделение обработки обращений разных типов.

                  Я считаю, что обработка обращений от пользователей (любых) – функция, а не процесс. Мы все знаем название этой функции.
                  А управление инцидентами – процесс, одним из входов в который являются обращения пользователей. Это процесс поддержки, в конечном счете направленный на достижение четкой цели – сокращения потерь бизнеса, связанных с неправильной работой ИТ. Кроме управления инцидентами, достижению этой же цели способствуют – каждый по-своему – процессы управления доступностью, непрерывностью и (в меньшей степени) некоторые другие.
                  Реализация по запросам пользователей предусмотренных дизайном услуги штатных операций – другой процесс. Он является частью деятельности по эксплуатации (не поддержки) услуг и направлен на предоставление пользователям требуемой им функциональности и/или обеспечение нормальной работы инфраструктуры. С точки зрения бизнеса этот процесс способствует не минимизации потерь, а повышению полезности. Конечно, обработка запросов помогает предотвратить инциденты, но это справедливо в отношении любой деятельности по эксплуатации.

                  Итого: обработку любых обращений выполняет функция service desk. Очень здорово, если процедуры этой обработки максимально унифицированы.

                  Но сама по себе своевременная качественная обработка обращений не является целью какого-либо из обсуждаемых процессов. Цели процессов – другие, “кардинально разные”, и, скорее всего, их достижение потребует разных процедур, разных ресурсов, разных метрик и т.д.
                  В самом общем виде это процессы “поддержка” и “эксплуатация”. Хотя в конкретной реализации названия могут быть любыми.

                  • “Цели процессов — другие, «кардинально разные», и, скорее всего, их достижение потребует разных процедур, разных ресурсов, разных метрик и т.д.”

                    Ром, приведи примеры кардинально разных целей, процедур, ресурсов и метрик. Я на практике такого ни разу не встречал. Тем не менее, ты очень связно излагаешь и я почти верю. Чтобы убрать “почти” нужен пример 🙂

                    • Боюсь, просто примеров недостаточно. Неизбежно возникнут новые вопросы.
                      Я попробую изложить эту картину ITSM-мира в отдельном посте.

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

                      Я это все, к сожалению, не сам придумал. Первоисточник – здесь: http://www.itsmportal.com/system/files/Functions_and_Processes-sec.pdf
                      Но мне очень нравится, и я почти со всем согласен.

                    • “Поддержка и эксплуатация — разные процессы с разными целями.”

                      Видимо, не все так считают. Например, ГОСТ Р ИСО 12207-1999 «Процессы жизненного цикла программных средств» (ISO/IEC 12207-1995) полагает, что поддержка есть часть эксплуатации. Смотри разделы 5.4 и 5.4.4.

                    • Ну вы тут все уже подробно расписали – и про жалобы\благодарности (согласен с Димой), и про источник разницы в подходах: разделение или не разделение поддержки и эксплуатации.

                      Вот и славно )

          • Ну так для быстрой и качественной обработки эти процессы нужно делить если:

            1) У процессов разные маршруты движения и разные группы исполнения.

            2) У процессов разные “Классификация и процедуры выялвения \ регистрации”.

            3) Разные процедуры подверждения решения.

            4) Разные метрики, отчетность…

            Попытка совместить эти вещи в рамках одного унивирсального процесса как раз и приведет к увелечению сроков обработки.

            Более того, если ставить вопрос подобным образом то необходимо обрабатывать запросы \ инциденты не быстро и качественно. А в сроки согласованные с бизенсом и качеством приемлимым для бизнеса.

            В свою очередь требования к срокам и качеству могут кардинально различаться для инцидентов и запросов….

            Получается много если 🙁 Это опять приводит к выводу, что все зависит от заказчика…

            • Владимир, в принципе я их уже несколько штук сделал “совместными”, поэтому по опыту скажу – там разная только процедура “исполнения” получается, все остальное одинаково.

              Сроки согласованные и качество приемлемое – оно и имелось ввиду, в общем. Просто, для краткости – оно вроде бы ясно. О требованиях к сроку и качеству я в сообщение выше задал тот же вопрос. Так что ответ на все если есть, и это одно если – “если у процессов кардинально разные цели”. Я-то могу привести пример кардинально разных целей (много анализировал на заданную тему), но в ветке пока кардинально разных целей не увидел. И у 99% заказчиков кардинально разных целей нет – “устраняй инциденты\исполняй запросы, чтоб все крутилось и работало”. Быстро и качественно – это не кардинально разная цель, а значит никакой необходимости разделять процесс управления нет.

              И, могу заметить, товарищи это мы даже про шаблоны-модели (templates-models) не говорили – которые с оперативной точки зрения чуть чаще и важнее, чем упомянутые Романом жалобы\благодарности.

              • Александр, прочитав всю ветвь дискуссии, не могу отделаться от мысли, что все мы (люди так или иначе связанные с ITSM) делимся на две категории:

                Первая категория – консультанты и заказчики, начинавшие свой путь, когда золотого правила ITSM «Люди – Процессы – Технологии» не существовало. Альтернативы HPOV не было. Следовательно, вся работа велась от технологии. И такие технологические «фишки», как наряды на работы в инцидентах или упомянутое в данном посте деление инцидентов и запросов (точнее его отсутствие) становится догматом и продвигается везде как наиболее разумное решение вне зависимости от людей, которым с этими решениями потом жить.

                Вторая категория – консультанты и заказчики, начавшие свой ITSM путь с решний HP, CA, BMC. Для этих людей наряды на работу в инцидентах вещь совсем не тривиальная. Особенно учитывая, производителей этих решений которые утверждают, что инцидент это результат маловероятного стечения обстоятельств и спрогнозировать, а тем более спланировать действия по его устранению не представляется возможным. При этом если нам для устранения инцидента нужно, что-то заменить, то регистрируется экстренное изменение, в котором и задаются наряды на работу. Так же для этих людей объединение процессов «ересь», т.к. понимание ITSM формировалось по другим принципам и технологиям. В итоге продвигаются другие технологические фишки, опять же вне зависимости от людей.

                Не удивлюсь, что скоро появятся ITSM консультанты и заказчики, воспитанные на новых технологиях, например на сервисе service-now.com. Так они и тех и других будут считать космонавтами…

                Получается, мы наблюдаем спор технологий за ширмой оптимизации процессов, а про людей опять забыли… обидно 🙁

                • Владимир, ну не знаю насчет спора технологий. По крайней мере, применительно ко мне

                  Здравое зерно в вашем посте есть – процессные технологи (не важно, консультанты или заказчики) всегда зависимы от инструмента, чтобы они там сами не говорили о “только процессах”.

                  Вот только ко мне это относится в слабой степени. В период активной работы с HP SD мне по большому счету было все равно – один процесс или два. Объект INC (кто помнит) использовал как вспомогательный, для облегчения регистрации авто-инцидентов, а основная логика инцидентов-запросов строилась на SCall.

                  Мысли же о разделении процессов сформулированы тогда, когда инструмент перестал оказывать какое-либо влияние на процессную архитектуру (т.к. все равно процесс разрабатывался с нуля). Так что тут технологии или стартовые инструменты SD-решения не сыграли никакой роли 8)

                  ps про наряды в инцидентах тема не такая простая, и ее нужно бы обсуждать отдельно, Владимир )

                  • Александр, тема нарядов уже обсуждалась http://www.realitsm.ru/2010/11/vzaimodejstvie/ и в комментариях тоже встречаются ссылки на систему автоматизации.

                    Отдельного обсуждения требует тема влияния систем автоматизации на проектируемые процессы в целом. 🙂 Так как консультанты редко признаются в озвученной вами зависимости. Сорри если ушли в оффтоп.

                    • Да я читал (писать в это время некогда было), там не очень системно про наряды, если честно.

                    • “Так как консультанты редко признаются в озвученной вами зависимости.”

                      Ну с меня взятки гладки – я не себя под систему, я систему под себя построил 😀

  • Иван

    Руковожу службой поддержки одного вендора. Разделения у нас нет и, честно сказать, никогда не понимал смысла этого разделения.

    Александр правильно говорит: “Тут нет различий в целях: нужно быстро и качественно обработать инциденты\запросы”. Пример среди запросов на обслуживание у нас есть запрос на получение регистрационного ключа. Новый ключ мы обещаем выдать максимум за 4 рабочих часа. Если мы не уложимся в это время, то, поверьте мне, могут возникнуть ситуации похуже тех, что в инцидентах описывают, т.к. без нового ключа работа в нашей системе будет не возможна, что приведет к остановке работы многих сотрудников. Конечно, если заранее позаботиться о получении нового ключа, то вопрос стоит не так остро, но я не об этом.

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

    • Иван, отличный пример, спасибо.

      Что касается разных исполнителей, то и это кажется мне недостаточным основанием для выделения процесса – важнее разница в организации труда. Например, есть варианты реализации, где VIP-пользователей обслуживают выделенные группы операторов и даже специалистов. Но это не означает, что обработка запросов VIP-пользователей обязательно выделяется в отдельный процесс.

    • Да, Иван – я, собственно, тоже из практики брал
      Ну не получается (и бессмысленно) в большинстве реальных практических процессов делить обработку запросов и инцидентов

    • Федулов Кирилл

      Побольше бы здесь обсуждений непосредственно от “real”ьных участников процессов. Иван, пишите чаще! Ваше мнение, как мне кажется, здесь самое ценное. Оно сродни оценке пользователя в обсуждаемых процессах 🙂

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

      • Как забавно устроена жизнь. Начнёшь нормальную тему, опираясь исключительно на практику, выскажешь свою точку зрения (что, мол, делить не надо). После чего участники беседы поддержат Александра и Ивана. Александра – в том, что он прав, Ивана – в том, что он практик. А автору – шиш 😀

        • Георгий

          Автору – почет и уважение 😀

      • Иван

        Готов писать посты, опирающиеся на мой практический опыт. Вы только скажите как 🙂

        К тому же все больше убеждаюсь, что в основном обсуждаются проблемы внутренних служб поддержки, а особенности внешних обсуждают крайне редко (все-таки свои особенности есть).

        • Кирилл Федулов

          Ну посты, это к создателям портала 🙂
          Вот кстати и тема для новых-старых обсуждений: “отличие внешений и внутренней поддержки на практике”

  • Кирилл Федулов

    Дмитрий, Вы же понимаете, что при таких дискуссиях на нижних ветках изначальный посыл теряется и забывается. Такова уж судьба “топик стартера”. Но, чтобы у Вас не падала мотивация в дальнейшем “открывать” подобные обсуждения, вместо шиша могу признать, что ваша точка зрения мне сильно ближе. Не дуйтесь =)))

  • Дима, я с тобой уже столько раз согласен был, что самому страшно )

    Даже хотел в ответе на тебя тоже ссылаться (к приходу OT инструмент стало возможно подкручивать как угодно, и он практически перестал влиять на процессные решения), но не стал – вдруг у тебя другое мнение. А оказалось – такое же )

  • Борис Юрченко

    Год назад руководил службой ТП в крупном системном интеграторе, поддерживал корпоративных заказчиков, системы контактных-центров. Договорились с заказчиком на обработку "запросов" в рамках "инцидентов" по приоритету "4-консультационный" с SLA- 2ч реакция, 30д. решение. Обрабатывался той-же группой инженеров левел2 и вопросов больше ни у кого не возникало "к нам или не к нам".

    Реальные примеры: 1) Нужна документация по определенному функционалу 2) Что будет если "нажмем здесь" ? 3) Нам кажется, что работает "не так".

    С уважением, Борис.

  • niicyymvi

    Довольно интересно


Добавить комментарий для Роман ЖуравлёвОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM