WEBVTT

00:00:00.160 --> 00:00:05.040
Продавец обновляет адрес клиента. Позже финансовый отдел открывает ту же запись и все еще видит

00:00:05.040 --> 00:00:09.460
старый адрес. Итак, какой же адрес верный? Годами это решалось так. Кто-то выгружал данные,

00:00:09.600 --> 00:00:13.220
правил таблицу, отправлял ее по почте и вручную вводил обновление во второе приложение.

00:00:13.420 --> 00:00:18.260
Dynamics 365 Dollright меняет это. Он связывает финансово-операционные приложения с клиентскими

00:00:18.260 --> 00:00:21.800
приложениями на базе Dataverse, поэтому общие записи, такие как клиенты и заказы,

00:00:21.940 --> 00:00:27.140
синхронизируются автоматически. С вами я, Милка Петерс из M365FM, и этот полезный совет

00:00:27.140 --> 00:00:31.280
объясняет суть Dollright простыми словами. Мы разберем, что передается, как это работает,

00:00:31.560 --> 00:00:35.340
где Dollright применим, а где нет. Для начала давайте перейдем к бизнес-проблеме,

00:00:35.500 --> 00:00:40.260
которая вызвала необходимость в этом решении. Проблема, которую решает Dollright.

00:00:40.580 --> 00:00:44.500
Представьте бизнес, где две группы работают с одним клиентом, но ежедневно используют

00:00:44.500 --> 00:00:49.360
совершенно разные приложения. Финансово-операционные приложения отвечают за бэк-офис. Это финансы,

00:00:49.500 --> 00:00:54.120
запасы, продукты, заказы, закупки и цепочки поставок. Здесь компания очлеживает продажи,

00:00:54.120 --> 00:00:58.700
возможности поставок, свои долги и платежи клиентов. Клиентские приложения сосредоточены на

00:00:58.700 --> 00:01:02.760
работе, близкой к заказчику. Отделы продаж работают с лидами и создают сделки. Служба

00:01:02.760 --> 00:01:06.460
поддержки клиентов обрабатывает вопросы и обращения. Выездное обслуживание планирует задачи и

00:01:06.460 --> 00:01:09.840
отправляет специалистов на объекты. Проектные команды следят за выполнением обязательств перед

00:01:09.840 --> 00:01:13.880
клиентом. Разная работа требует разных интерфейсов. Продавцу не нужно копаться в финансовом

00:01:13.880 --> 00:01:18.200
интерфейсе только ради того, чтобы обновить контакт после звонка. Но финансовому специалисту

00:01:18.200 --> 00:01:22.520
нужны данные клиента и заказа, соответствующие продажам, ведь счета и поставки

00:01:22.520 --> 00:01:27.340
зависят от этой информации. Без связи один клиент незаметно превращается в две разные записи.

00:01:27.460 --> 00:01:33.020
В продажах может быть Нортвинд Байкс, а в финансах Нортвинд Бисикл Компани. О, в одной записи

00:01:33.020 --> 00:01:37.980
новый адрес, а в другой счета все еще уходит в старый офис. Обе записи выглядят логично по отдельности,

00:01:38.180 --> 00:01:42.340
но они больше не описывают одни и те же деловые отношения. Сначала возникают мелкие проблемы.

00:01:42.540 --> 00:01:46.620
Кто-то не может найти клиента, потому что его имя в другом приложении отличается. Продавец обещает

00:01:46.620 --> 00:01:50.760
цену или проверяет остатки, но информация не совпадает с операционной системой. Финансистам

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

00:01:54.860 --> 00:01:59.260
Затем эти мелкие проблемы накапливаются. Кто-то выгружает данные клиентов в электронную таблицу,

00:01:59.400 --> 00:02:03.380
кто-то другой правит несколько строк и импортирует их куда-то еще. Кто-то третий вводит нового

00:02:03.380 --> 00:02:07.420
клиента в обе программы, потому что никто не знает, где запись появится раньше. Вскоре появляются

00:02:07.420 --> 00:02:12.000
дубликаты, разные адреса и куча времени уходит не на работу, а на сверку данных. Все это происходит

00:02:12.000 --> 00:02:15.620
не из-за невнимательности людей. Это происходит потому, что системы вынуждают людей самих становиться

00:02:15.620 --> 00:02:19.400
связующим звеном. Люди копируют данные, люди запоминают, какое приложение использовать первым.

00:02:19.400 --> 00:02:23.000
Люди замечают ошибки уже после того, как они дошли до другой команды. Такой подход работал,

00:02:23.120 --> 00:02:26.640
когда бизнес-системы были раздельными, а команды мирились с задержками. Но когда отделы продаж,

00:02:26.740 --> 00:02:30.000
обслуживания, финансов и операций нуждаются в одной и той же информации о клиенте в течение дня,

00:02:30.200 --> 00:02:32.380
электронная таблица становится плохим инструментом передачи данных.

00:02:32.540 --> 00:02:35.760
Вспомните простой разговор о заказе. Клиент звонит в отдел продаж и спрашивает,

00:02:35.960 --> 00:02:39.860
сможете ли вы доставить заказ на следующей неделе. И сколько это будет стоить? Отделу продаж для

00:02:39.860 --> 00:02:44.040
ответа нужны сведения о товаре, цене и наличии на складе. Как только клиент соглашается,

00:02:44.040 --> 00:02:48.160
отделам финансов и операций нужны точные данные о клиенте и заказе для оформления сделки.

00:02:48.360 --> 00:02:52.020
Обеим сторонам нужны одни и те же факты. Отделу продаж и эти факты нужны в приложении,

00:02:52.160 --> 00:02:55.600
в котором работают менеджеры. Финансистам и специалистам по операциям они нужны в приложении,

00:02:55.720 --> 00:02:59.220
где они управляют заказами, финансами и доставкой. Цель состоит не в том, чтобы заставить

00:02:59.220 --> 00:03:03.260
каждую команду работать в одном гигантском приложении. Цель в том, чтобы общие записи следовали

00:03:03.260 --> 00:03:07.020
четкому, согласованному маршруту. Именно здесь на сцену выходит Далрайт.

00:03:07.020 --> 00:03:13.040
Что же такое Далрайт на самом деле? Вот самое простое определение. Далрайт – это встроенное

00:03:13.040 --> 00:03:17.080
решение Microsoft, которое синхронизирует выбранные данные между приложениями Dynamics

00:03:17.080 --> 00:03:21.980
365, Finance & Operations и Dataverse. Dataverse – это общая платформа данных для многих

00:03:21.980 --> 00:03:27.180
бизнес-приложений Microsoft. Ее используют Dynamics 365 Sales, Customer Service, Field Service и некоторые

00:03:27.180 --> 00:03:31.700
компоненты Project Operations. PowerApps и PowerAutomate также могут ее использовать. Вам не нужно знать,

00:03:31.700 --> 00:03:35.800
как именно Dataverse хранит каждую запись, чтобы понять Далрайт. Просто рассматривайте его как общую

00:03:35.800 --> 00:03:40.700
область данных на стороне клиентских приложений Dynamics 365. Представьте офисные здания с передним

00:03:40.700 --> 00:03:45.300
и задним офисом. Передний офис занимается общением с клиентами. Менеджеры по продажам,

00:03:45.500 --> 00:03:49.980
агенты по обслуживанию, выездные специалисты. Им нужны экраны, которые помогают общаться с людьми,

00:03:50.200 --> 00:03:54.040
отслеживать запросы и управлять работой. Задний офис занимается работой, которая обеспечивает

00:03:54.040 --> 00:03:59.340
функционирование компании. Финансовая отчетность, склад, заказы, закупки, доставка. Оба офиса работают

00:03:59.340 --> 00:04:02.960
на одну компанию, но без надлежащей связи между ними кому-то приходится буквально переносить

00:04:02.960 --> 00:04:07.260
информацию из одной стороны в другую. Они несут распечатанный бланк, отправляют письмо или копируют

00:04:07.260 --> 00:04:10.820
данные в другую систему. Работа все равно выполняется, но это занимает больше времени,

00:04:11.020 --> 00:04:14.900
а детали могут искажаться по пути. Далрайт – это как служебная внутренняя дверь между этими

00:04:14.900 --> 00:04:18.480
двумя офисами. Когда поддерживаемая запись изменяется с одной стороны, Далрайт передает

00:04:18.480 --> 00:04:22.260
соответствующие изменения через эту дверь на другую сторону. Это не объединяет все приложения в одну

00:04:22.260 --> 00:04:26.200
гигантскую программу. Отдел продаж по-прежнему работает в своей среде. Финансовый отдел по-прежнему

00:04:26.200 --> 00:04:29.840
работает в своей. Каждая команда сохраняет свои интерфейсы, в то время как выбранная общая информация

00:04:29.840 --> 00:04:33.960
остается связанной в фоновом режиме. Это слово, поддерживаемый, имеет значение. Далрайт не

00:04:33.960 --> 00:04:38.480
копирует бездумно все данные в обе системы. Система работает через заданные связи между записями,

00:04:38.640 --> 00:04:43.360
которые должны быть объединены. Майкрософт называет эти связи картами таблиц. Таблица – это просто

00:04:43.360 --> 00:04:48.200
место, где приложение хранит один тип записей. Таблица клиентов хранит записи о клиентах. Таблица

00:04:48.200 --> 00:04:52.900
товаров хранит записи о товарах. Таблица адресов хранит сведения об адресах. Карта таблиц сообщает

00:04:52.900 --> 00:04:57.980
Далрайт, какая таблица в Finance and Operations связана с какой таблицей в Dataverse. Представьте карту таблиц,

00:04:57.980 --> 00:05:02.340
как согласованный лист перевода. Один столбец определяет запись с одной стороны. Другой столбец

00:05:02.340 --> 00:05:05.840
определяет соответствующую ей запись с другой стороны. Остальная часть листа поясняет,

00:05:06.000 --> 00:05:10.120
какие поля должны соответствовать друг другу. Например, имя, номер телефона, строка адреса.

00:05:10.220 --> 00:05:14.220
Это соглашение задает правила связи. Без него два приложения могли бы использовать разные метки

00:05:14.220 --> 00:05:18.500
или хранить одни и те же детали в разных местах. Карта сообщает Далрайт, как связаны эти детали.

00:05:18.640 --> 00:05:23.340
Поэтому приложениям не нужен человек для их интерпретации каждый раз. Часто, услышав название Далрайт,

00:05:23.340 --> 00:05:27.600
люди предполагают, что любые изменения всегда передаются в обе стороны. Иногда это так.

00:05:27.600 --> 00:05:31.640
Для поддерживаемой двусторонней карты изменение в Dataverse может обновить связанную запись в

00:05:31.640 --> 00:05:35.980
Finance and Operations. Поддерживаемое изменение в Finance and Operations также может обновить связанную

00:05:35.980 --> 00:05:39.820
запись в Dataverse. Обе стороны могут участвовать в работе с одной и той же общей записью. В этом

00:05:39.820 --> 00:05:44.120
и заключается суть Далрайт. Обновление происходит практически в реальном времени. Оно происходит быстро,

00:05:44.320 --> 00:05:48.540
по мере работы, а не в ожидании запланированной ночной задачи. Пользователь обновляет поддерживаемую

00:05:48.540 --> 00:05:53.320
запись и соединение отправляет это обновление, пока работа еще актуальна. Почти реальное время не

00:05:53.320 --> 00:05:57.280
означает магию или нулевую задержку. Это означает, что соединение создано для оперативной

00:05:57.280 --> 00:06:01.300
бизнес-работы, а не для ежедневного обмена файлами. Если кто-то меняет деталь, связанной команде

00:06:01.300 --> 00:06:04.940
не нужно ждать завтрашнего утра, чтобы увидеть это. Это меняет подход к работе команд.

00:06:05.120 --> 00:06:09.040
Фронт-офис может использовать данные, поступающие из бэк-офиса. Бэк-офис может получать

00:06:09.040 --> 00:06:13.180
поддерживаемые обновления из клиентских приложений. Dataverse становится фундаментом данных с одной

00:06:13.180 --> 00:06:17.500
стороны, Finance and Operations остается операционной основой с другой, а Далрайт поддерживает связь

00:06:17.500 --> 00:06:22.360
утвержденных общих записей. Тем не менее, для такой «открытой двери» нужны правила. Прежде чем позволить

00:06:22.360 --> 00:06:25.820
записи передаваться в обоих направлениях, нужно определить, где она должна создаваться,

00:06:25.820 --> 00:06:29.680
кто может ее менять и чья сторона главнее при возникновении разногласий между приложениями.

00:06:29.760 --> 00:06:34.440
Какие данные могут перемещаться и какая система ими управляет. Итак, какие записи Далрайт

00:06:34.440 --> 00:06:38.460
может поддерживать связанными. Типичные примеры начинаются с записей, которые ежедневно

00:06:38.460 --> 00:06:43.280
используют многие отделы. Записи о клиентах, адреса, контакты, продукты, поставщики,

00:06:43.540 --> 00:06:48.240
сведения о компании и справочная информация для финансов и налогов. Давайте на минуту задумаемся

00:06:48.240 --> 00:06:54.000
о записи клиента. Отделу продаж нужны имя клиента, основной контакт, номер телефона и адрес доставки.

00:06:54.000 --> 00:06:58.780
Финансовому отделу нужны юридические данные клиента, платежные реквизиты и информация для заказов

00:06:58.780 --> 00:07:03.220
и счетов. Если каждый отдел ведет свой собственный список клиентов, компания тратит время на сверку

00:07:03.220 --> 00:07:07.200
записей вместо обслуживания клиента. При наличии правильных карт Далрайт эти команды могут

00:07:07.200 --> 00:07:10.900
работать со связанными данными клиентов. Это не значит, что пользователям отдела продаж нужно

00:07:10.900 --> 00:07:14.860
срочно изучать финансовые приложения. Это означает, что они могут работать с информацией о клиентах

00:07:14.860 --> 00:07:19.680
в Dynamics 365 Sales, а финансовые специалисты – соответствующие информации в приложении Finance.

00:07:19.680 --> 00:07:24.780
Клиент остается узнаваемым как один и тот же объект в обоих местах. Адреса тоже имеют значение.

00:07:24.960 --> 00:07:29.100
У клиента может быть платежный адрес, адрес доставки и, возможно, объект, который должен посетить

