{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Где деньги, или Финансовое планирование SaaS-проекта

Как подступиться к финансовому планированию, если вы взялись за него в первый раз.

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

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

Речь пойдёт об экономике SaaS-проектов: для других бизнесов и PnL, и расчёты могут выглядеть по-другому.

Зачем сотрудникам думать об экономике проекта

В том, чтобы сотрудники думали об экономике проекта, компания видит свой интерес. Бизнес не может постоянно инвестировать в бесперспективные, убыточные идеи. Компании нужно, чтобы инвестиционные решения по продуктам и проектам принимались с учётом экономики. Что мы получим, если будем вести разработку исключительно из соображений «сделать хорошо для пользователя»? Как можно больше фичей, и желательно бесплатно.

«Чтобы не вкладываться в продукты, которые не принесут денег, нужно, чтобы люди понимали, как их работа влияет на финансовые показатели всей компании. Как этого добиться? Можно приставить экономиста к каждому, кто ведёт проект – а можно дать всем сотрудникам немного экономического бэкграунда и простимулировать использовать эти знания. Мы выбрали второй путь».

Евгений Левин, Chief Strategy Officer, SEMrush

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

Дальше речь пойдёт о тех финансовых инструментах, которыми пользуются наши сотрудники для ведения своих проектов.

PnL – главный финансовый артефакт проекта

У любого проекта есть набор артефактов: например, организационных (бэклог задач) или коммуникационных (регулярные встречи). Главный финансовый артефакт проекта – PnL (Profit and loss statement). В нём сводят все планируемые затраты и доходы. По тому, как вы подготовили PnL, становится ясно, насколько глубоко вы проработали потенциал проекта, учли ли все проблемные места.

Разберём на примере, как устроен PnL. Будем двигаться по документу сверху вниз, шаг за шагом вычитая из линий, подсвеченных жёлтым, параметры, перечисленные под ними.

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

Следующая строка называется Revenue (выручка). Теперь понятно, почему Revenue также называют top line: это самая верхняя линия в PnL.

Начинаем вычитать из выручки обязательные расходы. Сначала – те, что расположены прямо под верхней линией. Эти расходы являются функцией от revenue: если выручка вырастет на 10%, эти расходы, скорее всего, тоже увеличатся на 10%. Что мы туда включаем:

  • Комиссию платёжных систем (оплатить наш инструмент можно только онлайн) – она составляет 2,5% и редко меняется.

  • Возвраты – деньги, которые мы сначала получили от пользователей, а потом вернули.

Деньгами до вычета этих расходов мы распоряжаться не могли, так как платёжные системы удерживают комиссию сразу, да и возвраты тоже «пощупать» нельзя. Когда мы вычли эти параметры из Revenue, то получили Net Revenue – деньги, которыми мы реально располагаем. Дальше вы увидите, что это «располагаем» включает в себя множество обязательных расходов. Важно помнить, что это SEMrush – SaaS-компания и это специфический для нашего бизнеса PnL.

Первый из расходов, которые мы будем вычитать, называется cost of service – сколько денег мы потратили, чтобы просто оказать сервис клиенту. Без этих затрат клиент не смог бы воспользоваться продуктом – или сделать это на должном уровне. Обычно сюда входят сервера и стоимость технической поддержки.

Следующая линия PnL называется Gross Profit – то, что осталось, когда мы вычли из Net Revenue стоимость сервиса. Эти деньги мы можем потратить на развитие бизнеса, то есть на увеличение выручки. Под этой линией располагаются расходы на продажи и маркетинг – то есть все затраты, направленные на увеличение выручки. Это и зарплаты специалистов по маркетингу и продажам, и расходы на рекламу.

Когда мы вычитаем всё это из Gross profit, получается то, что называется contribution margin. Это сумма, оставшаяся после того, как мы оказали сервис и вложили деньги в увеличение бизнеса. Её мы можем потратить на постоянные расходы компании (они обозначены в PnL как total operating expenses). В зависимости от специфики бизнеса, в эту сумму могут входить разные составляющие. Для нас это аренда офиса, административные расходы, зарплаты (за вычетом зарплат маркетологов и специалистов по продажам – они идут в contribution margin). Здесь же учитываются все затраты на подписки, HR-расходы, оплата услуг аудиторов и внешних консультантов.

После вычета всех фиксированных расходов мы получаем сумму под названием EBITDA – важный показатель именно для софтового бизнеса. Эта аббревиатура расшифровывается как earnings before interests, taxes, depreciation and amortization. Это прибыль компании до учёта так называемых interests – процентов по кредитам (выданным либо полученным), налогов (taxes), потери стоимости (depreciation) и амортизации. Со всеми ITDA разберётся бухгалтерия, а нам важно, сколько денег мы заработали до всех этих бухгалтерских манипуляций. Это наша основная метрика с точки зрения экономики проекта.

Когда мы смотрим на PnL из прошлого, то видим перед собой отчёт: что мы потратили и что заработали. Когда мы планируем новый проект, у нас такого отчёта нет – тут-то и начинается самое интересное. Нам нужно предсказать, как он будет выглядеть: сделать прогноз по выручке и затратам – и потом следить, как реальность сходится с нашими ожиданиями. Как это сделать?

Прогнозируем выручку

Часто встает вопрос, с чего начинать прогнозы – с выручки или с затрат? Ответить на него можно по-разному, в зависимости от обстоятельств.

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

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

Чтобы спрогнозировать revenue, надо собрать и проанализировать исторические данные (трафик, конверсии). Планируя SaaS-проект, нужно мыслить когортами. Когортой называют группу объектов, объединенных единым свойством – в случае SaaS это пользователи, пришедшие в один и тот же месяц. Пользователи из одной и той же когорты часто ведут себя похожим образом, поэтому когортами удобно пользоваться для анализа и прогнозов.

Выручку также можно рассчитывать по когортам. Мы принимаем за когорту месячную выручку, которую получаем от пользователя, привлечённого в конкретный месяц.

Пример когорты со случайными числами

Допустим, в январе 2017-го мы привлекли 1000 пользователей. В первый месяц на каждого из них мы получили 100 долларов. На следующий месяц часть пользователей отписалась от сервиса – активных пользователей в когорте стало меньше, и в среднем один пользователь заплатил нам уже где-то 95 долларов. При этом общее количество пользователей, привлечённых в январе 2017-го, не изменилось – это по прежнему 1000 человек. Получается, что числитель (выручка от всех пользователей, которые продолжают платить в текущем месяце) уменьшается, а знаменатель (количество пользователей, привлечённых в первый месяц) остаётся прежним.

Так мы рассчитываем когорту выручки для последующих месяцев: смотрим, сколько пользователей привлекли за май 2017-го, сколько денег они заплатили нам в июне, июле и так далее. Повторяем это упражнение для всех остальных месяцев, по которым у нас есть данные. Если у нас есть информация по когортам выручки за значительный период времени, можно рассчитать медиану по каждому первому, второму и далее месяцу. Так мы найдём базовую когорту и сможем использовать её при моделировании.

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

Теперь мы можем строить модель выручки для предстоящих месяцев. Нужно предположить, сколько будет новых платящих пользователей в интересующем нас месяце, и поочередно умножить их количество на каждый из месяцев базовой когорты. Допустим, в октябре 2018-го мы собираемся привлечь 2000 новых пользователей. Если мы умножим 2000 на базовую когорту, то поймём, сколько денег получим от этих пользователей в первый месяц, во второй и так далее.

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

Дальше нам нужно работать с переменными. Допустим, мы запускаем новый инструмент. Из исторических данных мы знаем, что похожие инструменты, размещённые в левом меню, собирают определённый трафик и имеют схожую конверсию. Мы решаем разместить новый инструмент в этой части меню. Дальше мы выбираем переменные и пробуем построить модель на их основе (например, смотрим, что будет, если у нового инструмента конверсия будет чуть больше или чуть меньше). На основе этой модели мы выдвигаем гипотезы: оптимистичный сценарий, пессимистичный и из рук вон плохой, а потом строим модель – набор формул с нашими переменными.

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

Например, у нас есть переменная про retention (удержание пользователей) – она будет выражаться определенной когортой. При оптимистичном сценарии когорта может быть на 5% выше, а при пессимистичном – на 5% ниже.

У нас есть ещё одна переменная – конверсия, которая может оказаться куда более чувствительной. Например, наша стандартная конверсия – 2% – если она повысится до 3%, это будет очень существенное изменение. Переменная конверсии будет иметь более высокую чувствительность, чем переменная retention. В этой ситуации стоит сосредоточиться на конверсии и провести эксперименты, чтобы лучше её понять.

Анализ чувствительности покажет, какую часть нашей модели нужно уточнить максимально. После этого мы можем ставить цели по выручке, причём сразу две. Первая – амбициозная (тот результат, который получится у нас при благоприятном стечении обстоятельств). Вторая – консервативная, которой с большой вероятностью можно достичь. Её мы и положим в бюджет.

Итак, мы разобрались, как устроен PnL SaaS-проекта – главной документ, где учитываются все доходы и расходы – и попробовали спрогнозировать выручку. Надеемся, что это упражнение было для вас полезным и однажды вы воспользуетесь описанными практиками для планирования своего проекта.

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

0
7 комментариев
Написать комментарий...
Михаил Корытов

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

Ответить
Развернуть ветку
Semrush
Автор

Спасибо за добрые слова! Нам очень приятно:)

Ответить
Развернуть ветку
Виктор Брежнев

Крутая статья! Будет круто, если вы выложите шаблон подобного документа)

Ответить
Развернуть ветку
Semrush
Автор

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

Ответить
Развернуть ветку
Feruza Ergeshova

А когда будет следующая часть статьи ?

Ответить
Развернуть ветку
Тоже хочу

" В нём сводят все планируемые затраты и доходы."
" главный финансовый артефакт проекта"
если сводится, то уже не главный

Ответить
Развернуть ветку
Тоже хочу

Какое слабое понимание бизнеса у Semrush. А ведь PnL это уже укоренившаяся мировая практики. Все что нужно, это просто нанять "умных" лидеров

Ответить
Развернуть ветку
4 комментария
Раскрывать всегда