WEBVTT

00:00:03.790 --> 00:00:09.530
Добро пожаловать в рубрику Microsoft Knowledge на Гетос. Я Мирко Питерс. Сегодняшняя тема часто

00:00:09.530 --> 00:00:14.850
сбивает людей с толку. Что именно такое Dataverse? Это база данных, приложение или скрытая служба

00:00:14.850 --> 00:00:19.870
Dynamics 365, которую должны понимать только IT-специалисты. Вот самое простое определение.

00:00:20.050 --> 00:00:24.790
Dataverse – это общая база данных, лежащая в основе многих решений Dynamics 365. Представьте

00:00:24.790 --> 00:00:30.270
Dynamics 365 как офисное издание. Продажи, обслуживание клиентов и другие приложения – это кабинеты,

00:00:30.270 --> 00:00:34.630
где работают люди, а Dataverse – это система картотеки и правила, скрытые за стенами. К концу

00:00:34.630 --> 00:00:38.930
этого выпуска вы узнаете, где хранятся данные Dynamics и как обновление информации об одном клиенте

00:00:38.930 --> 00:00:43.410
отражается в продажах, автоматизации и отчетности. Но прежде чем переходить к названиям продуктов,

00:00:43.650 --> 00:00:48.790
давайте начнем с рабочих проблем, которые это решает. Единое общее место. Вместо разрозненных

00:00:48.790 --> 00:00:53.450
копий. Представьте компанию с отделом продаж, службой поддержки и финансовым отделом. Продажи

00:00:53.450 --> 00:00:57.230
хранят данные клиентов в электронной таблице. Поддержка работает в отдельном инструменте для

00:00:57.230 --> 00:01:01.130
обработки заявок. У финансов свои имена клиентов в их собственной системе. Кто-то сохраняет

00:01:01.130 --> 00:01:05.290
цепочки писем в общем почтовом ящике, а другой ведет заметки в папке, которую никто больше не

00:01:05.290 --> 00:01:09.430
может найти. Один и тот же клиент теперь существует в пяти местах. Сначала такая структура кажется

00:01:09.430 --> 00:01:13.090
нормальной, потому что каждая команда видит только ту часть работы, которая перед ней. Но вот в чем

00:01:13.090 --> 00:01:17.130
дело, как только клиент меняет номер телефона, адрес, название компании или контактное лицо,

00:01:17.310 --> 00:01:21.370
начинаются проблемы. Продажи обновляют таблицу, поддержка этого не видит, а финансы продолжают

00:01:21.370 --> 00:01:25.450
отправлять документы по старому адресу. Затем кто-то выгружает список, вручную его чистит,

00:01:25.450 --> 00:01:29.410
рассылает по почте, и внезапно три человека считают, что именно их копия верная.

00:01:29.530 --> 00:01:33.250
Какому списку верить? Этот вопрос отнимает больше времени, чем вы можете подумать.

00:01:33.410 --> 00:01:37.430
Сотрудники тратят время на сверку записей. Менеджеры спрашивают, почему отчет не совпадает

00:01:37.430 --> 00:01:41.730
с системой продаж. Агент поддержки открывает заявку для клиента, чьи данные уже лежат где-то еще,

00:01:41.870 --> 00:01:46.070
но немного отличаются. Никто не пытается создать беспорядок. Беспорядок возникает из-за копий.

00:01:46.210 --> 00:01:50.230
20 лет назад отдельные системы означали отдельные серверы, базы данных и команды, хранящие

00:01:50.230 --> 00:01:53.070
собственную информацию. Их соединение требовало индивидуальной разработки,

00:01:53.070 --> 00:01:56.810
запланированного импорта и множество ручных проверок. Изменения в одном месте могло дойти до

00:01:56.810 --> 00:02:01.130
другой системы завтра, на следующей неделе или никогда. Dataverse предоставляет бизнес-приложением

00:02:01.130 --> 00:02:05.670
общее место для такого типа информации. Простыми словами, Dataverse — это облачная платформа

00:02:05.670 --> 00:02:09.770
данных Microsoft для бизнес-информации. Она хранит информацию в структурированных таблицах,

00:02:09.870 --> 00:02:13.510
поэтому данные имеют четкую форму, вместо того, чтобы существовать как хаотичные заметки,

00:02:13.670 --> 00:02:17.390
разрозненные файлы и несвязанные вкладки таблиц. Представьте это как корпоративный архив,

00:02:17.630 --> 00:02:20.550
к которому могут одновременно обращаться несколько одобренных инструментов.

00:02:20.550 --> 00:02:25.590
Клиент регистрируется в Dataverse один раз. Этот клиент может появиться в Dynamics 365 Sales,

00:02:25.790 --> 00:02:29.390
когда продавец работает над сделкой. Те же данные клиента могут отобразиться в Dynamics

00:02:29.390 --> 00:02:33.990
365 Customer Service, когда агент обрабатывает запрос в поддержку. PowerApp может использовать

00:02:33.990 --> 00:02:37.710
ту же информацию о клиенте для выездного сотрудника или менеджера, не требуя предварительного

00:02:37.710 --> 00:02:41.690
копирования данных в новое приложение. Одна строка с данными клиента — одна общая точка

00:02:41.690 --> 00:02:45.770
отсчета. Это не значит, что теперь каждая команда видит все подряд. Доступ все еще требует

00:02:45.770 --> 00:02:49.830
правил, о которых мы скоро поговорим. Это значит, что одобренные приложения работают с одними

00:02:49.830 --> 00:02:52.890
и теми же бизнес-данными, вместо создания собственных дублирующих версий.

00:02:53.010 --> 00:02:57.890
Вот почему Dynamics 365 и Dataverse так органично сочетаются. Приложения Dynamics 365,

00:02:58.110 --> 00:03:01.190
такие как Sales и Customer Service, используют Dataverse для хранения и защиты данных,

00:03:01.290 --> 00:03:05.190
с которыми они работают. Но вот в чем дело, когда говорят об интеграции Dynamics 365

00:03:05.190 --> 00:03:09.370
секунд Dataverse, часто представляют два отдельных продукта, которым нужен соединитель.

00:03:09.570 --> 00:03:14.250
Для многих приложений Dynamics 365 это не так. Данные уже находятся в Dataverse.

00:03:14.250 --> 00:03:19.390
Вам не нужно выгружать список клиентов из Dynamics 365, копировать его в другую базу и надеяться,

00:03:19.590 --> 00:03:22.790
что обе стороны останутся актуальными. Вы можете строить решения на той же базе,

00:03:22.950 --> 00:03:27.430
используя ту же бизнес-информацию, что уже использует Dynamics 365. Это меняет сам подход

00:03:27.430 --> 00:03:31.370
к обсуждению. Вместо вопроса, как нам синхронизировать эти два списка клиентов,

00:03:31.550 --> 00:03:35.110
вы можете спросить, кому и каким приложениям нужен доступ к этой записи клиента,

00:03:35.330 --> 00:03:39.830
и что каждому из них разрешено делать. Конечно, Dataverse не заменяет все системы компании.

00:03:39.830 --> 00:03:44.610
Бизнес может по-прежнему использовать финансовые ПА, отраслевые инструменты, складские системы,

00:03:44.810 --> 00:03:48.830
сайты или устаревшие приложения со своими данными. Dataverse — это не волшебный клей,

00:03:49.010 --> 00:03:53.450
который в одночасье уберет все внешние системы. Она дает вам общее место для бизнес-данных,

00:03:53.650 --> 00:03:58.190
которыми должны обмениваться связанные приложения. Данные клиентов, продажи, поддержка,

00:03:58.370 --> 00:04:02.190
задачи и последующие действия. Эти записи могут существовать вместе как единый источник,

00:04:02.310 --> 00:04:06.350
который одобренные инструменты могут читать и обновлять. Итак, откройте этот архив вместе со мной.

00:04:06.350 --> 00:04:12.110
Как только вы увидите, как Dataverse организует информацию внутри, вся связь с Dynamics 365 станет

00:04:12.110 --> 00:04:18.490
гораздо понятнее. Архивный шкаф, таблицы, строки, столбцы и связи. Давайте откроем этот архив.

00:04:18.630 --> 00:04:23.310
В Dataverse информация находится в таблицах. Представьте это как обычный шкаф с отдельными ящиками.

00:04:23.450 --> 00:04:28.590
Ой, в одном ящике лежат компании, в другом — люди, а в третьем — запросы в поддержку. Вы не бросаете

00:04:28.590 --> 00:04:33.410
все бумаги в один огромный ящик, надеясь, что кто-то разберет их потом. У каждого ящика своя задача.

00:04:33.410 --> 00:04:37.050
Так и в Dataverse. Таблица хранит один тип бизнес-информации. Таблица организации обычно

00:04:37.050 --> 00:04:40.570
содержит компании, с которыми вы работаете. Таблица контактов хранит данные об отдельных

00:04:40.570 --> 00:04:44.330
людях. Таблица интересов содержит потенциальных клиентов, пока они не стали реальными.

00:04:44.510 --> 00:04:49.530
Таблица обращений хранит запросы в поддержку, а таблица действия очлеживает звонки, письма,

00:04:49.690 --> 00:04:54.270
встречи и задачи. Это стандартные таблицы. Microsoft включает их в систему, потому что большинству

00:04:54.270 --> 00:04:58.750
компаний нужно вести учет клиентов, людей, работы и общения. Нет смысла создавать новую таблицу для

00:04:58.750 --> 00:05:02.630
обычных задач, если уже есть подходящее стандартное. Однако у каждой компании есть и

00:05:02.630 --> 00:05:07.130
специфика работы. Учебному центру может потребоваться учет курсов и сертификатов. Бизнесу в

00:05:07.130 --> 00:05:11.930
сфере недвижимости, здания, помещения и инспекции. Производителю, проверке оборудования или

00:05:11.930 --> 00:05:16.630
сервисные визиты. В таких случаях можно создать пользовательские таблицы, соответствующие именно

00:05:16.630 --> 00:05:20.650
вашей работе. Представьте создание пользовательской таблицы как добавление нового ящика в шкаф с

00:05:20.650 --> 00:05:24.990
четкой маркировкой. Теперь о строках. Каждая таблица состоит из строк. Строка – это один элемент в