00:07:29.100 --> 00:07:32.860
сервисный специалист. Эти данные нельзя просто скопировать в одно поле, как обычный текст,

00:07:33.060 --> 00:07:36.980
поскольку у каждого адреса своя задача. Далрайт поддерживает общую структуру записей,

00:07:37.140 --> 00:07:41.440
необходимую для таких связей. С контактами дело обстоит также. У одной компании клиента могут быть

00:07:41.440 --> 00:07:45.440
покупатель, контакт по расчетам с кредиторами и менеджер по обслуживанию. Отделу продаж нужно знать,

00:07:45.440 --> 00:07:48.960
кто принимает решения. Финансовому отделу нужно знать, кому направлять вопросы по счетам.

00:07:49.120 --> 00:07:52.960
Сервисной службе нужно знать, кто ждет их на объекте. Связанные записи помогают каждой команде

00:07:52.960 --> 00:07:56.140
видеть людей, относящихся к клиенту, не дублируя эту информацию в каждом приложении.

00:07:56.280 --> 00:07:59.720
Продукты – еще один распространенный пример. Торговому представителю нужно знать,

00:07:59.900 --> 00:08:04.080
что продает компания, какова стоимость продукта и есть ли он в наличии. Эти ответы обычно приходят

00:08:04.080 --> 00:08:08.240
из операционной части бизнеса, так как именно там управляют продуктами, запасами, закупками и выполнением

00:08:08.240 --> 00:08:12.220
заказов. Вот почему информация о продуктах часто создается в модуле финансов и операций.

00:08:12.220 --> 00:08:17.100
Операционная команда создает и подготавливает продукт там. Как только продукт готов для работы

00:08:17.100 --> 00:08:22.460
с клиентами, Далрайт передает соответствующие сведения в Dataverse. Пользователи отдела продаж

00:08:22.460 --> 00:08:27.020
могут выбирать и обсуждать продукт в своем приложении без повторного ввода списка продуктов.

00:08:27.180 --> 00:08:30.840
Это помогает строить беседы с клиентами на основе того, что бизнес действительно может

00:08:30.840 --> 00:08:34.840
предоставить. Данные о ценах и складских запасах также могут поступать в отдел продаж через

00:08:34.840 --> 00:08:39.260
связанные приложения. Вместо того, чтобы гадать, существует ли товар, изменилась ли цена и позволяют

00:08:39.260 --> 00:08:43.080
ли запасы выполнить обещания. Отдел продаж может опираться на информацию, связанную с

00:08:43.080 --> 00:08:47.320
операционной стороной. Это не отменяет необходимости в хорошем коммерческом чутье. Это устраняет

00:08:47.320 --> 00:08:50.940
одну лишнюю причину, по которой торговый представитель звонит на склад для уточнения базовых

00:08:50.940 --> 00:08:54.420
деталей. Информация о поставщиках также может передаваться туда, где она требуется для

00:08:54.420 --> 00:08:58.460
бизнес-процессов. Реквизиты компании, организационные структуры, финансовые и налоговые

00:08:58.460 --> 00:09:01.900
справочные данные могут быть важны как для клиентской, так и для операционной стороны.

00:09:02.120 --> 00:09:06.680
Конкретные записи зависят от приложений и процессов компании, но общая схема остается прежней.

00:09:06.680 --> 00:09:11.000
Обменивайтесь записями, которые должны означать одно и то же в обеих системах. Не стоит полагать,

00:09:11.180 --> 00:09:14.940
что каждая запись должна передаваться в обоих направлениях. Некоторые приложения поддерживают

00:09:14.940 --> 00:09:19.700
двусторонние обновления. Изменение может начаться в Dataverse и перейти в Finance and Operations

00:09:19.700 --> 00:09:24.620
или наоборот. Такой подход подходит для записей, где обе стороны имеют веские деловые причины для

00:09:24.620 --> 00:09:29.120
обновления данных. Другие схемы работают в одном направлении. Продукты – отличный тому пример.

00:09:29.300 --> 00:09:33.840
Во многих компаниях создание продуктов закреплено за Finance and Operations, поскольку она управляет

00:09:33.840 --> 00:09:38.640
мастер данными продуктов, запасами и другими деталями, необходимыми для продаж. Затем информация

00:09:38.640 --> 00:09:42.800
о продукте передается в Dataverse, где ее используют отделы продаж и обслуживания. Это четкое

00:09:42.800 --> 00:09:46.600
правило. Нет нужды в том, чтобы две команды создавали конкурирующие версии одного продукта.

00:09:46.740 --> 00:09:50.920
Одна сторона создает продукт и управляет им, а другая получает его и использует в своей работе.

00:09:51.040 --> 00:09:55.300
Для каждой общей записи требуется подобное решение. Где создается эта запись? Кто может ее

00:09:55.300 --> 00:09:59.320
редактировать? Если название, адрес, цена или классификация выглядят неверно, какая команда должна

