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

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

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

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

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

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

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

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

Вопроса два:

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

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

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

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

  • Виктор

    Если я правильно понял ситуацию, то я действительно не понимаю, зачем заказчику показывать, какое подразделение закрыло инцидент.

    Данная информация нужна лишь для подсчета трудочасов сотрудников и %, куда ушли ресурсы подразделения.

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

    Единственное, я бы на вашем месте вместо «текущего исполнителя» в отчете указывал ответственное за услугу подразделение, которое и отвечает за соблюдение её SLA.

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

    • Сергей

      Виктор, доброго.

      Непонятно как контролировать кто (какая группа\специалист) в настоящий момент отвечает за решение инцидента\ЗнО.

      То есть если за Таски отвечает группа поддержки, то за Инциденты\ЗнО — именно их решение «продаём» — сервис-менеджер. У сервис-менеджера в списке всех Инц\ЗнО — не будет видна группа поддержки ответственная за конкретный Инц\ЗнО.

      Что бы узнать — надо заходить в каждый.

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

      Работать с консолью тасков в группы своего сервиса (10ять консолей 10ти групп работающих с тасками или одну общую по таскам) — пропустить инцидент\ЗнО — по которому указан сервис неправильно или произошло некорректное назначение.

      И так и так — неудобно.

  • Виктор

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

    А ещё есть различные столы, которые можно настраивать в любых срезах.

    • Сергей

      Виктор, спасибо.

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

  • Андрей К

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

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

    Другой вопрос, что на каждый запрос такого Координатора не поставишь. В таком случае мы делали спецфлаг «Нарушение стандартного хода работ», который требовал внимания в случаях когда таски закрывались с нехорошим кодом или создавались новые в дополнение в шаблонным. Т.е. управляли по исключениям. Работает и так, и так.

    • Сергей

      Андрей, спасибо.

      А кто выставлял в родительском объекте такой «таск»?

      Если сервис-менеджер (группы работают с тасками) то возвращаясь на круг — мониторить из родительских объектов все связанные активные таски — неудобно.

      • Андрей К

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

        • Сергей

          Андрей, принято.

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

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

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

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

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

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

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

    • Сергей

      Добрый день.

      По решению методолога поле «группа назначения» в Инц\ЗнО — признано техническим так как работы выполняются по Таскам.

      За решение Тасков отвечает группа поддержки, сервис-менеджер отвечает в целом за все Инц\ЗнО. Ответа кто отвечает за решение каждого конкретного Инц\ЗнО — нет.

      Исходя из имеющегося — отвечает за решение каждого конкретного Инц\ЗнО — сервис-менеджер

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

        На сколько понимаю разделение ответственностии исполнение такое:

        Процесс решения:

        отв. за корректное выполнение операций процесса — сервис-менеджер

        Решение заявок: отв. сервис-менеджер, исп. группы поддержки

        Решение тасков: отв и исп сотрудники групп пождержки

        Ответы на вопросы:

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

        2. Либо по расписанию, либо, как было сказано, ранее автоматически метить заявки, уже вывалившиеся из лимитов, и ими рулить в ручном режиме + полномочия на воздействие на исполнителей.

        • Сергей

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

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

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

            Давайте расскажу, как реализовано, где сейчас работаю.

            Существует ответственность за решение заявки, указано может быть, как только рабочая группа, так и дополнительно конкретный сотрудник. Меняется ответственный в ручную и могут сделать это, как сотрудники 1 линии всегда, так и сотрудники текущей ответственной группы. При этом на самой ответственной группе может в заявке не быть ни одного активного таска.

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

            Эта схема позволяет сервис-менеджеру меньше времени тратить на поиски того, кто должен реально влиять на ход решения. Из минусов возрастают возможности «футбола» заявок, и.е. доп затраты на контроль.

            • Сергей

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

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

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

                Сергей, извините за долгий ответ.

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

                • Сергей

                  Сергей, то что из формы Таска можно перейти в Инц\ЗнО — это понятно.

                  1. Но видят ли специалисты в одной консоли и Инц\ЗнО за которые отвечают и Таски?

                  2. Имеют ли возможность специалисты изменить в карточке Инц\ЗнО — информацию.

                  3. Как наладить контроль над Инц\ЗнО если поле (группа поддержки) будет скрыта?


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

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

  • Рубрики

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

    • Работать меньше, чтобы сделать больше
      Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, …
    • Это же не наш профиль…
      Не смотр на то, что на нашем портале мы обсуждаем вопросы ITSM, я хотел бы затронуть тему “котиков”. Многие наверняка скажут: “Причем здесь котики? Это же не ваш профиль”. А какой …
    • Кто такие агенты изменений в продуктовой команде?
      Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не …
    • Обновление Scrum Guide
      18 ноября 2020 года отцы-основатели Scrum Кен Швабер (Ken Schwaber) и Джеф Сазерлэнд (Jeff Sutherland) опубликовали новую версию руководства Scrum (Scrum Guide). Это особенно …
    • Где в ITIL можно почитать про управление техническим долгом?
      Во время вебинара нам поступил вопрос: Есть ли в практиках ITIL разделы\главы, в которых уделяется внимание управлению техдолга? (чтобы почитать)…
    • Технический долг: как бороться с невидимым врагом
      Зачастую о техническом долге говорят, как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Он и тебя посчитал
      В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной …
    • «DevOps Handboek» — «DevOps для ИТ-менеджеров» на голландском
      Книга Олега Скрынника «DevOps для ИТ-менеджеров» — лучший выбор для тех, кто хочет разобраться в том, что такое DevOps, — вышла на голландском …
    • Диагностика продуктовых команд как поток
      Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что …
    • Учёт доступности? А можно как-то попроще?
      На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: «а можно как-то попроще?». Вопрос, в общем-то, …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT