Выбор платформы для интернет-магазина в зависимости от размера бизнеса
Привет, VC! Меня зовут Андрей Фролов, аккаунт-директор в команде php-разработчиков для ecommerce Metalcode.
В связи с тенденцией нового витка развития интернет-магазинов в эпоху маркетплейсов напишу своё личное мнение по выбору платформы для запуска интернет-магазина или еком-направления в компании.
Моё мнение основано на практике работы в разработке и технической поддержке интернет-магазинов. Больше 9 лет я работаю с екомом и выделил одинаковые проблемы в зависимости от годовой выручки интернет-магазина.
Надеюсь, это поможет компаниям и брендам, которые планируют разработку своего интернет-магазина.
Выручка до 100 млн. рублей
Что использовать?
SaaS-решения с готовым функционалом и модулями - Insales, Tilda, CS-Cart.
Почему?
При таком размере у екома ещё нет уникальных бизнес-процессов и запроса на кастомную разработку. Всё можно уложить в рамки платформы. Не нужно привлекать разработчиков для реализации "выдуманных фичей". Часто это пробелы в бизнес-процессах, которые решаются изменением самого процесса.
Самый яркий пример, это использование Битрикса на таком размере. Тут быстро придёт тупик. Стоимость разработки на Битриксе просто не подходит размеру вашего интернет-магазина. Не нужно мучать себя и подрядчиков в поиске самого дешевого.
Выручка 100 млн - 1,5 млрд
На этом размере уже появляются кастомные бизнес-процессы и запросы на интеграции с внешними системами. Требуется доступ к коду и команда разработки. Именно команда. Один разработчик ничего не сделает. Бизнес-аналитик, менеджер, разработчик - минимальный состав команды.
Что использовать?
1С-Битрикс.
Почему?
В Битриксе уже есть много модулей, которые требуется настроить и кастомизировать под вас, а так же внутри него можно проводить разработку кастомного функционала. Витрина товаров дополняется инструментами персонализации и конструкторами или особенностями товаров.
Например, это могут быть товары по сериям со сроками годности и нужно проводить кастомную интеграцию каталога с 1С.
Выручка от 1,5 млрд
Переход на уровень фреймворков.
Что использовать?
Например, Ensi.
Почему?
Здесь бизнес упирается в ограничения готовой платформы и дальнейшее масштабирование становится медленным и дорогим.
На этом этапе в бизнесе есть уже построенные бизнес-процессы, которые нужно не подстроить под "коробку" и перевести как есть на платформу, а нужна возможность настроить саму платформу под процессы.
В своём Telegram-канале пишу про маркетинг и продажи в b2b, а также про выбор IT-решений для бизнеса - Фролов | бизнес для бизнеса.
Telegram-канал Metalcode
Главное, чтобы потом разработка не инвестировала в тебя)
Какой бюджет закладывать на заказную разработку, если ты посерединке из приведенных примеров? Считать как процент от годового оборота, который нужно реинвестировать в ИТ? На примере того же битрикса
Думаю если в процентах, то нужно реинвестировать 5-7 % от годового оборота магазина. Но не менее 4-5 млн рублей. Иначе лучше использовать saas-решения, а бюджет направить на привлечение трафика.
А когда подрастешь, маркетинговые бюджеты умножить и добавить разработку?)
Круто же когда все согласовано, разработка отвечает целям общей стратегии, в том числе маркетинговым активностям, а не остается бек-офисом который четотам пилит и жрет бюджет.
Есть общая стратегия, есть бюджет на маркетинг и на разработку. Затраты на разработку должны быть связаны с эффективностью от внедрения той или иной "фичи", не разработка ради разработки. В общем без понимания куда идти и как оценивать эффективность - печальные результаты. Постоянный подрядчик делает работу более предсказуемой в плане бюджетов т.к. с ним можно спланировать работы и оценки на будущие работы.
Почему такой размер компании для внедрения e-commerce платформы ensi — хорошо обосновал Сергей Мелихов в интервью https://vc.ru/marketing/989454-lyubaya-kompaniya-okazyvayushchaya-it-uslugi-mechtaet-stat-produktovoy-sergey-melihov-sovladelec-ensi-i-greensight
Забавно, когда коробочное решение помогает компании исправить кривой бизнес-процесс – привести его к типовому, стандартному, отказавшись от своего велосипеда и это начинает работать лучше. Видел такие примеры
В этом вопрос хорошо работает концепция Гартнера Pace-layered strategy, которая предлагает разный взгляд на системы в зависимости от того, откуда поступают требования и формируют ли процессы, которые поддерживают эти системы, ваши конкурентные преимущества.
Внедрение коробки с типовыми для рынка процессами может быть эффективным там, где вам не нужно никакой уникальности (у большинства ритейлеров, например, бухгалтерия). А ваши киллер-фичи или зону экспериментов поддерживать через коробки вряд ли получится.
Чуть подробнее про это писал тут: https://t.me/ecomparticles/699
Gartner Pace-Layered Application Strategy относит системы компании к одному из трех слоев в зависимости от того, как сформулированы требования, и насколько реализованные в них процессы обеспечивают конкурентные преимущества ритейлера на рынке.
🟦 Например, налоговый учет устроен...
Gartner Pace-Layered Application Strategy относит системы компании к одному из трех слоев в зависимости от того, как сформулированы требования, и насколько реализованные в них процессы обеспечивают конкурентные преимущества ритейлера на рынке.
🟦 Например, налоговый учет устроен примерно одинаково в любой компании, поэтому для автоматизации требуется стандартная многофункциональная система (уровень Systems of Records).
🟩 Обработка заказов у каждого ритейлера организована по-разному. Это часть клиентского сервиса, который отличает одну компанию от другой. Для автоматизации этого ключевого процесса требуется разработка приложения по требованиям бизнеса, который хорошо представляет, что именно ему нужно (уровень Systems of Differentiation).
🟨 Наконец, любая цифровая витрина — это зона постоянных экспериментов, которые поддерживают системы, развиваемые по гибким методологиям (уровень Systems of Innovation). Требования в этой зоне возникают спонтанно, а time-to-market должен быть минимальным.
100% так, не надо ломать преимущества компании, затаскивая их в коробочное решение.
В тоже время, в небольшом ритейлере половина БП может быть организована по наитию. Эффективность спорная, работает и ладно. Преимущество ли?)
Анализируешь, предлагаешь поменять на типовой процесс – начинает работать лучше.
Например, сборка заказов – вполне себе критичный процесс для клиентского сервиса: от поступления до отгрузки может быть полностью выдуман неким завсклада. Работает. Но как только пиковая нагрузка – возникают человеческие ошибки, пересорты и тд. Идем разбираться, хотим дать инструмент – ТСД-шку. Но этот инструмент вообще не ложится на выдуманные БП. Можно все переписать под их процесс (1С-ку, ПО для ТСД и тд), но разумнее показать как “правильно” – типовой процесс и вполне может заработать эффективнее чем было, уж точно более регламентировано. ТСД банальный пример, но у них как раз ПО коробочное, хорошо отражает смысл.
На мой взгляд, тут перепутано следствие и причина.
В вашем примере противопоставляется отсутствие процесса и хоть какой-то процесс. Второе, как правило, работает лучше, особенно на дистанции. Автоматизация не может быть эффективной, если в системы просто переносятся исторически сложившийся порядок операций: сначала нужно создать процесс, а потом уже думать о том, чтобы перенести его в системы.
И это типичный неуспешный кейс — внедрить систему, чтобы появились процессы. Давайте внедрим CRM и у тогда у нас появится процесс продаж. Обычно это не срабатывает, процессы не появляются. Вместо этого у людей прирастает работы в виде администрирования системы, которую они в 100% случаев начинают саботировать.
И еще: довольно часто бывает, что автоматизаторы слишком переоценивают свое видение ситуации, и недооценивают видение людей на местах. А последние строят такие операции, которые учитывают большое количество нюансов и частных случаев, которые проходят мимо тех, кто загоняет их в какую-то систему. Это тоже довольно важный аспект.
Сейчас мы вам тут все автоматизируем! =)
Вот есть исторически сложившийся процесс, не очень удачный. С ним надо что-то делать – трансформировать, поправить, удалить и сделать новый.
Есть пример как может быть – типовой процесс (пусть будет модно назван бестпрактик), который себя хорошо показывает. Допустим, я о нем знаю, потому что он заложен в какой-то системе. Коробочное решение, потенциально, делали не дураки и предлагают решение универсальное, для всех – что на малом масштабе часто и требуется.
И если мне о таком типовом процессе известно, так еще и известно, что он вполне ложится в наши системы, зная их ограничения – то первично предложу рассмотреть его.
Дальше скорректировать используя знания тех самых людей на местах, которых я не обесцениваю. Наоборот надо брать их в рабочую группу и вовлекать, если получится.
Сначала исправляется сам процесс, а потом уже перекладывается в какие-либо системы. Не вижу противоречия. Пусть новый процесс будет продиктован какой-то системой / коробокой / ПО, если он видится как более верный, что в этом плохого? Нет попытки натянуть свой избыточный инструмент туда где все прекрасно работает.
Все так: сначала исправляется сам процесс, потом перекладывается в какие-либо системы.
А ведь всё логично и не поспоришь особо_)
А мы всегда за фреймворк. Ну вот ты сейчас 500-1000 миллионов. А через год будет 1500. И все, переделывать?)
Вот сейчас ты 500-1000 миллионов, а через год меньше 100 и вероятность этого повыше будет чем то, что будет 1,5 ярда. А ты вбухал средств в разработку "на вырост" на фреймворке и платишь за его обслуживание и развитие немеряно алчным пограмистам... И что теперь всё переделывать на Тильду?)
"Собачки мы уходим" - алчные программисты, которые не хотят быть в проекте на 100 лямов ))
Забирайте собачек, мы приведем волков!)
Сибирских!)
Как оцениваете вероятность?) Предпринимательство это всегда риск. Если держать в голове, что завтра будет пипец, то лучше не начинать.
Если делаешь – не бойся, если боишься – не делай))
Ну и мы же про средний/крупный бизнес уже говорим, там такое падение не из-за сайта)
Да, наверняка есть и статистика, но это же общеизвестный принцип пирамиды) чем выше, тем тяжелее и подобных меньше. Понятно что каждый думает что это не про него и вообще "он вырастит на 500% в следующем году", но...
Да, лично я выбрал бы фреймворк уже с оборотом больше 100 млн-) Ну хотя бы тот же Laravel, если про php. И уж точно не Битрикс... Но это мои личные заморочки + понимание во что это мне выльется в обслуживание и развитие...Тут же в посте речь идёт о подходе в целом для бизнеса скорее, как я понял
Конечно сайт на фреймоврке не станет причиной кризиса компании. Но может в совокупности факторов стать тем что утянет на дно... Ну типа "сайт на вырост", машину в лизинг пореспектабельнее, секретаршу посимпатичнее и т.д.))
Господи 🥲 вот фреймворки, и самописная разработки это все точно до миллиарда смысла не имеет. Т.к. столько проектов видел, на зенде или симфони, а оно там не нужно было. Задачи простые, рокетсайенс нету 🤷♂️ На кой там фреймворк, а потом разработчик уезжает в закат и пум-пум-пууум 😅
Как вы это оценили?) Исследования может есть? Почему фреймворки? Это не сильно дороже битрикса, если подходить с умом, но затем внедрить какую-то фичу сильно дешевле. У нас есть кейс, где заказчик вкладывал два раза в коробку, но она не оправдывала себя. Фреймворк взлетел) Конечно, есть много других факторов, но как есть)
Если близко к ярду, и есть предпосылки к кратному росту - можно идти в фреймворки "на вырост".
Если на уровне 500млн - значит уже на битриксе 😃 (очень вряд ли на инсейлз), значит стоит еще подрастить оборот, нормально реализованный сайт и интеграции потянет. А дальше реплатформинг.
500 это выручка? А маржинальность? Почему это не смотрим?)) Посмотрите на ИМ 5-7 лет назад, многие уже тогда делали на фреймворках)
Если отбросить легкое утрирование вокруг битрикса, я не отрицаю и не противопоставляю его фреймворкам, особенно php-шным.
В рамках текущего разбора битрикс и laravel, например, будут в одном сегменте – посерединке. Главное, применять по назначению и под потребности. Битрикс под более типовое (и обычно быстрый запуск), laravel под более кастомное/сервисное, более сложные бизнес-процессы.
В рамках статьи пытаемся предостеречь маленькие компании от кастомной разработки. А крупный от битрикса =) Для крупного мне очень симпатизирует ensi (в составе кстати имеет laravel, но там много чего еще интересного, на то она и платформа).
Именно, не противопоставление одно другому, а применение на основе опыта и проблем, что встречаются в работе
У вас конфликт интересов, вы зарабатываете на кастомизации этих фреймворков :)
Я может что то не понимаю, но почему нельзя сваять магазин на Битриксе, и сделать интеграцию с 1с за 500-700 тысяч на типовом решении и использовать хорошие интеграции и спокойно работать 5-7 лет пока идёшь к милиарду от 100 млн?
Потому что можно сваять магазин на SaaS решении с идеальной интеграцией с 1С и др. и стоимостью менее 100к в год ))
А что это за saas?
Облачная платформа, где можно "арендовать" сайт. Обычно с кучей готовых интеграций. Например insales
Да не :) это все в пользу нищих и наивных. Арендовать, за копейки чет сделать. 100к Инсейлс будет только сама платформа. Сделать настройки и уникализировать + настроить эквайринги, рассчет доставки и прочую веутрянку минимум 100 часов по ставке 1,5к в итоге получаем лонч 250к + саппорт по мелочи 50к в год. Итого 300к ща первый год, это минималка. Но тут это тебе не принадлежит, и ты ещё на 100к в год прилипаешь по софту. А Битрикс не стоит таких денег. Уж сильно не обьективно это всё
Тут про мышление) Если тебе жмет 300к разработка, то может не тем занят)) Посмотрите сколько вкладывают в разработку топовые продукты в своих нишах) Те же ИМ)
Дак я не говорю о том жмёт или не жмёт 😅 я говорю о том что говорить что saas это прям мастхев до 100 млн рублей не корректно. Если например сравнить его с Битриксом то это тож самое по деньгам, если не дешевле, при том что кастомить saas сильно сложнее или вообще невозможно. Про фреймворки, просто негативный опыт, они все прилетали мне без документации и типа ну давайте пртоатим 150-200 часов чтобы вникнуть что там написано, естественно ни кто не хочет вкладывать в рисеч чужого кода эти деньги
У нас получается сделать всё это: настройки, уникализировать + настроить эквайринги, расчет доставки и прочую внутрянку. Всё делают сами специалисты, а не просто высылают инструкции. Всё в бюджете до 100к в год.
Плюсом ежемесячно получаешь все обновления. Всё, что запрашивают такие же предприниматели, как ты сам.
У вас это у кого?
Здесь очень не любят рекламу. Поэтому ссылка только в моём профиле ))
А ну так эмм… в том то и дело) получается за 100к можно только с ноунеймами работать из saas что естественно риск, сегодня эта платформа есть и у неё идеальные интеграции, все бесшовно, а завтра её нет, и че делать 😟
Если такое решение никак не ограничивает, можно хоть до 100 ярдов идти
В ваших рекомендациях выручка от онлайн направления или в целом по компании?
Рассматривал именно онлайн направление отдельно
Но тут можно иначе посмотреть. Крупный производитель промышленного оборудования с годовой выручкой 3 млрд решает строить еком для b2b. И с чего начинать? Со стратегии думаю, куда хотим прийти в итоге и от этого выбирать решение