Повышаем рентабельность digital-студии без крови и репрессий27.06.2019 15:47

В штате WebCanape — 90 человек. Управлять таким количеством сотрудников и контролировать их не у всех получается хорошо. Из-за неэффективного управления может проседать качество услуг компании, снижаться рентабельность проектов, ухудшаться общий климат в офисе. Чтобы этого избежать, мы внедрили у себя мониторинг эффективности работы сотрудника.

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

Эта система дала нам возможность:

• увеличить скорость выполнения задач и сократить сроки сдачи проектов;
• строить реальные прогнозы загрузки производства на месяц вперед;
• прогнозировать потребность в новых сотрудниках и планировать набор персонала;
• внедрить инструмент управленческой отчетности;
• вывести более 90% проектов в зону рентабельности.

Сейчас расскажем, как мы в этому пришли.

Архитектура системы мониторинга эффективности в WebCanape

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

• Учет трудозатрат. Для этой цели используем Redmine. Здесь мы ставим задачи друг другу и отбиваем затраченное время по каждой.
• Учет времени нахождения на рабочем месте. У каждого сотрудника WebCanape есть индивидуальный электронный ключ, которым он открывает дверь, чтобы попасть в офис. Мы установили систему контроля доступа Bolid, которая собирает все данные о входе и выходе сотрудников. Так мы знаем, сколько времени каждый человек находится в офисе.
• Мониторинг производства в Canape STAT — собственная разработка WebCanape. Сюда собираются все данные по трудозатратам из Redmine и сведения о времени на рабочем месте от СКД. Так у нас появляется полная картина по всем сотрудникам, а также по загруженности отделов (количестве часов/задач на отделе и на каждом сотруднике).
• Контроль рентабельности в Canape CRM (тоже разработали сами). В систему попадают данные по всем трудозатратам из Redmine, и мы можем отследить, когда проект попадает в зону риска, то есть количество отработанных часов вот-вот превысит оценочное время.

Подробно о каждом инструменте и об их работе далее.

Структура штата WebCanape: чье время и как мы считаем

Из 90+ штатных сотрудников студии около 30% составляют менеджеры. Остальные — производство и административный персонал.

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

• Выполнение задачи.
• Коммуникация по задаче.
• Самообразование.

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

Трудозатраты административного персонала учитываются по времени нахождения в офисе.

Характер работы менеджера сильно отличается от характера и состава задач других сотрудников. Потому мы не считаем время, которое уходит на выполнение работы менеджерами и аккаунт-менеджерами. Мы отказались от учета их трудозатрат, потому что если менеджер ведет более 10 проектов (а у нас в WebCanape получается примерно так), то при ручном отслеживании времени разрастается время на переключение между системами. Автоматизировать этот процесс мы пока не стали, потому что считать время телефонных переговоров, коммуникации в почте, постановки задач автоматически в условиях нашей инфраструктуры оказалось непросто. Да и сейчас это не является для нас приоритетом — отдел внутренней разработки загружен релизами новых версий Canape CMS.

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

Как мы интегрировали системы учета в бизнес-процессы компании

К текущей системе мы пришли не сразу. Сначала решали проблемы точечно, а затем объединили все решения в комплекс.

	Проблема	Решение
1	Затягивание сроков по проектам Вроде все работали как обычно, но все чаще сроки сдачи проекта срывались. Нужно было понять, на каком сегменте цепочки проблема. Штат: до 20 человек	Учет времени разработчиков Чтобы понять, где образуются дыры, мы стали учитывать время, затрачиваемое разработчиками, анализировать его и корректировать структуру задач и регламенты работы.
2	Превышение оценочного времени по проектам Когда начали четко контролировать время разработчиков, часов, которые закладывали в проект при продаже, стало не хватать, и проекты оказывались нерентабельными. Штат: 35 человек	Подсчет рентабельности проектов Анализ рентабельности проектов позволил нам скорректировать оценку трудозатрат по проектам и вывести более 90% в зону рентабельности.
3	Отсутствие консолидированных данных по загрузке производства Проектов становилось все больше, сроки нужно было выдерживать, производство начало «задыхаться». Одни отделы были загружены на несколько недель вперед, другие сдали большую часть проектов и оказывались недозагружены. Не хватало сводных данных по нагрузкам на каждый отдел, чтобы можно было грамотно распределить работы по проектам. Штат: 40 человек	Визуализация данных по трудозатратам и нагрузкам Для визуализации всех данных по загрузке сотрудников мы разработали собственный сервис, куда попадали данные из Redmine. Отображение всех сведений оформлено в виде тепловой карты, где цветовым кодом обозначена недозагрузка/перегрузка конкретного сотрудника/отдела.
4	Расширение штата —> сложно контролировать С повышение рентабельности мы стали быстрее развиваться, больше вкладывать в маркетинг, что вылилось в увеличение потока заявок и, как следствие, расширение коллектива, чтобы эти заявки обрабатывать и отрабатывать. Появилась потребность в автоматизации контроля сотрудников. Штат: 60 человек	Интеграция с системой контроля доступа Большим коллективом сложно управлять. Чтобы поддерживать трудовую дисциплину на уровне, мы стали учитывать время нахождения людей в офисе. Все наши сотрудники официально трудоустроены в штат компании. Данные о трудозатратах, количестве задач и времени на рабочем месте объединили в одну систему и получили наглядную картину по отделам.
5	Увеличение объема заказов → потребность в оптимизации работы С увеличением объема заказов стало недостаточно просто считать рентабельность и время нахождения людей на работе. Захотелось оптимизировать процессы так, чтобы обрабатывать больший объем заказов без расширения штата. Штат: 90 человек	Решение выявленных проблем и оптимизация работы Нам стало интересно, как сделать заказы рентабельнее и сократить сроки выполнения. На этом этапе мы стали искать «тонкие места» в производстве и продумывать способы оптимизации, чтобы в дальнейшем зарабатывать еще больше.

Рассмотрим подробнее, какую работу мы провели на каждом из этих этапов.

Шаг 1. Считать трудозатраты

Начали мы с малого — ввели таск-трекер. Не стали внедрять никакие дополнительные таймеры, все делали в Redmine и собственной CRM. Это дало понимание, сколько времени уходит на конкретную задачу. Все это нормировали — появились нормативы по типам задач.

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

Шаг 2. Следить за рентабельностью и сроками

Для учета рентабельности и контроля сроков по проектам мы давно разработали собственную систему управления проектами Canape CRM, в которой ведем все услуги компании: от разработки до продвижения сайтов.В договоре по каждому проекту прописаны сроки сдачи. Эти сроки мы визуально представили в CRM.

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

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

На основе этих данных несложно сделать вывод об эффективности каждого менеджера. Видно, сколько каждый сдал проектов, сколько из них — в срок, сколько заработал для компании.

Это открытая статистика — сотрудники могут видеть, кто справляется лучше, а кто хуже. В CRM-системе автоматически выстраивается рейтинг.

Не секрет, что главное офисное противоборство — это противоборство менеджера с разработчиком. Как быть, если разработчик затягивает сроки по проекту? Мы вышли из этой ситуации, зашив количество проектов и сроки их сдачи в KPI менеджера и разработчика. Так менедджер всеми силами старается контролировать разработчиков, чтобы те не превышали свои сроки по задачам и сдавали их вовремя. Своевременность сдачи проектов мы стали учитывать и при переводе разработчиков на следующий грейд.

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

Мы видим отзывы, которые оставляют клиенты. Если не укладываемся по срокам — предупреждаем и объясняем причины. Сейчас это контролирует руководитель производства.

Шаг 3. Визуализируем нагрузки

После предыдущего шага остались некоторые проблемы, одна из которых заключалась в том, что у нас не было данных по загрузке отделов. Мы не знали и не могли спрогнозировать, когда, например, верстальщики разгребут очереди и смогут снова брать проекты. То есть все эти данные у нас фактически были, но в разрозненном виде. Интерпретировать их правильно не получалось.

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

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

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

Шаг 4 — интегрируем со СКУД

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

Теперь мы видим, сколько времени человек потратил на задачи и сколько он находился в офисе при этом. Это позволяет исключить манипуляции с трудозатратами. Если сотрудник находился на рабочем месте 6 часов, а в задачах проставил 10 часов, у руководителя или контролирующего возникнут вопросы. Система также помогает поддерживать дисциплину труда. Мы видим, кто постоянно опаздывает, а кто приходит вовремя. Когда в офисе больше 50 человек и они рассажены по двум этажам и разным кабинетом, за такими вещами сложно уследить.

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

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

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

Шаг 5 — оптимизируем процессы

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

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

Менеджеру и разработчику не нужно уточнять друг у друга, кто, когда и какую задачу будет делать. Все есть в системе. Задачи со статусами «Оценка» (нужно дать ответ новому клиенту) и «К выкладке» (когда нужно что-то выложить на живой сайт) по умолчанию идут первыми. Есть задачи со статусом «Не продано». Это значит, что проект точно будет запущен, на него нужно отвести время, но приступать к задаче пока нельзя, потому что какие-то данные по нему еще уточняются. В задачах также предусмотрена метка «Приоритетная» — это самые срочные задачи, и такую метку может выставлять только руководитель отдела.

К чему мы пришли

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

• Повышение скорости выполнения задач и сдачи проектов.
• Прогноз загрузки производства на месяц вперед.
• Прогноз потребности в кадровых ресурсах.
• Инструмент управленческой отчетности.
• Более 90% проектов в зоне рентабельности.
• Еще один внутренний сервис :(

Последний пункт нас не очень радует, но когда мы начинали этот процесс, ни Битрикс, ни AmoCRM не было. Мы писали собственный инструмент под себя без опоры на внешние сервисы. Если бы такие проблемы стали перед нами сейчас, мы бы, конечно, искали решение на стороне, а сегодня это наше «узкое» место. На поддержание и усовершенствование системы требуется много ресурсов, сил разработчиков. Однако есть и положительный момент — это серьезный вызов для новых сотрудников. Они прокачивают свои скиллы на наших внутренних продуктах.

Логика системы учета рабочего времени WebCanape

• Не мешает рабочему процессу.

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

• Охватывает всех сотрудников.

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

• Открыта для всех.

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

• Возлагает ответственность на руководителей отделов.

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

• Строится вокруг рентабельности.

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

• Внедряется поэтапно.

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

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

Сейчас мы готовим еще один материал о том, как и для чего мы разработали собственную CRM. Подписывайтесь на канал в Telegram, чтобы не пропустить.

Полный текст статьи читайте на CMS Magazine