Продавец обновляет адрес клиента. Позже финансовый отдел открывает ту же запись и все еще видит старый адрес. Итак, какой же адрес верный? Годами это решалось так. Кто-то выгружал данные, правил таблицу, отправлял ее по почте и вручную вводил обновление во второе приложение. Dynamics 365 Dollright меняет это. Он связывает финансово-операционные приложения с клиентскими приложениями на базе Dataverse, поэтому общие записи, такие как клиенты и заказы, синхронизируются автоматически. С вами я, Милка Петерс из M365FM, и этот полезный совет объясняет суть Dollright простыми словами. Мы разберем, что передается, как это работает, где Dollright применим, а где нет. Для начала давайте перейдем к бизнес-проблеме, которая вызвала необходимость в этом решении. Проблема, которую решает Dollright. Представьте бизнес, где две группы работают с одним клиентом, но ежедневно используют совершенно разные приложения. Финансово-операционные приложения отвечают за бэк-офис. Это финансы, запасы, продукты, заказы, закупки и цепочки поставок. Здесь компания очлеживает продажи, возможности поставок, свои долги и платежи клиентов. Клиентские приложения сосредоточены на работе, близкой к заказчику. Отделы продаж работают с лидами и создают сделки. Служба поддержки клиентов обрабатывает вопросы и обращения. Выездное обслуживание планирует задачи и отправляет специалистов на объекты. Проектные команды следят за выполнением обязательств перед клиентом. Разная работа требует разных интерфейсов. Продавцу не нужно копаться в финансовом интерфейсе только ради того, чтобы обновить контакт после звонка. Но финансовому специалисту нужны данные клиента и заказа, соответствующие продажам, ведь счета и поставки зависят от этой информации. Без связи один клиент незаметно превращается в две разные записи.

В продажах может быть Нортвинд Байкс, а в финансах Нортвинд Бисикл Компани. О, в одной записи новый адрес, а в другой счета все еще уходит в старый офис. Обе записи выглядят логично по отдельности, но они больше не описывают одни и те же деловые отношения. Сначала возникают мелкие проблемы. Кто-то не может найти клиента, потому что его имя в другом приложении отличается. Продавец обещает цену или проверяет остатки, но информация не совпадает с операционной системой. Финансистам нужно обработать заказ, но данные клиента требуют проверки, писем и ручного обновления. Затем эти мелкие проблемы накапливаются. Кто-то выгружает данные клиентов в электронную таблицу, кто-то другой правит несколько строк и импортирует их куда-то еще. Кто-то третий вводит нового клиента в обе программы, потому что никто не знает, где запись появится раньше. Вскоре появляются дубликаты, разные адреса и куча времени уходит не на работу, а на сверку данных. Все это происходит не из-за невнимательности людей. Это происходит потому, что системы вынуждают людей самих становиться связующим звеном. Люди копируют данные, люди запоминают, какое приложение использовать первым.

Люди замечают ошибки уже после того, как они дошли до другой команды. Такой подход работал, когда бизнес-системы были раздельными, а команды мирились с задержками. Но когда отделы продаж, обслуживания, финансов и операций нуждаются в одной и той же информации о клиенте в течение дня, электронная таблица становится плохим инструментом передачи данных. Вспомните простой разговор о заказе. Клиент звонит в отдел продаж и спрашивает, сможете ли вы доставить заказ на следующей неделе. И сколько это будет стоить? Отделу продаж для ответа нужны сведения о товаре, цене и наличии на складе. Как только клиент соглашается, отделам финансов и операций нужны точные данные о клиенте и заказе для оформления сделки. Обеим сторонам нужны одни и те же факты. Отделу продаж и эти факты нужны в приложении, в котором работают менеджеры. Финансистам и специалистам по операциям они нужны в приложении, где они управляют заказами, финансами и доставкой. Цель состоит не в том, чтобы заставить каждую команду работать в одном гигантском приложении. Цель в том, чтобы общие записи следовали четкому, согласованному маршруту. Именно здесь на сцену выходит Далрайт.

Что же такое Далрайт на самом деле? Вот самое простое определение. Далрайт – это встроенное решение Microsoft, которое синхронизирует выбранные данные между приложениями Dynamics 365, Finance & Operations и Dataverse. Dataverse – это общая платформа данных для многих бизнес-приложений Microsoft. Ее используют Dynamics 365 Sales, Customer Service, Field Service и некоторые компоненты Project Operations. PowerApps и PowerAutomate также могут ее использовать. Вам не нужно знать, как именно Dataverse хранит каждую запись, чтобы понять Далрайт. Просто рассматривайте его как общую область данных на стороне клиентских приложений Dynamics 365. Представьте офисные здания с передним и задним офисом. Передний офис занимается общением с клиентами. Менеджеры по продажам, агенты по обслуживанию, выездные специалисты. Им нужны экраны, которые помогают общаться с людьми, отслеживать запросы и управлять работой. Задний офис занимается работой, которая обеспечивает функционирование компании. Финансовая отчетность, склад, заказы, закупки, доставка. Оба офиса работают на одну компанию, но без надлежащей связи между ними кому-то приходится буквально переносить информацию из одной стороны в другую. Они несут распечатанный бланк, отправляют письмо или копируют данные в другую систему. Работа все равно выполняется, но это занимает больше времени, а детали могут искажаться по пути. Далрайт – это как служебная внутренняя дверь между этими двумя офисами. Когда поддерживаемая запись изменяется с одной стороны, Далрайт передает соответствующие изменения через эту дверь на другую сторону. Это не объединяет все приложения в одну гигантскую программу. Отдел продаж по-прежнему работает в своей среде. Финансовый отдел по-прежнему работает в своей. Каждая команда сохраняет свои интерфейсы, в то время как выбранная общая информация остается связанной в фоновом режиме. Это слово, поддерживаемый, имеет значение. Далрайт не копирует бездумно все данные в обе системы. Система работает через заданные связи между записями, которые должны быть объединены. Майкрософт называет эти связи картами таблиц. Таблица – это просто место, где приложение хранит один тип записей. Таблица клиентов хранит записи о клиентах. Таблица товаров хранит записи о товарах. Таблица адресов хранит сведения об адресах. Карта таблиц сообщает Далрайт, какая таблица в Finance and Operations связана с какой таблицей в Dataverse. Представьте карту таблиц, как согласованный лист перевода. Один столбец определяет запись с одной стороны. Другой столбец определяет соответствующую ей запись с другой стороны. Остальная часть листа поясняет, какие поля должны соответствовать друг другу. Например, имя, номер телефона, строка адреса.

Это соглашение задает правила связи. Без него два приложения могли бы использовать разные метки или хранить одни и те же детали в разных местах. Карта сообщает Далрайт, как связаны эти детали. Поэтому приложениям не нужен человек для их интерпретации каждый раз. Часто, услышав название Далрайт, люди предполагают, что любые изменения всегда передаются в обе стороны. Иногда это так. Для поддерживаемой двусторонней карты изменение в Dataverse может обновить связанную запись в Finance and Operations. Поддерживаемое изменение в Finance and Operations также может обновить связанную запись в Dataverse. Обе стороны могут участвовать в работе с одной и той же общей записью. В этом и заключается суть Далрайт. Обновление происходит практически в реальном времени. Оно происходит быстро, по мере работы, а не в ожидании запланированной ночной задачи. Пользователь обновляет поддерживаемую запись и соединение отправляет это обновление, пока работа еще актуальна. Почти реальное время не означает магию или нулевую задержку. Это означает, что соединение создано для оперативной бизнес-работы, а не для ежедневного обмена файлами. Если кто-то меняет деталь, связанной команде не нужно ждать завтрашнего утра, чтобы увидеть это. Это меняет подход к работе команд.

Фронт-офис может использовать данные, поступающие из бэк-офиса. Бэк-офис может получать поддерживаемые обновления из клиентских приложений. Dataverse становится фундаментом данных с одной стороны, Finance and Operations остается операционной основой с другой, а Далрайт поддерживает связь утвержденных общих записей. Тем не менее, для такой «открытой двери» нужны правила. Прежде чем позволить записи передаваться в обоих направлениях, нужно определить, где она должна создаваться, кто может ее менять и чья сторона главнее при возникновении разногласий между приложениями. Какие данные могут перемещаться и какая система ими управляет. Итак, какие записи Далрайт может поддерживать связанными. Типичные примеры начинаются с записей, которые ежедневно используют многие отделы. Записи о клиентах, адреса, контакты, продукты, поставщики, сведения о компании и справочная информация для финансов и налогов. Давайте на минуту задумаемся о записи клиента. Отделу продаж нужны имя клиента, основной контакт, номер телефона и адрес доставки.

Финансовому отделу нужны юридические данные клиента, платежные реквизиты и информация для заказов и счетов. Если каждый отдел ведет свой собственный список клиентов, компания тратит время на сверку записей вместо обслуживания клиента. При наличии правильных карт Далрайт эти команды могут работать со связанными данными клиентов. Это не значит, что пользователям отдела продаж нужно срочно изучать финансовые приложения. Это означает, что они могут работать с информацией о клиентах в Dynamics 365 Sales, а финансовые специалисты – соответствующие информации в приложении Finance. Клиент остается узнаваемым как один и тот же объект в обоих местах. Адреса тоже имеют значение. У клиента может быть платежный адрес, адрес доставки и, возможно, объект, который должен посетить сервисный специалист. Эти данные нельзя просто скопировать в одно поле, как обычный текст, поскольку у каждого адреса своя задача. Далрайт поддерживает общую структуру записей, необходимую для таких связей. С контактами дело обстоит также. У одной компании клиента могут быть покупатель, контакт по расчетам с кредиторами и менеджер по обслуживанию. Отделу продаж нужно знать, кто принимает решения. Финансовому отделу нужно знать, кому направлять вопросы по счетам.

Сервисной службе нужно знать, кто ждет их на объекте. Связанные записи помогают каждой команде видеть людей, относящихся к клиенту, не дублируя эту информацию в каждом приложении. Продукты – еще один распространенный пример. Торговому представителю нужно знать, что продает компания, какова стоимость продукта и есть ли он в наличии. Эти ответы обычно приходят из операционной части бизнеса, так как именно там управляют продуктами, запасами, закупками и выполнением заказов. Вот почему информация о продуктах часто создается в модуле финансов и операций. Операционная команда создает и подготавливает продукт там. Как только продукт готов для работы с клиентами, Далрайт передает соответствующие сведения в Dataverse. Пользователи отдела продаж могут выбирать и обсуждать продукт в своем приложении без повторного ввода списка продуктов. Это помогает строить беседы с клиентами на основе того, что бизнес действительно может предоставить. Данные о ценах и складских запасах также могут поступать в отдел продаж через связанные приложения. Вместо того, чтобы гадать, существует ли товар, изменилась ли цена и позволяют ли запасы выполнить обещания. Отдел продаж может опираться на информацию, связанную с операционной стороной. Это не отменяет необходимости в хорошем коммерческом чутье. Это устраняет одну лишнюю причину, по которой торговый представитель звонит на склад для уточнения базовых деталей. Информация о поставщиках также может передаваться туда, где она требуется для бизнес-процессов. Реквизиты компании, организационные структуры, финансовые и налоговые справочные данные могут быть важны как для клиентской, так и для операционной стороны.

Конкретные записи зависят от приложений и процессов компании, но общая схема остается прежней. Обменивайтесь записями, которые должны означать одно и то же в обеих системах. Не стоит полагать, что каждая запись должна передаваться в обоих направлениях. Некоторые приложения поддерживают двусторонние обновления. Изменение может начаться в Dataverse и перейти в Finance and Operations или наоборот. Такой подход подходит для записей, где обе стороны имеют веские деловые причины для обновления данных. Другие схемы работают в одном направлении. Продукты – отличный тому пример. Во многих компаниях создание продуктов закреплено за Finance and Operations, поскольку она управляет мастер данными продуктов, запасами и другими деталями, необходимыми для продаж. Затем информация о продукте передается в Dataverse, где ее используют отделы продаж и обслуживания. Это четкое правило. Нет нужды в том, чтобы две команды создавали конкурирующие версии одного продукта.

Одна сторона создает продукт и управляет им, а другая получает его и использует в своей работе. Для каждой общей записи требуется подобное решение. Где создается эта запись? Кто может ее редактировать? Если название, адрес, цена или классификация выглядят неверно, какая команда должна это исправить? Эти вопросы звучат просто, но они предотвращают массу путаницы в будущем. Связь позволяет очень быстро передавать изменения. Если не определено, кто отвечает за эти изменения, так же быстро может распространиться и ошибка. Выберите владельца для записи, а при необходимости и для отдельных полей внутри нее. Например, отдел продаж может отвечать за данные о взаимоотношениях с клиентом и его основные контакты. Финансовый отдел может отвечать за платежные данные, а операционный – за данные о продуктах и запасах. Точное распределение зависит от специфики вашего бизнеса, но оно должно быть задокументировано и понятно сотрудникам.

Существуют также два термина, которые вы встретите после расширения Dataverse через двойную запись «Сторона» – «Парти» и «Компания» – «Компани». Сторона – это способ Microsoft унифицированно работать с физическим или юридическим лицом. Это помогает связывать людей, организации, контакты и адреса, не рассматривая каждую связь как отдельную несвязанную запись. Компания помогает Dataverse понимать контекст бизнес-компании, используемой в «Finance and Operations». Вам не обязательно становиться экспертом по этим терминам в первый же день. Просто знайте об их существовании, поскольку финансы и операции обрабатывают бизнес-структуры, которые должны распознаваться клиентскими приложениями при перемещении записей между двумя странами. Как только записи могут перемещаться в обоих направлениях, процессы вокруг этих записей становятся не менее важными, чем сами данные. Как изменения передаются между приложениями?

Давайте проследим за одним изменением в системе и посмотрим, что происходит на самом деле. Торговый представитель разговаривает с клиентом, который только что переехал в новый офис. Во время этого разговора представитель открывает запись клиента в Dynamics 365 Sales и обновляет адрес. Достаточно просто. Правда. Затем он сохраняет запись. И вот здесь начинается самое интересное. Sales сохраняет это изменение в Dataverse — это сторона данных для клиентских приложений. Затем механизм двойной записи проверяет карту, связывающую информацию о клиенте и адресе между этой стороной и финансами и операциями. Он автоматически отправляет соответствующие изменения. Никаких файлов экспорта, лежащих в общей папке в ожидании, пока их кто-то заберет. Никому не нужно писать в финансовый отдел с просьбой «Эй, пожалуйста, обновите этот адрес». Карта уже знает, какие поля связаны, и отправляет нужные изменения прямо в соответствующую запись клиента в финансах и операциях. Поэтому пользователь финансового отдела может позже открыть эту запись клиента, увидеть обновленный адрес и обработать заказ или подготовить счет без задержек.

Вот и весь практический результат — просто и понятно. Два человека продолжают работать в разных приложениях, но никому не нужно повторно вводить одни и те же данные о клиенте. Торговый представитель работает в интерфейсе, разработанном для общения с клиентами. Пользователь финансового отдела работает в интерфейсе, созданном для финансовых задач. Каждый видит ту информацию о клиенте, которая ему действительно нужна, и именно там, где она нужна. И это работает и в обратном направлении тоже. Представьте, что финансовый отдел обновляет информацию о клиенте в финансах и операциях. Скажем, финансовый специалист исправляет деталь, которая относится к операционной записи клиента. Двойная запись использует соответствующую карту в обратном направлении и отправляет это обновление в Dataverse. Затем Sales или любое другое приложение на базе Dataverse может подхватить его. Это соединение является синхронным для обычной повседневной работы. Синхронность означает, что приложение пытается выполнить обновление в тот же момент, а не откладывают его в фоновое задание, которое может запуститься через 20 минут. Если соединение не может завершить обновление, эта проблема требует немедленного внимания, а не тихого ожидания, пока кто-то заметит несоответствие.

Такое поведение логично для общих бизнес-записей. Вы же не хотите, чтобы адрес клиента, данные о продукте или другая общая информация расходились часами из-за того, что пакетное задание еще не сработало. Люди принимают решение на основе того, что они видят на своем экране прямо сейчас. Таким образом, соединение поддерживает тесную синхронизацию обеих сторон во время работы. Однако текущая работа иногда требует контролируемой паузы. Функция двойной записи включает параметры воспроизведения, паузы и наверстывания. Воспроизведение означает, что сопоставление работает и поддерживаемые изменения передаются в обычном режиме. Пауза временно останавливает сопоставление, когда команде нужно выполнить плановые работы, исследовать проблему или безопасно внести изменения. Но пауза – это не постоянное место для остановки. Пока сопоставление приостановлено, изменения могут накапливаться в очереди в течение ограниченного времени и объема. Когда сопоставление возобновляется, функция наверстывания обрабатывает эти ожидающие изменения. Это помогает командам восстановить работу после запланированного перерыва. Но кто-то должен отвечать за эту паузу и знать, когда сопоставление должно снова запуститься. Прежде чем все это начнет работать в повседневной деятельности. Есть еще один шаг – начальная синхронизация.

Начальная синхронизация приводит существующие записи с обеих сторон к общей отправной точке. Представьте компанию, у которой уже есть клиенты в Finance and Operations и записи клиентов в Dataverse. Соединение не может просто включиться и предположить, что каждая существующая запись уже идеально совпадает. Нужна стартовая линия. Начальная синхронизация помогает перенести существующие данные до того, как пользователи начнут полагаться на обновление в реальном времени. Эта работа требует осторожности, потому что дубликаты записей, неполные адреса и старые тестовые данные не очищаются магическим образом только из-за запуска синхронизации. Напротив, они могут создать проблемы еще быстрее, если записи не следуют согласованным правилам. Когда сопоставления запущены, людям, управляющим двойной записью, нужно четкое место для проверки работоспособности. Двойная запись предоставляет объединенные журналы действий и ошибок, чтобы администраторы могли видеть, что обработало соединение и где возникли проблемы.

Они также могут устанавливать оповещения и пороговые значения. Это означает, что нужные люди узнают о проблемах до того, как пользователи обнаружат их из-за отсутствующего или неудачного обновления. Это представление поддержки важно, потому что у каждой ошибки есть причина. Возможно, отсутствует обязательное поле. Возможно, связанная запись еще не поступила. Возможно, кто-то изменил данные способом, который не соответствует сопоставлению. Повторная попытка обработки неудачной записи без устранения причины обычно просто приводит к повторному сбою. Хорошо настроенная система двойной записи очлеживает соединение, устраняет причины ошибок и фокусируется поставление на записях, которые действительно должны оставаться связанными. Где двойная запись подходит лучше всего? Двойная запись лучше всего подходит, когда ваш бизнес использует Dynamics 365 Finance или Supply Chain Management вместе с клиентскими приложениями, такими как продажи, обслуживание клиентов, выездное обслуживание или управление проектами. Эти приложения поддерживают разные части одного и того же делового процесса. Одна команда общается с клиентом, другая планирует доставку, управляет запасами, очлеживает расходы или отправляет счета. Когда обеим группам необходимо работать со связанными записями в течение дня, функция двойной записи «Далрайт» может объединить эту работу, не заставляя всех переходить в одно приложение. Возьмем в качестве примера процесс от потенциальной сделки до оплаты. Продавец работает с потенциальным клиентом в Dynamics 365 Sales.

Он очлеживает контакты, обсуждает продукты, формирует коммерческое предложение и переходит к оформлению заказа. В ходе этого общения продавцу требуются данные о клиенте, информация о продукте, цены и сведения о заказе, которые относятся к финансовой стороне компании. Как только сделка совершена, финансовый отдел и отдел управления цепочками поставок берут на себя работу, которая следует за обещанием продажи. Они занимаются выполнением заказа, складским учетом, выставлением счетов и ведением финансовой отчетности. Двойная запись помогает этим двум частям оставаться на связи. Продавцы могут работать в клиентском приложении, которое соответствует их задачам, в то время как специалисты по финансам и операциям управляют транзакцией в приложении, созданном для их работы. История клиента не разделяется на две разные версии. Одну – от отдела продаж, другую – от финансового отдела. Филд-сервис – еще один хороший пример. Представьте компанию, которая отправляет технических специалистов для установки, ремонта или обслуживания оборудования на объектах клиентов.

