Риски венчурного инвестирования: какие бывают и как оценить
На каждом инвестиционном комитете мы обсуждаем не только возможности проектов, но и смотрим на риски. Даже при кажущейся устойчивости, текущих успехах и невероятных перспективах, любой венчурный проект (venture - рисковать с англ.) имеет высокую вероятность (свыше 50%) неудачи и снижения капитализации. Хороший пример - стартап Klarna.
При анализе компаний мы оцениваем как минимум 5 стандартных типов рисков: (1) рыночный риск (2) риск бизнес-модели (3) риск технологии (4) риск команды (5) финансовые риски
Как профессиональные венчурные инвесторы анализируют риски - рассказываем в нашей карточке🔼🔥
@VoskhodVC - канал венчурного фонда «Восход»
#риски #vc #база
На каждом инвестиционном комитете мы обсуждаем не только возможности проектов, но и смотрим на риски. Даже при кажущейся устойчивости, текущих успехах и невероятных перспективах, любой венчурный проект (venture - рисковать с англ.) имеет высокую вероятность (свыше 50%) неудачи и снижения капитализации. Хороший пример - стартап Klarna.
При анализе компаний мы оцениваем как минимум 5 стандартных типов рисков: (1) рыночный риск (2) риск бизнес-модели (3) риск технологии (4) риск команды (5) финансовые риски
Как профессиональные венчурные инвесторы анализируют риски - рассказываем в нашей карточке🔼🔥
@VoskhodVC - канал венчурного фонда «Восход»
#риски #vc #база
С какими основными юридическими рисками сталкиваются технологические стартапы - разработчики ПО?
Специально для нашего канала разбирает M&A- и VC-юрист Анастасия Нерчинская. Анастасия дала очень подробные комментарии, которые будут полезны тем, кто готовится запускать стартап и думает над привлечением инвестиций в будущем. Знание рисков позволит избежать массу негативных последствий. Их мы также разберем в серии постов.
Типовые юридические риски, которые часто встречаются в деятельности разработчиков ПО (особенно на старте) связаны с их ключевыми «активами»:
📌создаваемым программным продуктом или устройством на его основе;
📌командой разработки;
📌возможностью структурирования бизнеса с учетом ИТ-льгот;
📌бизнес-процессами (автоматизированное или «ручное»
управление разработкой) и методология разработки ПО;
📌массивами данных и технологиями их обработки.
Итак, начинаем серию публикаций о правовых рисках и неблагоприятных последствиях при создании софтверных проектов, которые наиболее часто выявляются при юридической проверке стартапа.
Первая проблема – в компании неправильно документируется процесс создания ПО👇❌💥
#риски
@VoskhodVC - канал венчурного фонда "Восход
Специально для нашего канала разбирает M&A- и VC-юрист Анастасия Нерчинская. Анастасия дала очень подробные комментарии, которые будут полезны тем, кто готовится запускать стартап и думает над привлечением инвестиций в будущем. Знание рисков позволит избежать массу негативных последствий. Их мы также разберем в серии постов.
Типовые юридические риски, которые часто встречаются в деятельности разработчиков ПО (особенно на старте) связаны с их ключевыми «активами»:
📌создаваемым программным продуктом или устройством на его основе;
📌командой разработки;
📌возможностью структурирования бизнеса с учетом ИТ-льгот;
📌бизнес-процессами (автоматизированное или «ручное»
управление разработкой) и методология разработки ПО;
📌массивами данных и технологиями их обработки.
Итак, начинаем серию публикаций о правовых рисках и неблагоприятных последствиях при создании софтверных проектов, которые наиболее часто выявляются при юридической проверке стартапа.
Первая проблема – в компании неправильно документируется процесс создания ПО👇❌💥
#риски
@VoskhodVC - канал венчурного фонда "Восход
Разбираем юридические риски разработчиков ПО вместе с профессиональным юристом, Анастасией Нерчинской
⚠️Проблема 1: неправильно документируется процесс создания ПО. Это приводит к тому, что компания считает себя правообладателем ПО, но на самом деле может им не являться.
Примеры типовых ошибок:
🔺Основатели стартапа начали разрабатывать MVP продукта до создания самой компании, а затем просто предоставили ей доступ к кодовой базе (репозиторию), но права на ПО не передали.
🔺СЕО, СТО и другие руководители стартапа сильно вовлечены в процесс создания кода (пишут его сами). Но их трудовые обязанности предполагают выполнение преимущественно управленческих и организационных функций (особенно это справедливо для СЕО), но не разработку ПО.
🔺С разработчиками ПО (штатными или внешними) некорректно оформлены документы, связанные с созданием программных продуктов.
❗Основной риск:
Права на создаваемое ПО принадлежат не компании, а другим лицам (например, работникам, основателям, внешним разработчикам и т.п.). Если они инициируют спор – компании может быть запрещено использовать такие компоненты ПО, в том числе развивать и коммерциализировать его. Это может негативно повлияет на экономику стартапа, вызвать простой бизнеса, потребовать расходов на замену критичных компонентов, затормозить его развитие.
Дополнительные негативные последствия:
▪️Возмещение убытков или выплата компенсации «настоящим» правообладателям ПО;
▪️Возмещение убытков пользователям ПО (клиентам компании, если нее уже есть рынок) вне зависимости от модели распространения ПО;
▪️Сложности с подготовкой компании к новому раунду инвестиций, продаже или IPO.
тг-канал автора: Анастасия Нерчинская
#voskhodvc #риски
@VoskhodVC - канал венчурного фонда "Восход"
⚠️Проблема 1: неправильно документируется процесс создания ПО. Это приводит к тому, что компания считает себя правообладателем ПО, но на самом деле может им не являться.
Примеры типовых ошибок:
🔺Основатели стартапа начали разрабатывать MVP продукта до создания самой компании, а затем просто предоставили ей доступ к кодовой базе (репозиторию), но права на ПО не передали.
🔺СЕО, СТО и другие руководители стартапа сильно вовлечены в процесс создания кода (пишут его сами). Но их трудовые обязанности предполагают выполнение преимущественно управленческих и организационных функций (особенно это справедливо для СЕО), но не разработку ПО.
🔺С разработчиками ПО (штатными или внешними) некорректно оформлены документы, связанные с созданием программных продуктов.
❗Основной риск:
Права на создаваемое ПО принадлежат не компании, а другим лицам (например, работникам, основателям, внешним разработчикам и т.п.). Если они инициируют спор – компании может быть запрещено использовать такие компоненты ПО, в том числе развивать и коммерциализировать его. Это может негативно повлияет на экономику стартапа, вызвать простой бизнеса, потребовать расходов на замену критичных компонентов, затормозить его развитие.
Дополнительные негативные последствия:
▪️Возмещение убытков или выплата компенсации «настоящим» правообладателям ПО;
▪️Возмещение убытков пользователям ПО (клиентам компании, если нее уже есть рынок) вне зависимости от модели распространения ПО;
▪️Сложности с подготовкой компании к новому раунду инвестиций, продаже или IPO.
тг-канал автора: Анастасия Нерчинская
#voskhodvc #риски
@VoskhodVC - канал венчурного фонда "Восход"
⚡Продолжаем разбирать юридические риски и негативные последствия, связанные с разработкой ПО вместе с юристом Анастасией Нерчинской. Первый разбор - тут.
⚠️Проблема 2: несвоевременное оформление прав на ПО в процессе его создания, откладывание “на потом”. Поэтому “в моменте” сложно доказать, что права на конкретные компоненты ПО принадлежат стартапу.
Примеры типовых ошибок:
🔺На начальных этапах деятельности стартапа (особенно в процессе проверки гипотезы) на корректное юридическое оформление документации по разработке ПО обычно нет необходимой экспертизы (для этого нужно привлекать профессионального ИТ-юриста).
🔺Компания понимает, что у нее хорошие отношения с разработчиками, «все свои», а значит, все необходимые документы и процессы можно оформить позже (например, перед новым раундом).
🔺У стартапа небольшая команда, поэтому процессы разработки не автоматизированы, бэк-офиса нет, а оформление документов в «ручном режиме» по каждому созданному объекту ПО отвлекает от основной работы, что не кажется эффективным.
🔺В компании не выстроены механизмы работы с информацией и трекингом задач в процессе создания ПО: отсутствует защита от утечек информации, не внедрены правила (на уровне локальных нормативных актов) работы с бэкапами и черновыми версиями ПО, репозиториями и учетным записями, системами контроля версий и иными информационными сервисами.
❗Основной риск:
Компания становится уязвима перед конкурентами, и, скорее всего, не сможет защитить свои права на ПО в случае спора с третьим лицом. В любом споре компания должна подтвердить наличие у нее прав на спорный компонент. Если она не сможет сделать это, конкурент компании, даже если он действительно использует заимствованную разработку стартапа, не будет привлечен к ответственности. Если спорный компонент ПО был значимым – компания утратит конкурентное преимущество.
Дополнительные негативные последствия:
▪️Кто-то из ключевых разработчиков может уволиться из компании; с кем-то могут испортиться отношения и т.п., - ничего «дооформить» не получится или это станет сложнее;
▪️В процессе развития продукта сильно усложняется архитектура ПО. Поскольку отдельные части ПО и без того сложно идентифицировать для целей документирования, если откладывать процесс оформления «на потом» - можно «потерять» ряд компонентов или потратить на эту задачу намного больше ресурсов.
тг-канал автора: Анастасия Нерчинская
#voskhodvc #риски
@VoskhodVC - канал венчурного фонда "Восход"
⚠️Проблема 2: несвоевременное оформление прав на ПО в процессе его создания, откладывание “на потом”. Поэтому “в моменте” сложно доказать, что права на конкретные компоненты ПО принадлежат стартапу.
Примеры типовых ошибок:
🔺На начальных этапах деятельности стартапа (особенно в процессе проверки гипотезы) на корректное юридическое оформление документации по разработке ПО обычно нет необходимой экспертизы (для этого нужно привлекать профессионального ИТ-юриста).
🔺Компания понимает, что у нее хорошие отношения с разработчиками, «все свои», а значит, все необходимые документы и процессы можно оформить позже (например, перед новым раундом).
🔺У стартапа небольшая команда, поэтому процессы разработки не автоматизированы, бэк-офиса нет, а оформление документов в «ручном режиме» по каждому созданному объекту ПО отвлекает от основной работы, что не кажется эффективным.
🔺В компании не выстроены механизмы работы с информацией и трекингом задач в процессе создания ПО: отсутствует защита от утечек информации, не внедрены правила (на уровне локальных нормативных актов) работы с бэкапами и черновыми версиями ПО, репозиториями и учетным записями, системами контроля версий и иными информационными сервисами.
❗Основной риск:
Компания становится уязвима перед конкурентами, и, скорее всего, не сможет защитить свои права на ПО в случае спора с третьим лицом. В любом споре компания должна подтвердить наличие у нее прав на спорный компонент. Если она не сможет сделать это, конкурент компании, даже если он действительно использует заимствованную разработку стартапа, не будет привлечен к ответственности. Если спорный компонент ПО был значимым – компания утратит конкурентное преимущество.
Дополнительные негативные последствия:
▪️Кто-то из ключевых разработчиков может уволиться из компании; с кем-то могут испортиться отношения и т.п., - ничего «дооформить» не получится или это станет сложнее;
▪️В процессе развития продукта сильно усложняется архитектура ПО. Поскольку отдельные части ПО и без того сложно идентифицировать для целей документирования, если откладывать процесс оформления «на потом» - можно «потерять» ряд компонентов или потратить на эту задачу намного больше ресурсов.
тг-канал автора: Анастасия Нерчинская
#voskhodvc #риски
@VoskhodVC - канал венчурного фонда "Восход"