Бизнес внутри бизнеса: надо ли проекты выделять в дочерние бизнесы?

upload0jcegj60r6.jpg

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

Я почти 15 лет работаю в ИТ на ТОП позициях, запускал два своих стартапа, имею опыт организации подразделений внутри компаний. Расскажу свое экспертное мнение на тему организации бизнеса внутри компании.

Если кратко ответить на вопрос статьи — нужно стремиться выделить бизнес в отдельное направления, но делать это нужно грамотно и постепенно.

Больше не нужно искать и обзванивать каждое диджитал-агентство
Создайте конкурс на workspace.ru — получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь — выберите и сэкономьте до 30%.
Создать конкурс →

Диверсификация

Это аксиома для любого бизнеса. В ИТ бизнесе это особенно важно. Совершенно недопустимо разрабатывать проекты, не задумываясь о смежных направлениях. Работая лишь в одной нише, вы складываете все яйца в одну корзину. Жить можно, до первых проблем.

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

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

Разберем примеры диверсификации для разных типов ИТ компаний.

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

Разработка под заказ. У вас есть четкое ТЗ и договор на NDA и отчуждение авторских прав. Но знания ваших программистов никто не отнимет. Даже при написании проекта по ТЗ у вас есть гибкость в реализации (почти всегда). Вы можете на старте заложить себе возможность гибкого развития проекта, а при сдаче проекта заявить это заказчику. Этим вы с высокой долей вероятности сможете его вернуть к себе с новым заказом на развитие проекта.

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

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

Тендерная разработка. Чтобы выиграть тендер, у вас должна быть возможность предложить решение за минимальные деньги. Этого можно добиться как раз за счет наличия у вас в компании собственных готовых решений или гибкой платформы для быстрой адаптации под клиента. Развивая такую платформу, вы сможете предлагать готовые решения широкому кругу заказчиков.

Главный вывод — при разработке любого проекта или задачи всегда старайтесь взглянуть на нее чуть шире имеющегося заказа. Подумать, как вы можете переиспользовать его в будущем. Или предположить, с чем к вам вернется этот заказчик в будущем. И заложить допустимые варианты в создаваемое решение. Как правило, такое решение не увеличивает стоимость разработки проекта (укладывается в оценку рисков). Зато дает вам возможность развиваться.

Шаги

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

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

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

Как видно, такой подход не увеличит бюджет на проект.

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

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

Если же получается создать что-то новое, то сразу выделять его в отдельное товарное предложение.

Начать предлагать решение клиентам. Этот шаг можно начать делать и не имея готового продукта, это позволит в целом понять готовы ли клиенты за него платить.

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

Главная ваша задача — определить спрос. Подтвердить гипотезу востребованности нового решения путем совершения 2–3 продаж.

Развить направление. Ваш продукт начали активно покупать. На базе обратной связи от клиента вам нужно продолжить развивать продукт. Это все уже классическая продуктовая разработка.

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

Оценить потенциал роста. Пора ставить задачу маркетологам провести оценку рынка на предмет емкости. Скорее всего вы это уже делали на предыдущих шагах. Сейчас эти данные стоит актуализировать.

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

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

Сейчас же пора подготовить юр лицо к дальнейшей самостоятельной жизни этого направления.

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

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

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

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

Полный текст статьи читайте на CMS Magazine