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

Кто последний, тот и...

В редакцию портала поступил вопрос. Альберт, постоянный читатель и комментатор RealITSM, спрашивает:

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

Есть вопрос по определению ответственности по просрочкам в обращениях.

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

На мой взгляд, это несправедливо, поскольку те сотрудники, по чьей вине обращение просрочено, избегают ответственности, передавая её на других исполнителей. 

Поделитесь, пожалуйста, своими идеями по данному вопросу: кто как решает данный вопрос, какие есть алгоритмы определения ответственности по просроченным обращениям?

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

  • Сергей

    Ответ из книжки расчет показателя TPI

    Ответ из жизни. У нас каждое нарушение заносится в отдельную таблицу. Обязанность менеджера услуги состоит в анализе каждого нарушения и заполнения нарушителя или нарушителей. Это позволяет указать причины, указать, что нарушение произошло по вине двух групп или исполнителей (например, при параллельной работе), а также указать другие ошибки. К примеру, обращение провисело 90 % времени в ЦПП до эскалации. Или была выставлена неверная услуга — в результате все работали с одним SLA, а когда проанализировали — сменили услугу и SLA упал. В общем, у нас так — ответственность за нарушение SLA — в зоне персональной ответственности менеджера услуги и его обязанность провести анализ причин возникновения нарушения, выработать мероприятия по их устранению и наказать виноватых. На основании этих данных строятся уже все отчеты и метрики.

    Для понимание 1МЛН обращений в год 300 услуг 100 менеджеров услуг 99,7 плановый показатель количества выполненных обращений

    • Альберт

      Понятно, что за качество оказания ИТ-услуги отвечает менеджер ИТ-услуги, в Вашем случае нет чёткого алгоритма, фактически роль судьи на себя берёт менеджер ИТ-услуги, разбирая просроченные обращения в ручном режиме, на мой взгляд, здесь велики риски субъективной оценки, личного взаимоотношения с исполнителями и т.п... Спасибо за ответ

  • Alexey Yusov

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

  • Альберт

    спасибо, я также пришёл к этому выводу, мерим сколько времени выполняли исполнители, тот кто больше держал просроченное обращение, тот больше остальных внёс вклад в общее дело просрочки, тот и виноват.

    • Геннадий

      Интересно.

      А если группа действительно работала с обращением, допустим 3 часа (нашлись проблемы и действительно все исправляли) и для закрытия надо было получить согласования с каких-то 3х других групп, которые уже каждая растягивала этот процес по пол часа каждая(обедали, за чаем ходили, чем-то другим занимались). А SLA у вас — 4 часа. 

      Виноваты будут те, кто работал 3 часа? 🙂 

  • Денис

    Коллеги, ну а какже тот факт, что:

    1. если просрочила одна группа исполнителей, которая фактически не выполняла обращение, но держала на себе, к примеру, 4 часа, ;

    2. вторая группа исполнителей, которая выполнила обращение сделала это за 30 минут.

    Итого по схеме распределения получаем, что та группа, которая просрочила, но не выполнила обращение, получает его просроченное. А вторая группа, которая выполнила обращение, не получает ничего.

    Ваше мнение по данному поводу? Я считаю, что не справедливо.

    • Алексей Кротов

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

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

      или не хватает рес-сов для группы.

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

  • Альберт

    Добрый день, я так понял дискуссия закончилась, можно обратиться к литературе и получить ответ из книжек? Спасибо

    • Алексей Кротов

      Честно — не могу найти лит-ру, но это достаточно известная книга по матричному подходу к управлению (процессный + иерархический/функциональный подходы), в к-ром процессного управляющего интересует конкретный конечный продукт, а функционального — чтобы его команда не разбежалась и маневры м/ду хотелками процессных управляющих. 

  • Николай

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT