WEBVTT

00:00:00.000 --> 00:00:04.080
Когда клиент нажимает «Купить» на вашем сайте, нужный ему товар может находиться на складе,

00:00:04.200 --> 00:00:08.540
в магазине на другом конце города или у службы доставки. Но на самом деле клиент ожидает всего

00:00:08.540 --> 00:00:12.560
две вещи – четкое обещание и посылку у своей двери. Добро пожаловать в новый выпуск

00:00:12.560 --> 00:00:17.540
Microsoft NoLedge на Getas на M365FM. Я Мо Питерс, и сегодня мы простыми словами поговорим

00:00:17.540 --> 00:00:21.860
об интеллектуальном управлении заказами в Dynamics 365. Мы проследим путь заказа от нажатия

00:00:21.860 --> 00:00:25.780
кнопки оплаты до его фактической доставки. Представьте себе это как центральный диспетчерский

00:00:25.780 --> 00:00:29.980
пункт в большом офисном здании. Это не еще один интернет-магазин, и он не упаковывает коробки.

00:00:30.000 --> 00:00:34.220
Он просто направляет нужных людей и системы, чтобы работа выполнялась там, где нужно.

00:00:34.780 --> 00:00:39.240
Почему с заказами возникает путаница? Представьте, что вы продаете одни и те же

00:00:39.240 --> 00:00:44.440
наушники через свой сайт, обычные магазины, онлайн-маркетплейс и колл-центр. Для клиента это

00:00:44.440 --> 00:00:49.280
просто разные способы купить наушники. Но за кулисами каждый канал отправляет данные о заказе в

00:00:49.280 --> 00:00:54.200
совершенно разные системы. На сайте создается одна запись, в кассовой системе магазина – другая,

00:00:54.360 --> 00:00:58.500
маркетплейс использует свой формат, а оператор колл-центра создает заказ еще где-то.

00:00:58.500 --> 00:01:02.200
Одно простое обещание клиенту превращается в несколько разрозненных частей, которые не

00:01:02.200 --> 00:01:05.720
взаимодействуют друг с другом. А наличие запасов добавляет еще один уровень сложности.

00:01:05.880 --> 00:01:10.360
На главном складе может быть 20 пар. В магазине на другом конце города – 5, и на другом складе

00:01:10.360 --> 00:01:14.400
тоже есть запас. Но он находится дальше, и доставка обойдется дороже. Часть товара уже

00:01:14.400 --> 00:01:19.260
зарезервирована под другие заказы, возвраты или покупателей в магазине. Поэтому цифра рядом с товаром

00:01:19.260 --> 00:01:23.900
еще не решает проблему. Затем нужно решить, как осуществлять доставку. Должен ли отправлять склад,

00:01:24.120 --> 00:01:28.140
должен ли отправлять магазин. Или клиент может забрать товар самостоятельно. А если кто-то покупает

00:01:28.140 --> 00:01:31.260
два товара, и ни в одном месте нет обоих сразу, стоит ли разбивать заказ на две посылки или

00:01:31.260 --> 00:01:35.020
подождать, пока все можно будет отправить вместе. Каждый выбор влияет на стоимость, время доставки

00:01:35.020 --> 00:01:38.980
и обещания, которые вы дали клиенту. Два десятилетия назад компании выполняли эти задачи в разных

00:01:38.980 --> 00:01:42.980
системах и разными командами. Отдел продаж принимал заказ. Кто-то проверял наличие на складе.

00:01:43.120 --> 00:01:47.220
Склад получал запрос. Партнер по доставке получал свой запрос. Отдел расчетов занимался своей

00:01:47.220 --> 00:01:50.660
частью позже. Это отлично работало, когда заказы были простыми, а объемы – небольшими.

00:01:50.760 --> 00:01:54.400
Но вот в чем загвоздка. Когда обновления между системами проходят медленно, людям приходится

00:01:54.400 --> 00:01:58.200
заполнять эти пробелы вручную. Оператор поддержки проверяет один экран, пишет письмо на склад,

00:01:58.380 --> 00:02:01.780
затем звонит перевозчику, а тем временем товар может быть продан через другой канал до того,

00:02:01.940 --> 00:02:05.700
как информация об остатках обновится на сайте. Теперь у вас есть заказ на то, что вы не можете

00:02:05.700 --> 00:02:09.740
отправить. Так и возникают излишки продаж. И именно поэтому выбор доставки занимает так много

00:02:09.740 --> 00:02:13.820
времени. Команды постоянно копируют данные из одного места в другое, а клиенты получают расплывчатые

00:02:13.820 --> 00:02:18.520
ответы вместо конкретных. С точки зрения клиента, вся эта сложность не имеет значения, ведь он задает

00:02:18.520 --> 00:02:23.440
лишь один вопрос. Где мой заказ? Компании нужно единое место, где можно видеть путь заказа во всех

00:02:23.440 --> 00:02:27.640
бизнес-приложениях, позволяя каждому из них делать то, что оно умеет лучше всего. Отдел

00:02:27.640 --> 00:02:32.100
продаж фиксирует продажу. Склад управляет комплектацией и упаковкой. Отдел доставки занимается

00:02:32.100 --> 00:02:36.420
отправкой. Биллинг отвечает за деньги. Никому не нужно выбрасывать все свои системы. Не хватает

00:02:36.420 --> 00:02:41.700
лишь координатора между ними. Ой, место, которое может принять заказ, понять, что делать дальше,

00:02:41.960 --> 00:02:48.640
и направить работу без цепочки ручных передач. В этом-то и проблема. Dynamics 365 Intelligent Order Management

00:02:48.640 --> 00:02:55.120
решает ее, говоря простым языком. Итак, что же такое Dynamics 365 Intelligent Order Management?

00:02:55.420 --> 00:03:01.560
Привет! Сегодня мы разберем это простыми словами. Вот самое простое определение. Это облачное

00:03:01.560 --> 00:03:07.580
приложение, которое принимает заказ и проводит его через все системы компании с момента поступления

00:03:07.580 --> 00:03:12.700
до выполнения и оплаты. Представьте оживленный железнодорожный вокзал. Поезда прибывают с разных

00:03:12.700 --> 00:03:17.560
направлений. Пассажирам нужны разные платформы. Некоторые пересадки быстрые, другие требуют ожидания.

00:03:17.560 --> 00:03:22.320
Intelligent Order Management работает как диспетчерская вокзала. Она не ведет поезд и не продает билеты,

00:03:22.560 --> 00:03:26.440
но видит весь маршрут и говорит каждой системе, что делать дальше. Microsoft создала

00:03:26.440 --> 00:03:31.060
Intelligent Order Management на базе Dataverse. Dataverse — это общая платформа данных для многих

00:03:31.060 --> 00:03:36.660
приложений Dynamics 365 и Power Platform. Проще говоря, она предоставляет бизнес-приложениям

00:03:36.660 --> 00:03:41.540
общее место и формат для хранения информации. Это значит, что заказ не будет иметь разный смысл в

00:03:41.540 --> 00:03:45.820
каждой системе или на каждом экране. Эта общая платформа помогает, но вам не нужно покупать все остальные

00:03:45.820 --> 00:03:49.760
приложения Dynamics 365, чтобы использовать Intelligent Order Management. Компания может

00:03:49.760 --> 00:03:54.940
использовать Dynamics 365 Finance или Supply Chain Management. Другая может использовать свою складскую

00:03:54.940 --> 00:03:59.280
систему, интернет-магазин или службу доставки от стороннего поставщика. Это приложение работает

00:03:59.280 --> 00:04:03.500
как с продуктами Microsoft, так и со сторонними бизнес-приложениями. Точки подключения называются

00:04:03.500 --> 00:04:08.040
провайдерами. Провайдер передает информацию о заказах и их выполнении между Intelligent Order Management

00:04:08.040 --> 00:04:12.480
и другой системой. Представьте провайдера как переводчика на входе. Система отправляет заказ в

00:04:12.480 --> 00:04:16.880
своем собственном формате. Провайдер распознает этот формат, передает данные в Intelligent Order

00:04:16.880 --> 00:04:21.900
Management и отправляет следующий запрос в формате, понятном другой системе. Итак, приложение собирает

00:04:21.900 --> 00:04:26.120
информацию о заказах воедино, даже если они поступили из разных источников. Клиент может совершить

00:04:26.120 --> 00:04:31.500
покупку на сайте AIO. Другой может оформить заказ через систему торговых точек. Бизнес-клиент может

00:04:31.500 --> 00:04:36.200
отправить электронный заказ через B2B процесс. Интеллектуальное управление заказами дает компании

00:04:36.200 --> 00:04:41.220
единое место для просмотра заказов и отслеживания стадии их выполнения. Не каждый заказ следует по одному и тому же

00:04:41.220 --> 00:04:45.320
пути. Один может ожидать поступления товара на склад. Другой может уже находиться на складе. Третий

00:04:45.320 --> 00:04:49.320
может потребовать выставления счета после доставки. Приложение отслеживает состояние, чтобы команда

00:04:49.320 --> 00:04:53.380
видела больше, чем просто статус «заказ получен». Они могут в точности видеть, на каком этапе пути

00:04:53.380 --> 00:04:58.380
находится заказ. Вот часть, которую люди иногда упускают. Интеллектуальное управление заказами не берет

00:04:58.380 --> 00:05:03.180
на себя всю работу. Оно не становится внезапно экраном комплектовщика, сетью доставки перевозчика или

00:05:03.180 --> 00:05:07.860
биллинговой системой финансового отдела. Эти подключенные приложения по-прежнему выполняют свою специализированную

00:05:07.860 --> 00:05:11.200
работу. Интеллектуальное управление заказами руководит передачей задач между ними.

00:05:11.220 --> 00:05:16.140
Оно получает запрос, проверяет маршрут, передает работу дальше, а затем ожидает следующие обновления.

00:05:16.340 --> 00:05:20.820
А теперь давайте проследим за одним заказом на этом пути, ведь путь заказа позволяет гораздо лучше

00:05:20.820 --> 00:05:27.060
понять всю концепцию. Правила пути заказа, которые направляют работу. Представьте, что клиент заказывает

00:05:27.060 --> 00:05:32.780
два товара на вашем сайте поздно вечером и хочет получить их завтра. Интернет-магазин фиксирует заказ,

00:05:33.040 --> 00:05:38.440
имя клиента, адрес доставки, две позиции заказа и выбор доставки. Провайдер передает этот заказ в

00:05:38.440 --> 00:05:42.760
интеллектуальную систему управления, и путь заказа может начаться. Прежде чем кто-либо попытается

00:05:42.760 --> 00:05:47.180
его выполнить, система проверяет заказ, чтобы убедиться, что вся необходимая информация на месте и

00:05:47.180 --> 00:05:51.140
соответствует правилам компании. Она проверяет заголовок заказа на наличие деталей о клиенте и

00:05:51.140 --> 00:05:54.860
доставке. Она проверяет каждую позицию на наличие товара и количество. Она подтверждает,

00:05:55.040 --> 00:05:58.440
что адрес содержит достаточной информации для доставки, и проверяет, соответствует ли заказ

00:05:58.440 --> 00:06:02.720
правилам канала продаж. Эта первая проверка предотвращает передачу некорректных данных дальше по цепочке,

00:06:02.720 --> 00:06:07.820
пока они не вызвали проблем. Представьте заказ, в котором пропущен номер квартиры. Если он сразу попадет на склад,

00:06:08.440 --> 00:06:11.940
перевозчику, проблему могут заметить только тогда, когда посылку не удастся доставить.

00:06:12.100 --> 00:06:16.800
Этап проверки выявляет проблему раньше, пока еще есть время связаться с клиентом или приостановить

00:06:16.800 --> 00:06:21.460
заказ. Основа этой работы заключается в потоке оркестрации. Эта фраза звучит технически,

00:06:21.680 --> 00:06:26.060
но все просто. Поток оркестрации – это визуальная карта, которая говорит системе управления заказами,

00:06:26.240 --> 00:06:29.980
что должно происходить по мере поступления информации о заказах и событий из подключенных систем.

00:06:29.980 --> 00:06:34.000
Вы создаете эту карту вокруг своих собственных бизнес-процессов. Базовый поток заказа может

00:06:34.000 --> 00:06:38.100
начинаться с поступления нового заказа. Он проверяет заголовок и строки. Он отправляет заказ

00:06:38.100 --> 00:06:41.840
для принятия решений по выполнению. После этого он направляет заказ на выполнение в соответствующую

00:06:41.840 --> 00:06:45.280
подключенную систему. Когда работа доходит до нужного этапа, он может передать сведения о заказе

00:06:45.280 --> 00:06:48.300
поставщику услуг выставления счетов. У каждого действия есть четкая задача.

00:06:48.400 --> 00:06:52.900
Проверка заголовка заказа изучает основные детали заказа. Проверка строки заказа анализирует

00:06:52.900 --> 00:06:57.000
отдельные товары и их количество. Отправка на выполнение передает заказ поставщику,

00:06:57.000 --> 00:07:01.900
который занимается этой работой. Отправка на оплату передает информацию о заказе биллинговой системе.

00:07:02.040 --> 00:07:06.980
Эти названия звучат как надписи на панели управления заводом, и это удобно, так как каждая метка точно указывает,

00:07:06.980 --> 00:07:11.620
что происходит в этой точке процесса. Но реальному бизнесу часто недостаточно одной прямой линии.

00:07:11.800 --> 00:07:15.880
Возможно, заказы с веб-сайта идут по одному пути, а заказы бизнес-клиентов – по другому.

00:07:16.040 --> 00:07:19.800
Возможно, для одного типа товара требуется особое одобрение. Возможно, заказ может продвигаться

00:07:19.800 --> 00:07:23.460
дальше, только если первый шаг прошел успешно. Интеллектуальное управление заказами включает

00:07:23.460 --> 00:07:28.120
условия для такого выбора. Условие создает путь «да» и путь «нет». Если предыдущее действие

00:07:28.120 --> 00:07:31.860
выполнено успешно, заказ может продолжить путь по ветке «да». Если оно не удалось,

00:07:32.060 --> 00:07:35.740
поток может направить заказ по другому пути. Это не решает все проблемы само по себе,

00:07:35.740 --> 00:07:39.760
но дает процессу запланированный ответ вместо того, чтобы оставлять команду обнаруживать

00:07:39.760 --> 00:07:44.100
ошибку случайно. Существуют также разветвители. Разветвитель направляет поток по нескольким

00:07:44.100 --> 00:07:47.880
путям на основе определенных вами правил. Вы можете использовать его, когда заказы из разных

00:07:47.880 --> 00:07:51.480
источников требуют разных проверок или когда разные части работы требуют разных маршрутов.

00:07:51.660 --> 00:07:55.180
Некоторые разветвленные пути могут позже снова сойтись, а другие продолжаются независимо.

00:07:55.320 --> 00:07:58.760
Пользовательские действия охватывают задачи, уникальные для конкретного бизнеса. Возможно,

00:07:58.920 --> 00:08:01.880
у компании есть собственная производственная система или партнерская система,

00:08:02.040 --> 00:08:05.220
не охваченная стандартным действием. Пользовательское действие может подключить этот этап

00:08:05.220 --> 00:08:08.960
к потоку заказа, чтобы маршрут отражал полный процесс, а не скрывал часть работы в письмах или

00:08:08.960 --> 00:08:13.780
ручных операциях. Вернемся к нашему заказу из двух позиций. Система получает его с сайта и проверяет

00:08:13.780 --> 00:08:18.300
данные клиента, адрес и товарные позиции. Затем заказ доходит до этапа принятия решения о

00:08:18.300 --> 00:08:22.620
выполнении. Если обе позиции могут следовать одним маршрутом, поток может отправить запрос на

00:08:22.620 --> 00:08:27.180
выполнение как единое целое. Если правила компании требуют иного результата, заказ может пойти

00:08:27.180 --> 00:08:31.000
другим путем. Может быть, на две позиции нужны отдельные запросы на выполнение, может быть,

00:08:31.000 --> 00:08:35.480
для заказа нужен другой вариант доставки. Поток не гадает, он следует правилам, созданным бизнесом

00:08:35.480 --> 00:08:40.080
и событиям, которые возвращают подключенные системы. Эта последняя часть важна. Интеллектуальное

00:08:40.080 --> 00:08:43.780
управление заказами направляет работу, но подключенные системы отчитываются по мере

00:08:43.780 --> 00:08:48.580
продвижения дел. Провайдер фулфилмента может получить запрос. Беллинговая система может получить

00:08:48.580 --> 00:08:53.480
детали заказа. Эти события продвигают заказ по всему маршруту. Таким образом, приложение не является

00:08:53.480 --> 00:08:57.760
одной гигантской системой для полной замены. Это набор правил, связывающих специалистов и передающих

00:08:57.760 --> 00:09:01.660
каждой системе нужную работу в нужное время. Интернет-магазин фиксирует заказ. Система

00:09:01.660 --> 00:09:05.340
фулфилмента берет на себя выполнение заказа. Беллинговая система берет на себя оплату.

00:09:05.520 --> 00:09:08.480
Интеллектуальное управление заказами выстраивает маршрут между этими задачами.

00:09:08.640 --> 00:09:12.540
Ответственные за процесс заказа сотрудники могут создавать такие цепочки прямо в приложении.

00:09:12.740 --> 00:09:16.900
Им не нужно прописывать каждый путь традиционным кодом, и не нужно обращаться к ИТ-администратору

00:09:16.900 --> 00:09:20.320
для изменения каждого бизнес-правила. Это дает команде по цепочкам поставок возможность

00:09:20.320 --> 00:09:24.340
моделировать именно те процессы, которые им нужны. Тем не менее, такие изменения требуют осторожности.

00:09:24.340 --> 00:09:28.660
Цепочка оркестрации остается неопубликованной, пока вы ее создаете и тестируете. На этом этапе

00:09:28.660 --> 00:09:33.260
входящие данные не проходят через цепочку. После публикации цепочка и ее действия запускаются

00:09:33.260 --> 00:09:36.960
при поступлении данных в систему. После публикации вы не можете напрямую редактировать

00:09:36.960 --> 00:09:40.780
опубликованную цепочку. Если бизнесу нужны изменения, команда может остановить опубликованную

00:09:40.780 --> 00:09:44.320
цепочку, что вернет ее в неопубликованное состояние. Они могут отредактировать цепочку и

00:09:44.320 --> 00:09:48.120
опубликовать новую версию, когда она будет готова. Такой подход побуждает команды тестировать маршрут,

00:09:48.300 --> 00:09:51.780
прежде чем через него пойдут реальные заказы. Маршрут работает только тогда, когда он знает,

00:09:51.780 --> 00:09:55.540
какие запасы реально доступны. Это подводит нас к актуальной информации об инвентаризации,

00:09:55.740 --> 00:09:59.760
лежащей в основе каждого решения по фулфилменту. Видимость запасов – это понимание того,

00:10:00.000 --> 00:10:03.940
что вы действительно можете продать. Простая истина. Вы не можете выполнить заказ,

00:10:04.140 --> 00:10:08.580
если не знаете, что товар есть в наличии. Звучит очевидно, но запасы могут прятаться на складе,

00:10:08.700 --> 00:10:12.020
в магазине, у партнера или в разных юридических лицах внутри одной компании.

00:10:12.200 --> 00:10:15.580
Когда каждое подразделение ведет свой учет, вы не можете ответить на базовый вопрос,

00:10:15.840 --> 00:10:19.220
что я могу обещать клиенту прямо сейчас. Видимость запасов дает интеллектуальному

00:10:19.220 --> 00:10:23.140
управлению заказами актуальный обзор всех остатков вашей сети поставок. Представьте это как

00:10:23.140 --> 00:10:27.020
информационное табло в распределительном центре. Вместо того, чтобы звонить на каждый склад и просить

00:10:27.020 --> 00:10:30.500
кого-то проверить наличие, процесс обработки заказа смотрит на один общий обзор, куда стекаются

00:10:30.500 --> 00:10:34.940
данные из всех систем. Но даже если товар где-то числится, это не значит, что он может выполнить

00:10:34.940 --> 00:10:39.360
любой заказ. Товар может лежать на складе, но быть уже зарезервированным, или находиться в магазине,

00:10:39.460 --> 00:10:43.620
который торгует только локально, или же просто быть слишком далеко, чтобы соблюсти выбранный клиентом

00:10:43.620 --> 00:10:48.080
срок доставки. Есть большая разница между товаром, который где-то существует, и товаром, который может

00:10:48.080 --> 00:10:52.380
выполнить этот заказ прямо сейчас. Представьте, что клиент купил куртку онлайн и хочет получить

00:10:52.380 --> 00:10:57.140
ее завтра. На вашем главном складе их не осталось. Без актуальных данных о запасах сайт может

00:10:57.140 --> 00:11:02.040
принять заказ на основе устаревших цифр, и склад получит запрос на то, чего не может отправить,

00:11:02.240 --> 00:11:07.120
а клиент узнает об этом только после оплаты. Это создает лишнюю работу для всех. Благодаря связанной

00:11:07.120 --> 00:11:11.140
информации об остатках, интеллектуальная система управления заказами видит, что на главном складе

00:11:11.140 --> 00:11:15.820
куртки нет, зато она есть в ближайшем магазине. Если этот магазин поддерживает доставку, он может выполнить

00:11:15.820 --> 00:11:20.540
заказ. Если клиент выбрал самовывоз, этот же магазин станет точкой выдачи. Решение начинается

00:11:20.540 --> 00:11:24.980
с лучшего обзора товарных запасов. Для компании с несколькими юридическими лицами этот обзор

00:11:24.980 --> 00:11:29.160
охватывает все их запасы. Это важно, когда вы работаете в нескольких странах, регионах или