00:05:24.990 --> 00:05:29.130
таком ящике. Например, одна строка в таблице контактов может представлять Марию Гомес,

00:05:29.130 --> 00:05:33.370
сотрудницу компании-клиента. В ее строке хранятся персональные данные, отделенные от всех

00:05:33.370 --> 00:05:37.670
остальных контактов в системе. Столбцы описывают детали, которые нужно сохранить для каждой строки.

00:05:37.810 --> 00:05:43.010
В строке Марии могут быть столбцы для имени, фамилии, email, телефона, должности, компании,

00:05:43.250 --> 00:05:47.630
владельца записи и статуса. Столбец определяет тип информации для этого поля. Например,

00:05:47.850 --> 00:05:52.010
в поле email ожидается адрес почты, а в поле статуса – выбор из разрешенных значений.

00:05:52.130 --> 00:05:56.970
Так бизнес-информация приобретает надежную структуру. Без столбцов один человек может

00:05:56.970 --> 00:06:02.030
вписать телефон в поле заметок, другой – в поле имени, а кто-то вовсе его не укажет.

00:06:02.150 --> 00:06:06.330
Благодаря четкой структуре таблицы контактов, все работают с одинаковыми данными в одних и тех

00:06:06.330 --> 00:06:10.510
же местах. Эта структура также помогает приложениям понимать данные. Форма может отображать

00:06:10.510 --> 00:06:14.990
нужные поля, отчет – группировать контакты по статусу, а автоматизация – срабатывать при смене

00:06:14.990 --> 00:06:19.070
владельца. Информация не просто хранится, она снабжена метками, которые объясняют связанным

00:06:19.070 --> 00:06:23.050
инструментом значения каждой части. Начинайте со стандартных таблиц, если они соответствуют

00:06:23.050 --> 00:06:27.070
вашим бизнес-задачам. Если вы продаете компаниям, таблицы организаций и контактов уже

00:06:27.070 --> 00:06:31.070
описывают привычную всем модель. Если вы занимаетесь поддержкой клиентов, обращения станут

00:06:31.070 --> 00:06:34.170
хорошей отправной точкой. Добавляйте пользовательские таблицы только тогда,

00:06:34.370 --> 00:06:38.210
когда ваша информация не вписывается в стандартные шаблоны. Это позволяет избежать типичной

00:06:38.210 --> 00:06:42.510
проблемы – создание пяти разных таблиц, которые означают одно и то же – клиент. Одна команда

00:06:42.510 --> 00:06:47.470
называет это – клиент, другая – главный клиент, третья – контакт партнера. Вскоре люди перестают

00:06:47.470 --> 00:06:51.170
понимать, какую таблицу им следует использовать. Понятные стандартные таблицы и тщательно

00:06:51.170 --> 00:06:54.430
названные пользовательские таблицы делают структуру базы данных доступной для всех по мере ее

00:06:54.430 --> 00:06:58.730
расширения. Следующий этап – это когда эти «ящики» начинают работать вместе. Контакты относятся

00:06:58.730 --> 00:07:03.370
к определенной организации. Мария работает в Контаса LTD. Вместо того, чтобы снова вводить адрес,

00:07:03.550 --> 00:07:07.510
телефон и реквизиты Контаса в строку Марии, Датаверс позволяет создать связь между таблицей

00:07:07.510 --> 00:07:11.990
контактов и таблицей организаций. Мария связана с Контаса, и эта связь важна, так как информация

00:07:11.990 --> 00:07:16.150
о компании остается привязанной к компании. Если у Контаса меняется адрес, нужно лишь раз обновить

00:07:16.150 --> 00:07:20.010
строку организации, и все связанные контакты будут ссылаться на ту же компанию, не храня у себя

00:07:20.010 --> 00:07:24.670
устаревшие копии. Связи также соединяют обращения в службу поддержки с клиентом, который его создал.

00:07:24.790 --> 00:07:29.530
Они могут связать торговую сделку со звонками, письмами, встречами и задачами, относящимися к ней.

00:07:29.650 --> 00:07:33.570
Когда продавец открывает сделку, он видит всю связанную с ней активность, вместо того,

00:07:33.690 --> 00:07:38.530
чтобы искать ее в разрозненных заметках и календарях. Информация обретает контекст. Вы смотрите не

00:07:38.530 --> 00:07:43.130
просто на номер обращения, вы видите, к какому клиенту оно относится. Вы просматриваете не просто

00:07:43.130 --> 00:07:47.450
контакт. Вы видите компанию, связанную с этим человеком. Эти связи делают данные полезными,

00:07:47.630 --> 00:07:50.710
избавляя от необходимости многократно вводить одни и те же сведения в разных местах.

00:07:50.830 --> 00:07:54.130
Небольшое замечание по поводу терминологии, прежде чем вы начнете читать старые руководства или

00:07:54.130 --> 00:07:58.590
смотреть видео. Вы можете услышать слова «сущность», «поле» и «запись». Это устаревшие термины

00:07:58.590 --> 00:08:03.490
датаверс. Microsoft теперь использует таблица, вместо «сущности», «столбец», вместо «поле» и «строка»,

00:08:03.490 --> 00:08:08.990
вместо «записи». Значение при этом не изменилось. В старом руководстве, где сказано «создать сущность»,

00:08:08.990 --> 00:08:13.250
речь идет о создании таблицы. «Поле» — это «столбец», а «запись» — это «строка».

00:08:13.250 --> 00:08:17.270
Знание обоих вариантов терминологии убережет вас от мысли, что вы нашли другой продукт.

00:08:17.310 --> 00:08:21.990
Итак, таблица организует информацию, а связи ее объединяют. Но хорошо организованному шкафу все

00:08:21.990 --> 00:08:26.030
еще нужны средства контроля. Кто-то должен решать, что люди могут вводить, изменять и к чему

00:08:26.030 --> 00:08:30.130
могут безопасно получать доступ. Правила и стойка регистрации. Данные в датаверс работают

00:08:30.130 --> 00:08:33.810
эффективно только тогда, когда нужные люди могут безопасно с ними взаимодействовать. Торговому

00:08:33.810 --> 00:08:37.090
представителю нужны данные клиента, агенту поддержки, истории обращений,

00:08:37.090 --> 00:08:41.170
менеджеру — более широкий обзор, а внешнему партнеру — доступ лишь к малой части процесса.

00:08:41.250 --> 00:08:45.350
Они не должны видеть один и тот же объем информации. Представьте запись о клиенте с личной

00:08:45.350 --> 00:08:49.490
заметкой, согласованной ценой и открытым обращением в поддержку. Предоставление всем

00:08:49.490 --> 00:08:53.010
пользователям полного доступа быстро создает риски. Слишком строгие ограничения,

00:08:53.210 --> 00:08:56.790
мешающие работе, создают другую проблему. Датаверс предоставляет инструменты для управления

00:08:56.790 --> 00:09:00.750
этим процессом. Первый из них — это управление идентификацией. При входе в систему с учетной

00:09:00.750 --> 00:09:05.510
записью компании вас идентифицирует Microsoft IntraID. Представьте IntraID как стойку регистрации

00:09:05.510 --> 00:09:09.410
на входе в офис. Вы приходите, показываете пропуск, и администратор проверяет, кто вы,

00:09:09.530 --> 00:09:13.230
прежде чем пропустить. Датаверс использует эту идентификацию, чтобы знать, какой пользователь

00:09:13.230 --> 00:09:17.150
работает с данными. Система не просто спрашивает, можно ли этому человеку войти. Она также

00:09:17.150 --> 00:09:21.330
определяет, что этому человеку разрешено делать после входа. Здесь на помощь приходят роли

00:09:21.330 --> 00:09:25.910
безопасности. Роль безопасности — это набор прав, связанных с должностью или обязанностями.

00:09:26.090 --> 00:09:30.230
Вы можете создать одну роль для отдела продаж, другую — для службы поддержки, и еще одну — для

00:09:30.230 --> 00:09:33.970
менеджеров. Каждая роль определяет доступ к таблице. Например, менеджеру по продажам

00:09:33.970 --> 00:09:37.790
может быть разрешено читать, создавать и обновлять организации, контакты, интересы и сделки.

00:09:37.890 --> 00:09:41.670
При этом ему может быть запрещено удалять важную информацию о клиентах. Специалист службы

00:09:41.670 --> 00:09:44.930
поддержки может создавать и обновлять обращения, но не менять торговые сделки.

00:09:45.090 --> 00:09:49.090
Права доступа могут включать чтение, создание, изменение и удаление строк. Это значит,

00:09:49.270 --> 00:09:52.630
что доступ не зависит от того, помнит ли кто-то, какие кнопки скрыть в каждом приложении.

00:09:52.770 --> 00:09:56.630
Права доступа привязаны к самим данным, поэтому одни и те же защитные механизмы действуют везде,

00:09:56.810 --> 00:09:59.950
где отображаются данные датаверс. Затем вы можете еще больше ограничить доступ.

00:10:00.090 --> 00:10:03.370
Безопасность на уровне строк определяет, с какими отдельными строками может работать

00:10:03.970 --> 00:10:07.930
Менеджер по продажам может видеть только своих клиентов, а руководитель отдела – клиентов

00:10:07.930 --> 00:10:12.350
всех членов своей команды. Оба используют одну и ту же таблицу организаций. Просто они видят

00:10:12.350 --> 00:10:15.870
разные ее части. Такая настройка помогает сотрудникам сосредоточиться на своей работе,

00:10:15.970 --> 00:10:19.670
а руководителям – видеть общую картину. Это также снижает вероятность того, что кто-то откроет

00:10:19.670 --> 00:10:24.210
информацию о клиенте, который у него нет доступа. Некоторые данные требуют еще более строгой защиты.

00:10:24.390 --> 00:10:28.230
Безопасность на уровне столбцов позволяет защитить отдельные столбцы внутри таблицы. Возможно,

00:10:28.390 --> 00:10:31.790
пользователю нужно открыть строку клиента, но нельзя видеть личный идентификатор, зарплату,

00:10:31.790 --> 00:10:35.510
банковские реквизиты или частные финансовые заметки. Строка клиента остается доступной для

00:10:35.510 --> 00:10:39.330
выполнения необходимых задач. При этом защищенный столбец остается ограниченным для доступа.

00:10:39.450 --> 00:10:42.850
Для крупных компаний бизнес-единицы помогают создавать границы между подразделениями

00:10:42.850 --> 00:10:46.510
организации. Компания может разделять регионы, отделы или дочерние предприятия,

00:10:46.670 --> 00:10:50.690
работающие с разными группами клиентов. Бизнес-единицы помогают настроить доступ с учетом

00:10:50.690 --> 00:10:54.990
этих границ. Это не значит, что каждому бизнесу нужна сложная схема безопасности. Небольшой команде

00:10:54.990 --> 00:10:58.550
может потребоваться лишь несколько четко определенных ролей. Крупной компании нужно больше уровней,

00:10:58.550 --> 00:11:02.410
так как ее команды, регионы и обязанности различаются. Суть в том, что Dataverse позволяет

00:11:02.410 --> 00:11:05.970
настроить доступ в соответствии с тем, как работает бизнес. Контроль доступа определяет,

00:11:06.030 --> 00:11:09.250
кто может получить данные, но правила также защищают качество самих данных.

00:11:09.430 --> 00:11:12.990
Бизнес-правило может потребовать ввода номера телефона, прежде чем пользователь сохранит новый

00:11:12.990 --> 00:11:16.410
контакт. Оно может проверить условия, например, потребовать указания причины при закрытии

00:11:16.410 --> 00:11:19.850
обращения. Оно также может менять отображение данных для пользователей в зависимости от введенной

00:11:19.850 --> 00:11:23.470
информации. Одно и то же правило действует во всех приложениях, использующих эту таблицу.

00:11:23.610 --> 00:11:27.610
Это важно, чтобы одно приложение не принимало неполные данные, а другое их отклоняло.

00:11:27.610 --> 00:11:31.590
Правила относятся к бизнес-информации, а не к конкретному экрану, на котором она отображается.

00:11:31.770 --> 00:11:35.370
Dataverse также может выполнять логику в фоновом режиме, чтобы поддерживать согласованность

00:11:35.370 --> 00:11:39.970
бизнес-процессов. Деталь, которую нужно запомнить, проста. Данные идут в комплекте с правилами,

00:11:40.150 --> 00:11:44.750
а не просто хранятся. Таким образом, фундамент включает информацию людей, допущенных к работе с ней,

00:11:44.890 --> 00:11:50.010
и правила, обеспечивающие ее пригодность. Поскольку Dynamics 365 работает на том же фундаменте,

00:11:50.230 --> 00:11:54.410
ей не нужен традиционный мост для доступа к собственным бизнес-данным. Что на самом деле означает

00:11:54.410 --> 00:12:00.610
интеграция Dynamics 365? Большинство слышит интеграция Dynamics 365 секунд Dataverse и представляет

00:12:00.610 --> 00:12:05.290
две разные системы, соединенные коннектором. Одна система содержит данные клиента, другой нужна их

00:12:05.290 --> 00:12:10.510
копия, поэтому кто-то настраивает синхронизацию, ждет ее завершения и надеется, что ничего не сломается.

00:12:10.670 --> 00:12:17.570
Такая картина типична для многих бизнес-инструментов. Но здесь, в случае с Dynamics 365 Sales и Dynamics

00:12:17.570 --> 00:12:23.650
365 Customer Service связь намного теснее. Эти приложения используют Dataverse в качестве общей основы

00:12:23.650 --> 00:12:27.990
для данных. Это не две разные базы данных, пересылающие записи клиентов друг к другу для

00:12:27.990 --> 00:12:31.690
взаимодействия. Они работают с одной и той же бизнес-информацией изначально.

00:12:31.870 --> 00:12:36.430
Давайте перейдем к конкретике. Представьте, что вы менеджер по продажам и создаете новую

00:12:36.430 --> 00:12:41.730
компанию в Dynamics 365 Sales. Вы добавляете основного контактного лица и начинаете работать над

00:12:41.730 --> 00:12:45.870
потенциальной сделкой. Эти данные сразу становятся частью общих сведений, используемых приложением.

00:12:45.870 --> 00:12:50.390
Позже этот клиент обращается в службу поддержки. Агент поддержки может работать с теми же самыми

00:12:50.390 --> 00:12:54.350
данными компании и контактного лица. Никому не нужно экспортировать списки из продаж или

00:12:54.350 --> 00:12:58.770
создавать клиента заново в отдельном инструменте поддержки. Агент просто привязывает обращение к

00:12:58.770 --> 00:13:03.310
этому клиенту и видит историю, которая помогает понять ситуацию. Отдел продаж видит сделку,

00:13:03.510 --> 00:13:07.870
служба поддержки, обращение, и обе команды работают с одним и тем же клиентом. Это вовсе не означает,

00:13:08.090 --> 00:13:12.650
что все экраны выглядят одинаково или что все команды следуют единому процессу. Отделу продаж нужны

00:13:12.650 --> 00:13:17.390
лиды, возможности, звонки и встречи. Службе поддержки нужны обращения, очереди и истории

00:13:17.390 --> 00:13:21.310
обслуживания. Каждое приложение Dynamics 365 предоставляет сотрудникам инструменты,

