Кейс: внедрение Канбана в коммерческом блоке дистрибутора

В то время как большинство внедрений Канбана заканчивается самой канбан-доской, а в лучшем случае, ежедневными встречами команды у этой доски, нам в описанном кейсе удалось пойти дальше.

Мы полностью перевели работу отдела сопровождения продаж небольшой дистрибьюторской компании на сервисный подход, а также установили и смогли удержать предельное количество одновременно выполняемых задач в работе (WIP-лимиты). Кроме того, нам удалось создать работоспособную систему метрик и отчетности, которая позволяет управлять потоком заявок от продаж в реальном времени и эффективностью сервисного подразделения в целом. Весь проект, включая подготовку к запуску и стабилизацию процессов, занял примерно 3,5 месяца.

Среди первых результатов: надежность процесса и взаимозаменяемость сотрудников; сокращение времени выполнения задач; удовлетворенность сотрудников сопровождения; актуальная и объективная информация о скорости, производительности и качестве сервиса, которую можно использовать для его дальнейшего совершенствования.

Многие изученные мной материалы и доклады по Канбану дают довольно поверхностное представление о том, с чем придется столкнуться на практике или заточены на начальный уровень подготовки, объясняющий терминологию и общие принципы работы Канбана. Данный кейс позволяет заглянуть за кулисы процесса его внедрения.

Хотя я использую термин «Канбан» и знаком с книгой «Канбан» Дж Дэвида Андерсона, а также «Кратким руководством по Канбану», имею опыт применения некоторых инструментов на своих проектах, я не участвовал в сертификационных тренингах по Канбану, и не претендую, на то, что использую канонически правильные термины и инструменты в том виде, как они задумывались, например S.T.A.T.I.K.

Тем не менее материалы по Канбану таких известных экспертов как Алексей Пименов, Алексей Жеглов, Игорь Филипьев помогли мне адаптировать и внедрить ряд практик Канбана в описанном консалтинговом проекте.

Компания

Дистрибутор мед.техники и оборудования. ~ 50 человек в штате.

Контекст внедрения

Два ключевых подразделения компании в периметре проекта:
Коммерческий блок состоит из ~20 сотрудников, включает три отдела: ответственный за продажи отдельной категории оборудования и два других со всеми остальными категориями продукции, разделяющие ответственного по клиентам. Основная функция отделов продаж – работа с текущими или новыми клиентами. Большую часть времени менеджеры находятся вне офиса – в разъездах и на встречах с клиентами. Цикл продаж – длинный, в среднем от 6 до 12 месяцев, поэтому ведение сделки чем-то похоже на управление проектом.

При этом для осуществления продаж необходимо выполнять огромный объем аналитической и административной работы, чем занимается Отдел сопровождения, состоящий из 8 человек.
Основными задачами отдела сопровождения является: подготовка коммерческих предложений; взаимодействие с поставщиками; формирование смет для коммерческих предложений; подбор необходимых сведений для участия в тендерах и конкурсах; подготовка аналитических материалов, обосновывающих цену продажи и т.д.

В отличие от IT сферы количество и разнообразие видов услуг (сервисов), оказываемых подразделением сопровождения было значительно больше, а количество различных маршрутов (цепочек создания ценности) насчитывало от 5 до 10.

Ключевые проблемы

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

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

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

Также в компании использовали практику закрепления за каждым менеджером по продажам отдельного специалиста по сопровождению. Со временем такие «команды», состоящие из продавца и сопровожденца, могли успешно функционировать, но только в случае, если между ними возникала «химия» и только до тех пор, пока кто-то из менеджеров по сопровождению не выбывал — заболевал, уходил в отпуск или покидал компанию.

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

Этапы внедрения

Первый этап изменений прошел летом 2018 года по инициативе руководителя отдела сопровождения, когда в компании реализовывался проект по модернизации процесса продаж.

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

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

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

Для систематизации учета всех заявок решили использовать Trello. Этот инструмент соответствовал нашим требованиям даже в бесплатной версии.

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