00:11:29.160 --> 00:11:33.300
бизнес-единицах, а данные об остатках хранятся не в одной системе. Процесс обработки заказа

00:11:33.300 --> 00:11:38.240
использует данные об остатках в реальном времени, определяя дальнейший путь. Склад, магазин или другой

00:11:38.240 --> 00:11:42.840
источник запасов по-прежнему ведет собственный учет. Прозрачность запасов объединяет текущие

00:11:42.840 --> 00:11:47.440
показатели в единый процесс заказа, где правила исполнения могут их использовать. Это помогает

00:11:47.440 --> 00:11:51.680
не давать обещаний, основанных на вчерашних данных, и дает службе поддержки четкий ответ,

00:11:51.820 --> 00:11:55.800
когда кто-то спрашивает, успеет ли товар вовремя. Вместо того, чтобы искать информацию в разных

00:11:55.800 --> 00:12:00.100
системах в надежде на их совпадение, команда видит статус остатков, повлиявший на выбор способа

00:12:00.100 --> 00:12:05.580
доставки. Конечно, видеть все возможные точки отправки – это еще не все. Вы можете обнаружить товар в пяти

00:12:05.580 --> 00:12:10.540
разных местах. Одно ближе всего к клиенту, другое имеет больше запасов, третье позволяет отправить

00:12:10.540 --> 00:12:15.380
оба товара вместе. Кто-то или что-то все равно должно сделать выбор. Эта задача ложится на плечи

00:12:15.380 --> 00:12:23.260
оптимизации исполнения заказов. Исполнение. Оптимизация. Выбор лучшего места для отправки

00:12:23.260 --> 00:12:29.300
заказа. Оптимизация сравнивает возможные места для заказа и выбирает одно на основе правил вашей

00:12:29.300 --> 00:12:34.520
компании. Проще говоря, она отвечает на вопрос, откуда должен прийти этот заказ. Лучший не всегда

00:12:34.520 --> 00:12:39.160
означает ближайший. Товар может быть в ближайшем магазине, но отправка оттуда может стоить дороже.

00:12:39.160 --> 00:12:43.520
На более удаленном складе оба товара могут быть уже готовы к упаковке, а в другом месте товар есть,

00:12:43.720 --> 00:12:47.380
но сроки доставки не соответствуют ожиданиям клиента. Каждая компания должна решить,

00:12:47.560 --> 00:12:51.460
чему отдавать приоритет в правилах. Некоторые бизнесы ставят на первое место скорость доставки.

00:12:51.640 --> 00:12:55.740
Другие стремятся снизить затраты на логистику. Компания также может захотеть сохранить запасы

00:12:55.740 --> 00:12:59.440
магазина для розничных покупателей или избежать дробления заказа на несколько посылок,

00:12:59.520 --> 00:13:03.540
если есть другой вариант. Интеллектуальное управление заказами использует стратегии исполнения,

00:13:03.720 --> 00:13:08.020
отражающие этот выбор. Это похоже на выбор маршрута для курьерского фургона. Самый короткий

00:13:08.020 --> 00:13:12.200
путь не всегда самый быстрый, ведь могут быть пробки, дорожные работы или задержки в пути.

00:13:12.340 --> 00:13:17.240
Также и ближайший склад не всегда обеспечивает лучший результат, если учитывать стоимость товара,

00:13:17.440 --> 00:13:22.220
обязательства по срокам и варианты доставки. Вернемся к покупателю, который заказал два товара

00:13:22.220 --> 00:13:27.720
онлайн. В магазине в 10 минутах езды есть первый товар. На складе есть оба товара, но он находится

00:13:27.720 --> 00:13:32.740
дальше. Если отправить первый товар из магазина, а второй со склада, покупатель может получить

00:13:32.740 --> 00:13:37.780
две посылки вовремя, но это увеличит затраты на доставку. Возможно, склад сможет отправить оба

00:13:37.780 --> 00:13:41.740
товара одной посылкой. Если это позволит уложиться в обещанный срок, отправка одной посылки с

00:13:41.740 --> 00:13:44.820
этого склада может стать лучшим решением. Правила могут быть настроены на сокращение

00:13:44.820 --> 00:13:48.260
количества отправлений и снижение стоимости доставки. Но если доставка завтра важнее,

00:13:48.420 --> 00:13:52.260
чем получение всех товаров вместе, система может выбрать магазин для одного товара и склад для

00:13:52.260 --> 00:13:56.460
другого, это и есть разделение заказа. Разделение заказа не означает сбой в работе системы.

