В этой статье в основном описывается роль, которую должна выполнять система заказов на традиционных предприятиях электронной коммерции, разбираются дизайнерские идеи по основным функциональным модулям, включенным в систему заказов, и высказываются некоторые мысли о будущем развитии системы заказов.
1. Роль системы заказов на предприятии
Прежде чем строить систему заказов предприятия, необходимо разобраться в отношениях между общей бизнес-системой предприятия и восходящими и нисходящими отношениями системы заказов.Только путем расчистки границ бизнес-системы могут система порядка будет определена, тем самым обеспечив эффективную и четкую связь между системами.
2. Связь между системой заказов и различными бизнес-системами.
(1) Внешняя система:
На этом уровне находятся все системы, используемые внешними пользователями предприятия, включая официальный сайт, C-сторону, используемую обычными пользователями, а также мерчант-бэкенд, используемый мерчантами, и системы дистрибуции в различных каналах продаж, таких как сотрудничество с банком. центры кредитных карт, WeChat Coupeрation представляет продукты компании на платформе партнера. Такие системы стоят на переднем крае контакта с клиентами и являются плацдармом для реализации компаниями своих бизнес-моделей.
(2) управленческий средний и фон:
Каждая бизнес-форма C-стороны будет иметь соответствующий системный модуль, такой как система заказов, отвечающая за управление транзакциями платформы, система продвижения для управления информацией о скидках, система продуктов для управления всеми продуктами на платформе и система контента для управления всеми Контент отображения внешней системы.
(3) Система государственной службы:
С развитием предприятия, после того как информатизация достигнет определенного уровня, предприятию необходимо обслуживать и платформизировать общие функции, чтобы обеспечить рациональность архитектуры приложений и повысить эффективность обслуживания. Этот тип системы в основном обеспечивает базовую поддержку сервисных возможностей для других прикладных систем. Обратите внимание на общедоступный номер: Программист Бай Наннан, получите последнее руководство по вопросам собеседования по Java в 2020 году (более 200 страниц документов в формате PDF).
3. Отношения вверх и вниз в системе заказов
Можно видеть, что система заказов напрямую получает информацию о пользователях, преобразует информацию о пользователях в заказы на продукты и одновременно управляет и отслеживает информацию и данные о заказах, что является важным звеном для клиентов во всей линии транзакций компании. Во-вторых, он соединяет систему продуктов, систему продвижения, систему складирования, систему членства, платежную систему и т. Д. И играет роль в связывании всей платформы электронной коммерции.
4. Бизнес-структура системы заказов
(1) Заказать услугу
Основными функциями этого модуля являются службы и страницы, которые пользователи используют ежедневно, включая список заказов, детали заказа, онлайн-заказы и т. д. Он также включает многомерные службы данных заказов для общедоступных бизнес-модулей.
(2) Логика заказа
Ядро системы заказов играет жизненно важную роль.Система заказов отвечает за управление созданием заказов, оплатой заказа, изготовлением заказа, подтверждением заказа, завершением заказа, отменой заказа и другими процессами заказа. Он также включает в себя сложные правила статуса заказа, правила расчета суммы заказа и правила увеличения и уменьшения запасов. В разделе 4 дизайн основной функции будет сосредоточен на этом.
(3) Нижние службы
Предприятия, достигшие определенного уровня информатизации, обычно разбивают на модули общественные услуги компании, такие как продукты, и строят соответствующие продуктовые системы с относительно независимыми кодами, базами данных и интерфейсами. Однако и здесь возникает проблема: например, информация, которую необходимо получить в сценарии создания заказа, разбросана по разным системам.
Если его нужно вызывать из различных систем госуслуг: во-первых, это займет много времени, а во-вторых, стоимость обслуживания кода очень высока. Следовательно, система заказов подключается к требуемому интерфейсу модуля государственной службы, и услуга подключения к общественной системе может быть выполнена в системе заказов.
Основные функции системы заказов
1. Содержание информации, содержащейся в заказе
Чтобы система заказов могла эффективно и точно управлять заказами и отслеживать их, в заказе будет храниться ряд данных о заказах в режиме реального времени о продуктах, скидках, пользователях, платежной информации и т. д. для взаимодействия с нижестоящими системами, такими как реклама. , складирование и логистика.
Взяв в качестве примера заказ из обычного торгового центра B2C, он содержит следующую информацию:
Что нужно обратить внимание на вот тип заказа. С непрерывным развитием бизнеса платформы, после разнообразия категорий и методов транзакции, необходимо провести многомерное управление классификацией порядков, а также тип заказа способствует масштабируемости системы заказа. Каждый тип заказа будет соответствовать набору процессов и набора статусов, что удобно для управления классификацией и повторного использования заказов.
2. Механизм процесса
Процесс относится к абстрагированию всего потока заказов от создания до завершения с точки зрения платформы, таким образом формируя набор стандартных правил процесса. Различные типы продуктов или типы транзакций имеют разные процессы в системе, поэтому для облегчения управления процессом заказа будет установлен модуль механизма обработки.
Каждый процесс заказа будет включать в себя прямой процесс и обратный процесс.Прямой процесс можно сравнить с потоком информации между внутренними системами во время бесперебойной онлайн-покупки. Обратный процесс — это фоновый системный процесс, вызванный различными действиями, такими как модификация заказа, отмена заказа, возврат и возврат, при этом условия запуска каждого процесса можно разделить на два сценария: запуск системы и запуск вручную. Обратите внимание на общедоступный номер: Программист Бай Наннан, получите последнее руководство по вопросам собеседования по Java в 2020 году (более 200 страниц документов в формате PDF).
(1) Прямой процесс
Если взять в качестве примера систему заказов обычного торгового центра B2C, то в соответствии с его реальным бизнес-сценарием процесс заказа можно разделить на пять основных этапов: создание заказа > оплата заказа > изготовление заказа > подтверждение заказа > выполнение заказа.
За каждым этапом интерактивное распространение заказов между несколькими системами можно резюмировать следующим образом:
Заказать Создать:
После того, как пользователь размещает заказ, система должна сгенерировать заказ.В это время ей необходимо получить информацию о продукте, связанную с заказом, а затем получить предпочтительную информацию, связанную с продуктом.Если продукт не участвует в предпочтительная информация, эта ссылка не требуется.
Затем получите права членства учетной записи.Здесь следует отметить: разница между льготной информацией и правами членства, например: полная скидка - это льготная информация, скидка 9,2% для членов SUPER относится к правам членства, один для продукта, другой для счета. Во-вторых, правила суперпозиции и правила приоритета преференциальной деятельности.
Правило увеличения или уменьшения запасов относится к тому, когда товар в заказе будет вычтен из запасов соответствующего товара из системы хранения.В настоящее время существует два основных метода:
Заказ на сокращение запасов, то есть уменьшение количества запасов, когда пользователь успешно размещает заказ.
-
Преимущества: удобный пользовательский интерфейс, простая системная логика;
-
Недостатки: это приведет к злонамеренному размещению заказа или отказу от его покупки после размещения заказа, что сделает невозможным покупку для пользователей, которым это действительно нужно, что повлияет на реальные продажи;
Решение:
-
Установите время действия заказа, если заказ успешно создан и оплата не произведена в течение N минут, заказ будет отменен, а инвентарь будет откатан;
-
Лимит покупок, используйте различные условия для ограничения количества покупок покупателями, например, один аккаунт, один ip, можно купить только один;
-
Контроль рисков, оценка с технической точки зрения, блокировка вредоносных учетных записей и запрет на покупку вредоносных учетных записей.
Плата за уменьшение инвентаря — то есть после завершения оплаты пользователем и отправки отзыва на платформу количество инвентаря уменьшается.
-
Преимущества: снижение потребления ресурсов из-за недействительных заказов;
-
Недостатки: из-за разницы во времени в результатах возврата стороннего платежа успешная оплата нескольких пользователей одновременно приведет к тому, что количество размещенных заказов превысит инвентарь, а отсутствие инвентаря продавца легко приведет к -на складе и жалобы, и стоимость будет увеличиваться.
Решение:
-
Еще раз проверьте запасы перед оплатой, например, подтвердите, что заказ должен быть оплачен, и проверьте его еще раз, а также дружелюбно подскажите пользователю, что запасов недостаточно;
-
Добавлена подсказка: на странице сведений о продукте на странице шага заказа сообщается, что платеж несвоевременный, и наличие товара на складе не может быть гарантировано.
Подводя итог, можно сказать, что оба метода имеют свои преимущества и недостатки, поэтому их необходимо рассматривать в сочетании с реальными сценариями, такими как: всплески, распродажи, акции и т. д., а также способ размещения заказа на снижение можно использовать инвентарь. Для продуктов с большим товарным запасом и меньшим одновременным трафиком используется метод оплаты и сокращения запасов.
Внедрите эти два метода в сферу продаж, сопоставьте типы товаров, типы рекламных акций, отношения спроса и предложения и т. д. и гибко используйте их, чтобы в полной мере использовать преимущества компьютерных систем.
с:
После оплаты заказа пользователю необходимо получить информацию об оплате заказа, включая серийный номер платежа, время оплаты и т. д. После оплаты заказа наступает время ожидания доставки заказа продавцом, однако в процессе доставки, в зависимости от бизнес-модели платформы, может происходить дробление заказа.
Как правило, существует два типа разделения заказа:
-
Во-первых, продукты, выбранные пользователями, поступают из разных каналов (самообслуживаемых и продавцов, продавцов и продавцов);
-
Другой — разделить заказ на уровне SKU: такие факторы, как разные склады, SKU с разными требованиями к доставке, ограничения по весу и объему упаковки и т. д., должны разделить заказ.
Разделение ордеров также является относительно самостоятельным модулем, который здесь подробно описываться не будет.
Производство заказов: Производство заказов относится к обзору процесса производства продуктов от предприятий до пользователей. Например, в электронной коммерции процесс доставки продавца имеет стандартизированный процесс: содержимое заказа будет отправлено на склад, а склад будет заказывать, комплектовать, упаковывать и доставлять товары для доставки.
Подтверждение заказа: после получения товара система заказа должна напомнить пользователю оценить товар после подписания экспресс-доставки. Здесь следует отметить, что подтверждение получения товара не означает, что сделка прошла успешно, наоборот, это начало послепродажного обслуживания.
Завершение заказа: Завершение заказа относится к состоянию в течение X дней с момента получения товара, в это время заказ не находится в диапазоне времени послепродажной поддержки. На этом процесс продвижения заказа завершен.
(2) Обратный процесс
Как упоминалось выше, обратный процесс относится к различным операциям, таким как изменение заказа, отмена заказа, возврат и возврат.Необходимо разобраться в отношениях между этими процессами и прямым процессом, чтобы прояснить полный процесс заказа заказа. система.
Модификация заказа: вы можете отсортировать информацию в заказе и установить объем модификации заказа в соответствии со степенью корреляции информации и бизнес-требованиями.Например, после того, как клиент разместил заказ, он хочет изменить адрес и номер телефона грузополучателя. На этом этапе необходимо обновить только соответствующие данные.
Отмена заказа: пользователь не производит оплату после отправки заказа. В это время пользователь отменяет заказ в принципе. Поскольку платеж еще не был произведен, это относительно просто. Нужно только восполнить вычтенный инвентарь. когда заказ был первоначально отправлен, и скидка, использованная в рекламной скидке.Ваучеры, права и т. д. будут компенсированы соответственно в зависимости от правил платформы.
Возврат: после того, как пользователь успешно заплатит, после того, как клиент сделает запрос на возмещение, продавец должен проверить возмещение.После того, как две стороны достигнут соглашения, система должна завершить возмещение в форме заказа на возмещение, связывая исходные данные заказа. Поскольку изменения в товаре нет, то взаимодействие с системой инвентаризации рассматривать не нужно, а только взаимодействие с системой продвижения и платежной системой.
Возврат: после успешной оплаты пользователем, после того, как клиент отправил запрос на возврат, продавец должен провести проверку возврата.После того, как две стороны достигнут соглашения, необходимо пополнить систему инвентаря, а также платежную систему и акцию. система выполнит возврат в виде формы возврата. Наконец, в процессе возврата/возврата необходимо объединить бизнес-сценарии платформы, продумать логику распределения скидки, а также правила и процедуры обработки возврата скидки при возврате/возврате.
(3) Государственный автомат
Конечный автомат — это инструмент для управления логикой состояния заказа. Конечный автомат можно разделить на три элемента, а именно текущее состояние, действие и вторичное состояние.
-
Текущее состояние: относится к текущему состоянию.
-
Действие: после выполнения действия его можно переместить в новое состояние или оставить в исходном состоянии.
-
Подсостояние: новое состояние, в которое следует перейти после выполнения действия. «Подсостояние» относится к «текущему состоянию». После активации «подсостояния» оно преобразуется в новое «текущее состояние». состояние".
Дизайн конечного автомата должен сочетать реальные бизнес-сценарии платформы и усовершенствовать переключение между состояниями для выполнения определенного действия.
Торговый центр B2C для линейной системы, например, следующим образом:
Чтобы эффективно отслеживать заказы и управлять ими, система заказов абстрагирует статус заказа от ключевых узлов в процессе заказа. Статус заказа можно разделить на статус системного заказа, статус заказа продавца, статус заказа покупателя и т. д. с точки зрения разных пользователей.
Для системы заказов, чем мельче и четче детализация подразделения статусов заказов, тем выше точность и надежность управления системой заказов.Например: в двух состояниях ожидания платежа и ожидания доставки фон системы заказов будет Он делится на отмену тайм-аута заказа, отказ в оплате заказа, завершение оплаты заказа и т. Д.
Поэтому в модуле статуса заказа обычно поддерживается таблица сопоставления статусов, а статус системного заказа повторно делится на разные роли пользователей для удовлетворения потребностей разных пользователей.
Кроме того, с непрерывным развитием платформ электронной коммерции соответствующий статус заказа будет отличаться для разных типов бизнеса. Таким образом, несколько наборов конечных автоматов обычно хранятся в системе заказов, чтобы соответствовать использованию различных типов заказов.
Развитие системы заказов
Основная структура системы заказов и основные бизнес-модули в основном завершены.С развитием предприятия объем бизнеса и форма бизнеса постоянно меняются, и предприятие может формировать несколько систем заказов, сосуществующих для удовлетворения различных потребностей бизнеса.
Архитектура бизнес-системы выглядит следующим образом:
Возникновение этой ситуации создаст на платформе очень большое узкое место в разработке, например:
Три системы заказов, каждая система заказов обрабатывает разные типы заказов, нет унифицированных продаж заказов, информации о статусе заказа, стойка регистрации на веб-сайте не отображает и не контролирует статус заказа единообразно и может поддерживать только набор жестких кодов на веб-сайте. Центр участников стойки регистрации Единая информация о заказах и данные о статусе для участников. После того, как беспроводная сторона подключается к сети, поскольку она не понимает логику управления статусом заказа центра членства внешнего веб-сайта, необходимо реализовать детализацию заказа и управление статусом внешнего веб-сайта на стороне беспроводного приложения. опять таки.
Три набора серверных систем заказов и общедоступных бизнес-систем, таких как членский центр, платежи и финансы, инструменты продвижения, распределение заказов клиентов и другие системы, необходимо подключить один раз Логика обработки общедоступных бизнес-процессов не является унифицированной. , один и тот же интерфейс нескольких отделов должен быть подключен.Изменив его один раз, повторное обслуживание и развитие интерфейса тяжелы.
Разработка заказа пока возложена на бизнес-подразделения, каждое подразделение будет учитывать только свою логику, а не общественную структуру, и будет идти только дальше и дальше. Когда дело доходит до таких проектов, как беспроводная связь, необходимо связываться с различными бизнес-подразделениями, а развитие беспроводных приложений на стороне беспроводной связи идет медленно.
Таким образом, будущая система заказов может быть разделена на два модуля: центр заказов и система бизнес-заказов для управления всеми данными заказов компании и предоставления унифицированных услуг для каждого модуля.
наконец
Для построения системы заказов предприятия она не должна быть ни большой и полной, ни маленькой и точной. Необходимо объединить реальную ситуацию на рынке, в компании и в бизнесе, чтобы окончательно сформулировать план проектирования системы и план итерации продукта.
В итоге они согласуются с общим развитием компании и дополняют друг друга.
Обратите внимание на общедоступный номер: Программист Бай Наннан, получите последнее руководство по вопросам собеседования по Java в 2020 году (более 200 страниц документов в формате PDF).