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

Контроль обработки инцидентов

Опубликовано 3 октября 2018
Рубрики: ITSM, Вопрос из зала, Обо всём на свете, Практика и опыт, Процессы, Управление инцидентами, Эксплуатация ИТ
Комментарии

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

Хотел бы задать вопрос в студию о наболевшем.

Ситуация следующая: рабочие группы обрабатывают заявки только через Таски (рабочие задания), ничего другого они не видят, хотя практическая возможность из Таска заглянуть в Инцидент или ЗнО\ЗнИ присутствует.

Заказчику мы естественно «продаём» Инциденты и Запросы.

Сейчас мне настойчиво «предлагают» отойти от схемы указания в Инц\ЗнО\ЗнИ группы поддержки (поле Группа назначения), потому как может быть несколько одновременно выполняемых Тасков (или ещё пор каким то причинам) да и сами группы работают только с Тасками.

Т.е. увидеть в списке\перечне Инцидентов (например) кто сейчас за него отвечает возможности не будет и это усложнит подготовку отчётов для заказчика (прописывать логику что из какого таска должно попасть в отчёт Заказчика по Инц\ЗнО\ЗнИ – малоприятного).

Вопроса два:

— что думает об этом, снятие («де-факто») ответственности за исполнение Инц\ЗнО\ЗнИ с групп поддержки, уважаемое сообщество