00:13:56.560 --> 00:14:00.240
Это может быть запланированным выбором, когда ни одна точка не может выполнить весь заказ целиком

00:14:00.240 --> 00:14:04.960
нужным образом. Бизнес решает, когда разделение оправдано, через свою стратегию выполнения заказов.

00:14:04.960 --> 00:14:09.180
Тот же подход лежит в основе покупки онлайн с доставкой из магазина. Клиент оформляет заказ на

00:14:09.180 --> 00:14:13.260
сайте, но у ближайшего магазина есть нужный товар, и он может быстро его отправить. Тогда этот

00:14:13.260 --> 00:14:17.760
магазин становится точкой отгрузки, даже если клиент там никогда не был. Это также поддерживает

00:14:17.760 --> 00:14:22.700
покупку онлайн с самовывозом из магазина. Система использует данные о наличии и местоположении,

00:14:22.960 --> 00:14:28.520
чтобы найти магазин для самовывоза, предоставляя клиенту удобный вариант получения, а компании – возможность

00:14:28.520 --> 00:14:34.280
направить заказ в нужное место. Этим решением не обязательно быть разрозненными для каждого канала продаж.

00:14:34.280 --> 00:14:38.960
Без единого процесса принятия решений сайту, маркетплейсу и колл-центру может потребоваться

00:14:38.960 --> 00:14:43.280
настройка собственных правил маршрутизации. При изменении политики доставки или начале

00:14:43.280 --> 00:14:47.220
использования магазинов для отгрузки командам придется обновлять сразу несколько систем.

00:14:47.420 --> 00:14:51.520
Оптимизация выполнения заказов объединяет этот процесс в одном месте на всем пути заказа.

00:14:51.660 --> 00:14:56.100
Сайт продолжает принимать заказы, маркетплейс продолжает принимать заказы, а магазин продолжает

00:14:56.100 --> 00:15:01.360
продавать товары. Но компания может менять логику выбора точки отгрузки без перенастройки правил в каждом

00:15:01.360 --> 00:15:06.640
канале, получая больше контроля при перемещении истоков, смене сроков доставки или появлении новых

00:15:06.640 --> 00:15:11.220
опций. Тем не менее, стратегия выполнения заказов может сравнивать площадки только при наличии

00:15:11.220 --> 00:15:15.680
актуальных данных из соответствующих систем. Заказы должны поступать, данные об остатках должны

00:15:15.680 --> 00:15:19.900
обновляться, а партнеры по доставке должны получать задачи и сообщать о статусе их выполнения.

00:15:20.080 --> 00:15:22.540
Эта работа по подключению зависит от провайдеров.

00:15:23.220 --> 00:15:28.120
Провайдеры и соединения – это двери в здание. Чтобы интеллектуальное управление заказами выполняло

00:15:28.120 --> 00:15:32.240
свою работу, ему нужен надежный способ связи со всем окружением. Именно провайдеры делают

00:15:32.240 --> 00:15:35.940
это возможным. Провайдер – это, по сути, соединение, которое передает сведения о заказах и

00:15:35.940 --> 00:15:38.860
обновлениях выполнения между системой интеллектуального управления заказами и другими

00:15:38.860 --> 00:15:42.580
системами. Информация передается в обоих направлениях, поэтому никому не нужно копировать что-либо

00:15:42.580 --> 00:15:46.620
вручную. Представьте себе здание с множеством дверей для доставки. Одна дверь получает заказы

00:15:46.620 --> 00:15:50.980
из вашего интернет-магазина, другая соединяется с вашей системой учета запасов. Третья отправляет

00:15:50.980 --> 00:15:55.420
задание на склад или партнеру по доставке. У каждой двери есть четкая цель, а провайдеры управляют

00:15:55.420 --> 00:15:59.400
информацией, проходящей через каждую из них. Майкрософт создает некоторые из этих коннекторов

00:15:59.400 --> 00:16:03.180
самостоятельно. Они называют их собственными провайдерами – first-party providers. Они соединяют

00:16:03.180 --> 00:16:07.100
интеллектуальное управление заказами с такими приложениями, как Dynamics 365 Supply Chain Management,

00:16:07.240 --> 00:16:12.360
Dynamics 365 Commerce или Dynamics 365 Finance. Службы учета запасов и выполнения заказов внутри

00:16:12.360 --> 00:16:15.880
интеллектуального управления также используют этих провайдеров для обмена данными. Конечно,

00:16:16.120 --> 00:16:20.060
у вас наверняка уже есть другие системы. Вот здесь на помощь приходят сторонние провайдеры. Они

