Конструктор продуктов или единая экосистема.Что выгоднее и реальнее для девелопера

Рассмотрели различия подходов к созданию единой экосистемы продуктов и к платформам-конструкторам — в статье на портале Всеостройке.рф.

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

Конструктор продуктов: гибкость и скорость адаптации

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

В качестве примера можно привести платформу «Самолет 10D», разработанную Группой «Самолет». Эта система объединяет различные модули, охватывающие широкий спектр задач, от мониторинга строительных площадок до управления логистикой и поставками материалов. Благодаря такому модульному подходу компания смогла значительно сократить сроки согласования документации, снизить количество ошибок в отчетности и оперативно тестировать новые сервисы. Цифровизация позволила компании увеличить производительность труда на 60% за 1,5 года.

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

«Конструктор продуктов или единая система? Реальный ответ — не то и не другое в чистом виде. 

Конструктор продуктов, или, так скажем, “цифровое болото”, требует множества интеграционных механизмов. В информационном моделировании это очень сложный и к тому же проблемный инструмент для использования данных в виде IFC. Дешевизна компонентов “цифрового болота” обернётся потерями времени и дополнительными затратами.

Единая система единой системе — большая разница. Если речь идёт о единой экосистеме ведущего вендора “СиСофт Девелопмент”, то это удача. Но и здесь есть проблемы, которые решаются за счёт интеграции с другими российскими разработчиками по направлениям, которые сам “СиСофт Девелопмент” не считает своими бизнес-направлениями. 

Например, есть два отечественных разработчика по технологиям информационного моделирования, которые преуспели в своих областях. Я говорю о “Кредо-Диалоге” и “Топоматике”. “Кредо-Диалог” специализируется на информационном моделировании инженерной геологии и линейных объектов — автомобильных дорог со всей инфраструктурой. “Топоматик” занимается проектированием железнодорожных систем. У каждого из этих разработчиков и у “СиСофт Девелопмент” есть свой формат с открытой спецификацией. Технологическая совместимость этих форматов обеспечена таким образом, что не нужно пользоваться форматом IFC. Поэтому пользователи могут удобно создавать такой конструктор продуктов от этих вендоров, и это будет бесшовная линейка единой экосистемы, но от различных производителей. Это уже реальность, и когда пользователь понимает это удобство, то в дальнейшем его не приходится уговаривать использовать такие системы.

Как определить, когда выгоднее инвестировать в конструктор продуктов, а когда в экосистему? Рекомендую обращать внимание на бесшовность технологий информационного моделирования для формирования и ведения информационной модели по всему жизненному циклу. Это приоритет при выборе разработчика программного обеспечения. Повторю: экономия при “конструкторе” — это затраты на преодоление хаоса и проблем от IFC.

Если у какого-то разработчика всего один продукт, его нужно использовать там, где потребитель считает его необходимым и максимально эффективным. Во всех других случаях стоит отдавать предпочтение бесшовным линейкам ведущих разработчиков, особенно если есть необходимость в передаче информационной модели на следующий этап жизненного цикла», — Михаил Бочаров, заместитель генерального директора по научной работе АО «СиСофт Девелопмент».

Единая экосистема: синергия и лояльность клиентов

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

Одним из самых известных примеров реализации концепции единой экосистемы является проект ПИК Digital, разработанный компанией ПИК. Эта система включает в себя набор сервисов: от платформы 3D-проектирования BIMTeam до маркетплейса услуг ПИК-Сервис и Family Manager — многоролевой платформы для работы с библиотеками ТИМ-компонентов. 

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

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

На рынке существует множество ИТ-продуктов, которые подходят под ТЗ застройщика. Их внедрение по отдельности поможет решить локальные задачи: понадобился онлайн-каталог на сайте — использовали решение от одного разработчика, начали работать с агентами — подключили сервис для работы с партнёрами от другого вендора. 

Но со временем такая лоскутная автоматизация превращает работу с сервисами в хаос. Чтобы внедрить новый сервис, девелоперу приходится искать место в ИТ-инфраструктуре, тратить время и деньги на интеграцию, а также обучать команду работе с каждой новой программой. Разрозненные системы приводят к низкой доступности данных и сложностям с управленческим контролем. Ещё работать в конструкторе продуктов дорого: нужно обучать и содержать команду сопровождения и порой покупать лицензии на дублирующий функционал.

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

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

Также плюсом будет наличие открытого API – он пригодится, если вы собираетесь расширять функциональность экосистемы самостоятельно», — Максим Селезенев, директор по продукту Profitbase.

Гибридный подход: оптимальное сочетание гибкости и синергии

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

Примером реализации гибридного подхода является стратегия ДОМ.РФ. Госкорпорация разработала ряд модульных сервисов, таких как аналитический конструктор «Про Дома» и маркетплейс ДДУ, которые интегрированы в единую экосистему. Это позволяет ДОМ.РФ оперативно реагировать на изменения рынка и одновременно обеспечивать синергию между различными сервисами, повышая их ценность для клиентов.

