Сложная техническая поддержка: часть вторая. Канбан и Тимлид

Меня зовут Кравчик Юрий, я директор и соучредитель компании «Интерра» — оператора ГЛОНАСС мониторинга транспорта и других подвижных и не очень объектов. По сути, это кусок IoT, который появился значительно раньше, чем IoT.

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

Итак в первой части заметки я рассказал вводные данные и начало эволюции.

Теперь продолжим. Итак 7 человек в отделе технической поддержки. Техническая поддержка обеспечивает несколько плоскостей деятельности оператора ГЛОНАСС IoT

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

2. Внутренняя активность. Это заявки типа: внутреннее обучение, подготовка оборудования (прошивка, проверка, настройка, заведение в облако)

3. ТимЛид - контроль, координация, командная активность

4. Дежурство по приемке выездных работ.

5. Внутренний тренер и внутренние тренинги

Все эти функции распределяются в расписании работы отдела на месяц вперед. Каждый день есть один дежурный по приемке выездных работ, каждую неделю есть ТимЛид (передаваемая должность). Каждый день кто-то один работает с 11-00 до 20-00. Кроме того в расписании учтена работа в субботу и воскресенье с 9 до 18-00

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

К цифрам.

Каждый день отдел технической поддержки обрабатывает около 60 заявок (инцидентов).

Каналы поступления инцидентов: 10% открытые линии непосредственные диалоги из интерфейса основной программной платформы, 20% входящие телефонные звонки, 30% по электронной почте, 10% из разработанного специализированного кабинета Абонента, 20% от отдела продаж и сектора сопровождения абонентов, 10% сгенерированы сотрудниками отдела ТП.

Мы понимаем, что одним из эффективных способов работы технической поддержки является туннелирование каналов поступления заявок и мы находимся в процесс перетягивания заявок на сторону разработанного нами программного интерфейса "Кабинет Абонента".

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

Еще о нововведениях. В 2018 году мы добавили в расписание функции тимлида. Каждую неделю один из сотрудников отдала ТП (по очерееди) становится ТимЛидом. Основные функции которого координировать работу отдела, проверять активность и загруженность, помогать равномерно распределять заявки, подключаться на сложные заявки, контролировать полноту соблюдения регламентов, задавать темп. ТимЛид участвует по всех совещаниях и планерках, представляя отдел ТП, получает доступ на просмотр "Открытых линий", прослушивание звонков IP телефонии отдела. Одной из ключевых фукнций ТимЛида является администрирование КанБан доски, поддержание правильного потока и по сути выполняет роль менеджер сервиса запросов (service request manager) от многих заказчиков.

Почему КанБан ? КанБан - очень легко и прозрачно ложиться будни рабочего процесса отдела технической поддержки. Прохождение заявки четко регламентировано, определены этапы, определены критерии. Из набора функций в КанБан (каденций) - ТимЛид обеспечивает:

ТимЛид - должность, которая обеспечивает один из принципов КанБан - поощрения развития лидерства.

Практики которые мы используем от КабБан:

Разные инциденты (заявки) у нас имеют разные этапы выполнения, поэтому мы их обобщили и на доску вынесли следующие этапы (колонки доски). Строки таблицы - это сотрудники ТП, у каждого своя строка + 2 специальные строки - так называемые (swimlanes - плавательные дорожки)

1. Очередь заявок (или бэклог ) тут оказываются заявки (индиденты) на стикерах, зарегистрированные в системе и имеющие состояние "Новый". Как только инцидент зарегистрирован в системе, запускается счетчик времени реакции.

2. Как только заявка взята в работу сотрудником или назначена сотруднику ТимЛидом - начинается отсчет времени решения и стикер заявки "садиться" на строку сотрудника на Канбан доске в второй колонке "Первичная оценка" - эта колонка как и следующие две разделена на две подколонки "in progress" и "done", что соответственно говорит о процессе работы по стикеру и уже выполненном этапе. На этом этапе сотрудник по нашему регламенту должен в телефонном режиме контактировать с Абонентом, сообщить, что он занимается заявкой, задать понятные на этом этапе вопросы, провести и сообщить первичную оценку времени решения. На этом же этапе определяется нужны ли дополнительные ресурсы для решения - например специалист ТП третьего уровня.

3. Третья колонка это не посредственно "Решение заявки" - в зависимости от типа заявки этот этап в регламенте может быть разбит на промежуточные, однако для визуализации на доске используется один общий, который отражает именно процесс работы над заявкой. Две подколонки "in progress" "done"

4. "Проверка и доведение результатов" на этом этапе происходит проверка (с ТимЛидом выборочно) и систематизация результатов - оформление их в виде электронного письма или технического заключения, сообщение результатов Абоненту или Заказчику заявки в телефонном режиме и иным, выбранным заказчиком способом. Две подколонки "in progress" "done"

5. "Готово" - тут находятся завершенные тикеты - каждый день их снимает или Тимлид или сотрудник по своей строке. Эта единая колонка без подколонок.

Важнейшим условием, использования Кабнан является определение ЕМКОСТИ по каждой колонке на Канбан доске. Емкость в нашем случае определяет максимально возможное количество стикеров (заявок), находящихся на каждом этапе. Емкость для каждого этапа вы можете выбрать и рассчитать самостоятельно. В качестве отправной точки можно взять 2N+1 , где N - количество сотрудников. То есть емкость определяет можно ли затащить тикет на этот этап или нет.

Например во 2ой колонке емкость 11 заявок. В сумме в двух подколонках находится 10 по всем сотрудникам. Значит новую заявку на этот этап мы можем "затащить" только одну. Далее что бы затащить новую заявку какому либо сотруднику - необходимо продвинуть дальше одну из заявок, находящуюся сейчас на этом этапе. Это можно сделать в том числе "подключившись" с помощью к тем сотрудникам у кого возник "затык" на этапе первичной оценки (например не могут найти правильный контакт Абонента).

Именно принцип емкости - двигает вперед и задает ритм. Мы понимаем, что реальная цепь событий не всегда позволяет соблюдать емкость в ущерб результату. Именно поэтому существуют swimlane - дополнительные строки Канбан таблицы - это строки вне емкости каждой колонки.

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

Возможно определение правил использования swimlane - например классический вариант - на дорожке в один момент времени может быть не более одного стикера (заявки)

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

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

Команда (если это команда) всегда более эффективна чем сумма эффективностей отдельных участников.

Вот пожалуй все для второй части. В следующей статье я расскажу про Кайдзен и эволюцию мотивационной схемы.