{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Выбор платформы для интернет-магазина в зависимости от размера бизнеса

Привет, VC! Меня зовут Андрей Фролов, аккаунт-директор в команде php-разработчиков для ecommerce Metalcode.

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

Моё мнение основано на практике работы в разработке и технической поддержке интернет-магазинов. Больше 9 лет я работаю с екомом и выделил одинаковые проблемы в зависимости от годовой выручки интернет-магазина.

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

Выручка до 100 млн. рублей

Что использовать?

SaaS-решения с готовым функционалом и модулями - Insales, Tilda, CS-Cart.

Почему?

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

Проще говоря на этом этапе нужная витрина товаров с возможностью заказать.

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

Выручка 100 млн - 1,5 млрд

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

Что использовать?

1С-Битрикс.

Почему?

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

Например, это могут быть товары по сериям со сроками годности и нужно проводить кастомную интеграцию каталога с 1С.

Выручка от 1,5 млрд

Переход на уровень фреймворков.

Что использовать?

Например, Ensi.

Почему?

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

На этом этапе в бизнесе есть уже построенные бизнес-процессы, которые нужно не подстроить под "коробку" и перевести как есть на платформу, а нужна возможность настроить саму платформу под процессы.

В своём Telegram-канале пишу про маркетинг и продажи в b2b, а также про выбор IT-решений для бизнеса - Фролов | бизнес для бизнеса.

Telegram-канал Metalcode

0
43 комментария
Написать комментарий...
Metalcode
Ответить
Развернуть ветку
Андрей Фролов
Автор

Главное, чтобы потом разработка не инвестировала в тебя)

Ответить
Развернуть ветку
Антон Носков

Какой бюджет закладывать на заказную разработку, если ты посерединке из приведенных примеров? Считать как процент от годового оборота, который нужно реинвестировать в ИТ? На примере того же битрикса

Ответить
Развернуть ветку
Андрей Фролов
Автор

Думаю если в процентах, то нужно реинвестировать 5-7 % от годового оборота магазина. Но не менее 4-5 млн рублей. Иначе лучше использовать saas-решения, а бюджет направить на привлечение трафика.

Ответить
Развернуть ветку
Антон Носков
а бюджет направить на привлечение трафика.

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

Ответить
Развернуть ветку
Андрей Фролов
Автор

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

Ответить
Развернуть ветку
Metalcode

Почему такой размер компании для внедрения 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% случаев начинают саботировать.

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

Ответить
Развернуть ветку
Антон Носков

Сейчас мы вам тут все автоматизируем! =)

Вот есть исторически сложившийся процесс, не очень удачный. С ним надо что-то делать – трансформировать, поправить, удалить и сделать новый.

Есть пример как может быть – типовой процесс (пусть будет модно назван бестпрактик), который себя хорошо показывает. Допустим, я о нем знаю, потому что он заложен в какой-то системе. Коробочное решение, потенциально, делали не дураки и предлагают решение универсальное, для всех – что на малом масштабе часто и требуется.

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

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

Сначала исправляется сам процесс, а потом уже перекладывается в какие-либо системы. Не вижу противоречия. Пусть новый процесс будет продиктован какой-то системой / коробокой / ПО, если он видится как более верный, что в этом плохого? Нет попытки натянуть свой избыточный инструмент туда где все прекрасно работает.

Ответить
Развернуть ветку
Сергей Мелихов

Все так: сначала исправляется сам процесс, потом перекладывается в какие-либо системы.

Ответить
Развернуть ветку
Алексей Осипенко

А ведь всё логично и не поспоришь особо_)

Ответить
Развернуть ветку
Саша Комбаров из Pyrobyte.ru

А мы всегда за фреймворк. Ну вот ты сейчас 500-1000 миллионов. А через год будет 1500. И все, переделывать?)

Ответить
Развернуть ветку
Алексей Осипенко

Вот сейчас ты 500-1000 миллионов, а через год меньше 100 и вероятность этого повыше будет чем то, что будет 1,5 ярда. А ты вбухал средств в разработку "на вырост" на фреймворке и платишь за его обслуживание и развитие немеряно алчным пограмистам... И что теперь всё переделывать на Тильду?)

Ответить
Развернуть ветку
Антон Носков

"Собачки мы уходим" - алчные программисты, которые не хотят быть в проекте на 100 лямов ))

Ответить
Развернуть ветку
Саша Комбаров из Pyrobyte.ru

Забирайте собачек, мы приведем волков!)

Ответить
Развернуть ветку
Антон Носков

Сибирских!)

Ответить
Развернуть ветку
Саша Комбаров из Pyrobyte.ru

Как оцениваете вероятность?) Предпринимательство это всегда риск. Если держать в голове, что завтра будет пипец, то лучше не начинать.
Если делаешь – не бойся, если боишься – не делай))
Ну и мы же про средний/крупный бизнес уже говорим, там такое падение не из-за сайта)

Ответить
Развернуть ветку
Алексей Осипенко

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

Да, лично я выбрал бы фреймворк уже с оборотом больше 100 млн-) Ну хотя бы тот же Laravel, если про php. И уж точно не Битрикс... Но это мои личные заморочки + понимание во что это мне выльется в обслуживание и развитие...Тут же в посте речь идёт о подходе в целом для бизнеса скорее, как я понял

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

Ответить
Развернуть ветку
Литвинов Александр

Господи 🥲 вот фреймворки, и самописная разработки это все точно до миллиарда смысла не имеет. Т.к. столько проектов видел, на зенде или симфони, а оно там не нужно было. Задачи простые, рокетсайенс нету 🤷‍♂️ На кой там фреймворк, а потом разработчик уезжает в закат и пум-пум-пууум 😅

Ответить
Развернуть ветку
Саша Комбаров из Pyrobyte.ru

Как вы это оценили?) Исследования может есть? Почему фреймворки? Это не сильно дороже битрикса, если подходить с умом, но затем внедрить какую-то фичу сильно дешевле. У нас есть кейс, где заказчик вкладывал два раза в коробку, но она не оправдывала себя. Фреймворк взлетел) Конечно, есть много других факторов, но как есть)

Ответить
Развернуть ветку
Антон Носков

Если близко к ярду, и есть предпосылки к кратному росту - можно идти в фреймворки "на вырост".

Если на уровне 500млн - значит уже на битриксе 😃 (очень вряд ли на инсейлз), значит стоит еще подрастить оборот, нормально реализованный сайт и интеграции потянет. А дальше реплатформинг.

Ответить
Развернуть ветку
Саша Комбаров из Pyrobyte.ru

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к в год прилипаешь по софту. А Битрикс не стоит таких денег. Уж сильно не обьективно это всё

Ответить
Развернуть ветку
Саша Комбаров из Pyrobyte.ru

Тут про мышление) Если тебе жмет 300к разработка, то может не тем занят)) Посмотрите сколько вкладывают в разработку топовые продукты в своих нишах) Те же ИМ)

Ответить
Развернуть ветку
Литвинов Александр

Дак я не говорю о том жмёт или не жмёт 😅 я говорю о том что говорить что saas это прям мастхев до 100 млн рублей не корректно. Если например сравнить его с Битриксом то это тож самое по деньгам, если не дешевле, при том что кастомить saas сильно сложнее или вообще невозможно. Про фреймворки, просто негативный опыт, они все прилетали мне без документации и типа ну давайте пртоатим 150-200 часов чтобы вникнуть что там написано, естественно ни кто не хочет вкладывать в рисеч чужого кода эти деньги

Ответить
Развернуть ветку
Николай Истомин

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

Ответить
Развернуть ветку
Литвинов Александр

У вас это у кого?

Ответить
Развернуть ветку
Николай Истомин

Здесь очень не любят рекламу. Поэтому ссылка только в моём профиле ))

Ответить
Развернуть ветку
Литвинов Александр

А ну так эмм… в том то и дело) получается за 100к можно только с ноунеймами работать из saas что естественно риск, сегодня эта платформа есть и у неё идеальные интеграции, все бесшовно, а завтра её нет, и че делать 😟

Ответить
Развернуть ветку
Сергей Мелихов

Если такое решение никак не ограничивает, можно хоть до 100 ярдов идти

Ответить
Развернуть ветку
Николай Истомин

В ваших рекомендациях выручка от онлайн направления или в целом по компании?

Ответить
Развернуть ветку
Андрей Фролов
Автор

Рассматривал именно онлайн направление отдельно

Ответить
Развернуть ветку
Андрей Фролов
Автор

Но тут можно иначе посмотреть. Крупный производитель промышленного оборудования с годовой выручкой 3 млрд решает строить еком для b2b. И с чего начинать? Со стратегии думаю, куда хотим прийти в итоге и от этого выбирать решение

Ответить
Развернуть ветку
40 комментариев
Раскрывать всегда