Выбираю решение для магазина одежды

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

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

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

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

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

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

Как выбрать идеологию:


Итак что бывает:

1) Коммерческие готовые коробочные движки
Что в них хорошего:
Относительно низкая стоимость

Быстрый старт (можно запустить проект с минимальными затратами)

Как правило очень много настроек и возможностей по расширению.

Имеется куча хелпов и вменяемая поддержка


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


2) Коммерческие промышленные коробочные CMF
Самые известные - это bitrix и umi-cms
Что хорошего:

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

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

3) OpenSource CMF - бесплатные коробки, поддерживаемые сообществами.
Например - joomla, drupal, magento, zPublish и другие

Плюсы

Не нужно платить за лицензию
Как правило очень большая гибкость и высокие возможности
Огромное количество внедрений и протестированных модулей
Большое количество людей, которые поддерживают - то есть могут помочь с модификациями
Стоимость работы специалистов как правило не высока
Доступ к исходному коду

Минусы

Сложны в понимании, настройке, установки
Нет "рюшечек" - по умолчанию админки сложны в понимании и не красивы на вид (все конечно настраивается - но по умолчанию так)
Нестандартные решения потребуют проектирования и затрат на разработчиков
Поддержки в нормальном понимании нет
Документация и хел - фрагментарны и трудно доступны

4) Собственная разработка на базе "web framework ов разработчика"


Например Django (Python), Symphony (PHP), Zend

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

Минусы
Высокая цена разработки + существенные риски увеличения бюджета
Большие и трудно контролируемые сроки разработки
Необходимо уметь общаться с командой разработчиков
Необходимо провести вменяемое проектирование и потратить деньги на написание детальной документации и технических спецификаций
Риск преемственности кода при отсуттсвии нормального документирования
Требует более долгого тестирования


5) Saas- аренда магазинов умерла. Называть Software as a service арендой - неправильно. Saas - это очень сильное и очень модное направление на западе - начинает приживаться у нас - за ним будущее. На западе - ты платишь арендную плату за ядро - можно разместить на любом домене - можно делать все что хочешь - через Api внедрять и разрабатывать модули, интегрировать - работать с любыми независимыми разработчиками - то есть по сути это полноценное решение с высокой гибкостью и доступом к исходному коду. У нас пока это находится в зачаточном состоянии - поэтому и путают с арендой. Самый известный представитель - это Insales.ru -


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

Теперь как выбрать идеологию:


Если у Вас относительно типовой проект.
То есть:
Стандартный процесс заказа или с небольшими отступлениями
Нет сложных апселлов
Настраиваемых под конкретные сценарии апселлов и умных витрин
Не требуется нестандартной интеграции с внешними решениями

Плюс:

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

То Вам подойдет в 80% случаев решение номер 1 - при этом, Вы можете в зависимости от наличия денег - или привлечь специалиста для настройки и запуститься быстрее или даже разобраться самостоятельно или напрячь своих сотрудников

Однако - если у Вас при этом жесткое ограничение бюджета на старте и есть свободное время и желание вникать в процессы самому то можно выбрать open source CMF и долго копаться в ней самому. Либо подключить Saas. Saas не подойдет - если у Вас есть четкое видение серьезного мастшабного развится проекта - в этом случае скорее всего все таки нужно брать решения на уровне opensource

Если у Вас не типовой проект, то есть:

Есть особенности в оформлении заказа
Нестандартные решения по интеграции с внешними сервисами
Вменяемая политика по внедрению юзабилити
Сложная уникальная дисконтная система
Нестандартные апселлы и система витрин
и так далее

То скорее всего Вам нужно брать промышленную CMF и нанимать разработчиков

При этом если
У Вас есть запасы по бюджету и Вы готовы на риск ради того чтобы получить лучшее
Есть время
Есть опыт общения с разработчиками и управлением проекта
Есть четкое видение проекта
У Вас есть желание создать уникальные продукт
Вам важно иметь эту разработку в собственности (например для повышения цены компании)
Вы не можете жить чтобы не контролировать все и все

То выбирайте индивидуальную разработку на базе фрэймворка разработчика.

А если

Вы уверены в себе
Хотите сэкономить на старте но понимаете что нужно будет выкладываться после
Вам нравится философия opensource
Вы можете обойтись без "рюшечек"
Умеете работать гибко


То здесь будет opensource CMF и конечно команда разработчиков + ТЗ и проектирование.

Если у Вас уникальный и нестандартный проект, кишащий мега идеями и не похожий не на кого

То конечно Ваш путь лежит к frameworkу разработчика и опять же проектированию ТЗ и управлению проектами и большим рискам.

Возможен вариант и open source CMF - если хочется при этом еще и сэкономить, быстрее запустить и нам не так уж и важна уникальность разработки.

И разработка самого магазина - это малая часть в построении бизнеса. Не самая значительная.
Главное - это маркетинг. Как сделать так, чтобы покупали у Вас а не у конкурентов...

Создать модель продаж - самое ценное что есть. А продавать можно и до разработки магазина. Например есть такая схема запуска

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

