WEBVTT 00:00:03.860 --> 00:00:06.780 Ласкаво просимо до Microsoft Knowledge Nuggets. 00:00:07.000 --> 00:00:08.000 Я Мірко Петерс. 00:00:08.100 --> 00:00:11.000 Тема сьогоднішнього випуску часто спантили чує людей. 00:00:11.220 --> 00:00:12.400 Що ж таке Dataverse? 00:00:12.580 --> 00:00:15.900 Це база даних, додаток чи якась прихована служба Dynamics 365, 00:00:16.360 --> 00:00:18.220 яку мають розуміти лише IT-фахівці. 00:00:18.400 --> 00:00:19.860 Ось найпростіше визначення. 00:00:20.020 --> 00:00:23.740 Dataverse – це спільна основа даних для багатьох можливостей Dynamics 365. 00:00:24.240 --> 00:00:27.040 Уявіть Dynamics 365 як офісну будівлю. 00:00:27.040 --> 00:00:31.260 Продажі, обслуговування клієнтів та інші програми – це кімнати, де працюють люди, 00:00:31.260 --> 00:00:34.080 а Dataverse – це система картотеки та правила за стінами. 00:00:34.280 --> 00:00:37.220 До кінця цього епізоду ви дізнаєтеся, де зберігаються дані Dynamics 00:00:37.220 --> 00:00:41.340 і як оновлення даних одного клієнта відображається в продажах, автоматизації та звітності. 00:00:41.460 --> 00:00:45.620 Але перш ніж перейти до назв продуктів, почнімо з бізнес-хаосу, який це вирішує. 00:00:46.140 --> 00:00:47.400 Одне спільне місце. 00:00:47.900 --> 00:00:49.140 Замість окремих копій. 00:00:49.320 --> 00:00:53.040 Уявіть компанію з відділом продажів, службою підтримки та фінансовим відділом. 00:00:53.040 --> 00:00:55.360 Відділ продажів веде клієнтську базу в таблиці. 00:00:55.540 --> 00:00:57.800 Служба підтримки працює в окремій системі тікетів. 00:00:57.940 --> 00:01:00.540 Фінанси мають імена клієнтів у своїй власній системі. 00:01:00.680 --> 00:01:05.440 Хтось зберігає листування в спільній пошті, а інший веде нотатки в папці, яку ніхто не може знайти. 00:01:05.600 --> 00:01:08.180 Тепер один і той самий клієнт існує у п'яти місцях. 00:01:08.340 --> 00:01:12.480 Спочатку такий стан речей здається нормальним, бо кожна команда бачить лише свою частину роботи. 00:01:12.480 --> 00:01:17.940 Але річ у тім, щойно клієнт змінює номер телефону, адресу, назву компанії чи контактну особу, починаються проблеми. 00:01:17.940 --> 00:01:22.880 Відділ продажів оновлює таблицю, підтримка цього не бачить, а фінанси продовжують надсилати документи за старою адресою. 00:01:23.040 --> 00:01:29.220 Потім хтось експортує список, вручно очищує його, розсилає електронною поштою, і раптом троє людей вважають свій варіант правильним. 00:01:29.380 --> 00:01:30.660 Якому списку довіряти? 00:01:30.840 --> 00:01:33.100 Це питання забирає більше часу, ніж можна подумати. 00:01:33.260 --> 00:01:35.260 Співробітники зупиняються, щоб звірити записи. 00:01:35.260 --> 00:01:38.140 Менеджери питають, чому звіт не збігається із системою продажів. 00:01:38.140 --> 00:01:42.640 Агент підтримки відкриває справу для клієнта, чиї дані вже є в іншому місці, але з невеликими відмінностями. 00:01:42.800 --> 00:01:44.420 Ніхто не намагається створити хаос. 00:01:44.580 --> 00:01:45.960 Хаос виникає через копії. 00:01:46.140 --> 00:01:51.080 20 років тому окремі системи означали окремі сервери, окремі бази даних і окремі команди, що зберігали власну інформацію. 00:01:51.280 --> 00:01:55.140 Їхнє з'єднання потребувало спеціальної розробки, запланованого імпорту та багаторучної перевірки. 00:01:55.140 --> 00:01:59.240 Зміна в одному місці могла потрапити до іншої системи завтра, наступного тижня або ніколи. 00:01:59.240 --> 00:02:02.820 Dataverse надає бізнес-додаткам спільне місце для такого типу інформації. 00:02:02.980 --> 00:02:07.480 Простими словами, Dataverse – це хмарна платформа даних Microsoft для бізнес-інформації. 00:02:07.700 --> 00:02:11.620 Вона зберігає цю інформацію в структурованих таблицях, тому дані мають чіткий вигляд, 00:02:11.700 --> 00:02:15.560 а не залишаються випадковими нотатками, файлами чи розрізненими вкладками таблиць. 00:02:15.560 --> 00:02:20.520 Можете уявити це як корпоративну шафу для документів, якою можуть одночасно користуватися кілька схвалених інструментів. 00:02:20.640 --> 00:02:22.700 Клієнт з'являється в Dataverse лише один раз. 00:02:22.700 --> 00:02:27.120 Цей клієнт може відображатися в Dynamics 365 Sales, коли менеджер працює над угодою. 00:02:27.260 --> 00:02:32.860 Ті самі дані клієнта можуть з'явитися в Dynamics 365 Customer Service, коли агент опрацьовує запит у службу підтримки. 00:02:32.980 --> 00:02:37.060 PowerApp може використовувати ту саму інформацію про клієнта для виїзного працівника чи менеджера аккаунта 00:02:37.060 --> 00:02:39.500 без необхідності попереднього копіювання даних у новий застосунок. 00:02:39.500 --> 00:02:41.900 Один рядок клієнта – один спільний орієнтир. 00:02:41.980 --> 00:02:44.460 Це не означає, що кожна команда раптом бачить усе. 00:02:44.620 --> 00:02:47.380 Доступ все одно потребує правил, і ми невдовзі до цього перейдемо. 00:02:47.380 --> 00:02:52.880 Це означає, що схвалені застосунки можуть працювати з тією ж бізнес-інформацією, замість того, щоб створювати власні конкуруючі версії. 00:02:53.040 --> 00:02:56.300 Ось чому Dynamics 365 і Dataverse так природно поєднуються. 00:02:56.460 --> 00:03:02.000 Застосунки Dynamics 365, такі як Sales і Customer Service, використовують Dataverse для зберігання та захисту даних, з якими вони працюють. 00:03:02.000 --> 00:03:09.280 Але ось у чому річ. Коли хтось говорить про інтеграцію Dynamics 365 з Dataverse, вони часто уявляють два окремі продукти, яким потрібен конектор між ними. 00:03:09.460 --> 00:03:14.240 Для багатьох застосунків Dynamics 365 це не так. Дані вже знаходяться в Dataverse. 00:03:14.240 --> 00:03:21.020 Ви не витягуєте список клієнтів із Dynamics 365, не копіюєте його в іншу базу даних і не сподіваєтеся, що обидві сторони залишатимуться актуальними. 00:03:21.160 --> 00:03:26.080 Ви можете будувати на тій самій основі, використовуючи ту саму бізнес-інформацію, яку вже використовує Dynamics 365. 00:03:26.080 --> 00:03:31.460 Це змінює суть розмови. Замість того, щоб запитувати, як нам синхронізувати ці два списки клієнтів. 00:03:31.600 --> 00:03:36.660 Ви можете запитати, які люди та застосунки мають працювати з цим записом клієнта і що дозволено робити кожному з них. 00:03:36.660 --> 00:03:47.300 Звісно, Dataverse не замінює кожну систему, яку має компанія. Бізнес може продовжувати використовувати фінансове програмне забезпечення, галузеві інструменти, складські системи, веб-сайти чи старі застосунки, що мають власні дані. 00:03:47.420 --> 00:03:51.100 Dataverse – це не чарівний клей, який миттєво усуває всі сторонні системи. 00:03:51.260 --> 00:03:55.880 Він надає вам спільне місце для бізнес-даних, якими повинні обмінюватися пов'язані застосунки. 00:03:55.880 --> 00:03:59.780 Відомості про клієнтів, продажі, підтримку, завдання та подальші дії. 00:03:59.960 --> 00:04:04.020 Ці записи можуть існувати разом, маючи одне джерело, яке схвалені інструменти можуть читати та оновлювати. 00:04:04.160 --> 00:04:06.420 Тож відкрийте цю шафу для документів разом зі мною. 00:04:06.420 --> 00:04:13.060 Коли ви побачите, як Dataverse впорядковує інформацію всередині, весь зв'язок із Dynamics 365 стане набагато зрозумілішим. 00:04:13.260 --> 00:04:16.700 Шафа для документів, таблиці, рядки, стовпці та зв'язки. 00:04:16.900 --> 00:04:18.400 Давайте відкриємо цю шафу. 00:04:18.540 --> 00:04:20.960 У середині Dataverse інформація розміщується в таблицях. 00:04:25.880 --> 00:04:27.620 А третя – запити в службу підтримки. 00:04:27.780 --> 00:04:31.660 Ви ж не кидаєте кожен папірець в одну величезну шухляду, сподіваючись, що хтось розбереться з цим пізніше. 00:04:31.820 --> 00:04:33.480 Кожна шухляда має своє призначення. 00:04:33.640 --> 00:04:35.940 Отже, у Dataverse таблиця містить один тип бізнес-інформації. 00:04:35.940 --> 00:04:38.660 Таблиця облікових записів зазвичай містить компанії, з якими ви працюєте. 00:04:38.760 --> 00:04:40.600 Таблиця контактів містить окремих людей. 00:04:40.760 --> 00:04:44.300 Таблиця потенційних клієнтів містить дані про них, перш ніж вони стануть реальними клієнтами. 00:04:44.300 --> 00:04:50.540 Таблиця звернень містить запити на підтримку, тоді як таблиця дій відстежує роботу, як от дзвінки, листи, зустрічі та завдання. 00:04:50.720 --> 00:04:52.060 Це стандартні таблиці. 00:04:52.060 --> 00:04:56.780 Microsoft включає їх, оскільки більшості компаній потрібно відстежувати клієнтів, людей, роботу та розмови. 00:04:56.900 --> 00:05:01.060 Вам не потрібно відразу створювати нову таблицю для чогось типового, якщо стандартна таблиця вже підходить для цього. 00:05:01.200 --> 00:05:03.460 Але кожна компанія також має свою специфічну роботу. 00:05:03.600 --> 00:05:06.380 Навчальній компанії може знадобитися відстежувати курси та сертифікати. 00:05:06.380 --> 00:05:09.720 Бізнесу з нерухомості можуть знадобитися дані про будівлі, приміщення та інспекції. 00:05:09.900 --> 00:05:12.900 Виробник може відстежувати перевірки обладнання або сервісні візити. 00:05:12.900 --> 00:05:17.440 У таких випадках ви можете створити власні таблиці, що відповідають діяльності вашої компанії. 00:05:17.580 --> 00:05:21.400 Уявіть власну таблицю, як додавання нової шухляди до шафи з чітким маркуванням. 00:05:21.520 --> 00:05:23.320 Тепер кожна таблиця містить рядки. 00:05:23.500 --> 00:05:25.460 Рядок – це один елемент у цій шухляді. 00:05:25.460 --> 00:05:30.560 Наприклад, один рядок у таблиці контактів може представляти Марію Гомес, людину з компанії-клієнта. 00:05:30.780 --> 00:05:34.480 Її рядок містить її власні дані, відокремлені від усіх інших контактів у системі. 00:05:34.640 --> 00:05:37.520 Стовпці описують деталі, які ви хочете зберегти для кожного рядка. 00:05:37.680 --> 00:05:44.700 Рядок контакту Марії може мати стовпці для її імені, прізвища, адреси електронної пошти, номера телефону, посади, компанії, власника запису та статусу. 00:05:44.700 --> 00:05:47.400 Стовпець визначає тип інформації, що має бути в цьому місці. 00:05:47.400 --> 00:05:51.960 Стовпець електронної пошти очікує адресу, а стовпець статусу може містити варіанти затверджених станів. 00:05:52.080 --> 00:05:54.840 Ось як бізнес-інформація набуває надійної структури. 00:05:55.020 --> 00:06:02.180 Без стовпців одна людина може ввести номер телефону в поле приміток, інша – додати його в поле імені, а хтось інший може взагалі його не внести. 00:06:02.400 --> 00:06:06.580 Завдяки чіткій таблиці контактів усі працюють з однаковим набором даних у тих самих місцях. 00:06:06.580 --> 00:06:09.440 Така структура також допомагає додаткам розуміти ці дані. 00:06:09.440 --> 00:06:15.300 Форма може показувати правильні поля, звіт може групувати контакти за статусом, а автоматизація може реагувати на зміну власника. 00:06:15.480 --> 00:06:20.520 Інформація не просто зберігається, вона має мітки, які повідомляють підключеним інструментам, що означає кожна частина. 00:06:20.640 --> 00:06:23.860 Починайте зі стандартних таблиць, коли вони відповідають вашим бізнес-потребам. 00:06:24.000 --> 00:06:28.420 Якщо ви продаєте компаніям, облікові записи та контакти вже описують шаблон, зрозумілий більшості людей. 00:06:28.420 --> 00:06:31.960 Якщо ви займаєтеся підтримкою клієнтів, звернення дадуть вам точку відліку. 00:06:31.960 --> 00:06:36.700 Додавайте власні таблиці лише тоді, коли ваш бізнес має інформацію, яка не вписується у вбудовані шаблони. 00:06:36.840 --> 00:06:41.720 Це дозволяє уникнути поширеної проблеми, коли створюється п'ять різних таблиць, що означають одне й те саме клієнта. 00:06:41.840 --> 00:06:46.520 Одна команда називається «Клієнт», інша. Основні дані клієнта. Третя – партнерський контакт. 00:06:46.620 --> 00:06:49.680 Невдовзі люди вже не розуміють, яку саме таблицю слід використовувати. 00:06:49.680 --> 00:06:54.660 Чіткі стандартні таблиці та ретельно названі власні таблиці роблять систему зрозумілою для нових користувачів. 00:06:54.800 --> 00:06:57.680 Наступний етап – це коли ці «шухляди» починають працювати разом. 00:06:57.840 --> 00:07:01.900 Контакт належить до облікового запису. Марія працює в компанії «Контосу Ліматад». 00:07:01.900 --> 00:07:05.660 Замість того, щоб знову вводити адресу, основний номер телефону та реквізити Контосу у запис Марії, 00:07:05.800 --> 00:07:09.000 Dataverse може створити зв'язок між таблицею контактів і таблицею облікових записів. 00:07:09.000 --> 00:07:13.720 Марія пов'язана з Контосу, і цей зв'язок важливий, оскільки інформація про компанію залишається разом із компанією. 00:07:13.840 --> 00:07:17.340 Якщо Контосу змінює офісну адресу, достатньо один раз оновити рядок облікового запису, 00:07:17.400 --> 00:07:20.940 і всі пов'язані контакти вказуватимуть на ту саму компанію без зберігання застарілих копій даних. 00:07:21.040 --> 00:07:24.500 Зв'язки також пов'язують запит на підтримку з клієнтом, який його надіслав. 00:07:24.640 --> 00:07:29.480 Вони можуть пов'язати торгову можливість із дзвінками, листами, зустрічами та завданнями щодо цієї угоди. 00:07:29.480 --> 00:07:32.780 Коли продавець відкриває можливість, він бачить пов'язану з нею активність, 00:07:32.880 --> 00:07:35.960 замість того, щоб шукати її в непов'язаних нотатках чи календарях. 00:07:36.320 --> 00:07:37.840 Інформація отримує контекст. 00:07:38.020 --> 00:07:41.700 Ви не просто бачите номер запиту, ви бачите, якому клієнту він належить. 00:07:41.840 --> 00:07:45.860 Ви не просто переглядаєте контакт, ви бачите компанію, пов'язану з цією людиною. 00:07:46.000 --> 00:07:50.580 Ці зв'язки роблять дані корисними, позбавляючи від потреби повторно вводити одні і ті самі факти в різних місцях. 00:07:50.580 --> 00:07:54.740 Маленьке зауваження щодо термінології, перш ніж ви почнете читати старі посібники чи дивитися давніші відео. 00:07:54.860 --> 00:07:57.380 Ви можете почути слова «сутність поле» та «запис». 00:07:57.380 --> 00:07:58.980 Це застарілі терміни Dataverse. 00:07:59.140 --> 00:08:04.340 Microsoft тепер використовує таблиця «замість сутність стовпець», «замість поле» та «рядок», «замість запис». 00:08:04.340 --> 00:08:05.680 Значення не змінилося. 00:08:05.880 --> 00:08:10.640 Отже, старий посібник, який радить створити «сутність», насправді каже про створення таблиці, 00:08:10.780 --> 00:08:13.040 «поле» – це стовпець, а «запис» – це рядок. 00:08:13.040 --> 00:08:17.200 Розуміння обох варіантів термінів береже вас від думки, що ви знайшли інший продукт. 00:08:17.240 --> 00:08:20.440 Отже, таблиці впорядковують інформацію, а зв'язки об'єднують її. 00:08:20.560 --> 00:08:23.040 Але навіть добре впорядкована «шафа» потребує контролю. 00:08:23.200 --> 00:08:27.160 Хтось має вирішувати, що користувачі можуть вводити, змінювати та до чого вони мають безпечний доступ. 00:08:27.300 --> 00:08:29.020 Це як правила та стіл реєстрації. 00:08:29.020 --> 00:08:33.240 Дані в Dataverse працюють ефективно лише тоді, коли потрібні люди мають до них безпечний доступ. 00:08:33.240 --> 00:08:38.260 Менеджеру з продажу потрібні дані клієнта, агенту підтримки, історія звернень, керівнику – ширший огляд, 00:08:38.380 --> 00:08:41.060 а зовнішньому партнеру може бути потрібен лише обмежений доступ. 00:08:41.240 --> 00:08:43.480 Вони не повинні бачити однакову інформацію. 00:08:43.640 --> 00:08:48.540 Уявіть запис клієнта з приватною нотаткою, узгодженою ціною та відкритим запитом у службу підтримки. 00:08:48.540 --> 00:08:51.540 Надання всім користувачам повного доступу швидко створить ризики. 00:08:51.680 --> 00:08:55.160 Надто суворі обмеження, через які працівники не можуть виконувати роботу, створюють іншу проблему. 00:08:55.160 --> 00:08:59.340 Dataverse надає вам засоби контролю для цього, і перший елемент контролю починається з ідентифікації. 00:08:59.500 --> 00:09:03.380 Коли ви входите за допомогою свого робочого облікового запису, Microsoft EntraID ідентифікує вас. 00:09:03.520 --> 00:09:06.220 Уявіть EntraID як стійку реєстрації на вході в офіс. 00:09:06.360 --> 00:09:10.220 Ви приходите, показуєте перепустку, і адміністратор перевіряє, хто ви, перш ніж ви зможете увійти. 00:09:10.220 --> 00:09:13.860 Dataverse використовує цю ідентифікацію, щоб знати, який саме користувач працює з даними. 00:09:13.980 --> 00:09:16.660 Система не обмежується запитанням, чи дозволено цій людині вхід. 00:09:16.660 --> 00:09:19.800 Вона також запитує, що цій людині дозволено робити після входу. 00:09:19.960 --> 00:09:22.020 Саме тут у гру вступають ролі безпеки. 00:09:22.200 --> 00:09:25.840 Роль безпеки – це набір дозволів, прив'язаних до посади або обов'язків. 00:09:26.020 --> 00:09:30.460 Ви можете створити одну роль для відділу продажів, іншу – для агентів підтримки, а третю – для керівників. 00:09:30.460 --> 00:09:32.760 Кожна роль може контролювати доступ до таблиці. 00:09:32.940 --> 00:09:37.720 Наприклад, менеджер з продажу може читати, створювати та оновлювати облікові записи, контакти, ліди та угоди. 00:09:37.900 --> 00:09:40.820 Їм може бути заборонено видаляти важливу інформацію про клієнтів. 00:09:40.960 --> 00:09:44.880 Агент підтримки може створювати й оновлювати звернення, але не змінювати угоди з продажу. 00:09:45.100 --> 00:09:48.400 Дозволи можуть охоплювати читання, створення, зміну та видалення рядків. 00:09:48.540 --> 00:09:52.660 Це означає, що доступ не залежить від того, чи пам'ятає хтось, які кнопки приховати в кожному додатку. 00:09:52.660 --> 00:09:54.520 Дозволи закріплені за самими даними. 00:09:54.680 --> 00:09:57.800 Отже, однакові обмеження діють всюди, де з'являються ці дані Dataverse. 00:09:57.960 --> 00:09:59.920 Потім ви можете звузити доступ ще більше. 00:09:59.920 --> 00:10:03.620 Безпека на рівні рядків визначає, з якими окремими рядками може працювати людина. 00:10:03.780 --> 00:10:06.140 Менеджер з продажу може бачити лише свої клієнтські записи, 00:10:06.260 --> 00:10:08.940 тоді як керівник відділу бачити рядки всіх учасників команди. 00:10:09.080 --> 00:10:11.480 Обидва використовують одну і ту саму таблицю облікових записів. 00:10:11.580 --> 00:10:13.540 Проте вони бачать різні частини цієї таблиці. 00:10:13.540 --> 00:10:17.420 Така структура допомагає людям зосередитися на своїй роботі, надаючи керівникам необхідний огляд. 00:10:17.420 --> 00:10:21.620 Це також зменшує ймовірність того, що хтось відкриє дані клієнта, до яких немає доступу. 00:10:21.780 --> 00:10:24.360 Деяка інформація потребує ще суворішого захисту. 00:10:24.500 --> 00:10:27.600 Безпека на рівні стовпців може захистити окремі стовпці в таблиці. 00:10:27.760 --> 00:10:31.080 Можливо, користувач може відкрити рядок клієнта, але не повинен бачити ідентифікатор, 00:10:31.080 --> 00:10:33.780 зарплату, банківські реквізити чи конфіденційні фінансові нотатки. 00:10:33.920 --> 00:10:36.860 Рядок клієнта залишається доступним для виконання потрібної роботи. 00:10:37.020 --> 00:10:39.100 Захищений стовпець залишається обмеженим. 00:10:39.100 --> 00:10:43.320 Для великих компаній бізнес-підрозділи можуть створювати межі між різними частинами організації. 00:10:43.500 --> 00:10:47.960 Компанія може відокремлювати регіони, відділи або філії, що працюють з різними групами клієнтів. 00:10:48.120 --> 00:10:51.300 Бізнес-підрозділи допомагають сформувати правила доступу в межах цих кордонів. 00:10:51.300 --> 00:10:54.300 Це не означає, що кожному бізнесу потрібна складна схема безпеки. 00:10:54.420 --> 00:10:56.820 Малій команді може бути достатньо лише кількох чітких ролей. 00:10:56.820 --> 00:11:00.960 Більшій компанії може знадобитися більше рівнів, оскільки її команди, регіони та обов'язки відрізняються. 00:11:01.180 --> 00:11:04.520 Суть у тому, що Dataverse може адаптувати доступ до того, як бізнес працює насправді. 00:11:04.660 --> 00:11:09.240 Контроль доступу захищає те, хто може отримати дані, але правила також захищають якість самих даних. 00:11:09.240 --> 00:11:13.340 Бізнес-правило може вимагати від когось введення номера телефону перед збереженням нового контакту. 00:11:13.500 --> 00:11:16.660 Воно може перевіряти умову, наприклад, вимагати причину закриття звернення. 00:11:16.660 --> 00:11:20.220 Воно також може змінювати те, що бачать користувачі залежно від введеної ними інформації. 00:11:20.380 --> 00:11:23.380 Це ж правило застосовується в усіх програмах, які використовують цю таблицю. 00:11:23.520 --> 00:11:27.640 Це важливо, оскільки ви не хочете, щоб одна програма приймала неповні дані, а інша відхиляла їх. 00:11:27.640 --> 00:11:31.520 Правило належить до бізнес-інформації, а не до конкретного екрана, на якому вона відображається. 00:11:31.680 --> 00:11:36.080 Dataverse також може виконувати логіку у фоновому режимі, щоб допомогти підтримувати узгодженість бізнес-процесів. 00:11:36.200 --> 00:11:38.140 Деталь, яку варто запам'ятати, проста. 00:11:38.140 --> 00:11:41.040 Дані надходять разом із правилами, а не просто як сховище. 00:11:41.200 --> 00:11:46.780 Отже, фундамент включає інформацію людей, які мають право працювати з нею, і правила, що роблять її придатною до використання. 00:11:46.780 --> 00:11:53.080 Коли Dynamics 365 працює на тій самій основі, їй не потрібен традиційний міст лише для доступу до власних бізнес-даних. 00:11:53.220 --> 00:11:59.880 Що насправді означає інтеграція Dynamics 365, більшість людей чують інтеграція Dynamics 365 з Dataverse 00:11:59.880 --> 00:12:02.460 і уявляють дві окремі системи, з'єднані конектором. 00:12:02.460 --> 00:12:10.420 Одна система зберігає дані клієнтів, іншій потрібна копія, тому хтось налаштовує синхронізацію, чекає її завершення і сподівається, що нічого не зламається. 00:12:10.420 --> 00:12:13.400 Така картина має сенс для багатьох бізнес-інструментів. 00:12:13.520 --> 00:12:20.660 Але тут TMS для Dynamics 365 Sales та Dynamics 365 Customer Service зв'язок набагато тісніший. 00:12:20.820 --> 00:12:23.960 Ці програми використовують Dataverse як спільний фундамент даних. 00:12:24.040 --> 00:12:28.300 Це не дві окремі бази даних, що обмінюються рядками клієнтів, щоб зрозуміти одна одну. 00:12:28.500 --> 00:12:31.520 Вони працюють тією самою бізнес-інформацією від самого початку. 00:12:31.520 --> 00:12:33.960 Давайте розглянемо це на конкретному прикладі. 00:12:34.080 --> 00:12:38.960 Уявіть, що ви продавець і створюєте нову компанію в Dynamics 365 Sales. 00:12:39.160 --> 00:12:42.440 Ви додаєте головний контакт і починаєте працювати над потенційною угодою. 00:12:42.580 --> 00:12:45.820 Ці деталі миттєво стають частиною спільних даних, які використовує програма. 00:12:45.940 --> 00:12:48.380 Пізніше цей клієнт звертається до служби підтримки. 00:12:48.560 --> 00:12:51.960 Агент підтримки може працювати з тими самими даними про компанію та контакт. 00:12:52.000 --> 00:12:56.680 Нікому не потрібно експортувати список із продажів або створювати клієнта знову в окремому інструменті підтримки. 00:12:56.680 --> 00:13:02.140 Агент просто підв'язує звернення до цього клієнта і бачить історію, яка допомагає зрозуміти, що ТМС відбувається. 00:13:02.280 --> 00:13:06.600 Відділ продажів бачить угоду, служба підтримки, звернення, і обидві команди працюють з одним і тим самим клієнтом. 00:13:06.760 --> 00:13:11.680 Це зовсім не означає, що всі екрани мають виглядати однаково, або кожна команда повинна дотримуватися ідентичного процесу. 00:13:11.820 --> 00:13:14.620 Для продажів потрібні ліди, можливості, дзвінки та зустрічі. 00:13:14.760 --> 00:13:18.040 Для обслуговування клієнтів потрібні звернення, черги та історія обслуговування. 00:13:18.040 --> 00:13:22.180 Кожен додаток Dynamics 365 надає інструменти, адаптовані до конкретної роботи. 00:13:22.280 --> 00:13:30.560 Хоча бізнес-інформація може поєднуватися за потреби, саме ця спільна основа мається на увазі, коли говорять про інтеграцію Dynamics 365 і Dataverse. 00:13:30.740 --> 00:13:39.720 Справа не лише в перенесенні даних з точки, а в точку будинок головне – це робота додатків з одними і тими самими рядками, зв'язками, правилами та контролем доступу від самого початку. 00:13:39.920 --> 00:13:42.240 Давайте розглянемо простий шлях продажу. 00:13:42.240 --> 00:13:44.820 Лід надходить з вебсайту або після заходу. 00:13:44.820 --> 00:13:50.920 Менеджер з продажу працює з цим лідом, дізнається більше про людину та перетворює лід на клієнтські відносини і можливість. 00:13:51.080 --> 00:13:54.960 Дзвінки, електронні листи, зустрічі та завдання – усе це можна пов'язати з цією роботою. 00:13:55.080 --> 00:13:58.760 Тож команді не потрібно шукати інформацію в різних інструментах, щоб зібрати все докупи. 00:13:58.900 --> 00:14:03.280 Якщо клієнту згодом знадобиться допомога, звернення до служби підтримки можна пов'язати з тим самим клієнтом. 00:14:03.440 --> 00:14:06.780 Агент підтримки бачить не просто ім'я та адресу електронної пошти. 00:14:06.780 --> 00:14:10.380 Він працює в контексті вже визначених стосунків із клієнтом. 00:14:10.560 --> 00:14:17.260 Тим часом відділ продажів бачить, що у клієнта є відкрите звернення і не йде на переговори про поновлення, не знаючи про проблему. 00:14:17.420 --> 00:14:24.000 Одне клієнтське відношення підтримує різні види роботи, що набагато корисніше, ніж просто зберігати однакові імена клієнтів у двох системах. 00:14:24.120 --> 00:14:27.780 Ви також можете почути термін «Command Data Model», іноді скорочено «CDM». 00:14:27.780 --> 00:14:31.260 Нехай ця назва не здається вам чимось занадто загадковим. 00:14:31.400 --> 00:14:38.680 Це просто означає, що Microsoft надає загальні шаблони бізнес-таблиць для того, що відстежують багато компаній, аккаунти, контакти, дії та звернення. 00:14:38.820 --> 00:14:43.220 Ці шаблони дають додаткам на базі Dynamics 365 та Dataverse спільну початкову мову. 00:14:43.320 --> 00:14:44.840 Акаунт означає компанію. 00:14:44.980 --> 00:14:46.420 Контакт означає людину. 00:14:46.640 --> 00:14:48.980 Дія відстежує роботу навколо бізнес-відносин. 00:14:49.140 --> 00:14:55.280 Ви можете налаштувати систему під свою компанію та додавати власні таблиці за потреби, але вам більше не доведеться щоразу починати з чистого аркуша. 00:14:55.280 --> 00:15:01.500 Коли один додаток розуміє таблицю аккаунтів, а інший використовує ту саму таблицю, обидва звертаються до одного типу бізнес-інформації. 00:15:01.660 --> 00:15:04.060 Це також змінює можливості того, що ви можете створити. 00:15:04.220 --> 00:15:09.320 Припустімо, вашій виїзній команді потрібен простий додаток, щоб знайти клієнта, підтвердити візит і додати нотатку після зустрічі. 00:15:09.440 --> 00:15:13.980 Ви можете створити Pava App, який працюватиме з тими ж таблицями Dataverse, що вже використовується в Dynamics 365. 00:15:13.980 --> 00:15:17.880 Немає потреби експортувати клієнтів у новий список лише для цього застосунку. 00:15:18.020 --> 00:15:22.060 Виїзний працівник відкриває застосунок, знаходить клієнта і оновлює інформацію про візит. 00:15:22.220 --> 00:15:29.080 Дані залишаються пов'язаними з відносинами з клієнтами, які вже використовують відділ продажів або обслуговування, згідно з правилами безпеки, про які ми говорили раніше. 00:15:29.240 --> 00:15:32.440 Для більш структурованої бізнес-роботи можна створити керований моделью застосунок. 00:15:32.580 --> 00:15:34.980 Керований моделью застосунок починається з моделі даних. 00:15:34.980 --> 00:15:40.080 Ви обираєте таблиці Dataverse, визначаєте їхні зв'язки, налаштовуєте форми і представлення та застосовуєте ролі безпеки. 00:15:40.180 --> 00:15:43.720 Потім PowerApps використовує цю структуру для створення робочого бізнес-застосунку. 00:15:43.880 --> 00:15:47.800 Уявіть це як організацію верстака з інструментами та матеріалами, які ваша команда реально використовує. 00:15:47.940 --> 00:15:50.820 Таблиці описують роботу, а зв'язки поєднують її елементи. 00:15:51.040 --> 00:15:53.360 Форми дозволяють людям вводити та переглядати дані. 00:15:53.520 --> 00:15:56.380 Представлення допомагають їм знаходити рядки, що потребують уваги. 00:15:56.380 --> 00:15:59.220 Безпека визначає, що кожна особа може відкривати чи змінювати. 00:15:59.360 --> 00:16:03.780 Керований моделью застосунок може працювати поряд із Dynamics 365, оскільки обидва працюють з Dataverse. 00:16:03.940 --> 00:16:11.600 Можливо, Dynamics 365 Sales керує повним процесом продажів, тоді як менший керований моделью застосунок дає менеджерам із контрактів зручне місце для відстеження угод. 00:16:11.720 --> 00:16:15.740 Обидва можуть працювати з пов'язаними даними клієнтів без створення другої бази даних клієнтів. 00:16:15.920 --> 00:16:18.360 Звісно, такий доступ все одно потребує обережності. 00:16:18.360 --> 00:16:24.960 Те, що застосунок може працювати з таблицею Dataverse, не означає, що кожен користувач має редагувати кожен рядок або бачити кожну колонку. 00:16:25.140 --> 00:16:28.680 Ролі, доступ до рядків та бізнес-правила все ще контролюють те, що відбувається. 00:16:28.840 --> 00:16:35.040 Польовий застосунок може надати користувачу саме ті дані клієнта та дії, які йому потрібні, не розкриваючи решту даних компанії. 00:16:35.220 --> 00:16:40.840 Отже, інтеграція Dynamics 365 із Dataverse тепер більше не є кабелем, що з'єднує дві віддалені кімнати. 00:16:40.840 --> 00:16:46.480 Застосунки Dynamics 365, власні застосунки та бізнес-процеси можуть працювати на основі одного спільного фундаменту. 00:16:46.600 --> 00:16:49.440 Коли ви це бачите, наступне питання стає зрозумілим. 00:16:49.620 --> 00:16:54.540 Як ще можна використовувати це ж оновлення клієнта на підключеній платформі Microsoft? 00:16:54.920 --> 00:16:57.580 Як підключена платформа працює в реальній роботі? 00:16:57.760 --> 00:17:01.660 Спільне оновлення клієнта стає корисним, коли інструменти навколо нього можуть реагувати. 00:17:01.820 --> 00:17:07.420 Pava Otomite бере на себе подальшу роботу, відстежуючи зміни в рядку Dataverse і запускаючи дію, коли така зміна відбувається. 00:17:07.420 --> 00:17:10.920 Наприклад, новий лід потрапляє в Dynamics 365 Sales. 00:17:11.080 --> 00:17:16.100 Потік може сповістити призначеного продавця, опублікувати повідомлення в Teams або створити завдання для подальшої дії. 00:17:16.280 --> 00:17:18.980 Нікому не потрібно весь день стежити за спільною поштовою скринькою. 00:17:19.160 --> 00:17:22.140 Лід змінюється і наступний крок запускається автоматично. 00:17:22.320 --> 00:17:26.640 Pava Otomite не потребує окремої копії ліда лише для виконання цієї роботи. 00:17:26.800 --> 00:17:31.940 Він може реагувати на рядок у Dataverse, використовуючи ті самі дані про клієнта та власника, які використовує застосунок для продажу. 00:17:31.940 --> 00:17:38.200 Це утримує автоматизацію близько до бізнес-процесу, замість того, щоб покладатися на когось, хто має експортувати файл і запускати ручний ланцюжок електронних листів. 00:17:38.340 --> 00:17:39.260 Далі – Pava BI. 00:17:39.500 --> 00:17:42.380 Менеджеру з продажів може знадобитися переглянути поточний конвейер. 00:17:42.500 --> 00:17:50.020 Керівнику служби підтримки клієнтів може знадобитися побачити, скільки звернень надійшло цього тижня, які з них залишаються відкритими або які клієнти звертаються до підтримки найчастіше. 00:17:50.020 --> 00:17:57.500 Pava BI може звітувати за бізнес-даними Dataverse, тому команди можуть бачити результати роботи без створення свіжих експортів у таблиці щоп'ятниці. 00:17:57.700 --> 00:18:00.020 Звіт базується на бізнес-даних, які люди вже використовують. 00:18:00.700 --> 00:18:04.020 Це означає, що графік конвейера може змінюватися в міру просування можливостей. 00:18:04.180 --> 00:18:08.000 Інформаційна панель звернень може показувати поточне навантаження, поки агенти оновлюють випадки. 00:18:08.200 --> 00:18:12.040 Суть тепер у тому, що інформаційна панель замінює ручну перевірку деталей людьми. 00:18:12.040 --> 00:18:16.340 Вона дає їм чіткіше уявлення про роботу, перш ніж вони вирішать, що потребує уваги. 00:18:16.440 --> 00:18:19.220 Pava Apps додає ще один шлях до того самого процесу. 00:18:19.340 --> 00:18:22.300 Уявіть, що виїзний працівник прибуває на об'єкт клієнта. 00:18:22.500 --> 00:18:26.000 Їм не потрібен повний функціонал Dynamics 365 Sales. 00:18:26.240 --> 00:18:31.900 Їм може знадобитися лише знайти клієнта, переглянути деталі візиту, підтвердити, що сталося, і додати примітку або фото. 00:18:32.240 --> 00:18:35.320 Спеціалізований застосунок Pava App може надати їм такий спрощений досвід. 00:18:35.320 --> 00:18:38.680 Команді по роботі з клієнтами може знадобитися застосунок для перегляду клієнтських угод. 00:18:38.800 --> 00:18:41.440 Менеджеру може знадобитися простий застосунок для схвалення запиту. 00:18:41.600 --> 00:18:46.080 Кожен застосунок може зосереджуватися на одній роботі, працюючи з тією ж контрольованою інформацією Dataverse за лаштунками. 00:18:46.220 --> 00:18:48.760 Людина бачить інструмент, який відповідає її повсякденним завданням. 00:18:48.900 --> 00:18:50.720 Бізнес зберігає зв'язну інформацію. 00:18:50.900 --> 00:18:53.380 Іноді ця інформація бере початок за межами Dataverse. 00:18:53.380 --> 00:18:57.580 Компанія може мати список з онлайн-джерела, який має стати частиною її бізнес-даних. 00:18:57.680 --> 00:19:04.520 Pava Query може завантажувати дані з підтримуваних онлайн-джерел, очищати їх під час імпорту та завантажувати у потрібну таблицю Dataverse. 00:19:04.700 --> 00:19:09.980 Це корисно, коли зовнішнє джерело містить інформацію, яку мають використовувати ваші інструменти Dynamics та Pava Platform. 00:19:10.200 --> 00:19:14.880 Вам все одно потрібно вирішити, що саме належить до Dataverse і як це має підключатися до існуючих таблиць. 00:19:14.880 --> 00:19:18.660 Імпорт даних без таких роздумів просто переносить плутанину в нове місце. 00:19:18.660 --> 00:19:21.760 Нехай Отем об'єднає ці частини в один повсякденний потік. 00:19:21.900 --> 00:19:28.200 Новий лід потрапляє в Dynamics 365 і правило призначення перевіряє, хто має відповідати за нього, можливо, на основі регіону або продукту. 00:19:28.340 --> 00:19:32.500 Власник отримує повідомлення в Teams через потік Pava Automate, тож він знає, що робота чекає. 00:19:32.660 --> 00:19:39.500 Коли менеджер з продажу оновлює лід і просуває його через процес продажу, інформаційна панель Pava BI змінюється, показуючи команді поточний стан конвейера. 00:19:39.500 --> 00:19:42.240 Одне оновлення запускає корисну роботу в кількох місцях. 00:19:42.240 --> 00:19:44.860 Pava Automate переміщує роботу з одного кроку на інший. 00:19:44.980 --> 00:19:47.260 Pava BI допомагає людям бачити результати роботи. 00:19:47.380 --> 00:19:50.280 Pava Apps надають окремим командам спеціалізований спосіб для роботи. 00:19:50.420 --> 00:19:54.760 Dataverse тримає бізнес-інформацію впорядкованою та захищеною, поки ці інструменти виконують свої завдання. 00:19:54.920 --> 00:19:56.300 Ця різниця має значення. 00:19:56.680 --> 00:20:00.740 Автоматизація – це не система зберігання файлів, а інформаційна панель – не база даних клієнтів. 00:20:00.740 --> 00:20:04.160 Кожен інструмент має окрему функцію, але всі вони можуть працювати з одного джерела. 00:20:04.160 --> 00:20:10.660 Розуміння цього допомагає вибрати правильний інструмент, замість того, щоб використовувати кожну таблицю чи простий список для керування цілим бізнес-процесом. 00:20:11.760 --> 00:20:14.240 Коли Dataverse підходить і чого він не замінює? 00:20:14.560 --> 00:20:15.460 Ось у чому річ. 00:20:15.640 --> 00:20:19.600 Вибирайте Dataverse, коли багато користувачів і додатків повинні працювати з пов'язаними бізнес-даними. 00:20:19.780 --> 00:20:22.340 Вам потрібні чіткі правила доступу та повторювані процеси. 00:20:22.340 --> 00:20:25.100 Dataverse цим справляється, але він не замінює все інше. 00:20:25.220 --> 00:20:28.420 Excel залишається найкращим вибором для особистого аналізу та швидких списків. 00:20:28.420 --> 00:20:31.340 Списки SharePoint добре підходять для простого командного відстеження. 00:20:31.480 --> 00:20:35.400 А якщо ви розробник, якому потрібен глибокий контроль, SQL залишається надійним вибором. 00:20:35.440 --> 00:20:37.260 Отже, коли Dataverse справді підходить. 00:20:37.380 --> 00:20:42.580 Коли ваші дані мають з'єднуватися між додатками Dynamics 365, автоматизацією та звітами без створення копій. 00:20:42.700 --> 00:20:44.400 Ось де він проявляє себе найкраще. 00:20:44.560 --> 00:20:45.520 Але висновок. 00:20:45.520 --> 00:20:48.000 Одна основа – багато бізнес-інструментів. 00:20:48.120 --> 00:20:49.560 Отже, основний підсумок. 00:20:49.560 --> 00:20:56.760 Dynamics 365 та Dataverse працюють найкраще, коли всі ваші дані, правила, безпека, додатки, автоматизація та звіти мають спільну основу. 00:20:56.860 --> 00:21:04.620 Підписуйтесь на Microsoft Knowledge Nuggets на m365.fm, щоб отримувати більше зрозумілих інструкцій щодо Dynamics 365, Pava Platform та Microsoft 365. 00:21:04.620 --> 00:21:09.960 Потім подивіться наш епізод про керовані моделью додатки, щоб побачити, як таблиці Dataverse перетворюються на робочий бізнес-додату.