Операционная деятельность и вообще вся текучка в практически любом рабочем процессе почти всегда может быть оптимизирована, а иногда даже полностью автоматизирована. И чем больше вы делаете новых проектов, тем круче вы вырабатываете систему и тем проще вам организовывать и делать следующие. В этой колонке расскажу, как автоматизировать все, что только можно.
Авгиевы конюшни
Каждый новый вызов или проект очень похож на гору немытой посуды, которую разбираешь после ужина.
Вы смотрите на нее и думаете: «Господи, с чего же начать?» Все в кучу – тарелки, вилки, ложки, ножи, сковородки, доски. Все скопилось за целый день, и как-то надо это все перемыть. А вы устали после рабочего дня и в ютубчике новый «ДЗК» не досмотрен.
Но деваться некуда, кроме вас никто ничего не помоет. Вы начинаете все это разбирать, и за очень короткое время оказывается, что все можно систематизировать. Разделить на две части: можно мыть в посудомоечной машине и нельзя. А из того, что можно помыть в посудомойке: что в нее влазит и не влазит.
Так и с новым проектом – есть часть работ, которую вы можете делегировать, расписав, что надо сделать, автоматизировать или полностью убрать. И часть, которую нужно делать своими руками.
Со временем, чем чаще вы складываете посуду в посудомойку, тем больше учитесь вырабатывать собственную систему. В первую очередь загружать верхнюю полку с чашками и блюдцами, а позже нижнюю – с кастрюлями и тарелками. Доставать из кучи грязной посуды предметы по определенному признаку, не тратя лишнее время на то, чтобы положить что-то на верхнюю, а что-то на нижнюю полку.
Спустя 15 минут вы смотрите на кухню – она чистая, посудомойка работает, все вымытое руками высыхает на сушилке. Вы в прекрасном настроении, довольны закрытым гештальтом и идете спать.
Палка о двух концах
Энергичный руководитель, недавно получивший должность и управление командой, хочет автоматизировать и оптимизировать максимальное количество процессов. И это хорошо.
Но часто он хочет это сделать сразу, даже не поработав внутри определенного процесса хотя бы месяц. А ведь многие кастомные (читайте – уникальные для каждой отрасли, компании, команды) процессы содержат большое количество «но» и «если», которые можно выявить, только столкнувшись с ними.
Суть палки о двух концах в том, что, с одной стороны, быстрая оптимизация – очень хорошо. Она экономит время, позволяет дорабатывать себя в процессе и не создавать из руководителя узкое горлышко, на котором стопорятся все процессы.
А также меньше замыкаться в операционке и больше фокусироваться на развитии команды, продукта или услуги и достижении глобальных целей.
С другой стороны, быстрая оптимизация – плохо. Приведу пример из собственной практики.
Представьте себе департамент, в котором есть три команды. Есть руководитель департамента и тимлид в каждой команде.
В департамент ежедневно прилетает по 5–10 задач от других департаментов. Каждая задача может относиться к одной из трех команд внутри департамента или сразу к двум и даже к трем. Также каждая задача может быть неправильно составлена, не иметь ценности и полезности для бизнеса и так далее.
Подход «быстрой оптимизации» говорит нам, что нужно дать возможность постановщикам задач сразу выбирать исполнителями одну (или несколько) из команд и переложить ответственность на тимлидов.
Практика работы с таким потоком задач уточняет, что «быстрая оптимизация» сразу приведет к нескольким проблемам:
- Руководитель департамента (по умолчанию обладающий большей информированностью о целях бизнеса и ситуации в компании в целом) не заметит задачи, которые не нужно было делать вообще. Да, со временем тимлиды научатся разбираться в этом лучше, но поначалу зря будет потрачено множество человеко-часов.
- Руководитель департамента замкнется на своих задачах и вообще не будет в курсе задач команды. Глобально в этом нет ничего плохого, но локально и точечно ему будет сложнее быстро вникнуть и помочь с решением «завтыков» в выполнении задач командой.
- Перекладывая на постановщика задачи необходимость выбирать подходящую команду, а на тимлида – решать, его команде делать задачу или перекинуть на другого тимлида (и еще убедить его, что это верное решение), – тоже не лучшее решение, которое может привести к потере качества выполнения задач. «Не та» команда будет делать не то, что должна/не то, что у нее лучше получается.
В стремлении уменьшить операционку и автоматизировать все, что только можно, нет ничего плохого. Наоборот, это совершенно правильный подход.
Главное – делать это только после того, как прожили эту операционку и точно знаете весь фарватер и подводные камни.
Про оптимизацию процессов
Опытному менеджеру все равно, каким отделом заниматься – он везде наведет порядок.
Отличие опытного менеджера не в том, что он лучше знает, какие изменения вносить. Ведь зачастую все изменения – очевидные, понятные и адекватные. Фишка в готовности их вносить и в умении делать от начала до конца.
Ниже небольшой кейс из моего опыта примерно двухгодичной давности.
У нас в Netpeak есть отдел SDR (sales development representative), проще говоря – команда специалистов по первичной обработке заявок. Это лицо (или голос) компании, люди, которые первыми общаются с каждым новым клиентом.
Их задача – экономить время клиентов (быстро разобраться, что им не подходят наши услуги) и отдела продаж (передавать целевые заявки).
Для агентского бизнеса отдел SDR – редкость, он нужен только тогда, когда входящих заявок на услуги действительно очень много (а у нас их более 500 ежемесячно).
Классически этот отдел был частью департамента продаж и, по сути, первой ступенью у сейлза. Никто особо долго на позиции SDR не задерживался и рассматривал должность как «пару месяцев постоять у кассы».
Примерно год назад я сделал этот отдел частью департамента маркетинга и занялся детальным аудитом.
- В первую очередь я попросил тимлида подробно и в свободной форме написать, что он делает.
- Собрал все отчеты в docs/spreadsheets, которые заполняет команда.
- Прошел по руководителям отделов и каждого отдельно спросил, какие отчеты от SDR они смотрят. Оказалось, что никто и ничего не смотрит. То есть огромное количество документов регулярно заполнялось командой просто так – вдруг кто-то когда-то решит что-то проверить.
- Закрыл доступы ко всем документам. Если кто-то захочет посмотреть документ – должен будет прислать мне запрос на открытие доступа. Спойлер: два года спустя таких запросов – ноль.
- Оставил один общий внутренний файл с ежемесячной отчетностью и настроил его полуавтоматическое заполнение формулами.
- Полностью изменил систему стимулирования. Вместо сложной, с кучей отдельных маленьких бонусов, оставил один бонус и увеличил его в два раза.
- В ультимативной форме перевел 100% всей работы по заявкам исключительно в CRM, настроил простой и быстрый контроль статусов заявок для тимлида.
- Проанализировал автоматические ежемесячные задачи, удалил 90%, оставил только несколько по проверке звонков и обработке заявок.
- Сделал карьерную лестницу, создал роли junior/middle/senior SDR, прописал требования к позициям и финансовые бонусы за переход.
- Ввел регулярные (раз в две недели) часовые созвоны с тимлидом.
Кстати, стоит сказать, что сделал я все это сидя в Одессе, притом что вся команда SDR – в Харькове.
И вот теперь SDR – отдельная самостоятельная команда, в которую мы набираем людей и в которой растут профессионалы. Здесь уже крутые спецы middle-уровня, которые отлично разбираются в услугах агентства, а показатель качества переданных заявок практически каждый месяц линейно растет вверх.
Я не хвастаюсь, хвастаться здесь нечем – я не сделал вообще ничего экстраординарного. Просто уделил время и внимание процессам, которые делали (или не делали) только потому, что так делали всегда.
С ужасом от нового проекта (или доработкой корявого процесса) лучше всего помогает справиться именно системный подход. И нет большей награды, чем осознание того, что теперь вы знаете, как очищать авгиевы конюшни.
Этот материал – не редакционныйЭто – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: