Автоматизация Интернет-магазина (минимум 1С)

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

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

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

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



Ну а что тут особенного?

Ну если нужно, можно сделать апдейт нескольких тысяч записей в базе и за пару секунд - современные СУБД, диски SAS, мощные процессоры, 48 Гбайт памяти... У нас, например, в одном проекте был каталог примерно из 800000 товаров, в которых импортировались предложения из сотен магазинов с привязкой, и номенклатура некоторых магазинов исчислялась десятками тысяч. Это был суровый импорт, но оно работало и в требования заказчика мы укладывались. Да, пришлось поставить неслабый выделенный сервер, а как иначе?

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

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

Поддерживаю.
Если торговая компания уже капитально вложилась в 1С, возможно, придется так и продолжать платить за ее доработку и интеграцию с витриной интернет-магазина.

Если же нет "отягощения" в виде 1С, лучше всего сразу заказывать интегрированное решение CRM или даже ERP, смотря что нужно.



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

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

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



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

Автор, подытожу. Решение ваших задач укладывается в сумму от 10 до 50 000 рублей. Если вам именно надо запустить магазин и зарабатывать, а не "внедрять, допиливать, согласовывать"

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

Автор обозначил свои требования в одном из постов. Среди них - интеграция с 1с кстати.
Допустим автор открывает SHOP2YOU ADVANCED.
Там у вас написано, что интеграция есть. Где хранятся картинки и описание товара? на сервере?
В таком случае, когда позвонит клиент, куда менеджер будет смотреть? одним глазом в каталог магазина, одним - в 1с?
Не спорю, у вас крутой продукт, но у него есть некоторые особенности архитектуры. Одно из них - контент хранится в одном месте, учет ведется в другом.

И куда кстати пропали крутые CRM-щики из ветки? я все таки хочу услышать их аргументы в вопросе "нужна ли CRM интернет магазину с 1000 наименований и одним менеджером". Хотя исчезли они наверно по той причине, что ответ - "не нужна" )))

Поясню насчет интеграции с 1С.

По сути все наши решения деляться на готовые (Lite, Classic), заказные (Advanced) и нестандартные проекты (Enterprise). Интеграция с 1С делается в проектах Advanced и Enterprise, если она нужна, но может быть добавлена и в Classic (смотря что понимать под интеграцией).

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

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

На выбор способа интеграции влияют исторически сложившиеся технологии.

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

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

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

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

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



Важнее задать другой вопрос: где хранится актуальная информация о товарах?

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

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

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



Обычно в более или менее серьезных магазинах работает далеко не один менеджер.

Когда мы говорим о наших решенниях со встроенными CRM и ERP, то возможен, например, такой вариант.

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

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

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



Вообще-то я нигде не описывал архитектуру наших решений

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

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

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

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

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

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

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

А с чем связанны особые требования к архитектуре, со сложными товарами или с неадекватностью заказчиков?

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

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

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

Также к архитектурным особенностям можно отнести балансировщики нагрузки и применение серверных кластеров для распределения нагрузки.

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

Понял. Спасибо.

Соглашусь с www.askkt.ru, что рассматривать SaaS решения не очень хочется.
Сам умею работать в 1С, и, по крайней мере, на первых порах не привлекать к работе бухгалтера, поэтому нужна интеграция и без лишних телодвижений.
На полностью готовое решение не надеюсь: но, учитываю, опыт работы с росбизнессофт - все может быть допилено под мои "неадекватные" фантазии.

Автор, раз вы умеете работать в 1с - вам нужно
1. Забить в нее номенклатуру (полуавтоматически)
2. Поменять названия в выгружаемой на сайт продукции, чтоб поисковики правильно искали ваш товар (возможно не понадобится)
3. Выгружать периодически на сайт номенклатуру.
4. Получать в 1с заказы с сайта.
Если вам такой расклад нравится - пишите.

Можно задам свой небольшой вопрос в этой теме?

Кто подскажет: хочется выгружать номенклатуру из 1С на сайт по расписанию, напр.1 или 2 р. в день. Но много заказов, которые находятся в статусе "отложен , но неоплачен", соотвественно в 1С они не проведены - не оформленая "реализация товаров". Естественно выгрузка целой категории будет некорректна. Как с этим бороться?

Извините, если немного не по теме)