WEBVTT

00:00:00.120 --> 00:00:02.040
Продавець оновлює адресу клієнта.

00:00:02.180 --> 00:00:05.740
Пізніше фінансовий відділ відкриває той самий запис і бачить стару адресу.

00:00:05.840 --> 00:00:07.240
То яка ж адреса правильна?

00:00:07.360 --> 00:00:09.840
Роками для вирішення цього хтось мав експортувати дані, редагувати таблицю,

00:00:09.920 --> 00:00:13.140
надсилати її електронною поштою та двічі вводити одне й те саме оновлення в інший додаток.

00:00:13.280 --> 00:00:15.840
Dynamics 365 Dual Right це змінює.

00:00:16.000 --> 00:00:19.820
Він з'єднує фінансові та операційні програми з програмами для роботи з клієнтами на базі Dataverse,

00:00:19.820 --> 00:00:23.160
тому спільні записи, як-от клієнти та замовлення, синхронізуються автоматично.

00:00:23.320 --> 00:00:28.840
З вами Мілко Петерс із М365FM, і цей короткий огляд пояснює Dual Right простою мовою.

00:00:29.020 --> 00:00:33.180
Ми розглянемо, що передається, як це працює, де Dual Right доречний, а де ні.

00:00:33.340 --> 00:00:36.840
Почнемо з бізнес-проблеми, яка створила потребу в цьому рішенні.

00:00:38.280 --> 00:00:40.280
Проблема, яку вирішує Dual Right.

00:00:40.640 --> 00:00:45.680
Уявіть бізнес, де дві групи працюють з одним клієнтом, але використовують абсолютно різні програми щодня.

00:00:45.840 --> 00:00:48.600
Фінансові та операційні програми відповідають за бек-офіс.

00:00:48.600 --> 00:00:52.220
Це гроші, запаси, продукти, замовлення, закупівлі та ланцюги постачання.

00:00:52.360 --> 00:00:56.940
Тут компанія відстежує, що продає, що може доставити, кому винна і що клієнт має сплатити.

00:00:57.100 --> 00:00:59.820
Програми для роботи з клієнтами фокусуються на ближчій взаємодії.

00:01:00.020 --> 00:01:02.340
Відділ продажів опрацьовує ліди та створює можливості.

00:01:02.500 --> 00:01:04.800
Служба підтримки клієнтів опрацьовує питання та звернення.

00:01:04.980 --> 00:01:07.600
Виїзне обслуговування планує роботи та відправляє фахівців на об'єкти.

00:01:07.720 --> 00:01:10.040
Проєктні команди відстежують роботу, обіцяну клієнту.

00:01:10.040 --> 00:01:12.220
Різним завданням потрібні різні інтерфейси.

00:01:12.300 --> 00:01:16.560
Продавець не повинен копатися у фінансових екранах лише для того, щоб оновити контакт після дзвінка.

00:01:16.700 --> 00:01:19.640
Але фінансовому користувачеві потрібні деталі клієнта та замовлення,

00:01:19.780 --> 00:01:23.840
що збігаються з даними відділу продажів, бо рахунки та доставки залежать від цієї інформації.

00:01:24.040 --> 00:01:27.240
Без зв'язку один клієнт непомітно перетворюється на два записи.

00:01:27.380 --> 00:01:31.820
У відділі продажів може бути Noswind Bikes, а у фінансах Noswind Bicycle Company.

00:01:31.820 --> 00:01:35.840
Один запис має нову адресу, інший все ще надсилає рахунки в старий офіс.

00:01:35.960 --> 00:01:40.520
Обидва записи виглядають логічно самі по собі, але вони вже не описують одні й ті самі ділові відносини.

00:01:40.700 --> 00:01:42.500
Спочатку виникають дрібні проблеми.

00:01:42.640 --> 00:01:45.580
Хтось не може знайти клієнта, бо назва відрізняється в іншій програмі.

00:01:45.720 --> 00:01:50.060
Менеджер з продажів обіцяє ціну або перевіряє запаси, але інформація не збігається з операційною стороною.

00:01:50.200 --> 00:01:54.760
Фінанси мають обробити замовлення, але деталі клієнта потребують перевірки, листа та чергового оновлення вручну.

00:01:54.760 --> 00:01:56.740
Потім ці дрібні проблеми накопичуються.

00:01:56.900 --> 00:01:59.060
Хтось експортує дані клієнтів у таблицю.

00:01:59.220 --> 00:02:02.180
Інша людина виправляє кілька рядків і імпортує їх в інше місце.

00:02:02.340 --> 00:02:06.400
Хтось інший вносить нового клієнта в обидві програми, бо ніхто не знає, який запис з'явиться першим.

00:02:06.560 --> 00:02:11.160
Незабаром з'являються дублікати, різні адреси і часу на перевірку даних витрачається більше, ніж на їх використання.

00:02:11.320 --> 00:02:13.300
Все це відбувається не тому, що люди неуважні.

00:02:13.440 --> 00:02:16.100
Це трапляється тому, що системи змушують людей ставати сполучною ланкою.

00:02:16.100 --> 00:02:19.340
Люди копіюють дані. Люди запам'ятовують, який додаток використовувати першим.

00:02:19.480 --> 00:02:22.080
Люди помічають помилки вже після того, як вони потрапили до іншої команди.

00:02:22.200 --> 00:02:25.700
Цей підхід працював, коли бізнес-системи були окремими, а команди змирилися із затримками.

00:02:25.840 --> 00:02:29.940
Але коли відділам продажу, сервісу, фінансів та операцій одночасно потрібна одна й та сама інформація про клієнта,

00:02:30.040 --> 00:02:32.120
електронна таблиця стає поганим інструментом передачі даних.

00:02:32.220 --> 00:02:34.200
Подумайте про просту розмову щодо замовлення.

00:02:34.200 --> 00:02:37.220
Клієнт телефонує у відділ продажу і запитує, чи зможете ви доставити наступного тижня.

00:02:37.320 --> 00:02:38.300
І скільки це коштуватиме?

00:02:38.440 --> 00:02:39.260
Подвійний апостроф.

00:02:39.360 --> 00:02:42.660
Команді продажу потрібні дані про продукт, ціну та наявність на складі, щоб відповісти.

00:02:42.800 --> 00:02:48.120
Коли клієнт погоджується, фінансовому та операційному відділам потрібна правильна інформація про клієнта та замовлення для обробки продажу.

00:02:48.260 --> 00:02:50.200
Обом сторонам потрібні одні й ті самі факти.

00:02:50.380 --> 00:02:53.020
В відділу продажу потрібні ці факти в додатку, де вони працюють.

00:02:53.020 --> 00:02:57.500
Фінансовому та операційному відділам вони потрібні в додатку, де вони керують замовленнями, грошима та доставкою.

00:02:57.640 --> 00:03:01.200
Мета полягає не в тому, щоб змусити кожну команду працювати в одному гігантському інтерфейсі.

00:03:01.320 --> 00:03:04.640
Мета – забезпечити, щоб спільні записи проходили чіткий узгоджений шлях.

00:03:04.800 --> 00:03:07.540
Саме тут на сцену виходить Dual-Ride – подвійний запис.

00:03:07.800 --> 00:03:09.900
Що ж таке насправді Dual-Ride?

00:03:10.160 --> 00:03:11.740
Ось найпростіше визначення.

00:03:11.740 --> 00:03:19.620
Dual-Ride – це вбудоване з'єднання від Microsoft, яке підтримує вибрані дані в синхронізації між додатками Dynamics 365 Finance & Operations та Dataverse.

00:03:19.780 --> 00:03:23.060
Dataverse – це спільна основа даних для багатьох бізнес-додатків Microsoft.

00:03:23.380 --> 00:03:28.180
Її використовують Dynamics 365 Sales, Customer Service, Field Service та частини Project Operations.

00:03:28.340 --> 00:03:30.780
PowerApps та PowerAutomate також можуть її використовувати.

00:03:30.980 --> 00:03:34.420
Вам не потрібно знати, як Dataverse зберігає кожен окремий запис, щоб зрозуміти Dual-Ride.

00:03:34.420 --> 00:03:38.520
Просто сприймайте це як спільну область даних на боці клієнтських додатків Dynamics 365.

00:03:38.520 --> 00:03:41.640
Уявіть офісну будівлю з фронт-офісом та бек-офісом.

00:03:41.780 --> 00:03:47.220
Фронт-офіс займається спілкуванням із клієнтами – продавці, сервісні агенти, виїзні працівники.

00:03:47.500 --> 00:03:51.900
Їм усім потрібні екрани, які допомагають спілкуватися з людьми, відстежувати запити та керувати роботою.

00:03:52.040 --> 00:03:54.940
Бек-офіс займається роботою, яка підтримує функціонування компанії.

00:03:55.100 --> 00:03:58.460
Наші фінансові записи – склад, замовлення, закупівлі, доставка.

00:03:58.460 --> 00:04:04.240
Обидва офіси працюють на одну компанію, але без належного зв'язку між ними хтось має переносити інформацію з одного боку на інший.

00:04:04.400 --> 00:04:08.240
Вони носять роздруковані форми, надсилають електронні листи або копіюють дані в іншу систему.

00:04:08.440 --> 00:04:12.260
Робота все одно виконується, але це займає більше часу, а деталі можуть змінюватися в процесі.

00:04:12.420 --> 00:04:15.640
Dual-Ride – це як внутрішні двері з персоналом між цими двома офісами.

00:04:15.800 --> 00:04:20.540
Коли підтримуваний запис змінюється з одного боку, Dual-Ride передає відповідну зміну через ці двері на інший бік.

00:04:20.540 --> 00:04:22.880
Це не об'єднує всі програми в одну величезну програму.

00:04:23.000 --> 00:04:24.880
Відділ продажів може продовжувати працювати в продажах.

00:04:25.000 --> 00:04:26.940
Фінансовий відділ може продовжувати працювати у фінансах.

00:04:27.080 --> 00:04:31.080
Кожна команда зберігає екрани, створені для її роботи, тоді як обрана спільна інформація залишається пов'язаною з алаштунками.

00:04:31.220 --> 00:04:32.980
Це слово «підтримуваний» має значення.

00:04:33.160 --> 00:04:36.100
Dual-Ride не копіює сліпо кожен фрагмент даних в обох системах.

00:04:36.220 --> 00:04:39.540
Це працює через визначені зв'язки між записами, які належать один одному.

00:04:39.540 --> 00:04:42.540
Microsoft називає ці зв'язки відображеннями таблиць Table Maps.

00:04:42.680 --> 00:04:45.460
Таблиця – це просто місце, де програма зберігає один тип запису.

00:04:45.580 --> 00:04:47.620
Таблиця клієнтів зберігає записи про клієнтів.

00:04:47.720 --> 00:04:49.640
Таблиця продуктів зберігає записи про продукти.

00:04:49.760 --> 00:04:51.800
Таблиця адрес зберігає відомості про адреси.

00:04:51.920 --> 00:04:56.700
Відображення таблиць вказує Dual-Ride, яка таблиця на боці Finance and Operations з'єднується з якою таблицею в Dataverse.

00:04:56.840 --> 00:04:59.360
Уявіть відображення таблиць, яку згоджений лист перекладу.

00:04:59.360 --> 00:05:01.680
Один стовпиць ідентифікує запис з одного боку.

00:05:01.820 --> 00:05:04.480
Інший стовпиць ідентифікує відповідний запис з іншого боку.

00:05:04.640 --> 00:05:07.400
Решта листа пояснює, які поля належать одне до одного.

00:05:07.620 --> 00:05:09.940
Наше ім'я, номер телефону, рядок адреси.

00:05:10.060 --> 00:05:11.860
Ця угода надає правила з'єднання.

00:05:12.040 --> 00:05:15.800
Без неї дві програми можуть використовувати різні мітки або зберігати однакові дані в різних місцях.

00:05:15.960 --> 00:05:18.580
Відображення вказує Dual-Ride, як ці деталі співвідносяться.

00:05:18.760 --> 00:05:21.500
Отже, програмам не потрібна людина, щоб інтерпретувати їх щоразу.

00:05:21.500 --> 00:05:26.620
Часто люди чують назву Dual-Ride і припускають, що це означає, ніби кожна зміна завжди рухається в обидва боки.

00:05:26.760 --> 00:05:27.480
Іноді це так.

00:05:27.680 --> 00:05:32.420
Для підтримуваного двостороннього відображення зміна в Dataverse може оновити відповідний запис у Finance & Operations.

00:05:32.680 --> 00:05:36.580
Підтримувана зміна у Finance & Operations також може оновити відповідний запис у Dataverse.

00:05:36.740 --> 00:05:39.220
Обидві сторони можуть брати участь у тому самому спільному записі.

00:05:39.340 --> 00:05:40.900
Це і є частина, дуал, подвійний.

00:05:41.040 --> 00:05:43.060
Оновлення відбувається майже в режимі реального часу.

00:05:43.060 --> 00:05:47.100
Воно відбувається швидко, поки люди працюють замість очікування запланованого завдання, яке запускається вночі.

00:05:47.240 --> 00:05:52.000
Користувач оновлює підтримуваний запис, і з'єднання надсилає це оновлення, поки робота ще актуальна.

00:05:52.160 --> 00:05:54.980
Майже в реальному часі не означає магію або нульову затримку.

00:05:55.120 --> 00:05:59.160
Це означає, що з'єднання створено для живої бізнес-роботи, а не для обміну файлами раз на день.

00:05:59.320 --> 00:06:03.100
Якщо хтось змінює деталь, відповідній команді не потрібно чекати до завтрашнього ранку, щоб побачити її.

00:06:03.100 --> 00:06:05.100
Це змінює те, як можуть працювати команди.

00:06:05.200 --> 00:06:07.800
Фронт-офіс може використовувати дані, що надходять із бек-офісу.

00:06:07.920 --> 00:06:11.220
Бек-офіс може отримувати підтримувані оновлення від програм, що взаємодіють із клієнтами.

00:06:11.380 --> 00:06:16.080
Dataverse стає основою даних з одного боку, Finance and Operations залишається операційною основою з іншого,

00:06:16.180 --> 00:06:18.640
а Dual-Right підтримує затверджені спільні записи пов'язаними.

00:06:18.800 --> 00:06:21.320
Все ж таки, живі внутрішні двері потребують правил.

00:06:21.480 --> 00:06:25.840
Перш ніж дозволити запису рухатися в обох напрямках, потрібно знати, звідки цей запис має починатися,

00:06:25.840 --> 00:06:29.560
хто може його змінювати і яка сторона має бути головною, коли дві програми не згодні,

00:06:29.700 --> 00:06:32.580
які дані можуть переміщуватися і яка система ними володіє.

00:06:32.740 --> 00:06:35.700
Отже, які записи Dual-Right може підтримувати в синхронізованому стані.

00:06:35.940 --> 00:06:39.600
Найпоширеніші приклади починаються із записів, які багато відділів використовують щодня.

00:06:39.740 --> 00:06:44.360
Записи про клієнтів, адреси, контакти, продукти, постачальники, реквізити компанії

00:06:44.360 --> 00:06:46.880
та довідкова інформація для фінансів і податків.

00:06:47.020 --> 00:06:48.980
Подумайте на мить про запис клієнта.

00:06:48.980 --> 00:06:53.980
Відділу продажів потрібні назва клієнта, основний контакт, номер телефону та адреса доставки.

00:06:54.120 --> 00:06:59.160
Фінансовому відділу потрібні юридичний запис клієнта, платіжні реквізити та інформація для замовлень і рахунків.

00:06:59.300 --> 00:07:01.480
Якщо кожен відділ веде свій окремий список клієнтів,

00:07:01.580 --> 00:07:04.740
компанія витрачає час на порівняння записів замість обслуговування клієнта.

00:07:04.920 --> 00:07:08.780
Завдяки правильним картам Dual-Right ці команди можуть працювати з пов'язаними даними клієнтів.

00:07:08.920 --> 00:07:12.260
Це не означає, що користувачам продажів раптово потрібно вивчати фінансовий додаток.

00:07:18.980 --> 00:07:29.680
Клієнт може мати платіжну адресу, адресу доставки та, можливо, об'єкт, який має відвідати сервісний працівник.

00:07:29.820 --> 00:07:34.820
Ці деталі не можна просто розглядати як звичайний текст, скопіюваний в одне поле, оскільки кожна адреса має свою функцію.

00:07:34.960 --> 00:07:38.160
Dual-Right підтримує спільну структуру записів, необхідну для такого зв'язку.

00:07:38.320 --> 00:07:40.060
Контакти дотримуються тієї ж моделі.

00:07:40.200 --> 00:07:44.180
Одна компанія-клієнт може мати покупця, контактну особу з кредиторської заборгованості та менеджера з обслуговування.

00:07:44.180 --> 00:07:46.360
Відділу продажів потрібно знати, хто приймає рішення.

00:07:46.480 --> 00:07:48.960
Фінансовому відділу потрібно знати, кому адресувати запитання щодо рахунків.

00:07:49.080 --> 00:07:51.280
Сервісному відділу потрібно знати, хто чекає на об'єкті.

00:07:51.360 --> 00:07:56.160
Пов'язані записи допомагають кожній команді бачити людей, пов'язаних із клієнтом, без потреби вводити цю інформацію повторно в кожному додатку.

00:07:56.280 --> 00:07:58.160
Продукти – це ще один поширений приклад.

00:07:58.300 --> 00:08:02.840
Торговий представник повинен знати, що продає компанія, яка вартість продукту та чи є він у наявності.

00:08:02.840 --> 00:08:08.580
Ці відповіді зазвичай надходять з операційної сторони бізнесу, оскільки саме там керують продуктами, запасами, закупівлями та виконанням замовлень.

00:08:08.700 --> 00:08:12.080
Ось чому інформація про продукт часто з'являється у Finance & Operations.

00:08:12.420 --> 00:08:15.080
Операційна команда створює та готує продукт там.

00:08:15.240 --> 00:08:20.940
Коли продукт готовий до роботи з клієнтами, Dual Right може передати відповідні дані про нього в Dataverse.

00:08:21.120 --> 00:08:27.020
Користувачі продажів можуть вибирати та обговорювати продукт у власному додатку без потреби вносити список продуктів в друге.

00:08:27.020 --> 00:08:31.380
Це допомагає будувати розмови з клієнтами на основі того, що бізнес дійсно може надати.

00:08:31.560 --> 00:08:35.600
Дані про ціни та запаси також можуть надходити у відділ продажів через пов'язані додатки.

00:08:35.800 --> 00:08:40.180
Замість того, щоб гадати, чи існує товар, чи змінилася ціна або чи є запас для виконання обіцянки,

00:08:40.320 --> 00:08:43.960
відділ продажів може працювати з інформацією, прив'язаною до операційної системи.

00:08:44.040 --> 00:08:46.540
Це не скасовує потреби в хорошому досвіді продажів.

00:08:46.540 --> 00:08:51.300
Це усуває одну з непотрібних причин, через яку менеджер з продажу дзвонить на склад лише для уточнення основних даних.

00:08:51.460 --> 00:08:54.980
Інформацію про постачальників також можна підключити там, де це потрібно бізнес-процесу.

00:08:55.120 --> 00:09:01.800
Дані про компанію, організаційні структури, фінансові довідкові дані та податкові довідкові дані можуть бути важливими як для клієнтської сторони, так і для операційної.

00:09:01.940 --> 00:09:06.680
Точний перелік записів залежить від додатків і процесів, які використовує компанія, але принцип залишається незмінним.

00:09:06.680 --> 00:09:10.160
Надавайте спільний доступ до записів, які повинні означати одне й те саме в обох місцях.

00:09:10.280 --> 00:09:13.280
Але не варто припускати, що кожен запис має передаватися в обох напрямках.

00:09:13.460 --> 00:09:15.580
Деякі додатки підтримують двостороннє оновлення.

00:09:15.740 --> 00:09:21.000
Зміна може розпочатися в Dataverse і перейти у фінанси і операції, або розпочатися у фінансах і операціях і перейти в Dataverse.

00:09:21.160 --> 00:09:25.540
Такий підхід підходить для записів, де обидві сторони мають вагому бізнес-причину для оновлення затверджених даних.

00:09:25.680 --> 00:09:27.220
Інші карти працюють в один бік.

00:09:27.400 --> 00:09:29.000
Продукти є корисним прикладом.

00:09:29.000 --> 00:09:37.840
У багатьох компаніях фінанси та операції відповідають за створення продукту, оскільки операційний відділ контролює майстердані продукту, запаси, одиниці виміру та інші деталі, необхідні для його продажу і доставки.

00:09:37.960 --> 00:09:42.040
Потім продукт передається в Dataverse, де його можуть використовувати відділи продажу та обслуговування.

00:09:42.200 --> 00:09:43.140
Це чітке правило.

00:09:43.340 --> 00:09:46.440
Продукт не потребує того, щоб дві команди створювали конкуруючі версії.

00:09:46.600 --> 00:09:50.920
Одна сторона створює та керує продуктом, інша сторона отримує та використовує його в межах своєї роботи.

00:09:50.920 --> 00:09:53.100
Кожен спільний запис потребує такого рішення.

00:09:53.100 --> 00:09:54.460
Де бере початок цей запис?

00:09:54.640 --> 00:09:55.820
Хто може його редагувати?

00:09:56.020 --> 00:09:59.660
Якщо назва, адреса, ціна чи класифікація виглядають неправильно, яка команда це виправляє?

00:09:59.800 --> 00:10:02.880
Ці запитання звучать просто, але вони запобігають великій плутанині в майбутньому.

00:10:03.060 --> 00:10:04.960
З'єднання може дуже швидко передати зміну.

00:10:05.100 --> 00:10:08.580
Якщо ніхто не домовився, хто відповідає за цю зміну, вона може так само швидко поширити помилку.

00:10:08.760 --> 00:10:12.480
Виберіть власника для запису та за потреби для окремих деталей у цьому записі.

00:10:12.480 --> 00:10:16.980
Наприклад, відділ продажу може володіти даними про відносини з клієнтом та основною контактною інформацією.

00:10:17.100 --> 00:10:21.140
Фінансовий відділ може відповідати за платіжні деталі, а операційний – за дані про продукти та запаси.

00:10:21.280 --> 00:10:26.840
Ваш точний розподіл залежить від особливостей роботи вашого бізнесу, але це потрібно зафіксувати і довести до відома людей, які використовують додатки.

00:10:26.960 --> 00:10:32.720
Також є два терміни, які ви можете побачити після розширення Dataverse за допомогою DualWrite, сторона – паті та компанія – кампані.

00:10:32.720 --> 00:10:37.040
Сторона – це спосіб Microsoft послідовно працювати з особою або організацією.

00:10:37.180 --> 00:10:44.100
Це допомагає пов'язувати людей, організації, контакти та адреси, не розглядаючи кожне відношення як окремий, непов'язаний запис.

00:10:44.280 --> 00:10:49.140
Компанія допомагає Dataverse розуміти контекст бізнес-компанії, що використовується у фінансах та операціях.

00:10:49.280 --> 00:10:52.080
Вам не обов'язково ставати експертом в обох термінах з першого дня.

00:10:52.080 --> 00:10:59.160
Просто знайте, що вони існують, оскільки Finance & Operations опрацьовує бізнес-структури, які мають розпізнавати клієнтські додатки, коли записи переходять між двома сторонами.

00:10:59.280 --> 00:11:04.460
Коли записи можуть рухатися в обох напрямках, процес навколо цих записів важить так само багато, як і самі дані.

00:11:04.600 --> 00:11:06.460
Як зміни передаються між додатками?

00:11:06.660 --> 00:11:10.360
Давайте простежимо за однією зміною в системі і побачимо, що відбувається насправді.

00:11:10.480 --> 00:11:14.180
Торговий представник спілкується телефоном із клієнтом, який щойно переїхав в новий офіс.

00:11:14.180 --> 00:11:19.500
Під час розмови представник відкриває запис клієнта у Dynamics 365 Sales і оновлює адресу.

00:11:19.620 --> 00:11:20.920
Досить просто, чи не так?

00:11:21.040 --> 00:11:22.440
Потім вони зберігають запис.

00:11:22.660 --> 00:11:24.300
Ось тут починається найцікавіше.

00:11:24.460 --> 00:11:28.420
Sales зберігає цю зміну в Dataverse – це сторона даних для додатків, що взаємодіють з клієнтами.

00:11:28.560 --> 00:11:33.620
Потім DualWrite перевіряє карту, яка пов'язує інформацію про клієнта та адресу між цим сайтом і Finance & Operations.

00:11:33.920 --> 00:11:36.020
Вона автоматично надсилає відповідну зміну.

00:11:36.020 --> 00:11:39.520
Жодних файлів експорту, що лежать у спільній папці в очікуванні, поки хтось їх забере.

00:11:39.660 --> 00:11:43.960
Нікому не потрібно надсилати електронний лист у відділ фінансів із повідомленням «Гей, будь ласка, оновіть цю адресу».

00:11:43.960 --> 00:11:49.820
Карта вже знає, які поля пов'язані, і надсилає підтримувану зміну прямо до відповідного запису клієнта у Finance & Operations.

00:11:50.120 --> 00:11:56.740
Отже, фінансовий користувач може пізніше відкрити запис клієнта, побачити оновлену адресу та опрацювати замовлення або підготувати рахунок без жодної затримки.

00:11:56.740 --> 00:11:58.960
Це практичний результат, просто і зрозуміло.

00:11:59.100 --> 00:12:03.600
Дві людини продовжують працювати в різних додатках, але жодному з них не потрібно переписувати одні й ті самі дані клієнта.

00:12:03.740 --> 00:12:07.000
Торговий представник працює на екрані, розробленому для спілкування з клієнтами.

00:12:07.160 --> 00:12:10.240
Фінансовий користувач працює на екрані, створеному для фінансової роботи.

00:12:10.380 --> 00:12:14.340
Кожна людина бачить інформацію про клієнта, яка їй дійсно потрібна саме там, де вона потрібна.

00:12:14.460 --> 00:12:16.580
І цей шлях працює і в іншому напрямку також.

00:12:16.580 --> 00:12:20.580
Уявіть, що фінанси оновлюють підтримувану інформацію про клієнта у Finance & Operations.

00:12:20.860 --> 00:12:25.020
Скажімо, фінансовий користувач виправляє деталь, яка належить до операційного запису клієнта.

00:12:25.200 --> 00:12:29.620
DualWrite використовує відповідну карту у зворотному напрямку та надсилає це оновлення в Dataverse.

00:12:29.780 --> 00:12:33.820
Тоді Sales, Customer або будь-який інший додаток на базі Dataverse зможе його отримати.

00:12:33.980 --> 00:12:36.820
Це з'єднання є синхронним для звичайної повсякденної роботи.

00:12:36.980 --> 00:12:41.220
Синхронний означає, що додатки намагаються завершити відповідне оновлення як частину того самого моменту роботи,

00:12:41.220 --> 00:12:44.400
а не відкладати його у фонове завдання, яке може запуститися через 20 хвилин.

00:12:44.520 --> 00:12:48.280
Якщо з'єднання не може завершити оновлення, ця проблема потребує негайної уваги,

00:12:48.320 --> 00:12:51.100
а не має тихо ховатися, поки хтось не помітить невідповідність.

00:12:51.220 --> 00:12:53.780
Така поведінка є логічною для спільних бізнес-записів.

00:12:53.940 --> 00:12:57.720
Ви ж не хочете, щоб адреса клієнта, деталі продукту чи інша спільна інформація розходилися годинами через те,

00:12:57.820 --> 00:12:59.140
що пакетне завдання ще не запустилися.

00:12:59.280 --> 00:13:02.400
Люди приймають рішення на основі того, що вони бачать на своєму екрані прямо зараз.

00:13:02.400 --> 00:13:05.520
Отже, з'єднання підтримує взаємодію обох сторон під час роботи.

00:13:05.640 --> 00:13:08.560
Проте робота в реальному часі іноді потребує контрольованої паузи.

00:13:08.680 --> 00:13:11.640
Функція подвійного запису включає опції відтворення, паузи та надолуження.

00:13:11.820 --> 00:13:15.000
Відтворення означає, що карта активна і підтримувані зміни передаються, як зазвичай.

00:13:15.140 --> 00:13:18.260
Пауза тимчасово зупиняє карту, коли команді потрібно виконати планові роботи,

00:13:18.360 --> 00:13:20.240
дослідити проблему або безпечно внести зміни.

00:13:20.360 --> 00:13:22.440
Але пауза – це не постійне місце для зупинки.

00:13:22.440 --> 00:13:26.340
Коли карту призупинено, зміни можуть накопичуватися в черзі протягом обмеженого часу та обсягу.

00:13:26.460 --> 00:13:29.800
Коли робота карти відновлюється, функція надолуження обробляє накопичені зміни.

00:13:29.940 --> 00:13:32.880
Це допомагає командам відновити роботу після запланованої перерви.

00:13:33.040 --> 00:13:36.740
Але хтось має відповідати за цю паузу та знати, коли карту слід запустити знову.

00:13:36.860 --> 00:13:40.820
Перш ніж усе це почнеться в повсякденній роботі, є ще один крок – початкова синхронізація.

00:13:40.960 --> 00:13:44.760
Початкова синхронізація зводить наявні записи з обох сторон до спільної точки відліку.

00:13:44.760 --> 00:13:49.280
Уявіть компанію, яка вже має клієнтів у Finance and Operations і записи про клієнтів у Dataverse.

00:13:49.460 --> 00:13:53.500
З'єднання не може просто вімкнутися і припустити, що кожен наявний запис уже ідеально збігається.

00:13:53.640 --> 00:13:54.860
Потрібна точка старту.

00:13:55.020 --> 00:14:00.160
Початкова синхронізація допомагає перенести наявні дані, перш ніж користувачі покладатимуться на оновлення в реальному часі.

00:14:00.280 --> 00:14:07.380
Ця робота потребує уваги, оскільки дублікати записів, неповні адреси та старі тестові дані не очищаються магічним чином лише через запуск синхронізації.

00:14:07.380 --> 00:14:11.660
Навпаки, вони можуть швидше створювати проблеми, якщо записи не відповідають узгодженим правилам.

00:14:11.780 --> 00:14:16.140
Коли карти запущені відповідальним за подвійний запис, потрібне чітке місце для перевірки стану системи.

00:14:16.240 --> 00:14:22.340
Подвійний запис надає об'єднані журнали активності та помилок, щоб адміністратори могли бачити, що обробило з'єднання і де виникли проблеми.

00:14:22.460 --> 00:14:25.100
Вони також можуть налаштовувати сповіщення та порогові значення.

00:14:25.260 --> 00:14:30.320
Це означає, що потрібні люди дізнаються про проблеми до того, як користувачі виявлять їх через відсутні або невдалі оновлення.

00:14:30.320 --> 00:14:33.460
Такий погляд на підтримку важливий, оскільки кожна помилка має причину.

00:14:33.600 --> 00:14:35.420
Можливо, відсутнє обов'язкове поле.

00:14:35.520 --> 00:14:37.400
Можливо, пов'язаний запис ще не надійшов.

00:14:37.540 --> 00:14:40.160
Можливо, хтось змінив дані у спосіб, що не відповідає карті.

00:14:40.260 --> 00:14:44.780
Повторна спроба обробити помилковий запис без усунення причини зазвичай призводить до такої ж помилки знову.

00:14:44.940 --> 00:14:52.640
Добре налаштована система подвійного запису стежить за з'єднанням, усуває причини помилок і зосереджує карти на записах, які дійсно мають бути пов'язані.

00:14:52.640 --> 00:14:54.700
Де подвійний запис підходить найкраще.

00:14:54.700 --> 00:15:04.240
Подвійний запис найкраще підходить, коли ваш бізнес використовує Dynamics 365 Finance або Supply Chain Management разом із клієнтськими програмами, такими як продажі, обслуговування клієнтів, виїзне обслуговування або управління проектами.

00:15:04.360 --> 00:15:07.440
Ці програми підтримують різні частини одного бізнес-процесу.

00:15:07.580 --> 00:15:13.600
Одна команда спілкується з клієнтом, інша планує доставку, керує запасами, відстежує витрати або надсилає рахунки.

00:15:13.600 --> 00:15:20.740
Коли обом групам потрібно працювати з пов'язаними записами протягом дня, DualWrite може поєднати цю роботу, не змушуючи всіх користуватися одним додатком.

00:15:20.900 --> 00:15:23.680
Візьмемо для прикладу процес від потенційного клієнта до оплати.

00:15:23.840 --> 00:15:27.280
Продавець працює з потенційним клієнтом у Dynamics 365 Sales.

00:15:27.500 --> 00:15:31.780
Він відстежує контакти, обговорює продукти, створює комерційну пропозицію та переходить до замовлення.

00:15:31.780 --> 00:15:39.000
Під час цієї розмови продавцю потрібні дані про клієнта, інформація про продукт, ціни та відомості про замовлення, що стосуються фінансової сторони компанії.

00:15:39.160 --> 00:15:44.680
Коли продаж стає реальним, підрозділ фінансів та управління ланцюгами постачання бере на себе роботу, що виконується після підтвердження домовленостей.

00:15:44.840 --> 00:15:48.460
Він займається виконанням замовлень, виставленням рахунків за складські запаси та фінансовою звітністю.

00:15:48.620 --> 00:15:51.440
DualWrite допомагає цим двом частинам залишатися пов'язаними.

00:15:51.440 --> 00:15:57.880
Продавці можуть працювати в додатку, який відповідає їхнім завданням, тоді як фінансовий та операційний відділи керують транзакцією в додатку, створеному для їхньої роботи.

00:15:58.000 --> 00:16:02.460
Клієнт не перетворюється на дві окремі історії, одну розказану відділом продажів і іншу – фінансовим відділом.

00:16:02.620 --> 00:16:04.480
Field Service – ще один гарний приклад.

00:16:04.620 --> 00:16:09.300
Уявіть компанію, яка відправляє техніків для встановлення, ремонту або обслуговування обладнання на об'єктах клієнтів.

00:16:09.300 --> 00:16:15.380
Працівнику на виїзді потрібні дані про клієнта, деталі роботи та інформація про актив клієнта, який компанія встановила або обслуговує.

00:16:15.520 --> 00:16:20.660
За лаштунками компанія також має відстежувати запчастини, витрати, закупівлі та кошти, пов'язані з цією роботою.

00:16:20.820 --> 00:16:23.500
Field Service зосереджується на плануванні та завершенні візиту.

00:16:23.680 --> 00:16:27.720
Фінансовий та операційний відділи зосереджуються на пов'язаних з цим операційних та фінансових записах.

00:16:27.720 --> 00:16:34.300
Коли ці записи належним чином пов'язані, робота техніка не відокремлена від використаних запчастин, вартості робіт або запису клієнта.

00:16:34.460 --> 00:16:39.140
Project Operations відповідає тій самій моделі, особливо для компаній, що продають роботу за проектами.

00:16:39.280 --> 00:16:44.100
Команда проекту може керувати роботою з клієнтом, часом працівників, запланованими витратами та етапами проекту.

00:16:44.220 --> 00:16:48.780
Фінансовому відділу потрібно бачити фінансовий аспект закупівель, витрат, виставлення рахунків та звітності.

00:16:48.780 --> 00:16:56.640
Без зв'язку менеджери проектів можуть витрачати за багато часу на запити до фінансового відділу, тоді як фінансисти чекають на підтвердження результатів від команд проекту.

00:16:56.760 --> 00:17:02.720
Пов'язані записи проектів дають обом групам чіткіше бачення роботи в міру її переходу від обіцянки клієнту до фінансової активності.

00:17:02.860 --> 00:17:10.740
Тут також є ширша перевага Pava Platform, оскільки сторона клієнтського додатка використовує Dataverse, то затверджені дані в Dataverse можуть підтримувати Pava Apps та Pava Otamate.

00:17:10.740 --> 00:17:16.760
Компанія може створити невеликий додаток для внутрішньої команди або налаштувати потік, що реагує, коли бізнес-запис досягає певної точки.

00:17:16.960 --> 00:17:21.260
Це не означає, що кожен запис фінансового та операційного відділів має автоматично з'являтися в кожному додатку Pava App.

00:17:21.340 --> 00:17:27.700
Це означає, що пов'язані записи можуть стати частиною ширшого набору бізнес-інструментів, якщо компанія ретельно обирає мету та належним чином захищає дані.

00:17:27.800 --> 00:17:29.700
Один кордон має залишатися чітким.

00:17:29.900 --> 00:17:33.060
DualRite не підтримує Dynamics 365 Business Central.

00:17:33.060 --> 00:17:42.020
Business Central може підключатися до інших продуктів Microsoft іншими методами, але DualRite призначено для фінансово-операційного модуля Dynamics 365 та клієнських програм на базі Dataverse.

00:17:42.180 --> 00:17:45.420
Це також не інструмент для копіювання кожної таблиці, яку ви знайдете.

00:17:45.640 --> 00:17:51.380
Запис має переміщуватися тому, що людям потрібен той самий оперативний запис в обох місцях, а не тому, що копіювання даних здається безпечнішим.

00:17:51.520 --> 00:17:58.040
DualRite також не замінює ширший план інтеграції, коли компанії потрібні канали звітності, зв'язки зі сторонніми системами або велика міграція даних.

00:17:58.040 --> 00:18:02.520
Ставлення до кожного підключення даних як до однакового завдання швидко створює проблеми.

00:18:02.880 --> 00:18:05.240
Обмеження, підготовка та типові помилки.

00:18:05.420 --> 00:18:08.960
Уявіть DualRite як рукостискання та домовленість між двома системами.

00:18:09.160 --> 00:18:14.580
Вони погоджуються синхронізувати певні спільні записи, але це не магічний канал для будь-якої таблиці, звіту чи зовнішньої системи.

00:18:14.700 --> 00:18:17.940
Перш ніж налаштовувати його, перевірте, які інтеграції вже існують.

00:18:17.940 --> 00:18:22.820
Якщо старе підключення та DualRite одночасно оновлюють один і той самий запис клієнта, ви можете швидко створити конфлікти.

00:18:22.960 --> 00:18:24.600
Це головний біль, якого ви не хочете.

00:18:24.600 --> 00:18:29.660
Тож спочатку домовтеся про основи, як ви будете вводити імена, яка юридична компанія володіє кожним записом,

00:18:29.820 --> 00:18:33.040
хто може вносити зміни, які ролі безпеки потрібні кожній команді.

00:18:33.200 --> 00:18:35.600
Дублікати та неповні записи перед першою синхронізацією.

00:18:35.780 --> 00:18:37.580
Почніть із попередньо створених карт Microsoft.

00:18:37.880 --> 00:18:39.460
Вони вже пов'язують загальні записи.

00:18:39.640 --> 00:18:41.960
Спеціальні таблиці та поля потребують ретельного тестування.

00:18:42.000 --> 00:18:47.260
Перевіряйте пов'язані таблиці та залежності карт, оскільки іноді один запис потребує існування іншого, перш ніж він зможе синхронізуватися.

00:18:47.260 --> 00:18:49.820
Плануйте першу синхронізацію залежно від обсягу ваших даних.

00:18:49.920 --> 00:18:52.520
Не ставтеся до цього як до вимикача світла, який виклацаєте під час обіду.

00:18:52.640 --> 00:18:53.780
Це спричинить проблеми.

00:18:53.900 --> 00:18:56.540
Призупинена карта все одно потребує власника та плану перезапуску.

00:18:56.660 --> 00:18:59.200
Поставлені в чергу зміни та невдалі записи не зберігаються вічно.

00:18:59.420 --> 00:19:02.580
Стежте за журналами активності, помилками, сповіщеннями та пороговими значеннями.

00:19:02.720 --> 00:19:06.740
Коли щось виходить з ладу, знайдіть відсутнє поле, поганий запис або порушене правило, що стоїть за цим.

00:19:06.740 --> 00:19:08.880
Повторні спроби не виправлять погані дані.

00:19:09.040 --> 00:19:12.720
Коли ви бачите DualRide як контрольований міст, усе стає на свої місця.

00:19:13.200 --> 00:19:15.480
Висновок. Одна спільна бізнес-розмова.

00:19:15.680 --> 00:19:19.700
DualRide забезпечує переміщення підтримуваних спільних записів між фінансами і операціями

00:19:19.700 --> 00:19:21.840
та вашими клієнтськими програмами на базі Dataverse.

00:19:21.980 --> 00:19:25.140
Таким чином, команди можуть працювати з пов'язаними бізнес-даними.

00:19:25.340 --> 00:19:29.380
Підписуйтесь на улюбленій платформі подкастів, щоб отримати більше знань зі мною,

00:19:29.380 --> 00:19:33.960
Мірко Пітерсон на m365.fm і поділіться цим епізодом з тим,

00:19:34.100 --> 00:19:37.760
хто все ще з'єднує продажі, сервіс та фінанси через чергову таблицю.