Когда клиент нажимает «Купить» на вашем сайте, нужный ему товар может находиться на складе, в магазине на другом конце города или у службы доставки. Но на самом деле клиент ожидает всего две вещи – четкое обещание и посылку у своей двери. Добро пожаловать в новый выпуск Microsoft NoLedge на Getas на M365FM. Я Мо Питерс, и сегодня мы простыми словами поговорим об интеллектуальном управлении заказами в Dynamics 365. Мы проследим путь заказа от нажатия кнопки оплаты до его фактической доставки. Представьте себе это как центральный диспетчерский пункт в большом офисном здании. Это не еще один интернет-магазин, и он не упаковывает коробки. Он просто направляет нужных людей и системы, чтобы работа выполнялась там, где нужно. Почему с заказами возникает путаница? Представьте, что вы продаете одни и те же наушники через свой сайт, обычные магазины, онлайн-маркетплейс и колл-центр. Для клиента это просто разные способы купить наушники. Но за кулисами каждый канал отправляет данные о заказе в совершенно разные системы. На сайте создается одна запись, в кассовой системе магазина – другая, маркетплейс использует свой формат, а оператор колл-центра создает заказ еще где-то.

Одно простое обещание клиенту превращается в несколько разрозненных частей, которые не взаимодействуют друг с другом. А наличие запасов добавляет еще один уровень сложности. На главном складе может быть 20 пар. В магазине на другом конце города – 5, и на другом складе тоже есть запас. Но он находится дальше, и доставка обойдется дороже. Часть товара уже зарезервирована под другие заказы, возвраты или покупателей в магазине. Поэтому цифра рядом с товаром еще не решает проблему. Затем нужно решить, как осуществлять доставку. Должен ли отправлять склад, должен ли отправлять магазин. Или клиент может забрать товар самостоятельно. А если кто-то покупает два товара, и ни в одном месте нет обоих сразу, стоит ли разбивать заказ на две посылки или подождать, пока все можно будет отправить вместе. Каждый выбор влияет на стоимость, время доставки и обещания, которые вы дали клиенту. Два десятилетия назад компании выполняли эти задачи в разных системах и разными командами. Отдел продаж принимал заказ. Кто-то проверял наличие на складе.

Склад получал запрос. Партнер по доставке получал свой запрос. Отдел расчетов занимался своей частью позже. Это отлично работало, когда заказы были простыми, а объемы – небольшими. Но вот в чем загвоздка. Когда обновления между системами проходят медленно, людям приходится заполнять эти пробелы вручную. Оператор поддержки проверяет один экран, пишет письмо на склад, затем звонит перевозчику, а тем временем товар может быть продан через другой канал до того, как информация об остатках обновится на сайте. Теперь у вас есть заказ на то, что вы не можете отправить. Так и возникают излишки продаж. И именно поэтому выбор доставки занимает так много времени. Команды постоянно копируют данные из одного места в другое, а клиенты получают расплывчатые ответы вместо конкретных. С точки зрения клиента, вся эта сложность не имеет значения, ведь он задает лишь один вопрос. Где мой заказ? Компании нужно единое место, где можно видеть путь заказа во всех бизнес-приложениях, позволяя каждому из них делать то, что оно умеет лучше всего. Отдел продаж фиксирует продажу. Склад управляет комплектацией и упаковкой. Отдел доставки занимается отправкой. Биллинг отвечает за деньги. Никому не нужно выбрасывать все свои системы. Не хватает лишь координатора между ними. Ой, место, которое может принять заказ, понять, что делать дальше, и направить работу без цепочки ручных передач. В этом-то и проблема. Dynamics 365 Intelligent Order Management решает ее, говоря простым языком. Итак, что же такое Dynamics 365 Intelligent Order Management?

