Содержание:

1. Почему так важно запустить интернет-магазин быстрее

2. Из чего состоит MVP маленького и среднего магазина

3. Процесс запуска проекта

4. Как не превратить проект в долгострой

5. Чем отличается техническое решение от организационного?

Почему так важно запустить интернет-магазин быстрее

Владельцы новых интернет-магазинов делятся обычно на две диаметрально противоположные категории:

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

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

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

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

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

Почему быстрый запуск — это важно?

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

«Упущенная выгода за период» = «Количество планируемых заказов» * «Средний чек заказа» — «Затраты на закупку товара» — «Затраты на рекламу» — «Налоговые и прочие издержки»

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

Упущенная выгода за месяц = 300 заказов * 3000 руб. — Закупка 450 000 руб. — Реклама 100 000 руб. — Зарплата менеджера магазина 50 000 руб. — Налог на прибыль 15% 45 000 руб. = 255 000 руб. Вот сумма, которую в этом месяце вы не заработали, хотя могли.

Иными словами, скорость выхода на рынок — ваша насущная необходимость.

Из чего состоит MVP маленького и среднего магазина

Мы уже выяснили, что чем быстрее начнем работать, тем быстрее начнем зарабатывать. Но как построить структуру магазина, чтобы она помогала зарабатывать, а не мешала?

Нам нужно определить некий стартовый набор функционала, достаточный для организации продаж и эффективного обслуживания клиентов. То есть MVP (Minimum Valuable Product) вашего интернет-магазина.

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

Еще один важный момент — какой магазин считать маленьким, а какой — средним?

В этой статье для удобства принято, что:

• маленький магазин — это точка, которую в состоянии полностью обслужить 1-2 человека. Обычно это до 15 заказов в сутки в зависимости от специфики. В маленьком магазине важно не упустить ни одного клиента, полная автоматизация процессов возможна, но малорентабельна;

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

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

И на нашем этапе запуска не лишним будет вспомнить, что главная цель магазина — это продавать.

Возможно, в вашем маленьком магазине и не будет поначалу всех удобств — однако он должен отвечать своей главной цели: продавать товар и не мешать владельцу получать за него оплату.

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

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

Например, нужна ли в маленьком магазине интеграция каталога с системой 1С?

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

Или, например, нужно ли заводить e-mail рассылку на вновь созданном маленьком магазине? Тоже, скорее всего, нет. Допустим, вы ее создали. Как будете собирать базу подписчиков, есть ли на это отдельный маркетинговый бюджет? Кто будет рассылать ваши рассылки, есть ли контент-менеджер? Если нет, успеет ли обычный менеджер магазина делать рассылки, есть ли у него компетенции? В то же время, клиенты, которые заказывают у вас товары, оставляют свои контактные данные. Можно оставить клиентам возможность указать при оформлении заказа, хотят ли они получать рассылки на будущее. База будет постепенно накапливаться.

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

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

Итого. Если сложить функционал таблицы, выделенный зеленым цветом и маркером «Да», мы получим MVP (Minimum Valuable Produсt) интернет-магазина. Функционал, минимально необходимый для организации продаж и корректного обслуживания клиентов.

Процесс запуска проекта

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

Так вот, если о принципах — то часто возникают следующие сложности:

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

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

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

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

• у вас есть определенный бюджет на разработку, в который нужно уложиться;

• есть набор модулей, который должен присутствовать на сайте — и этот набор тоже должен уложиться в бюджет. Методы реализации этих модулей обсуждаются с разработчиком;

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

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

Agile подразумевает, что вы «держите руку на пульсе» проекта. Планирование позволяет разбить проект на небольшие кусочки, которые можно принимать в процессе разработки по частям — например, отдельно карточку товара или отдельно новости. Можно объединять эти кусочки-задачи в более продолжительные спринты, но это не обязательно. Гораздо важнее, чтобы разработчики представляли вам готовый результат по каждой мелкой задаче не реже чем раз в три дня. Почему именно три? Более длительные сроки в случае ошибки выльются в более длительные исправления. Почему не один день? Мелочный контроль — тоже чересчур, хотя в случае срочной разработки можно «побить» задачи и по дням.

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

Как не превратить проект в долгострой

«Было гладко на бумаге, да забыли про овраги». В реальности разработчики проекта часто сами предлагают и процедуры, и график разработки, особенно если это веб-студия. Повлиять на эти процедуры крайне сложно. Так или иначе, проект может быть сдан по графику выбранной веб-студии, а может затянуться на веки вечные. Многое зависит и от вас.

Основная ошибка, которую часто допускают новички — это стремление сделать все идеально. Учесть все нюансы. Добиться, чтобы все «летало» и «масштабировалось». Подобный перфекционизм выливается примерно в следующую ситуацию.

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

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

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

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

В 90% случаев решение: «отложить на потом».

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

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

После старта магазина вы сможете провести аналитику: узнать, в какие разделы заходят пользователи чаще всего, удобно ли им пользоваться корзиной, сортировками и т.п. Можно организовать исследование потребительских нужд (Customer Development) — если вы не сделали этого на старте. Далее — вы примете организационное и финансовое решение поменять или дополнить какой-то функционал на сайте. Но при этом ваш неидеальный сайт уже будет работать и приносить вам доход.

Чем отличается техническое решение от организационного?

Сейчас мы подходим к торжественному моменту — определению разницы между техническими и организационными решениями. Но сначала экспресс-вопрос: что лучше — выбрать самую быструю систему управления сайтом (CMS) или самую популярную?

Техническое решение: самую быструю.

Организационное решение: самую популярную.

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

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

1. Какова стоимость лицензии на CMS и общая стоимость разработки?

2. Насколько сложно найти персонал на выбранную модель CMS?

3. Насколько дорого обслуживание?

4. Как скоро можно внедрить систему в эксплуатацию?

5. Какой функционал система включает в себя, много ли маркетинговых инструментов?

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

7. Отражает ли выбранная CMS нюансы законодательства РФ (системы складского учета, онлайн-кассы, платежные системы и т.п.)?

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

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

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

Сотрудники должны быть знакомы с системой или быть готовыми изучить ее в кратчайшие сроки. Если система незнакомая и новая — у вас появляются дополнительные затраты на внедрение и обучение.

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

На тендерной площадке Workspace ваш проект ждут более 4000 агентств. Создание интернет-магазина нужно доверять профессионалам.

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

Ведь наша первоочередная цель — продавать. Вся техническая инфраструктура — лишь способ облегчения этой деятельности.

А эта статья — лишь способ облегчения принятия ваших решений. Надеюсь, она была вам хотя бы немного полезной. Удачных вам продаж!

Автор: Елена Лебедева, директор по интернет-маркетингу Pilgrimstore.RU.