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

Вопрос из зала: Количество единиц службы поддержки

Опубликовано 21 марта 2012
Рубрики: Service Desk, Вопрос из зала, Всё это - ЛЮДИ, Измерение и оценка ИТ, Управление инцидентами, Эксплуатация ИТ
Комментарии

Сергей задаёт вопрос:

Хотелось бы обсудить следующую задачу:

Пусть мы имеем систему, которую используют 20 предприятий, общее количество пользователей 500, пусть на одном из предприятий 40 пользователей. Пусть система обслуживается с 9 до 18, время реакции 1 час, время закрытия типовой заявки на обслуживание 4 часа.

Вопросы:

1 какой инфориации не хватает, чтобы можно было рассчитать количество единиц службы поддержки (КЕСП)

2. Как изменится КЕСП если указанное предприятие попросит уменьшить время реакции до 0,5 часа

И общий вопрос — используются ли в практике управления услугами методы теории массового обслуживания?

Спасибо.

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

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

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

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

    1. Если под единицами службы поддержки Вы понимаете её сотрудников, то не хватает следующей информации:
    а) состав вопросов к службе поддержки, зависимость службы поддержки от других внутренних групп и внешних поставщиков, наши возможности по влиянию на внутренние группы и внешних поставщиков (поскольку время решения обеспечивается всеми линиями поддержки);
    б) функции, возложенные (или которые можно возложить) на СП, что может определяться квалификацией сотрудников СП, техническими возможностями, полномочиями;
    в) география объектов обслуживания;
    г) определение времени реакции (в отличие от времени решения, под этим часто понимаются абсолютно разные вещи – от отправки пользователю отбивки о регистрации обращения до прибытия на площадку клиента), т.е. ответ на вопрос “что именно нужно обеспечить за 1 час времени реакции?”;
    д) каналы поступления информации в СП и их возможности (АТС, мониторинг, средства удалённого управления рабочими столами, …)
    2. См. вопрос 1.г.
    Общий вопрос: разумеется, правда обычно на бОльших объёмах.

  • Pavel Solopov

    Не хватает информации об объёме входящих заявок и средней трудоёмкости выполнения заявок (4 часа это крайний срок или трудоёмкость?).
    Тогда по Эрланг C можно будет посчитать необходимое количество специалистов.

    Как изменится надо смотреть из модели, может и никак не изменится.

    Я когда-то разрабатывал целую методику расчёта “справедливой цены ИТ-услуги”, которая базировалась на теории массового обслуживания.
    Большого интереса у заказчика она не вызвала, о других случаях практического использования мне не известно.

    Как справедливо отметил Дмитрий, точность методов ТМО тем выше, чем больше объёмы входящих заявок.

  • Сергей

    Спасибо за комментарии.
    Честно говоря, задачка приведена для старта обсуждения, на самом деле хочется решить более общую — переоткрыть в 100-й раз “методику расчёта «справедливой цены ИТ-услуги»”, возможно, убедившись, как и Павел, что для реальных задач она не применима.
    Проблема в том, что договора на сопровождение мы как положено современной сервисной организации заключаем с указанием уровней услуг, согласующие эти договора представители заказчика высказывают свои пожелания тоже в терминах корректировки услуг, а вот перевести этот язык на язык бюджета (если сократить время реакции, то стоимость возрастет на…) не умеем.А финансисты считают по простой формуле — от количества пользователей. В доступной мне литературе об этом как-то тоже ни слова. Кроме — ТМО. Но, как сказно выше, “Большого интереса у заказчика она не вызвала…” Или есть другие методики, удовлетворяющие заказчика?

    • Pavel Solopov

      Вы мух с котлетами не мешайте. 🙂
      Финаснсисты вполне справедливо считают исходя из количества пользователей, но такое прииближение справедливо, если временные ограничения сохраняются постоянными и если количество обращений пропорционально количеству пользователей (такое допущение справедливо не для всех услуг).
      Эрланг C вам замечательно поможет посчитать, как скажется изменение крайних сроков на количестве необходимых сотрудников поддержки, которые с необходимой вероятностью смогут в эти сроки уложиться (надо сразу понимать, что здесь всё построено на вероятности).
      Для применения Эрланг С вам надо знать трудозатраты по единичному запросу, и количество запросов в единицу времени (здесь надо быть внимательным, формула Эрланг С оперирует с секундами, вам придёться нормализовать единицы времени, иначе можете получить ошибку), если у вас нагрузка не равномерная, то можете рассматривать количество обращений только в пиковые моменты.

      В моём случае у заказчика была иная проблема, они хотели получить как раз нормы времени на выполнение операций. что в вашем случае значит «Большого интереса у заказчика она не вызвала…», я не понял.
      Вам надо финансистам объяснить как считать или заказчикам?

      • Сергей

        Павел, спасибо!
        Постараюсь не валить все в одну кучу.
        1. Финансисты считают как согласовано с заказчиком, т.е. для изменения методики расчета объяснять надо вначале заказчикам, а потом финансистам.
        2. Для обоснования иной, кроме подушевой, методики расчета стоимости основываться надо на СМО и, в частности, использовать формулы Эрланга. При этом, в расчете надо учитывать все те (но и не только их, похоже) параметры, о которых у меня спрашивали Вы и Дмитрий.
        Спасибо, ушел думать. Если получу что-нибудь годное — отчитаюсь.

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

          Сергей, Павел, а Вы не преувеличиваете роль формулы Эрланга С? Это формула определения количества агентов call-centr’а, она ничего не знает ни про функциональную эскалацию, ни про время решения. Она знает только про время обработки на первой линии. Как я писал выше “время решения обеспечивается всеми линиями поддержки”.

          • Pavel Solopov

            За Сергея не отвечу. А я не преувеличиваю. 🙂
            Во-первых, Эрланг С это не расчёт числа операторов колцентра, это расчёт необходимого числа автоматов для обработки входного потока запросов с очередью.
            В качестве автоматов могут рассматриваться как сотрудники колцента, так и сотрудники любой из линий поддержки. А поток запросов может быть как от пользователя к первой линии, так от первой линии на вторую, так и от системы мониторинга.
            Во-вторых, я из постановки задачи сделал для себя вывод, что поддержка у нас в одну линию. Т.е. кто заявки принимает, тот на них реагирует, тот их и исполняет (хотя возможно погорячился).
            В-третьих, применение Эрланг С “в лоб”, действительно, не самый верный способ, даже если у нас одна линия у нас есть два SLA – время реакции и вермя решения. Модель придёться несколько усложнить, но не надо увлекаться постройка идеальной модели может не окупиться.
            И конечно же придёться задатсья некоторыми допущениями. Например, если у нас всё же две линии, то тогда для первой линии допустимое время ожидания в очереди будет 1 час-трудоёмкость операций реагирования, а для второй 4 часа – 1 час – трудоёмкость операций исполнения.
            Если 4 часа общее время исполнения заявки.

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

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

              Хм. При нескольких группах L2, при ненулевом уровне FLR на таком потоке обращений ТМО окончательно теряет смысл. Например, при 500 пользователях и графике 5×9 получаем поток порядка 40-60 обращений в день. То есть применение Эрланга даже для L1 вызывает вопрос, речь идёт об 1-2 операторах. Далее, при FLR 30% и трёх группах L2 при равномерном распределение обращений имеем в среднем на одну группу L2 не более 15 обращений в день. Паша, какой Эрланг? Это как применять статфизику к коллективу из 10^2 частиц 🙂

              • Сергей

                Да, речь идет о системах с количеством пользователей от нескольких сотен до нескольких тысяч, со службой поддержки, сопровождающей одновременно 3-7 систем…
                Перечитал. Может экономисты правы, используя только один параметр? 🙂

                • Pavel Solopov

                  Может экономисты правы, используя только один параметр?

                  Экономисты правы в том случае, если:
                  1. Все пользователи имеют похожие требования, т.е. 3 пользователя пораждают 6 запросов, а 6 будут порождать 12.
                  2. Не предполагается изменение требований к качеству. Т.е. трудоёмкость и предельное время решения заявок остаются прежними.

                • Pavel Solopov

                  Где вы это прочли? Эрланг используют и для расчёта менее нагруженных систем. Просто нужно скорректировать временные интервалы.
                  Собственно нагрузку принято считать в тех же самых Эрлангах. И она зависит не только от количества входящих запросов, но и от продолжительности их нахождения в системе (в нашем случае – трудоёмкости).

              • Pavel Solopov

                Ну не так всё мрачно, Дим.
                Критикуешь, предлагай, как говорится.

                Всё зависит от того, какой брать интервал анализа. Если брать нагрузку в час, то окнечно ерунда выйдет. Но ведь и трудоёмкость выполнения запросов может составлять несколько часов. Давайте, допустим, возьмём, нагрузку на вторую линию в 15 заявок в день, при этом средняя трудоёмкость одной заявки пусть будет 1,5 часа. А максимальное время, отведённое на заявку 3 часа. Считаем совокупную мощность входного потока за день: 15*1,5 = 22,5 часа. При рабочем времени одного специалиста в 8 часов, получаем 22,5/8 ~ 3 человека (другими словами Эрланга).
                Но такой расчёт не учитывает требования по конечному времени ожидания и случайному характеру возникновения входящих запросов. Учесть это нам поможет как раз, тот самый Эрланг С.
                Я тут быренько качнул библиотеку формул для экселя и сделал небольшой калькулятор. По результатам моего калькулятора:
                чтобы с вероятностью 90%
                решить 15 заявок в день
                не более чем за 3 часа
                при трудоёмкости каждой заявки 1.5 часа

                потребуется 5 человек.
                В общем, где-то похоже на правду, как я считаю.

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

                  1. В расчёте сделано неявное предположение, что L2 состоит из специалистов, которые занимаются только устранением инцидентов (что редко бывает правдой).
                  2. Если рассматривать трудозатраты на решение одного обращения как случайную величину (со средним 1,5 ч), то у неё будет очень большая дисперсия. Она в предложенных 90% не учтена (там, насколько я помню, учитывается неравномерность поступления, а не дисперсия времени обработки).
                  3. И главное. Для приведённого расчёта Эрланг совсем не нужен. То же самое, только без вероятности, можно посчитать гораздо проще (собственно, что Вы и сделали, получив цифру 3). А процент вероятности с учётом замечания 2 всё равно неверен. Так зачем усложнять оценочный расчёт Эрлангом, если его точность при этом всё равно не повысить? 🙂

                  • Pavel Solopov

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

                    Аналогичным образом можно учесть занятость L2 в каких-то иных задачах.

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

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

                      “Если у вас трудозатраты случайная величина с огромной дисперсией, то вы не бизнесом занимаетесь, а в кости играете”

                      1. ТМО – суть специализированное применение теории вероятности. Выбрасываем? Бизнес на этом не построить?
                      2. Большая дисперсия будет не из-за того, что мы не представляем, какими запросами управляем, а из-за того, что существует большое количество разных запросов, со сроками выполнения от нескольких минут до нескольких дней. Более того, запросов, в выполнении которых будут участвовать несколько групп (последовательно или параллельно). Кости здесь не причём.
                      3. Эрланг С применим к обработке большого количества запросов. Именно такая картина обеспечивает усреднение **** входного потока и разное время обработки отдельных запросов. Именно по этому – это теория _массового_ обслуживания. У каждой теории есть границы применимости, у ТМО – в том числе.
                      4. Классический Эрланг С, по которому Вы считаете, работает с отклонениями от среднего, как со случайной погрешностью. Это значит: а) чем больше отклонения (дисперсия), тем ниже точность и б) не учитывается систематическая погрешность (например, повторяемые **** плотности потока по времени суток). Учёт систематической погрешности ввести можно, если сделать предположение о её характере и найти подходящую математику, но xls-калькуляторы Эрланга, в большом количестве распространённые в Сети, этого делать не умеют.

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

                      **** в моём тексте означают нецензурное слово “к о л е б а н и й”.

                    • Pavel Solopov

                      “Для первой линии — простая формула”
                      По этой формуле вы посчитаете только то количество человек, которые в притык за день разгребут все входящие. Без учёта каких-либо SLA.

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

                      Во-первых, почему в притык? Операнды T и k могут дать Вам нужный запас.
                      Во-вторых, про SLA: всё очень зависит от того, какой SLA. Если только время обработки на первой линии – учту в T. Если более комплексный, например, также будет включать в себя FLR, то это и Эрланг не учтёт.
                      В-третьих, удлиннением периода выборки, Вы ничего не добьётесь. Если мы говорим о нескольких десятках агентов, Эрланг позволит посчитать аккуратнее, чем предложенная мной формула, она будет слишком груба. Если счёт идёт на 1-2-3 человека, округлением до ближайшего целого Вы мгновенно перекроете всю точность Эрланга 🙂
                      Всё, это последняя попытка, устал уже спорить. Никак не могу взять в толк, зачем микроскопом гвозди заколачивать… Но в конце концов … можно ведь заколотить.

                    • Pavel Solopov

                      Ну если всё, что сложнее простейших арифметических операций это уже микроскоп (всё чаще убеждаюсь, что для многих Итишников это так), то сдаюсь. Действительно, зачем бедных менеджеров измождать расчётами, они же ИТ-ишники, а ИТ, это почти магия – заветный бубен занимает на стене почётное место.

                    • Pavel Solopov

                      Дмитрий, ну так а альтернатива-то какая? Как посчитать? Эмпирически или методом проб и ошибок? Какие предложения?
                      Или задача не решима и не решаема?

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

                      Как это нерешаема? Вы же сами посчитали выше потребность в людях и без всякого Эрланга. Для первой линии – простая формула: N * T / (k * D), где:
                      N – количество обращений
                      T – среднее время обработки одного обращения
                      k – коэффициент утилизации (0,7-0,8)
                      D – длительность рабочей смены, мин.

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

                      Плюс график смен, условия ТК.

                    • Pavel Solopov

                      1. Ключевым была “огромная дисперсия”, т.е. неопределённость стремящаяся к бесконечности. Тут не теория вероятности нужна, а теория невероятности. 🙂
                      2. При некоторых допущениях всё можно промоделировать. Можно разные запросы разделить на отдельные потоки и обсчитывать их самостоятельно, можно посчитать средневзвешенную трудоёмкость заявки. Можно смоделировать и последовательные и параллельные работы (если их доля существена).
                      Это если говорить о применении вообще, а в конркетном случае Сергея, может быть пойдёт и обычный Эрланг С. Он нам дополнительных вводных не дал.
                      3. Так берите не день, берите месяц, будет у вас более мощный поток входящих запросов. Вообще если запросов мало, то потребность в персонале можно и чисто эмпирически вычислить. А если такой вопрос возник, то значит поток уже не помещается в “оценке на глаз”.
                      4. про десперсию я сказал выше. На п.б тоже есть решение, рассматривать только моменты пиковой нагрузки. Эти расчёты можно делать за рамками формулы Эрланга. Хотя можно конечно и достаточно сложную формулу самому написать. Конечно же по умолчанию калькулятор Эрланга это не считает. Надо просто подготовить для него данные. 🙂

                      P.S. Я кстати не готовым калькулятором пользуюсь, а аддоном, который добавляет в экселевские формулы несколько формул Эрланга и вытекающих из них.

  • Сергей

    Я планирую, как и написал, попробовать использовать для расчетов СМО, как одну из формул СМО используя формулу Эрланга, понимая ее ограничения. Конечно, полный расчет службы сопровождения сложнее, чем только пересчет по Эрлангу на основе параметров потока заявок и длительности обработки одной заявки.

  • Роман Журавлёв

    Обалдеть. Читается, как детектив. Improbability drive, высшая математика, СМО и ТМО. Скотту Адамсу и не снилось, честное слово.

    Ветку “задать вопрос” придется открывать новую, но для такого дела не жалко. С нетерпением ждем результатов экспериментов Сергея на людях.

  • Сергей

    Да… Пожалуй, теперь не отвертеться, придется дожимать тему до конца. Пока обложился теор. вером, тряхнул, что называется, стариной. Спасибо за комментарии, прочистил (загрузил) мозг.
    Пока идем “от услуг” — провели декомпозицию стандартных услуг по двум системам, обрабатываем имеющуюся статистику
    Результаты обязательно представлю на суд общественности.

    • Сергей Зайцев

      Общественность хотела бы все-таки взглянуть на результаты.

      • Сергей

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

        Понятно, что первое (сбор статистики) и последнее (продавливать решения) идут особенно тяжело.

         

      • Олег Скрынник

        Вот это да! Спустя ДВА ГОДА!!!

        Сильно.

        Сергей и Сергей, вы потрясли до глубины души.

        Респект.

         

    • Александр

      Коллеги, добрый день!
      Спустя 5 лет ситуация не изменилась?

  • Сергей

    Добрый день. Коллеги так есть все таки примерно универсальная формула иди методика расчета сотрудников сопровождения ИТ L2?
    По опыту скажу, что мы каждый раз при расширении штата собираем статистику текущей загрузки сотрудников, показываем риски финансовых потерь, если не сможем принять функционал в сопровождение и т.д.
    Затем специальные люди в управлении персоналом, решают, дать нам запрашиваемое количество ставок или нет, и дают на свое усмотрение.
    Как правило меньше чем просим и без возможности ввести сразу все ставки в ШР.

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

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

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