«Господи, с чего же начать?»: как настроить работу компании так, чтобы все было четко и понятно

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

Авгиевы конюшни

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

Вы смотрите на нее и думаете: «Господи, с чего же начать?» Все в кучу – тарелки, вилки, ложки, ножи, сковородки, доски. Все скопилось за целый день, и как-то надо это все перемыть. А вы устали после рабочего дня и в ютубчике новый «ДЗК» не досмотрен.

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

Так и с новым проектом – есть часть работ, которую вы можете делегировать, расписав, что надо сделать, автоматизировать или полностью убрать. И часть, которую нужно делать своими руками.

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

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

Палка о двух концах

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

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

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

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

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

Представьте себе департамент, в котором есть три команды. Есть руководитель департамента и тимлид в каждой команде. 

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

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

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

1. Руководитель департамента (по умолчанию обладающий большей информированностью о целях бизнеса и ситуации в компании в целом) не заметит задачи, которые не нужно было делать вообще. Да, со временем тимлиды научатся разбираться в этом лучше, но поначалу зря будет потрачено множество человеко-часов.
2. Руководитель департамента замкнется на своих задачах и вообще не будет в курсе задач команды. Глобально в этом нет ничего плохого, но локально и точечно ему будет сложнее быстро вникнуть и помочь с решением «завтыков» в выполнении задач командой.
3. Перекладывая на постановщика задачи необходимость выбирать подходящую команду, а на тимлида – решать, его команде делать задачу или перекинуть на другого тимлида (и еще убедить его, что это верное решение), – тоже не лучшее решение, которое может привести к потере качества выполнения задач. «Не та» команда будет делать не то, что должна/не то, что у нее лучше получается.

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

Главное – делать это только после того, как прожили эту операционку и точно знаете весь фарватер и подводные камни.

Про оптимизацию процессов

Опытному менеджеру все равно, каким отделом заниматься – он везде наведет порядок. 

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

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

У нас в Netpeak есть отдел SDR (sales development representative), проще говоря – команда специалистов по первичной обработке заявок. Это лицо (или голос) компании, люди, которые первыми общаются с каждым новым клиентом.

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

Для агентского бизнеса отдел SDR – редкость, он нужен только тогда, когда входящих заявок на услуги действительно очень много (а у нас их более 500 ежемесячно).

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

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

1. В первую очередь я попросил тимлида подробно и в свободной форме написать, что он делает.
2. Собрал все отчеты в docs/spreadsheets, которые заполняет команда.
3. Прошел по руководителям отделов и каждого отдельно спросил, какие отчеты от SDR они смотрят. Оказалось, что никто и ничего не смотрит. То есть огромное количество документов регулярно заполнялось командой просто так – вдруг кто-то когда-то решит что-то проверить.
4. Закрыл доступы ко всем документам. Если кто-то захочет посмотреть документ – должен будет прислать мне запрос на открытие доступа. Спойлер: два года спустя таких запросов – ноль.
5. Оставил один общий внутренний файл с ежемесячной отчетностью и настроил его полуавтоматическое заполнение формулами.  
6. Полностью изменил систему стимулирования. Вместо сложной, с кучей отдельных маленьких бонусов, оставил один бонус и увеличил его в два раза.  
7. В ультимативной форме перевел 100% всей работы по заявкам исключительно в CRM, настроил простой и быстрый контроль статусов заявок для тимлида.
8. Проанализировал автоматические ежемесячные задачи, удалил 90%, оставил только несколько по проверке звонков и обработке заявок.
9. Сделал карьерную лестницу, создал роли junior/middle/senior SDR, прописал требования к позициям и финансовые бонусы за переход.
10. Ввел регулярные (раз в две недели) часовые созвоны с тимлидом.

Кстати, стоит сказать, что сделал я все это сидя в Одессе, притом что вся команда SDR – в Харькове.

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

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

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