Если у Вас был опыт общения с руководителем отдела Service Desk, то наверняка первое, что Вы от него услышали это многочисленные жалобы на жизнь, сотрудников и жестоких клиентов.
Управлять небольшой службой техподдержки из 5 человек еще как-то можно, но когда людей становится больше, а количество обращений в день переваливает за сотню, то жизнь руководителя превращается в ад: постоянные эскалации, перегруженность персонала и почти полная утеря контроля за происходящим.
Просто представьте, что у Вас сотня админов, которых Вы ежедневно обеспечиваете работой (это не выдумка, а реальность).
В этой ситуации надо что-то предпринимать. Тут каждый выкручивается как может – выдумываются многочисленные отмазки, изобретается «стандартизация», клиентов заставляют заполнять невероятных размеров формы с полями, назначение которых невозможно угадать, а при каждом удобном случае обращения скидываются с исполнителя обратно на клиента. На нарушения SLA (плановых сроков исполнения заявок) вообще никто не смотрит. Перечень мер можно продолжать бесконечно.
Проблема не нова и не уникальна – она присутствует на каждом предприятии, в какой бы области оно ни работало. Перепроизводство, перегруженность персонала, проталкивание срочных заказов. Аналогии напрашиваются.
Можно ли с этим что-то сделать? Конечно! Работающие и очень эффективные меры давно известны – это Бережливое производство (Lean Manufacturing) и Теория ограничений (Theory of Constraints, TOC).
Давайте посмотрим как методы и метрики бережливого производства могли бы послужить на благо службы технической поддержки Вашей компании.
Небольшой экскурс в Lean и TOC
Давайте начнем с краткого введения в Теорию Ограничений и Бережливое производство в том небольшом объеме, который необходим для понимания концепции этой статьи.
Если говорить кратко, то Бережливое производство – это философия (набор методик) для сокращения потерь, ускорения производства и его непрерывного совершенствования с целью увеличения прибыли предприятия.
Теория ограничений – это как бы надстройка над Бережливым производством, которая гласит, что в любом производстве есть всего лишь одно единственное узкое место, которое тормозит всё. И скорость всего предприятия в целом равно скорости этого узкого места (бутылочного горлышка).
Бесполезно расширять что-либо еще, кроме бутылочного горлышка – это всё равно ни к чему не приведёт. Именно поэтому локальные оптимизации не работают. И именно поэтому нет смысла утилизировать мощности отделов на 100% - это только вызовет перепроизводство.
А вот увеличение производительности горлышка на X% приведет к увеличению прибыли всего предприятия на X%. А это миллионы, а может и миллиарды!
Это если кратко.
Единственная, но очень важная метрика теории ограничений
В Теории ограничений есть, по сути, единственная метрика, на основе которой принимаются все решения – это Проход (или Проток, Throughput).
Tu= P – TVC,
где Tu – величина прохода на единицу продукции;
P – цена единицы продукции;
TVC – полностью переменные затраты
(https://tocpeople.com/2012/08/upravlenie-predpriyatiem-po-finansovym-pokazatelyam-tos/)
Если грубо, то это операционная прибыль, заложенная в конкретную единицу продукта.
Как это можно использовать?
Давайте рассмотрим известный пример с двумя продуктами. Пусть человек-бутылочное горлышко принимает участие в производстве продуктов А и Б.
Продукт А стоит 300 руб, а продукт Б – 400 руб.
При этом Проход (грубо - Прибыль) продукта А = 100 руб, а у продукта Б = 200 руб
Какие продукты и в каком количестве должен производить человек-бутылочное горлышко, чтобы максимизировать прибыль предприятия (а мы знаем, что именно он определяет всю прибыль предприятия)?
NB. Вы уже провели аналогии с технической поддержкой, категориями обращений пользователей и админами, которые эти обращения выполняют?
Казалось бы, продукт Б стоит дороже и прибыль в нём больше, однако всё не так просто. Для решения уравнения не хватает одной очень важной переменной – времени, которое человек-горлышко затрачивает на производство каждого вида продукта.
Время производства продукта А – 5 мин, продукта Б – 30 мин.
Продукт А: 100 руб / 5 мин = 20 руб / мин
Продукт Б: 200 руб / 30 мин = 6,6 руб / мин
Получается, что при изготовлении продукта А компания получает прибыль в 20 руб/мин, а при изготовлении продукта Б – всего 6,6 руб/мин.
Выбор очевиден, не правда ли? Нужно производить как можно больше продукта А, а в оставшееся время – продукт Б.
Переложение метрики Прохода для технической поддержки
Самое главное сомнение, которое у Вас скорее всего возникнет – в тех поддержке нет прибыли. Совершенно верно.
Дело в том, что Проход может быть не только прибылью. Он может быть чем угодно, что будет являться аналогией прибыли и что будет давать ценность компании и клиенту.
В случае с тех поддержкой несомненной ценностью является количество обращений, отработанных в установленный срок.
Для вычисления метрики могут понадобиться некоторые данные, которые можно извлечь из Вашей системы регистрации обращений в тех поддержку.
Из Jira, например, можно извлечь следующие данные:
· Приоритет задачи
· Категория задачи
· Общее время исполнения (от регистрации до перевода в статус Resolved) с учетом всех дней и выходных. Время исполнения с точки зрения клиента от самого начала до самого конца.
Дополнительно можно вычислить Touch time - время ручной работы админа по каждой задаче. Другими словами время, затраченное администратором на задачу за вычетом выходных, нерабочего времени и нахождения задачи в статусе Need Info (запрос доп информации от клиента).
Если на человеке висело несколько параллельных задач, то Touch time вычисляется по каждой завершенной задаче отдельно, а затем берется 85% персентиль от всего полученного множества.
Персентиль не так чувствителен к выбросам как среднее, поэтому его часто используют в качестве гарантированного значения для какого-либо параметра, в нашем случае Touch time.
В Jira значение Touch time можно вычислить как время между сменами статусов.
Время работы человека-горлышка (или время, затраченное на производства продукта) = Touch time
Проход = количество выполненных задач конкретной категории и приоритета
К прохода = Прибыль / Время работы горлышка
или
К прохода = количество выполненных горлышком задач / Touch time
Наибольшее значение коэффициента говорит о том, какой категории заявок стоит отдавать приоритет, чтобы на выходе из горлышка максимизировать общее количество выполненных заявок.
Вот реальный пример из службы тех поддержки:
Колонка template – Категория задач. Строки упорядочены по убыванию коэффициента прохода.
Таблица даёт много материала для раздумий. Например, видно, что наибольшее влияние на поток оказывают задачи с низким приоритетом. Это сильно противоречит общепринятому восприятию того, что делать надо в первую очередь блокеры и высокий приоритет, и вызывает несогласие и неприятие.
Однако, если подумать нестандартно, то можно прийти к выводу, что раз задач с низким приоритетом так много, то стоит посадить выделенных людей, которые будут заниматься только ими.
Почитайте интересную статью про технологию Swarming в которой есть много подобных нестандартных выводов.
Такую таблицу можно отфильтровать по приоритету задачи, например, блокеру. В этом случае Вы получите категории задач, наиболее влияющие на проход блокеров.
Теперь, когда понятно как быть с задачами, поступающими в бутылочное горлышко, нужно определиться где же это самое горлышко находится.
Поиск бутылочного горлышка техподдержки
В бережливом производстве первым шагом часто производят «картирование» потока создания ценности, т.е. на схеме потока отображают время, затрачиваемое на каждое действие, в том числе отображаю сколько из этого времени затрачено на создание ценности, а сколько на потери и ожидание.
Если просуммировать время создания ценности и соотнести его с общим временем цикла, то можно посчитать эффективность потока:
Эффективность потока = Суммарное время создания ценности / Общее время цикла * 100%
Часто эффективность потока в компаниях не превышает 5-10%.
Каким образом посчитать эффективность потока для задач тех поддержки?
Если Вы используете Jira, то можно считать время между сменой статусов и в качестве времени создания ценности брать время непосредственной работы админа, но это сложно.
Можно использовать метод проще и считать по количеству выполненных задач за период:
Эффективность потока = Кол-во выполненных задач / (Всего задач в работе) * 100%
Соответственно, такую эффективность легко посчитать по каждой категории задач, админу или команде. Т.е. Вы будете точно видеть, где именно у Вас низкая эффективность.
Вот примеры с реальными данными:
Можно отфильтровать данные по наименее эффективным группам и получить эффективность входящих в них админов.
Что обозначает эффективность потока в тех поддержке?
Эффективность потока – это не только подсчет времени потерь. На самом деле это поиск мест, где скапливается «незавершенка» - большое количество задач в работе, которые никак не могут закончится, либо лежат и ждут своей очереди.
Вот пример реальной ситуации по настоящему, не выдуманному админу:
Как видите, ситуация жесткая – он делает всего 4-5 задач в день, а вешают на него аж по 10 штук.
Естественно, о какой эффективности тут может идти речь.
Очень удобно анализировать подобные метрики в Qlik – он позволяет последовательно сужать выборку в разных разрезах. Например, сначала выбирается категория обращений с максимальным количество незавершенного производства, затем, в её рамках, группа админов, а затем становится понятным кто из админов выбранной группы имеет наибольшую незавершенку. Таким образом можно добраться до конкретного человека и конкретной выполняемой им операции.
Как видите, метрики бережливого производства с помощью коэффициента эффективности потока, потенциально позволяют Вам обнаружить бутылочное горлышко весьма простым путем.
А если посчитать Touch time и коэффициент прохода, то можно еще и расставить приоритеты исполнения обращений, приходящих в бутылочное горлышко.
Т.е. метрики бережливого производства действительно могут помочь с налаживанием дел в технической поддержки.
Что делать со всеми этими метриками?
Улучшать, конечно. С помощью Kaizen – непрерывного совершенствования. В низкой эффективность виноваты не люди – виновата система. И её надо перестраивать.
Т.е. нужно находить корневую причину проблемы (истинную причину, а не лежащую на поверхности) и устранять её. И так поступать с каждой проблемой.
Вот хороший пример как в Службе Service Desk использовали Lean (бережливый подход) и что из этого получилось.
Смотрите: допустим Вы с помощью метрик обнаружили, где в тех поддержке есть узкое место. Идите туда и смотрите на месте, что происходит (т.н. «гемба»). Увидеть проблему не сложно. Надо просто наблюдать и разделять действия на потери и создание ценности, а также анализировать каждое действие в глубину до тех пор, пока не наступит кристальная ясность и понимание, что ниже больше ничего нет.
Зуб даю, что первое, что Вы увидите в тех поддержке - это то, что админы (/сотрудники тех поддержки) делают по десятку задач одновременно (см. график выше). Вы наверняка на себе испытали как это работает:
Клиент оставляет обращение, оно назначается на админа, а тот быстро-быстро что-то отвечает и мгновенно переводит задачу обратно с целью получения доп информации, либо переводит задачу на какого-то другого человека. И всё потому, что ему некогда ждать пока клиент ответит – ему нужно сделать сегодня еще кучу задач.
Как результат, админ целый день занимается тем, что старается как можно быстрее снять с себя поступающие задачи и перевести их на клиента, а в итоге не делает ничего, либо делает чрезвычайно медленно. Типичная проблема многозадачности.
А почему у админа много задач? Корневой причиной является распространенная ложная установка. Руководство считает, что ресурсы надо утилизировать на 100%, чтобы они не простаивали. Поэтому и загружает админа задачами. Но на самом деле это заблуждение, вызывающее огромные проблемы.
При однозадачности задачи выполняются в разы быстрее, чем при многозадачности:
Решить проблему можно. Теория ограничений для этого случая говорит:
· Расширьте бутылочное горлышко
· Подчините ему всё производство
Расширение горлышка обозначает, что админы не должно заниматься ничем иным, кроме действий, создающих ценность. И между этими действиями не должно быть перерывов. Т.е. надо сделать так, чтоб у админа не было шанса перевести задачу на кого-либо. На момент старта работы он должен быть полностью обеспечен всей необходимой информацией.
Простая перестройка процесса позволит админу выполнять только одну задачу за раз. Это может увеличить его производительность в разы:
Вариантов решений множество.
Помните, что этот админ-бутылочное горлышко, по сути, является первопричиной того, с какой скоростью и качеством Ваша служба технической поддержки обрабатывает запросы. Думайте в числах прохода. Если найм или выделение помощника этому админу увеличит проход в 5 или 10 раз, разве это не стоит того?
Возьмите одного админа-бутылочное горлышко, определите его проблему, найдите корневые причины и устраните их. Расширьте его мощность и увеличьте таким образом проход.
А на этом всё.
NB. Все выводы в этой статье сделаны на основе наблюдений за реальным отделом технической поддержки большой компании.
Автор статьи надеется, что смог показать другую точку зрения на привычные процессы и зародил в читателе зерно сомнения и инакомыслия.
Ваши комментарии он с удовольствием прочитает и ответит на них.
