Экономика проектов (начинать проект или нет) — версия два

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

    Под катом будут финансовые методы, опробованные на ИТ-проектах, в частности — как составить дорожную карту, как работать с горизонтом планирования, как подсчитать показатели, как проанализировать риски.


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

    Бизнес-кейс


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

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

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

    Дорожная карта


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

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

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


    В данном случае А – это приведенные к настоящему моменту расходы на исследование спроса, В – приведенные к настоящему моменту (инвестиционные) расходы на разработку, а С – приведенные к настоящему моменту чистые доходы (чистые — это значит доходы минус расходы, то есть прибыль).

    Забегая вперед, NPV такого проекта будет получаться в результате сворачивания этого дерева начиная от «листьев» к «корню». NPV = -A + 0.7*(-B + 0.9*C) = – A – 0.7*B + 0.63*C. О том, что такое NPV и что такое «приведенные к настоящему моменту деньги» — будет чуть позже.

    Горизонт планирования


    Начальная точка горизонта планирования — всегда настоящий момент. Не имеет смысла учитывать прошлые затраты при оценке будущего проекта — потому что для всех вариантов развития событий они одинаковы, это во-первых, а во-вторых они только отвлекают (не дают никакой дополнительной информации).
    Для конечной точки горизонта планирования определяется терминальная стоимость (стоимость проекта за горизонтом) и может быть два случая:
    1. Окончание жизненного цикла продукта и ликвидация накопленных активов. Терминальная стоимость в этом случае — стоимость продаваемых активов.
    2. Точка, в которой считается, что после неё денежные потоки проекта одинаковы (проект выходит на «мощность» и генерирует одинаковый поток денег). Терминальная стоимость в этом случае — приведенная к этой точке стоимость этих денежных потоков.


    После определения по какому варианту будет рассчитываться проект, то есть допущений, следует собственно его обсчитать. Для нашего примера, работа с горизонтом планирования может быть следующей:
    фаза продаж и поддержки © не требует инвестиционных расходов, и длится, допустим, 5 лет, продажи начисляются в конце периода. Ликвидации активов (продажи оборудования или накопленных данных/компонент) нет. Исследование спроса (А) пусть у нас требует одного года (расходы в начале периода), и инвестиции в разработку (В) пусть занимают два года (расходы в начале периода).

    Расчет показателей


    Теперь самое время поговорить о расчете тех показателей, по которым можно принимать решение о старте. Мы рассмотрим два показателя — NPV (Net Present Value) и PI (Profitability Index). Они являются согласованными, то есть выдают одинаковую информацию для принятия решений, но используются в различных случаях.

    В этих формулах: NCF — Net Cash Flow — чистый денежный поток, Inv — инвестиции, t — время, а i — ставка дисконтирования. О ставке дисконтирования можно говорить долго и безрезультатно, поэтому я скажу коротко и по делу — это стоимость капитала (в процентах) для проекта, которая должна быть не ниже, чем доходность альтернативных вложений с таким же уровнем риска. По-хорошему это должен быть WACC, который в случае с заемным капиталом еще понятно как его рассчитывать (стоимость — процент кредита), а в случае с собственным — надо опираться на то, что скажут владельцы капитала. В любом случае ставку дисконтирования в расчетах следует делать параметром.

    NPV таким образом показывает, сколько чистой прибыли с учетом того, что будущие платежи стоят дешевле сейчас (чем в будущем), мы имеем. В случае неограниченного инвестиционного бюджета, для NPV > 0 проект следует принять, если NPV < 0 — отклонить, в случае нуля — пересмотреть позже, после изменения каких-либо его факторов. В случае ограниченного бюджета, проекты следует отранжировать по PI, и, отсекая по сумме инвестиций проектов, начать набирать проекты в портфель с самого высокого PI — это гарантирует максимальный NPV портфелю.

    Теперь о том, как рассчитать NCF. NCF — это сумма двух потоков — инвестиционного и операционного. Для случая ИТ-проектов, инвестиции — это затраты в разработку продукта/сервиса, а операции — это производство и продажа продукта (а также его поддержка).

    Пример расчета можно найти в файле.

    Анализ рисков


    Если заглянуть в файл, то там можно найти вкладку «Торнадо». Диаграмма «Торнадо» показывает, как изменяется некоторый показатель (в нашем случае NPV) в зависимости от изменения параметров проекта, таких как например, объем продаж или цена. Выбранные худшие значения параметров могут уводить проект в зону отрицательного NPV, что означает что за этим параметром скрывается что-то нехорошее, и его надо как минимум дополнительно исследовать, и затем отслеживать.

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

    Что за бортом


    За бортом остались налоги. На прибыль, НДС, ЕСН и прочее. Как их учесть — зависит от проекта, если оценка проекта идет внутри компании — то надо разговаривать с бухгалтером или экономистом.
    За бортом остался учет инфляции — по-хорошему, её надо учитывать и в ценах, и в ставке дисконтирования. Обычно, в ставке инфляция уже сидит, а цены надо не просто индексировать на какой-то процент, а просто ставить будущие цены.

    В заключение


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

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

    Подробнее
    Реклама

    Комментарии 7

      0
      Бывают два крайних варианта развития жизни проектов с точки зрения экономики, которые предполагают неоднозначность выводов:
      1. Есть аналоги, они прекрасно работают, просчитали, запускаем — не пошло (рынок перенасыщен, ситуация в мире изменилась)
      2. Аналогов нет, предварительно не понятна монетизация, запустили, появились дополнительные факторы, проект «взлетел», «бабло гребем лопатой»

      Как в этом случае прогнозировать «запускать или нет»?
        0
        Смотрите, вы говорите «запустили» — значит решение уже принято. Я буду говорить о случае, что проект пока не запустили.

        Тогда речь идет о жизненном цикле продукта, о рынке продукта. Первый случай — рынок перенасыщен — это зрелость или концовка ЖЦ продукта. Второй случай — самое начало. И то и другое сопровождается высоким во втором случае, и средним в первом, риском убыточности. То есть предложенные «крайние» случае — это не про проект, а про рынок. Расчет проекта остается одинаковым в обоих случаях, сценарии могут быть заложены в дорожную карту проекта (в ветви) — правда оценивать вероятность для второго случая сложно, поэтому в моём примере есть и исследование спроса, и отказ от проекта. Мысль в том, что описанная методика оценки не зависит ни от качества прогнозирования, ни от ЖЦ продукта.

        А вообще, оба указанных случая должны отражаться на диаграмме «Торнадо» — причем, в случае фактора «объем продаж».
          0
          Если проект коммерческий, то разве нет необходимости учитывать причуды рынка? Техническая часть и экономическая связаны очень тесно в рамках проекта и иногда даже сложно их разделить.

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

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

          Одним из методов такого прогнозирования является анализ американского IT- рынка. Если мы отстаем, например, на 5 лет, то можно посмотреть что есть у них, скопировать и сделать это у нас. Но, опять же, когда-то работает, когда нет.

          Вот я хочу у вас выпытать какие-то особые методы, кроме использования формул :)
            0
            Если проект коммерческий, то причуды рынка нужно учитывать, если есть возможность их спрогнозировать. Как учитывать — я описал два способа (либо в дереве решений, либо в диаграмме Торнадо — и то и другое — элементы анализа риска).

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

            Что касается стартапов и формул. У маркетологов есть свои методы оценки потенциала — например, фокус-группы: продукт рассматривают потенциальные незаинтересованные и специально некомпетентные лица, и говорят — будут они пользоваться или нет.

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

            Вобщем, каких-то универсальных методов «чтоб выстреливало» — нету (знал бы прикуп жил бы в Сочи). Всегда есть риск, и причем риск тем выше, чем выше инновационность (это следует из неравенства Чебышева, если считать что чем инновационней продукт, тем выше разброс в потенциальных продажах). Посмотрите здесь матрицу Стейнера. Поэтому я могу посоветовать иметь сбалансированный по этапам ЖЦ продуктов портфель, например портфельный анализ по Хоферу.

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

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

              Есть такая штука — миграция ценности в отрасли. То есть ценность для потребителя мигрирует — сначала всем были нормальны магазины с прилавком, а потом появилась модель супермаркетов — и все перешли на неё — так потребителю удобнее. В ИТ случился переход от текстовых интерфейсов к графическим. Вот только с облаками на мой взгляд телега впереди лошади идёт. Про миграцию ценности можете поискать Сливоцки — одноименная книга.

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

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

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


            Если экономический анализ не бьется с интуицией, то как там было у Козьмы Пруткова: "если на клетке с буйволом написано медведь — не верь глазам своим".

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

          Самое читаемое