00:09:59.320 --> 00:10:02.880
это исправить? Эти вопросы звучат просто, но они предотвращают массу путаницы в будущем.

00:10:03.060 --> 00:10:06.580
Связь позволяет очень быстро передавать изменения. Если не определено, кто отвечает за эти

00:10:06.580 --> 00:10:10.440
изменения, так же быстро может распространиться и ошибка. Выберите владельца для записи, а при

00:10:10.440 --> 00:10:14.740
необходимости и для отдельных полей внутри нее. Например, отдел продаж может отвечать за данные

00:10:14.740 --> 00:10:18.440
о взаимоотношениях с клиентом и его основные контакты. Финансовый отдел может отвечать за

00:10:18.440 --> 00:10:22.860
платежные данные, а операционный – за данные о продуктах и запасах. Точное распределение зависит от

00:10:22.860 --> 00:10:26.700
специфики вашего бизнеса, но оно должно быть задокументировано и понятно сотрудникам.

00:10:26.700 --> 00:10:30.720
Существуют также два термина, которые вы встретите после расширения Dataverse через двойную запись

00:10:30.720 --> 00:10:35.100
«Сторона» – «Парти» и «Компания» – «Компани». Сторона – это способ Microsoft унифицированно

00:10:35.100 --> 00:10:39.740
работать с физическим или юридическим лицом. Это помогает связывать людей, организации,

00:10:39.940 --> 00:10:44.260
контакты и адреса, не рассматривая каждую связь как отдельную несвязанную запись.

00:10:44.420 --> 00:10:49.180
Компания помогает Dataverse понимать контекст бизнес-компании, используемой в «Finance and Operations».

00:10:49.180 --> 00:10:52.840
Вам не обязательно становиться экспертом по этим терминам в первый же день. Просто знайте об их

00:10:52.840 --> 00:10:55.660
существовании, поскольку финансы и операции обрабатывают бизнес-структуры,

00:10:55.660 --> 00:10:58.740
которые должны распознаваться клиентскими приложениями при перемещении записей между двумя

00:10:58.740 --> 00:11:02.600
странами. Как только записи могут перемещаться в обоих направлениях, процессы вокруг этих записей

00:11:02.600 --> 00:11:06.740
становятся не менее важными, чем сами данные. Как изменения передаются между приложениями?

00:11:06.900 --> 00:11:10.460
Давайте проследим за одним изменением в системе и посмотрим, что происходит на самом деле.

00:11:10.640 --> 00:11:14.180
Торговый представитель разговаривает с клиентом, который только что переехал в новый офис.

00:11:14.380 --> 00:11:19.500
Во время этого разговора представитель открывает запись клиента в Dynamics 365 Sales и обновляет адрес.

00:11:19.700 --> 00:11:24.400
Достаточно просто. Правда. Затем он сохраняет запись. И вот здесь начинается самое интересное.

00:11:24.400 --> 00:11:28.380
Sales сохраняет это изменение в Dataverse — это сторона данных для клиентских приложений.

00:11:28.540 --> 00:11:32.140
Затем механизм двойной записи проверяет карту, связывающую информацию о клиенте и адресе между

00:11:32.140 --> 00:11:36.140
этой стороной и финансами и операциями. Он автоматически отправляет соответствующие изменения.

00:11:36.340 --> 00:11:39.800
Никаких файлов экспорта, лежащих в общей папке в ожидании, пока их кто-то заберет.

00:11:39.920 --> 00:11:43.780
Никому не нужно писать в финансовый отдел с просьбой «Эй, пожалуйста, обновите этот адрес».

00:11:43.780 --> 00:11:48.400
Карта уже знает, какие поля связаны, и отправляет нужные изменения прямо в соответствующую запись

00:11:48.400 --> 00:11:52.760
клиента в финансах и операциях. Поэтому пользователь финансового отдела может позже открыть эту

00:11:52.760 --> 00:11:56.760
запись клиента, увидеть обновленный адрес и обработать заказ или подготовить счет без задержек.

00:11:56.900 --> 00:12:00.640
Вот и весь практический результат — просто и понятно. Два человека продолжают работать в разных

00:12:00.640 --> 00:12:03.680
приложениях, но никому не нужно повторно вводить одни и те же данные о клиенте.

00:12:03.780 --> 00:12:07.000
Торговый представитель работает в интерфейсе, разработанном для общения с клиентами.

00:12:07.160 --> 00:12:10.280
Пользователь финансового отдела работает в интерфейсе, созданном для финансовых задач.

00:12:10.280 --> 00:12:14.520
Каждый видит ту информацию о клиенте, которая ему действительно нужна, и именно там, где она нужна.

00:12:14.580 --> 00:12:18.520
И это работает и в обратном направлении тоже. Представьте, что финансовый отдел обновляет

00:12:18.520 --> 00:12:22.920
информацию о клиенте в финансах и операциях. Скажем, финансовый специалист исправляет деталь,

