top down и bottom up в чем разница
Как посчитать объем рынка? — TAM, SAM, SOM
Если вы просматривали когда-нибудь презентации стартапов, то наверняка видели эти загадочные сокращения — TAM, SAM, SOM. Эти аббревиатуры дают нам понять объем рынка сбыта продукта. Инвестору важно какой рынок будет захватывать стартап, как он на него смотрит и считает. Поэтому все обязательно добавляют слайд с объемом рынка. Часто так бывает, что основатели, не имея выручки, хотят показать: смотрите, зато у нас рынок большущий, что-нибудь да точно заработаем. И рисуют какие-то невероятные суммы в сотни миллиардов долларов. Однако, понимание объема своего рынка также важно и для основателей. Как же понять какой рынок будет занимать проект, как его лучше посчитать? Что такое bottom-up и top-down подходы?
Примерно оценив рынок, основатель может решить, стоит ли ему идти к венчурному инвестору или нет. Возможно проще и лучше взять кредит. Если рынок маленький, то там вполне можно построить хороший бизнес, но нельзя построить большую постоянно растущую компанию, а это не укладывается в стратегию венчурного инвестора. Мы все-таки целимся на доходность в 10х, а если весь рынок эти 10х на вложения, то как инвестор сможет вернуть деньги вложенные в фонд, да еще и заработать?
Bottom-up и Top-down подходы.
Начнем сначала с bottom-up и top-down подходов подсчета рынка.
Эти два подхода кардинально отличаются. Сразу скажу, что в Leta Capital мы больше предпочитаем Bottom-up подход. Он более точен, но нужно больше времени и усилий, чтобы с его помощью подсчитать рынок.
Top-down подход.
Bottom-up подход.
Рассчитывается путем оценки потенциальных продаж с целью определения общего объема продаж. Анализ «снизу вверх» оценивает, где продукты могут быть проданы, кому они могут быть проданы. Например, вы решили предоставлять сервис выгула собак. Допустим, вы находитесь в России, а точнее в Москве. Тогда вы можете прикинуть сколько, есть хозяев с собаками. Постарайтесь найти наиболее точные статистические данные из доверенных источников. Можно оценить, оттолкнувшись от количества населения в городе. К примеру, в Москве 600к собак, и только 8% из них будут гулять каждый день. Тогда, если ваш средний чек 1000р, то максимально возможная выручка в день будет равна 600,000*8%*1000 = 48 млн руб. Тогда в год весь рынок выгула собак — это 17 млрд. руб. Однако тут нужно учесть, что большую сумму вы будете отдавать выгульщикам собак. Поэтому скорее ваш рынок можно оценить в 600,000*8%*200*365= 3,5 млрд. Руб. Где 200 рублей — это то, что получаеты вы за выгул одной собаки.
Хотя оценка с помощью bottom-up анализа требует гораздо больших усилий, результат, как правило, намного точнее.
TAM, SAM, SOM
Теперь перейдем к аббревиатурам. Они расшифровываются так:
TAM (Total Addressable Market)
Общий целевой рынок или TAM относится к общему рыночному спросу на продукт или услугу. Это максимальная сумма дохода, которую может получить бизнес, продавая свой продукт или услугу на определенном рынке. TAM наиболее полезен для бизнеса, чтобы объективно оценить потенциал конкретного рынка для роста и масштабирования.
Показатель TAM определяет сколько клиентов нуждаются в вашем продукте/услуге. Учитывает всех клиентов, в том числе те, которые не могут себе позволить приобрести продукт.
Выше, где я рассказывал про bottom-up анализ, как раз рассчитывается показатель TAM.
SAM (Serviceable Addressable Market)
Если компания не является монополистом, то скорее всего, она не сможете охватить весь целевой рынок TAM для ее продукта или услуги. Даже если у компании есть только один конкурент, все равно будет крайне сложно убедить весь рынок покупать продукт или услугу только этой компании..
SAM определяет сегмент (долю) от общего рынка (TAM) потребителей, которые готовы и могут купить продукт/услугу из схожих с вами категорий бизнеса.
Здесь нужно подумать, кто из потребителей и в каком объеме может купить продукт?
Например, если вы продаете софтверный продукт, который нужен во всем мире, но у вас только русскоязычная версия и на данном этапе вы продаете только в России, то SAM можно посчитать как TAM, но только для России, а не всего мира.
Также есть еще более интересный способ посчитать SAM. Сумма выручки всех конкурентов и самого стартапа. Можно узнать цены конкурентов и примерно оценить, сколько компаний они обслуживают.
SOM (Serviceable & Obtainable Market, Share of Market)
SOM — это объем рынка, доля от SAM, который может занять бизнес с учетом имеющейся стратегии, действий конкурентов и конкурентных преимуществ компании. Это может быть реальной клиентской базой компании или реалистичной долей от показателя SAM. Посчитать можно разными способами. Можно поделить выручку прошлого года на SAM прошлого года. Получившийся процент — это доля рынка компании в прошлом году. Оценив SAM текущего года, можно умножить его на долю рынка в процентах, которую занимала компания в прошлом году.
Допустим компания продает софтверный продукт, какой-нибудь софтверный инструмент. Но на данный момент, так как основатели еще не привлекали инвестиции, денег хватает только на то, чтобы платить зарплату 5 продавцам. Вы оценили SAM в 20,000 компаний. Каждый ваш продавец может продать только 120 компаниям в год. Следовательно 5 продавцов — могут обслужить 600 компаний. То есть 3% — а это и будет ваш SOM.
Как вы уже поняли, у подсчета TAM, SAM и SOM разные цели: SOM определяет, сколько потенциально вы можете продать в ближайшее время, SOM / SAM показывают целевую долю рынка, а TAM потенциал масштабирования. Все они играют важные роли в оценке инвестиционной возможности, а фокусироваться нужно на том, чтобы как можно точнее посчитать рынок, нежели на том, чтобы нарисовать огромные числа в презентации.
Научившись определять долю рынка, компания может принимать решения о дальнейшей стратегии. А грамотно предоставив эту информацию инвестору, можно увеличить шансы на получение инвестиций.
Сверху вниз или снизу вверх
Эта статья входит в нашу коллекцию «Из окопов». В нем обсуждаются управление проектами, управление портфелями и управление задачами, а также сравниваются связанные с ними методы управления сверху вниз и снизу вверх.
Чтобы скачать версию Word в этой статье, см. в статье Top-down или bottom-up: white paper (Project Server 2010).
Дополнительные статьи см. в статье «Из окопов».
Сверху или снизу вверх?
Те из нас, кто работал в ИТ на протяжении многих лет, как правило, видят вещи с технической точки зрения, а иногда это не служит нам хорошо. Если мы посмотрим на данные управления портфелями, Project управления и управления задачами, это может выглядеть очень похоже. У меня есть поле ID, поле описания и дата начала и окончания во всех трех. Привязка всех трех из них должна быть естественной.
Давайте рассмотрим эти три понятия по одному. Их сходство легко увидеть, но существуют фундаментальные различия в трех перспективах.
Управление портфелем — подход сверху вниз
Люди могут означать много разных вещей под «управление портфелем», но наиболее распространенным значением, вероятно, является выбор проектов и приоритеты. Принципы в конечном счете затрагивают всех сотрудников организации, но этот процесс очень интересен для руководителей старшего звена. Управление начинается с определенных ограничений, таких как общий доступный бюджет и необходимость ответить на вопрос: «Что мы можем и должны сделать с таким объемом денег?» Если процесс управления портфелем достаточно зрелый, этот анализ может включать не только новые идеи, но и существующие проекты.
Чтобы создать процесс выбора портфеля и определения приоритетов, руководство должно противостоять тем, какие бизнес-критерии годят компанию, и заранее согласовать метрики, которые будут учитываться при поиске новых и существующих проектов. Должна ли доходность инвестиций быть ключевым показателем? Возможно, нам следует рассмотреть вопрос о влиянии на удовлетворенность клиентов, удержание персонала или соответствие стратегическим целям. Какие бы ключевые показатели ни были, руководство должно взвесить каждую инициативу проекта с учетом того, как этот проект может продвигать эти цели и как каждый проект сравнивает с альтернативными инициативами, на которые можно было бы потратить деньги.
Это очень аналитический процесс, даже если он сделан в голове. Это, конечно, очень аналитически, когда вы используете программное обеспечение управления портфелем проектов. Даже после того, как анализ программного обеспечения поступает в отчет или представление, практически всегда существует некоторый надзор на уровне управления, где принимается окончательное решение о приоритетах. Когда это будет завершено, окончательные результаты должны быть переданы тем, кто будет делать управление проектами каждого из проектов. Эти решения будут иметь последствия для финансирования одних проектов, а не для финансирования других, для того, чтобы сделать ресурсы более приоритетными для одних проектов, а не для других, а для продвижения расписания некоторых проектов и отсрочки других.
Project Управление — сверху вниз и снизу вверх
После утверждения проекта он переходит в другую область. Теперь в центре внимания более классическое представление планирования проектов. Теперь мы должны фактически создать то, что мы описали в нашем бизнес-обоснование, прежде чем он был утвержден.
Руководитель проекта начинает мыслить с точки зрения области проектов и ее результатов. Руководитель проекта знает конечный продукт, который необходимо создать, будь то программное обеспечение или здание, готовое к заполняемости. Они могут придумать основные этапы этого проекта и создать структуру сбоя работы.
Разработан критический путь логических действий, необходимых для завершения проекта. Руководитель проекта также знает, что он или она будут нести ответственность за график, который производится, поэтому он или она консультируется с рядом экспертов по предметам в проекте. Руководитель проекта создает представление проекта снизу вверх, просматривая задачу по задачам и обобщая эти задачи до этапов проекта и, в конечном счете, самого проекта. В это время руководитель проекта может также начать деление ресурсов по навыкам, по отделу или даже по имени. Эти ресурсы могут иметь затраты, связанные с ними. В результате вычисления продолжительности задач, необходимых ресурсов и их показателей мы оцениваем проект снизу вверх.
Пока все в порядке.
Но когда мы смотрим на даун-подход процесса выбора портфеля проектов, это тоже было затратой. Фактически, сметная стоимость проекта была частью бизнес-обоснования, которое руководство рассматривало при его одобрении. Если мы сейчас только что выполним нижнюю оценку проекта с помощью объединенных знаний экспертов по предметным темам, что они использовали при выборе проекта в исполнительном пакете?
Хороший вопрос. В некоторых организациях проекту будет дана примерная оценка от отдела проектов для создания бизнес-обоснования проекта. В других организациях перед рассмотрением проекта в процессе портфеля создается полная оценка снизу вверх. Проблема обоих этих подходов заключается в том, что они принимают усилия. Полная оценка может занять много усилий, но проект еще не получил одобрения для финансирования любых усилий. Так что во многих организациях кто-то из руководства просто делает предположение о том, какие будут затраты на этот проект.
Таким образом, процесс выглядит все интегрированным, но может быть немного catch-22 здесь. В первую очередь, работа, затраченная на смету или выбор проекта, чтобы иметь возможность тратить время на проект?
Кроме того, что произойдет, если снизу вверх оценка не соответствует оценке процесса выбора портфеля? Если оценка меньше, то, вероятно, нет проблем, но если работа не может быть завершена в то время или бюджет, оцененный людьми выбора портфеля, существует конфликт.
Вы можете подумать, что естественным является повторное перенаправление высшего руководства и просто обсуждение проблемы, но существует множество ситуаций, когда это не так просто, как кажется.
Во-первых, комитет по выбору портфеля редко является штатом управления проектами. Старшие сотрудники управления проектами почти всегда включаются в состав комитета по выбору портфеля, но сама группа обычно является очень старшими руководителями, которым сложно организовать время, чтобы все были вместе. Во-вторых, комитет по отбору может встречаться нерегулярно, поэтому собрать их вместе, чтобы обсудить все последствия несоответствия затрат для одного проекта по сравнению с оценкой, может быть большой проблемой. Наконец, существуют некоторые корпоративные культуры, в которых не будет продвижения по карьере, чтобы довести до старшего руководителя новости о том, что их догадки совершенно неправильно о том, что соответствующий график и бюджет для этого проекта.
Управление задачами — подход снизу вверх
Когда мы думаем об управлении задачами, мы склонны думать очень оперативно, и это чаще всего приводит нас к нашей повседневной повестке дня и продукту, как Outlook.
Теперь мы работаем на уровне отдельного или небольшого члена команды. Мы не видим задачи в контексте. Мы видим те вещи, которые мы обязались или, возможно, те вещи, которые мы попросили члена группы совершить. Это вообще не аналитическое представление. Есть задачи, которые нужно выполнять, и человек пообещал их выполнять.
По своей сути управление задачами очень просто. Вы выполните задачу, и когда вы завершите, скажите человеку, который дал вам задачу, чтобы она была завершена. Все функции для этого уже в Outlook.
Озорная ситуация с аналогичными данными
Есть поговорка: «Если она выглядит как утка и шарлатаны, как утка, она должна быть уткой». Это верно для уток, но это не всегда верно для данных, основанных на задачах.
Рассмотрим три уровня данных, ориентированных на проект:
На уровне портфеля у нас есть проект и, возможно, этапы ниже этого проекта. Сведения о фазе могут иметь номер кода, описание, продолжительность, дату начала и дату окончания.
На уровне проекта у нас есть проект и задачи ниже проекта. В сведениях о задачах может быть номер кода, описание, продолжительность, дата начала и дата окончания.
На этом уровне управления задачами у нас есть задача, а сведения о задачах могут иметь номер кода, описание, продолжительность, дату начала и дату окончания.
Они, конечно, выглядят одинаково, но на самом деле перспектива данных заставляет каждую из этих довольно распространенных записей служить совершенно другой цели.
Меня часто спрашивают: «Могу ли я переместить данные из представления портфеля в представление проекта в Outlook и обратно».
Краткий ответ на этот вопрос : «Да».
Но в нашей фирме мы говорим себе мантру, когда даем технические советы: «Не говорите мне, как это сделать, скажите мне, почему вы должны это сделать».
Чтобы сделать точку, представьте этот пример. Мы делаем полностью интегрированную среду. В верхней части шкалы мы имеем список проектов, организованных по портфолио. Мы не только выбираем эти проекты, но и интегрируемся еще дальше, следуя за ними после их активации в живых проектах из системы EPM. Для этого мы используем уже имеющиеся у нас функции для перемещения определений проектов и этапов с стороны портфолио нашей интегрированной системы в проектную сторону системы. Данные выглядят одинаково.
В нашей корпоративной системе управления проектами мы теперь делаем более подробное определение, используя исходные этапы из определения портфеля, которое было отжато сверху вниз. Это позволяет обновлять эту сводку в системе портфелей при обновлении проектов. Мы делаем много задач и назначаем много ресурсов. Теперь мы делаем анализ уровня ресурсов, чтобы определить нашу емкость во многих проектах.
Мы используем назначения ресурсов для нажатия данных задач и назначений каждому пользователю в качестве Outlook задачи или события календаря. Пользователям больше не нужно ходить в «систему управления проектами». Теперь они могут видеть свои данные в своей повседневной повестке дня. Данные выглядят так же, как и в списке проектов, и связаны далее вверх по течению с представлением портфеля.
Прогресс от этих задач и доступности от Outlook возвращается от человека к системе управления проектами вместе с оценками, когда эта работа будет завершена. Данные выглядят так же, как и в двух других системах, поэтому перемещение данных относительно легко.
Создание такой системы технически очень просто с помощью средств, доступных нам сегодня, а также немного конфигурации и разработки. И это будет прекрасно демонстрироваться.
Нам регулярно запросят именно этот тип структуры. Но, несмотря на то, что мы можем это сделать, должны ли мы?
Imagine, что на уровне задач человек принимает утреннее отключение для экстренного посещения стоматолога и обновляет свою Outlook, что она не будет доступна сегодня утром. Это плохая новость для него, но волновые эффекты для проекта могут быть массовыми. Теперь проектная система подсчитывает, что задача, которая должна была быть выполнена сегодня утром, не будет выполнена сегодня; она будет завершена только в середине дня завтра. Он послусно смотрит на критический путь и все задачи вниз по течению от этого и толкает их вперед на четыре часа. Возможно, пострадали сотни задач. Результатом может быть нажатие даты окончания проекта через пол дня. Другие проекты также затронуты, так как другие люди, работающие над этим проектом, теперь должны переустроить свои задачи, а само представление портфеля выдвинет несколько пикселей вперед.
Если представить себе это в режиме реального времени, проблема увеличивается. Сотни или тысячи людей в течение дня внося изменения, а представление EPM, представление выравнивания ресурсов и представление портфолио анимировать взад и вперед с эффектами.
На самом деле этого не происходит. Прежде всего, незадачливая стоматологическая пациентка вернется на свой пост в 12:00 и может просто работать несколько часов спустя сегодня вечером, чтобы убедиться, что этот критический путь догнал и все будет вернуться в нужное русло в первой половине дня.
Кроме того, несмотря на то, что данные выглядят одинаково, они никогда не интегрируются таким образом из-за именно этого эффекта.
Контекст данных — вопросы перспективы
Когда мы смотрим на данные, контекст данных имеет решающее значение. Данные, которые могут выглядеть одинаково из схемы записи к записи, используются для очень разных целей в зависимости от перспективы приложения.
В верхней части портфеля мы делаем стратегические решения о том, куда помещаем наши ресурсы для максимальной отдачи от инвестиций. Мы можем сделать выбор, который руководитель проекта не сделает. В моей организации мы иногда выбирали проекты, которые полностью не имеют нашего существующего набора навыков, зная, что мы были бы крайне неэффективными при их выполнении, но делали это, потому что мы хотели улучшить эти навыки. Отдача от инвестиций не была эффективной установкой, она была обучена установщикам. Это аналитическое представление.
В тактическом представлении проекта мы делаем оперативные решения о том, где получить лучшую пропускную способность нашего персонала и как можно быстрее и эффективнее завершить наши проекты. Глаз руководителя проекта всегда в будущее. То, что происходило в прошлом, интересует только руководителя проекта, поскольку оно улучшает его представление о будущем. Это также очень аналитическое представление.
В представлении управления задачами, как в повестке дня, мы не аналитически. Повестка дня — это система обязательств. Мы обещаем себе или другим, что мы будем делать определенные вещи в определенное время. Это может соответствовать аналитическому представлению. А может и нет.
Смешивание этих точек зрения и контекстов без понимания влияния может привести к хаосу.
Сверху или снизу вверх?
Существует, как обычно, нет правильного ответа. Некоторые аспекты системы управления проектами действительно должны быть снизу вверх. В конце концов, это люди, которые будут создавать все, что ваш проект о. Но некоторые решения принимаются и должны приниматься с самого верха и, по необходимости, сверху вниз.
Если вы держите различия для каждого уровня парадигмы управления проектами, становится понятнее, следует ли действительно интегрировать некоторые из этих систем или нет. Если процесс и мышление одного уровня не имеют прямой выгоды, будучи полностью интегрированы с другого уровня, то интеграция не является лучшей игрой. Важно узнать, как такая интеграция будет работать в реальном контексте и обеспечивает ли частота и детализация с одного уровня какое-либо значение для другого.
Если, например, руководящий комитет собирается только один раз в квартал, чтобы принимать решения о том, какие проекты двигаться вперед, а какие нет, то какая польза для обновления их представления каждый день, каждую неделю или даже каждый месяц?
Действительно ли алгоритм управления ресурсами для управления проектами предприятия должен видеть назначение отдельного лица или достаточно знать примерную доступность этого человека?
И тем не менее, если бы мы могли отправить назначение на повестку дня или на экран расметки конкретного человека напрямую, это бы сэкономит им по несколько минут каждый день, чтобы перейти в другую систему и интерфейс, чтобы увидеть те же данные?
Таким образом, сверху вниз право в некоторых обстоятельствах и снизу вверх право в других. Вы должны посмотреть на свою собственную ситуацию, чтобы увидеть, где интеграция этих средств и концепций может вернуть правильные дивиденды, прежде чем их совместить.
Об авторе
Крис Вандерслуис является президентом и основателем канадской компании HMS Software, сертифицированного партнером Microsoft. Он имеет степень по экономике в Университете McGill и более 30-летний опыт автоматизации систем управления проектами. Он является давним членом Института управления Project (PMI) и помог найти главы Группы Microsoft Project пользователей (MPUG) в Монреале, Торонто и Квебеке. Публикации, для которых Крис написал: Fortune, Heavy Construction News, Computing Canada magazine и PMI’s PMNetwork, и он является регулярным обозревателем для Project Times. Он преподает Project управления в Университете McGill и часто выступает на функциях ассоциации управления проектами в Северной Америке и по всему миру. HMS Software является издателем системы хронометража проекта TimeControl и с 1995 Microsoft Project партнером по решению.
Как оценить объем крупного рынка
Важная часть любого product discovery – определить объем рынка, который ваш продукт способен занять, и доход, который продукт может привести.
Сегодня я расскажу о Bottom Up и Top Down методах анализа рынка, с помощью которых можно рассчитать реально достижимый рынок.
Top Down анализ – это расчет общего рынка с определением доли вашего продукта с нем.
Например, мы хотим продавать свежие фрукты с доставкой в стране. Нужно определить, насколько велик рынок для такого бизнеса.
Мы выяснили, что один россиянин тратит в среднем 600 рублей в месяц на фрукты, т.е. 7200 рублей в год. При этом ежегодно россиянами тратится примерно 3.5 трлн. рублей на фрукты.
Понятно, что не всем удобна опция с доставкой. На самом деле, запускать этот бизнес имеет смысл только в крупных городах – Москва и Питер. Мы знаем, что житель большого города тратит в среднем 1500 руб. в месяц на фрукты, т.е. 18 000 руб. в год. Ежегодно в двух городах тратится примерно 300 млрд. руб. в год.
Не все жители крупных городов пользуются доставкой, таковых всего 50%. Это снижает оценку до 150 млрд.руб. Супермаркеты всегда будут иметь за собой большую долю рынка, поэтому мы предположим, что только 20% людей будет заказывать фрукты с доставкой на дом. Таким образом, наша оценка составляет 30 млрд. рублей.
Я привел общий пример, где не учел многого. Для достижения максимально точного размера рынка нужно вести более строгую аналитику. Упустите важные предположения – переоцените свой ТАМ.
Вообще, Top Down анализ несложен, но он может ввести в заблуждение. Он не даст нам ответы на вопрос, сможем ли мы действительно выйти на этот рынок и чего нам это будет стоить. Хорошая новость заключается в том, что ответ на эти вопросы дает нам Bottom Up анализ.