По всем видам сервисов сделали единый обобщенный маршрут движения, который отразили в виде набора колонок в Trello. У нас получились следующие колонки:

Все карточки были отмечены тегом отдела, к которому они принадлежат.

Срочные запросы отмечались тегом «Срочно».

Далее подготовили чек-листы и инструкцию, описывающие выполнение новых функций в процессе.

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

Сделали иллюстрированную инструкцию по тому, кто участвует в процессе, что они могут и что не могут делать (например, менеджеры по продажам имели право создавать карточки только в Очереди и не имели права двигать карточки по доске).

Все документы по новому процессу согласовали с руководителями отделов продаж, провели инструктаж, занесли все текущие заявки в Trello и запустили в работу.

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

Уже на этом этапе, по мнению руководителя отдела сопровождения Н., были получены заметные ей результаты: «касательно моего отдела: гораздо проще стало понимать, какая загрузка, кто сколько делает, я сейчас меньше уделяю времени на вопросы «Ты что делаешь, ты чем занят?». Соответственно, более оперативное распределение задач, которые были поставлены на исполнителя, а он «выбыл»: у меня есть возможность оперативно распределить без потери времени. У меня рутинного контроля стало меньше: Оперативных вопросов осталось много, но относительно отслеживания задач, львиной части нашей работы, времени стало отнимать меньше наполовину. Сейчас я спокойно понимаю все, и задачи, минуя меня, сами двигаются дальше, то есть моего участия уже как такового не нужно. Хороший пример: я была в отпуске, назначила девочку в качестве администратора, сказала ей отслеживать – и все очень хорошо получилось. Я даже в отпуске заходила в Trello, поглядывала – все нормально. Мне легче, я хотя бы этот фронт работ себе уменьшила, эту рутину бешеную. Больше акцент на порядок, дисциплину.».

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

Итого: увеличение количества «срочных» задач и постоянный прессинг сопровождения со стороны менеджеров по продажам, рост напряжения между подразделениями.

С учетом новых вводных стартовал второй этап модернизации процесса сопровождения для решения описанных выше проблем и с целью выстроить из сопровождения надежный, быстрый и клиентоориентированный «конвейер».

В рамках этой работы решили продолжить использовать инструмент Trello, дополнив его необходимыми аналитическими инструментами.

Перед тем, как предложить подход к описанию и улучшению сервиса, решил перечитать статью Игоря Филипьева и заодно посмотреть видео Тома Рейнолдса про метод проектирования и планирования внедрения канбан-системы S.T.A.T.I.K.

Для определения подхода к описанию и улучшению сервиса я отталкивался именно от логики S.T.A.T.I.K., в процессе поменяв последовательность шагов на свой вкус. Занял весь процесс, правда, не 1,5 часа, как декларируют эксперты, а несколько недель обсуждений в формате 1,5 часовых воркшопов 2-3 раза в неделю, но на выходе получился уже не набросок будущей системы, а ее промышленная версия с необходимой поддержкой ИТ-инструментами.

Давайте пройдемся по шагам, к которым я пришел по мотивам S.T.A.T.I.K.:

1. Понять источники нагрузки

У нас есть 3 отдела продаж, которые формируют 99% запросов для обработки.

2. Понять предназначение системы

Основное предназначение системы – удовлетворять потребности отдела продаж по качеству и скорости обработки запросов с учетом реального приоритета и требуемых сроков. Звучит несколько обобщенно, но конкретика появится уже при описании «fit for purpose» конкретных типов сервисов и их классов.

3. Определить типы задач

В процессе анализа выяснилось, что количество оказываемых услуг (сервисов) по сравнению с первым этапом выросло с 5 до 8, без учета мелких задач (сделать скан, распечатать и др.) и тех, которые выполняются разово и не могут быть формализованы (аналитика продаж, исследование рынка и др.).

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

Список услуг был составлен руководителем отдела сопровождения и согласован с руководителями всех отделов продаж.

4. Понять фитнес-критерии или «fitness-for-purpose» системы