Как работает платформер?

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

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

Альтернативой платформингу является «клонирование и владение», когда продукт копируется и создаётся заново с нуля с небольшими изменениями, чтобы создать новую версию оригинала.

«На сегодняшний день на рынке представлено более 100 proptech-решений. Условно их делят на 3 большие категории, а именно: решения для проектирования и строительства, для продаж и для эксплуатации.

Наиболее востребованными решениями, по нашей оценке, являются решения по проектированию, контролю строительства, управлению продажами и заселением, а также эксплуатацией и гарантийными заявками. Это связано с тем, что вопросы снижения издержек, связанных с качеством строительства, выходит на первый план у многих девелоперов. Успех, по моему мнению, достигается не через сложные и громоздкие экосистемы, а через гибкие решения, которые легко интегрируются друг с другом. Например, одно решение может быть ориентировано на BIM-моделирование, другое — на исполнительную документацию, третье — на строительный контроль, а четвертое — на эксплуатацию. Эти решения могут быть разработаны разными компаниями, но их можно объединить у одного заказчика благодаря интеграции. Это позволяет девелоперам удовлетворять свои потребности в цифровизации различных процессов не одним универсальным решением, а путем интеграции подходящих решений от разных поставщиков», — Александр Разин, операционный директор экосистемы «Базис Недвижимость». 

Что первично: продукт или платформа?

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

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

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

«Советы для среднего разработчика, который является основным потребителем в Российской Федерации:

— выбирать надёжных разработчиков с длительным нахождением на рынке;

— обращать внимание на наличие открытого формата с открытой спецификацией;

— учитывать наличие качественной технической поддержки;

— отдавать предпочтение бесшовным линейкам;

— использовать технологии информационного моделирования для всего жизненного цикла информационной модели», — Михаил Бочаров, заместитель генерального директора по научной работе АО «СиСофт Девелопмент».

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

Почему компаниям следует задуматься о платформе?

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

Примеры: Apple и Tesla

• Apple создала сначала компьютер Macintosh, а затем разработала платформу для других устройств и программ.
• Tesla с самого начала инвестировала в разработку платформы для электромобилей, что обеспечило ей конкурентное преимущество и успех на рынке.

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

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

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

«Если планируете запускать проекты быстро и без больших рисков, конструктор может оказаться оптимальным решением. Вы заранее разрабатываете типовые модули (архитектурные, инженерные, планировочные), которые легко комбинировать под разные площадки и цели. Это снижает время проработки каждого нового проекта и делает процесс более предсказуемым. Экосистема же выгоднее, когда ваша цель — не просто продать квартиры, а сформировать вокруг объектов особую среду и инфраструктуру. Большие инвестиции в экосистему окупаются за счёт лояльности клиентов, развития дополнительной коммерции на территории и высокой добавленной ценности проекта в долгосрочной перспективе», — Артур Хасиятуллин, основатель и CEO «Платформа Штаб» (Ex-CEO Russia Traceair).

Конструктор продуктов: гибкость и скорость адаптации

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

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

Однако важно помнить, что конструктор продуктов должен обеспечивать не только скорость и гибкость, но и соответствие потребностям целевой аудитории. В противном случае продукты, созданные по единому шаблону, могут оказаться невостребованными на рынке.
Если же говорить не о разработке собственных продуктов, а о поиске вендоров и софта для решения задач компании, то стоит отметить, что, возможно, идеального продукта для всех нет. И придется собирать «корзинку решений».

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

При этом на рынке уже сформировался достаточно гибкий стек решений, на котором все умеют работать: Word, Excel, MS Project, мессенджеры (Telegram, например), Телемост. Причем все решения бесплатные — даже MS Office, если его и покупать легально, то все равно для производственных задач достается бесплатно, т.к. для других задач он все равно нужен, и нет варианта “не покупать”. 

Т.е. все решения меряются по эффективности с этим бесплатным, не идеальным и не самым эффективным стеком. Это основная причина, почему мы не видим успешных кейсов внедрений комбайнов (типа 1С ERP 2, УСО, БИТ и прочих), т.к. пользователи все равно скатываются в Excel и в лучшем случае из-под палки для формальности всё бьют двойной работой в эти системы.

Чего не скажешь об узкоспециализированных решениях для конкретных задач. Кто станет спорить с тем, что СОД или таск-трекер организовать на специализированной системе эффективнее, чем на Excel? Многие даже готовы за это заплатить.

Основная неэффективность “бесплатного” стека технологий заключается в том, что, во-первых, приходится перебивать данные в разные системы и, во-вторых, форматы данных не стабильны, не структурированы, из-за чего не подлежат системному анализу и использованию. Нестабильность структуры данных в файлах Excel — это обратная сторона медали его гибкости и универсальности.

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