Привет! Сегодня мы разберем это простыми словами. Вот самое простое определение. Это облачное приложение, которое принимает заказ и проводит его через все системы компании с момента поступления до выполнения и оплаты. Представьте оживленный железнодорожный вокзал. Поезда прибывают с разных направлений. Пассажирам нужны разные платформы. Некоторые пересадки быстрые, другие требуют ожидания. Intelligent Order Management работает как диспетчерская вокзала. Она не ведет поезд и не продает билеты, но видит весь маршрут и говорит каждой системе, что делать дальше. Microsoft создала Intelligent Order Management на базе Dataverse. Dataverse — это общая платформа данных для многих приложений Dynamics 365 и Power Platform. Проще говоря, она предоставляет бизнес-приложениям общее место и формат для хранения информации. Это значит, что заказ не будет иметь разный смысл в каждой системе или на каждом экране. Эта общая платформа помогает, но вам не нужно покупать все остальные приложения Dynamics 365, чтобы использовать Intelligent Order Management. Компания может использовать Dynamics 365 Finance или Supply Chain Management. Другая может использовать свою складскую систему, интернет-магазин или службу доставки от стороннего поставщика. Это приложение работает как с продуктами Microsoft, так и со сторонними бизнес-приложениями. Точки подключения называются провайдерами. Провайдер передает информацию о заказах и их выполнении между Intelligent Order Management и другой системой. Представьте провайдера как переводчика на входе. Система отправляет заказ в своем собственном формате. Провайдер распознает этот формат, передает данные в Intelligent Order Management и отправляет следующий запрос в формате, понятном другой системе. Итак, приложение собирает информацию о заказах воедино, даже если они поступили из разных источников. Клиент может совершить покупку на сайте AIO. Другой может оформить заказ через систему торговых точек. Бизнес-клиент может отправить электронный заказ через B2B процесс. Интеллектуальное управление заказами дает компании единое место для просмотра заказов и отслеживания стадии их выполнения. Не каждый заказ следует по одному и тому же пути. Один может ожидать поступления товара на склад. Другой может уже находиться на складе. Третий может потребовать выставления счета после доставки. Приложение отслеживает состояние, чтобы команда видела больше, чем просто статус «заказ получен». Они могут в точности видеть, на каком этапе пути находится заказ. Вот часть, которую люди иногда упускают. Интеллектуальное управление заказами не берет на себя всю работу. Оно не становится внезапно экраном комплектовщика, сетью доставки перевозчика или биллинговой системой финансового отдела. Эти подключенные приложения по-прежнему выполняют свою специализированную работу. Интеллектуальное управление заказами руководит передачей задач между ними.

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

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

Эти названия звучат как надписи на панели управления заводом, и это удобно, так как каждая метка точно указывает, что происходит в этой точке процесса. Но реальному бизнесу часто недостаточно одной прямой линии. Возможно, заказы с веб-сайта идут по одному пути, а заказы бизнес-клиентов – по другому. Возможно, для одного типа товара требуется особое одобрение. Возможно, заказ может продвигаться дальше, только если первый шаг прошел успешно. Интеллектуальное управление заказами включает условия для такого выбора. Условие создает путь «да» и путь «нет». Если предыдущее действие выполнено успешно, заказ может продолжить путь по ветке «да». Если оно не удалось, поток может направить заказ по другому пути. Это не решает все проблемы само по себе, но дает процессу запланированный ответ вместо того, чтобы оставлять команду обнаруживать ошибку случайно. Существуют также разветвители. Разветвитель направляет поток по нескольким путям на основе определенных вами правил. Вы можете использовать его, когда заказы из разных источников требуют разных проверок или когда разные части работы требуют разных маршрутов.

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

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

