Отделяем инциденты от запросов

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

ITIL® пишет о том, что эти два процесса могут быть одним (как, например, в ISO 20000:2011), но лучше их разделять, потому что:

Инцидент – это обычно событие неожиданное, в то время как запрос на обслуживание можно и нужно планировать… хотя «туманные» области всегда останутся…

© ITIL Service Operation, TSO, 2011

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

Решение должно отталкиваться от объёма и структуры этого спроса. Зачем люди приезжают в автосервис? Мне кажется, в трёх случаях:

  1. Если с автомобилем что-то «не так» (последствия аварии, нештатные шумы и т.п.).
  2. Если автомобиль надо улучшить, чтобы повысить удовлетворенность им (тюнинг).
  3. Если пора делать ТО (по рекомендациям завода-изготовителя).

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

Тогда получается, что 1 – это инциденты, а 2 и 3, конечно же, запросы на обслуживание. Спрос на ваши услуги будет складываться, таким образом, из нормированных (тюнинг и ТО)  и ненормированных (вот они, инциденты) работ.

Ура! Приступаем к планированию ресурсов. 

  • Ведь вы знаете точно, сколько автомобилей эксплуатируется в вашем городе и как часто их надо обслуживать? Более того, работы по ТО уже нормированы по времени и снабжены чёткими инструкциями того же завода производителя. Значит, можно посчитать требуемое количество "рук" для этих работ и даже количество механиков в смене (например, многие клиенты считают удобным сдать машину на ТО утром, перед работой).
  • Кроме этого, вы знаете (и об этом пишет ITIL) статистику инцидентов, и на ее основе можете спрогнозировать объем работ по пункту «1». А учитывая пиковые значения, взять в каждую смену «резервного» механика, на случай большого количества аварий (гололёд, 1 сентября и т.п.).
  • «Туманной» областью здесь является «тюнинг», ведь на эти услуги нет устойчивого спроса, напротив – сами услуги меняются со временем (сейчас вот мода на шторки на дверях иномарок E-класса и на ДХО). Механизмы предсказания здесь уже не в статистике прошлых периодов, а в сфере управления спросом.

Резюмирую: отделять обработку инцидентов от запросов на обслуживание нужно, прежде всего, если вы планируете ИТ-персонал на основе статистики. А в противном случае, какая разница? Всё равно в обоих процессах работают одни и те же механики.