00:16:20.060 --> 00:16:23.420
соединяют сервисы, которые Майкрософт не разрабатывала. Возможно, это ваша текущая платформа

00:16:23.420 --> 00:16:26.500
электронной коммерции, Marketplace, логистическая компания или складская система. Суть не в том,

00:16:26.620 --> 00:16:29.400
чтобы навязать вам определенный набор приложений, а в том, чтобы позволить вам подключить системы,

00:16:29.440 --> 00:16:32.680
которые уже подходят вашему бизнесу. За кулисами эти провайдеры используют коннекторы Power Automate.

00:16:32.820 --> 00:16:36.360
В Power Platform есть более 200 готовых коннекторов, так что у вас масса вариантов для старта.

00:16:36.440 --> 00:16:40.540
А если ни один из них не подходит, вы или ваш партнер можете создать своего провайдера.

00:16:40.700 --> 00:16:45.940
Каждое подключенное приложение продолжает выполнять свою работу. Ваш интернет-магазин фиксирует покупку.

00:16:45.940 --> 00:16:50.100
Система учета запасов очлеживает остатки. Партнер по выполнению заказов упаковывает и доставляет

00:16:50.100 --> 00:16:53.600
товары. Система Биллинга занимается финансами. Интеллектуальное управление заказами координирует

00:16:53.600 --> 00:16:56.880
сообщения и дальнейшие шаги между всеми ними. Как только эти системы начинают делиться обновлениями,

00:16:57.020 --> 00:16:59.440
ваш бизнес видит все, что происходит во всем процессе обработки заказов.

00:16:59.620 --> 00:17:02.320
Больше не нужно искать информацию на разных экранах.

00:17:03.040 --> 00:17:05.320
Больше аналитики и целостное представление.

00:17:05.680 --> 00:17:08.960
Эта общая информация дает гораздо более ясную картину вашей работы с заказами.

00:17:09.140 --> 00:17:11.440
Интеллектуальное управление заказами включает панели мониторинга Power BI,

00:17:11.440 --> 00:17:13.520
которые собирают метрики заказов и выполнения в одном месте.

00:17:13.740 --> 00:17:17.480
Служба поддержки клиентов может найти заказы, которые перестали двигаться.

00:17:17.480 --> 00:17:21.120
Операционный отдел может заметить заблокированные маршруты или задержки в выполнении заказов.

00:17:21.180 --> 00:17:23.820
А руководители бизнеса могут искать закономерности во всем процессе.

00:17:23.960 --> 00:17:26.280
Без такого обзора задержка может показаться изолированной проблемой.

00:17:26.360 --> 00:17:28.720
Но когда данные собраны вместе, ваша команда может заметить, что многие заказы

00:17:28.720 --> 00:17:31.100
замедляются у конкретного партнера по выполнению или что определенный вариант доставки

00:17:31.100 --> 00:17:35.320
создает больше исключений, чем ожидалось. Панель мониторинга не решает проблему сама по себе,

00:17:35.320 --> 00:17:38.700
но помогает людям точно знать, где искать причину.

00:17:39.840 --> 00:17:43.100
Это делает процесс управления прозрачным и эффективным.

00:17:43.700 --> 00:17:46.940
Вспомните офисные здания. Интеллектуальное управление заказами

00:17:46.940 --> 00:17:51.100
объединяет стойку регистрации для приема заявок, складской терминал с информацией о наличии,

00:17:51.300 --> 00:17:54.720
систему планирования маршрутов для выбора места отгрузки и аналитический центр,

00:17:54.960 --> 00:17:56.560
где команды очлеживают все процессы.

00:17:56.640 --> 00:18:00.200
У каждой части своя задача, но именно заказ связывает их воедино.

00:18:01.200 --> 00:18:04.200
Итог. Один заказ, один скоординированный путь.

00:18:04.340 --> 00:18:07.040
Спасибо, что присоединились ко мне за порцией новых знаний.

00:18:07.220 --> 00:18:10.640
Интеллектуальное управление заказами выстраивает единый прямой маршрут для всех процессов,

00:18:10.780 --> 00:18:12.580
от первичного приема заявки до финального счета.

00:18:12.580 --> 00:18:15.780
Подписывайтесь на любимой платформе для подкастов и смотрите следующий эпизод.

00:18:15.900 --> 00:18:19.960
Вы увидите, как именно Dynamics 365 и Power Platform выполняют всю работу за кулисами.