Когда каждое подразделение ведет свой учет, вы не можете ответить на базовый вопрос, что я могу обещать клиенту прямо сейчас. Видимость запасов дает интеллектуальному управлению заказами актуальный обзор всех остатков вашей сети поставок. Представьте это как информационное табло в распределительном центре. Вместо того, чтобы звонить на каждый склад и просить кого-то проверить наличие, процесс обработки заказа смотрит на один общий обзор, куда стекаются данные из всех систем. Но даже если товар где-то числится, это не значит, что он может выполнить любой заказ. Товар может лежать на складе, но быть уже зарезервированным, или находиться в магазине, который торгует только локально, или же просто быть слишком далеко, чтобы соблюсти выбранный клиентом срок доставки. Есть большая разница между товаром, который где-то существует, и товаром, который может выполнить этот заказ прямо сейчас. Представьте, что клиент купил куртку онлайн и хочет получить ее завтра. На вашем главном складе их не осталось. Без актуальных данных о запасах сайт может принять заказ на основе устаревших цифр, и склад получит запрос на то, чего не может отправить, а клиент узнает об этом только после оплаты. Это создает лишнюю работу для всех. Благодаря связанной информации об остатках, интеллектуальная система управления заказами видит, что на главном складе куртки нет, зато она есть в ближайшем магазине. Если этот магазин поддерживает доставку, он может выполнить заказ. Если клиент выбрал самовывоз, этот же магазин станет точкой выдачи. Решение начинается с лучшего обзора товарных запасов. Для компании с несколькими юридическими лицами этот обзор охватывает все их запасы. Это важно, когда вы работаете в нескольких странах, регионах или бизнес-единицах, а данные об остатках хранятся не в одной системе. Процесс обработки заказа использует данные об остатках в реальном времени, определяя дальнейший путь. Склад, магазин или другой источник запасов по-прежнему ведет собственный учет. Прозрачность запасов объединяет текущие показатели в единый процесс заказа, где правила исполнения могут их использовать. Это помогает не давать обещаний, основанных на вчерашних данных, и дает службе поддержки четкий ответ, когда кто-то спрашивает, успеет ли товар вовремя. Вместо того, чтобы искать информацию в разных системах в надежде на их совпадение, команда видит статус остатков, повлиявший на выбор способа доставки. Конечно, видеть все возможные точки отправки – это еще не все. Вы можете обнаружить товар в пяти разных местах. Одно ближе всего к клиенту, другое имеет больше запасов, третье позволяет отправить оба товара вместе. Кто-то или что-то все равно должно сделать выбор. Эта задача ложится на плечи оптимизации исполнения заказов. Исполнение. Оптимизация. Выбор лучшего места для отправки заказа. Оптимизация сравнивает возможные места для заказа и выбирает одно на основе правил вашей компании. Проще говоря, она отвечает на вопрос, откуда должен прийти этот заказ. Лучший не всегда означает ближайший. Товар может быть в ближайшем магазине, но отправка оттуда может стоить дороже.

На более удаленном складе оба товара могут быть уже готовы к упаковке, а в другом месте товар есть, но сроки доставки не соответствуют ожиданиям клиента. Каждая компания должна решить, чему отдавать приоритет в правилах. Некоторые бизнесы ставят на первое место скорость доставки. Другие стремятся снизить затраты на логистику. Компания также может захотеть сохранить запасы магазина для розничных покупателей или избежать дробления заказа на несколько посылок, если есть другой вариант. Интеллектуальное управление заказами использует стратегии исполнения, отражающие этот выбор. Это похоже на выбор маршрута для курьерского фургона. Самый короткий путь не всегда самый быстрый, ведь могут быть пробки, дорожные работы или задержки в пути. Также и ближайший склад не всегда обеспечивает лучший результат, если учитывать стоимость товара, обязательства по срокам и варианты доставки. Вернемся к покупателю, который заказал два товара онлайн. В магазине в 10 минутах езды есть первый товар. На складе есть оба товара, но он находится дальше. Если отправить первый товар из магазина, а второй со склада, покупатель может получить две посылки вовремя, но это увеличит затраты на доставку. Возможно, склад сможет отправить оба товара одной посылкой. Если это позволит уложиться в обещанный срок, отправка одной посылки с этого склада может стать лучшим решением. Правила могут быть настроены на сокращение количества отправлений и снижение стоимости доставки. Но если доставка завтра важнее, чем получение всех товаров вместе, система может выбрать магазин для одного товара и склад для другого, это и есть разделение заказа. Разделение заказа не означает сбой в работе системы.

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

Оптимизация выполнения заказов объединяет этот процесс в одном месте на всем пути заказа. Сайт продолжает принимать заказы, маркетплейс продолжает принимать заказы, а магазин продолжает продавать товары. Но компания может менять логику выбора точки отгрузки без перенастройки правил в каждом канале, получая больше контроля при перемещении истоков, смене сроков доставки или появлении новых опций. Тем не менее, стратегия выполнения заказов может сравнивать площадки только при наличии актуальных данных из соответствующих систем. Заказы должны поступать, данные об остатках должны обновляться, а партнеры по доставке должны получать задачи и сообщать о статусе их выполнения. Эта работа по подключению зависит от провайдеров. Провайдеры и соединения – это двери в здание. Чтобы интеллектуальное управление заказами выполняло свою работу, ему нужен надежный способ связи со всем окружением. Именно провайдеры делают это возможным. Провайдер – это, по сути, соединение, которое передает сведения о заказах и обновлениях выполнения между системой интеллектуального управления заказами и другими системами. Информация передается в обоих направлениях, поэтому никому не нужно копировать что-либо вручную. Представьте себе здание с множеством дверей для доставки. Одна дверь получает заказы из вашего интернет-магазина, другая соединяется с вашей системой учета запасов. Третья отправляет задание на склад или партнеру по доставке. У каждой двери есть четкая цель, а провайдеры управляют информацией, проходящей через каждую из них. Майкрософт создает некоторые из этих коннекторов самостоятельно. Они называют их собственными провайдерами – first-party providers. Они соединяют интеллектуальное управление заказами с такими приложениями, как Dynamics 365 Supply Chain Management, Dynamics 365 Commerce или Dynamics 365 Finance. Службы учета запасов и выполнения заказов внутри интеллектуального управления также используют этих провайдеров для обмена данными. Конечно, у вас наверняка уже есть другие системы. Вот здесь на помощь приходят сторонние провайдеры. Они соединяют сервисы, которые Майкрософт не разрабатывала. Возможно, это ваша текущая платформа электронной коммерции, Marketplace, логистическая компания или складская система. Суть не в том, чтобы навязать вам определенный набор приложений, а в том, чтобы позволить вам подключить системы, которые уже подходят вашему бизнесу. За кулисами эти провайдеры используют коннекторы Power Automate.

В Power Platform есть более 200 готовых коннекторов, так что у вас масса вариантов для старта. А если ни один из них не подходит, вы или ваш партнер можете создать своего провайдера. Каждое подключенное приложение продолжает выполнять свою работу. Ваш интернет-магазин фиксирует покупку. Система учета запасов очлеживает остатки. Партнер по выполнению заказов упаковывает и доставляет товары. Система Биллинга занимается финансами. Интеллектуальное управление заказами координирует сообщения и дальнейшие шаги между всеми ними. Как только эти системы начинают делиться обновлениями, ваш бизнес видит все, что происходит во всем процессе обработки заказов. Больше не нужно искать информацию на разных экранах. Больше аналитики и целостное представление. Эта общая информация дает гораздо более ясную картину вашей работы с заказами. Интеллектуальное управление заказами включает панели мониторинга Power BI, которые собирают метрики заказов и выполнения в одном месте.

Служба поддержки клиентов может найти заказы, которые перестали двигаться. Операционный отдел может заметить заблокированные маршруты или задержки в выполнении заказов. А руководители бизнеса могут искать закономерности во всем процессе. Без такого обзора задержка может показаться изолированной проблемой. Но когда данные собраны вместе, ваша команда может заметить, что многие заказы замедляются у конкретного партнера по выполнению или что определенный вариант доставки создает больше исключений, чем ожидалось. Панель мониторинга не решает проблему сама по себе, но помогает людям точно знать, где искать причину. Это делает процесс управления прозрачным и эффективным. Вспомните офисные здания. Интеллектуальное управление заказами объединяет стойку регистрации для приема заявок, складской терминал с информацией о наличии, систему планирования маршрутов для выбора места отгрузки и аналитический центр, где команды очлеживают все процессы.

У каждой части своя задача, но именно заказ связывает их воедино. Итог. Один заказ, один скоординированный путь. Спасибо, что присоединились ко мне за порцией новых знаний. Интеллектуальное управление заказами выстраивает единый прямой маршрут для всех процессов, от первичного приема заявки до финального счета. Подписывайтесь на любимой платформе для подкастов и смотрите следующий эпизод. Вы увидите, как именно Dynamics 365 и Power Platform выполняют всю работу за кулисами.