Для меня неочевидно, как определить fitness-for-purpose системы в целом. Более того, я считаю, что если делать данный шаг, то уже в разрезе конкретных сервисов, что мы и сделали чуть позже. Это не исключает, что ряд требований может относиться к работе сервисного подразделения в целом.

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

Мы начали обсуждение в формате 1,5 часового воркшопа с качественных критериев, так как по сравнению с количественными они вызывали существенно меньше споров и не требуют на входе замеров показателей.

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

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

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

Тем не менее через несколько сессий мы описали критерии для каждого из продуктов по каждому из восьми сервисов.

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

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

Как выяснилось, даже те чек-листы, которые были введены на первом этапе внедрения мало кем использовались из-за неформальности «командной» работы сопровожденцев и продавцов. Что в итоге после расформирования команд это привело к росту неудовлетворенности продавцов качеством сервиса сопровождения.

5. Проанализировать возможности и по устранению узких мест

Основными узкими местами, влияющими на сроки прохождения запросов были: перегрузка сотрудников сопровождения (на каждого в моменте в среднем приходилось 11-12 задач) и длинные сроки нахождения задач на уточнении (некоторые доходили до сотен дней).

Кроме того, проанализировав карточки на доске Trello мы поняли, что многие из них висят месяцами и даже годами, а вовсе не те 3-5 дней, которые закладываются на решение сопровождением отдельной практической задачи, например, подготовки КП.

Как выяснилось позже, дело в том, что вместо запроса атомарной конкретной услуги с понятным входом и выходом менеджеры по продажам де-факто начали использовать карточки Trello как способ отслеживания хода проекта в целом. Сами же запросы они указывали в комментариях к карточкам такого проекта-сделки.

Таким образом, в каждой карточке накапливалась вся история действий и обсуждений по сделке (используемая компанией CRM система не позволяла отслеживать ход сделки в требуемой детализации).

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

6. Определить классы обслуживания

Согласно Краткому руководству по Канбану, класс сервиса определяет:

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

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

По сути, единственным классом обслуживания в прочтении Краткого руководства по Канбану, который был нами добавлен в процесс – стал «Ускоренный» класс. Он отмечался в доске Trello тегом «Срочно» и, когда люди перестали обращать на них внимание, появился тег «Важно», чтобы исправить ситуацию, но и это не работало на ускорение.

Впоследствии проанализировав сроки обработки запросов, мы поняли, что большая часть срочных запросов выполняется практически с той же скоростью, что и обычные (13 против 15 дней). Добавление этих тегов не ускоряло их выполнение, их количество составляло около 15% от общего количества. Таким образом, нужно было пересматривать подход к тому, как сделать «Срочные» в системе запросы по-настоящему срочными, то есть хотя бы на 20% более быстрыми чем стандартные. Далее к этому классу обслуживания я вернусь, когда речь зайдет об установке WIP-лимитов.

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

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

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

7. Смоделировать поток ценности

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

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

Вариант с несколькими канбан-досками для одного подразделения мы также отмели, это бы отрезало нам путь в работе с WIP-лимитами, которые удобно отслеживать, когда вся работа команды сервиса собрана на одной доске.

8. Определить начальные изменения

В качестве ближайших возможных изменений мы наметили:

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

9. Спроектировать Канбан-систему

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

В работе, Выполнено) добавили только колонку «Закрыто» после колонки «Выполнено».

В модернизированном процессе колонка Выполнено использовалась только в случае, если в запросе менеджер отметил, что хотел бы принять результат лично. После принятия результата или истечения срока ожидания приемки карточка перемещалась в статус «Закрыто».

Добавление данного этапа обработки позволило нам в будущем избежать жалоб менеджеров по продажам на качество оказанной услуги.

10. Сделать дизайн карточек

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

Поскольку клиент успешно использовал Trello – пространство для маневра с дизайном самой карточки на доске было невелико.

Для того, чтобы в дальнейшем собирать различную аналитику по задачам мы добавили на Trello-доску теги, соответствующие типу сервиса, сложности запроса и классу обслуживания («Срочно»). Все теги присваивал руководитель отдела при назначении задачи на специалиста отдела сопровождения.

