Кирилл, спасибо за классный материал и решение. Позволю себе несколько комментариев.
Что мне показалось офигенным:
- Сама методологическая креативность, использование теорий Остервальдера и Lean в одной интегральной системе. - Современная трендовая упаковка, умелое внедрение ИИ и опенсорс-возможностей - Минимизация издержки на бизнес-моделирование. - Четкое различение бизнес-модели и бизнес-плана.
В чем вижу возможные подводные камни (к обсуждению):
1. Процесс бизнес-моделирования – больше про ментальную синхронизацию команды (разработчиков, собственников, продуктологов, маркетологов и т.п.), нежели непосредственно про артефакт в виде документации – хотя и она, безусловно, важна как принятый к исполнению договор между всему.
2. Отсутствие серийного запроса на бизнес-моделирование. Здесь мы как бы оказываемся между двух парадигм – желанием по lean тестировать гипотезы и стремление структурного waterflow-разработчка иметь развернутую документацию. В первом случае детальное диджитал-моделирование может быть избыточно, во втором – напротив, одним цифровым продуктом не ограничишься.
3. Тестировать бизнес-модели без продукта как воплощения – достаточно проблематично. С другой стороны, "пошатать" решение можно только при наличии онлайн- или оффлайн-синхронизации – в виде воркшопа, форсайт, стратсессии или просто мозгового штурма.
4. Сама структура, то есть базовый канвас бизнес-модели может отличаться от ниши к нише очень сильно. А значит, некой универсальной модели (и универсальной теории, стоящей за ней), может не быть.
Гриша, спасибо большое за отзыв и хорошие вопросы. Позволь, поделюсь размышлениями, раз ты предложил обсудить тему. Буду стараться двигаться по пунктам как у тебя.
1. Честно говоря, именно так я практиковал до недавних пор, о чем упомянул вскользь в материале. Но, с другой стороны, бизнес-моделирование используется в том числе для корректировки видения. Вот у нас продукт AS IS, а вот таким он может быть. Сильно шевелит мозг и раскрывает глаза. Я тестировал сервис (будем говорить фреймворк) с одним из потенциальных пользователей, услышал такой интересный комментарий, что, мол, пока заполняешь – о многом задумываешься и по ходу хочется вернуться на блок назад и переделать модель. И второе для меня открытие (хотя, может быть, это случайное совпадение), так это то, что есть запрос на создание бизнес-планов. Но их сильно удобнее создавать на основе бизнес-модели. Модель задает структуру и это, на мой взгляд, круто!
2. Тут ты прав. Мои гипотезы о востребованности основываются на запросах в консалтинг и собственных предположениях о проблемах. Являются ли они действительными именно для предпринимателя – вопрос. Надо тестировать. Мне очень хотелось бы дать удочку тем, кто нуждается в систематизации видения и в структурировании бизнес-логики. Нужно ли это тем, кто не хочет / не может / не имеет нужды обратиться к консультанту – пока не знаю.
3. Тут ты тоже прав. Но знаешь, что интересно. На выходе, когда ты создаешь модель – у тебя набираются данные, чтобы идти и её тестировать. Идеальный сценарий (один из), на мой взгляд, это когда ты собрал бизнес-модель → сделал условно посадочную страницу с выработанными тезисами / скрипт продаж → проверил спрос / запрос → скорректировал модель → снова протестировал → масштабировал. Можно ли это делать самостоятельно? Уверен, что да.
4. А вот здесь не соглашусь, но это дискуссионный момент, то есть не истина в последней инстанции. Имею ввиду следующее. С точки зрения организационного дизайна и теории систем какой бизнес не возьми – он имеет сетевую природу. Любую из компаний можно представить в виде графа. Является ли теория графов универсальной? На мой взгляд, да. Но суть не в этом (в этом проекте я теорию графов не использовал 😁). Все же, любой бизнес имеет общие точки, присущие любой организации. Продукт производится любой компанией? Любой. Клиенты есть в любой организации? В любой. Доходы и расходы есть в любой организации? Да. Процессы есть везде? Да. И так далее. Эти общие компоненты разные консультанты и исследователи систематизируют по-разному, именно так и появляются фреймворки и методологии. И вопрос применимости заключается не в том, подходит инструмент или не подходит, а скорее понятен ли он пользователю, сложен ли он в использовании и достаточен ли, чтобы решить задачу бизнес-моделирования в конкретной нише. Вот, я пока допускаю (но это мне уже пользователи скажут), что мой инструмент является понятным, простым и достаточным для бизнес-моделирования в любой нише.
Кирилл, спасибо за классный материал и решение. Позволю себе несколько комментариев.
Что мне показалось офигенным:
- Сама методологическая креативность, использование теорий Остервальдера и Lean в одной интегральной системе.
- Современная трендовая упаковка, умелое внедрение ИИ и опенсорс-возможностей
- Минимизация издержки на бизнес-моделирование.
- Четкое различение бизнес-модели и бизнес-плана.
В чем вижу возможные подводные камни (к обсуждению):
1. Процесс бизнес-моделирования – больше про ментальную синхронизацию команды (разработчиков, собственников, продуктологов, маркетологов и т.п.), нежели непосредственно про артефакт в виде документации – хотя и она, безусловно, важна как принятый к исполнению договор между всему.
2. Отсутствие серийного запроса на бизнес-моделирование. Здесь мы как бы оказываемся между двух парадигм – желанием по lean тестировать гипотезы и стремление структурного waterflow-разработчка иметь развернутую документацию. В первом случае детальное диджитал-моделирование может быть избыточно, во втором – напротив, одним цифровым продуктом не ограничишься.
3. Тестировать бизнес-модели без продукта как воплощения – достаточно проблематично. С другой стороны, "пошатать" решение можно только при наличии онлайн- или оффлайн-синхронизации – в виде воркшопа, форсайт, стратсессии или просто мозгового штурма.
4. Сама структура, то есть базовый канвас бизнес-модели может отличаться от ниши к нише очень сильно. А значит, некой универсальной модели (и универсальной теории, стоящей за ней), может не быть.
В общем, в любом случае, есть о чем подумать.
Гриша, спасибо большое за отзыв и хорошие вопросы. Позволь, поделюсь размышлениями, раз ты предложил обсудить тему. Буду стараться двигаться по пунктам как у тебя.
1. Честно говоря, именно так я практиковал до недавних пор, о чем упомянул вскользь в материале. Но, с другой стороны, бизнес-моделирование используется в том числе для корректировки видения. Вот у нас продукт AS IS, а вот таким он может быть. Сильно шевелит мозг и раскрывает глаза. Я тестировал сервис (будем говорить фреймворк) с одним из потенциальных пользователей, услышал такой интересный комментарий, что, мол, пока заполняешь – о многом задумываешься и по ходу хочется вернуться на блок назад и переделать модель. И второе для меня открытие (хотя, может быть, это случайное совпадение), так это то, что есть запрос на создание бизнес-планов. Но их сильно удобнее создавать на основе бизнес-модели. Модель задает структуру и это, на мой взгляд, круто!
2. Тут ты прав. Мои гипотезы о востребованности основываются на запросах в консалтинг и собственных предположениях о проблемах. Являются ли они действительными именно для предпринимателя – вопрос. Надо тестировать. Мне очень хотелось бы дать удочку тем, кто нуждается в систематизации видения и в структурировании бизнес-логики. Нужно ли это тем, кто не хочет / не может / не имеет нужды обратиться к консультанту – пока не знаю.
3. Тут ты тоже прав. Но знаешь, что интересно. На выходе, когда ты создаешь модель – у тебя набираются данные, чтобы идти и её тестировать. Идеальный сценарий (один из), на мой взгляд, это когда ты собрал бизнес-модель → сделал условно посадочную страницу с выработанными тезисами / скрипт продаж → проверил спрос / запрос → скорректировал модель → снова протестировал → масштабировал. Можно ли это делать самостоятельно? Уверен, что да.
4. А вот здесь не соглашусь, но это дискуссионный момент, то есть не истина в последней инстанции. Имею ввиду следующее. С точки зрения организационного дизайна и теории систем какой бизнес не возьми – он имеет сетевую природу. Любую из компаний можно представить в виде графа. Является ли теория графов универсальной? На мой взгляд, да. Но суть не в этом (в этом проекте я теорию графов не использовал 😁). Все же, любой бизнес имеет общие точки, присущие любой организации. Продукт производится любой компанией? Любой. Клиенты есть в любой организации? В любой. Доходы и расходы есть в любой организации? Да. Процессы есть везде? Да. И так далее. Эти общие компоненты разные консультанты и исследователи систематизируют по-разному, именно так и появляются фреймворки и методологии. И вопрос применимости заключается не в том, подходит инструмент или не подходит, а скорее понятен ли он пользователю, сложен ли он в использовании и достаточен ли, чтобы решить задачу бизнес-моделирования в конкретной нише. Вот, я пока допускаю (но это мне уже пользователи скажут), что мой инструмент является понятным, простым и достаточным для бизнес-моделирования в любой нише.
Все это в порядке рассуждений, конечно же.