Ну как?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Дмитрий Исайченко

    ...но лучше их разделять, потому что: "Инцидент – это обычно событие неожиданное, в то время как запрос на обслуживание можно и нужно планировать… хотя «туманные» области всегда останутся"

    Хилое основание. Например, изменения тоже бывают плановые и внеплановые (срочные / аварийные). Так что — надо делить на разные процессы? И закупки быват плановые и срочные. Тоже два процесса?

    Конечно, в этих двух случаях есть своя специфика в отработке процедур, но самого факта наличия как плановых, так и внеплановых событий / работ еще не является достаточным основанием для выделения их обработки в разные процессы. Нет?

    0
    0
    1. Константин Нарыжный Автор

      Это не хилое основание, а лучшие практики.

      Что значит "внеплановые" изменения? Надо определить критерии экстренного изменения и отдельную процедуру для них (см. ISO20000:2011 9.2). Так что таки да — тут два разных потока работ.

      0
      0
  2. Дмитрий Исайченко

    А еще одной причиной "не делить" является как раз наличие таких "туманных областей", а значит — потребность в переклассификации объектов, нечеткое разделение ответственности за обработку отдельных видов запросов и так далее.

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

    0
    0
    1. Константин Нарыжный Автор

      Процесс, как известно, приводит к результатам, путем преобразования ресурсов в выходы.

      Результат УИ — повышение удовлетворенности заказчиков и по пользователей путем скорейшего устранения сбоев.

      Результат УЗО — предоставление пользователям стандартных видов обслуживания.

      Устранение инфраструктурных и пользовательских инциденты приведет к результату УИ. Хилый пример 😉

      0
      0
    2. Андрей

      C одной стороны, действительно, это все работы инженеров. Плановые и неплановые. Поэтому и MOF понятен, и ISO20000. Только плановые идут по шаблону и малорисковые, а неплановые зачастую непонятны и довольно рисковые. Т.е. с первыми справится менее квалифицированный инженер, а вот с инцидентом еще разбираться надо. Тут я полностью согласен с Максимом и Робом 🙂

      Далее отчетность по процессу. Аналитику проблем не особо интересны запросы. А вот статистику инцидентов посматривает. Т.е. нужно разделять по какому-то признаку.

      Можно еще найти разницу уже при автоматизации. В запросах, например, может быть плановое время старта. Зачем оно инцидентам? А если необходимо создавать группы запросов (дать доступ в дату1 – отнять доступ в дату2)? Запросам нужно интегрироваться со сложным деревом шаблонов на портале, а инцидентам упростить регистрацию и найти похожие. Т.е. автоматизация отличается. В итоге много правил разделения и сложно администрировать.

      С «туманными областями» тоже imho более-менее ясно:

      — инцидент не может стать запросом (только потребовать выполнение связанного запроса, но это не отменяет инцидент)

      — запрос не может стать инцидентом (может оказаться, что есть связанный инцидент, но запрос надо будет продолжить после устранения инцидента)

      — стандартный запрос может оказаться нестандартным и наоборот. Решается 1 кнопкой в средстве автоматизации в рамках УЗО

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

      0
      0
      1. Alexander Peshkov

        Почему аналитику проблем не интетесны запросы?

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

        0
        0
        1. Константин Нарыжный Автор

          Зависит от того, о каких аналитиках проблем вы говорите.

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

          А если о живых, то, я такой роли документально зафиксированной, описанной и закрепленной нигде не видел. И если бы увидел, то подозреваю, что такой сотрудник был бы загружен другими проблемами, у которых соотношение "выгода \ затраты на устранение" было бы несколько выше, чем "экономия времени айтишников \ стоимость обучения Excel" =)

          0
          0
          1. Alexander Peshkov

            Беспощаден как зорро!

            Есть такая категория инцидентов — пользовательские инциденты. Когда все работает, а пользователь дотягивает до последней секунды и разъяренно требует срочно создать ему что-то, потому что сам он не умеет, а через пять минут совещание у ГД.

            0
            0
  3. Nargiza Suleymanova

    Мне как раз очень близка идея разделения этих двух процессов: в моепрактике они требуют совершенно разного подхода. Про аргумент, что используются те же люди, скажу так: а разве в управлении проблем не те же люди участвуют, что и в управлении инцидентами? В реальной жизни — очень даже 😉

     

    0
    0
    1. Константин Нарыжный Автор

      Наргиза, прочёл ваш комментарий, и внезапно вспомнил, что я сейчас адепт MOF 4. Там, то что мы называем УИ и УЗО объдинены в Customer Service SM Function со следующей общей целью: 

      The primary goal of customer service is to provide a positive experience for users by meeting their IT needs and addressing complaints and issues that arise during the normal course of using an IT service. 

      И работа состоит из 5 шагов:

      ·         1. Records the user’s contact information and the details of the request.

      ·         2. Classifies the user’s request.

      ·         3. Resolves the user’s request.

      ·         4. Confirms the resolution and closes the request.

      ·         5. Ensures good service.

      И различаются только подпроцессы 3 😉 http://technet.microsoft.com/en-us/library/cc543262.aspx

      0
      0
  4. Nargiza Suleymanova

    Браузер сглючил, так что дописываю 🙂

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

    Вообще, что с запросами хорошо: они предельно просто описываются 🙂

    0
    0
    1. Константин Нарыжный Автор

      А вот в этом комментарии вспомнил Роба нашего Ингланда. Он, Наргиза, как раз на вашей стороне. У него сейчас главная идея "Standard+Case". Боюсь, по-русски пока ничего не публиковалось на эту тему. Вот тут можно посмотреть: http://www.basicsm.com/standard-case

      Если грубо, то Роб считает уникальные инциденты Case-событиями, требующими творческого подхода к решению. Всё, что неуникально должно быть стандартизовано, измеримо и предсказуемо. 

      0
      0
  5. Чак Максим

    А я согласен с необходимостью разделения... И аргумент у меня простой:

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

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

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

    0
    0
  6. Vladimir Lyaleko

    Очередной виток вечного вопроса...

    Очевидно, что вопрос разделения процессов, ровно как и вопрос "Что такое услуга" зависит от среды в которой мы строим нашу систему управления.

    Главное научиться говорить на одном языке, оказавшись в данной среде.

    Было бы круто сформировать объективные критерии подхода к проектированию процессов управления инцидентами и запросами. 

    Один раз пытались, но в данном посте все было в одну сторону (http://www.realitsm.ru/2011/06/srm_and_incident_management/).

    После того поста в голове сложилась определенная картина мира, которую использую в работе:

    Два процесса если:

    1. Разные ресурсы исполнения (это редкость, но встречалось на практике).

    2. Кардинально различаются потоки работ (например, когда в запросах поднимаются вопросы согласования, стоимостных оценок и т.д.). Сводный регламент в котором отражена обработка  инфраструктурных инцидентов, обращений пользователей и выполнения запросов на обслуживание  получется монстроподобным. Был пример, когда силами заказчика единый регламент был разделен на три:  Управления инцидентами, Управление обращениями и Управление запросами. Справидливости ради стоит отметить, что обратная ситуация бывает гораздо чаще. Когда вендор настоял на разделенмии процессов, которые нечем друг от друга не отличаются и заказчик самостоятельно сводит кучу мукулатуры в единый рабочий документ. Один раз даже было, когда сначало разделили, потом объеденили, потом снова разделили :))) Причем  все без участия внешних консультантов 🙂

    В целом указанные факты часто сводят на нет позитивные моменты объеденения процессов, о которых писал Дмитрий.

    Было бы круто пополнить этот список дополнительными аргументами ЗА (кроме соответствия ITIL и желания вендоров).

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

     

    P.S В тему предложенной аналогии:

    Для ремонта и ТО у меня официальный поставщик услуг.

    Для тюнинга и целого ряда запросов на осблуживания (замена масла, расходников) у меня серый поставщик услуг.

    Это к вопросу о одних и  тех же механиках 🙂  Опять много букв получилось...

     

     

     

    0
    0
  7. Alexey Yusov

    Мне кажется приведенный пример с автосервисом крайне неудачным или, в лучшем случае, очень сферическим. В отрыве от SLA вопрос разделения этих процессов даже с точки зрения только планирования ресурсов рассматривать крайне сложно. И цели процессов разные. В случае с инцидентами на первом месте — скорость решения. И только это будет создавать "positive experience", который позитивен только в случае "asap". В случае с запросами для клиента — позитив, если просто в срок сделают все задачи или ответят на вопросы.

    Был пост Евгения Шилова про типовый заявки — http://www.realitsm.ru/2013/07/tipovye-zayavki/. Там все очень дельно написано. И это совсем другой процесс, в том числе и по уровню автоматизации. И что касает примера MOF, то и 2-ой процесс различается существенно. Для типовых запросов клссификация должна быть преднастроена фактически.

    Так что на мой взгляд, при любых вариантах, это 2 разных процесса. А если кажется, что он один в каком-то конкретном случае, то скорее всего второго просто нет вообще. Или он просто как суслик, которого не видно, но он есть :-)!

    0
    0
  8. Alexey Yusov

    У него (автосрвсиса) нет обязательных клиентов, которых он обязан обслуживать с заданным SLA. Безусловно, "шикарные лучшие практики" можно применть к любому сервисному бизнесу, откинув IT от SM. Но обосновывать единство и противоположность инцидентов и запросов примером автосервиса я бы не стал. Владимир Ляленко тоже показал разницу в примере про "официалов" и "серых" поставщиков.

    0
    0
    1. Константин Нарыжный Автор

      Кто такие "обязательные клиенты"? Которые не опаздывают к назначенному времени? )))) Параметры качества услуг для внешних поставщиков задаются рынком. Не соответствуешь рыночным значениям — попрощайся даже с необязательными клиентами. Вот такой вот вынужденный SLА, если он вам необходим.

      Я не очень понял про "серых" поставщиков. Признавать борьбу "серого" с "белым", значит указывать клиенту (а в моем случае еще и слушателям) на его место в цепочке создания ценности: спонсирующее и зависимое. Теория управления качеством, из которой "шлп" растут — как раз об обратном. Я в этой истории предполагаю, что рынок конкурентный и прозрачный. Это если умствовать. А проще можно сказать, что рынки "белого" обслуживания и "серого" не пересекаются (гарантия-постгарантия). У них разные клиенты (не считая Владимира Лялеко), и там и там разделение и объединение процессов возможно (возможно, что силами Владимира же) 😉

      Любой пример из SM без IT мне как раз всегда кажется удачным, потому что демонстрирует желаемое будущее ИТ-рынка: поставщики ориентируются на клиента, а не на "маржу".

      Все равно, спасибо за мнение и ссылки!

      0
      0
  9. Alexey Yusov

    "Обязательные клиенты" — это те, кто придут за услугами в люом случаею По крайней мере, в течение срока договора (это для внешних клиентов ИТ-компаний). Про SLA, как эффект саморегуляции рынка я не спорю. А вот насчет "белого" и "серого" рынка — это всего лишь вопрос цены и платежеспособности клиента. И рынки всегда пересекаются, т.к. даже самые богатые клиенты иногда заают себе вопрос — "А за что плачу?!".

    Пример с автосервисом очень часто бывает неудачным именно потому, что бизнес всегда ориентирован первично только на "маржу", т.е. на изволчение прибыли. (IT) SM для бизнеса — лишь инструмент для извлечения прибыли. И если у Вас был, есть или будет свой собственный бизнес, то Вы согласитесь со мной, что все "песенки" про SM и Клиента - лишь пустой звук при нулевом сальдо на расчетном счету за отчетный период.

    Многие ИТ-шники даже из самых-самых верхов очень часто этого не понимают, потому что ЗП капает и даже с учетом депремирования за нарушение SLA не может превратиться в ноль сегодня же. Парашюты, отступные по соглашению сторон и т.д... В бизнесе в ноль можно улететь очень быстро.

    Я целиком и полностью за (IT | nonIT) SM. Но каждый отдельный случай в качестве примера надо очень тщательно прорабатывать. Для рассказа слушателям от ИТ и даже не очень можно рассказывать про автосервис в качестве примера. Но попробуйте пригласить на курсы владельца автосервиса. И пусть он рассказжет про инциденты, запросы и клиенториентированный подход. И как делить процессы и ресурсы. Уверен, что будет занимательно.

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
19
ОКТ
23