11. Определить явные политики

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

Например: задача на уточнении может висеть не более 3-х дней.

Задача на проверке может висеть не более 2-х дней, причем по истечении 1 дня уходит уведомление на руководителя отдела продаж, который был инициатором запроса, а через 2 дня задача принимается автоматически с соответствующей пометкой в карточке.

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

Кроме того, если раньше допускалось движение карточек назад, теперь мы оставили такую возможность только для колонки «Уточнение постановки задачи», а для остальных статусов запретили.

12. Установить WIP-лимиты

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

Благо некоторая статистика о количестве одновременно выполняемых задач уже была накоплена в Trello. На каждого сотрудника сопровождения приходилось в моменте в среднем 11-12 задач. Именно этот уровень мы и взяли за основу для диалога с бизнесом, уменьшив на 10-15% до 9 задач. Мы показали топ-менеджменту, что в любом случае сотрудник сопровождения не может выполнять одномоментно 9 задач, а это значит, что де-факто помимо тех задач, которые находятся на уточнении, остальные остаются в очереди, которую мы на данный момент даже не видим.

Руководство компании и, в частности, коммерческий директор быстро поняли взаимосвязь скорости прохождения запросов и количества задач в работе и согласилось с предложенным нами и сопровождением WIP-лимитом. Следить за лимитом должен был руководитель отдела сопровождения (в терминах Канбана – Service Delivery Manager), которая назначала задачи.

Лимит мы назначили на колонки: Назначен исполнитель, Уточнение постановки задачи, В работе, Выполнено. При этом этапы «Уточнение постановки задачи» и «Выполнено» фактически находились в зоне ответственности отделов продаж. Такой подход стимулировал продажи быстрее уточнять возникшие у сопровождения вопросы и оперативно выполнять приемку, высвобождая место под новые запросы. Контроль за соблюдением WIP-лимитов возложили на начальника отдела сопровождения.

Для того, чтобы задачи в этих статусах не застревали и долго не занимали место в WIP-лимите мы ввели жесткие сроки на нахождение в них, например, задача на приемке в любом случае принималась в течение 2-х дней, а висение карточки на уточнении более 3-х дней требовало детального объяснения либо переноса карточки обратно в очередь или ее архивирования.

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

Мало договориться о WIP-лимитах, для того чтобы их поддерживать нужна качественная и достаточно детальная аналитика. Да и в целом считаю, что уровень танцев у канбан-доски без метрик не решает вопрос повышения скорости сервиса или оценки его эффективности. А зачем нам вообще Канбан, если его эффект невозможно пощупать?

Поэтому мы решили, что запускать второй этап будем сразу уже с полноценной аналитикой. В качестве инструмента мы выбрали NAVE (getnave.com) – облачный сервис, который позволяет интегрироваться с наиболее популярными таск-трекерами и без дополнительного конфигурирования строить наиболее популярную Канбан-отчетность, CFD-диаграмму, диаграмму рассеивания, частотную диаграмму, а также рассчитывать время обработки запроса на каждом этапе (cycle time) и в целом (lead time).

Аналогичных облачных сервисов со столь же простой интеграцией и настройкой мы на тот момент не нашли.

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

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

Также в процессе адаптации отчетности мы пересмотрели многие из канонических канбановских представлений и отчетов, например CFD-диаграмму, которая оказалась не слишком понятной и удобной. Это было важно так как среди участников внедрения со стороны клиента больших спецов в теории вероятности и в Канбане с теоретической точки зрения не было. Более подробно про отчеты и метрики я напишу в отдельной статье.

Довольно серьезная битва с бизнесом произошла вокруг «Ускоренного» класса обслуживания. Несмотря на то, что всем было понятно, что текущая схема, когда каждый инициатор запроса сам определял срочность, сводило желаемое ускорение к нулю, никто из бизнеса был не готов отказаться от существующего де-факто права «ускорить» задачу.

