Александр Богданов (AGIMA)
На самом деле процессы – это люди в первую очередь. Наверное, мой доклад будет чуть-чуть меньше о системах, с помощью которых можно автоматизировать процессы, и больше об основных принципах, людях, которые эти процессы строят, и как эти процессы сами должны эволюционным путем в компании зарождаться.
Я расскажу на опыте своей компании – компании AGIMA. Расскажу, почему я никогда сильно не заморачивался над автоматизацией, почему процессы сами возникали, сами автоматизировались, и как-то все само строилось без особого, активного в этом участия – моего или управленческой команды. Сейчас расскажу, почему для нас это точно бесстрашный опыт.
Во-первых, нам 10 лет. Мы очень рады. На самом деле, я не ожидал, что мы так долго уже существуем. До этого у меня не было компании, которой 10 лет уже. Было несколько компаний по одному-двум годам жизни. 10 лет казался длинным периодом, а на самом деле пролетели мгновенно, но, когда ты смотришь назад, то много интересного можешь для себя увидеть – как, собственно, все развивалось. Можно в двух словах проиллюстрировать:
10 лет назад нас было четыре сотрудника, мы делали один продукт или оказывали одну услугу, и у нас был годовой оборот около 1 млн. рублей в год. Для управления такой командой нам ничего не нужно было.
Мы сидели все в одной комнате, могли друг с другом общаться напрямую, никаких бюрократических способов коммуникации нам точно не нужно было и они нам только бы мешали.
6 лет назад нас было уже 25 сотрудников, мы все еще делали один продукт или оказывали одну услугу, оборот уже был равен 20 млн. И здесь, конечно же, нам чего-то уже нужно было для управления таким коллективом и процессами, которые в нем происходили.
Но нам, в принципе, было достаточно банальной системы управления, т.е. у нас была некая инфраструктура на уровне почтовых рассылок, все коммуникации шли в почте – как с клиентом, так и между собой – все фиксировалось в почте. И уже тогда начинали формироваться некие общие правила, например, того, как происходит workflow по проекту, где взять какую-то документацию и т.д. Эти общие правила существовали у нас на общем диске, и тогда эта система вполне устраивала нас.
3 года назад у нас было 60 сотрудников. Было три направления, понятно, что каждое направление чуть-чуть отличается по процессам между собой. И около 70 млн. рублей у нас был годовой оборот. Здесь уже чуть сложнее был управлять этой историей. И у нас начали зарождаться различные wiki.
- Первые wiki появились сами собой у разработчиков – разработчики начали описывать историю работы над проектом. Все проекты становились все дольше и дольше, длиннее, соответственно, надо было передавать знания. Потом wiki иммигрировала к менеджменту. В общем, в какой-то момент wiki поглотила все наши процедуры внутри, начиная от стойки ресепшн и заканчивая тестированием. Все сейчас у нас проходит в wiki.
- Дальше стали прописываться роли в компании, т.к. мы понимали уже, что, в принципе, некоторые сотрудники в компании – это достаточно типичные специалисты. Мы должны описать, какие у них будут роли, приблизительно сколько они должны для нас стоить, сколько они должны выдавать цены с продукта, который они должны выдавать на выходе. И все это у нас автоматически может начинаться с нашего HR-менеджера, который работает по найму таких специалистов, используя прописанные роли, и заканчиваться тем, что мы контролируем, насколько эти роли исполняются.
- Дальше все возможные вопросы, которые по многу раз задаются нашими сотрудниками, мы автоматически вносили в FAQ. У нас тем самым FAQ формировался.
- И какие-то процессы начинали уже получать системный, отраженный в документации workflow – сайто-производственный процесс, процесс сдачи проекта, документооборот – все просто автоматически фиксировалось.
Сейчас у нас в компании более 120 сотрудников и, в принципе, нас нельзя назвать одной компанией, у нас уже четыре компании в той или иной степени задействовано. Мы имеем 10 направлений и более 220 млн. оборот годовой. Конечно же, этим управлять надо совсем по-другому, чем мы управляли компанией из четырех человек.
Во-первых, появилась такая штука, как корпоративная культура. Надо понимать, чем твоя компания с точки зрения HR-политики отличается от других компаний, подобных тебе. Особенно, когда ты начинаешь конкурировать не только с компаниями, которые занимаются тем же самым сайто-строительством, а ты конкурируешь уже с более крупными компаниями по деньгам, которые занимаются другими вещами, но которые заинтересованы в твоих специалистах. У тебя должна быть своя корпоративная культура, тебе нужно ее фиксировать, тебе нужно ее поливать, ухаживать за ней, выращивать, чтобы люди действительно шли к тебе, в твою компанию, в твою экосистему.
Тебе нужно понимать и четко доносить до каждого сотрудника, какая его карьерная лестница, что его, вообще, ждет в будущем. Она не обязательно должна быть очень четко прописана и детализирована. Несмотря на то, что для некоторых сотрудников у нас есть вполне ясные грейды, для всех сотрудников должна быть ясна перспектива, что он на этом месте не будет сидеть всю жизнь.
Практически для каждого сотрудника должна быть зафиксирована система мотивации, чтобы этим было удобно пользоваться, соответственно, если я придумаю для какого-то звена системы мотивацию, я могу это передать руководителю соответствующего департамента, и он может эту систему мотивации применять везде, поэтому для каждого сотрудника у нас тоже все зафиксировано.
Конечно же, делопроизводство, большое количество документации, особенно, когда ты делаешь бизнес в России, все это прекрасно понимают, документов очень много, и специфика документов большая, поэтому тоже все должно быть прописано.
Ну и, в какой-то момент начинаешь документировать инфраструктуру в офисе, а дальше автоматизировать использование офисной инфраструктуры, начиная от бронирования переговорок и т.д. Все это тоже возникает автоматически, когда у тебя появляется в какой-то момент очередь переговорок. Сначала возникает листочек, который прилепляют на переговорки, где люди пишут время, а потом это автоматически переходит в google-документы, из google-документа в какой-то момент переезжает в Битрикс24.
На самом деле, чем быстрее ты растешь, тем быстрее ты меняешься. Другого не дано. Но перед тем как я, вообще, хотел рассказать, как у нас детально все это выглядит, я хотел ответить на вопрос многих: «Ну, круто, что вы растете, а как расти быстро лучше расскажите, чем рассказать нам, как управлять во время этого быстрого роста». Поэтому я в двух словах расскажу, как, я считаю, можно расти быстро, а потом расскажу как можно дальше быстро меняться.
Во-первых, я поделил рост на три больших таких куска. Первое – это надо наладить хорошенько входящий поток. Входящий поток лидов, заявок – неважно, как вы будете это называть.
Все очень просто. Все начинается с PR. Я считаю, PR – самый великолепный инструмент на нашем рынке. Причем, многие меня спрашивают: «Мы еще пока ничего такого крутого не сделали, чего нам PR’ить, собственно?». На самом деле PR’ить надо в первую очередь не свои кейсы, а PR’ить нужно свой подход, свое видение, вообще, свою философию – это идея, новые вещи, которые ты хочешь использовать, проекты, в которые ты веришь и т.д. Это достойно PR’а на первом этапе, и оно уже генерит достаточно хороший поток лидов. Дальше автоматически это происходит – в продажи, дальше – производство, дальше у тебя рождаются кейсы. Собственно, это постоянная история, в которой рождается PR, который тебе постоянно дает входящий поток лидов.
И второе – это внутренний поток. В какой-то момент 3 года назад мы на него перефокусировались, т.е. до этого много внимания уделяли именно входящему потоку, 3 года назад сместили вектор внимания на внутренний поток, потому что из него рождаются более качественные лиды.
Кстати, мы выложили в открытый доступ видеозаписи с конференций WhaleRider 2015 и 2016. Вот соответствующие листы в нашем аккаунте — 2015 и 2016 в нашем аккаунте на YouTube.
Внутренний поток управляется, в основном, менеджерами, но в нашем случае, мы наделили этой ролью аккаунт-директоров – это наши топ-менеджеры, руководители менеджерских групп. Суть в следующем, что задача аккаунт-директора – вести свой клиентский портфель, планировать по этому клиентскому портфелю менеджерский состав, но, самое главное, что они планируют нагрузку, они выхватывают лиды, формируют их готовые заказы. Они вместе с клиентом доводят проект до конца и после этого обеспечивают PR этому проекту. Причем, если вы посмотрите, как мы PR’им наши проекты, мы всегда в PR’е проектов задействуем и клиентов, и наших сотрудников, т.е. всегда можно посмотреть и увидеть реально команду. И мы водим наших клиентов на конференции, они рассказывают про наши проекты. На самом деле, такое большое внимание к клиенту во время сдачи проекта рождает очень хороший поток дальнейших проектов, мы становимся в какой-то момент сплоченной семьей, где pater familias’ом семьи является наш аккаунт-директор. И это очень клево генерит нам постоянный внутренний поток лидов.
Как я уже сказал, я считаю, что PR – это незаменимый инструмент для обеспечения себя постоянным потоком лидов. И перед тем, как начать много PR’иться и активно PR’иться, единственный способ обеспечить себя действительно качественным объемом лидов после вашего PR’а – это убедиться в том, что вы сами верите, что вы особенные. Если вы поверите в то, что вы особенные и разберетесь, почему именно вы особенные, неважно в чем, просто вы должны поверить, что вы такой один. И в это поверят, как минимум, ваши близкие. После этого вам достаточно любых инструментов, начиная от статей, различных пресс-релизов, Facebook и даже телека, неважно, какие каналы вы будете использовать для того, чтобы иметь максимальный посев, так скажем, вашего позиционирования, это здорово будет работать.
После того, как вы обеспечили себя очередью заявок… Я считаю, что очередь должна быть больше, чем вы можете производить. Это, кстати говоря, принцип, над которым спорят многие: чего должно быть больше – заказов или производственных мощностей? Я сторонник того, что заказов должно быть больше, чем ты можешь произвести. Так работают практически все успешные производственные, да и торговые компании. Если мы придем покупать какой-нибудь автомобиль хороший, нас поставят в очередь, мы будем этот автомобиль ждать, если, конечно, это не какой-то автомобиль с витрины. Так вот, после того, как вы создали поток лидов, у вас есть очередь, вы из нее можете выбирать, что вы будете продавать.
Мы задаемся вопросом: как же можно много продавать? Как я сказал, не всех нужно пускать к вам, очередь должна быть сильно больше, чем вы можете сделать, потому что потом вы можете очень интересно с этим играть.
Как мы можем работать с нашей очередью? На входе любого нашего клиента встречает девочка. У нее задача достаточно примитивная – разгрузить наших аккаунт-директоров, потому что дорогостоящий и очень высококвалифицированный ресурс. Задача девочки: первое – убедиться, что клиент или заявка, которая к нам пришла, имеет все необходимые атрибуты, т.е. есть заполненный бриф, есть какие-то необходимые приложенные материалы, техническое задание и т.д., для того чтобы дальше пустить это в работу. Для начала это фиксировалось в Excel. В принципе, таблички Excel при малом потоке, при малой очереди вполне достаточно, не надо создавать каких-то сложных инструментов. В какой-то момент, когда лидов стало много, мы все это дело интегрировали в CRM.
Что дальше? После того, как девочка обработала все заявки, была выбрана часть заявок, с которыми мы работаем, в которых есть все необходимые атрибуты, все пускается по кругу наших аккаунт-директоров. У нас четыре аккаунт-директора в компании, каждый аккаунт-директор руководит группой менеджеров. Всего порядка 25 менеджеров у нас сейчас трудится. Каждый аккаунт-директор получает лид. Предположим, какой-то клиент со всеми атрибутами хочет сделать определенный проект. Аккаунт-директор смотрит, а вписывается ли ему сейчас в текущем его состоянии портфель и этот лид? Да/нет. Если ему не нравится или он не хочет его брать, или у него сейчас перегруз, он его не берет, пускает дальше.
Если все четыре аккаунт-директора пасуют, то уходит этот лид в партнерскую программу. Раньше мы эти лиды выкидывали или мы их ставили на длинный лист ожидания, сейчас мы их отдаем в партнерскую программу. Партнерская программа – это для нас было достаточно приятное открытие, сейчас мы построили, наверное, самую большую партнерскую сеть, т.е. нас 80 компаний-партнеров и 80% лидов отдается в партнерскую программу.
Партнерская программа выглядит просто. Если у нас есть приблизительный круг согласования аккаунт-директоров – возьму/не возьму, точно такой же есть круг согласования у партнеров. Как только переходит в партнерскую программу лид, каждый из партнеров говорит: хочу/не хочу. И если несколько хочет, они сражаются за этот лид и дальше лид обрабатывают.
Те лиды, которые мы отобрали, которые будут дальше вести наши аккаунт-директора, у нас по ним есть правило: мы должны победить в 100% случаев. Если ты, аккаунт-директор, вдруг считаешь, что по какой-то причине мы в тендере не победим, не надо в него вообще лезть. Поэтому, вообще, если говорить про продажи, продажи в нашем текущем состоянии – это очень дорогая история, поэтому проиграть в этой дорогой истории, значит, потерять много денег.
Почему она дорогая? Во-первых, в продаже участвуют практически все топ-менеджеры, т.е. все руководители различных направлений, все, кто обладает максимальной экспертизой. Если мы приезжем к клиенту, мы должны полностью раскрыться, мы должны показать, что таких, как мы, больше нет – это первое. Второе – во время продажи существует огромное количество политики. Мы должны обязательно разобраться, кто на стороне клиента будет присутствовать на всех встречах, кто заинтересованное лицо, у кого из представителей клиента какие интересы личные и общие. Дальше мы должны разобраться, кто из наших конкурентов участвует в этом тендере, мы должны понять, какие у них сильные и слабые стороны, мы должны подготовить нашу стратегию продажи в конкретном случае так, чтобы представить себя максимально сильно по сравнению со всеми конкурентами в именно этом случае. Если нужно, мы проведем аналитику по проекту, если нужно и мы поймем, что на стороне клиента хромает менеджмент, мы предложим ему сразу же на этапе тендера полностью взять менеджмент на себя. Если нужно, мы предложим ему возможность высадить десант к нему на сторону, чтобы убедить его в том, что мы максимально быстро добьемся необходимых сроков. Процесс продажи длинный, долгий, дорогой, и поэтому в нем надо обязательно побеждать.
Приблизительная статистика: на данный момент к нам входит около 200 качественных обращений в месяц, их стоимость в районе 80 млн. рублей в месяц. Внутрь мы берем лишь 20%, остальное уходит в партнерку.
После того, как вы разберетесь с тем, как много продавать, или вы уже на данный момент много продаете, и у вас с этим проблем нет, вы переходите в стадию, с которой сталкивается большинство компаний, и многие на этом этапе умирают.
Продавать много не так сложно. Очень сложно много производить. И чем дальше ты идешь, тем больше ты это понимаешь. Производить много, качественно и в срок очень сложно. Продать много – никаких проблем.
Так вот, как много производить?
Во-первых, как и с очередью продаж, такая же должна быть очередь в производстве. Если у вас нет очереди на производство, если все сразу же получают сервис, т.е. клиент обратился, и завтра уже начали его проект пилить, то это значит, что у вас все не очень хорошо, особенно, наверное, у вас все не очень хорошо с рентабельностью. Потому что если у вас нет очереди, значит, у вас есть простои. Если у вас есть простои, значит, вы теряете деньги. Добавочная стоимость у нас не очень большая, соответственно, любой простой фактически может убить всю рентабельность. Поэтому простои – убытки, очередь – прибыль. Но, опять же, не надо путать очередь с хаосом, многие не умеют работать с очередью.
Что значит очередь? Клиент должен сразу же получить понимание того, когда его проект запустится в производство. И существует много маленьких трюков, как это можно сделать, например, в договоре мы прописываем, практически в любом договоре, необходимые условия, что мы имеем право взять на себя месяц на формирование команды. Понятно, что в некоторых случаях, мы, смотря из загрузки производства, можем пойти навстречу клиенту и начать пилить проект до согласования договора, иногда мы можем использовать пункт про согласование договора до начала работ. Ты всегда имеешь право очередью управлять, т.е. у тебя очередь а) должна быть, б) ей надо уметь управлять, чтобы не возникал хаос.
Как же после того, как мы заключили контракты, как после этого у нас строится производство? В первую очередь, менеджер нарезает весь проект на его этапы. Все это у нас вначале было в табличке, мы называли это «табличка отгрузок». Заключили контракт – в табличку отгрузок попали все этапы, каждый этап актом закрывается, у каждого этапа есть стоимость. После этого, как только проект нарезан, каждый из представителей заинтересованных подразделений, предположим, руководитель дизайна, проектирования, разработки, каждый из них обязан предоставить ресурсы, он должен прямо в табличке отобразить, а, собственно, кто будет трудиться на этом проекте. И он дальше должен таким же образом обеспечить рентабельность этого производства.
Фактически сейчас мы пришли к тому, что у нас есть себестоимость, т.е. есть ресурс на этот кусок работы, и есть стоимость этих производственных работ, себестоимость. И дальше есть понятная итоговая сумма, сколько по акту мы получим денег. Т.е. мы можем автоматически просчитывать рентабельность каждого куска, но, самое главное, что мы не просто рентабельность просчитываем, самое главное, что мы можем планировать загруженность каждого ресурса. Фактически мы можем после такой истории выводить Ганта не просто по проекту, а можем по каждому сотруднику – видеть, как у нас загружены внутренние сотрудники, внешние и т.д.
Вообще, в какой-то момент мы поняли, что ресурсы – это такая интересная штука… Ресурсами я называю всех конечных исполнителей, которые не занимаются управлением, которые занимаются непосредственно производством, неважно, кто это – проектировщик, дизайнер, разработчик, тестировщик. Ресурсы – это очень интересная сущность, их иногда бывает очень много, иногда бывает очень мало, чаще бывает очень мало, но это если вы быстро растете. В какой-то момент, если вы вдруг не растете, у вас их становится больше, если вы падаете по оборотам и по заказам. Как только мы поняли, что ресурсы – это единица, которая должна быть самой масштабируемой в компании, потому что если у тебя растет сильно вдруг загрузка… А загрузка никогда не бывает линейной, никогда не бывает стабильной, она всегда падает или увеличивается – это постоянная амплитудная история. В общем, ресурсы должны очень быстро под эту историю адаптироваться. Поэтому у нас существует несколько критериев по ресурсам:
- Первое – это внутренние, штатные ресурсы. У нас есть правило, что все штатные ресурсы всегда должны быть подкреплены full-time контрактом. Грубо говоря, если у нас есть внутри единица, которая занимается непосредственно производством, она должна на 100% времени быть выкуплена клиентом. Это первое.
- Второе – такое понятие как кадровый резерв. Этому тоже надо уделять большое внимание. Грубо говоря, списки самых классных сотрудников моих конкурентов у меня всегда есть, я знаю, в кого из них всегда пальцем тыкнуть, когда нужно очень быстро масштабироваться.
- И третье, в какой-то момент мы поняли, что нам нужна большая команда субподрядов.
На данный момент у нас за 4 года создана целая федеральная сеть субподрядных компаний, 80 компаний в ней участвуют. В общем, эта сеть субподрядчиков позволяет нам быстро масштабироваться. Если рисовать, видно как протекает у нас загрузка (в виде волны). Минимум загрузки мы всегда обеспечиваем внутренними ресурсами, все амплитуды мы покрываем аутсорсом. Даже если аутсорс по деньгам менее выгоден, вы вдруг посчитали, что вам внутреннего человека дешевле содержать, то эти амплитуды показывают, что простой вашего внутреннего человека в результате всю эту рентабельность убьет, поэтому лучше амплитуду покрывать внешними командами. Но, опять же, речь идет об аутсорсе только исполнителей, все управленческие функции тимлида – все должно быть внутри.
Как все сейчас управляется в AGIMA? В какой-то момент мне кто-то рассказал про такую систему, я назвал это «системой бабочки», где мы имеем несвязанные, неподчиненные друг другу два кластера людей:
Первый – это вся экспертиза, которая существует в компании. И второй – это вся управленческая команда, которая есть в компании. Они друг другу не подчиняются. Вся экспертиза состоит из руководителей основных экспертных направлений, скажем, руководитель отдела аналитики, руководитель отдела юзабилити, руководитель отдела дизайна и т.д. Под каждым из них есть свои специалисты. То же самое в управленческой команде. Есть четыре аккаунт-директора, под каждым из них есть PM различного рода (сейчас расскажу, какого плана PM у нас бывают). И они взаимодействуют между собой с помощью команды администрации. Я являюсь представителем команды администрации, различные арбитражные функции команда администрации тоже выполняет, когда вдруг возникают какие-то конфликты. Такая система позволяет нам быть очень устойчивыми. С одной стороны, у нас есть экспертиза, которую мы постоянно наращиваем внутри, и которая никак не зависит от менеджмента. С другой стороны, у нас есть крепкая менеджерская команда, внутри которой может какая-то текучка линейных PM’ов происходить, но при этом мы сохраняем основных аккаунт-директоров, которые ведут основные клиентские портфели.
Что из себя представляют руководители направлений «экспертизы». Руководители направления «экспертизы» – это самые главные эксперты. Вы можете этих экспертов постоянно видеть на конференциях, от нашего имени выступающих. Каждый из них – это самый высокоуровневый эксперт не только в компании, но и на рынке мы такого позиционируем. Под ним трудятся эксперты, которые у него учатся, эти люди отвечают и внутри, и снаружи за то качество продукта, которое мы даем на каждом этапе производства. Инфраструктура в отделах «экспертизы» выглядит следующим образом:
В основном, у каждого более-менее крупного подразделения у руля стоит выдающийся эксперт, у него есть заместитель, на нем больше такие исполнительные функции, т.е. он больше занимается организационными вопросами, арбитражными вопросами внутри цеха. Дальше есть ресурс-менеджер, если это совсем большой отдел. Ресурс-менеджер непосредственно занимается только тем, что он, как я уже сказал, есть план по отгрузкам на определенный проект, который менеджер поставил, так вот ресурс-менеджер в отделе экспертизы подбирает ресурсы изнутри, снаружи, он обеспечивает на 3 месяца вперед, как минимум, любой проект ресурсами заранее. Дальше есть тим-лиды – это наша гордость. В любом цеху у нас есть тим-лиды – разработка, дизайн. Тим-лиды называются у нас арт-директорами и т.д. В общем, тим-лиды – это такие практически специалисты, как руководители отдела. На самом деле, надо понимать, что в какой-то момент, вдруг, руководителя отдела может не стать. Будем надеяться, что они все будут долго жить, но тем не менее. Поэтому у вас всегда есть замена. Тим-лиды – это фактически точно такие же управленцы, такие же руководители основного цеха, поэтому, во-первых, это подрастающая смена, во-вторых, это та команда, которая непосредственно управляет ресурсами. У каждого тим-лида в подчинении свои собственные проекты и своя команда, ну и, в общем-то, ресурсы.
Дальше, руководители групп менеджеров, те самые аккаунт-директора. Что из себя представляют они?
Это самые опытные менеджеры проектов. У каждого из них за плечами 10-тилетняя история управления проектами, управления различными менеджерами. Это самые опытные люди, которые повидали сотни проектов. Им продать проект, или разрулить какую-то проблему – ничего не составляет. У каждого из них в подчинении своя команда менеджеров, у каждого из них в управлении свой клиентский портфель, и их основной KPI – увеличивать объем этого клиентского портфеля. Их система мотивации устроена очень просто: чем больше у тебя клиентский портфель, тем больше ты получаешь.
Что из себя представляет инфраструктура в отделах менеджмента?
Во-первых, в отделах менеджмента, если мы говорим о большом проекте. Например, у нас есть один из проектов, который в год у нас приносит только на производство в районе 50-60 млн. рублей. На этом большом проекте у нас создана следующая инфраструктура:
- Во главе стоит Product Owner. Фактически это менеджер, который является представителем заказчика на нашей стороне, т.е. это наш человек, но этот человек постоянно катается то к заказчику, то к нам. Его задача – формировать длинный лист задач, т.е. чтобы всегда была очередь из задач именно по этому проекту.
- Дальше есть проджект-менеджер или проджект-менеджеры, между ними по-разному могут делиться куски работ, могут делиться роли, кто-то может быть джуниором, сиром – не важно.
- И такая еще есть история, которая называется «менеджер первой линии». Когда она у нас появилась, мы очень начали этому радоваться, потому что мы смогли обеспечивать SLA. У любого заказчика на любом проекте рано или поздно возникает следующая ситуация: «Вы мне не пилите баги, потому что вы запускаете новый функционал». Или наоборот: «Вы запускаете новый функционал и не можете допиливать баги». Проблема легко решается – мы заключаем поддержку с клиентом, есть SLA некий, в течение которого мы обеспечиваем время реагирования в течение, скажем, 15 минут, обеспечиваем некие основные принципы обработки большого количества задач быстро. Эти принципы у нас зафиксированы как с клиентом, так и с сотрудником – менеджером первой линии. Его задача обработать весь входящий поток вопросов. Чтобы вы приблизительно понимали, менеджер первой линии на этом крупном проекте у нас в день обрабатывает 250 писем от приблизительно 15-16 представителей заказчика. Задача – по быстрым письмам сразу дать ответ, по более долгим письмам – передать менеджерам второй линии – проджект-менеджерам, их пропинговать, убедиться, что они дали ответы. В общем, он отвечает, в основном, за коммуникации.
Чем дальше вы идете, чем больше у вас процессов возникает, они могут быть абсолютно разные, не надо пытаться под ваши процессы подтянуть ваш бизнес, скорее пытайтесь ваш бизнес понять, как он растет, и под него заточить или описать бизнес-процесс. Так вот, мы начинаем сразу описывать, как мы их называем, «правила игры». Эти правила игры фиксируем в wiki. Там же все могут их комментировать и т.д.
Автоматические некоторые процессы, которые мы регламентируем, вырастают в автоматизированные процессы. Например, как с переговоркой – сначала мы просто писали на стенке о том, что нам нужна переговорка, потом мы начали использовать google docs, потом у нас появилась автоматическая система Битрикс 24, мы начали ставить галочку. Дальше то же самое происходит с, например, системой отпусков. Т.е. все мелкие процессы, которые у нас требуют постоянного внимания, просто автоматически в какой-то момент перерастают в программную систему. Там ничего сложного нет. Более сложные процессы остаются просто описанными регламентами в нашей wiki.
Еще важную вещь мы поняли, что, несмотря на то, что кажется всем очевидным, что вроде бы пришел новый сотрудник, чего там разобраться в том, что как у нас работает. На самом деле на изучение правил игры требуется достаточно много времени. Поэтому делаем следующим образом: как только мы взяли сотрудника, он даже еще не вышел на работу, мы уже его после подписания NDA, пускаем в нашу wiki, и в некоторых разделах он должен обязательно изучить всю информацию, т.е. все, что касается офисов, все, что касается workflow – все это он должен знать. Когда он придет на работу, в первый же день мы его начнем тестировать, мы у него сразу будем спрашивать, а как работает это, к кому ты подойдешь за таким-то вопросом и т.д. Он все это должен знать, чтоб он сразу с первого дня был подготовлен.
Помимо этого, мы еще у себя в какой-то момент внедрили различные тесты на входе, чтобы сразу отсеивать людей по IQ. Сейчас у нас появляются тесты на психотипы и т.д., тесты на умение правильно формулировать свои мысли. Всякие правила игры для вступления и для работы сотрудник должен впитать сразу.
Вообще, когда спрашивают, а что собственно нужно регламентировать или автоматизировать? Я всегда отвечают так: если вы считаете, что вам ничего не нужно регламентировать или автоматизировать, не надо ничего ни регламентировать, ни автоматизировать. Все это появляется само. Как только к вам начинают люди постоянно подходить с одним и тем же вопросом, вы ответите на него один раз, второй, третий… На четвертый вы поймете, что лучше это где-то записать. На пятый вы, наверное, поймете, что лучше какой-то тест дать и т.д. Т.е. как только у вас возникает много постоянной однотипной работы, автоматизируйте ее, превратите ее в процесс.
Была ошибка у нас одна, когда 4 года назад мы начали писать регламенты. Я, вообще, всегда стараюсь строить нашу компанию демократичной – все равны, все имеют право на свое мнение, каждый имеет право управлять командой, поэтому я решил, что любой регламент, который я придумаю, я буду согласовывать со всеми топ-менеджерами. Я называл это «Совет директоров». И мы каждый понедельник в 10 утра собирались с советом директоров. Перед нами лежал регламент. Я, вообще, по образованию юрист, поэтому я очень любил эту законотворческую деятельность – кто-то, значит, формирует законопроект, потом мы садимся, его обсуждаем, потом мы за него голосуем – такой цикл утверждения законопроекта в закон. В общем, все это превратилось в бюрократическую фигню. Каждую неделю мы собирались этим важным советом директоров, сидели, занимались какими-то глупостями, потом забывали про эти регламенты. И я понял, что на самом деле лучшие регламенты формируются очень просто – заинтересованный в регламенте человек (это может быть любой человек, это может быть просто девочка на ресепшне – кто угодно, кто хочет у нас в компании внедрить какие-то правила) формирует правила игры, законопроект этот. Потом согласовывает его с теми людьми, которых этот законопроект будет касаться непосредственно. После того, как это согласовано, он просто подходит к своему руководителю и говорит: «Вот правила игры, они согласованы с таким-то ребятами, почитай». Руководитель почитал, принял, все. Дальше, после этого люди имеют право комментировать. Конечно же, имею я право вето, вдруг, если что-то произойдет, но я им редко пользуюсь. Т.е. фактически правила игры формируются сами, автоматически, люди их комментируют, т.е. видно общественное мнение, такая вот демократическая управленческая штука.
И, конечно же, нужно понимать, что в любом эффективном управлении есть две основных части: первая – это постановка задачи, вторая – это контроль ее выполнения. Контроль выполнения любой задачи – это отчетность.
Отчетность нужно собирать, нужно требовать, нужно не лениться ее изучать. Отчетность начинается с проектов. На всех проектах должны быть Ганты, на проектах надо видеть, сколько часов планируется, кто эти часы должен вырабатывать, на сколько этот сотрудник реально живой, здесь и готов работать. Мы должны видеть по каждому сотруднику его выработку, сколько часов он производит, насколько его эффективность. Если он постоянно производит мало, то мы можем какие-то вопросы задавать по этому сотруднику. Мы можем видеть работу каждого отдела, насколько рентабельны отделы, насколько, возможно, в будущем рентабелен отдел, его историю и т.д. И, конечно же, управленческая отчетность. Чем дальше вы будете в различные стороны шагать, не просто наращивая внутри объем, а взаимодействие с другими компаниями, поглощая какие-то компании, управленческая отчетность будет становиться все сложнее.
Пара слов про развитие. Как я, вообще, считаю, мы должны развиваться дальше.
Во-первых, конечно же, создавая новые направления.
Мы четыре направления за последние два года запустили, мы очень активно их прокачиваем. Я считаю, нужно из одной услуги и, особенно, если ты уже подошел к потолку объемов по этой услуге, из услуги выходить дальше в дополнительные смежные отрасли. И поэтому мы создаем новые направления у себя, эти новые направления качаем и, понятно, что у каждого направления чуть-чуть другие бизнес-процессы внутри, и не надо этого бояться. Вы сами потом поймете, как они должны с вашей системой взаимодействовать и т.д. Главное – не надо натягивать какие-то существующие шаблоны уже на новый бизнес, потому что новый бизнес – это всегда эксперимент.
Дальше у нас появляются такие истории, например, что направление AGIMA.mobile у нас выделилось в отдельную компанию AGIMA.mobile. Сейчас недавно мы слились со старым игроком на рынке мобильных разработок Галс Софт. Теперь у нас компания называется Agima.mobile/Gals, и вопрос: как этим управлять, если у нас уже есть внутренние какие-то бизнес-процессы внутри AGIMA?
Поэтому, как только ты начинаешь понимать, что вроде бы задействовано несколько юр. лиц, там должна чуть сложнее становиться управленческая отчетность. Самое главное даже возникает на уровне взаимодействия. У нас часто, как только AGIMA.mobile стал отдельным юридическим лицом, отдельной компанией, у нас сразу возникли вопросы у многих сотрудников: AGIMA.mobile – это, вообще, AGIMA? Как нам взаимодействовать, на чьей стороне будет менеджер? Т.е. много вопросов, которые тебе задают. Опять же, если их тебе задают постоянно, вопросы одни и те же, ответы на них зафиксируй в правилах. Правила могут поменять потом, ничего страшного, все ошибаются. Если вопрос один раз задали, необязательно из этого рождать какие-то правила, необязательно это превращать в процесс.
Еще раз призываю всех – не нужно стараться расти лишь увеличением мощности, производственных ресурсов, нужно расти, рождая различных «дочек», поглощая другие компании, открывая новые направления, превращая их в отдельные бизнесы. И не нужно бояться того, как этим потом управлять – вы сами потом разберетесь. Начинайте с простых инструментов, не тратя на это много денег – с почты, с просто общения. И потихонечку фиксируйте все. Я пришел к тому, что любой процесс ты сначала фиксируешь, потом делегируешь, потом со стороны смотришь, а как он работает, что-то подтюнишь и все превращается в процесс, в регламент и это достаточно хорошо работает.
Ну и, самое главное, что, вот, я недавно слышал, что какие-то компании управляются роботами. Я все-таки считаю, что если компания управляется роботами, она никогда не сможет стать уникальной, она никогда не сможет стать не такой как все, она не сможет сделать резкого скачка. Все очень просто, потому что, какие бы бизнес-процессы, какую бы программу вы не заложили, все равно все будет упираться в людей. Поэтому я сделал акцент на то, что у меня сформирована сильная команда лидеров AGIMA, топ-менеджерский состав. Фактически каждый из этих людей может придумывать свои бизнес-процессы в компании, может свою систему управления внедрять, я с ними не спорю. И на самом деле между всеми топ-менеджерами в компании существует доверие, мы понимаем, что у нас общий вектор, у нас есть общие цели. И если мы в этом расходимся, то никакие бизнес-процессы нам точно не помогут навести порядок.
Помимо этого, хочется пожелать каждому из вас соответствовать росту своей компании, расти самому. Учить английский, если вы вдруг до сих пор его не знаете, потому что в какой-то момент вы упретесь в контракт своей мечты, в котором вам понадобится английский, и вы его не получите, потому что вы не знаете английский. Или заниматься спортом, например, и проповедовать спорт в массы, потому что здоровые сотрудники значительно эффективней, чем сотрудники, которые бухают каждый день. Я действительно рекомендую – занимайтесь спортом, тратя на это много времени.
Этот доклад — расшифровка одного из лучших выступлений на конференции по управлению проектами и предпринимательству WhaleRider.
Кстати, пора рассказывать о том, что мы для вас приготовили в этом году — конференция WhaleRider 2017 уже через месяц — 5 и 6 июня.
Михаил Трутнев, исполнительный директор компании Ultimate Guitar, расскажет о…
Рок-н-ролл и Способ работы, при котором прибыль растет каждый месяц
Очень спорный доклад! Вот, например, некоторые (не все) рекомендации Михаила:
Краткое содержание доклада:
- Предлагать идеи — не право, а обязанность каждого сотрудника;
- Без постоянных команд и должностей;
- К черту KPI;
- Разработчик (аналитик, дизайнер) должен быть одновременно или продуктовиком или продажником;
- Расформировали Q&A!
Ну так же нельзя! Это не будет работать! Но у Михаила есть железный аргумент — результат, это работает! Поэтому мы обязательно будем слушать Михаила и спорить с ним на конференции.
Автор: olegbunin