— есть ли отработанные и практические советы как в этом случае эффективно управлять процессами и контролировать обработку Инц\ЗнО\ЗнИ сервис-менеджеру.

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

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

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

  • Виктор

    Если я правильно понял ситуацию, то я действительно не понимаю, зачем заказчику показывать, какое подразделение закрыло инцидент.
    Данная информация нужна лишь для подсчета трудочасов сотрудников и %, куда ушли ресурсы подразделения.
    Также данная информация нужна, если у вас действует схема оперативной связи инициатора с текущим исполнителем (мы специально у себя эту схему зарезали).
    Единственное, я бы на вашем месте вместо “текущего исполнителя” в отчете указывал ответственное за услугу подразделение, которое и отвечает за соблюдение её SLA.

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

    • Сергей

      Виктор, доброго.
      Непонятно как контролировать кто (какая группа\специалист) в настоящий момент отвечает за решение инцидента\ЗнО.
      То есть если за Таски отвечает группа поддержки, то за Инциденты\ЗнО – именно их решение “продаём” – сервис-менеджер. У сервис-менеджера в списке всех Инц\ЗнО – не будет видна группа поддержки ответственная за конкретный Инц\ЗнО.
      Что бы узнать – надо заходить в каждый.
      Работать в этом случае сервис-менеджеру с консолью инцидентов\ЗнО – неоптимально.
      Работать с консолью тасков в группы своего сервиса (10ять консолей 10ти групп работающих с тасками или одну общую по таскам) – пропустить инцидент\ЗнО – по которому указан сервис неправильно или произошло некорректное назначение.
      И так и так – неудобно.

  • Виктор

    Я не знаю, в какой системе вы работаете, но в большинстве из них (у нас в частности, Итилиум и JIRA) видно как ответственное подразделение по самому обращению (на случай, если обращение будет просрочено, можно спросить у него, что происходит и когда ждать счастья), так и текущий открытый таск (“наряд” – в итилиуме) и ответственного, который по нему сейчас работает.
    А ещё есть различные столы, которые можно настраивать в любых срезах.

    • Сергей

      Виктор, спасибо.
      То есть у вас (мы в ServiceNow работаем) есть возможность в дашборд\стол\консоль по инцидентам (перечень инцидентов по сервису) подтянуть колонку из связанного Таска?

  • Андрей К

    Корневой вопрос когда все работы в тасках – кто отвечает за итоговый результат. И именно из этого стоит исходить, а не как и откуда тянуть колонки. Поэтому Менеджер процесса у вас справедливо переживает.
    Ответственный за Инцидент/ЗнО/ЗнИ нужен для организации работ: контроль общих сроков работ (у вас же SLA на родительский объект, а не на таски, верно), работа с неудачными таскми, создание новых, если предыдущие ни к чему не привели и прочеее. С него итоговый спрос.
    Другой вопрос, что на каждый запрос такого Координатора не поставишь. В таком случае мы делали спецфлаг “Нарушение стандартного хода работ”, который требовал внимания в случаях когда таски закрывались с нехорошим кодом или создавались новые в дополнение в шаблонным. Т.е. управляли по исключениям. Работает и так, и так.

    • Сергей

      Андрей, спасибо.
      А кто выставлял в родительском объекте такой “таск”?
      Если сервис-менеджер (группы работают с тасками) то возвращаясь на круг – мониторить из родительских объектов все связанные активные таски – неудобно.

      • Андрей К

        Если вы про флаг, то он вставал автоматически и был признаком, требующем ручного контроля.

        • Сергей

          Андрей, принято.
          Хотелось бы, что бы кто-то принимал меры что бы подобные “нехорошие” флаги не возникали. Флаг это по наступлению события, а вот как бы принимать меры что бы нехорошее событие не наступало по Инц\ЗнО, не имея ответственного за каждый конкретный Инц\ЗнО.

          Спасибо за совет, попробую логику появления таких флагов продумать до наступления нехорошего события.

  • Сергей Семикин

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

    Правильно я понял, что у вас в системе учёта обращений создаётся заявка (она же упоминается в вопроса, как Инцидент/ЗнО/ЗнИ.

  • Сергей Семикин

    И ещё один вопрос: каково ваше разделение ответственности и исполнения за: процесса решения Инц/ЗнО/ЗнИ, решения конкретного экземпляра заявки, решения текущего таска?

    • Сергей

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

      • Сергей Семикин

        На сколько понимаю разделение ответственностии исполнение такое:
        Процесс решения:
        отв. за корректное выполнение операций процесса – сервис-менеджер
        Решение заявок: отв. сервис-менеджер, исп. группы поддержки
        Решение тасков: отв и исп сотрудники групп пождержки

        Ответы на вопросы:
        1. Снятие де-факто ответственности за результат продоваемых заказчику услуги и передача ее сервис-менеджеру будет работать, если у него есть полномочия награждать/наказывать руководителей и исполнителей рабочих групп. Если такого нет, то ему будет очень тяжело корректировать их деятельность. А точно ли именно ответственность снимается, больше похоже на скрытие поля от заказчика, что не мешает его оставить видным внутри.
        2. Либо по расписанию, либо, как было сказано, ранее автоматически метить заявки, уже вывалившиеся из лимитов, и ими рулить в ручном режиме + полномочия на воздействие на исполнителей.

        • Сергей

          Сергей, спасибо.

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

          • Сергей Семикин

            Давайте расскажу, как реализовано, где сейчас работаю.
            Существует ответственность за решение заявки, указано может быть, как только рабочая группа, так и дополнительно конкретный сотрудник. Меняется ответственный в ручную и могут сделать это, как сотрудники 1 линии всегда, так и сотрудники текущей ответственной группы. При этом на самой ответственной группе может в заявке не быть ни одного активного таска.
            Определяется текущая рабочая группа в заявке по схеме функциональной эскалации в зависимости от текущей проблемной КЕ.
            Эта схема позволяет сервис-менеджеру меньше времени тратить на поиски того, кто должен реально влиять на ход решения. Из минусов возрастают возможности “футбола” заявок, и.е. доп затраты на контроль.

            • Сергей

              Сергей, ещё раз спасибо.
              Я правильно понимаю что сотрудники рабочей группы у вас видят в консоли не только таски но и Инц\ЗнО если отвечают за их исполнение? В одной консоли или в разных?

              • Сергей Семикин

                Сергей, извините за долгий ответ.
                Да, видят и свое задание (таска) и заявку (Инц/ЗнО), да и всю историю работы по заявке тоже видят. Из формы заявки можно увидеть все задания, из формы задания вызвать родительскую заявку.

                • Сергей

                  Сергей, то что из формы Таска можно перейти в Инц\ЗнО – это понятно.
                  1. Но видят ли специалисты в одной консоли и Инц\ЗнО за которые отвечают и Таски?
                  2. Имеют ли возможность специалисты изменить в карточке Инц\ЗнО – информацию.
                  3. Как наладить контроль над Инц\ЗнО если поле (группа поддержки) будет скрыта?

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

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

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