00:12:23.080 --> 00:12:26.980
которая относится к операционной записи клиента. Двойная запись использует соответствующую

00:12:26.980 --> 00:12:31.200
карту в обратном направлении и отправляет это обновление в Dataverse. Затем Sales или любое

00:12:31.200 --> 00:12:35.760
другое приложение на базе Dataverse может подхватить его. Это соединение является синхронным для

00:12:35.760 --> 00:12:39.580
обычной повседневной работы. Синхронность означает, что приложение пытается выполнить

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

00:12:43.500 --> 00:12:47.560
через 20 минут. Если соединение не может завершить обновление, эта проблема требует

00:12:47.560 --> 00:12:51.200
немедленного внимания, а не тихого ожидания, пока кто-то заметит несоответствие.

00:12:51.360 --> 00:12:55.180
Такое поведение логично для общих бизнес-записей. Вы же не хотите, чтобы адрес клиента,

00:12:55.360 --> 00:12:58.320
данные о продукте или другая общая информация расходились часами из-за того, что пакетное

00:12:58.320 --> 00:13:01.520
задание еще не сработало. Люди принимают решение на основе того, что они видят на своем

00:13:01.520 --> 00:13:05.200
экране прямо сейчас. Таким образом, соединение поддерживает тесную синхронизацию обеих сторон

00:13:05.200 --> 00:13:09.480
во время работы. Однако текущая работа иногда требует контролируемой паузы. Функция двойной записи

00:13:09.480 --> 00:13:13.160
включает параметры воспроизведения, паузы и наверстывания. Воспроизведение означает, что сопоставление

00:13:13.160 --> 00:13:16.160
работает и поддерживаемые изменения передаются в обычном режиме. Пауза временно останавливает

00:13:16.160 --> 00:13:19.280
сопоставление, когда команде нужно выполнить плановые работы, исследовать проблему или

00:13:19.280 --> 00:13:23.240
безопасно внести изменения. Но пауза – это не постоянное место для остановки. Пока сопоставление

00:13:23.240 --> 00:13:26.140
приостановлено, изменения могут накапливаться в очереди в течение ограниченного времени и

00:13:26.140 --> 00:13:29.520
объема. Когда сопоставление возобновляется, функция наверстывания обрабатывает эти ожидающие

00:13:29.520 --> 00:13:33.580
изменения. Это помогает командам восстановить работу после запланированного перерыва. Но кто-то должен

00:13:33.580 --> 00:13:37.820
отвечать за эту паузу и знать, когда сопоставление должно снова запуститься. Прежде чем все это начнет

00:13:37.820 --> 00:13:40.960
работать в повседневной деятельности. Есть еще один шаг – начальная синхронизация.

00:13:41.120 --> 00:13:44.860
Начальная синхронизация приводит существующие записи с обеих сторон к общей отправной точке.

00:13:45.000 --> 00:13:48.920
Представьте компанию, у которой уже есть клиенты в Finance and Operations и записи клиентов в

00:13:48.920 --> 00:13:52.720
Dataverse. Соединение не может просто включиться и предположить, что каждая существующая запись

00:13:52.720 --> 00:13:56.620
уже идеально совпадает. Нужна стартовая линия. Начальная синхронизация помогает перенести

00:13:56.620 --> 00:14:00.140
существующие данные до того, как пользователи начнут полагаться на обновление в реальном времени.

00:14:00.320 --> 00:14:04.040
Эта работа требует осторожности, потому что дубликаты записей, неполные адреса и старые

00:14:04.040 --> 00:14:07.440
тестовые данные не очищаются магическим образом только из-за запуска синхронизации.

00:14:07.620 --> 00:14:11.660
Напротив, они могут создать проблемы еще быстрее, если записи не следуют согласованным правилам.

00:14:11.780 --> 00:14:15.560
Когда сопоставления запущены, людям, управляющим двойной записью, нужно четкое место для проверки

00:14:15.560 --> 00:14:19.100
работоспособности. Двойная запись предоставляет объединенные журналы действий и ошибок,

00:14:19.160 --> 00:14:22.320
чтобы администраторы могли видеть, что обработало соединение и где возникли проблемы.

00:14:22.320 --> 00:14:26.780
Они также могут устанавливать оповещения и пороговые значения. Это означает, что нужные люди узнают

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

00:14:30.500 --> 00:14:33.520
Это представление поддержки важно, потому что у каждой ошибки есть причина.

00:14:33.520 --> 00:14:37.380
Возможно, отсутствует обязательное поле. Возможно, связанная запись еще не поступила.

00:14:37.500 --> 00:14:40.280
Возможно, кто-то изменил данные способом, который не соответствует сопоставлению.

00:14:40.420 --> 00:14:44.080
Повторная попытка обработки неудачной записи без устранения причины обычно просто приводит к

00:14:44.080 --> 00:14:47.760
повторному сбою. Хорошо настроенная система двойной записи очлеживает соединение,

