Коли клієнт натискає «купити» на вашому сайті, потрібний товар може лежати на складі у магазині на іншому кінці міста або у партнера з доставки. Утім, клієнт очікує лише двох речей – чіткої обіцянки та пакунка біля своїх дверей. Вітаємо у черговому епізоді Microsoft Knowledge Nuggets на М365FM. Я Мо Пітерс, і сьогодні ми розглянемо інтелектуальне управління замовленнями в Dynamic з 365-ма простою мовою. Ми простежимо за цим замовленням від кліку на сторінці оплати до процесу, який забезпечує його доставку.

Він просто спрямовує потрібних людей і системи так, щоб робота виконувалася в правильному місці. Чому замовлення стають хаотичними? Уявіть, що ви продаєте одні й ті самі навушники через свій сайт, фізичні магазини, онлайн-маркетплейс та колл-центр. Для клієнта це все просто різні способи купити навушники. Але за лаштунками кожен канал передає деталі замовлення в абсолютно різні системи. На вашому сайті зберігається один запис, у магазині на касі інший, Маркетплейс надсилає дані у власному форматі, а оператор колл-центру створює замовлення деінде. Одна проста обіцянка клієнту розпадається на кілька рухомих частин, які не взаємодіють між собою. А складські запаси додають ще один рівень складності. На головному складі може бути 20 пар. У магазині через дорогу 5 і ще один склад також має запаси. Але він далі, а вартість доставки там вища. Частина товару вже зарезервована для інших замовлень, повернень або покупців у магазині.

Тому цифра поруч із товаром насправді не вирішує проблему. Потім вам потрібно вирішити, як доставити товар. Чи має його відправити склад. Чи має це зробити магазин. Або клієнт може забрати його самостійно. А якщо хтось купує два товари, але жодна локація не має обох, чи розділяти замовлення на дві посилки, чи чекати, поки все можна буде відправити разом. Кожен вибір впливає на вартість, термін доставки та обіцянку, яку ви дали клієнту. Два десятиліття тому компанії виконували ці завдання в окремих системах за допомогою різних команд. Відділ продажів приймав замовлення. Хтось перевіляв наявність на складі. Склад отримував запит. Партнер з доставки отримував інший запит. Відділ розрахунків займався своєю частиною пізніше. Це працювало добре, коли замовлення були простими, а обсяги – невеликими. Але ось у чому річ. Коли оновлення між системами рухаються повільно, люди починають заповнювати ці прогалини вручну.

Агент служби підтримки перевіряє один екран, пише листа на склад, потім дзвонить перевізнику, і тим часом товар може бути проданий через інший канал, перш ніж оновлення запасів дійде до сайту. Тепер у вас є замовлення на те, чого ви не можете надіслати. Саме так стається перевищення обсягів продажу. І саме тому вибір варіантів доставки займає забагато часу. Команди постійно копіюють дані з місця на місце, а клієнти отримують розмиті відповіді замість конкретики. Для клієнта вся ця складність не має значення, адже він ставить лише одне запитання – де моє замовлення? Компанії насправді потрібне єдине місце, де можна бачити шлях замовлення через усі пов'язані бізнес-додатки, водночас дозволяючи кожному додатку робити свою справу. Відділ продажів реєструє продаж. Склад керує збором та пакуванням. Служба доставки забезпечує відправлення. Бухгалтерія опрацьовує платежі. Нікому не потрібно викидати всі наявні системи.

Бракує лише координатора між ними. Ой, місце, яке може прийняти замовлення, зрозуміти наступні кроки та спрямувати роботу без ланцюга ручних передач. Ось у чому проблема. Dynamics 365 Intelligent Oda Management відповідає цьому простому визначенню. То що саме таке Dynamics 365 Intelligent Oda Management? Ми розберемо це простими словами. Ось найпростіше визначення. Це хмарний додаток, який приймає замовлення та веде його через усі системи компанії від моменту надходження до завершення виконання та оплати. Уявіть жвавий залізничний вокзал. Поїзди прибувають з різних напрямків. Пасажирам потрібні різні платформи. Деякі пересадки швидкі, інші потребують очікування. Intelligent Oda Management працює як диспетчерська вокзалу. Він не керує поїздом і не продає квитки, але бачить увесь маршрут і підказує кожній системі, що робити далі. Microsoft побудувала Intelligent Oda Management на базі Dataverse.

Dataverse – це спільна платформа даних для багатьох додатків Dynamics 365 та Pava Platform. Простими словами, це надає бізнес-додаткам єдине місце та формат для зберігання інформації. Це означає, що замовлення не має зовсім іншого значення в кожному екрані чи системі. Ця спільна основа допомагає, але вам не обов'язково купувати всі інші додатки Dynamics 365, щоб користуватися Intelligent Oda Management. Компанія може використовувати Dynamics 365 Finance або Supply Chain Management. Інша може мати власну складську систему, інший інтернет-магазин або службу доставки від іншого постачальника. Цей додаток може працювати як з продуктами Microsoft, так і з іншими бізнес-рішеннями. Точки підключення називаються провайдерами. Провайдер передає дані про замовлення та виконання між Intelligent Oda Management та іншою системою. Уявіть провайдера як перекладача на вході. Одна система надсилає замовлення у власному форматі.

Провайдер розпізнає цей формат, передає інформацію в Intelligent Oda Management і може надіслати наступний запит у форматі, зрозумілому, іншій системі. Отже, додаток збирає інформацію про замовлення в одному місці, навіть якщо воно було оформлене деінде. Клієнт може зробити покупку через торговельний сайт AIO. Інший може оформити замовлення через систему точок продажу. Бізнес-клієнт може надіслати електронне замовлення через B2B-процес. Інтелектуальне управління замовленнями надає компанії єдине місце для перегляду замовлень та відстеження етапу їх виконання. Не кожне замовлення проходить однаковий шлях. Одне може очікувати на наявність товару, інше може вже перебувати на складі. Третє може потребувати виставлення рахунку після доставки. Додаток відстежує цей стан, щоб команда бачила не лише статус «Замовлення отримано». Вони можуть бачити, на якому саме етапі шляху перебуває замовлення.

Ось момент, який люди іноді пропускають. Інтелектуальне управління замовленнями не бере на себе всю роботу. Воно не стає раптом екраном збирання для комірника, мережею доставки перевізника чи системою рахунків фінансового відділу. Ці підключені додатки продовжують виконувати свою спеціалізовану роботу. Інтелектуальне управління замовленнями спрямовує передачу даних між ними. Воно отримує запит, перевіряє маршрут, передає завдання далі та чекає на наступне оновлення. Тепер простежимо за одним замовленням, оскільки шлях замовлення робить усю концепцію набагато зрозумілішою. Шлях замовлення – це правила, що керують роботою. Уявіть, що клієнт замовляє два товари на вашому сайті пізно ввечері і хоче, щоб обидва були доставлені завтра. Інтернет-магазин фіксує замовлення ім'я клієнта, адресу доставки, дві товарні позиції та обраний спосіб доставки. Провайдер передає це замовлення в систему інтелектуального управління і шлях замовлення розпочинається.

Перш ніж хтось спробує виконати його, система перевіряє замовлення, щоб переконатися, що вся інформація наявна і відповідає правилам компанії. Вона перевіряє заголовок замовлення щодо даних клієнта та доставки. Вона перевіряє кожну позицію щодо продукту та кількості. Вона підтверджує, що адреса містить достатньо інформації для доставки і перевіряє відповідність правилам каналу продажу. Ця первинна перевірка зупиняє поширення помилкових даних, перш ніж вони спричинять проблеми. Уявіть замовлення без номера квартири. Якщо воно одразу потрапить на склад, а потім до перевізника, проблему можуть помітити лише тоді, коли посилку не вдасться доставити. Етап перевірки виявляє проблему раніше, поки ще є час зв'язатися з клієнтом або притримати замовлення. Основою для цієї роботи є потік оркестрації. Цей вислів звучить технічно, але він простий. Потік оркестрації – це візуальна карта, яка вказує системі управління, що робити, коли надходить інформація про замовлення та приходять події від підключених систем.

Ви створюєте цю карту на основі власних бізнес-процесів. Базовий потік замовлення може починатися з моменту надходження нового замовлення. Він перевіряє заголовок і рядки. Він надсилає замовлення для прийняття рішень щодо виконання. Після цього він надсилає замовлення на виконання до потрібної підключеної системи. Коли робота досягає потрібного етапу, він може надіслати інформацію про замовлення постачальнику послов з виставлення рахунків. Кожна дія має чітке завдання. Перевірка заголовка замовлення звіряє основні деталі замовлення. Перевірка рядка замовлення звіряє окремі товари та їхню кількість. Надсилання на виконання передає замовлення на виконання постачальнику, який відповідає за цю роботу. Надсилання рахунку передає інформацію про замовлення постачальнику послуг з виставлення рахунків. Ці назви звучать як позначки на панелі керування заводом, і це корисно, оскільки кожна позначка точно вказує, що відбувається в цей момент потоку.

Але реальному бізнесу часто потрібно більше, ніж одна пряма лінія. Можливо, замовлення з веб-сайту йдуть одним шляхом, а від бізнес-клієнтів – іншим. Можливо, один тип продукту потребує спеціального схвалення. Можливо, замовлення може рухатися далі, лише якщо перший крок успішний. Інтелектуальне управління замовленнями включає умови для такого вибору. Умова створює шлях, так і шлях – ні. Якщо попередня дія успішна, замовлення може продовжуватися шляхом – так. Якщо вона не вдається, потік може спрямувати замовлення іншим шляхом. Це не вирішує кожну проблему само по собі, але забезпечує заплановану реакцію процесу замість того, щоб покладатися на те, що команда випадково виявить помилку. Також існують розділювачі. Розділювач спрямовує потік на кілька шляхів на основі визначених вами правил. Ви можете використовувати його, коли замовлення з різних джерел потребують різних перевірок, або коли різні частини роботи потребують різних маршрутів.

Деякі розділені шляхи можуть знову з'єднуватися пізніше, тоді як інші продовжуються окремо. Користувацькі дії охоплюють завдання, унікальні для бізнесу. Можливо, у компанії є власна виробнича система або система партнера, яка не охоплена стандартною дією. Користувацька дія може підключити цей крок до потоку замовлень, щоб маршрут відображав увесь процес, а не приховував частину в листах чи ручній роботі. Повернімося до нашого замовлення з двох позицій. Система отримує його з веб-сайту та перевіряє дані клієнта, адресу та товарні позиції. Потім замовлення досягає етапу прийняття рішення щодо виконання. Якщо обидва товари можуть йти одним маршрутом, потік може надіслати запит на виконання далі як одне ціле. Якщо правила компанії вимагають іншого результату, замовлення може обрати інший шлях. Можливо, для двох товарів потрібні окремі запити на виконання, можливо, замовлення потребує іншого вибору доставки.

Потік не вгадує. Він слідує правилам, створеним бізнесом і подіям, які повертають підключені системи. Ця остання частина має значення. Інтелектуальне управління замовленнями може спрямовувати роботу, але підключені системи звітують, коли робота просувається вперед. Постачальник послуг з виконання замовлень може отримати запит. Білінговий провайдер може отримати деталі замовлення. Ці події забезпечують рух замовлення через весь процес. Отже, цей додаток – не одна гігантська система заміни. Це набір правил, що об'єднує спеціалістів, надаючи кожній системі потрібну роботу в потрібний час. Інтернет-магазин приймає замовлення. Система виконання замовлень займається їх опрацюванням. Білінгова система займається виставленням рахунків. Інтелектуальне управління замовленнями керує маршрутом між цими завданнями. Відповідальні за процес замовлення фахівці можуть створювати ці потоки безпосередньо в додатку.

Їм не потрібно писати кожен шлях як традиційний код і не потрібно просити IT-адміністратора змінювати кожне бізнес-правило. Це дає команді з логістики можливість моделювати саме той процес, який їм потрібен. Проте ці зміни потребують обережності. Потік оркестрації залишається неопублікованим, поки ви його створюєте та тестуєте. На цьому етапі вхідні дані не проходять через потік. Після публікації потік та його дії запускаються, коли дані надходять у систему. Після публікації ви не можете редагувати цей потік безпосередньо. Якщо бізнесу потрібні зміни, команда може зупинити опублікований потік, що повертає його до неопублікованого стану. Вони можуть відредагувати потік, а потім опублікувати нову версію, коли вона буде готова. Така організація спонукає команди тестувати маршрут до того, як ним підуть реальні замовлення. Маршрут працює лише тоді, коли він знає, які запаси є в наявності. Це підводить нас до оперативної інформації про запаси, що стоїть за кожним рішенням щодо виконання.

Видимість запасів – це розуміння того, що ви можете реально продати. Ось проста істина. Ви не можете виконати замовлення, якщо не знаєте, що маєте цей товар на складі. Звучить очевидно, але запаси можуть ховатися на складі у магазині, у партнерському пункті або в різних юридичних особах всередині однієї компанії. Коли кожна локація веде власний облік, ви не можете відповісти на просте запитання, що я можу гарантувати цьому клієнту прямо зараз.

Як табло запасів у розподільчому центрі. Замість того, щоб дзвонити на кожен склад і просити когось перевірити, процес замовлення дивиться на один спільний огляд, куди надходять дані з усіх ваших систем. Тепер, якщо товар відображається як запас десь, це не означає, що він може виконати будь-яке замовлення. Продукт може лежати на складі, але вже бути зарезервованим або він знаходиться в магазині, що продає лише локально, або він просто занадто далеко, щоб дотриматися обіцяного клієнту терміну доставки. Існує велика різниця між запасами, які десь існують, і запасами, які можуть виконати це замовлення прямо зараз. Уявіть, що клієнт купив куртку онлайн і хоче отримати її завтра. На вашому головному складі її вже немає. Без актуальних даних про запаси ваш сайт може прийняти замовлення за старими показниками, і тоді склад отримає запит на товар, якого не може надіслати, через що клієнт дізнається про це лише після оплати.

Це створює зайву роботу для всіх. Завдяки об'єднаній інформації про запаси інтелектуальна система управління замовленнями бачить, що на головному складі куртки немає, але вона є в магазині поруч. Якщо цей магазин підтримує доставку, він може виконати замовлення. Якщо клієнт обрав самовивіз, той самий магазин стає точкою видачі. Рішення починається з кращого огляду залишків. Для компанії з кількома юридичними особами цей огляд охоплює запаси всіх підрозділів. Це важливо, коли ви працюєте в кількох країнах, регіонах або бізнес-одиницях, де запаси не враховуються в межах одного списку. Процес обробки замовлення використовує дані про запаси в реальному часі для вибору подальших дій. Склад, магазин або інше джерело запасів, як і раніше, веде власні записи. Видимість запасів надає актуальні дані для ширшого процесу замовлення, де їх можуть використовувати правила виконання. Це допомагає уникнути обіцянок, заснованих на вчорашніх даних, і дає службі підтримки чітку відповідь, коли хтось запитує, чи прибуде товар вчасно.

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

Виконання Оптимізація Вибір найкращого місця для відправлення замовлення Оптимізація порівнює можливі місця виконання замовлення та обирає одне з них на основі встановлених вами правил. Простою мовою, вона відповідає на питання, звідки має надійти це замовлення. Найкраще не завжди означає найближче. Найближчий магазин може мати товар, але доставка звідти може коштувати дорожче. На віддаленому складі обидва товари вже можуть бути готові до пакування, а інша точка може мати запас, але не встигати доставити товар в обрану клієнтом дату. Кожна компанія має вирішити, чому надавати перевагу в правилах. Деякі бізнеси ставлять швидкість доставки на перше місце. Інші хочуть мінімізувати витрати на доставку. Компанія також може прагнути зберегти запаси в магазинах для покупців, що заходять особисто, або уникати розділення замовлення на кілька посилок, якщо немає іншого виходу. Інтелектуальне управління замовленнями використовує стратегії виконання, що відображають ці вибори.

Думайте про це як про вибір маршруту для фургона доставки. Найкоротша дорога не завжди найшвидша, адже можуть бути затори, дорожні роботи чи затримки в дорозі. Так само і найближчий склад не завжди є найкращим рішенням, якщо врахувати вартість запасів, зобов'язання перед клієнтом та варіанти доставки. Повернімося до клієнта, який придбав два товари онлайн. У магазині за 10 хвилин від нього є перший товар. На складі є обидва товари, але він розташований далі. Якщо магазин відправить перший товар, а склад – другий, клієнт отримає дві посилки вчасно, але це підвищить витрати на доставку. Склад може відправити обидва товари разом. Якщо це дозволяє вкластися в обіцяний термін, одна посилка з цього місця може бути кращим вибором. Правила можуть надавати перевагу меншій кількості відправлень та нижчим витратам на доставку. Але якщо доставка на завтра важливіша за відправлення товарів разом, система може вибрати магазин для одного товару, а склад – для іншого.

Це і є розділене замовлення. Розділене замовлення не означає, що система дала збій. Це може бути плановим рішенням, коли жодна локація не може виконати замовлення повністю належним чином. Бізнес вирішує, коли доцільно розділяти замовлення за допомогою обраної стратегії виконання. Такий самий підхід підтримує купівлю онлайн з відправкою з магазину. Клієнт робить замовлення на сайті, а магазин поруч має потрібний товар і може швидко його відправити. Тож цей магазин стає джерелом виконання замовлення, навіть якщо клієнт там ніколи не був. Це також підтримує купівлю онлайн із самовивозом у магазині. Система використовує дані про запаси та місцезнаходження, щоб знайти магазин для самовивозу, тому клієнт отримує зручний варіант, а компанія спрямовує замовлення, куди потрібно. Ці рішення не обов'язково мають бути окремими для кожного каналу продажу. Без єдиного процесу прийняття рішень вебсайт, маркетплейс і кол-центр можуть потребувати власних правил маршрутизації.

Коли бізнес змінює політику доставки або починає використовувати магазини для виконання замовлень, командам доводиться оновлювати кілька систем. Оптимізація виконання замовлень зосереджує цей процес в одному місці протягом усього шляху замовлення. Вебсайт продовжує приймати замовлення, маркетплейс – замовлення, а магазин – продавати товари. Але компанія може змінити спосіб вибору локації без перебудови правил у кожному каналі, отримуючи більше контролю, коли рухаються запаси, змінюються обіцянки щодо доставки або з'являються нові опції. Однак стратегія виконання може порівнювати локації лише тоді, коли необхідна інформація надходить від систем, що нею володіють. Замовлення мають надходити, оновлення запасів мають приходити, а партнери з виконання – отримувати завдання та звітувати про прогрес. Ця робота з підключення залежить від провайдерів. Провайдери та підключення – це двері до будівлі.

Щоб інтелектуальне керування замовленнями виконувало свою роботу, йому потрібен надійний спосіб взаємодії з усім навколо. Провайдери – це те, що робить це можливим. Провайдер – це, по суті, підключення, яке передає дані замовлень та оновлення виконання між інтелектуальним керуванням, замовленнями та іншою системою. Інформація передається в обох напрямках, тому нікому не потрібно копіювати її вручну. Уявіть будівлю з багатьма дверима для доставки. Одні двері отримують замовлення з вашого інтернет-магазину, інші з'єднуються з вашою системою обліку запасів. Треті надсилають завдання на склад або партнеру з доставки. Кожні двері мають чітке призначення, а провайдери керують інформацією, що проходить крізь них. Microsoft створює частину цих коннекторів самостійно. Вони називають їх провайдерами першої сторони. Вони з'єднують інтелектуальне керування замовленнями з такими програмами, як Dynamics 365 Supply Chain Management, Dynamics 365 Commerce або Dynamics 365 Finance.

Служби обліку запасів і виконання замовлень у межах інтелектуального керування також використовують ці провайдери для обміну даними. Тепер, імовірно, у вас уже є інші системи. Ось тут і стають у пригоді сторонні провайдери. Вони підключають сервіси, які Microsoft не розробляє. Можливо, це ваша наявна платформа електронної комерції, торговий майданчик, логістична компанія або складська система. Мета полягає не в тому, щоб змусити вас використовувати певний набір програм. А це потрібно для того, щоб ви могли підключити системи, які вже відповідають вашому бізнесу. За лаштунками ці провайдери використовують коннектори Pava Otamate. Pava Platform має понад 200 готових коннекторів, тому у вас є багато варіантів для старту. А якщо жоден з них не підходить, ви або ваш партнер можете створити власного провайдера. Кожна підключена програма продовжує виконувати свою роботу. Ваш інтернет-магазин фіксує покупку.

Система обліку запасів відстежує залишки. Партнер з виконання пакує та доставляє замовлення. Система виставлення рахунків опрацьовує фінанси. Інтелектуальне керування замовленнями координує повідомлення та наступні кроки між усіма ними. Коли ці системи обмінюються оновленнями, ваш бізнес може бачити, що відбувається в межах усього процесу замовлення. Більше не потрібно шукати інформацію на окремих екранах. Інсейти та загальну картину Ця спільна інформація надає набагато чіткіше уявлення про вашу роботу із замовленнями. Інтелектуальне керування замовленнями включає інформаційні панелі PAVABI, які об'єднують показники замовлень та виконання в одному місці. Служба підтримки клієнтів може знайти замовлення, які перестали рухатися. Операційний відділ може помітити заблоковані маршрути або затримки виконання. А бізнес-лідери можуть шукати закономірності в межах усього процесу. Без такого огляду затримка може здаватися ізольованою проблемою.

Але коли дані зібрані разом, ваша команда може помітити, що багато замовлень сповільнюється у конкретного партнера з виконання або що певний варіант доставки створює більше винятків, ніж очікувалося. Інформаційна панель не вирішує проблему сама по собі, але вона допомагає людям знати, де саме шукати. Згадайте офісну будівлю. Інтелектуальне управління замовленнями об'єднує стійку реєстрації, що приймає запити, складську дошку з наявністю товарів, планувальник маршрутів для вибору місця виконання та звітний центр, де команди бачать перебіг усіх процесів. Кожна частина має своє завдання, але замовлення пов'язує їх усіх. Висновок «Одне замовлення, одна скоординована подорож». Дякую, що приєдналися до цієї порції знань. Інтелектуальне управління замовленнями прокладає єдиний прямий маршрут через увесь ваш процес від первинного отримання до кінцевого рахунку. Підписуйтесь на вашій улюбленій подкаст-платформі та дивіться наступний епізод.

Ви побачите, як саме Dynamics 365 та Pava Platform виконують роботу за лаштунками.