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

1. Роль системы заказов на предприятии

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

2. Связь между системой заказов и различными бизнес-системами.

(1) Внешняя система:

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

(2) Средний и бэкэнд управления:

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

(3) Система государственной службы:

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

3. Восходящие и нисходящие отношения в системе заказов.

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

4. Бизнес-структура системы заказов

(1) Заказать услугу

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

(2) Логика порядка

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

(3) Базовые услуги

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

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

Основные функции системы заказов

1. Информация о содержимом, включенная в заказ

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

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

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

2. Механизм процесса

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

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

(1) Прямой процесс

В качестве примера возьмем систему заказов в обычном торговом центре B2C.,В соответствии с реальным бизнес-сценарием,Его процесс заказа можно абстрагировать как5большие шаги：Создание заказа>Оплата заказа>Заказать изготовление>Подтверждение заказа>Заказ выполнен。

То, как заказы взаимодействуют и перемещаются между несколькими системами на каждом этапе, можно резюмировать следующим образом:

Создание заказа:

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

Затем получите права членства учетной записи. Здесь следует отметить: разницу между привилегированной информацией и правами участника. Например: полная скидка на товары — это информация о скидках, а скидка 20 % для участников SUPER относится к правам участника. Один для товаров, а другой для аккаунта. Второе — это правила суперпозиции и правила приоритета преференциальной деятельности.

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

Уменьшите запасы при размещении заказа, то есть уменьшите количество запасов, когда пользователь успешно разместит заказ.

• Преимущества：Дружественный пользовательский опыт,система логична и лаконична;
• недостаток：Это приведет к размещению злонамеренных заказов или отказу от покупки после размещения заказа.,Предотвращение покупки пользователями, которым это действительно нужно.,Влиять на реальные продажи;

Решение:

1. Установить срок действия заказа,В случае успешного создания заказа оплата не будет производиться в течение N минут.,но Отмена заказ, откат инвентаря;
2. Лимит покупки: использование различных условий для ограничения количества предметов, которые могут приобрести покупатели, например, одна учетная запись и один IP, можно приобрести только один предмет;
3. Контроль рисков, если судить с технической точки зрения, блокировка вредоносных аккаунтов и запрет покупок с вредоносных аккаунтов.

Сокращение платежей и запасов — то есть количество запасов уменьшается после того, как пользователь завершает платеж и отправляет его на платформу.

• Преимущества：Уменьшите потери ресурсов, вызванные недействительными заказами；
• недостаток：Существует разница во времени в возвращаемых результатах из-за сторонней оплаты.,Несколько пользователей успешно оплатили одновременно,Приведет к тому, что количество заказа превысит запасы,Недостаточный инвентарь у торговцев может легко привести к дефициту товаров и жалобам.,Стоимость увеличивается.

Решение:

1. Проверьте инвентарь еще раз перед оплатой, проверьте еще раз при подтверждении заказа на оплату и дружелюбно подскажите пользователю, что инвентаря недостаточно;
2. Добавлена ​​подсказка: на странице сведений о продукте на странице этапа заказа отображается сообщение о том, что если оплата не будет произведена вовремя, наличие товара не может быть гарантировано и т. д.

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

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

Оплата заказа:

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

Обычно существует два типа разделения ордеров:

• Во-первых, продукты, выбранные пользователями, поступают из разных каналов (самостоятельные и торговцы, торговцы и торговцы);
• Другой способ — разделить заказ на уровне SKU: разные склады, SKU с разными требованиями к транспортировке, ограничениями по весу и объему упаковки и другими факторами необходимо разделить заказ.

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

Заказать изготовление：Заказать изготовление,Это относится к обзору процесса от продукта от предприятия до пользователя. Например, платформа электронной коммерции,Процесс доставки продавца стандартизирован.,Содержимое заказа будет отправлено на склад.,Складские заказы товаров、Сбор、Упаковка、Сдайте курьеру на доставку.

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

Заказ выполнен：Заказ Выполнено относится к статусу товара через X дней после получения,В настоящее время заказ находится за пределами периода послепродажной поддержки. До сих пор,Процесс обработки заказа завершен.

(2) Обратный процесс

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

Модификация заказа：Можно разобраться в информации внутри заказа,По степени корреляции информации и требованиям бизнеса,Каков диапазон изменения установленного порядка?,Например: после того, как клиент разместил заказ.,Я хочу изменить адрес и номер телефона грузополучателя. На данный момент вам нужно только обновить соответствующие данные.

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

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

вернуть товар：После успешной оплаты пользователем,Клиент выдалвернуть После обращения товара продавцу необходимо осуществить Возврат обзор денег, после того, как обе стороны достигнут соглашения, необходимо пополнить систему инвентаря, систему оплаты, систему продвижения на Возврат деньги заполнение одной формы деньги。наконец,существовать Возвращать деньги/вернуть В товарном процессе необходимо объединить бизнес-сценарии платформы и учесть логику преимущественного распределения при возникновении возврата. деньги/вернуть товар, правила оформления и процедуры возврата скидок.

(3) Государственный автомат

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

1. Текущий статус：относится к текущему состоянию。
2. действие：действие После выполнения,Возможен перенос в новое состояние,Вы также можете сохранить его в исходном состоянии.
3. вторичное состояние：действие Новое состояние, в которое можно перейти, когда оно удовлетворено,“вторичное состояние» относится к «Текущий статус”с точки зрения,“вторичное После активации «Состояние» трансформируется в новый «Текущий». статус”Понятно。

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

В качестве примера возьмем систему заказов торгового центра B2C:

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

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

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

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

Разработка системы заказов

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

Архитектура бизнес-системы выглядит следующим образом:

Возникновение этой ситуации приведет к очень большим узким местам в разработке платформы, таким как:

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

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

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

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

наконец

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

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

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

наконец

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

В конечном итоге они согласуются с общим развитием компании и дополняют друг друга.