В Garage Eight наступила неделя оптимизации. Число ad hoc задач сократилось в 3 раза

Привет, Хабр! Меня зовут Константин, я лидирую аналитику партнерских программ в компании Garage Eight. Еще год назад ad hoc были для нас настоящим бедствием: мы достаточно долго существовали в реалиях 60–70 таких задач в месяц. Но в какой-то момент решили, что пора завязывать, и за несколько шагов сократили их до 20–25.

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

Почему возникают ad hoc задачи 

Я работаю с несколькими регионами Юго-Восточной Азии и Африки. В мои задачи входит не только обеспечение команды цифрами, дашбордами и планированием, но и развитие аналитической компетенции sales-менеджеров. Специфика партнерской программы в том, что для нас это «компания в компании». Задачи могут прилетать откуда угодно. Например, со стороны:

• С-level;

• отдельных партнеров;

• отдельных клиентов;

• HR;

• копирайтера;

• дизайнера. 

Ad hoc — это такая задача, которая возникает «по ситуации», выходит за рамки процесса business as usual и привычных автоматизированных расчетов. А еще отнимает ваше время, провоцирует выгорание и синдром отложенной жизни. Типичный пример: менеджер приходит за информацией о перформансе и прибыльности партнера, чтобы понять, как и с каким риском с ним можно работать в рамках определенного офера. И через некоторое время повторяет этот запрос несколько раз — меняются только партнеры и отдельные нюансы выгрузки.

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

• Дисфункция. Что-то должно быть автоматизировано по определению, но оно работает в ручном режиме.

• Развитие спроса на данные. Менеджер понял, куда целиться, чтобы бустить базу, растить метрики, (пере)выполнять KPI, получать больше бонус, и теперь ему срочно нужны новые метрики или агрегации.

• Любопытство. Важно в discovery и change-процессах. На практике это может звучать примерно так: «А давайте посмотрим на „экзотическую“ метрику депозита в скользящем 100-дневном окне». То есть вы хотите увидеть инсайты в привычных переменных.

• Ошибка. Вопрос возник, потому что пользователь не понимает, что у него что-то уже автоматизировано. Он приходит с запросом, не зная, что для решения задачи не нужен ad hoc — уже есть отчет с готовыми показателями.

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

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

Как мы разобрались с потоком ad hoc задач

Через метод проб и ошибок мы вывели относительно универсальный алгоритм:

• На входе у вас должен быть понятный формат ad hoc: описание задачи по регламенту, что, когда и в каком виде нужно. Если пользователь не умеет так формулировать — это нормально, можно задать соответствующие вопросы на берегу (во избежание попадания в антипаттерн garbage in, garbage out). Хороший вариант 一 отдельный канал в любимом корпоративном мессенджере, лучший 一 workflow в том же канале или тикет в трекере, например Jira или Asana.

• Механика приоритизации ad hoc должна быть прозрачна. Один из вариантов — здравый смысл, который держится на двух ключевых моментах: «Кому это нужно?» и «Зачем это нужно?». Например, ad hoc получит больший приоритет, если результат его выполнения:

  • нужен большому числу людей;

  • сокращает срок выполнения трудозатратного процесса;

  • сильно экономит время дорогого сотрудника;

  • приносит или экономит деньги здесь и сейчас.

• Все ad hoc хранятся где-то в каком-то виде: и заявки, и решения (код, таблица, витрина, пайплайн, график). У всех есть временные метки и названия. Так можно переиспользовать код и делиться результатами. Особенно это помогает в кейсах, где предполагается обращение к разным API, DWH и продовым базам данных — на смеси SQL и Python.

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

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

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

Когда вы умеете хранить, классифицировать и понимать причины, по которым появляются ad hoc задачи, становится понятнее, что делать:

• Формализовать и обсуждать. Среди потока разнообразных ad hoc всегда есть те, что сочетают в себе ценность в деньгах и/или экономии времени, стабильный спрос и воспроизводимость. Именно такие вещи в первую очередь подлежат автоматизации.

• Не подменять реальные изменения полумерами. Если похожие запросы повторяются — конвертируйте ad hoc в регулярный отчет.

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

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

Еще лайфхаки работы с ad hoc

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

• Покажите выгоду от data-driven решений. Тот же sales-менеджер может увеличить свой перформанс за счет понимания надежности и перспектив развития партнеров — разберите с пользователями сценарий: как это работает. Более самостоятельные пользователи способны решать некоторые ad hoc задачи своими силами.

• Создайте комьюнити 一 некоторые кейсы будут закрываться внутри него.

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

• Больше данных 一 меньше отчетов. При оптимальной производительности один или несколько мастер-отчетов и отдельные дашборды, закрывающие специфические задачи.

При выстроенной отработке ad hoc мы понимаем, что всегда будут задачи, которые по приоритизации на нашем канбане попадают в категорию some day, что в вольном переводе будет значить «никогда». Это что-то такое, что интересно было бы посмотреть, но либо время аналитика дороже потенциального профита, либо business needs успели поменяться до того, как случилась приоритизация.

По итогу число ad hoc можно существенно сократить, но стоит понимать, что в масштабном бизнесе почти нереально свести их число к нулю. Во-первых, это невозможно просто потому, что бизнес-логика и аналитика постоянно эволюционируют. Это требует периодических экспериментов, начиная от точечного A/B-тестирования вплоть до новых методик долгосрочного прогнозирования и стратегической оценки рисков. Во-вторых, при правильном подходе именно ad hoc, как по мне, 一 отличный драйвер развития, источник новых идей и подходов. 

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