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

Разрушители легенд: польза автоназначений

Речь идёт об автоматическом распределении работ (в виде заявок пользователей, заданий и так далее) по различным группам и специалистам. Как обычно, пост создан по следам недавних дискуссий с заказчиками. Мой тезис прост – не все автоназначения, как и йогурты, одинаково полезны. То есть всё не так однозначно. Чтобы разобраться, начать надо со следующего: большинство продуктов различают два вида назначений – на группы и на специалистов (персональные назначения в пределах групп).

С назначениями на группы по-моему всё просто. Большинство продуктов умеют выполнять назначение на группы автоматически. По различным критериям – классификация обращения / задания, заказчик, регион и так далее. Мне кажется, это полезный механизм – он помогает сократить время обработки за счёт сокращения ошибок при выборе ответственной группы. Сокращаются также и непроизводственные трудозатраты, поскольку специалистам «на вход» попадает меньше непрофильных задач.

А вот с персональными назначениями в пределах группы всё сложнее. Для автоматизации персональных назначений обычно используется один из трёх алгоритмов (или их комбинация):

  1. Циклический (round-robin). Задачи назначаются на членов группы по очереди: Пете, Диме, Васе, Пете, Диме, Васе и так далее.
  2. Выравнивание нагрузки. Задачи распределяются так, чтобы на каждом члене группы было одинаковое число открытых задач. То есть если на мне «висит» 5 задач, а на моём коллеге 6, новая задача будет назначена мне (не зависимо от очерёдности).
  3. Профилирование нагрузки. Задачи распределяются так, чтобы количество открытых задач на каждом члене группы было пропорционально некоторым весам (например, отражающим уровень компетенции или целевой уровень загрузки оперативными задачами). Так, если на мне «висит» 5 задач и мой весовой коэффициент 1, а на моём коллеге «висит» 6 задач и его весовой коэффициент 2, новая задача будет назначена моему коллеге (не зависимо от очерёдности).

Вроде бы звучит привлекательно. Но рассмотрим, к каким минусам приводит автоматическое назначение на специалиста в пределах группы:

  1. Ни один из приведённых алгоритмов не принимает во внимание сложность задачи. Тот факт, что на мне 2 задачи, а на моём коллеге 5, ещё не означает, что я быстрее освобожусь или меньше загружен. Это существенно зависит от задач.
  2. Все приведённые алгоритмы существенно зависят от точности учёта недоступности специалистов (ведь если специалист недоступен, оперативность реакции на назначенные задачи будет низкой). И если с длительными отсутствиями (отпуск, командировка, болезнь) это вопрос вполне решаем, то с кратковременным отсутствием (визит к заказчику, совещание, обед) всё гораздо хуже.
  3. Циклический алгоритм, помимо минусов 1-2, абсолютно игнорирует различия в компетенции персонала.
  4. Алгоритмы с выравниванием и профилированием нагрузки, помимо минусов 1-2, узаконивают процветание принципа «дурака работа любит». Чем быстрее вы выполняете работу, тем больше вас будут грузить. И пусть ваши коллеги отдохнут.

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