Но после выбора идеологии нужно выбрать движок внутри. В первую очередь это делается сравнением возможностей движков "по умолчанию" с техническими требованиями. Затем считаем сколько нужно затратить денег на то что бы довести до требуемого состояния. Накладываем ограничения - типа затрат на поддержку, хостинг получаем 2-3 решения - их тестируем и вперед!

Начать с того что накладываем ограничения по нашей аудитории:

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

Ну а дальше с учетом этих требований пишем по модульно:



Оформление заказа
Требования по управлению внешним видом
Требования по интеграции Upsell
Каким образом дисконтная система участвует в оформлении заказа
Есть ли необходимость в использовании подароков
Требования к настройке модулей оплаты и доставки
Какие варианты сценариев предусмотрены
Возможности по настройке внешнего вида корзины
Возможности по использованию промо-кодов
Авторизация/регистрация в процессе и возможности по управлению
Интеграция процесса с внешними сервисами


Каталог товаров
Вложенность разделов и управление вложенностью.
Индивидуальные настройки сортировок
Возможность создавать виртуальные категории и параметры
Возможность по настройке отображения витрин в каталоге
Требования по автоматизации отображения витри
Возможность создания нестандартных категорий и фильтров
Управление блоками внешнего вида каталога (возможность создания шаблонов)
Настройка отображения товара в списке – требования к возможностям
Возможность различного отображения товара в списке для разных товарных
групп
Мультивалютность

Авторизация/регистрация
Возможность настройки полей и очередности форм
Возможность нестанадртных решений по авторизаци
Возможность создания уникальных сценариев под разные роли
Возможность интеграции с внешними сервисами и системами учета

SMM интеграция
Какие возможности необходимы для SMM?
Авторизация через twitter, facebook?
Комментирование, retweet, like it?

SMM на сайте
Новости, обновления – требования к возможности по настройке RSS
Профили пользователей – возможности и требования
Возможности по коммантированию
Рейтинги товаров, статей и проч.
Возможность личных страницы и интеграции с внешними сетями
(twitter, vkontakte)
Заметки и личные сообщения
Функционал работы с отзывами

Ценовая политика
Возможности по формированию группы наценок и правил.
Требования к возможностями по управлению наценками
Разные наценки для разных поставщиков и разных товарных групп
Интеграция с дисконтной программой
Возможности по отображению цен (ярлыки, перечеркивания)
Акции и распродажи: какие возможности необходимы?

Управление сайтом
Разграничение прав менеджеров
Удобство админки «по умолчанию»
Возможность разной настройки для разных менеджеров
Интеграция по требованию с внешними нестандартными решениями
Интеграция с 1С и другими сервисами (Erp, crm)
Требования к уровню персонала
Обучаемость
Скорость решения типовых задач

ERP, CRM, аналитика
Собственные ? Возможности интеграции с внешними

Требования к хостингу

Нагрузка
Количество операций
Безопасность
Цена
Бэкапаы
Требования к софту

Если по каждому пункту написать хотябы одно предложение - то получится минимальное ТЗ...
Если же писать ТЗ профессионально - то почитайте вот это

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



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

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



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

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

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

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

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



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

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

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

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

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

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

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

Большинству предпринимателей и торговых компаний будет затруднительно подготовить не то что техническое задание, но даже и запрос на функциональность интернет-магазина. Многие просят открыть магазин по принципу "сделайте нам как этот: http ://www....".

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

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

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

Так может рассуждать только владелец сервиса. Спасибо, cмешно
Быстрый - с трудом поверю. Мин. затрат - извольте.

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

То есть, указывайте уровень магазина, для кого данный сервис выгоден.

Смогу обосновать, хоть я владелец сервиса.

Во-первых, почему быстро.

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

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

Во-вторых, почему минимум затрат.

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

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

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

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

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

Но при этом надо иметь в виду:

- нужно будет потратить время и деньги на установку и начальную настройку скрипта;

- нужно заплатить за изготовление дизайна (см. мое замечение о стоимости дизайна выше);

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

- будут и другие траты (оплата хостинга, сопровождения, заботы о выполнении резервного копирования данных);

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

Т.е. конечно можно сделать дешевле, если только Ваше рабочее время ничего не стоит. Т.к. при таком подходе его придется потратить много.

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



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

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

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

Петр, спасибо!
Особенно ценно - описание структуры ТЗ. Обязательно воспользуюсь.

Вопрос по поводу CRM. Я до сих пор думал, что основные моменты CRM заложены в движке магазина. А если не так, если CRM - внешняя, то как клиенту могут отправляться уведомления о прохождении определенных стадий заказа? Они отправляются из внешней CRM? А есть встроенные простейшие CRM уже в движках?

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

При этом любое "взрослое решение" кроме "готовых коробочных" и примитивных saas позволяют интегрировать работу с внешней CRM через разные типы синхронизации.

Уже не раз видел например синхронизацию с HighRise и Mailchimp про 1С и говорить не надо.

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

У нас также есть встроенные CRM (решение Enterprise), которые автоматизируют всю деятельность некоторых наших клиентов, за исключением бухгалтерского учета. Бухгалтерский учет у них ведется в 1С, причем данные для такого учета экспортируются в 1С из нашего магазина.

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

Странная постановка задачи.. Может Вам к Вахтангу с саймейкерс? Он в многосайтовости спец)