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

Учет кратности работ при расчете срока оказания услуги

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

Добрый день!

Безуспешно ищу на форуме тему учета кратности работ при расчете срока оказания услуги (SLA).

 

Кейс следующий:

Наша организация оказывает ряд услуг, работы по которым могут быть множественными. Например, руководитель отдела делает заявку, что необходимо установить ПО на 10 ПК его сотрудников. Или от клиента поступила заявка на изготовление 5 ЭЦП. Диспетчер принимает заявки такого типа как одно обращение и указывает кратность работ 10 или 5. Инженер выполняя работы по обращению может учесть эту кратность при фиксации трудозатрат, с учетом того что норма на одну работу заранее четко определена. Исходя из описанного кейса возникает несколько вопросов:

  1. Логично предположить, что кратность работ должна влиять не только на трудозатраты, но и на срок предоставления услуги (если это заранее оговорено в договоре с клиентом). На каком этапе должно учитываться это влияние, с учетом того, что кратность может увеличиться в процессе выполнения работ? Например, понадобилось настроить не 10 ПК, а 12.
  2. Вытекает из первого вопроса. Если мы будем удлинять срок заявки в зависимости от кратности, клиент просто будет подавать не одну заявку на 5 ПК, а 5 заявок на каждый ПК. Срок у таких заявок стандартный, кто и как их будет выполнять клиента не волнует, мы должны уложиться в SLA по каждой заявке. Насколько правильно предположение из первого вопроса?
  3. Как и кто должен фиксировать наряды по обращением с кратными работами? Не очень правильно заводить 10 нарядов на 10 ЭЦП. Заводить одно задание с кратностью 10, тоже не совсем верно, так как первые 5 ЭЦП может выпускать один сотрудник, а вторые 5 — другой. Диспетчер при назначении нарядов по заявке знает только количество ЭЦП и рабочую группу, оказывающую услугу по их выпуску. Кто именно будет выполнять работы определит координатор группы, уже получив заявку. И он же, по идее, должен создать нужные наряды на нужных сотрудников?
Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

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

    1. Да, срок выполнения работ зависит от их объёма (кратности), но не строго пропорционально. Дело в том, что у каждой заявки срок складывается из двух составляющих — времени реакции и времени выполнения. Время реакции учитывает очередь заявок, которая препятствует мгновенному взятию новой заявки в работу и почти никогда не бывает нулевой. При кратных заявках время выполнения умножается на фактор объема, но время реакции — нет.

    1. (да, снова 1) Про «когда можно изменять» я бы ответил так: логичнее и удобнее с точки зрения управления работами разрешать изменять фактор объёма до того, как заявка будет взята в работу. Возможно, клиент поймёт это не сразу. Но если таких заявок много и они относительно небольшие (фактор объёма 5-10, а не, скажем 100-200), это точно рабочий вариант.

    2. Ну и пусть. Это право клиента и обязанность поставщика. Замечу в скобках, что из п. 1 следует, что общее время выполнения в этом случае увеличивается, поскольку время реакции умножается на кол-во заявок с фактором объема, равным единице. Так что бороться с таким поведением я бы не стал, тем более, что и клиенту это менее удобно (раз возникла тема кратных заявок).

    3. Да.

    P.S. Однако на определении срока вопросы к такой схеме обслуживания не заканчиваются. У «кратных» заявок при прочих равных усложняется логика взаимодействия с участниками по ходу выполнения и логика закрытия (возможно частичное выполнение — кому-то из 10 сделали, кому-то — нет). И эти вопросы тоже требуют урегулирования. По мне так более сложного, чем в случае сроков обработки.

  • Илья Рунов

    Я бы выделил в обсуждении _сообщение_ планового срока выполнения Заказчику и согласование _метода_ расчета срока выполнения с Заказчиком. С одной стороны, _сообщение_ о плановом должно помогать Заказчику планировать его деятельность. С другой стороны метод расчета планового срока может повлиять на KPI Исполнителя. Если Заявитель одновременно создает заявку(и) на 10 ПК и ожидает, что «одна женщина родит десять детей за девять месяцев», Исполнитель при согласовании SLA будет «закладывать» в «общую длительность выполнения» адский запас. Хорошо бы _согласовать_ с Заказчиком, что каждая дополнительная заявка того же типа и приоритета увеличивает срок на некую норму длительности. С Заказчиком внутри одной компании есть шанс для такого соглашения.

    Я бы предложил учесть факторы при организации обработки заявок с кратными работами:

    • Заявки, где Заявитель, конечный Пользователь и приемщик\оценщик качества работы – «одно лицо» отличаются от заявок, где это – «три разных человека».

    • Категории заявок, где требуется привязывать заявку или наряд к КЕ («ПК») отличаются от заявок на выдачу батарейки для мышки.

    • Категории заявок со стабильно стандартным составом и содержанием работ (условно, «ЭЦП») отличаются от заявок с дополнительными опциями (условно, «ПК»).

    Для примера, «время выполнения» 10 ПК в офисе 5 ПК в офисе + 5 home office ПК с согласованием и организацией удаленного доступа по VPN.

    Для кейса «ЭЦП» + «одно лицо» + «без КЕ» + «без особого содержания работ, без спецификации» Заявителю, Исполнителю, менеджеру удобно иметь одно обращение без заданий\нарядов.

    Для кейса «три разных человека» разумно иметь 10 заявок на 10 «ПК» или 10 заявок на 10 «ЭЦП». Иначе Исполнителю неясно, кому писать для уточнения задачи. Менеджеру и Заявителю не понятен операционный статус. При возврате в работу\плохой оценке сложнее разобраться, устранить корневую причину.

    Для остальных кейсов можно иметь «1 заявку и 10 нарядов» или «10 отдельных заявок», по вкусу.

    Мы можем мотивировать делать отдельные заявки\наряды диспетчера СервисДеск, Заявителя через портал или поручить тупую операцию информационной системе СервисДеск. В зависимости от кратности и нормы «времени выполнения» можем посчитать срок(и) на «выходе» от первой линии однократно или пересчитывать срок(и) в ходе жизненного цикла каждой заявки. Мне более важными кажутся: “P.S.” Дмитрия Евгеньевича, сообщение реалистичного срока выполнения Заказчику, само согласование метода расчета срока выполнения, упомянутые мною выше факторы.

    • Илья Рунов

      Этот текст:

      Для примера, «время выполнения» 10 ПК в офисе 5 ПК в офисе + 5 home office ПК с согласованием и организацией удаленного доступа по VPN.

      Следует читать:

      Для примера, «время выполнения» 10 ПК в офисе «не равно» 5 ПК в офисе + 5 home office ПК с согласованием и организацией удаленного доступа по VPN.

      Знак «не равно», видимо, был удален веб-сервером.

  • Владимир Невский

    Мы тоже думали про ЭТО и планируем ЭТО к внедрению. Согласен с Дмитрием.

    Кратность — назвали коэффициентом трудоемкости, который должны устанавливать диспетчера при оформлении заявки до момента маршрутизации (другие — лица заинтересованные).

    Да, делать наряды по заявке должен координатор, но кратность/трудоемкость тут как бы другая: дело в том, что кратность в заявке будет влиять на время SLA по заявке; трудоемкость в наряде будет влиять только на трудозатраты исполнителя/ей. Т.е. например, в заявке нужно залить 10 ПК: заказчику при оформлении отбивается крайний срок исполнения; если по факту нужно было залить 12 ПК (трудоемкость по нарядам = 12) и в срок SLA не уложились, то в дело должен вступать менеджер, который сможет аргументированно увеличить срок SLA или проставить Признак просрочки времени SLA для отчета в НЕТ, т.е. срок нарушили, но мы не виноваты/нас не за что наказывать. Таких ЕСЛИ порядка 15-20% — это жизнь и это условно нормальная ситуация.

  • Вячеслав

    Полагаю, что любые попытки не параллелить исполнителей и увеличивать сроки могут быть обоснованы только при значительном сокращении норматива на единицу работ зафиксированном в том же SLA. Грубо говоря, так и написать «при выполнении завки с количеством работ 1-5 устанавливается срок N*80%, 5-10 — N*70% и т.п.». Если же заказчик заботится первично о сроках, а не о стоимости, отстраивать инструменты декомпозиции в точке входа и соблюдать золотое правило конвеера «одна заявка — одна единица работ».

    Пы.сы. Вопрос стоимости всегда спорный, чье время дешевле ИТ спеца или автора запроса имеющего простой/деградацию...?


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

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

  • Рубрики

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

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT