WEBVTT

00:00:00.000 --> 00:00:02.060
Ласкаво просимо до Microsoft Knowledge Nuggets.

00:00:02.260 --> 00:00:03.180
Я Мо Пітерс.

00:00:03.320 --> 00:00:05.800
Сьогоднішня тема часто викликає запитання.

00:00:05.980 --> 00:00:07.320
Що саме таке Dataverse?

00:00:07.480 --> 00:00:10.760
Це база даних, додаток чи якась прихована служба Dynamics 365,

00:00:11.240 --> 00:00:13.080
яку мають розуміти лише IT-фахівці.

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

00:00:14.880 --> 00:00:18.640
Dataverse – це спільна основа даних для багатьох можливостей Dynamics 365.

00:00:19.140 --> 00:00:21.960
Уявіть Dynamics 365 як офісну будівлю.

00:00:22.100 --> 00:00:26.100
Продажі, обслуговування клієнтів та інші додатки – це кабінети, де працюють люди,

00:00:26.220 --> 00:00:28.920
а Dataverse – це система архівування та правила за стінами.

00:00:28.920 --> 00:00:32.180
Наприкінці цього епізоду ви дізнаєтеся, де зберігаються дані Dynamics

00:00:32.180 --> 00:00:36.240
і як оновлення інформації про клієнта з'являється в продажах, автоматизації та звітності.

00:00:36.360 --> 00:00:39.720
Але перш ніж перейти до назв продуктів, почнімо з робочого безладу.

00:00:39.880 --> 00:00:42.060
Це вирішується одним спільним місцем.

00:00:42.500 --> 00:00:45.360
Замість окремих копій уявіть компанію з відділом продажів,

00:00:45.500 --> 00:00:47.580
службою підтримки та фінансовим відділом.

00:00:47.760 --> 00:00:50.440
Відділ продажів тримає дані клієнтів у електронній таблиці.

00:00:50.600 --> 00:00:52.640
Підтримка працює в окремій системі тікетів.

00:00:52.640 --> 00:00:55.300
Фінанси мають імена клієнтів у своїй власній системі.

00:00:55.400 --> 00:00:57.860
Хтось інший зберігає листування у спільній поштовій скринці,

00:00:57.960 --> 00:01:00.380
а ще хтось веде нотатки в папці, яку ніхто не може знайти.

00:01:00.540 --> 00:01:02.900
Один і той самий клієнт тепер існує у п'яти місцях.

00:01:03.060 --> 00:01:04.820
Спочатку така організація здається нормальною,

00:01:04.880 --> 00:01:07.100
бо кожен відділ бачить лише ту частину роботи, яка перед ними.

00:01:07.240 --> 00:01:08.220
Але ось у чому річ.

00:01:08.380 --> 00:01:10.860
Як тільки клієнт змінює номер телефону, адресу, назву компанії

00:01:10.860 --> 00:01:12.520
або головний контакт, починаються проблеми.

00:01:12.520 --> 00:01:14.240
Відділ продажів оновлює таблицю.

00:01:14.360 --> 00:01:15.600
Підтримка цього не бачить.

00:01:15.700 --> 00:01:18.100
Фінанси продовжують надсилати документи на стару адресу.

00:01:18.220 --> 00:01:20.320
Тоді хтось експортує список, вручну його виправляє,

00:01:20.420 --> 00:01:22.860
розсилає електронною поштою і раптом троє людей вважають,

00:01:22.980 --> 00:01:24.240
що саме їхня копія правильна.

00:01:24.360 --> 00:01:25.540
Якому списку вірити?

00:01:25.700 --> 00:01:28.040
Це питання забирає більше часу, ніж ви могли б подумати.

00:01:28.200 --> 00:01:30.100
Персонал зупиняється, щоб звірити записи.

00:01:30.240 --> 00:01:33.000
Менеджери запитують, чому звіт не збігається з системою продажів.

00:01:33.000 --> 00:01:34.940
Агент підтримки відкриває справу для клієнта,

00:01:35.040 --> 00:01:37.520
чиї дані вже лежать де-інде, просто з невеликими відмінностями.

00:01:37.680 --> 00:01:39.320
Ніхто не намагається створити хаос.

00:01:39.480 --> 00:01:40.880
Хаос виникає через копії.

00:01:41.040 --> 00:01:43.280
20-ть років тому окремі системи означали окремі сервери,

00:01:43.360 --> 00:01:45.980
окремі бази даних і окремі команди, що зберігали власну інформацію.

00:01:46.120 --> 00:01:48.220
Для їхнього з'єднання потрібна була індивідуальна розробка,

00:01:48.320 --> 00:01:50.060
запланований імпорт і багаторучної перевірки.

00:01:50.240 --> 00:01:52.640
Зміна в одному місці могла дійти до іншої системи завтра,

00:01:52.640 --> 00:01:54.040
наступного тижня або ніколи.

00:01:54.040 --> 00:01:57.620
Dataverse надає бізнес-додаткам спільне місце для такого типу інформації.

00:01:57.780 --> 00:02:02.340
Простими словами, Dataverse – це хмарна платформа даних Microsoft для бізнес-інформації.

00:02:02.580 --> 00:02:04.900
Вона зберігає цю інформацію в структурованих таблицях,

00:02:05.000 --> 00:02:07.780
тому дані мають чітку форму, а не існують як випадкові нотатки,

00:02:07.920 --> 00:02:10.380
окремі файли чи розрізнені вкладки в електронних таблицях.

00:02:10.540 --> 00:02:12.400
Можна уявити це як корпоративну картотеку,

00:02:12.400 --> 00:02:15.340
якою можуть одночасно користуватися кілька схвалених інструментів.

00:02:15.440 --> 00:02:17.580
Клієнт з'являється в Dataverse лише один раз.

00:02:17.580 --> 00:02:22.000
Цей клієнт може відображатися в Dynamics 365 Sales, коли менеджер працює над угодою.

00:02:22.160 --> 00:02:25.600
Ті самі дані клієнта можуть з'явитися в Dynamics 365 Customer Service,

00:02:25.740 --> 00:02:27.700
коли агент опрацьовує запит у службу підтримки.

00:02:27.840 --> 00:02:30.800
Pava App може використовувати ту саму інформацію про клієнта для виїзного працівника

00:02:30.800 --> 00:02:34.280
або менеджера облікового запису без необхідності попереднього копіювання даних у новий застосунок.

00:02:34.280 --> 00:02:36.740
Один рядок клієнта – одна спільна точка відліку.

00:02:36.880 --> 00:02:39.340
Це не означає, що кожна команда раптом бачить усе.

00:02:39.340 --> 00:02:42.280
Доступ все одно потребує правил, і невдовзі ми до цього перейдемо.

00:02:42.420 --> 00:02:45.920
Це означає, що схвалені застосунки можуть працювати з однією бізнес-інформацією

00:02:45.920 --> 00:02:47.700
замість створення власних конкурентних версій.

00:02:47.860 --> 00:02:51.140
Ось чому Dynamics 365 і Dataverse так природно поєднуються.

00:02:51.320 --> 00:02:54.020
Застосунки Dynamics 365, такі як Sales і Customer Service,

00:02:54.120 --> 00:02:56.540
використовують Dataverse для зберігання та захисту даних, з якими вони працюють.

00:02:56.540 --> 00:02:57.660
Але ось у чому річ.

00:02:57.800 --> 00:03:00.920
Коли хтось говорить про інтеграцію Dynamics 365 з Dataverse,

00:03:01.040 --> 00:03:04.180
вони часто уявляють два окремі продукти, яким потрібен конектор між ними.

00:03:04.180 --> 00:03:07.400
Для багатьох застосунків Dynamics 365 це не так.

00:03:07.580 --> 00:03:09.100
Дані вже знаходяться в Dataverse.

00:03:09.280 --> 00:03:11.600
Ви не витягуєте список клієнтів з Dynamics 365,

00:03:12.020 --> 00:03:14.100
щоб скопіювати його в іншу базу даних і сподіватися,

00:03:14.220 --> 00:03:15.880
що обидві сторони залишаться актуальними.

00:03:16.020 --> 00:03:17.580
Ви можете будувати на тому самому фундаменті,

00:03:17.660 --> 00:03:19.260
використовуючи ту саму бізнес-інформацію,

00:03:19.380 --> 00:03:21.020
яку вже використовує Dynamics 365.

00:03:21.020 --> 00:03:22.980
Це змінює предмет розмови.

00:03:23.120 --> 00:03:26.160
Замість питання, як нам синхронізувати ці два списки клієнтів.

00:03:26.160 --> 00:03:29.840
Ви можете запитати, які люди та застосунки мають працювати з цим записом клієнта

00:03:29.840 --> 00:03:31.380
і що дозволено робити кожному з них.

00:03:31.540 --> 00:03:34.800
Звісно, Dataverse не замінює кожну систему, якою володіє компанія.

00:03:35.000 --> 00:03:37.740
Бізнес може і надалі використовувати фінансове програмне забезпечення,

00:03:37.880 --> 00:03:40.940
галузеві інструменти, складські системи, веб-сайти чи старі застосунки,

00:03:41.040 --> 00:03:42.120
що зберігають власні дані.

00:03:42.120 --> 00:03:46.000
Dataverse – це немагічний клей, який миттєво усуває всі зовнішні системи.

00:03:46.140 --> 00:03:48.100
Він надає спільне місце для бізнес-даних,

00:03:48.100 --> 00:03:50.680
які мають використовувати підключені застосунки.

00:03:51.000 --> 00:03:54.780
Дані клієнтів – робота з продажами, підтримка, завдання та подальші дії.

00:03:54.980 --> 00:03:56.740
Ці записи можуть співіснувати в одному джерелі,

00:03:56.820 --> 00:03:59.100
яке схвалені інструменти можуть вчитувати та оновлювати.

00:03:59.260 --> 00:04:01.260
Отже, відкрийте зі мною цю картотеку.

00:04:01.260 --> 00:04:05.040
Щойно ви побачите, як Dataverse впорядковує інформацію всередині,

00:04:05.120 --> 00:04:09.180
весь зв'язок з Dynamics 365 стане набагато легше зрозуміти.

00:04:09.340 --> 00:04:11.520
Таблиці, рядки, стовпці та зв'язки.

00:04:11.700 --> 00:04:13.380
Давайте відкриємо цю картотеку.

00:04:13.380 --> 00:04:15.960
У середині Dataverse інформація розміщується в таблицях.

00:04:16.100 --> 00:04:18.640
Уявіть це як справжню шафу з окремими висувними шухлядами.

00:04:18.780 --> 00:04:20.980
В одній шухляді зберігаються компанії, в іншій – люди,

00:04:21.080 --> 00:04:22.640
а в третій – запити до служби підтримки.

00:04:22.800 --> 00:04:25.080
Ви ж не кидаєте всі папери в одну величезну шухляду в надії,

00:04:25.200 --> 00:04:26.400
що хтось потім їх розсортує.

00:04:26.400 --> 00:04:28.260
У кожної шухляди є своє призначення.

00:04:28.400 --> 00:04:30.760
Отже, у Dataverse таблиця містить один тип бізнес-інформації.

00:04:30.760 --> 00:04:33.480
Таблиця облікових записів зазвичай містить компанії, з якими ви працюєте.

00:04:33.600 --> 00:04:35.380
Таблиця контактів містить окремих людей.

00:04:35.540 --> 00:04:37.920
Таблиця потенційних клієнтів Ліди зберігає дані про них до того,

00:04:38.020 --> 00:04:39.280
як вони стануть реальними покупцями.

00:04:39.420 --> 00:04:41.300
Таблиця звернень містить запити на підтримку,

00:04:41.300 --> 00:04:45.400
а таблиця дій може відстежувати роботу, як-от дзвінки, листи, зустрічі та завдання.

00:04:45.560 --> 00:04:46.900
Це стандартні таблиці.

00:04:47.060 --> 00:04:50.400
Microsoft включає їх, оскільки більшості компаній потрібно відстежувати клієнтів,

00:04:50.520 --> 00:04:51.720
людей, роботу та спілкування.

00:04:51.880 --> 00:04:54.400
Вам не потрібно починати зі створення нової таблиці для чогось типового,

00:04:54.500 --> 00:04:55.920
якщо стандартна вже підходить для цього.

00:04:56.080 --> 00:04:58.340
Але кожна компанія також має свою специфічну роботу.

00:04:58.340 --> 00:05:01.380
Тренінговій компанії може знадобитися відстеження курсів і сертифікатів.

00:05:01.500 --> 00:05:04.580
Компанії з нерухомості можуть знадобитися будівлі, об'єкти та перевірки.

00:05:04.740 --> 00:05:07.740
Виробник може відстежувати перевірки обладнання або сервісні візити.

00:05:07.900 --> 00:05:10.060
У таких випадках ви можете створити власні таблиці,

00:05:10.220 --> 00:05:12.300
які відповідають реальній роботі вашої компанії.

00:05:12.480 --> 00:05:16.240
Уявіть власну таблицю, як додавання нової шухляди до шафи з чітким маркуванням.

00:05:16.360 --> 00:05:18.180
Тепер кожна таблиця містить рядки.

00:05:18.180 --> 00:05:20.320
Рядок – це один елемент у цій шухляді.

00:05:20.480 --> 00:05:23.880
Наприклад, один рядок у таблиці контактів може представляти Марію Гомес,

00:05:24.000 --> 00:05:25.380
людину з компанії-клієнта.

00:05:25.600 --> 00:05:29.320
Її рядок містить її власні дані, відокремлені від усіх інших контактів у системі.

00:05:29.320 --> 00:05:32.380
Стовпці описують деталі, які ви хочете зберегти для кожного рядка.

00:05:32.520 --> 00:05:36.340
Рядок контакту Марії може мати стовпці для її імені, прізвища, адреси електронної пошти,

00:05:36.460 --> 00:05:39.360
номера телефону, посади, компанії, власника запису та статусу.

00:05:39.360 --> 00:05:42.280
Стовпець визначає тип інформації, яка має бути в цьому місці.

00:05:42.420 --> 00:05:44.480
Отже, стовпець електронної пошти очікує адресу,

00:05:44.520 --> 00:05:46.920
а стовпець статусу може містити затверджені варіанти статусу.

00:05:47.080 --> 00:05:49.840
Саме так бізнес-інформація набуває надійної структури.

00:05:49.840 --> 00:05:53.520
Без стовпців один працівник може ввести номер телефону в поле приміток,

00:05:53.640 --> 00:05:56.960
інший – у поле імені, а хтось інший може взагалі його не ввести.

00:05:56.960 --> 00:06:01.400
З чіткою таблицею контактів усі працюють з однаковим набором даних у тих самих місцях.

00:06:01.560 --> 00:06:04.140
Ця структура також допомагає програмам розуміти дані.

00:06:04.280 --> 00:06:07.700
Форма може показувати потрібні поля, звіт може групувати контакти за статусом,

00:06:07.780 --> 00:06:09.980
а автоматизація може реагувати на зміну власника.

00:06:10.260 --> 00:06:12.020
Інформація не просто зберігається десь.

00:06:12.020 --> 00:06:15.580
Вона має мітки, які повідомляють підключеним інструментам, що означає кожна частина.

00:06:15.700 --> 00:06:18.820
Починайте зі стандартних таблиць, коли вони відповідають потребам вашого бізнесу.

00:06:18.940 --> 00:06:22.100
Якщо ви продаєте компаніям, облікові записи та контакти вже описують модель,

00:06:22.220 --> 00:06:23.220
зрозуміло, більшості людей.

00:06:23.400 --> 00:06:26.880
Якщо ви займаєтеся підтримкою клієнтів, звернення стануть для вас відправною точкою.

00:06:27.020 --> 00:06:30.220
Потім додавайте власні таблиці лише тоді, коли у вашому бізнесі є інформація,

00:06:30.320 --> 00:06:31.720
що не вписується у вбудовані моделі.

00:06:31.720 --> 00:06:34.940
Це дозволяє уникнути поширеної проблеми, коли створюється п'ять різних таблиць,

00:06:35.040 --> 00:06:36.640
що означають одне й те саме клієнта.

00:06:36.780 --> 00:06:40.020
Одна команда називається «Клієнт», інша – «Основні дані клієнта»,

00:06:40.020 --> 00:06:41.380
третя – «Контакт партнера».

00:06:41.380 --> 00:06:44.440
Невдовзі люди вже не можуть розібратися, яку таблицю слід використовувати.

00:06:44.620 --> 00:06:48.120
Зрозумілі стандартні таблиці та ретельно названі власні таблиці роблять структуру зрозумілою

00:06:48.120 --> 00:06:49.580
для інших під час розширення системи.

00:06:49.580 --> 00:06:52.420
Наступний етап – це коли ці «шухляди» починають працювати разом.

00:06:52.540 --> 00:06:54.480
Контакт належить до облікового запису.

00:06:54.620 --> 00:06:56.460
Марія працює в компанії «Контосо».

00:06:56.460 --> 00:07:00.540
Замість того, щоб знову вводити адресу, основний номер телефону та реквізити компанії «Контосо» у запис Марії,

00:07:00.680 --> 00:07:03.860
Dataverse може створити зв'язок між таблицею контактів і таблицею облікових записів.

00:07:03.960 --> 00:07:08.160
Марія пов'язана з «Контосо», і цей зв'язок важливий, оскільки інформація про компанію залишається прикріпленою до неї.

00:07:08.160 --> 00:07:11.620
Якщо в «Контосо» змінюється адреса офісу, хтось один раз оновлює рядок облікового запису.

00:07:11.740 --> 00:07:15.920
Усі пов'язані контакти продовжують вказувати на одну і ту саму компанію, не зберігаючи власну застарілу копію.

00:07:16.060 --> 00:07:19.300
Зв'язки також з'єднують запит на підтримку з клієнтом, який його подав.

00:07:19.440 --> 00:07:24.400
Вони можуть пов'язати торговельну можливість із дзвінками, електронними листами, зустрічами та завданнями щодо цієї угоди.

00:07:24.400 --> 00:07:30.740
Коли продавець відкриває можливість, він бачить пов'язану з нею активність, замість того, щоб шукати її в непов'язаних нотатках і календарях.

00:07:31.100 --> 00:07:32.340
Інформація має контекст.

00:07:32.540 --> 00:07:34.300
Ви дивитеся не просто на номер справи.

00:07:34.440 --> 00:07:36.660
Ви бачите, до якого клієнта вона належить.

00:07:36.780 --> 00:07:38.560
Ви не просто переглядаєте контакт.

00:07:38.620 --> 00:07:40.900
Ви бачите компанію, пов'язану з цією особою.

00:07:41.060 --> 00:07:45.440
Ці зв'язки роблять дані корисними без необхідності багаторазового введення одних і тих самих фактів у різних місцях.

00:07:45.440 --> 00:07:49.620
Одна невелика примітка щодо термінології перед тим, як ви читатимете старі посібники або дивитиметеся старі відео.

00:07:49.740 --> 00:07:52.280
Ви можете почути слова «сутність поле» та «запис».

00:07:52.280 --> 00:07:53.740
Це старі терміни Dataverse.

00:07:53.900 --> 00:07:59.160
Microsoft тепер використовує таблиця «замість сутність стовпець», «замість поле» та «рядок», «замість запис».

00:07:59.160 --> 00:08:00.520
Значення не змінилося.

00:08:00.680 --> 00:08:05.560
Тож, якщо в старому посібнику сказано «створити сутність», це означає створення таблиці.

00:08:05.720 --> 00:08:07.940
Поле – це стовпець, а запис – це рядок.

00:08:07.940 --> 00:08:12.200
Розуміння обох варіантів термінів береже вас від думки, що ви знайшли інший продукт.

00:08:12.280 --> 00:08:15.220
Отже, таблиці впорядковують інформацію та зв'язки між нею.

00:08:15.340 --> 00:08:18.040
Але добре впорядкована шафа все одно потребує контролю.

00:08:18.200 --> 00:08:22.000
Хтось має вирішувати, що користувачі можуть вводити, змінювати та до чого мають безпечний доступ.

00:08:22.160 --> 00:08:24.360
Це правила та стіл реєстрації для даних.

00:08:24.460 --> 00:08:27.400
Спільні дані ефективні лише тоді, коли потрібні люди можуть безпечно з ними працювати.

00:08:27.520 --> 00:08:29.340
Торговому представнику потрібні дані клієнта.

00:08:29.340 --> 00:08:31.300
Агенту підтримки потрібна історія запитів.

00:08:31.300 --> 00:08:32.940
Керівнику потрібен ширший огляд.

00:08:33.080 --> 00:08:36.260
А зовнішньому партнеру може знадобитися доступ лише до невеликої частини процесу.

00:08:36.380 --> 00:08:38.640
Вони не повинні бачити одну і ту саму інформацію.

00:08:38.780 --> 00:08:43.380
Уявіть запис клієнта з приватною нотаткою, узгодженою ціною та відкритим запитом на підтримку.

00:08:43.560 --> 00:08:46.380
Надання всім користувачам повного доступу швидко створило бризики.

00:08:46.580 --> 00:08:50.060
Надто жорсткі обмеження, через які люди не можуть виконувати свою роботу, створюють іншу проблему.

00:08:50.240 --> 00:08:52.020
Dataverse надає вам засоби контролю для цього.

00:08:52.020 --> 00:08:54.180
Перший засіб контролю починається з ідентифікації.

00:08:54.180 --> 00:08:58.280
Коли ви входите у систему зі своїм корпоративним обліковим записом, Microsoft EntraID ідентифікує вас.

00:08:58.400 --> 00:09:01.120
Уявіть EntraID як стійку реєстрації на вході в офіс.

00:09:01.280 --> 00:09:05.100
Ви приходите, показуєте свій бейдж, і реєстратор перевіряє, хто ви, перш ніж ви зможете увійти.

00:09:05.280 --> 00:09:08.780
Dataverse використовує цю ідентифікацію, щоб знати, який саме користувач працює з даними.

00:09:08.920 --> 00:09:11.540
Це не обмежується лише питанням, чи дозволено цій людині вхід.

00:09:11.660 --> 00:09:14.660
Це також запитує, що цій людині дозволено робити після входу.

00:09:14.660 --> 00:09:16.840
Саме тут у гру вступають ролі безпеки.

00:09:16.840 --> 00:09:20.680
Роль безпеки – це набір дозволів, пов'язаних із роботою або обов'язками.

00:09:20.880 --> 00:09:25.380
Ви можете створити одну роль для торгового персоналу, іншу для агентів служби підтримки, а третю для менеджерів.

00:09:25.520 --> 00:09:27.600
Кожна роль може контролювати доступ до таблиці.

00:09:27.760 --> 00:09:32.640
Наприклад, торговому представнику може бути дозволено читати, створювати й оновлювати облікові записи, контакти, ліди та можливості.

00:09:32.820 --> 00:09:35.640
Їм може бути заборонено видаляти важливу інформацію про клієнтів.

00:09:35.640 --> 00:09:39.860
Агент підтримки може створювати та оновлювати звернення, але не може змінювати торгову можливість.

00:09:40.040 --> 00:09:43.240
Дозволи можуть охоплювати читання, створення, зміну та видалення рядків.

00:09:43.380 --> 00:09:47.380
Це означає, що доступ не залежить від того, чи пам'ятає хтось, які кнопки слід приховати в кожному додатку.

00:09:47.560 --> 00:09:49.540
Дозволи зберігаються разом із самими даними.

00:09:49.700 --> 00:09:52.680
Отже, однакові правила діють всюди, де відображаються дані Dataverse.

00:09:52.820 --> 00:09:54.680
Потім ви можете ще більше звузити доступ.

00:09:54.860 --> 00:09:58.340
Безпека на рівні рядків визначає, з якими окремими рядками може працювати людина.

00:09:58.340 --> 00:10:03.840
Торговий представник може бачити лише власних клієнтів, тоді як менеджер з продажу може бачити рядки клієнтів усієї своєї команди.

00:10:03.960 --> 00:10:06.420
Обидві особи використовують одну і ту саму таблицю облікових записів.

00:10:06.600 --> 00:10:08.440
Вони просто не бачать одну і ту саму її частину.

00:10:08.580 --> 00:10:12.180
Таке налаштування допомагає людям зосередитися на власній роботі, надаючи менеджерам потрібний огляд.

00:10:12.320 --> 00:10:16.580
Це також зменшує ймовірність того, що хтось відкриє інформацію про клієнта, до якої немає жодного стосунку.

00:10:16.740 --> 00:10:19.180
Деяка інформація потребує ще суворішого захисту.

00:10:19.180 --> 00:10:22.560
Безпека на рівні стовпців може захистити окремі стовпці всередині таблиці.

00:10:22.700 --> 00:10:28.600
Можливо, користувач може відкрити рядок клієнта, але не повинен бачити персональний ідентифікатор, зарплату, банківські реквізити чи приватну фінансову примітку.

00:10:28.740 --> 00:10:31.580
Рядок клієнта залишається доступним для виконання необхідної роботи.

00:10:31.740 --> 00:10:34.140
Захищений стовпець залишається обмеженим для перегляду.

00:10:34.300 --> 00:10:38.100
Для великих компаній бізнес-одиниці можуть створювати межі між частинами організації.

00:10:38.100 --> 00:10:42.980
Компанія може розділяти регіони, підрозділи або дочірні компанії, що працюють з різними групами клієнтів.

00:10:43.100 --> 00:10:46.160
Бізнес-одиниці допомагають формувати спосіб доступу через ці межі.

00:10:46.260 --> 00:10:49.140
Це не означає, що кожному бізнесу потрібна складна карта безпеки.

00:10:49.260 --> 00:10:51.720
Невеликій команді може знадобитися лише кілька чітких ролей.

00:10:51.860 --> 00:10:55.820
Великій компанії може знадобитися більше рівнів через відмінності в командах, регіонах та обов'язках.

00:10:56.020 --> 00:10:59.360
Суть у тому, що Dataverse може адаптувати доступ до того, як насправді працює бізнес.

00:10:59.360 --> 00:11:04.140
Контроль доступу захищає від того, хто може отримати дані, але правила також захищають якість самих даних.

00:11:04.240 --> 00:11:08.220
Бізнес-правило може вимагати від когось введення номера телефону перед збереженням нового контакту.

00:11:08.440 --> 00:11:11.600
Воно може перевірити умову, наприклад, вимагати причину при закритті звернення.

00:11:11.820 --> 00:11:15.200
Воно також може змінювати те, що бачать користувачі на основі введеної ними інформації.

00:11:15.380 --> 00:11:18.200
Це саме правило діє в усіх програмах, що використовують цю таблицю.

00:11:18.340 --> 00:11:22.480
Це важливо, оскільки ви не хочете, щоб одна програма приймала неповні дані, а інша відхиляла їх.

00:11:22.480 --> 00:11:26.360
Правило належить до бізнес-інформації, а не до одного екрана, на якому вона відображається.

00:11:26.540 --> 00:11:30.820
Dataverse також може виконувати логіку у фоновому режимі, щоб забезпечити послідовність бізнес-процесів.

00:11:30.980 --> 00:11:32.940
Деталь, яку варто запам'ятати, проста.

00:11:33.160 --> 00:11:35.880
Дані надходять разом із правилами, а не просто як сховище.

00:11:36.020 --> 00:11:41.560
Отже, фундамент включає інформацію, людей, яким дозволено з нею працювати, і правила, що підтримують її придатність до використання.

00:11:41.560 --> 00:11:48.000
Коли Dynamics 365 працює на тому самому фундаменті, їй не потрібен традиційний міст лише для доступу до власних бізнес-даних.

00:11:48.140 --> 00:11:57.340
Що насправді означає інтеграція Dynamics 365, більшість людей чують, інтеграція Dynamics 365 з Dataverse, і уявляють дві окремі системи, з'єднані конектором.

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

00:12:05.480 --> 00:12:08.200
Ця картина має сенс для багатьох бізнес-інструментів.

00:12:08.200 --> 00:12:15.480
Але ось у чому справа. Для Dynamics 365 Sales та Dynamics 365 Customer Service зв'язок набагато тісніший.

00:12:15.640 --> 00:12:18.880
Ці програми використовують Dataverse як свій спільний фундамент даних.

00:12:19.020 --> 00:12:23.240
Це не окремі бази даних, що передають записи клієнтів туди-сюди, лише щоб порозумітися.

00:12:23.240 --> 00:12:27.580
Вони працюють з однією і тією ж бізнес-інформацією від самого початку. Ось приклад.

00:12:29.540 --> 00:12:33.960
Ви – менеджер із продажів і створюєте нову компанію в Dynamics 365 Sales.

00:12:34.160 --> 00:12:37.320
Ви додаєте головний контакт і починаєте працювати над потенційною угодою.

00:12:37.320 --> 00:12:40.720
Ці деталі миттєво стають частиною спільних даних, які використовує програма.

00:12:40.820 --> 00:12:43.300
Пізніше цей клієнт звертається до служби підтримки.

00:12:43.500 --> 00:12:46.640
Агент підтримки може працювати з тими ж даними компанії та контакту.

00:12:46.820 --> 00:12:51.520
Нікому не потрібно експортувати список із продажів або створювати клієнта знову в окремому інструменті підтримки.

00:12:51.520 --> 00:12:56.720
Агент просто підключає звернення до цього клієнта і бачить історію, яка допомагає зрозуміти, що відбувається.

00:12:56.880 --> 00:12:58.380
Відділ продажів бачить угоду.

00:12:58.380 --> 00:13:01.640
Відділ підтримки бачить звернення і обидві команди працюють з одним клієнтом.

00:13:01.800 --> 00:13:06.520
Це не означає, що кожен екран виглядає ідентично або кожна команда дотримується одного і того самого процесу.

00:13:06.660 --> 00:13:09.580
Відділу продажів потрібні ліди, можливості, дзвінки та зустрічі.

00:13:09.580 --> 00:13:12.840
Служба підтримки клієнтів потребує звернень, черг та історії обслуговування.

00:13:13.000 --> 00:13:16.640
Кожен додаток Dynamics 365 надає людям інструменти, створені для їхньої роботи.

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

00:13:20.020 --> 00:13:25.700
Ця спільна основа – це те, що люди часто мають на увазі, коли говорять про інтеграцію Dynamics 365 та Dataverse.

00:13:25.860 --> 00:13:33.720
Це не лише перенесення даних з точки А в точку будинок, це про те, як додатки працюють з одними і тими самими рядками, зв'язками, правилами та контролем доступу.

00:13:33.860 --> 00:13:37.340
Для початку дозвольте офісам пройти через простий шлях продажу.

00:13:37.560 --> 00:13:39.660
Лід надходить з вебсайту або заходу.

00:13:39.820 --> 00:13:45.800
Продавець працює з цим лідом, дізнається більше про людину та перетворює лід на клієнтські відносини та можливість.

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

00:13:49.960 --> 00:13:53.660
Отже, команді не потрібно шукати в окремих інструментах, щоб зібрати історію докупи.

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

00:13:58.340 --> 00:14:01.680
Агент підтримки не просто бачить ім'я та адресу електронної пошти.

00:14:01.860 --> 00:14:05.320
Він може працювати в контексті вже визначених клієнтських відносин.

00:14:05.320 --> 00:14:12.040
Тим часом відділ продажів бачить, що у клієнта є відкрита проблема і може уникнути розмови про поновлення, не знаючи про минулі труднощі.

00:14:12.180 --> 00:14:15.040
Одні клієнтські відносини можуть підтримувати різні види роботи.

00:14:15.160 --> 00:14:18.820
Це набагато корисніше, ніж просто мати однакове ім'я клієнта у двох системах.

00:14:18.960 --> 00:14:23.100
Ви також можете почути термін «Спільна модель даних – Command Data Model», іноді скорочену CDM.

00:14:23.240 --> 00:14:26.140
Не дозволяйте назві звучати таємничіше, ніж є насправді.

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

00:14:33.700 --> 00:14:37.880
Ці шаблони дають додаткам на базі Dynamics 365 та Dataverse спільну мову для старту.

00:14:38.020 --> 00:14:39.820
Обліковий запис означає компанію.

00:14:39.960 --> 00:14:41.380
Контакт означає людину.

00:14:41.580 --> 00:14:43.900
Дія відстежує роботу навколо ділових відносин.

00:14:44.060 --> 00:14:50.200
Ви можете налаштувати систему для своєї компанії та додавати власні таблиці, де потрібно, але вам не обов'язково щоразу починати з чистого аркуша.

00:14:50.200 --> 00:14:56.800
Коли один додаток розуміє таблицю облікових записів, а інший використовує ту саму таблицю, обидва звертаються до одного типу бізнес-даних.

00:14:56.900 --> 00:14:58.780
Це також змінює можливості розробки.

00:14:58.900 --> 00:15:04.180
Припустимо, вашій виїздній команді потрібен простий додаток, щоб знайти клієнта, підтвердити візит і додати нотатку після зустрічі.

00:15:04.300 --> 00:15:08.760
Ви можете створити Pava App, який працює з тими самими таблицями Dataverse, що вже використовується в Dynamics 365.

00:15:09.180 --> 00:15:12.600
Немає потреби експортувати клієнтів у новий список лише для цього додатка.

00:15:12.600 --> 00:15:16.960
Працівник на виїзді відкриває додаток, знаходить клієнта та оновлює інформацію про візит.

00:15:17.060 --> 00:15:24.000
Дані залишаються пов'язаними з клієнтськими відносинами, які вже використовує відділ продажів або обслуговування, згідно з правилами безпеки, про які ми говорили раніше.

00:15:24.180 --> 00:15:27.280
Для більш структурованих бізнес-завдань ви можете створити модельний додаток.

00:15:27.460 --> 00:15:29.620
Модельний додаток починається з моделі даних.

00:15:29.740 --> 00:15:34.880
Ви обираєте таблиці Dataverse, визначаєте їхні зв'язки, налаштовуєте форми і представлення та призначаєте ролі безпеки.

00:15:34.880 --> 00:15:38.400
PowerApps потім використовує цю структуру для створення робочого бізнес-додатку.

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

00:15:42.580 --> 00:15:45.860
Таблиці описують роботу. Зв'язки поєднують окремі елементи.

00:15:46.060 --> 00:15:48.460
Форми дають людям місце для введення та перегляду деталей.

00:15:48.600 --> 00:15:51.380
Представлення допомагають їм знаходити рядки, що потребують уваги.

00:15:51.500 --> 00:15:54.120
Безпека вирішує, що кожна людина може відкривати чи змінювати.

00:15:54.120 --> 00:15:58.700
Модельний додаток може працювати паралельно з Dynamics 365, оскільки обидва використовують Dataverse.

00:15:58.840 --> 00:16:06.520
Можливо, Dynamics 365 Sales керує повним процесом продажу, тоді як менший модельний додаток дає менеджерам із контрактів зосереджене місце для відстеження угод.

00:16:06.640 --> 00:16:10.760
Обидва можуть працювати з пов'язаними даними клієнтів, не створюючи другу базу даних клієнтів.

00:16:10.920 --> 00:16:13.240
Звісно, такий доступ все одно потребує уваги.

00:16:13.240 --> 00:16:20.000
Те, що додаток може працювати з таблицею Dataverse, не означає, що кожен користувач повинен редагувати кожен рядок або бачити кожен стовпець.

00:16:20.040 --> 00:16:23.640
Рольовий доступ до рядків та бізнес-правила все ще контролюють те, що відбувається.

00:16:23.780 --> 00:16:29.880
Польовий додаток може надати комусь саме ті деталі клієнта та дії, які їм потрібні, не відкриваючи решту даних компанії.

00:16:30.060 --> 00:16:35.700
Отже, інтеграція Dynamics 365 з Dataverse – це тепер не кабель, що з'єднує дві віддалені кімнати.

00:16:35.700 --> 00:16:41.320
Додатки Dynamics 365 – спеціалізовані додатки та бізнес-процеси можуть працювати на одній спільній основі.

00:16:41.420 --> 00:16:44.360
Коли ви це бачите, наступне питання стає зрозумілим.

00:16:44.540 --> 00:16:49.400
Що ще може використовувати це ж оновлення клієнта на підключеній платформі Microsoft?

00:16:49.720 --> 00:16:52.480
Як підключена платформа працює в реальних умовах?

00:16:52.620 --> 00:16:56.540
Спільне оновлення клієнта стає корисним, коли інструменти навколо нього можуть реагувати.

00:16:56.720 --> 00:17:02.340
Pava Otamite виконує подальшу роботу, відстежуючи зміни в рядку Dataverse і запускаючи дію, коли така зміна відбувається.

00:17:02.340 --> 00:17:05.800
Наприклад, новий лід потрапляє в Dynamics 365 Sales.

00:17:05.940 --> 00:17:10.940
Потік може сповістити призначеного продавця, надіслати повідомлення в Teams або створити завдання для подальшої роботи.

00:17:11.080 --> 00:17:13.920
Нікому не потрібно цілий день стежити за спільною поштовою скринькою.

00:17:14.080 --> 00:17:17.160
Лід змінюється і наступний крок запускається автоматично.

00:17:17.340 --> 00:17:21.480
Pava Otamite не потребує окремої копії ліда, щоб виконати цю роботу.

00:17:21.680 --> 00:17:25.080
Він може реагувати на рядок у Dataverse, використовуючи ті самі дані про клієнта та власника,

00:17:25.080 --> 00:17:28.520
який використовує додаток для продажів, і це наближає автоматизацію до бізнес-процесу,

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

00:17:32.720 --> 00:17:34.140
Крім того, існує Pava BI.

00:17:34.360 --> 00:17:37.340
Менеджеру з продажів може знадобитися побачити поточний стан воронки продажів.

00:17:37.460 --> 00:17:41.280
Менеджеру з обслуговування клієнтів може знадобитися побачити, скільки звернень надійшло цього тижня,

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

00:17:44.940 --> 00:17:48.280
Pava BI може створювати звіти на основі бізнес-даних Dataverse,

00:17:48.420 --> 00:17:52.440
щоб команди бачили стан справ без створення нових експортів у таблиці щоп'ятниці.

00:17:52.640 --> 00:17:54.940
Звіт базується на бізнес-даних, які люди вже використовують.

00:17:55.600 --> 00:17:58.980
Це означає, що діаграма воронки продажів змінюється в міру просування можливостей.

00:17:59.140 --> 00:18:02.960
Інформаційна панель звернень може відображати поточне навантаження, поки агенти оновлюють справи.

00:18:03.120 --> 00:18:06.860
Суть у тому, що інформаційна панель замінює ручну перевірку деталей людьми.

00:18:06.860 --> 00:18:11.320
Вона дає їм чіткіше уявлення про роботу, перш ніж вони вирішать, що потребує уваги.

00:18:11.420 --> 00:18:14.240
Pava Apps додає ще один шлях до того самого процесу.

00:18:14.380 --> 00:18:17.240
Уявіть працівника, який прибуває на об'єкт до клієнта.

00:18:17.440 --> 00:18:20.860
Їм не потрібен повний досвід Dynamics 365 Sales.

00:18:21.060 --> 00:18:24.220
Можливо, їм потрібно лише знайти клієнта, переглянути деталі візиту,

00:18:24.340 --> 00:18:26.820
підтвердити, що сталося, і додати нотатку чи фото.

00:18:27.160 --> 00:18:30.180
Спеціалізований додаток Pava App може надати їм такий спрощений досвід.

00:18:30.180 --> 00:18:33.560
Команді з роботи з клієнтами може знадобитися додаток для перегляду клієнтських угод.

00:18:33.680 --> 00:18:36.380
Керівнику може знадобитися простий додаток для затвердження запиту.

00:18:36.540 --> 00:18:40.960
Кожен додаток зосереджується на одній задачі, працюючи з тими самими контрольованими даними Dataverse у фоновому режимі.

00:18:41.080 --> 00:18:43.540
Людина бачить інструмент, який підходить для її щоденної роботи.

00:18:43.700 --> 00:18:45.640
Бізнес зберігає всю пов'язану інформацію.

00:18:45.820 --> 00:18:48.440
Іноді ця інформація спочатку знаходиться поза межами Dataverse.

00:18:48.440 --> 00:18:52.500
Компанія може мати список з онлайн-джерела, який має стати частиною її бізнес-даних.

00:18:52.620 --> 00:18:59.440
Pava Query може імпортувати дані з підтримуваних онлайн-джерел, очищати їх під час імпорту та завантажувати у відповідну таблицю Dataverse.

00:18:59.620 --> 00:19:04.780
Це корисно, коли зовнішнє джерело містить інформацію, необхідну для ваших інструментів Dynamics та Pava Platform.

00:19:05.000 --> 00:19:09.620
Вам все одно потрібно вирішити, що саме належить до Dataverse і як це має підключатися до існуючих таблиць.

00:19:09.720 --> 00:19:13.380
Імпорт даних без попереднього планування лише переносить плутанину в нове місце.

00:19:13.380 --> 00:19:16.400
Давайте об'єднаємо ці частини в один повсякденний робочий процес.

00:19:16.520 --> 00:19:18.800
Новий потенційний клієнт потрапляє в Dynamics 365.

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

00:19:23.280 --> 00:19:27.360
Власник отримує повідомлення в Teams через потік Pava Automate, щоб знати, що на нього чекає робота.

00:19:27.520 --> 00:19:34.260
Коли менеджер з продажу оновлює дані та просуває клієнта за процесом продажу, інформаційна панель Pava BI змінюється, показуючи команді поточний стан воронки.

00:19:34.420 --> 00:19:37.180
Одне оновлення запускає корисну роботу в кількох місцях одночасно.

00:19:37.180 --> 00:19:39.760
Pava Automate переміщує роботу з одного етапу на наступний.

00:19:39.880 --> 00:19:42.080
Pava BI допомагає людям бачити результати роботи.

00:19:42.200 --> 00:19:45.200
Pava Apps дає конкретним командам цілеспрямований спосіб долучитися до процесу.

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

00:19:49.820 --> 00:19:51.180
Ця різниця має значення.

00:19:51.580 --> 00:19:55.500
Автоматизація – це не система архівування, а інформаційна панель – це не база даних клієнтів.

00:19:55.640 --> 00:19:59.260
Кожен інструмент має свою окрему функцію, але всі вони можуть працювати з одним джерелом даних.

00:19:59.260 --> 00:20:05.760
Розуміння цього допомагає обрати правильний інструмент, замість того, щоб намагатися керувати бізнес-процесами за допомогою звичайних таблиць чи списків.

00:20:06.300 --> 00:20:09.180
Коли Dataverse підходить, найкраще і що він не замінює.

00:20:09.340 --> 00:20:10.400
Ось у чому справа.

00:20:10.520 --> 00:20:14.500
Обирайте Dataverse, коли декільком користувачам і додаткам потрібно працювати з пов'язаними бізнес-даними.

00:20:14.660 --> 00:20:17.200
Вам потрібні чіткі правила доступу та повторювані процеси.

00:20:17.360 --> 00:20:19.940
Dataverse впорається з цим, але він не замінює все інше.

00:20:20.080 --> 00:20:23.300
Excel залишається найкращим вибором для особистого аналізу та швидких списків.

00:20:23.300 --> 00:20:26.280
Списки SharePoint добре підходять для простого командного відстеження.

00:20:26.400 --> 00:20:30.240
А якщо ви розробник і потребуєте повного контролю, SQL залишається надійним вибором.

00:20:30.340 --> 00:20:32.040
Тож, коли Dataverse дійсно доречний.

00:20:32.180 --> 00:20:37.580
Коли ваші дані мають бути пов'язані між Dynamics 365, додатками, автоматизацією та звітами без створення копій.

00:20:37.700 --> 00:20:39.420
Ось де він проявляє себе найкраще.

00:20:39.600 --> 00:20:43.000
Отже, висновок «Одна основа, багато бізнес-інструментів».

00:20:43.000 --> 00:20:44.220
Ось головний висновок.

00:20:44.220 --> 00:20:51.640
Dynamics 365 та Dataverse працюють найефективніше, коли всі ваші дані, правила, безпека, додатки, автоматизація та звіти мають спільну основу.

00:20:51.740 --> 00:20:59.400
Підписуйтесь на Microsoft Knowledge Nuggets на M365FM, щоб отримати більше зрозумілих інструкцій щодо Dynamics 365, Pava Platform та Microsoft 365.

00:20:59.400 --> 00:21:05.300
Потім подивіться наш випуск про модельні додатки, щоб побачити, як таблиці Dataverse перетворюються на робочий бізнес-додаток.