00:13:21.430 --> 00:13:25.230
созданные для их задач. Хотя деловая информация в основе может связываться где угодно,

00:13:25.470 --> 00:13:30.690
именно эту общую базу люди часто имеют в виду, говоря об интеграции Dynamics 365 и Dataverse.

00:13:30.850 --> 00:13:36.330
Речь не столько о перемещении данных из точки А в точку, сколько о работе приложений с одними и теми

00:13:36.330 --> 00:13:39.810
же строками, связями, правилами и правами доступа изначально.

00:13:39.810 --> 00:13:44.790
Давайте проследим путь простой продажи. Лид поступает с веб-сайта или мероприятия.

00:13:44.950 --> 00:13:49.230
Менеджер по продажам работает с этим лидом, узнает больше о человеке и превращает лидов

00:13:49.230 --> 00:13:53.690
клиентские отношения и возможность. Звонки, электронные письма, встречи и задачи – все это

00:13:53.690 --> 00:13:57.010
может быть привязано к данной работе. Таким образом, команде не нужно искать данные в разных

00:13:57.010 --> 00:14:00.810
инструментах, чтобы собрать всю историю воедино. Если клиенту позже потребуется помощь,

00:14:00.970 --> 00:14:05.430
обращение в поддержку будет связано с тем же самым клиентом. Агент поддержки видит не просто имя

00:14:05.430 --> 00:14:10.450
и адрес электронной почты. Он может работать в контексте уже определенных отношений с клиентом.

00:14:10.570 --> 00:14:15.270
Тем временем отдел продаж видит, что у клиента есть открытый вопрос по обслуживанию и не начинает

00:14:15.270 --> 00:14:19.550
переговоры о продлении, не зная о проблеме. Одни клиентские отношения могут поддерживать разные

00:14:19.550 --> 00:14:23.530
виды работы, что гораздо полезнее, чем просто хранение совпадающего имени клиента в двух

00:14:23.530 --> 00:14:28.790
системах. Вы также могли слышать термин «общая модель данных», иногда сокращаемый до CDM. Пусть название

00:14:28.790 --> 00:14:33.510
не кажется вам более загадочным, чем оно есть на самом деле. Это просто означает, что Microsoft предоставляет

00:14:33.510 --> 00:14:37.290
общие шаблоны бизнес-таблиц для того, что очлеживают многие компании, например, организации,

00:14:37.430 --> 00:14:42.050
контакты, действия и обращения. Эти шаблоны дают приложениям на базе Dynamics 365 и Dataverse

00:14:42.050 --> 00:14:47.070
общий язык для старта. Организация означает компанию. Контакт означает человека. Действие

00:14:47.070 --> 00:14:51.470
очлеживает работу в рамках деловых отношений. Вы можете настроить систему под свою компанию и

00:14:51.470 --> 00:14:55.230
добавлять свои таблицы при необходимости, но вам не нужно каждый раз начинать с чистого листа.

00:14:55.370 --> 00:14:59.670
Когда одно приложение понимает таблицу организации, а другое использует ту же таблицу, оба приложения

00:14:59.670 --> 00:15:03.370
обращаются к одному и тому же типу бизнес-информации. Это также меняет возможности

00:15:03.370 --> 00:15:07.330
разработки. Допустим, вашей выездной команде нужно простое приложение, чтобы найти клиента,

00:15:07.510 --> 00:15:10.430
подтвердить визит и добавить заметку после встречи. Вы можете создать PowerApp,

00:15:10.550 --> 00:15:13.930
которая будет работать с теми же таблицами Dataverse, что уже используется в Dynamics 365.

00:15:14.330 --> 00:15:18.010
Нет никакой необходимости экспортировать клиентов в новый список специально для этого приложения.

00:15:18.190 --> 00:15:22.110
Сотрудник на выезде открывает приложение, находит клиента и обновляет информацию о визите.

00:15:22.110 --> 00:15:26.010
Эти данные остаются связанными с отношениями с клиентами, которые уже используют отдел продаж или

00:15:26.010 --> 00:15:29.150
обслуживания в соответствии с правилами безопасности, о которых мы говорили ранее.

00:15:29.310 --> 00:15:32.490
Для более структурированных бизнес-задач можно создать приложение на основе модели.

00:15:32.490 --> 00:15:36.270
Приложение на основе модели начинается с модели данных. Вы выбираете таблицы Dataverse,

00:15:36.490 --> 00:15:40.010
определяете их связи, настраиваете формы и представления и применяете роли безопасности.

00:15:40.190 --> 00:15:43.790
Затем PowerApps использует эту структуру для создания полноценного рабочего бизнес-приложения.

00:15:43.950 --> 00:15:46.470
Представьте это как организацию рабочего места вокруг инструментов и материалов,

00:15:46.490 --> 00:15:49.030
которые действительно использует ваша команда. Таблицы описывают работу,

00:15:49.030 --> 00:15:53.490
а связи соединяют все компоненты вместе. Формы позволяют людям вводить и просматривать детали.

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

00:15:57.390 --> 00:16:00.550
что каждый конкретный человек может открыть или изменить. Приложение на основе модели может

00:16:00.550 --> 00:16:04.230
работать вместе с Dynamics 365, поскольку оба они взаимодействуют с Dataverse. Возможно,

00:16:04.410 --> 00:16:08.530
Dynamics 365 Sales обрабатывает весь процесс продаж, в то время как небольшое приложение на основе

00:16:08.530 --> 00:16:11.750
модели дает миниджарам по контрактам удобное место для отслеживания соглашений с клиентами.

00:16:11.870 --> 00:16:15.750
Оба могут работать с одними и теми же данными клиентов, не создавая вторую базу данных.

00:16:15.750 --> 00:16:20.130
Конечно, такой доступ все равно требует осторожности. То, что приложение может работать с таблицей

00:16:20.130 --> 00:16:24.150
Dataverse, еще не означает, что каждый пользователь должен иметь право редактировать каждую строку или

00:16:24.150 --> 00:16:28.010
видеть каждый столбец. Роли, доступ к строкам и бизнес-правила по-прежнему контролируют все

00:16:28.010 --> 00:16:31.910
происходящее. Выездное приложение может предоставить сотруднику именно те данные о клиенте и

00:16:31.910 --> 00:16:35.250
действия, которые ему нужны, не открывая доступ к остальной части компании или данным.

00:16:35.350 --> 00:16:40.210
Таким образом, интеграция Dynamics 365 секунд Dataverse теперь похожа на кабель, соединяющий две

00:16:40.210 --> 00:16:44.990
удаленными комнаты. Приложение Dynamics 365, пользовательские приложения и бизнес-процессы

00:16:44.990 --> 00:16:49.230
могут работать на одной общей базе. Как только вы это поймете, следующий вопрос станет очевидным.

00:16:49.410 --> 00:16:53.970
Где еще можно использовать это же обновление информации о клиенте в рамках платформы Microsoft или

00:16:53.970 --> 00:16:58.170
подключенной платформы? Как подключенная платформа работает в реальных условиях? Обновление

00:16:58.170 --> 00:17:01.810
информации о клиенте становится полезным, когда окружающие инструменты могут на него реагировать.

00:17:01.970 --> 00:17:05.830
Power Automate берет на себя последующую работу, очлеживая изменения в строке Dataverse и запуская

00:17:05.830 --> 00:17:10.370
действия при возникновении таких изменений. Например, в Dynamics 365 Sales появляется новый

00:17:10.370 --> 00:17:14.490
потенциальный клиент. Поток может уведомить назначенного продавца, отправить сообщение в Teams или

00:17:14.490 --> 00:17:18.750
создать задачу для последующей обработки. Никому не нужно весь день следить за общим почтовым ящиком.

00:17:18.930 --> 00:17:22.350
Информация о клиенте меняется, и следующий шаг запускается автоматически.

00:17:22.350 --> 00:17:27.270
Power Automate не нужна отдельная копия записи о клиенте, чтобы выполнить эту работу. Он может

00:17:27.270 --> 00:17:31.490
реагировать на строку в Dataverse, используя те же данные о клиенте и владельце, что и приложение

00:17:31.490 --> 00:17:35.210
для продаж. Это позволяет автоматизации оставаться частью бизнес-процесса, а не зависеть от того,

00:17:35.330 --> 00:17:38.130
что кто-то будет выгружать файлы и запускать ручную цепочку электронных писем.

00:17:38.270 --> 00:17:42.450
Затем есть Power BI. Менеджеру по продажам может понадобиться увидеть текущую в ранку продаж.

00:17:42.650 --> 00:17:46.350
Руководителю службы поддержки может быть важно узнать, сколько обращений поступило за неделю,

00:17:46.530 --> 00:17:49.910
какие из них остаются открытыми или какие клиенты обращаются в поддержку чаще всего.

00:17:49.910 --> 00:17:54.510
Power BI может формировать отчеты по бизнес-данным Dataverse, поэтому команды могут видеть ход работы,

00:17:54.670 --> 00:17:58.890
не создавая новые выгрузки в электронные таблицы каждую пятницу. Отчет составляется на основе

00:17:58.890 --> 00:18:02.750
бизнес-данных, которые люди уже используют. Это означает, что диаграмма воронки продаж может

00:18:02.750 --> 00:18:05.890
меняться по мере продвижения сделок. Панель мониторинга обращений может показывать текущую

00:18:05.890 --> 00:18:09.670
нагрузку по мере того, как агенты обновляют данные по заявкам. Суть в том, что панель мониторинга

00:18:09.670 --> 00:18:14.410
избавляет людей от необходимости вручную проверять детали. Она дает более четкое представление о работе,

00:18:14.410 --> 00:18:19.210
прежде чем они решат, что требует внимания. Power Apps добавляет еще один путь к этому же процессу.

00:18:19.210 --> 00:18:23.970
Представьте выездного сотрудника, прибывающего на объект клиента. Ему не нужен весь функционал

00:18:23.970 --> 00:18:29.850
Dynamics 365 Sales. Возможно, ему нужно только найти клиента, просмотреть детали визита, подтвердить

00:18:29.850 --> 00:18:33.930
произошедшее и добавить заметку или фото. Узкоспециализированное приложение Power App может

00:18:33.930 --> 00:18:37.110
предоставить им этот упрощенный интерфейс. Команде по работе с клиентами может потребоваться

00:18:37.110 --> 00:18:40.770
приложение для проверки клиентских соглашений. Менеджеру может понадобиться простое приложение для

00:18:40.770 --> 00:18:44.210
одобрения запроса. Каждое приложение может фокусироваться на одной задаче, работая при этом с одной

00:18:44.210 --> 00:18:48.130
и той же контролируемой информацией в Dataverse на заднем плане. Сотрудник видит инструмент, который подходит для его

00:18:48.130 --> 00:18:52.490
ежедневных задач. Бизнес сохраняет взаимосвязанную информацию. Иногда эта информация берется

00:18:52.490 --> 00:18:56.850
извне Dataverse. У компании может быть список из онлайн-источника, который должен стать частью

00:18:56.850 --> 00:19:01.270
ее бизнес-данных. Power Query может импортировать данные из поддерживаемых онлайн-источников,

00:19:01.470 --> 00:19:05.910
очищать их во время загрузки и сохранять в нужную таблицу Dataverse. Это полезно, когда во внешнем

00:19:05.910 --> 00:19:10.050
источнике содержится информация, необходимая для работы ваших инструментов Dynamics и Power Platform.

00:19:10.050 --> 00:19:14.430
Вам все равно нужно решить, что именно должно храниться в Dataverse и как это связано с существующими

00:19:14.430 --> 00:19:19.130
таблицами. Импорт данных без такого анализа просто переносит хаос в новое место. Пусть

00:19:19.130 --> 00:19:23.610
OTOM объединит эти части в один повседневный процесс. Новый лид попадает в Dynamics 365,

00:19:23.910 --> 00:19:26.770
а правило назначения определяет, кто должен стать ответственным за него, например,

00:19:26.910 --> 00:19:30.930
на основе региона или продукта. Ответственный получает сообщение в Teams через поток Power Automate,

00:19:31.110 --> 00:19:34.830
поэтому он знает, что его ждет работа. По мере того, как продавец обновляет данные по лиду и

00:19:34.830 --> 00:19:39.150
продвигает его по воронке продаж, панель мониторинга Power BI меняется, показывая команде OTOM текущую

00:19:39.150 --> 00:19:43.830
воронку. Одно обновление запускает полезную работу сразу в нескольких местах. Power Automate перемещает работу

00:19:43.830 --> 00:19:48.170
с одного этапа на следующий. Power BI помогает людям видеть ход этой работы. Power Apps предоставляет

00:19:48.170 --> 00:19:51.430
конкретным группам узкоспециализированные инструменты для работы. Dataverse обеспечивает

00:19:51.430 --> 00:19:55.090
организованность и безопасность бизнес-данных, пока эти инструменты выполняют свои задачи.

00:19:55.190 --> 00:20:00.090
Эта разница важна. Автоматизация — это не система хранения файлов, а информационная панель — не база

00:20:00.090 --> 00:20:04.030
данных клиентов. У каждого инструмента своя задача, но все они могут работать с одним источником

00:20:04.030 --> 00:20:08.710
данных. Понимание этого помогает выбрать правильный инструмент, а не пытаться управлять всем бизнес-процессом

00:20:08.710 --> 00:20:14.190
с помощью таблицы или простого списка. Где Dataverse уместно и что она не заменяет?

00:20:14.790 --> 00:20:18.650
Все просто. Выбирайте Dataverse, когда нескольким сотрудникам и приложениям нужен доступ к

00:20:18.650 --> 00:20:22.430
взаимосвязанным бизнес-данным. Вам нужны четкие правила доступа и повторяемые процессы.

00:20:22.570 --> 00:20:27.130
Dataverse справляется с этим, но не заменяет все остальное. Excel остается лучшим выбором для личного

00:20:27.130 --> 00:20:31.450
анализа и быстрых списков. Списки SharePoint хорошо подходят для простого отслеживания задач команды.

00:20:31.510 --> 00:20:35.250
А если вы разработчик, которому нужен глубокий контроль, SQL остается отличным выбором.

00:20:35.250 --> 00:20:39.010
Итак, когда же Dataverse действительно подходит? Когда ваши данные должны быть связаны между

00:20:39.010 --> 00:20:43.810
приложениями Dynamics 365, автоматизацией и отчетами без создания лишних копий. Именно в этом ее

00:20:43.810 --> 00:20:49.390
преимущество. В заключение. Одна основа – множество бизнес-инструментов. Итак, главный вывод.

00:20:49.570 --> 00:20:54.590
Dynamics 365 и Dataverse работают лучше всего, когда данные, правила, безопасность, приложения,

00:20:54.750 --> 00:20:58.530
автоматизация и отчеты объединены общей основой. Подписывайтесь на Microsoft NoLedge на

00:20:58.530 --> 00:21:04.590
Gettos на M365.fm, чтобы получать простые руководства по Dynamics 365, Power Platform и Microsoft 365.

00:21:04.590 --> 00:21:08.790
Затем посмотрите наш выпуск о модельных приложениях, чтобы узнать, как таблицы Dataverse превращаются

00:21:08.790 --> 00:21:09.950
в работающие бизнес-приложения.