Мы поставили себе цель, что количество срочных задач должно быть менее 10%, т.е. всего не более 7-8 штук. С учетом того, что было 3 отдела договорились каждому отделу дать по 2 срочных задачи внутри общего WIP-лимита в 9 задач на одного сотрудника сопровождения.

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

В качестве еще одного инструмента управления приоритетами решили оставить возможность руководителям отделов продаж ежедневно уточнять приоритеты задач, назначенных на исполнителей, но еще не взятых в работу. Хотя этим правом в итоге пользовались они не часто, напряжение при обсуждении лимитов на «Ускоренный» класс задач удалось избежать.

13. Договориться о Каденциях (Ритуалах)

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

Ретроспективы использовались только на этапе внедрения и их дальнейшее проведение только в плане у руководителя сопровождения.

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

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

14. Запуститься и оповестить всех

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

Запуск для всех сотрудников проводился в виде инструктажа на 1,5 часа, на котором руководство компании объявило о переходе на обновленный процесс, была представлена аналитика по текущей скорости прохождения запросов и способах исправления ситуации за счет введения четких правил формулированию запросов и делению их на сервисы. Ни в какие канбан-игры мы не играли. Честно говоря, немного пожалел, что мы попытались объяснить, что такое Канбан рядовым сотрудникам за час. Думаю, это бессмысленно – механику можно объяснить и без новых терминов, значение которых не добавляет ценности в работу участников процесса и вызывает дополнительное непонимание и сопротивление.

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

Примерно через месяц мы наладили аналитику с помощью сервиса NAVE и сводных таблиц Excel. Довели время на ее подготовку до 45 минут в неделю, а через несколько недель запустились регулярные еженедельные встречи команды отдела сопровождения в новом формате и ежемесячный обзор сервиса с топ менеджментом.

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

Ключевыми замечаниями со стороны менеджеров по продажам по итогам пилотирования модернизированного процесса стали:

• Неудобства, связанные с переходом от карточек равных сделке к атомарным запросам каждого сервиса отдельно, что повлекло увеличение их количества,
• Сложности с удаленным заведением запросов, так как не у всех сотрудников на тот момент были планшеты или ноутбуки, с помощью которых это можно было удобно сделать плюс недоступность части внутренних ресурсов за пределами офиса,
• Снижение качества выполнения запросов сопровождением при передаче от одного сотрудника к другому, в том числе из-за потери информации,
• Формальное отношение сотрудников сопровождения к выполнению запросов лишь бы выполнить запрос в срок,
• Потеря связи между взаимосвязанными запросами по одной сделке либо их передача в работу разным людям с большим временным перерывом.

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

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

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

В качестве положительных эффектов менеджеры по продажам отметили:

• Более четкое и однозначное понимание, где сейчас находится задача,
• Ускорение выполнения задач,
• Удобство шаблоны формулирования запросов, которые помогают не задумываться, какая информация нужна для корректного выполнения,
• Рост числа задач, выполненных корректно с первого раза.

С другой стороны, менеджеры по сопровождению отметили:

• Повышение мотивации, так как легче увидеть выполненную работу,
• Более быстрое выполнение задач,
• Снижение трудоемкости на распределение задач (раньше разбор очереди руководителем выполнялся постоянно, а теперь только 2 раза в день),
• Более четко стали видны запросы, длительное время висящие на уточнении,
• Описание задач стало более четким и полным.

По мнению коммерческого директора после создания канбан-системы компания:

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

Весь процесс от проектирования канбан-системы до ее запуска занял примерно 1,5 месяца и около 2-х месяцев потребовалось на стабилизацию работы по новым процессам.

Выводы:

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

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

3) Без объективных метрик невозможно по-настоящему внедрить и удержать WIP-лимиты, так как они будут все время оспариваться и в итоге нарушаться, что приведет к снижению уровня сервиса, и деградации канбан-системы.

4) Подходы, описанные в книгах и преподаваемые на тренингах, в практике должны быть адаптированы с учетом контекста, вашего опыта и веры в их работоспособность. Далеко не все инструменты, метрики и отчеты удобно использовать в каноническом виде.

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

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

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

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