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

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

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

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

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

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

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

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

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

Комментариев: 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
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM