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

Как правильно распределить 6 заявок на 4х сотрудников?

Опубликовано 15 апреля 2019
Рубрики: ITSM, Service Desk, Вопрос из зала, Всё это - ЛЮДИ, Измерение и оценка ИТ, Обо всём на свете, Практика и опыт, Эксплуатация ИТ
Комментарии

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

Вопрос про конвеер заявок.

Допустим поступает 5 заявок на 4х сотрудников. 4 раздаются автоматом, а как бысть с 5й?

Варианты:

1) Заявка висит в очереди, пока кто-то не освободится и не закроет свою, а после этого назначается на первого освободившегося.

2) 5 заявка назначается сотруднику 1, 6-я — сотруднику 2. В итоге сотрудники уже имеют в работе по 2 заявки одновременно. Но тогда появляется ситуация, что OLA (расчетное время выполнения одной задачи) посчитано по одной заявке, а время идёт сразу по двум (т.е. получаем что либо сотрудник должен в два раза быстрее теперь справиться, либо OLA должен быть в 2 или в 3-4 раза больше, чем необходимо).

Как на практике применяется этот момент? Спасибо!

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Построение системы KPI для ИТ
Как обеспечить управление процессами, проектами, услугами, персоналом

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

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

  • Сергей

    Добрый день.
    Тут однозначного ответа нет, т.к. практических реализаций может быть очень много. Все зависит от конкретной цели для чего строится учет, и определения как рассчитывается выполнение OLA.
    Точно целевое значение показателя выполнения OLA не должно меняться от количества заявок с которыми одновременно работает сотрудник, если это не прописано в договоренности операционного уровня.
    Расчет выполнения OLA может быть в виде интегрального показателя, который включает в себя набор показателей (время реакции, время решения, время взятия в работу и т.д.) для операций входящих в услугу.
    Так же показатель выполнения OLA может рассчитываться просто как отношение выполненных заявок согласно цели OLA к выполненных всего заявок. Как одни из примеров расчета.

    • Денис

      С OLA понятно, спасибо.

      В целом, при нарушенных сроках хотелось бы понять причину нарушений. Если раздавать заявки по одной, а остальные держать в очереди, то получим большое время реакции и какой-то отрезок выполнения – постфактум будет понятно в чем причина просрочки: видно будет заявку с относительно большим временем “в работе”.

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

      Плюс кто-то из разгрузившихся сотрудников мог бы из очереди эту заявку подхватить, а так она повисла в скрытой очереди (а формально “в работе) уже персонально у кого-то.

      В дополнение ко всему сам сотрудник начинает подвергается стрессу (время по всем заявкам которые у него в работе истекает сразу ) и соблазну не провалить свой KPI, забросить сложную проблему в дальний угол и решать простые.

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

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

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

    А не подойдёт сделать не распределение по доступности, а запрос исполнителем по готовности выполнять вторую заявку? Т.е. у исполнителя одновременно может быть более 1 заявки в работе. Единственное нужно ограничение сверху кол-ва заявок в одновременной работе и возможность из пула решаемых выводить (ставить на паузу) заявки, которые сейчас решить не возможно.

    • Сергей

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

  • Алексей

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

  • Илья Рунов

    А чего мы хотим? Из заголовка видны два варианта решения при сохранении _скорости_ поступления заявок: в один момент времени 6 заявок, 6 сотрудников или 4 заявки, 4 сотрудника. Предположим, менеджер хочет принять решение: поругать исполнителя за лень, чтобы работал быстрее(4х4), или увеличить пул доступных специалистов, если четверо не справляются(6х6). Можно попробовать отделить назначение(push), подтверждение правильного назначения(pull), принятие в работу(pull). Учитывать последовательные события: назначение в группу; подтверждение группой, что заявка попала по адресу; назначение специалисту; подтверждение специалистом, что готов принять в работу; фактическое принятие специалистом в работу. События для подсчета длительностей между ними. Количество перечисленных событий не равно количеству состояний в workflow. Длительность следует нормировать и сравнивать с фактом. Разрешить специалисту в один момент времени держать в работе только одну заявку. При переключении новой заявки «в работу» старую возвращать в «подтверждено специалистом, что готов принять в работу». Назначать «пятую» заявку конкретному специалисту можно (даже автоматически) после завершения работ по предыдущим «подтвержденным» заявкам (учет приоритетов заявок в алгоритме – следующее усложнение). В результате у менеджера будет «чистая» длительность выполнения работы и несколько длительностей разных типов «ожиданий выполнения работы». Тогда, ругать специалиста, если длительности «подтверждения готовности выполнить» группой или специалистом выше нормы. Ругать, если фактическая длительность выполнения не адекватна содержанию работы. Если в один момент времени выполняется только одна заявка, то при разумной фактической длительности выполнения и большой фактической длительностью между готовностью принятия в работу и началом работы разумно добавлять пул ресурсов, или менять процесс, или менять ожидания заказчика. Плюсы: видны текущие заявки в фактической работе, чем именно занят конкретный специалист; можно предсказать, какие заявки будут просрочены, вмешаться в последовательность выполнения. Минусы: работать специалисту в такой «потогонке» тяжело, часть уйдут; специалисты будут бороться за увеличение нормы длительности выполнения и прятать в нее «перекуры»; где найти менеджеров с «правами», желанием и компетенцией оценки нормы длительности выполнения работ каждой заявки и настойчивостью в воздействии на исполнителя; дополнительные административные затраты времени.

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

    А мы чего хотим? Если скорейшего времени решения, назначаем первым освободившимся и выстраиваем мотивацию так, что кто больше обработал, тот больше получил. Если (зачем-то) мы хотим равномерной загрузки (то есть как бы справедливости), то строго по очереди.

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

    P.S. Если хотим математической красоты, назначаем всем по 1,5 заявки 🙂

  • Sinan Aliyev

    “либо OLA должен быть в 2 или в 3-4 раза больше, чем необходимо”
    Если ситуация такова что OLA был подписан, а ситуация теперь показывает что выполнить не можем, то возможно надо его переделывать. Желательно сначала проводить анализ, уточнив зак какое время, что мы успеваем, а потом указывать реальные таргеты. Не забываем про SMART, а в частности A-Achievable, R-Relevant. Почему R? Потому что необходимо ли? Чаще всего бессмысленно так загонять себя в угол, разница в 5-10 минут на решение инцидента или запроса, возможно не приносит столь серьезного негативного влияния. Во всяком случае, его надо тоже финансово посчитать. Чего стоит этот простой? Если стоит, то сравните с наймом доп сотрудника и перераспределите нагрузку вновь.

  • Денис

    В целом получается парадоксальная ситуация – при пиковых неплановых нагрузках (пришло задач в 2 раза больше из-за какой-то глобальной причины, летит kpi отдела, который не отвечает за эту аварию, а героически все устраняет. То есть сотрудник работает в 2 раза больше, а получает выговор и депремирование. И что-то в этой системе не так. Понятно, можно в ручную пересчитать, но должно же все учитываться автоматически и работа сверх нагрузки в том числе.

  • Sinan Aliyev

    Верно. Не так. Называется этот инструмент Demand Pattern. Надо изучать а когда у нас в компании, там в бизнесе плановые, неплановые пики. Это банк? Если да то, отчётный период – конец месяца, квартала, года. Это компания сеть ресторанов? Значит пик, социальные праздники (8 марта), сезонный бизнес (летом аквапарки). Надо понять а что зарабатывает, какова критичность тех же самых ИТ услуг в эти пики. Каков процент заработка в сравнении с тихим периодом.
    Как это сделать? Как быстро и просто это понять? Разговаривайте, спрашивайте. Там в бизнесе, владельцы этих бизнес процессов, ветераны, знают когда у них горит. Вам надо глубже? Ставьте мониторинг, как на уровне технологий так и на уровне бизнес операций в аппликациях. Разработайте красивый тренды, дашборды. Статистика, это один из самых упущенных иважнейших инструментов Knowledge Management-а. Вспоминаем цикл – Data – Information – Knowledge – Wisdom.

    В зависимости от скачка, вычисляем сколько мы можем себе позволить прибавить к OpEx-у, к текущим ресурсам ИТ Департамента в эти пики. Обсуждаем их отдельно, договариваемся и прописываем в OLA, SLA, процедуры, называйте как хотите. И отходите от героизма. В долгосрочной перспективе, это регрессивно. Это одна из причин оттока ресурсов. В том числе в зарубеж. Надо выходить из ИТ департамента и изучать индустрию, изучать бизнес. Только так мы выйдем из саппортера в центр профита.

  • Sinan Aliyev

    Если не можем содержать внутренние постоянные ресурсы, пользуем 4 Dimensions – Partners and Suppliers. Транслируем риски на них. Поставщиков. Что они могут предложить нам в этих ситуациях. Можем ли запросить внеплановую поддержку от них. Локальный ресурс на сайте. Сколько это будет стоить. Бизнес может рассмотреть такую модель.

  • Антон

    Коллеги. давайте с терминологией разберемся.
    Operational Level Agreement (OLA) – Соглашение операционного уровня (OLA) – (Проектирование услуг) (Постоянное улучшение услуг) Соглашение между Поставщиком ИТ-услуг и другой частью той же Организации.

    Если мы говорим о времени решения и времени реакции на заявку то это совсем другая история.

    Теперь про то как назначать. У меня тут немного вопросов.
    1. Все заявки одного типа, сложности, длительности?
    2. Если у вас один из 5 ушел в туалет, а на него назначили заявку, как тут вы поступаете?
    3. У вас же есть договоренности с бизнесом на какие-то сроки?

    По мне автоматическое назначение – самое плохое назначение и выбирая из двух зол я бы выбрал очередь по одной причине: Нет зависимости от человека и время ожидание в очереди будет предсказуемо

  • Денис

    1) все разные по сложности. В том-то и проблема, что пока решаешь одну и застрял, время идёт по нескольким другим тоже. И в итоге выгоднее бросить сложную и переключиться на простые ( но не факт что они не окажутся с подвохом). Или, поработав над одной сложной основательно и долгои решив ее, получить пачку других просроченных и испорченную статистику.

  • Денис

    В целом получается, как ни сделай, а все равно при большом потоке либо в очереди прогорят задания, либо в работе и в итоге летит КПИ сотрудника, который никак не виноват что его в такие рамки загнали. Вот пока получается что ITIL становится инструментом наказать сотрудников, ведь нигде не прописано, что мастер Вася Пупкин не может за день поменять краны 200 позвонившим клиентам. Должен же успеть, ведь есть время реакции и есть время решения. Антон не укладывается почему-то.

    • Андрей Труфанов

      Исправлю: “летит KPI руководителя этого Васи Пупкина”, т.к. он не обеспечил возможности по управлению/удовлетворению пикового спроса (или создал этот спрос релизом изменения/приложения, как часть бывает в IT). Если в Васи есть норматив на один средний кран, то именно этой метрикой его и нужно измерять.
      ITIL здесь ни при чем

      • Денис

        Норматив есть, допустим час. Но прилетает в час 10 таких задач, открываются и 10 задач начинает одновременно идти время. А человек-то один.

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

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

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