В итоге мы, конечно же, придем к единым экосистемам: каждый узкоспециализированный продукт в такой и растет, просто они сразу в момент не могут стать таковыми. Но пока что на растущем ИТ-рынке для девелопера необходимо искать баланс — выбрать одно центральное решение, в котором он будет администрировать доступы и справочники, и несколько дополнительных узкоспециализированных, самых эффективных, с которыми он сможет сыньегрировать центральное. Т.е. в данном вопросе крайности плохи. И всё пытаться запихнуть в комбайн — плохо, и кучу разрозненных продуктов собрать и пытаться интегрировать — плохо», — Александр Попов, технический директор «Сигнала». 

Факторы успеха и ключевые тренды

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

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

Налаживание процессов разработки

• 3 совета разработчику, который выбирает между конструктором и экосистемой

«Чётко определите стратегические цели: нужен быстрый возврат инвестиций или создание долгосрочной ценности? Если первый вариант, делайте конструктор; если второй — экосистему.

Оцените свои ресурсы: у вас есть экспертиза и партнёры, чтобы развивать комплексную инфраструктуру? Если нет, возможно, лучше начать с конструктора и постепенно наращивать компетенции.

Анализируйте рынок и конкурентов: если похожих экосистем в регионе немного и есть спрос на качественную среду, это отличный шанс занять свою нишу. Но если у конкурентов уже сильные экосистемные проекты, вам может быть выгоднее выделиться за счёт гибкого “конструктора”», — Артур Хасиятуллин, основатель и CEO «Платформа Штаб» (Ex-CEO Russia Traceair).

Выбор стратегии разработки (продукт или платформа) зависит от бизнес-стратегии компании, особенностей рынка и доступных ресурсов. Важно, чтобы выбранный подход соответствовал долгосрочным целям и потребностям целевого рынка.

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

• Продукт — самоценный продукт, используемый независимо или в качестве основы для платформы.
• Платформа — исходный продукт с элементами для использования в качестве платформы.
• Экосистема — совокупность связанных продуктов и сервисов, функционирующих вокруг платформы.

Экосистема: Аналитики прогнозируют, что к 2026 году на экосистемы будет приходиться значительная доля мировой экономики.

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

Зачем создавать экосистему?

• Накопление данных для персонализированных предложений.
• Доступ к ноу-хау других компаний.
• Быстрое масштабирование за счет партнеров.
• Гибкость и устойчивость.
• Повышение привлекательности бренда и конкуренция с маркетплейсами.

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

Сравнение экосистемы и конструктора

• Конструктор продуктов подходит для быстрого вывода новых предложений на рынок и расширения ассортимента. Экосистема целесообразна при наличии лояльной клиентской базы и стремлении к увеличению LTV.
• Ключевые метрики для оценки эффективности: для конструктора — скорость вывода продукта на рынок, затраты на разработку и маркетинг. Для экосистемы — LTV, средний чек, уровень вовлеченности клиентов, количество партнеров.

«Для конструктора в первую очередь важно смотреть на скорость запуска (time-to-market) и себестоимость реализации. Чем быстрее вы сможете предложить новый продукт на рынок (при сохранении качества) и чем меньше ресурсов на это уйдёт, тем успешнее конструктор. В случае экосистемы основная ставка на вовлечённость жителей и партнёров, средний чек/выручку от сервисов на территории, а также на индекс удовлетворённости клиентов (NPS). Если в районе с экосистемой люди охотно остаются, пользуются дополнительными услугами и рекомендуют проект другим, — это главный показатель успеха», — Артур Хасиятуллин, основатель и CEO «Платформа Штаб» (Ex-CEO Russia Traceair).

• Экосистемы зарабатывают на контроле над клиентскими данными, комиссионными от партнерских продаж, увеличении лояльности и LTV клиентов, автоматизации бизнес-процессов.

Выбор между конструктором продуктов и единой экосистемой не является взаимоисключающим. Успешные компании, такие как ПИК и Группа «Самолет», сочетают оба подхода, используя модульные решения для тестирования новых гипотез и экосистемы: для монетизации и повышения лояльности клиентов. Главный тренд — переход от «цифровых фасадов» к глубоким преобразованиям бизнес-моделей, где ИТ становятся не статьей расходов, а источником конкурентных преимуществ. В конечном счёте, наиболее успешными будут те компании, которые смогут создать гибкую и масштабируемую ИТ-инфраструктуру, позволяющую оперативно реагировать на изменения рынка и обеспечивать максимальную ценность для клиентов.

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

Ранее мы писали про инструменты ПИКа для повышения производительности BIM-проектирования — «Робота» R2 и PIK СheckUP, а также про новое решение для проектирования интерьеров от проектного института Группы «Самолет» S23.