00:14:47.920 --> 00:14:51.560
устраняет причины ошибок и фокусируется поставление на записях, которые действительно

00:14:51.560 --> 00:14:54.780
должны оставаться связанными. Где двойная запись подходит лучше всего?

00:14:54.940 --> 00:14:58.760
Двойная запись лучше всего подходит, когда ваш бизнес использует Dynamics 365 Finance или

00:14:58.760 --> 00:15:02.320
Supply Chain Management вместе с клиентскими приложениями, такими как продажи, обслуживание клиентов,

00:15:02.320 --> 00:15:06.540
выездное обслуживание или управление проектами. Эти приложения поддерживают разные части одного и

00:15:06.540 --> 00:15:10.640
того же делового процесса. Одна команда общается с клиентом, другая планирует доставку,

00:15:10.840 --> 00:15:14.800
управляет запасами, очлеживает расходы или отправляет счета. Когда обеим группам необходимо

00:15:14.800 --> 00:15:18.660
работать со связанными записями в течение дня, функция двойной записи «Далрайт» может объединить

00:15:18.660 --> 00:15:22.280
эту работу, не заставляя всех переходить в одно приложение. Возьмем в качестве примера процесс

00:15:22.280 --> 00:15:27.240
от потенциальной сделки до оплаты. Продавец работает с потенциальным клиентом в Dynamics 365 Sales.

00:15:27.420 --> 00:15:30.600
Он очлеживает контакты, обсуждает продукты, формирует коммерческое предложение

00:15:30.600 --> 00:15:34.620
и переходит к оформлению заказа. В ходе этого общения продавцу требуются данные о клиенте,

00:15:34.740 --> 00:15:38.580
информация о продукте, цены и сведения о заказе, которые относятся к финансовой стороне

00:15:38.580 --> 00:15:42.440
компании. Как только сделка совершена, финансовый отдел и отдел управления цепочками поставок

00:15:42.440 --> 00:15:46.080
берут на себя работу, которая следует за обещанием продажи. Они занимаются выполнением заказа,

00:15:46.180 --> 00:15:48.600
складским учетом, выставлением счетов и ведением финансовой отчетности.

00:15:48.780 --> 00:15:52.620
Двойная запись помогает этим двум частям оставаться на связи. Продавцы могут работать в клиентском

00:15:52.620 --> 00:15:55.940
приложении, которое соответствует их задачам, в то время как специалисты по финансам и операциям

00:15:55.940 --> 00:15:59.480
управляют транзакцией в приложении, созданном для их работы. История клиента не разделяется на две

00:15:59.480 --> 00:16:02.580
разные версии. Одну – от отдела продаж, другую – от финансового отдела.

00:16:02.680 --> 00:16:06.340
Филд-сервис – еще один хороший пример. Представьте компанию, которая отправляет технических

00:16:06.340 --> 00:16:09.300
специалистов для установки, ремонта или обслуживания оборудования на объектах клиентов.

00:16:09.440 --> 00:16:12.900
Выездному сотруднику нужны данные о клиенте, подробности о работе и информации о клиентском

00:16:12.900 --> 00:16:17.040
активе, оборудовании, которое компания установила или обслуживает. За кулисами компания также должна

00:16:17.040 --> 00:16:20.740
отслеживать детали, расходы, закупки и денежные средства, связанные с этой работой.

00:16:20.740 --> 00:16:25.120
Филд-сервис фокусируется на планировании и выполнении визита. Finance and Operations фокусируется

00:16:25.120 --> 00:16:29.320
на операционных и финансовых записях вокруг этого процесса. Когда эти записи правильно связаны,

00:16:29.580 --> 00:16:33.600
работа техника не отделяется от использованных деталей, стоимости работ или связанной с ними

00:16:33.600 --> 00:16:38.300
записи клиента. Project Operations следует той же схеме, особенно для компаний, которые продают

00:16:38.300 --> 00:16:42.360
работу по проектам. Проектная команда может управлять работой с клиентом, временем сотрудников,

00:16:42.500 --> 00:16:46.160
плановыми затратами и этапами проекта. Финансовому отделу необходимо видеть финансовую

00:16:46.160 --> 00:16:50.440
сторону закупок, затрат, выставление счетов и отчетности. Без связи менеджеры проектов

00:16:50.440 --> 00:16:54.800
могут тратить слишком много времени на запросы обновлению финансистов, пока те ждут от команд

00:16:54.800 --> 00:16:59.120
подтверждения произошедших событий. Связанные проектные записи дают обеим группам более четкое

00:16:59.120 --> 00:17:02.780
представление о ходе работы по мере ее перехода от обещания клиенту к финансовой деятельности.

00:17:02.960 --> 00:17:06.900
Здесь также есть более широкое преимущество Power Platform, поскольку сторона клиентского приложения

00:17:06.900 --> 00:17:10.800
использует Dataverse, а одобренные данные в Dataverse могут поддерживать Power Apps и Power Automate.

00:17:11.000 --> 00:17:14.940
Компания может создать небольшое приложение для внутренней команды или настроить поток, который реагирует,

00:17:14.940 --> 00:17:19.160
когда бизнес-запись достигает определенного статуса. Это не означает, что каждая запись из Finance and Operations

00:17:19.160 --> 00:17:22.880
должна внезапно появиться в каждом приложении Power App. Это означает, что связанные записи могут

00:17:22.880 --> 00:17:26.280
стать частью более широкого набора бизнес-инструментов, если компания тщательно определяет

00:17:26.280 --> 00:17:29.820
эту цель и должным образом защищает данные. Одна граница должна оставаться четкой.

00:17:29.980 --> 00:17:34.860
Dalright не поддерживает Dynamics 365 Business Central. Бизнес-централ может подключаться к другим

00:17:34.860 --> 00:17:38.560
продуктам Microsoft иными способами, но Dalright предназначен для финансово-операционного

00:17:38.560 --> 00:17:43.220
направления Dynamics 365 и клиентских приложений на базе Dataverse. Это также не инструмент для

00:17:43.220 --> 00:17:47.160
копирования каждой таблицы, которую вы можете найти. Запись должна перемещаться, если людям

00:17:47.160 --> 00:17:50.460
нужна одна и та же операционная запись в обоих местах, а не потому, что копирование данных

00:17:50.460 --> 00:17:53.780
кажется более безопасным. Dalright также не заменяет более широкий план интеграции,

00:17:53.880 --> 00:17:57.300
когда компании требуются каналы отчетности, связи со сторонними системами или масштабная

00:17:57.300 --> 00:18:01.200
миграция данных. Если относиться к каждому подключению данных как к одной и той же задаче,

00:18:01.360 --> 00:18:05.640
это быстро создает проблемы. Ограничения, подготовка и распространенные ошибки

00:18:05.640 --> 00:18:10.220
Представьте Dalright как рукопожатие между двумя системами. Они договариваются синхронизировать

00:18:10.220 --> 00:18:14.620
определенные общие записи, но это не волшебный канал для любой таблицы, отчета или внешней системы.

00:18:14.620 --> 00:18:18.680
Прежде чем настраивать систему, проверьте, какие интеграции уже существуют. Если старое

00:18:18.680 --> 00:18:22.480
подключение и Dalright одновременно обновляют одну и ту же запись клиента, могут быстро возникнуть

00:18:22.480 --> 00:18:26.420
конфликты. Это головная боль, которая вам не нужна. Поэтому сначала договоритесь об основах.

00:18:26.520 --> 00:18:30.200
Как вы будете вводить имена? Какая юридическая компания владеет каждой записью? Кто может

00:18:30.200 --> 00:18:34.600
вносить изменения? Какие роли безопасности нужны каждой команде? Дубликаты и неполные записи

00:18:34.600 --> 00:18:38.960
перед первой синхронизацией. Начните с готовых карт от Microsoft. Они уже соединяют распространенные

00:18:38.960 --> 00:18:42.960
типы записей. Пользовательские таблицы и поля требуют тщательного тестирования. Проверьте связанные

00:18:42.960 --> 00:18:46.900
таблицы и зависимости карт, потому что иногда для синхронизации одной записи требуется наличие

00:18:46.900 --> 00:18:50.720
другой. Планируйте первую синхронизацию, исходя из объема ваших данных. Не относитесь к этому как

00:18:50.720 --> 00:18:54.000
к выключателю света, который можно щелкнуть во время обеда. Это приведет к проблемам. Для

00:18:54.000 --> 00:18:58.080
приостановленной карты по-прежнему нужны владелец и план перезапуска. Очереди изменений и неудачные

00:18:58.080 --> 00:19:02.160
записи не хранятся вечно. Следите за журналами активности, ошибками, оповещениями и пороговыми

00:19:02.160 --> 00:19:06.220
значениями. Когда что-то не получается, найдите отсутствующее поле, неверную запись или нарушенное

00:19:06.220 --> 00:19:10.200
правило. Многократные повторные попытки не исправят плохие данные. Когда вы воспринимаете

00:19:10.200 --> 00:19:15.520
Далрайт как контролируемый мост, все встает на свои места. Заключение – единый общий бизнес-диалог.

00:19:15.720 --> 00:19:19.420
Далрайт обеспечивает перемещение поддерживаемых общих записей между финансово-операционными

00:19:19.420 --> 00:19:23.340
системами и вашими клиентскими приложениями на базе Dataverse. Благодаря этому команды могут

00:19:23.340 --> 00:19:27.640
работать с взаимосвязанными бизнес-данными. Подписывайтесь на своей любимой подкаст-платформе,

00:19:27.820 --> 00:19:33.540
чтобы получать больше полезных знаний со мной, Мирко Питерсом, на m365.fm. И поделитесь этим выпуском

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