Выездному сотруднику нужны данные о клиенте, подробности о работе и информации о клиентском активе, оборудовании, которое компания установила или обслуживает. За кулисами компания также должна отслеживать детали, расходы, закупки и денежные средства, связанные с этой работой. Филд-сервис фокусируется на планировании и выполнении визита. Finance and Operations фокусируется на операционных и финансовых записях вокруг этого процесса. Когда эти записи правильно связаны, работа техника не отделяется от использованных деталей, стоимости работ или связанной с ними записи клиента. Project Operations следует той же схеме, особенно для компаний, которые продают работу по проектам. Проектная команда может управлять работой с клиентом, временем сотрудников, плановыми затратами и этапами проекта. Финансовому отделу необходимо видеть финансовую сторону закупок, затрат, выставление счетов и отчетности. Без связи менеджеры проектов могут тратить слишком много времени на запросы обновлению финансистов, пока те ждут от команд подтверждения произошедших событий. Связанные проектные записи дают обеим группам более четкое представление о ходе работы по мере ее перехода от обещания клиенту к финансовой деятельности.

Здесь также есть более широкое преимущество Power Platform, поскольку сторона клиентского приложения использует Dataverse, а одобренные данные в Dataverse могут поддерживать Power Apps и Power Automate. Компания может создать небольшое приложение для внутренней команды или настроить поток, который реагирует, когда бизнес-запись достигает определенного статуса. Это не означает, что каждая запись из Finance and Operations должна внезапно появиться в каждом приложении Power App. Это означает, что связанные записи могут стать частью более широкого набора бизнес-инструментов, если компания тщательно определяет эту цель и должным образом защищает данные. Одна граница должна оставаться четкой. Dalright не поддерживает Dynamics 365 Business Central. Бизнес-централ может подключаться к другим продуктам Microsoft иными способами, но Dalright предназначен для финансово-операционного направления Dynamics 365 и клиентских приложений на базе Dataverse. Это также не инструмент для копирования каждой таблицы, которую вы можете найти. Запись должна перемещаться, если людям нужна одна и та же операционная запись в обоих местах, а не потому, что копирование данных кажется более безопасным. Dalright также не заменяет более широкий план интеграции, когда компании требуются каналы отчетности, связи со сторонними системами или масштабная миграция данных. Если относиться к каждому подключению данных как к одной и той же задаче, это быстро создает проблемы. Ограничения, подготовка и распространенные ошибки Представьте Dalright как рукопожатие между двумя системами. Они договариваются синхронизировать определенные общие записи, но это не волшебный канал для любой таблицы, отчета или внешней системы.

Прежде чем настраивать систему, проверьте, какие интеграции уже существуют. Если старое подключение и Dalright одновременно обновляют одну и ту же запись клиента, могут быстро возникнуть конфликты. Это головная боль, которая вам не нужна. Поэтому сначала договоритесь об основах. Как вы будете вводить имена? Какая юридическая компания владеет каждой записью? Кто может вносить изменения? Какие роли безопасности нужны каждой команде? Дубликаты и неполные записи перед первой синхронизацией. Начните с готовых карт от Microsoft. Они уже соединяют распространенные типы записей. Пользовательские таблицы и поля требуют тщательного тестирования. Проверьте связанные таблицы и зависимости карт, потому что иногда для синхронизации одной записи требуется наличие другой. Планируйте первую синхронизацию, исходя из объема ваших данных. Не относитесь к этому как к выключателю света, который можно щелкнуть во время обеда. Это приведет к проблемам. Для приостановленной карты по-прежнему нужны владелец и план перезапуска. Очереди изменений и неудачные записи не хранятся вечно. Следите за журналами активности, ошибками, оповещениями и пороговыми значениями. Когда что-то не получается, найдите отсутствующее поле, неверную запись или нарушенное правило. Многократные повторные попытки не исправят плохие данные. Когда вы воспринимаете Далрайт как контролируемый мост, все встает на свои места. Заключение – единый общий бизнес-диалог.

Далрайт обеспечивает перемещение поддерживаемых общих записей между финансово-операционными системами и вашими клиентскими приложениями на базе Dataverse. Благодаря этому команды могут работать с взаимосвязанными бизнес-данными. Подписывайтесь на своей любимой подкаст-платформе, чтобы получать больше полезных знаний со мной, Мирко Питерсом, на m365.fm. И поделитесь этим выпуском с тем, кто все еще связывает продажи, обслуживание и финансы с помощью очередной таблицы.