Операционное управление — это то, во что я вернулся сам

Чем операционка отличается от стратегии

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

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

Почему собственники снова входят в операционное управление

У меня две причины, и обе из жизни. Первая — новые налоги: учёт приходится пересобирать под них. Вторая — погрешности, которые раньше были допустимы, теперь съедают маржу. Когда рынок растёт, неточность в пару процентов незаметна. Когда рост замедляется, она превращается в убыток.

Учёт и отчёты: фундамент

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

Второй шаг — дашборды и автоматические отчёты. Один из самых полезных у меня очень простой: список проектов, по которым больше 7 дней не было расходов. Маленькие расходы на проекте — индикатор, что он не будет закончен вовремя. Люди не работают над ним, а значит, срок уже под угрозой, хотя формально всё зелёное.

Какие отчёты нужны руководителю каждую неделю

Набор зависит от бизнеса, но для компании, которая продаёт часы команды, я бы начал с пяти.

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

Одна система или связка систем

У нас продажи живут в amoCRM, учёт — в таблицах, проектное управление — в Планфиксе, бухгалтерия — в 1С. Собрать всё по одному клиенту — отдельная задача, и честно, тяжёлая.

Заменять всё одной системой обычно дороже и дольше, чем связать существующие. Я бы шёл от общего идентификатора клиента, для компаний удобнее всего ИНН, и от регулярной выгрузки в одно хранилище, где строятся отчёты. Тогда каждая команда работает в привычном инструменте, а руководитель видит сводную картину.

Одно место для договорённостей

Договорённости и встречи у нас были разбросаны по пяти местам: Планфикс, Яндекс Календарь, Google Календарь, закреп в Телеграме и отдельные таблицы. Каждое по отдельности удобно. Вместе они гарантируют, что кто-то пропустит изменение.

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

Люди и роли

Самые долгие изменения в операционке касаются не систем, а людей: как им платят и кто за что отвечает.

Мотивация менеджеров от рентабельности проекта

За годы у нас накопилось легаси в бонусах. У старых сотрудников была одна схема мотивации, у новых — другая. Теперь у всех менеджеров бонус зависит от рентабельности проекта.

Почему не от выручки: выручка подталкивает продавать что угодно, в том числе проекты, на которых компания теряет деньги. Рентабельность связывает интерес менеджера с интересом компании. Но у такой схемы есть условие — точный учёт затрат. Без него спор о бонусе превращается в спор о цифрах.

PM и техлид: Discovery и Delivery

Отдельно прорабатываю ответственность связки менеджера проекта и техлида. По совету Ивана Поддубного из Вебпрактик смотрим в сторону разделения на Discovery и Delivery. Discovery — этап, где выясняют, какую задачу на самом деле решает проект, что войдёт в объём и какие риски есть. Delivery — разработка и сдача того, о чём договорились. К этому дуэту хорошо подключаются аккаунт-менеджеры, которые держат отношения с клиентом.

Зачем делить. Когда один человек и выясняет задачу, и сдаёт результат, ему выгодно закладывать в объём то, что легко сделать, а не то, что нужно клиенту. Раздельная ответственность делает разговор об объёме честнее. Ещё один плюс — Discovery можно продавать отдельным этапом с понятной ценой, и клиент не платит за разработку, пока не ясно, что именно строить.

Ошибки, которые я вижу в операционке

Большинство проблем повторяются от компании к компании. Вот те, что встречаются чаще всего.

• Отчёт есть, но его никто не открывает: нет дня недели, когда на него смотрят, и человека, который задаёт вопросы.
• Метрики считаются по-разному в разных отделах, и спор идёт о цифрах, а не о решениях.
• Новая система вводится поверх старой, а старую не отключают. В итоге данные расходятся в двух местах.
• Правила мотивации меняются задним числом. Это быстрее всего убивает доверие менеджеров.

Бюджет и гипотезы роста на следующий год

Последний блок — деньги на будущее. Я сокращаю расходы и собираю бюджет на следующий год, ищу, за счёт чего можно сохранить стоимость часа и проектов или поднять её умеренно.

Параллельно собираю гипотезы роста. Вспоминаю разговоры с клиентами за год, слушаю экспертов, разбираю, какие лиды к нам приходили, — их за год было больше 200. Для взгляда со стороны я нанял консультанта с большим опытом управления, Александра Шибаловского, он работал в Nexign директором по внедрению и заказной разработке.