Первый полный вариант Lean Canvas

Немного пораскинул мозгами – начинаем вот с такого.

Первые наброски – Lean Canvas

Мне очень нравится такой формат, как Lean Canvas. Это такой одностраничный документ, фиксирующий элементы бизнес-модели (гипотезы и проверенные утверждения) на одном листе бумаги. Сторонники Lean Startup – в том числе и я – считают, что это более полезный формат, нежели развесистые бизнес-планы. Цитата из Стивена Бланка:

Business Plan: A document investors make you write that they don’t read.

Есть несколько форматов Lean Canvas (см  http://www.ashmaurya.com/2010/08/businessmodelcanvas/). Я решил придумать свой, подходящий под конкретно мою ситуацию.

Над несколькими разделами еще буду думать. Пока есть собственно список разделов, и первые наброски ответов:

Эволюция идеи – что теперь? (четвертый замысел)

Сейчас август 2011г. Проект по командировкам де-факто прекратил свое существование. Инвестиции закончились в феврале. С марта я работаю full-time (коммерческим директором компании ФинГрад, отдельная интересная тема, как-нибудь расскажу).

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

Я считаю, что из всего, с чем мы сталкивались за это время, наиболее острыми являются именно вопросы, связанные с деньгами. В контексте командировок это означает в основном авансовые отчеты – их создание, согласование и возмещение. То есть – российскому рынку нужно решение из области Expense Management.

Это может быть смешно, но мне потребовалось два года и куча потерянных денег, времени и нервов для того, чтобы вернуться к идее, которая должна была быть очевидна с самого начала, поскольку:

• На мысль заняться командировками меня натолкнула именно проблема с составлением авансовых отчетов (когда я ездил в Ярославль летом 2009го),
• Компания, успех которой на американском рынке я хотел воспроизвести здесь – Concur Technologies – начала свою работу именно с авансовых отчетов. (Они стали относить себя к категории Travel & Expense Management только после покупки Cliqbook, корпоративного сервиса для заказа туристических услуг онлайн – но до сих пор основные деньги делаются ими именно на Expense Management).

Я решил, что буду рассказывать о том, как пойдет это исследование, здесь, в этом блоге. (Собственно для этого я за последнюю неделю восстановил историю проекта до настоящего момента). Таким образом я преследую две цели. Во-первых, просто фиксирую – хотя бы для себя самого – что делается и почему. И во-вторых – у меня есть надежда, что кто-то из моих читателей меня покритикует, это всегда очень ценно.

Так что – уважаемые читатели – если у вас есть критика (бизнес-идеи, подхода, да вообще чего угодно) – буду рад ее услышать!

Эволюция идеи – ответвление (командировочные документы)

Посередине работы над v2 (“автоматизация работы travel-офиса”) у нас возникла еще одна идея, которую мы решили реализовать параллельно, в виде эксперимента.

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

• Служебное задание,
• Приказ о командировке,
• Командировочное удостоверение,
• Авансовый отчет.

Служебное задание и приказ нужны для выполнения требований трудового законодательства, а также как обоснование производственной необходимости командировки. Командировочное удостоверение является подтверждением того, что командировка реально состоялась (не требуется при заграничных командировках). Авансовый отчет – документ, касающийся не только командировок, а вообще любых расходов, понесенных сотрудником в интересах компании; в частности он нужен для возмещения командировочных расходов (как прямых расходов, так и положенных сотруднику суточных).

Идея заключалась в том, чтобы сделать Web-приложение для заполнения командировочных документов. Я не думал (возможно зря), что за такой сервис кто-то будет платить, но обнаружил, что куча народу ищет в Рунете шаблоны этих четырех документов. Замысел заключался в том, что мы сможем завлечь на свой сервис достаточно заметную долю авторов этих запросов, и использовать полученную аудиторию для продвижения нашей системы (v2).

(Автоматическое заполнение имеет смысл, поскольку в этих четырех документах требуется заполнение минимум 59 полей, из них 29 повторяются по крайней мере в двух документах из четырех, а некоторые – такие как ФИО и должность – во всех четырех. Заполнение через Excel, соответственно, требует много повторов).

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

Минус же заключался в том, что мы опять-таки не продумали бизнес-модель (считая почему-то, что если речь идет о бесплатном сервисе, то это не требуется). Почему люди ищут эти шаблоны? Кто наш конкурент за трафик? Почему пользователи решат зарегистрироваться на нашем сервисе? Как будет привлекаться трафик, и почём? Все эти вопросы стали задаваться уже по ходу работы над сервисом.

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

Наверное, главный урок для меня заключается в том, что – как бы соблазнительно это ни выглядело – стартапу нельзя отвлекаться от одного, главного, магистрального направления. Идея “подстраховаться и попробовать что-нибудь еще, на случай, если план А не сработает”, порочна – ресурсы, отвлекаемые на план Б, жизненно необходимы, чтобы повысить вероятность успеха плана А. А если есть сомнения в том, что вы движетесь в правильном направлении – это повод задуматься и проанализировать именно план А: “в правильную ли сторону мы идем”?

 

Эволюция идеи – третий замысел

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

Идея заключалась в том, чтобы создать полноценное онлайн-турагентство для бизнеса, то есть сделать так, чтобы заявки на туристические услуги (после должного корпоративного согласования) обрабатывались не турагентами вручную (как мы планировали в v1 и v2), а автоматически, с использованием данных GDS. Мне казалось, что идея перспективна, потому что:

1. В этом сегменте успешно играет AnyWayAnyDay (у которого не было такого мощного модуля управления пользователями, какой уже был у нас, и вообще не было согласования заявок). На тот момент AWAD заявляли, что продают билетов на $20K в день – даже при очень низкой марже суммы получаются впечатляющие.
2. Вообще продавать “турагентство” (понятную услугу) легче, чем “управление командировками” (вообще новый сегмент)
3. Несколько заказчиков из тех, с кем мы общались по поводу v1, напрямую заявляли нам, что это было бы для них интересно.

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

Я воспользовался тем, что у AWAD оказалась достаточно хорошо прописанная/продуманная партнерская программа для корпоративного модуля. Став партнером AWAD, наша компания получила вполне законную возможность попродавать услуги AWAD, и искренне попытались это сделать (продавали “знакомым” компаниям). Попытки оказались неуспешными, и из полученной от клиентов обратной связи можно было сделать выводы по поводу идеи в целом:

1. Нет преимущества в цене. Заказчики смотрят в первую очередь на цены, а во вторую – на удобства. Устойчивое преимущество здесь получить очень сложно (почему – отдельная большая тема).
2. Невозможность кредитования массы клиентов. Без кредитования – то есть выписывания билетов мгновенно и выставления счета за уже выписанный билет – работа получается очень неудобной для клиента (нужны депозиты, или рынок ограничивается теми компаниями, у которых есть корпоративные кредитные карты – а их совсем немного). Для кредитования надо хорошо знать клиента и доверять ему, то есть масштабируемый бизнес построить невозможно.
3. Невозможность предоставить полный ассортимент услуг. Корпоративное турагентство должно помогать в организации любой поездки – а поездку, скажем, в условный “Урюпинск” автоматически забронировать невозможно, поскольку ни одна гостиница в Урюпинске не предполагает онлайн-бронирования.
4. Сопротивление пользователей. Как ни удивительно, сотрудники на самом деле абсолютно не горят желанием заказывать туристические услуги для своих командировок онлайн. В отличие от рынка частных лиц, где альтернатива заказу через Интернет – “топать в душное турагентство в соседнем подвале”, здесь всегда есть намного более привлекательный вариант – “поручить все секретарю, и пусть у нее болит голова по поводу всех нюансов”.

Как ни странно, но в чисто эмоциональном плане работа над v3 мне даже понравилась. Возникло ощущение, что я потратил время с толком, и получил внятный – пусть отрицательный – результат. Для меня это только подтвердило правоту концепции  Lean Startup.

Эволюция идеи – второй замысел

Среди заказчиков, с которыми удалось пообщаться по ходу предложения первой версии, был один крупный банк. Пообщавшись с их travel-отделом, я нащупал – как мне казалось – вполне реальную проблему, заключающуюся в обработке потока заказов от командированных.

В этом банке ежемесячно организовывалось около 150 командировок. Каждая командировка – от 2х до 4х услуг, требующих заказа (гостиница и билеты – обязательно, визы и такси – иногда), каждая услуга – 10-15 e-mailов (заказ от сотрудника, подтверждение от менеджера, заказ турагентству, выяснение деталей с турагентством, предложение вариантов сотруднику, выбор варианта сотрудником, окончательный заказ и.т.п.). С учетом сложных случаев получается около 10000 e-mailов в месяц, или один e-mail раз в пять минут рабочего времени – и это все на двух девушек travel-отдела. Понятно, что при такой плотности неизбежны сбои и ошибки. Собственно сами девушки это и подтвердили. Одна из них призналась, что записывает “что сделано/что осталось сделать” по конкретной командировке на листочке бумаги. Их начальница не в состоянии контролировать их работу. Передать командировку от одной к другой не представляется возможным. В отпуск они почти не ходят…

Эта проблема легла в основу второго замысла системы: мы решили сделать именно решение по автоматизации работы travel-отдела. Правда, мы и тут сразу замахнулись на большее: коль скоро этот workflow включает в себя работу турагентств, я решил сразу разрабатывать интерфейс и для турагентов тоже, чтобы они могли предлагать варианты по туристическим услугам внутри нашей системы. Таким образом, у нас получалась одна система с двумя интерфейсами, которые мы назвали Tilbi Travel Center и Tilbi Travel Agent, для travel-отделов и турагентов, соответственно. Нечто подобное мы наблюдали у английской компании KDS.

Наша “v2″ получилась не проще, а в чем-то даже и сложнее, чем v1. Пусть мы полностью отказались от отчетов, то есть – вроде бы – сократили функциональность в два раза. Но мы добавили детальности к нашим заказам (например, теперь, если сотрудник заказывал в travel-отделе авиабилет, он не писал название аэропорта, а выбирал аэропорт из справочника IATA, ЖД-станции - из справочника РЖД, и.т.п.), добавили турагентсткий интерфейс – в общем, трудозатраты на разработку этой системы получались не меньше, чем на первую. Правда, и с ресурсами у нас было лучше, чем при разработке первой версии. Все-таки часть системы (а именно админка) у нас уже была, и имелась вполне боеспособная команда разработчиков и как-то налаженные процессы. В итоге v2 была сделана в декабре 2010г.

С маркетинговой точки зрения какие-то уроки я все-таки из работы с v1 вынес. Главное – если с v1 мы начали продажи после окончания разработки, то с v2 мы начали эти процессы одновременно. В итоге тот факт, что v2 – тоже идеологически тупиковый вариант, оказался понятен примерно к тому же моменту, как система была готова к демонстрации, то есть к началу декабря 2010г.

Основные причины, почему на v2 не оказалось спроса:

• Узкий рынок: компаний, в которых происходит 100 и более командировок в месяц (наш критерий отбора), относительно немного
• Конкуренция: подобные системы предлагаются турагентствами, берущими корпоративных заказчиков на обслуживание (например ZCTS, ATH, NICKO TRAVEL). Более того, в таких системах обычно реализована какая-то интеграция с GDS (системами дистрибуции туристических услуг, например Amadeus или Galileo), что позволяет, по максимуму, обеспечить полный online-заказ услуги командированным или секретарем, а по минимуму – снять необходимость вручную вводить параметры услуги (номер рейса, время отправления и.т.д.). Тот факт, что мы предлагали “что-то более удобное”, не компенсировал того, что турагентства были уже хорошо знакомы с нашей целевой аудиторией. Кроме того, система предлагалась по факту бесплатно, поскольку турагентства ожидали получить финансовую выгоду от сокращения своих трудозатрат.
• Низкий приоритет проблемы в масштабах компании. Даже если travel-офис действительно “зашивается”, для бизнеса в целом это обычно мелкая задача, приоритет которой уж точно недостаточен, чтобы дать указание о запуске какого-либо проекта. Именно по этой причине даже тот банк, с помощью которого мы сформулировали постановку задачи, в итоге отказался от сотрудничества с нами.

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

(Продолжение следует).

Эволюция нашей идеи – первый замысел

Расскажу про свой проект немного поконкретнее.

Первоначально идея была “облегчить жизнь командированному”. Мысль автоматизировать эту область возникла, когда летом 2009го я много ездил в Ярославль по делам своего консалтингового проекта, и совершенно замучился заполнять отчеты по итогам каждой поездки.

Тогда я почитал про Concur Technologies, купился на идею “автоматизировать все, что связано с командировками”, и решил, что это и будет функциональностью нашего продукта. Сейчас стыдно, и немного странно, про это вспоминать, но да, еще два года назад идея “автоматизировать все” (пусть в рамках какой-то области) не казалась такой уж бредовой.

Первый замысел касательно функциональности продукта был такой:

• Создание заявки на командировку
• Согласование заявки
• Создание отчета по командировке
• Согласование отчета

Мы планировали сделать какую-то версию продукта к апрелю 2010г (разработку начали в феврале), но по целому ряду причин что-то “показываемое” мы получили только в конце июня, и реальную обратную связь начали получать в конце июля/августе. Выяснилось, что:

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

В общем, к сентябрю 2010г. стало понятно, что первый замысел – тупиковый.

Видеозапись с выступления на “неконференции”

 

 

 

 

 

 

 

А вот еще и видео c упомянутой выше неконференции:

http://videosostav.ru/video/4512fa25de880896b3fcbcd750cb3958/

(Ммда, над дикцией еще работать и работать…)

 

 

 

 

 

Презентация с майской “не-конференции”

Было в мае такое замечательное мероприятие “Не-конференция SaaS-предпринимателей“, организованное Кириллом Рубинштейном и Smartsourcing. Мне очень понравилось. Опять-таки – посмотрел изнутри на офис Яндекса  .

Лучше поздно, чем никогда. Вот моя презентация оттуда: http://www.slideshare.net/vshabat/ss-8136227. Я там рассказываю тоже про ошибки стартапера на собственном примере.

Minimum viable product

Всем известно, что первая версия любого продукта должна быть “небольшой”  по функциональности, чтобы поскорее выпустить ее на рынок и посмотреть на реакцию. Но что значит “небольшой”? Насколько “небольшой”? Что можно ограничивать в первой версии? (Только функциональность, или еще и быстродействие, дизайн, юзабилити, стабильность, …)?

Теоретики Lean Startup ввели такое понятие, как Minimum Viable Product (MVP). Мне эта идея очень нравится, попробую ее изложить в своем понимании.

MVP – это минимальный по функциональности продукт, позволяющий стартаперам получить осмысленную обратную связь с рынка.

То есть MVP – это НЕ ОБЯЗАТЕЛЬНО:

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

…хотя все это в некоторых случаях может и потребоваться.

Обязательно ли MVP должен быть маленьким или дешевым? Нет, хотя в некоторых случаях это возможно. Есть люди – бутстраперы – которые умеют раскручивать бизнес практически из ничего. Вот например замечательная история Грега Джанфорте (RightNow Technologies). Для него MVP представлял собой реально не более чем feature list будущего продукта – а дальше его пробивной энергии хватило на то, чтобы обзвонить с этим списком несколько сотен заказчиков, вступить с ними в осмысленный диалог, и получить заказ на продукт до того, как он был написан.

Но это получается не всегда. Мне кажется, функциональность MVP зависит от трех факторов:

1. Острота проблемы. Если вы предлагаете решение какой-то очень актуальной проблемы – например вы продаете первый в мире антивирус – заказчики могут понять, что именно им предлагается, не глядя собственно на продукт или даже на прототип. Наоборот, если проблема вторична, осмысленный диалог завяжется только после демонстрации (так будет, например, если вы делаете “еще более удобный” сайт для покупки авиабилетов)
2. Воображение заказчиков. Есть разные целевые аудитории. Одна крайность – топ-менеджеры, которые склонны принять решение/вынести суждение на нескольких рациональных аргументах, и не вникают в детали (так, вряд ли многие генеральные директора, решившие внедрять SAP, на самом деле хоть раз видели экран этой системы). Для них вполне можно обойтись feature list. Другая крайность – B2C; там MVP наверняка должен иметь некий законченный look & feel, поскольку народные массы принимают решение интуитивно, и иногда даже не могут его как следует объяснить.
3. Талант стартапера. То, на что способен Джанфорте и некоторые другие “звезды” (позвонить топ-менеджеру “с улицы” и попытаться продать ему несуществующий продукт), может быть не под силу мне или вам.

MVP может представлять собой:

• Feature list,
• Спеки/экраны системы,
• Сайт с описанием преимуществ,
• Прототип
• Бета-версию системы,
• v1.0 системы,
• …

Как видим, MVP – это не только продукт. Сюда же нужно добавить все то, что нужно,  чтобы выйти на диалог с заказчиком. То есть это может быть сайт плюс какой-то способ его раскрутки, или отработанный скрипт холодного звонка, или еще что-то… Более того, самого “продукта” (программы, делающей что-то полезное) в MVP изначально может и не быть. Например, если надо понять, есть вообще спрос или нет, то вариантом MVP вполне может быть промо-сайт, измеряющий количество кликов на кнопке “зарегистрироваться”.