На мой взгляд, распределение задач между членами группы – обязанность руководителя и неотъемлемая часть его работы. Это совсем не значит, что он будет вручную распределять все задачи. Это значит, что он должен так организовать работу, чтобы они распределялись правильно (для этого есть вполне отработанные подходы). Более того, разумное участие линейного менеджера в распределении задач – необходимая мера для совмещения оперативной работы с плановой / проектной работой. Стимулировать линейного менеджера выполнять свою работу в данном случае также достаточно просто – достаточно включить в оценку его работы метрики по своевременной реакции на поступающие задачи и их своевременному выполнению.

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

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

  • Добавлю к уязвимостям автоназначения на специалистов: оно предполагает, что 100% работ специалистов учитываются в той же системе. На практике это далеко не всегда так, и выполнение “других” работ попадает в категорию кратко- или долговременного отсутствия.

    • Отличное дополнение, спасибо.

    • Я бы даже переформулировал – это практически всегда НЕ так.

    • Георгий

      Рома, отличное дополнение. Его вообще нужно ОЧЕНЬ часто помнить 🙂 и при автоназначениях, и при вопросах с приоритетами и еще часто когда 🙂

      Однако, есть примеры, когда 100% работы учитываются в единой системе (или совокупности систем, зависит от реализации), лично видел, внедрял, развивал

  • Интересно. По этому вопросу у меня, кстати, нет сформировавшегося мнения.

  • >”На мой взгляд, распределение задач между членами группы – обязанность руководителя и неотъемлемая часть его работы.”

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

  • Автоназначение на исполнителя является самым популярным требованием к автоматизации у руководителей следующих групп:

    1) Эникейщики.
    2) Сотрудники выделенные для поддержки специализированных информационных систем.
    3) Сотрудники службы Service Desk.

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

    При этом, как правило, приходится докуручивать систему автоматизации, с целью нейтрализации указанных рисков и дополнительного контроля.

    В остальном согласен, автоназначение на исполнителя не панацея от всех болезней. Более того чаще данная автоматизация вредит больше, чем помогает 🙂

    • “1) Эникейщики.”
      Очень часто отсутствуют на рабочем месте, т.е. попадаем в проблему №2.

      “2) Сотрудники выделенные для поддержки специализированных информационных систем.”
      Все проблемы 1-4. И разница в компетенции, и разница в задачах, и регулярное отсутствие на рабочих местах.

      “3) Сотрудники службы Service Desk.”
      Только в случае наличия в составе Service Desk профильных групп. Вообще, довольно редкая ситуация.

      “… автоназначение выглядит оправданным. т.к. значительно экономит время руководителя”
      Это миф. Приведите пример, как конкретно автоназначение может “значительно” сэкономить время руководителя.

      • Дмитрий, самый яркий пример, это внедрение SAP в двух крупных компаниях. Сценарий в целом был одинаковый, за исключением нюансов.

        Так вот, представьте поток в 200 заявок по SAP в день, и все эти заявки летят на одного руководителя, который направляет их дальше по своей группе (as is).

        При этом:

        1) Доступность консультантов четко регламентирована и контролируется через приложение оператора. (Минус проблема 2)

        2) Группа консультантов САП, это сотрудники с одним уровнем компетенций. Всё что выходит за рамки данной компетенции, уходит на третью линию разработчиков. ( Минус проблема 3)

        3) Для сотрудников разработаны KPI характеризующие их работу. (Минус проблема 4)

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

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

        Это реальный пример, думаю при желании можно придумать ещё десяток не реальных…

        • Ну это действительно шикарный пример. Во-первых, он очень ясно демонстрирует, что решение – не в автоназначении, а в целом ряде организационных мер (собственно, Ваши пункты 1-3). Без них автоназначение не поможет. И, наконец, во-вторых, уберите отсюда автоназначение и включите обычный принцип “свободная касса” (разумеется, Ваши организационные пункты 1-3 остаются). И все.

          То есть проблема-то на самом деле решалась не автоназначением, а руководителем группы 2-й линии по SAP 🙂

          • Дмитрий, согласен.

            Собственно я и пытаюсь донести, что при ряде допущений автоназначение может быть полезной опцией, не более того 🙂

        • Ну и в довесок, для наглядности: а теперь уберите пункты 1-3 и включите автоназначение. Что получится? 😀

  • Федулов Кирилл

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

    • Федулов Кирилл

      Я безлик! Аватарка не подгрузилась! О_о

      • Какой кошмар.

        Оно подтягивается если email, указанный на http://www.gravatar.com, и здесь на портале, одинаковы.

        Верно ведь?

        • Кирилл Федулов

          Я уже это понял, просто с домашнего “зверя” в браузере на данном портале по умолчанию подставляется другой e-mail. Кстати, можно тереть оффтопик 🙂

  • “В целом же, я полностью с Вами согласен (помятуя предыдущую оплошность)”

    +1. Дима, я тоже согласен. Памятуя. Отличная тема на этот раз. Единодушная. 🙂

    • Николай

      Вот ещё, не дождётесь единодушия! 🙂

      Утверждение Дмитрия “распределение задач между членами группы – обязанность руководителя и неотъемлемая часть его работы” в случае распределения _потока_ работ считаю неправильным и вредным. Оно превращает руководителя в узкое место (bottleneck, SPoF). См. ниже -“Руководитель также может отсутствовать на рабочем месте, и зам его то же. И что ж работа встанет?” – подписуюсь.
      Другое дело, что выход не всегда в автоматизации. Распределять заявки может отдельная роль – например, координатор service desk.

      • Николай, а я совсем и не утверждал, что он будет сам распределять задачи. Его обязанность – организовать разбор задач. Силами подчинённого диспетчера, по правилу “свободная касса” – как угодно. Если он будет распределять все задачи лично, это вызывает у меня сомнение в том, что этот человек – руководитель.

        Собственно это написано в тексте поста. “На мой взгляд, распределение задач между членами группы – обязанность руководителя и неотъемлемая часть его работы. Это совсем не значит, что он будет вручную распределять все задачи. Это значит, что он должен так организовать работу, чтобы они распределялись правильно (для этого есть вполне отработанные подходы).” Не читали? 😉

        • Николай

          Читал, просто в тексте поста одна фраза не бътся со следующей 🙂

          Отлично, значит лично распределять не должен. Таким образом его обязанность – не “распределение задач”, а “организация распределения задач”.

          А какие тогда есть ещё “отработанные подходы”? Помимо “свободной кассы”, работающей как уже сказано далеко не во всякой культуре?

          И еще, чтоб мне больше не мерещилась вовлеченность руководителя в рутину – что обозначает фраза: “…разумное участие линейного менеджера в распределении задач – необходимая мера…”? Спасибо 🙂

          • “А какие тогда есть ещё «отработанные подходы»?”

            Помимо свободной кассы есть назначение диспетчера (или группы), дежурство по скользящему графику, распределение по типам задач (например, по территориям, по видам клиентов, по приложениям, …). Наверняка я вспомнил не все.

            “разумное участие линейного менеджера в распределении задач”

            В моём понимании – определение правил игры и контроль их исполнения. С минимальным вовлечением в оперативную работу.

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

            Вообще, это большая тема (сам чувствую – несёт, но не могу остановиться). В силу понятных причин у нас в стране всё как-то больше строят вертикали власти, а не вертикали управления. Это сказывается. И в малом масштабе (организация), и в большом масштабе (страна).

            • Николай

              Спасибо, примеры хорошие.

              И хотя тоже понимаю, что “несёт”, не могу удержаться – “…у нас в стране всё как-то больше строят вертикали власти, а не вертикали управления.” Да, наверно это так, и это “увы”. Но самое страшное, что думают только про те или иные _вертикали_, хотя для организации деятельности есть и collaboration, и networking… вот только “всех этих слов на русском нет” 🙁

  • Анатолий Павлюченко

    Не буду выдавать идею за свою, это идея Заказчика. Я вначале, как раз, сильно возражал.

    В предпоследнем абзаце автора поста упоминается метрика “своевременной реакции на поступающие задачи и их своевременному выполнению.” Вот о втором упоминании “своевременности” и хочу рассказать.
    Так вот, логическим завершением для автоназначений хоть на группу, хоть на роль в пределах группы был предложен триггер эскалации на того самого “линейного менеджера”. Срабатывать триггер должен при достижении 75% времени, отведенного на выполнение работы. Время на выполнение работ взято из контрактов на поддержку.
    Основная идея – автоматическая эскалация (или уведомление) вне зависимости от наличия или отсутствия специалистов, их загруженности или сложности задач. Это и есть пример упоминаемых здесь “организационных мер”. Внутри там ещё есть триггеры по времени для автоматического перехода между уровнями (линиями) службы поддержки.
    На всякий случай скажу и для поддержки “единодушия” скажу, что мой пост не “против”, а “за”. Это просто вариант выхода из цикла внутри группы.

    • Если я правильно понял то, что написано, то это стандартная практика в рамках любого проекта по поддержке. Идея – народная (поскольку автора уже не идентифицировать). Музыка и слова – тоже 🙂

  • Андрей Радосельский

    Руководитель также может отсутствовать на рабочем месте, и зам его то же. И что ж работа встанет?

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

    Посмотрите на макдональдс – как только тикет выполнен, сразу – “Свободная касса!”

    Ну или такой вид костыля для автоназначения. Если специалист считает что он готов взять новую заявку на себя он жмакает кнопку “взять новый запрос” и ему из пула дает заявку по какому-то алгоритму.

    • +1. Об этом и писал выше.

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

      • Андрей Радосельский

        Или так. Да, я то же встречал такое мнение. Что дескать руководителю группы виднее и ясно, что Вася умный, а Петя не очень -)
        Я бы ответил так:
        1. В группе не должно быть разноуровневости компетенцией. В данном контексте группа рассматривается не как не организационное образование согласно штатному расписанию. И если в группе есть “хромая лошадь” то это вопрос к руководителю, зачем ее держать?
        Также я бы сказал,что инцидент как раз и должен назначается одному человеку. И кстати, про темную сторону силы, – постоянный срыв сроков исполнения инцидентов является хорошим поводом ОБОСНОВАНО избавится от “тормоза”

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

        2. Именно. Кота в мешке. Это чтобы самые умные не подгадывали себе легкие заявки -)

    • Георгий

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

      А в общем мысль очень правильная, поддерживаю

      • Что подтверждает мои выводы о том, что первичной задачей при использовании ITIL для постановки процессов Сервисной службы является адаптация концепции под конкретный случай. То, что работоспособно в одном случае будет практически неосуществимо в другом.

        • Георгий

          Дмитрий, я не рулю этим форумом, но за пост про первичность адаптации концепций из книжек к реальности при внедрении ITSM – я бы честно присвоил вам внеочередное звание Капитана! 😀

          • Я не настолько долго “варюсь” в данной тематике, чтобы подобные выводы стали для меня очевидностью. К сожалению, практического руководства для “юного внедряльщика” мне не встретилось и до всего пришлось доходить самостоятельно.

            А вообще, я просто согласился с вашей мыслью =)

            • Георгий

              🙂 ответное туше принято )))


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM